AIを企業に導入する。
言葉だけを見ると、ずいぶん簡単そうです。
APIをつないで、データを渡して、プロンプトを書いて、動けば完成。
実際の企業システムは、そうきれいには進みません。
データは複数の部署やシステムに散らばっています。業務には例外があり、AIの回答をそのまま信用できない場面もあります。技術的に動くシステムができても、現場の人が本当に使うとは限りません。
OpenAIでForward Deployed Engineering（FDE）を率いるColin Jarvis氏のインタビューを見ると、この「AIは動く」と「仕事で使える」の距離を埋めることが、FDEの大きな役割だと分かります。
しかも仕事は導入で終わりません。
顧客固有の問題を現場で解き、その中から別の企業でも使える技術を見つけ、OpenAIのプロダクトへ戻していく。
FDEは、顧客の課題を見つけ、実装し、評価し、その解決方法を次の製品へ変えていくエンジニアです。
FDEは何を作るか決まっていないところから始まる
Forward Deployed Engineerを直訳すれば、「前線に配置されたエンジニア」といった意味になります。
OpenAIのFDEは実際に顧客の現場へ入り、業務を理解しながらシステムを作ります。
コードを書き、AIシステムを組み、評価し、必要なら本番環境まで持っていく。ここまでは、顧客と近い距離で働くエンジニアとして想像しやすいところです。
普通のソフトウェア開発と少し違うのは、作るものが最初から決まっているとは限らないことです。
顧客から「この機能を作ってください」と仕様が渡されるのではなく、「うちの業務を見て、AIで大きな問題を解決してほしい」というところから始まる場合があります。
Jarvis氏はFDEを立ち上げた背景として、顧客の業務ドメインを深く理解し、現場のユーザーと一緒に仕事をする方法が、本番導入まで進めるうえで一貫して効果的だったと説明しています。
FDEには「何を作るべきか」を見つけるところまで含まれます。
狙うのは、FDEを投入するだけの価値がある大きな問題
Jarvis氏の話では、OpenAIのFDEは顧客にとって数千万ドル規模、場合によっては数十億ドル規模のコスト削減や売上創出につながり得る課題を狙うとされています。
これは、すべての案件で実際にその金額の成果を出すという意味ではありません。
FDEという限られた人員を投入する以上、それに見合う大きさの問題を選ぶという考え方です。
顧客から来る小さな要望を一つずつ実装していけば、FDEは簡単に受託開発チームになります。
OpenAIが目指しているのは、大きな問題を解き、その過程で得られた技術をプロダクトやプラットフォームへ戻す流れです。
インタビューではPalantir由来の表現として「Eat Pain → Excrete Product」という言葉も紹介されています。
かなり強い言い方ですが、顧客固有の「痛み」を引き受け、そこから再利用できる製品を生み出すというFDEの性格はよく表れています。
Morgan Stanleyでは技術より「信頼」に時間がかかった
企業AIが本番まで進む難しさをよく表しているのが、Morgan Stanleyの事例です。
OpenAIは2023年、Morgan Stanleyのウェルスマネジメント部門へGPT-4を導入しました。
大量のリサーチレポートから、ウェルスアドバイザーが必要な情報を利用できるようにするシステムです。
OpenAIのチームはMorgan Stanleyのエンジニアとともに検索精度を調整し、適切なレポートを取得できる仕組みを構築しました。
Jarvis氏によれば、技術的な部分は6〜8週間ほどで形になりました。
ところが、その後さらに4か月をかけて、アドバイザーによるパイロット、評価、改善を繰り返しています。
現場の利用者が「このシステムなら仕事で使える」と判断できるところまで、信頼性を積み上げる必要があったためです。
最終的には約98％のアドバイザーが利用し、リサーチレポートの利用量は約3倍になったとJarvis氏は説明しています。
システムを作るのに6〜8週間。現場が信頼できる状態へ持っていくのに、さらに4か月。
企業AIをモデル性能だけで考えると、この後半部分が抜け落ちます。
半導体企業では、AIの担当範囲を少しずつ広げた
ヨーロッパの半導体企業では、FDEが業務を調べた結果、エンジニアの時間の70〜80％がバグ修正や旧世代チップとの互換性維持に使われていることが分かりました。
FDEチームは企業のバリューチェーンを調査し、10種類のユースケースを展開。最終的にはエンジニアの作業時間50％削減を目標とし、インタビュー時点では最初の数部門で20〜30％の削減を達成していたとされています。
ここで興味深いのは、自動化の進め方です。
最初からAIに修正まで任せたわけではありません。
まずCodexを使い、バグを調査して原因候補をまとめたチケットを作らせる。結果が信頼できるようになったら、実際の修正へ進ませる。次にPull Requestを作らせる。さらにAI自身のコードを試せる実行環境を用意する。
バグを調査する
↓
原因を提案する
↓
修正する
↓
Pull Requestを作る
↓
実行環境でテストする
責任範囲を段階的に広げ、最終的には「デバッグ調査・トリアージ・エージェント」と呼ばれる仕組みに発展しました。
AIエージェントを一気に完成させるより、どこまでならAIへ任せてもよいかを評価しながら広げていると見るほうが実態に近い事例です。
企業AIでは「動いた」だけでは完成にならない
この段階的な自動化を支えるのが、Jarvis氏が説明するEval Driven Developmentです。
AIが出した結果を評価セットで継続的に検証できる状態にしてから、完成とみなす考え方です。
通常のソフトウェアであれば、入力と期待する出力を決め、テストが通るかを確認できます。
LLMは確率的な性質を持つため、「一度うまく動いた」という確認だけでは足りません。
- どの種類の入力なら正しく処理できるか
- どのケースで失敗するか
- 成功率がどの程度か
こうした評価を継続できなければ、本番環境へ持っていく判断が難しくなります。
Jarvis氏は、LLMが書いたコードについても、評価セットが揃うまでは完成とみなさない考え方を説明しています。
これはFDE固有の話というより、生成AIをデモから業務システムへ移すときに出てくる問題です。
LLMには判断させる。でも、全部は任せない
OpenAIのFDEでは、何でもLLMに処理させる設計を取っているわけではありません。
インタビューで紹介されたサプライチェーンのデモでは、LLMが状況を理解し、複数のデータを組み合わせ、シミュレーションを実行します。
一方、最低2社のサプライヤーを確保する、リードタイムを守る、必要な材料がある、関税計算が正しい、といった絶対条件は通常のコードで検証します。
LLMは曖昧な情報を扱ったり、状況に応じた判断をしたりするのが得意です。
決められた条件を必ず同じルールで検査する仕事は、決定的なプログラムのほうが向いています。
柔軟な判断をLLMへ任せ、絶対に守る条件はコードで保証する。
企業AIを本番で使うなら、モデルの能力だけでなく、この境界をどこに置くかが設計の一部になります。
FDEがコンサルや受託開発と違うのは「その後」
顧客の業務を調べ、システムを作り、本番まで持っていく。
この説明だけなら、FDEはコンサルティング企業やSIerにかなり近く見えます。
OpenAIのFDEには、その案件で得た技術や知識をOpenAI側へ戻す役割があります。
一社のために作った仕組みの中から、他社でも繰り返し発生する問題を見つける。それを抽象化し、再利用できる製品へ変える。
カスタム開発そのものを、プロダクト探索の工程として扱っているわけです。
Klarnaの課題からSwarm、Agent SDK、AgentKitへつながった
その流れがよく見えるのが、KlarnaとT-Mobileの事例です。
Klarnaでは、カスタマーサービス向けのアプリケーションを構築しました。
対応するポリシーが20件程度なら個別のプロンプトでも扱えますが、400件以上になると同じ作り方ではスケールしません。
そこで指示とツールをパラメータ化し、それぞれの意図を評価セットで包む仕組みを作りました。
この仕組みを汎用化したものが、オープンソースで公開されたSwarmです。
次のT-Mobileでは、Klarnaよりポリシーの量と複雑さが約10倍に増えました。同じ仕組みをさらに拡張したことでプロダクトチームとの連携が進み、現在のAgent SDKへつながる流れが生まれ、その延長線上にAgentKitがあるとJarvis氏は説明しています。
Klarna
↓
Swarm
↓
T-Mobile
↓
Agent SDK
↓
AgentKit
最初からAgentKitという製品を企画して、この事例を当てはめたわけではありません。
具体的な顧客の問題を解いた結果、別の顧客にも共通する構造が見つかり、それを製品へ育てていった流れです。
OpenAIのFDEが経験した失敗は「一般化が早すぎたこと」
プロダクトへ戻すことが目的なら、最初から汎用的なものを設計したほうが効率的に見えます。
Jarvis氏は、FDEチームが経験した大きな失敗の一つとして、まさに「一般化が早すぎたこと」を挙げています。
ChatGPTのような大規模なプロダクトを持っていると、「この機能は企業にも使えるのではないか」と考え、先に汎用機能を作って、それを必要とする顧客を探しに行きやすい。
すると、実際の顧客が何に困っているのかを十分理解しないまま製品を作ることになります。
FDEでは逆の順序を取ります。
一社の具体的で大きな問題へ深く入り込み、まずその問題を解く。別の顧客でも同じような構造が見つかったときに、初めて共通部分を取り出します。
汎用化を目的に問題を探すのではなく、現場で繰り返し現れたものを汎用化するわけです。
FDEは「ゼロイチ」を担当し、再利用性が高まったら渡す
Jarvis氏はFDEを「ゼロイチ」のチームとして説明しています。
最初の顧客でプロダクト仮説を試し、次の顧客、その次の顧客で再利用できる範囲を増やす。
インタビューでは、最初の案件で20％程度しか再利用できなかったとしても、次の2〜3回で50％程度まで再利用性を高め、そこからスケールを担当する部門へ渡すという考え方が語られています。
難しい問題を見つける
↓
顧客と一緒に解決する
↓
共通部分を抽出する
↓
再利用性を高める
↓
プロダクト化する
↓
スケール部門へ渡す
FDEが永久に顧客案件を抱え続けるモデルではありません。
むしろFDEが仕事をするほど、その後はFDEがいなくても販売・展開できるものが増えていく状態が理想になります。
FDEにはAIの知識だけでは足りない
OpenAIのFDEが扱う仕事を並べると、必要な能力の幅が見えてきます。
顧客の業務を理解する。曖昧な状況から価値の大きな問題を探す。自分でコードを書く。LLMを評価する。既存データやシステムと統合する。本番環境で信頼性を確保する。
さらに、その仕事の中から再利用可能な技術まで見つけなければなりません。
プロダクトエンジニアなら、既存プロダクトをどう良くするかへ集中できます。
FDEは「そもそも何を作れば価値があるのか」というところから扱います。
技術、顧客、プロダクトの間を頻繁に行き来する職種です。
企業AIでは、データをつなぐだけでも足りない
Jarvis氏が今後伸びる領域として触れているのが、データとビジネスロジックの間にある変換層です。
企業には、データウェアハウス、社内文書、SharePoint、各種APIなど、さまざまな場所に情報があります。
それらをLLMへ接続しただけでは、企業の仕事を正しく理解できるとは限りません。
どのデータをどの条件で組み合わせるのか。この数字は業務上何を意味するのか。どこまで自動化を許してよいのか。
データの意味と業務ルールを、モデルが使える形へ変換する層が必要になります。
Jarvis氏は、MCPコネクタを接続するだけでは足りず、その間に軽量なロジック層を作ることが多かったと説明しています。
モデルが高性能になるほど、企業側では「何を見せるか」「何を実行させるか」「どの条件をコード側で保証するか」という周辺設計の比重が上がります。
FDEは現場の問題をOpenAIへ戻す経路でもある
Jarvis氏は、エージェントを動かすオーケストレーション、評価、ガードレール、データのラベル付け、トレーニングセット構築といった基盤が揃った先に、特定業務向けのファインチューニングが広がる可能性についても語っています。
本人も予測だと前置きしているため、これを2026年の確定したロードマップとして読むべきではありません。
ただ、この考え方はFDEの仕事ときれいにつながります。
顧客の現場へ入り、実際の成功と失敗を観察する。評価する。データを作る。その結果をプロダクトやモデルへ戻す。
FDEはAIを導入するだけでなく、現実の業務でAIがどこに失敗するのかをOpenAI側へ持ち帰る経路でもあります。
FDEが埋めているのは、企業AIの「最後の数メートル」
AIモデルの性能が上がれば、企業導入も自動的に簡単になるように見えます。
実際には、モデルが賢くなったあとにも大量の仕事が残ります。
どの業務に使うのか。何を正解とするのか。どう評価するのか。どこまでAIへ任せるのか。既存データをどんな意味で渡すのか。現場が信頼できる状態までどう持っていくのか。
そして一社で解いた問題から、次の製品をどう作るのか。
OpenAIのFDEは、この一連の工程を顧客の現場で扱っています。
技術デモを作る仕事と考えると、Morgan Stanleyで信頼を作るために費やした4か月や、KlarnaからAgent SDKへ続く流れは説明しにくくなります。
現場で本当に使えるところまで持っていき、その過程で見つけた共通問題を製品へ変える。
AIの能力と企業の現実のあいだに残っている「最後の数メートル」を埋めるところに、OpenAIのFDEという仕事の特徴があります。
よくある疑問
FDEは普通のソフトウェアエンジニアと何が違うのですか？
OpenAIのFDEでは、仕様が決まった機能を実装するだけでなく、顧客の業務へ入り、何を解決すべきかを見つけるところから担当します。実装、評価、本番導入に加え、その解決方法から再利用できる技術を見つけ、プロダクトへ戻すことも役割に含まれます。
FDEはSIerやコンサルタントと同じ仕事ですか？
顧客の課題を調べ、システムを構築する点には共通部分があります。ただし本記事で扱ったOpenAIのFDEでは、個別案件を納品して終えるのではなく、そこで得た知識を別の顧客で再利用し、最終的にOpenAIの製品へ戻すところまで重視されています。
なぜAIシステムに評価セットが必要なのですか？
LLMは確率的な性質を持ち、一度正しく動いたことだけでは本番での信頼性を判断しにくいためです。OpenAIのFDEでは、どのケースで成功・失敗するかを継続的に確認できる評価セットを使い、システムの完成度を判断しています。
FDEは何でもLLMに自動化させるのですか？
本記事の事例ではそうなっていません。曖昧な判断や情報の統合にはLLMを使いながら、必ず守る必要がある条件は通常のコードで検証するなど、処理の性質によって役割を分けています。
参考・参照元
本記事は、OpenAIのForward Deployed Engineering責任者Colin Jarvis氏へのインタビューを中心に、関連資料を参照しています。
- The Altimeter Podcast — Colin Jarvis | Head of Forward Deployed Engineering at OpenAI: Trust. Product. Impact.
- Apoorv Agrawal — “Eat Pain → Excrete Product: The FDE Playbook”
- ITmedia AI＋ — OpenAIが明かす、新職種「FDE」の実態
- Gregor Ojstersek — “Inside OpenAI’s Forward Deployed Engineer Role”
なお、FDEは企業によって仕事内容や位置づけが異なります。この記事では一般的なFDE職の定義ではなく、OpenAIがFDEをどのように運用しているかを中心に扱っています。
コメント