OpenAI の FDE チーム：従来の自分たちの仕事が不要になるのは、FDE が役割を果たした証し

OpenAIには、エンタープライズ顧客の現場に深く入り込んでプロジェクトを共同推進する専門のエンジニアリングチームが存在する。「FDE（Forward Deployed Engineer：顧客の現場で働くエンジニア）」と呼ばれる彼らのミッションは、モデルを顧客の実際の業務フローに組み込み、現場の従業員が安定的かつ確実に利用できるシステムを作り上げることだ。

この取り組みは、手間のかかる作業を伴う。例えば、ある大手半導体企業でのプロジェクトでは、AIを用いてチップのテストパターン生成、障害原因の分析、アーキテクチャ理解の支援などを行うことが求められた。生成されたテストが実用に耐えうるか、特定された障害原因が正しいかは、顧客側のチップ設計エンジニアと共に一つひとつ検証しなければならない。さらにFDEチームは、各種ツールの統合、モデルによるタスク実行のオーケストレーション、ユースケースごとのシステム基盤の構築にも奔走した。

OpenAIはこの案件に約15名のFDEを投入し、10以上のユースケースを推進した。メンバーの中には半導体の知見を持たない者もいたため、顧客の現場チームに常駐しながらチップ設計を一から学ぶこととなった。最初の3〜6か月を経て、これらのユースケースはすべて本番環境に投入され、初期ユーザーへの展開に成功した。その結果、従来は数週間を要していたデバッグ作業の一部が、わずか数時間にまで短縮された。

しかし、Codexの急速な進化が、ようやくプロジェクトを軌道に乗せたエンジニアたちに新たな問いを突きつけることとなった。「数か月かけて苦労して構築したユースケースを、Codexが難なくこなせるようになった今、私たちは次に何をすべきなのか？」

彼らが下した決断は、成熟したCodexによって従来の実装を置き換えていくことだった。個別に開発されていた各アプリケーションを共通フレームワークへと移行し、最終的には関連プロジェクトにおけるカスタムコードの約90%を削減した。

チーム責任者のColin Jarvisは、自分たちの過去の仕事を不要にすることこそ、FDEが正しく機能している証拠だと捉えている。なぜエンジニアリングチームが、自ら心血を注いで築き上げたシステムを自らの手でリプレイスすることを「成功」とみなすのだろうか？

デプロイの溝：モデルができることと、企業が実務で使いこなせない理由

基盤モデルの能力進化は、その能力を実務に落とし込むシステムや業務プロセスの整備よりも遥かに速い。ベンチマークテストで優れた成績を記録するモデルであっても、実際のビジネス現場に投入されると、さまざまな変数や制約条件を前に安定した挙動を示せないことがある。モデルが見かけ上「実行できそうに見えること」と、人間がそれを用いて「確実に業務を完遂できること」の間に横たわるギャップを、OpenAIは「デプロイの溝（Deployment Gap）」と呼んでいる。

農業機械大手ジョンディア（John Deere）の事例は、その分かりやすい例だ。同社の高精度除草技術「See & Spray」は、カメラと機械学習によって雑草を識別し、必要な箇所だけにピンポイントで散布することで、化学薬品の使用量を最大70%削減する。しかし、この成果を実際に享受するためには、農家自身が機器を正しく設定し、作付け計画を立て、天候や環境の変化に応じて作業手順を柔軟に調整できなければならない。

そこでジョンディアはOpenAIのAPIを活用し、より多くの農家にパーソナライズされたサポートを提供している。自然言語での問い合わせ対応や、個別状況に応じた設定アドバイスの提示、機械の性能が十分に引き出されていない箇所の検知などを通じて、農家がテクノロジーの真価を実感できるよう支援している。高精度散布技術が無差別な薬剤使用を削減し、AIを活用した支援サービスが人間による技術の有効活用を支えているのだ。

