AI人材はFDEだけではない――これから進む専門職の細分化

AIの社会実装とともに明確になる「責任」の境界

最近、Forward Deployed Engineer（FDE）という職種を目にする機会が増えました。

OpenAIのFDEは、顧客と直接協働し、課題の発見、技術的なスコープ設定、システム設計、実装、本番展開までを一貫して担当する役割として説明されています。OpenAIのFDE募集要項

AnthropicのFDEも、顧客の現場へ入り、実際の業務課題を解決するAIアプリケーションを提供する役割です。AnthropicのFDE募集要項

高性能なAIモデルがあっても、それだけで企業の業務が変わるわけではありません。

現場の課題を理解し、AIで解く範囲を決め、必要なシステムを構築し、実際に使える状態まで持っていく必要があります。

この一連の流れを横断するFDEは、AIをPoCで終わらせず、業務成果へつなげるための重要な専門職です。

一方で、FDEが注目される状況を見るほど、私は別の可能性も考えるようになりました。

AIの社会実装を担う専門職は、FDEだけではない。

AIが本番システムへ深く組み込まれるほど、Architecture、Engineering、Platform、Evaluation、Governanceなど、異なる責任を担う専門職の境界が明確になるのではないでしょうか。

FDEが必要とされる背景

現在、AI技術と企業の業務の間には、まだ大きな距離があります。

AIモデルが高性能でも、現場では次の問いに答えなければなりません。

どの業務課題をAIで解くのか
AIを使うことで、どのような価値を生むのか
既存業務のどこへAIを組み込むのか
どのデータやシステムと接続するのか
AIの出力を誰が確認するのか
どの状態になれば本番で利用できるのか

こうした問いは、モデルの性能だけでは解決できません。

業務理解、課題設定、設計、実装、導入をつなぐ役割が必要です。

特に、要件や正解がまだ明確でない導入初期では、一人または少人数のチームが複数の領域を横断する方が速く進められる場合があります。

FDEが重視されるのは、この不確実な状況を横断し、AIを実際の業務へ持ち込めるためだと思います。

一つのAIシステムには、複数の責任が存在する

ただし、AIを本番業務へ組み込む場合、必要になるのは現場導入だけではありません。

例えば、RAGを使って社内情報から回答を生成し、その結果を既存システムへ反映する仕組みを考えてみます。

このシステムを成立させるには、次のような判断が必要です。

判断すること	対応する責任
どの業務課題をAIで解くか	業務理解・現場導入
AIを既存業務のどこへ配置するか	全体Architecture
検索と回答生成をどう実装するか	Applied AI Engineering
データ・モデル・実行環境をどう維持するか	AI Platform
何をもって利用可能な品質とするか	AI Evaluation
どこまでAIに任せ、どこで人間が確認するか	AI Governance・HITL
問題発生時にどう追跡し、差し戻すか	運用・監査設計

これらは互いに関係していますが、同じ責任ではありません。

RAGを実装できることと、回答品質の合格基準を決めることは別です。

本番環境へ展開できることと、AIの出力をどこまで確定値として扱うかを決めることも別です。

一人が複数の役割を担当することはできます。

しかし、

一人が複数の役割を担当することと、役割の境界を曖昧にすることは同じではありません。

AI人材を構成する専門領域

AIに関する職種名や担当範囲は、まだ企業間で統一されていません。

同じ職種名でも、企業によって役割が異なる場合があります。

その前提で、AIシステムに必要な専門領域を責任から整理すると、次のようになります。

専門領域	中心となる問い	主な責任
Forward Deployment	現場のどの問題をAIで解くのか	顧客・業務とAIを接続し、本番導入まで進める
AI Architecture	AIをシステム全体のどこへ配置するのか	AI・人間・データ・既存システムの境界を設計する
Applied AI Engineering	AI機能をどう実現するのか	LLM・RAG・Agentを実装する
AI Platform	AIを継続的に動かす基盤をどう作るのか	モデル、データ、実行環境、監視、共通機能を整備する
AI Evaluation	何をもって利用可能な品質とするのか	評価指標、検証方法、合格基準を設計する
AI Governance・HITL	どこまでAIに任せ、どこで人間が介入するのか	承認、監査、権限、利用範囲、責任分界を設計する

これは標準化された職種分類ではありません。

実際の組織では、複数の領域を一つの職種が担当することもあります。

ただし、すでにAnthropicの採用情報には、Forward Deployed Engineerだけでなく、Applied AI Architect、Applied AI Engineerなどが別の職種として掲載されています。Anthropicの採用情報

職種名はまだ変化するとしても、異なる責任を担う専門性の分化は、すでに始まっていると見ることができます。

導入初期は横断し、社会実装が進むほど分化する

ここからは私の予測です。

AI導入の初期段階では、幅広い能力を持つ人が複数の領域を横断する方が合理的です。

しかし、AIが本番業務へ深く組み込まれ、利用範囲が広がるほど、導入速度以外の要求が増えていきます。

AI導入の段階	優先されるもの	担い方
検証・PoC	可能性の確認、導入速度	少人数が複数領域を横断する
初期導入	業務適合、実装、本番展開	FDEやApplied AI Engineerが広く担当する
利用拡大	品質、再利用性、運用性	Architecture、Platform、Evaluationが明確になる
重要業務への組込み	承認、監査、責任、リスク管理	Governance・HITLを含む責任境界が必要になる

AIシステムが小さいうちは、一人の判断で全体を見渡せるかもしれません。

