OpenAIにおけるFDEの意味：フォワードデプロイドエンジニアリングとデプロイメントギャップ

OpenAIのフォワードデプロイドエンジニアリング（FDE）チームは、「デプロイメントギャップ」—モデルが可能に見えることと、人々が仕事で確実に利用できることの間の距離—を埋めるために存在し、チームは製品とモデルが改善されるにつれて自分たちが不要になることを成功の尺度としています。2026年10月22日に公開された一人称の投稿で、チームの創設者は、John Deere、大手半導体メーカー、通信会社、Thrive Holdingsなどの顧客とのFDEエンゲージメントが、困難で未解決の問題を本番システム、再利用可能なCodexベースのパッケージ、そしてOpenAIリサーチが次に取り組む具体的な能力ギャップに変える方法を説明しています。

OpenAIにおけるFDEの意味（1段落で）

OpenAIのフォワードデプロイドエンジニアリングは、顧客と協力して彼らの最も困難な問題を理解し、本番環境で依存できるソリューションを構築する機能です。チームは2025年初頭にデプロイメントギャップを埋めるために設立されました。モデルの能力は、それらを実用化するために必要なシステムとプロセスよりも速く進化しています。時には欠けているのは製品であり、時にはモデルがベンチマークで良い成績を収めても、実際の変数と制約がある仕事をこなせないことがあります。FDEが学んだことはOpenAIの製品にフィードバックされ、リサーチに具体的な問題を提供します。

チームの表明された目標は、各エンゲージメントが次の顧客により良い出発点を残すことです。投稿が述べるように：「次の時に顧客がこの種の問題を解決するためにFDEを必要としないレベルまで床を引き上げたら、私たちは仕事をうまくやったことになります。」

OpenAIがFDEの仕事が時代遅れになるべきだと述べる理由

投稿は、Codexがリリースされたときに同僚が尋ねた質問で始まります：「Codexが私たちがここ数ヶ月かけて構築してきたユースケースをワンショットで処理できるようになったら、私たちは何をするのか？」著者の答えは、これは脅威ではなく進歩だということです。

数ヶ月ごとに自分たちを時代遅れにできれば、FDEチームはその役割を果たしています。

投稿は、チームが自分たちを時代遅れにする2つの異なる方法を特定しています。1つ目は、より良い製品がOpenAIにカスタム実装を置き換え、提供された価値を維持できるようにする場合です。2つ目は、FDEが今日のモデルが解決できない問題を、将来のモデルが提供できる能力に変えるのを支援する場合です。

運営原則：結果から始める

すべてのFDEチームセッションは、1つのコアバリューを持つスライドで始まります：「結果から始め、成功するために必要なことを行い、その後スケールに従う。」その根拠は、印象的なデモが、それが現実世界で機能するかどうかを誰も尋ねる前に長く進むことができ、チームの仕事は顧客の問題を本番環境で自信を持って支持できる基準に解決することです。

投稿はこれがなぜ難しいかについて率直です：問題はしばしば広く開かれており、確立されたグラウンドトゥルースがない場合があり、プレイブックもありません。「誰もがこれまで存在しなかったものを構築したいと思っています。そこに到達するために必要なことをしたいと思う人は少ないです。」

ケーススタディ：約15人のFDEと10以上のユースケースでの半導体検証

2025年半ば、約15人のOpenAI FDEが大手半導体顧客と10以上のユースケースで協力し、顧客の検証プロセスをAIネイティブにすることを目指しました。検証はその業界のプロジェクトの労力の約70%を占めることがあります。作業は3つの領域をカバーしました：

指示付きテスト生成
根本原因分析とデバッグ
アーキテクチャアシスタント

一部のFDEは数日前にOpenAIに参加したばかりで、半導体で働いた経験はありませんでした。彼らは顧客の検証チームに組み込まれ、余暇にチップ設計を学び、顧客のエンジニアと一緒に、AIが有用なテストを生成し、チップ障害を正しく診断できるかどうかをテストするための評価を構築しました。その学習と並行して、OpenAIは個々のユースケース用のカスタムハーネスを構築しました。最初の3〜6ヶ月で、それらすべてが本番稼働と初期ユーザー採用に達しました。