こうした取り組みには、既成のマニュアルなど存在しない。時には、何が正しい結果であるかを判断する正解基準そのものを顧客とゼロから定義することさえある。FDEはまず達成すべきビジネス成果を正確に把握し、その実現を阻んでいる要因がアプリケーション側のシステム設計にあるのか、それともモデル自体の能力不足にあるのかを見極めなければならない。

成果優先：まず現場で成立させ、その後に再現性を高める

Jarvisがチームに掲げている原則はシンプルだ。「ビジネス成果を起点とし、その実現に必要な作業を完遂した上で、得られた成功を横展開していく」というものだ。

半導体検証は、回路設計が仕様通りに動作するかを確認する工程であり、プロジェクト全体の作業量の約70%を占めることもある。したがって、ここでわずかでも時間を短縮できれば、実際の価値が生まれる。

チームは顧客と共に業務評価（Evals）の仕組みを構築した。単に回答の体裁が整っているかを見るのではなく、実際の具体的タスクを通じてAIが業務を完遂できているかを厳格に検証した。

各ユースケースのために構築された実行フレームワーク（Harness）は、モデルの実行、ツール呼び出し、結果の後処理のオーケストレーションを担った。OpenAIはこのプロジェクトにおける2つの具体的な成果も公表している。

• AIによる対象を絞ったテストの生成により、作業時間を約48%削減。
• コンピュートカーネルの最適化において、パフォーマンス向上の中央値22%を達成。（コンピュートカーネルとは、特定の計算処理を実行する低レベルコードを指す）

チーム編成においては、ジェネラリストとドメイン専門家が柔軟に組み合わされる。例えば生命科学分野のプロジェクトでは、科学的バックグラウンドを持つFDEが研究者と直接対話し、前臨床段階のターゲット検証や優先順位付け、遺伝子発現解析、化学合成経路の再構築などについて議論を交わし、ワークフローをどのように改善できるかを判断する。現場での迅速な学習能力と深い専門的判断力の双方が不可欠なのだ。

アーキテクチャの再構築：なぜ約90%のカスタムコードを削除したのか？

ユースケースが具体的な価値を生み出したとしても、それを全社にスケールさせることには依然として高いハードルが存在した。それぞれのワークフローに多くの個別統合が必要とされ、別のチームへ横展開するたびに、導入や保守に多大な工数がかかっていたからだ。

原文で示された根本原因分析のアーキテクチャ図は、当時の複雑さを克明に物語っている。仮説立案エージェント、インシデント分析ロール、仕様専門家、コード分析ロール、対話型分析ロールが協調してログや仕様書、コードを処理し、各所に専用ツールが接続されていた。チームはユースケースごとに、個別のターミナルUIやCLIエントリーポイントまで作り込んでいたのである。

だがCodexの能力が向上するにつれ、あるFDEがCodexを中心に据えてアプリケーションを再構築する試みを始めた。これを契機に、チームは各ユースケースをCodexを核とする共通実行フレームワークへと移行させた。Codexが共通の実行基盤を担うと同時に統一インターフェースとなったことで、個別構築されていたターミナルUIやCLIは役目を終えることとなった。

個別開発されたアプリケーションは、共通基盤上のプラグインやSkillsへと分解された。繰り返し使用される業務手法はスキルとしてカプセル化され、個別の機能はプラグイン経由で提供されるようになった。これにより、顧客社内のAI推進組織（CoE：Center of Excellence、社内のAI能力を一元管理・推進する組織）が、これらの能力を一括して管理・共有できるようになった。

MCP（Model Context Protocol）は、外部ツールをモデルアプリケーションに接続するための通信規格だ。図中に示されている専用ツールや仕様専門家エージェントは、MCPを介して引き続きシステム内で稼働している。また、コードベースやタスク成果物も変わらずCodexへの入力として機能している。アーキテクチャの簡素化は、業界固有の知識や専用ツール、専門エージェントが不要になったことを意味するわけではない。

Codex本体が集中的に改良されるたびに、これらの全ユースケースがその恩恵を直接受けることができるようになり、チームが個別に維持管理すべき連携コードは大幅に減少した。