しかし、対象業務、利用者、データ、モデル、連携先が増えると、必要な判断も増えます。

品質を誰が保証するのか
モデル更新時に誰が再評価するのか
共通基盤を誰が維持するのか
誤った出力による影響を誰が管理するのか
人間の承認をどこへ配置するのか
利用範囲と権限を誰が決めるのか

ここまでを一人の知識と判断だけに依存すると、その人がボトルネックになります。

判断過程も属人化し、問題が起きたときの責任も追跡しにくくなります。

そのため、AIの社会実装が進むほど、

誰が何を作業するかではなく、誰が何を判断し、何について責任を持つか

を明確にする必要が出てくると考えています。

FDEが不要になるわけではない

専門職が細分化されても、FDEの価値が下がるとは限りません。

むしろ、Architecture、Engineering、Platform、Evaluation、Governanceが専門化するほど、それらを顧客や業務課題へ接続する役割が必要になります。

FDEは、すべての専門領域を永続的に一人で担う職種というより、

現場の課題と複数のAI専門領域を接続し、実際の業務成果へ結びつける専門職

として、より明確になる可能性があります。

同時に、複数領域を横断できるGeneralistも必要です。

全体像を理解し、専門家同士の判断をつなぎ、局所最適を防ぐ役割は残ります。

今後必要になるのは、GeneralistかSpecialistかという二者択一ではありません。

複数領域を横断する人と、特定の責任を深く担う人を、どのように組み合わせるか

という組織設計です。

「AIに詳しい人」から「AIの何を担う人」へ

AI人材を評価するとき、LLMを何年扱ったか、どのツールを使えるかは、一つの情報になります。

しかし、AIが本番システムへ組み込まれるほど、より重要になるのは次の点です。

どの問題を解いてきたのか
どの設計判断を行ったのか
何について品質を保証したのか
どこまでをAIへ任せたのか
どの責任を担えるのか
他の専門領域とどう接続できるのか

AIが普及すれば、AIに関わる仕事が一つの職種へ集約される。

私は、むしろ逆になると予測しています。

新しい職種名が次々に生まれることが本質ではありません。

現在すでに存在している専門性の境界が、AIの社会実装とともに明確になっていく。

「AIに詳しい人」から、「AIシステムの何を設計し、何に責任を持つ人なのか」へ。

FDEは、その中で重要な専門職の一つです。

しかし、AIの社会実装を支える専門職はFDEだけではありません。

Architecture、Engineering、Platform、Evaluation、Governance。

AIが企業システムや社会インフラの一部になるほど、これらの責任は、より明確に分化していくのではないでしょうか。

追記：顧客自身が継続的に変えられる仕組みへ

2026年10月6日時点の考察です。専門性の分化に加えて、FDEによる構築と引き渡しの持続性を考えます。

作る費用が下がると、依頼する前提も変わる

顧客の要望を理解し、個別に構築して引き渡すことは、FDEが関わる提供形態の一つです。ただし、FDEの責任範囲は企業や契約によって異なり、個別実装だけに限られるわけではありません。

Coding Agentなどで試作や実装に必要な時間を短くできるなら、顧客が外部へ依頼する範囲も変わる可能性があります。顧客側に業務知識、技術力、検証と運用の体制があれば、自分たちで小さく作り、変更を重ねる選択肢を取りやすくなるためです。

これは、誰もが自力で安全に本番システムを作れるという意味ではありません。実装の入口が広がっても、何を変えるべきか、AIを使うべきか、どのリスクを引き受けるかという判断は残ります。

引き渡した後、誰が変え続けるのか

顧客ごとの構築が速くても、変更のたびに同じベンダーや担当者へ依頼しなければならないなら、導入後の費用と待ち時間が積み上がります。業務、データ、モデル、既存システムが変わったときに、顧客側が前提と責任を理解し、評価して変更できるかが重要です。

Gartnerの2026年9月29日の発表は、2028年までに企業の70%がベンダーFDEによって構築されたAgentic AIを放棄すると予測しています。これは将来予測であり、すでに確認された放棄率ではありません。発表は費用と顧客自身による継続改善の難しさを挙げ、知識移転、運用の所有権、契約時からの移行・終了計画を重視しています。

この予測だけでFDEの将来を決めることはできません。設計上の問いは、構築を終えた後に顧客が自分たちで価値を維持できるか、という点です。

Implementationに加え、ArchitectureとEnablementを担う

私の仮説は、FDEの価値の中心が個別実装から、顧客自身が継続的に改善できる条件の設計へ移る可能性がある、というものです。ここでいうEnablementは、研修や文書の引き渡しだけでなく、顧客が判断・変更・評価・運用を担える状態を整えることです。

変えるべき業務と、実現したい価値を一緒に見つける
AIを使う範囲と、人・AI・既存システムの役割を決める
変更可能なArchitectureと、責任・権限の境界を設計する
本番導入、利用者の習熟、組織への定着まで支える
顧客側に評価基準、変更手順、運用責任を移し、利用結果を改善へ戻せるようにする
必要なら他の仕組みへ統合し、安全に役割を終えられるようにする

深い製品知識や難しい統合を担う実装力は引き続き必要です。その力を、顧客が永久に依頼し続ける構造ではなく、顧客自身の改善能力へつなぐことに意味があります。

専門性の分化を考える際にも、担当者の職名だけでなく、この責任を誰が担い、どう顧客へ渡すかを見る必要があります。FDEがなくなると断定するのではなく、構築・導入・継続改善を接続する役割がどう変わるかを考えたいと思います。