報告された結果は次のとおりです：

AIベースの指示付きテスト生成による約48%の時間節約
カーネル最適化による22%の中央値パフォーマンス向上
数週間のデバッグが数時間に短縮

結果が再生されたとき、顧客のチーフハードウェアオフィサーが尋ねました：「あなたたちはここに来る前にチップ設計者として働いていましたか？」投稿の結論：「私たちのFDEは初日に業界を知っている必要はありませんが、それを学ぶのは彼らの責任です。」

ドメイン専門知識は採用要件として扱われ、あれば良いものではない

投稿は、コーディングアシスタントがソフトウェアをより速く構築できるようにするにつれて、顧客のビジネスを理解することがさらに重要になると主張しています。OpenAIは、ゼネラリストとドメイン専門家の混合でFDEチームを構築します。その理由は、健全な判断を下すのに十分な知識と、現状の前提に疑問を投げかけるのに十分な好奇心が必要だからです。

例えば、ライフサイエンスでは、FDEの科学的背景は、ターゲット検証と優先順位付け、遺伝子発現分析、化学合成経路再構築などの前臨床薬物発見タスクに取り組む研究者との信頼を得るのに役立ちます。その専門知識により、これらのワークフローがどのように改善されるかについて情報に基づいた判断を提供できます。

FDEがCodex、スキル、MCPで成功を再現可能にした方法

半導体ワークフローが価値を提供した後も、それぞれが別のチームに拡張するにはカスタム統合が多すぎました。次の課題は、ソフトウェアを展開および保守しやすくしながら結果を維持することでした。

その時点でCodexの能力は向上していました。あるFDEは、それを中心にアプリケーションを再構築することをテストし、その後チームと協力してユースケースをCodexをコアとする共通ハーネスに移行しました。カスタムアプリケーションは、共通のCodexプリミティブ上に構築されたプラグインとスキルになりました。Codexはまたインターフェースとなり、OpenAIは個々のユースケース用に書いた別々のターミナルUIとCLIを廃止できました。

チームは各プロジェクトからカスタムコードの約90%を削除できました。投稿によると、これによりワークフローの構築、保守、スケーリングの方法が3つの方法で変わりました：

Codexへの集中改善により、個々のユースケースに必要なグルーコードの量が削減されました。
主要な機能はスキルとプラグインとしてバンドルされ、共有が容易になり、顧客のAI CoEによって中央管理されました。あるチームから次のチームへの拡張は、新しいコネクタやMCPサーバーを交換し、新しい評価を構築し（チームにはそのためのスキルもありました）、そして稼働させるだけで簡単になりました。
オンボーディングは大幅に加速しました。2026年8月の例では、初期展開に2ヶ月かかりましたが、ソリューションを2番目のチームに拡張するのにかかったのは1日でした。

投稿はこの背後にある順序付けの原則を要約しています：「LLMは私たちを速く構築させます。その速度を使って価値あるものをユーザーの手に届け、実際に何が持続するかを学び、そして機能するものをスケールさせてください。」

OpenAI Presenceは顧客展開から生まれました

OpenAI Presenceは、企業向け音声およびチャットエージェントのための同社の製品であり、実際の顧客展開から生まれました。作業はSwarmから始まり、Agents APIを通じて進化しました。今日、ある顧客は電話の半分以上をAIで処理しています。

これらの展開を本番環境に持ち込むことで、OpenAIはどの問題がカスタムソリューションを必要とし、どのビルディングブロックを他のチームが使用できるかを学びました。これらのビルディングブロックはPresenceに取り込まれ、開発者が基盤インフラを再構築せずに規制されたワークフローを自動化しやすくなりました。

ケーススタディ：Thrive HoldingsのTax AIがパイロットで7,000件の申告を処理

