OpenAIのフォワード・デプロイド・エンジニアリング（Forward Deployed Engineering、以下FDE）責任者のColin Jarvis氏は2026年10月22日、FDEチームがOpenAIで何をしているのか、どのように働いているのか、そして企業が抱える最も難しい問題をどのように解決し、実際のインパクトを届けているのかを体系的に説明する記事を公開した。記事の出発点はチーム内のある問いだった。Codexが登場したとき、チームの誰かがこう尋ねた。「Codexが、私たちがここ数か月かけて構築してきたユースケースを一発でこなせるようになったら、私たちは何をするのか」。Jarvis氏は、この問いこそがOpenAIにおけるFDEの本質を突いていると述べる。チームは顧客と並走して最も困難な問題を理解し、顧客が依存できるソリューションを構築する。そこで学んだことは製品の形を左右し、リサーチ部門には解くべき具体的な問題を提供する。そして「数か月ごとに自分たちを不要な存在にできるなら、それは進歩であり、FDEチームが仕事を果たしている証拠だ」と強調する。
Jarvis氏は2025年初頭にこのチームを立ち上げた。目的は「デプロイメント・ギャップ」、すなわちモデルが能力的にできそうに見えることと、人々が実際の業務で確実に使えることとの間の距離を埋めることだった。モデルの能力は、それを活用するために必要なシステムやプロセスよりも速く進化してきた。欠けているものが製品であることもあれば、モデルがベンチマークでは良い成績を出すのに、現実の変数や制約の下では仕事をこなせないこともある。チームは顧客の最も難しい問題に焦点を当てる。モデルが今日その仕事をこなせる領域では、プロダクトと顧客と協力してソリューションを再現可能にする。モデルが及ばない領域では、顧客とリサーチと協力してギャップを定義し、改善を進める。目標は、各エンゲージメントが次の顧客により良い出発点を残すことだ。もし床を引き上げ、次回には顧客がこの種の問題を解くのにFDEを必要としないところまで来られれば、チームは仕事をうまくやったことになる。
記事ではJohn Deereの事例が挙げられている。200年の歴史を持つ農業企業である同社の課題は、農家向けのパーソナライズされた助言をどのようにスケールさせるかだった。同社の精密除草技術「See & Spray」はカメラと機械学習を使い、畑全体を処理するのではなく雑草を識別して点噴射することで、薬剤使用量を最大70%削減する。しかしその効果を実現するには、農家が技術を設定し、作付け計画を立て、状況の変化に応じて手法を調整する方法を知っている必要がある。John DeereはOpenAIのAPIを導入し、このサポートをパーソナライズかつスケーラブルにした。AIは農家の質問に自然言語で答え、個別の設定ガイダンスや推奨事項を提供し、機器が本来の性能を発揮できていない可能性を特定し、農家が技術から得ている価値を理解できるように支援する。機会は単一のやり取りにとどまらず、カスタマージャーニー全体にわたって関連するガイダンスを提供し、農家が機器をより有効に活用できるようにしつつ、効率と持続可能性を高めることにある。Jarvis氏は、これこそがOpenAIのFDEが取り組む課題の種類だと述べる。つまり、組織がAIの能力から、複雑な現実環境で実用的な価値を届けるシステムへと移行できるよう支援することだ。しかし問題はしばしば広く開かれており、確立されたグラウンドトゥルースもプレイブックも存在しない。誰もが前例のないものを作りたがるが、そこに到達するために必要なことをやろうとする人は少ない。優秀なFDEを見つけながら「十分に良い」の基準を引き上げるには、絶え間ない実験と実践が必要だった。
Jarvis氏は毎回のFDEチームセッションの冒頭に、1つのコアバリューを書いたスライドを映す。「成果から始め、成功するために必要なことを行い、その後スケールを考える」。印象的なデモは、それが現実世界で機能するかどうかを誰かが問うまで大きな効果を発揮し得るが、チームの仕事は顧客の問題を、本番環境で自信を持って保証できる水準まで解くことだ。
半導体業界の例として、2025年半ば、約15名のFDEが大手半導体顧客と10以上のユースケースに取り組んだ。狙いは同社の検証プロセスをAIネイティブにすることで、対象はディレクテッドテスト生成、根本原因分析とデバッグ、アーキテクチャアシスタントに及んだ。この業界では検証がプロジェクト工数の約70%を占めることがあり、機会は計り知れず、始めるべき場所も多くあった。FDEの一部は数日前にOpenAIに入社したばかりで、半導体の経験はなかった。彼らは顧客の検証チームに入り込み、余暇にチップ設計を学び、エンジニアとともに、AIが有用なテストを生成し、チップの故障を正確に診断できるかを評価するevalsを構築した。そうした学習と並行して、個々のユースケース向けのカスタムハーネスを構築した。最初の3〜6か月で、そのすべてが本番環境に到達し、初期のユーザー採用を得た。成果はメトリクスに表れた。AIベースのディレクテッドテスト生成により約48%の時間を削減。カーネル最適化により性能中央値が22%改善。数週間かかっていたデバッグが数時間に短縮された。これらを振り返ったとき、ハードウェア担当の最高責任者は「あなたたちは来る前からチップ設計者だったのか」と尋ねた。Jarvis氏の答えは明確だ。FDEは初日から業界を知っている必要はないが、業界を学ぶのは彼らの責任である、と。
コーディングアシスタントによってソフトウェア構築が速くなるにつれ、顧客のビジネスを理解することはさらに重要になる。チームはジェネラリストとドメイン専門家を混ぜて構成される。健全な判断を下すのに十分な知識と、現状についての前提を疑うのに十分な好奇心が必要だ。例えばライフサイエンス領域では、FDEの科学的バックグラウンドが、標的検証や優先順位付け、遺伝子発現解析、化学合成経路の再構築といった前臨床の創薬タスクに取り組む研究者との信頼獲得に役立つ。その専門性によって、こうしたワークフローをどう改善できるかについて根拠ある判断を下せる。これらのワークフローが価値を生み出せることはすでに示されていたが、別のチームへ展開するには、それぞれのカスタム統合が依然として多すぎた。次の課題は、その成果を保ちながら、ソフトウェアをより導入・保守しやすくすることだった。
その頃、Codexの能力は高まっていた。あるFDEがCodexを中心に自身のアプリケーションを再構築することを試し、その後チームと協力してユースケースをCodexを中核とする共通ハーネスへ移行した。カスタムアプリケーションはCodexの共通プリミティブ上に構築されたプラグインとスキルになった。Codexがインターフェースにもなり、ユースケースごとに書いていた個別のターミナルUIやCLIを廃止できた。各プロジェクトからカスタムコードの約90%を削除でき、ワークフローの構築・保守・スケールの方法が変わった。Codexへの集中的な改善の恩恵を受けられ、ユースケースごとに必要なグルーコードを減らせる。主要な機能はスキルやプラグインとしてまとめられ、相互に共有しやすく、AI CoEによる一元管理も容易になった。これにより、あるチームから次のチームへの展開は、新しいコネクタやMCPサーバーを差し替え、新しいevalsを構築し（これにもスキルを用意した）、稼働させるだけで済むようになった。2026年8月の例では、最初のデプロイに2か月かかったが、2番目のチームへの展開は1日で完了した。以降もチームのオンボーディングは規模拡大とともに加速し、この傾向は続いている。Jarvis氏はこれを「自分たちを不要にする」一つの形だと述べる。本番到達のために行った作業が重要な点を確立し、基盤となる製品が改善されるにつれて、カスタム実装の多くを置き換えつつ、そこから得られた価値を保つことができる。
だからこそ順序が重要になる。LLMによって速く構築できる。その速度を生かして価値あるものをユーザーの手に届け、実践で何が通用するかを学び、うまく機能するものをスケールさせる。この原則はすべてのエンゲージメントに当てはまる。例えば、企業向けの音声・チャットエージェント製品であるOpenAI Presenceは、実際の顧客デプロイから生まれた。取り組みはSwarmから始まり、Agents APIへと進化し、現在ではある顧客の通話の半分以上をAIが処理している。これらのデプロイを本番に乗せることで、どの問題にカスタムソリューションが必要で、どのビルディングブロックが他のチームに使えるかを学んだ。それらをPresenceに取り込み、開発者が基盤インフラを再構築せずに規制対象のワークフローを自動化できるようにした。各デプロイが製品の形を定め、次の顧客により良い出発点を提供した。
Thrive Holdingsでは、OpenAIのFDEと研究者がエンジニアや会計士と並んで、クレタ島の会計事務所向けにTax AIを構築した。パイロット期間中、Tax AIは7,000件の確定申告を処理し、スループットを約50%向上させた。最も難しい課題の一つは賃貸不動産の申告の自動化で、90%の適合率と再現率に到達するまでに6週間のエンジニアリングと実務者によるレビューを要した。この作業から再利用可能なパターンが生まれ、Tax AIを他の複雑な税務スケジュールへ拡張しやすくなった。チームは現在、同じアプローチを簿記、監査、ITサポートに適用しており、実務者のフィードバックと実際の利用を通じて改善されるシステムを構築している。
より良い製品によって構築したものを簡素化できることもあれば、モデル自体がまだその仕事をこなせないこともある。Jarvis氏は、今日のモデルがすでに可能にしているものだけを構築していては、リサーチが次に埋めるべき知能のギャップを見つけられないと強調する。そのため、重要なエンゲージメントの多くはそうした限界点から始まり、顧客、FDE、リサーチが協力して乗り越えることを約束する。チームはすでに大手通信顧客とカスタマーサービスプラットフォームを開発しており、顧客はそれを音声に拡張したいと考えていた。音声は同社のカスタマーサービス量の約90%を占めていた。これらのケースはチャットよりも対応コストが高く、アクセント、トーン、レイテンシと精度を本番水準に引き上げるという新たな技術的課題をもたらした。これを正しく実現できれば、同社のビジネスに大きな違いをもたらす。スコーピングの段階で、モデルは本番環境でその仕事をこなせるかを評価する主要なevalsで約60%のスコアだった。モデルの能力の限界に達しており、カスタマーサービスシナリオでの関数呼び出しと指示追従の改善が必要だった。チームは顧客にそれを説明し、リサーチを関与させた。FDEは顧客とともにプラットフォームを構築し、モデルが何をすべきかを定義した。リサーチは能力のギャップを埋める作業を進め、 successive model snapshotsによって顧客の要件に対する進捗をテストできた。6か月間で、主要なevalsの性能は約60%から80%、そして90%以上へと上昇し、本番に必要な水準に達した。その結果生まれた音声モデルは、この顧客のデプロイ、他のカスタムカスタマーサービスデプロイ、そしてPresenceを通じたマネージドデプロイを支えている。ある顧客のビジネスで遭遇した問題が、他の多くの顧客に役立つ改善の特定につながった。それぞれの部分が重要だった。顧客はモデルがまだ解けない問題に取り組むことを約束し、FDEはその問題を定義し、プラットフォームを構築し、エンゲージメントを最初から最後まで推進できるよう十分に近くにいた。リサーチは基盤モデルの能力を向上させた。これは「自分たちを不要にする」もう一つの形だ。今日のモデルが解けない問題を、将来のモデルが提供できる能力へと変える手助けである。この仕事のリターンは、特定の顧客に費やす時間を超えて広がる。
Jarvis氏は、人々の日常業務でAIを役立つものにするためにOpenAIに加わったと述べ、それが今もチームを導いているという。LLM開発のほとんどの場合、オッカムの剃刀が当てはまり、最も単純な解決策が最善だとチームによく言う。最先端の研究で定義される企業で、誇張にまみれた業界において、現場で信頼できる確実に動作するものを作りたいと考えている。目標は、各エンゲージメントが次のものを改善することだ。導入しやすい製品、より難しいタスクを扱えるモデル、あるいは次の顧客にとってのカスタム作業の削減。記事の最後で同氏は、解決したい難しい問題があればOpenAIは喜んで協力したい、こうした問題の解決を手伝いたいならぜひ参加してほしい、と述べている。