もちろん、横展開にあたっては依然として新たなチームが必要とするシステムの接続や、タスクに即した新規評価指標の策定が必要となる。原文では、最初のデプロイに2か月を要したユースケースが、2番目のチームへの展開には1日しかかからなかった事例が紹介されている。これは資産再利用の価値を示すものではあるが、以降のあらゆるプロジェクトが1日で稼働できることを保証するものではない。

チームが初期に本番運用のために費やした膨大な労力は、決して無駄にはならなかった。それらの取り組みがあったからこそ、どのような振る舞いが現場で真に有効であり、いかなる要件を満たすべきかが明確になったからだ。基盤プロダクトが進化を遂げた際、暫定的な個別実装はリプレイスされるが、すでに検証された業務価値はそのままユーザーへと届けられ続ける。

アプリケーション側の未成熟か、それともモデル自体の能力不足か？

原文では、2つの方向性の取り組みが描かれている。モデルがすでにタスクを処理できる能力を備えている場合、FDEは顧客やプロダクトチームと協働して、ソリューションの導入容易性と再利用性を高めることに注力する。一方で、モデルがまだ要件を満たせない場合、顧客や研究開発チームと共に能力ギャップを浮き彫りにし、モデルそのものの継続的改善へと繋げていく。これら2つの取り組みは、ひとつのプロジェクトの中で複雑に絡み合いながら進行することもある。

現場デプロイの積み重ねから再利用可能な能力を抽出する

OpenAIが提供するエンタープライズ向け音声・対話エージェント製品「Presence」は、まさにこうした現場経験の蓄積から誕生した。その取り組みはSwarmからAgents APIへと発展し、さらにPresenceへと結晶化した。チームは実際のデプロイ現場を通じて、どのような課題に個別対応が必要で、どの基本モジュールを共通化して他のチームに提供すべきかを識別し、後発のエンジニアが同じインフラを一から再構築する手間を省けるようにした。OpenAIの開示によると、ある顧客企業ではすでに入電の半数以上をAIが対応しているという。

Thrive Holdingsおよび傘下のCrete会計事務所における「Tax AI」プロジェクトもまた、高度な専門実務がどのように再利用可能な手法へと昇華するかを示している。OpenAIのFDEと研究者は、現場のエンジニアや会計士とワンチームとなってシステムを構築した。パイロット運用において、Tax AIは7,000件の税務申告書を処理し、処理スループットを約50%向上させた。

その中でも、賃貸不動産に関する申告処理では、適合率（Precision）と再現率（Recall）が90%に達するまでに、6週間のエンジニアリング作業と実務専門家による厳格なレビューを要した。適合率は「システムが出力した結果のうち、正しかった割合」を指し、再現率は「本来検出・処理すべき対象を、見落とさずに拾えた割合」を指す。原文ではこの評価がどの具体的な項目や判断基準に基づいて採点されたのかまでは詳述されていないため、この「90%」を「申告書全体の90%を人手を介さず完全自動処理できた」と解釈することはできない。

この難題を克服する過程で確立された再利用可能パターンによって、チームは他の複雑な税務別表への横展開をより容易に進められるようになった。現在、チームは同様のアプローチを記帳、監査、ITサポート業務へも適用しつつある。この事例は、エンジニアリングの実装力とドメイン専門家のフィードバックが一体となって初めて機能することを示しており、開示された情報だけで、課題の原因をプロダクト側かモデル側のどちらか一方に決めつけることはできない。

実務評価がモデルの弱点を研究チームへとフィードバックする

Jarvisは、既存のモデルで完遂できるタスクばかりを扱っていては、研究開発チームが次にどのような能力を底上げすべきかを見出すことはできないと考えている。そのため、多くの重要な戦略的協業案件では、現行のモデルでは歯が立たない難題をあえて出発点とし、顧客、FDE、そして研究チームが一体となってプロジェクトを推進する。