Thrive Holdingsでは、OpenAI FDEと研究者がエンジニアや会計士と協力して、クレタ島の会計事務所向けにTax AIを構築しました。パイロット中、Tax AIは7,000件の税務申告を処理し、スループットを約50%向上させました。

最も困難な課題の1つは、賃貸物件の申告を自動化することであり、90%の精度と再現率に達するために6週間のエンジニアリングと実務家のレビューが必要でした。その作業は再利用可能なパターンを生み出し、Tax AIを他の複雑な税務スケジュールに拡張しやすくしました。チームは現在、同じアプローチを簿記、監査、ITサポートに適用しており、実務家のフィードバックと実際の使用を通じて改善されるシステムを構築しています。

ケーススタディ：音声モデルのインテリジェンスギャップを約60%から90%以上に閉じる

時にはより良い製品がFDEが構築したものを簡素化できることがあります。時にはモデル自体がまだ仕事をこなせないことがあります。投稿は、OpenAIが今日のモデルがすでに可能にすることだけを構築した場合、リサーチが次に閉じる必要があるインテリジェンスギャップを発見できないと主張しています。したがって、多くの重要なエンゲージメントはその限界から始まり、顧客、FDE、リサーチが一緒にそれらを乗り越えることにコミットします。

大手通信顧客はすでにOpenAIとカスタマーサービスプラットフォームを開発しており、それを音声に拡張したいと考えていました。音声はその顧客のカスタマーサービスのボリュームの約90%を占め、これらのケースはチャットよりも封じ込めにコストがかかり、アクセント、トーン、レイテンシー/精度を本番グレードに引き上げるという新しい技術的課題をもたらしました。

スコーピング中、モデルは本番で仕事をこなせるかどうかを評価するための主要な評価で約60%のスコアでした—その能力の限界です。カスタマーサービスシナリオでの関数呼び出しと指示追従を改善する必要がありました。OpenAIはこれを顧客に説明し、リサーチを作業に参加させました：FDEは顧客とプラットフォームを構築し、モデルが何をする必要があるかを定義し、リサーチは能力ギャップを閉じることに取り組み、連続するモデルスナップショットによりチームは顧客の要件に対して進捗をテストできました。

6ヶ月にわたって、主要な評価でのパフォーマンスは約60%から80%、そして90%以上に上昇し、本番に必要なレベルに達しました。投稿はまた、Audio Big Benchの精度が5つのモデルスナップショットにわたって、2024年12月の65.6%から2026年5月の92.29%に上昇したことを引用しています。

結果として得られた音声モデルは現在、その顧客の展開、他のカスタムカスタマーサービス展開、およびPresenceを通じたマネージド展開をサポートしています。ある顧客のビジネスで遭遇した問題は、他の多くの顧客に役立つ改善を特定するのに役立ちました。

FDEモデルがAIの展開方法に意味すること

投稿は、困難な展開のための明確な分業を描いています：顧客はモデルがまだ解決できない問題に取り組むことを約束し、FDEはその問題を枠組みし、プラットフォームを構築し、エンゲージメントを最初から最後まで推進するのに十分近くに留まり、リサーチは基盤となるモデル能力を改善します。その作業のリターンは、特定の顧客と過ごした時間を超えて広がります。

著者の表明されたエンジニアリングバイアスはシンプルさに向かっています：「LLM開発のほとんどの場合、オッカムの剃刀が適用されます—最も単純な解決策が最良です。」最先端の研究と「誇張に汚染された」業界によって定義される会社で、表明された目的は、確実に機能し、現場の人々が依存できるものを構築することです。

各エンゲージメントの目標は、次に来るものを改善することです—展開しやすい製品、より難しいタスクを処理できるモデル、または次の顧客のためのカスタム作業の削減。そして、投稿を開いた質問への答えは投稿の最後の行です：Codexがチームが何ヶ月もかけて構築した作業を処理できるようになったら、「もっと難しい問題を見つけに行け。」