OpenAIには、Forward Deployed Engineer、略してFDEと呼ばれるエンジニアがいます。
名前だけを見ると、「顧客先へ派遣されるエンジニア」のようにも聞こえます。
実際にはもう少し役割が広い仕事です。
OpenAIのFDEは、顧客の現場へ入り、どこにAIを使えば本当に価値が出るのかを見つけ、システムを設計・実装し、本番導入まで持っていくエンジニアです。
さらに、その顧客で得られた解決方法を一社専用のシステムで終わらせず、他社でも使える仕組みとして抽象化し、OpenAIのプロダクトやプラットフォームへ戻していきます。
現在OpenAIはFDEについて、顧客とともに研究上の成果を本番システムへ変えるチームであり、「customer delivery」と「core platform development」の境界で働く存在だと説明しています。
仕事内容には、課題の発見、技術スコープの決定、システム設計、実装、本番展開、利用定着まで含まれます。
つまりFDEは、単なる「AI導入支援」でも「顧客向け受託開発」でもありません。
現場の問題を解決しながら、次のOpenAI製品を見つける仕事でもあります。
OpenAIのFDEとは何をする仕事なのか
OpenAIの現在の採用情報を見ると、FDEの仕事はかなり具体的です。
顧客と一緒に業務を調べる。
どの問題へAIを使うべきかを決める。
技術的な要件を整理する。
システムを設計する。
必要なら自分でコードを書く。
モデルを既存のデータやシステムへ接続する。
評価を行う。
そして、試作品ではなく安定した本番環境まで持っていく。
OpenAIはFDEの成果を、単に「システムが完成したか」ではなく、実際に現場で使われているか、業務に測定可能な効果が出ているかという点でも評価しています。
また、現場で得られた情報をResearchやProductへ戻し、モデルや製品のロードマップにも反映します。
ここが一般的な顧客サポートとの大きな違いです。
なぜ企業AIにはFDEが必要なのか
「AIを企業へ導入する」と聞くと、ずいぶん簡単そうに感じます。
APIをつなぐ。
データを渡す。
プロンプトを書く。
動けば完成。
ところが実際の企業システムは、そんなに単純ではありません。
データは複数の部署やシステムへ分散しています。
業務には例外があります。
AIの回答をそのまま信用できない場面もあります。
既存の承認フローやセキュリティルールもあります。
そして何より、「技術的には動く」と「現場が本当に使う」の間には大きな距離があります。
OpenAIのFDE責任者だったColin Jarvis氏は、FDEという形が生まれた背景として、従来の比較的ハンズオフな技術支援だけでは、企業を安定して本番利用まで導くことが難しかったと説明しています。
顧客の業務を深く理解し、実際の利用者と一緒に作る方式の方が、本番導入まで進む確率が高かった。
そこからForward Deployed Engineeringという形が作られていきました。
FDEは「何を作るか」を決めるところから始まる
一般的なソフトウェア開発では、ある程度作るものが決まっています。
「この機能を実装してください」
という要求から始まることが多いでしょう。
FDEの場合は、そこまで決まっていないことがあります。
むしろ、
「この業務を見て、AIで最も大きな価値を出せるところを探してほしい」
というところから始まります。
そのため、コードを書く前に顧客の業務を理解しなければなりません。
どの工程に時間がかかっているのか。
どこでミスが起きるのか。
どの作業ならAIへ任せてもよいのか。
どこでは人間の判断が必要なのか。
つまり、「何を作るべきかを決めること」自体がFDEの仕事に含まれています。
OpenAIがFDEに任せるのは「小さな課題」ではない
Jarvis氏の説明で印象的なのが、FDEが狙う問題の大きさです。
OpenAIでは、顧客にとって非常に大きなコスト削減や売上創出につながる可能性がある問題を優先すると説明していました。
もちろん、すべての案件が実際にその規模の成果を生むという意味ではありません。
重要なのは、FDEという希少な人材を投入する価値があるほど重要な問題を選ぶことです。
顧客から頼まれたことをすべて実装するのであれば、FDEは簡単に受託開発チームになってしまいます。
OpenAIが狙っているのは、そこではありません。
大きな問題を解決し、その過程で得た知識をOpenAI側へ戻す。
顧客案件を、次のプロダクトを見つける探索としても利用します。
Morgan Stanleyで分かった「AIが動く」と「AIを使う」の違い
FDEの役割が分かりやすく見えるのが、Morgan Stanleyの事例です。
OpenAIは2023年、Morgan Stanleyのウェルスマネジメント部門にGPT-4を導入しました。
目的は、膨大なリサーチレポートをウェルスアドバイザーが利用しやすくすることでした。
OpenAIのチームはMorgan Stanleyのエンジニアと一緒に入り、検索精度を調整し、必要なレポートを適切に取得できる仕組みを構築しました。
Jarvis氏によれば、技術的な部分は6〜8週間ほどで形になりました。
しかし、それで導入は終わりませんでした。
そこからさらに約4か月、ウェルスアドバイザーによるパイロット、評価、改善を繰り返しています。
現場の利用者が「これは仕事で使える」と信頼できる状態まで持っていく必要があったからです。
最終的には約98％のアドバイザーが導入し、リサーチレポートの利用量は約3倍になったとJarvis氏は説明しています。
企業AIの難しさが、この数字に表れています。
6〜8週間で技術はできた。
しかし、信頼を作るにはさらに4か月かかった。
モデルの性能だけを見ていると、この部分を見落とします。
半導体企業では「バグを見つけるAI」から「バグを直すAI」へ
もう一つ興味深いのが、欧州の半導体企業での事例です。
FDEが最初に調べたのは、「どのAIを入れるか」ではありませんでした。
どの仕事に最も時間が使われているかです。
調査すると、エンジニアの業務時間の70〜80％が、バグ修正や旧世代チップとの互換性維持などに使われていました。
そこでFDEチームは複数のユースケースを展開し、エンジニアの作業時間を減らすことを目標にしました。
興味深いのは、自動化の進め方です。
最初からAIへバグ修正を任せたわけではありません。
まずAIにバグを調査させる。
原因候補を提示させる。
それが十分信頼できるようになったら、修正案を作らせる。
さらにPRを作らせる。
その後、AI自身が書いたコードをテストできる環境を用意する。
つまり、
調査 → 信頼 → 修正 → テスト → 自動化
という順番で、AIへ任せる範囲を広げています。
「AIエージェントを作る」というより、AIへ任せてもよい責任範囲を評価しながら広げていく方式です。
だから企業AIには「評価」が必要になる
ここで重要になるのが、Eval、つまり評価です。
LLMは普通のプログラムとは違い、確率的に動きます。
一度うまく動いたからといって、別のケースでも正しく動くとは限りません。
そのため、
- どのケースなら成功するのか
- どこで失敗するのか
- どの程度の成功率が必要なのか
- モデルを変更したら性能がどう変わったのか
を継続的に測定する必要があります。
Jarvis氏は、LLMが生成したコードについても、評価セットが揃うまで完成とは考えないという趣旨の説明をしています。
これはFDE特有の話ではありません。
AIをデモから業務システムへ変えるときの基本条件です。
AIが大量のコードを書く時代に、人間がどこを確認すべきなのかという問題については、AIコード時代、コードレビューは誰のためにあるのかでも詳しく扱っています。
LLMだけで全部やらせない
OpenAIのFDEの考え方でもう一つ重要なのが、何でもLLMへ任せないことです。
たとえばサプライチェーンのデモでは、LLMが状況を理解し、複数の情報を組み合わせ、シミュレーションを行います。
一方で、
- 最低限必要なサプライヤー数
- リードタイム
- 必要な材料の確保
- 関税計算
など、絶対に守らなければならない条件は決定的なロジックで確認します。
つまり、
判断や曖昧さを扱う部分はLLM。
絶対条件は通常のコード。
という役割分担です。
LLMは柔軟ですが、確率的です。
通常のプログラムは、決められた条件なら同じ結果を返せます。
どちらか片方ですべてを作るのではなく、それぞれの得意な部分を組み合わせます。
FDEはコンサルタントやSIerと何が違うのか
ここまで読むと、FDEをコンサルタントや「AI時代のSIer」と考えたくなるかもしれません。
顧客の業務を調査し、システムを作り、本番まで持っていく。
確かに似ています。
OpenAIのFDEで特徴的なのは、その後です。
通常の受託開発なら、顧客へシステムを納品することが大きなゴールになります。
FDEでは、顧客案件から得られた解決方法を抽象化します。
別の顧客でも使えるか試します。
再利用性を高めます。
そして、プロダクトやプラットフォームへ戻します。
顧客案件そのものが、次の製品を作るための研究開発になっている。
ここが大きな違いです。
Klarnaの課題からSwarm、Agent SDKへつながった
その流れが分かりやすいのがKlarnaとT-Mobileの事例です。
Klarnaとの取り組みでは、カスタマーサービス向けのAIシステムを作りました。
最初は20件程度のポリシーを扱えても、それを400件以上へ拡大しようとすると、単純にプロンプトを書き足す方法ではスケールしません。
そこで、指示やツールを構造化し、それぞれの意図を評価セットで確認できる仕組みを作りました。
この考え方を一般化して公開されたものがSwarmです。
その後、より大規模で複雑なT-Mobileの案件へ応用され、プロダクトチームとの連携が進みました。
その流れがAgent SDKなどの製品へつながっていきます。
重要なのは、最初から「Agent SDKを作ろう」と考えて始めたわけではないことです。
顧客の具体的な問題を解いた結果、他の顧客でも繰り返し使える構造が見えてきた。
それを製品へ変えています。
「早すぎる一般化」がFDEの失敗になる
この方式には大きな落とし穴もあります。
一般化するのが早すぎることです。
Jarvis氏は、FDEで経験した大きな失敗の一つとして「早すぎる一般化」を挙げています。
巨大なプロダクトを持つ企業では、
「この機能は多くの企業で使えるのではないか」
と先に考えやすくなります。
そして、その機能を使ってくれそうな顧客を探す。
しかし、それでは本来の問題を十分に理解しないまま、先に答えを作ってしまいます。
FDEでは逆の順番を重視します。
まず誰かの本当に大きな問題を解く。
その解決策の中から、他でも使える部分を見つける。
一般化はその後です。
OpenAIのFDEは「ゼロイチ」のチーム
Jarvis氏は、FDEを「ゼロイチ」の仕事として説明しています。
最初の顧客で仮説を試す。
次の顧客でも試す。
再利用できる部分を増やす。
十分に共通化できたら、プロダクトやスケールを担当するチームへ渡す。
つまり、
問題を見つける
↓
顧客と解決する
↓
共通部分を見つける
↓
プロダクト化する
↓
大規模に展開する
という流れです。
FDEが永遠に同じ顧客を担当することが目的ではありません。
理想的には、FDEが解いた問題が製品化され、次からはFDEがいなくても導入できるようになります。
FDEと普通のソフトウェアエンジニアの違い
FDEもコードを書くエンジニアです。
ただし、一般的なプロダクトエンジニアとは仕事の出発点が違います。
プロダクトエンジニアは、基本的には存在するプロダクトを改善します。
FDEは、何を作るべきなのかという問いから背負う場合があります。
そのため必要になる能力も広くなります。
- 顧客の業務を理解する
- 曖昧な問題から価値の高い課題を見つける
- システムを設計する
- 本番品質のコードを書く
- LLMを評価する
- 既存データやシステムと統合する
- セキュリティや信頼性を確保する
- 現場への導入・定着を進める
- 再利用可能なパターンを見つける
現在OpenAIが東京で募集しているFDE職でも、技術的な発見から設計、構築、本番展開までを一貫して担当し、顧客チームと密接に働くことが求められています。
企業AIで難しいのは「データと業務の翻訳」
FDEの仕事を見ていると、AIモデルそのものより難しい部分も見えてきます。
企業には大量のデータがあります。
データウェアハウスにもある。
社内文書にもある。
SharePointにもある。
APIもあります。
しかし、それらをLLMへそのまま渡せば業務を理解できるわけではありません。
「この数字にはどういう意味があるのか」
「どの条件なら、このシステムのデータと組み合わせてよいのか」
「この業務では、どこまでAIに任せてよいのか」
といった業務上の意味を、AIシステムが扱える形へ変換する必要があります。
モデルが賢くなるほど、
何を見せるのか。
何をさせるのか。
どこで人間の承認を要求するのか。
という周辺設計が重要になります。
OpenAIは2026年、FDEをさらに大きな事業へ広げた
FDEは現在、OpenAI内部の小規模な実験チームという段階ではありません。
OpenAIは2026年5月、企業へのAI導入を支援するOpenAI Deployment Companyを立ち上げました。
この発表でOpenAIは、Forward Deployed Engineerを企業へ深く入り込ませ、重要な業務をAI中心に再設計し、日常的に利用できるシステムへ変えていく方針を明確にしています。
現在は金融、医療、法律、半導体など特定分野向けのFDEも募集されています。
東京でもForward Deployed EngineerやDeployment Leadなどの採用が行われています。
つまりFDEは、OpenAIにとって単なる技術支援チームではなく、企業がフロンティアAIを実運用へ移すための主要な仕組みへ拡大しつつあります。
FDEという仕事の本質は「最後の数メートル」を埋めること
AIモデルが高性能になれば、企業へのAI導入も自動的に簡単になるように思えます。
実際には、モデルが賢くなるほど別の問題が目立ってきます。
どの仕事へ使うのか。
どのデータを見せるのか。
何を成功とみなすのか。
どこまで自動化するのか。
どこに人間の判断を残すのか。
どうすれば現場の人が信頼して使うのか。
AIモデルそのものと、実際の企業業務の間にはまだ距離があります。
FDEの仕事は、その距離を埋めます。
現場に入る。
問題を見つける。
コードを書く。
失敗する。
評価する。
改善する。
本番へ持っていく。
そして、そこで得た解決方法をOpenAIの製品へ戻す。
AIの能力を「使える企業システム」へ変換する最後の数メートル。
それがOpenAIのForward Deployed Engineeringの役割です。
FAQ
OpenAIのFDEとは何の略ですか？
Forward Deployed Engineer、またはチーム全体を指すForward Deployed Engineeringの略です。顧客の現場へ深く入り、AIシステムの課題発見、設計、実装、評価、本番展開までを担当します。
FDEはコンサルタントですか？
顧客の課題を調査する点はコンサルタントと似ていますが、OpenAIのFDEは自らコードを書き、システムを構築し、本番導入まで担当します。また、顧客案件から得た知見を再利用可能な仕組みとしてOpenAIの製品やプラットフォームへ戻す役割もあります。
FDEは普通のソフトウェアエンジニアと何が違いますか？
通常のプロダクトエンジニアは既存製品の開発・改善を中心に担当します。FDEは顧客の現場へ入り、「何を作るべきか」という問題設定から担当することがあります。そのため、技術だけでなく顧客業務の理解や導入、評価、プロダクト化まで広い能力が必要になります。
日本でもOpenAIのFDEは働いていますか？
はい。2026年9月時点でOpenAIは東京のForward Deployed EngineerやDeployment Leadなどを募集しており、日本の顧客向けFDE体制を構築しています。
FDEになるにはどんなスキルが必要ですか？
OpenAIの現在の求人では、本番品質のソフトウェア開発能力に加えて、顧客と直接働いた経験、複雑で曖昧な問題を整理する能力、LLM・生成AIシステムへの理解などが求められています。東京のFDEでは日本語と英語の両方も必要とされています。
コメント