別の大手通信キャリアの事例では、すでにカスタマーサポート基盤が導入されていたが、顧客対応全体の約90%を占める音声領域への拡張が求められていた。しかし音声対応には、訛りや方言への適応、イントネーションの把握、応答の遅延や正確さなど、本番運用の要件が課される。

プロジェクトの初期要件定義フェーズにおいて、主要な業務評価（Evals）におけるモデルのスコアは約60%にとどまっており、特に関数呼び出し（Function calling）と指示追従（Instruction following）の能力向上が急務とされた。関数呼び出しとは、業務を完遂するために必要なツールをモデルが必要に応じて呼び出す仕組みだ。ここが不安定であれば、どれほど会話が滑らかに聞こえても、顧客の実際の手続きを完了させることはできない。

FDEは現状の能力ギャップを率直に顧客に説明し、研究開発チームをプロジェクトへ直接招き入れた。顧客側も未解決の技術的課題を共同で乗り越えることに合意した。FDEがプラットフォームの構築とタスク要件の定義を担い、研究チームがモデルを改良し、新しいモデルスナップショットを継続的に提供した。現場チームが顧客要件に照らしてその進捗を検証し続ける体制が整えられた。

6か月にわたる協業の末、主要業務評価のスコアは約60%から80%へと向上し、最終的には本番要件を満たす90%以上に達した。ここで磨き上げられた音声モデルは、この通信キャリアを支えるだけでなく、他の個別カスタマーサポート展開や、Presenceのマネージド環境にも組み込まれて広く活用されている。

ここにおいて、現場でのデプロイ業務はもうひとつの重要な役割を果たしている。単なる「モデルがまだ力不足である」という抽象的な課題を、繰り返し測定・検証可能な具体的なエンジニアリング課題へと翻訳することだ。研究開発の成果が再び現場へ戻って実証され、ある顧客が直面した困難が、後続の顧客が同じ轍を踏まないための道標となる。

どのような組織にFDEが必要か？ 顧客の自社能力と再利用性の見極め

OpenAIが公開した事例は、「モデルはすでに実現可能だがソリューションのデプロイが困難なケース」と、「モデル自体の能力が要件に未達であるケース」の双方を網羅している。一部の共同研究開発的な事例だけを取り上げて、「すべてのFDEプロジェクトはモデルの能力の限界からスタートしなければならない」と短絡的に捉えるべきではない。

自社組織においてこうしたFDEチームを必要とするかを判断する際には、「顧客が自前でシステム実装を完遂できるリソースやスキルを持っているか」、そして「現場で開発したモジュールを他の顧客へ横展開できるか」という2つの視点が極めて重要となる。当サイトのFDE選定解説記事では、この判断基準についてさらに詳細に掘り下げている。

プロダクトが個別実装を代替したとき、次のより困難な課題へと進む

Jarvisは、大規模言語モデルを活用した開発の大半において、よりシンプルなアプローチを選択することを重視している。その前提条件は常に「現場の課題を確実に解決できること」であり、システムの複雑さはタスク自体の要求水準によって決定されるべきだという思想だ。

すべての顧客協業は、後続の取り組みに対してより強固な足がかりを残すものでなければならない。それは、より導入が容易なプロダクトであったり、より難度の高いタスクを処理できるモデルの機能であったり、あるいは重複した車輪の再発明を減らす共通エンジニアリング資産であったりする。

それゆえ、かつて数か月を費やして構築したユースケースをCodexが肩代わりできるようになったとしても、チームは自らの存在価値を証明するために過去の実装にしがみつく必要はない。すでに検証された成果を資産として引き継ぎ、汎用プロダクトが担える部分はプロダクトへと委ね、自らは次のより困難な未知の課題へと挑み続けるのだ。

関連記事・動画：OpenAI FDEチーム公式インタビュー（録画配信）。チームの日常業務、顧客フィードバックが製品開発に与える影響、求められる人物像などが語られている。※公式ページの閲覧にはログインが必要です。