顧客とAIを業務に生かすチーム「FDE」、OpenAIが役割を紹介
OpenAIは2026年10月22日、顧客企業と協働してAIを業務に生かすチーム「FDE（Forward Deployed Engineering）」の役割を紹介する記事を公開しました。筆者はFDE責任者のColin Jarvis氏です。半導体や通信、税務の事例を交え、AIの性能と業務活用の差を埋める方法を解説しています。
ARCHETYP Staffingでは現在クリエイターを募集しています。
エンジニア、デザイナー、ディレクター以外に、生成AI人材など幅広い職種を募集していますのでぜひチェックしてみてください！
AIの性能と業務活用の差を埋めるFDEの役割
Colin Jarvis氏は2025年初めにFDEチームを立ち上げました。目的は、Jarvis氏が「デプロイメント・ギャップ」と呼ぶ問題の解消です。デプロイメント・ギャップとは、AIモデルが持っているように見える能力と、人々が実際の業務で確実に使えるものとの距離を指します。Jarvis氏によると、モデルの能力は、AIを使うためのシステムや業務プロセスの整備よりも速く進歩してきました。足りないのが製品である場合もあれば、ベンチマーク（性能を比較するための標準テスト）では高い成績を出すモデルが、現実の条件や制約の下では業務をこなせない場合もあるといいます。
FDEは、顧客企業が抱える最も難しい課題に取り組みます。現在のモデルで対応できる課題であれば、OpenAIのプロダクト部門や顧客と協力して、解決策を繰り返し使える形に整えます。
モデルの能力が足りない場合は、顧客やOpenAIの研究部門と一緒に不足している点を明確にし、改善につなげます。Jarvis氏は、1件ごとの取り組みで次の顧客の出発点を引き上げることを目標に掲げています。同じ種類の課題を次回はFDEなしで解決できる水準まで底上げできれば、FDEとして役割を果たしたことになると述べています。
FDEが取り組む課題の例として紹介されたのが、長い歴史を持つ農業関連企業John Deereです。John Deereの精密除草技術「See & Spray」は、カメラと機械学習で雑草を識別して散布し、畑全体に散布する場合と比べて化学薬品の使用量を最大70%削減します。ただし、効果を得るには、農家が機器の設定方法やシーズンの計画、状況に応じた作業の調整方法を理解している必要があります。John DeereはOpenAIのAPIを導入し、農家への個別のサポートを規模を広げて提供できるようにしました。AIは農家の質問に自然な言葉で答えるほか、設定の手引きや提案を農家ごとに示し、機器が本来の性能を発揮できていない可能性がある場面を特定します。
半導体企業の検証業務をAIで効率化し、Codexで横展開
Jarvis氏はFDEチームの会議の冒頭で毎回、「成果から始め、成功に必要なことをやり遂げ、その後で規模を広げる」という価値観を示しているといいます。デモの見栄えではなく、本番で通用する水準での課題解決をFDEの仕事としています。
具体例が大手半導体企業との取り組みです。2025年半ば、約15人のFDEが10件以上のユースケースに取り組みました。目標はチップの検証工程をAI前提の仕組みにすることで、対象には指向性テスト（特定の動作を確かめるために設計したテスト）の生成、根本原因の分析とデバッグ、アーキテクチャ設計を支援するアシスタントなどが含まれます。半導体業界では、検証がプロジェクトの作業量の約70%を占めることもあります。
FDEには入社して数日で、半導体の経験がないメンバーもいました。メンバーは顧客の検証チームに加わってチップ設計を学び、AIが有用なテストを生成できるか、チップの不具合を正しく診断できるかを確かめる評価テストを顧客のエンジニアと作りました。ユースケースごとに専用の実行基盤も構築し、最初の3〜6カ月ですべてのユースケースが本番稼働と初期の利用開始に至りました。成果として、AIによる指向性テストの生成で約48%の時間削減、カーネル最適化で性能の中央値22%向上、数週間かかっていたデバッグの数時間への短縮が報告されています。
一方、各ユースケースは個別の連携開発が多く、ほかのチームへの展開が困難でした。そこで、能力が向上したOpenAIのCodexを中核とする共通の実行基盤に各ユースケースを移行しました。個別のアプリケーションはCodexの基本機能の上に作るプラグインやスキルに置き換わり、ユースケースごとに作っていた操作画面も廃止しました。移行により、各プロジェクトの独自コードを約90%削減できたといいます。別のチームへの展開は、コネクターやMCPサーバー（AIと外部ツールをつなぐ仕組み）を入れ替え、新しい評価テストを作るだけで済む場合もあります。2026年8月のある例では、最初の導入に2カ月かかった一方、2つ目のチームへの展開は1日で完了しました。
現場での取り組みを製品とモデルの改善につなげる
FDEの経験は、OpenAIの製品にも反映されています。企業向けの音声・チャットエージェント製品「OpenAI Presence」は、実際の顧客への導入から生まれました。取り組みはSwarmから始まり、Agents APIを経て発展し、現在はある顧客が電話対応の半数以上をAIで処理しています。他チームでも使える構成要素をPresenceに組み込んだことで、開発者は基盤を作り直さずに、規制のある業務を自動化しやすくなったといいます。
Thrive Holdingsとの取り組みでは、FDEと研究者がエンジニアや会計士と協力し、Creteの会計事務所向けに「Tax AI」を開発しました。試験導入では7,000件の税務申告を処理し、処理量が約50%増えました。特に難しかった賃貸不動産の申告の自動化では、6週間の開発と実務家によるレビューを経て、適合率と再現率が90%に達しました。
モデル自体の能力が足りなかった例も紹介されています。大手通信企業では顧客対応の約90%を音声が占めており、FDEと構築済みの顧客サービス基盤を音声にも広げたいと考えていました。しかし、検討段階でのモデルの評価テストのスコアは約60%で、顧客サービスの場面での関数呼び出し（外部の機能を呼び出す仕組み）と指示への追従に改善が必要でした。FDEは顧客と基盤を構築してモデルに求める要件を定め、OpenAIの研究部門はモデルの能力向上に取り組みました。6カ月でスコアは約60%から80%、さらに90%以上へと上がり、本番運用に必要な水準に達しました。完成した音声モデルは、通信企業の導入に加え、ほかの顧客サービスの導入や、Presenceを通じた管理型の導入にも使われています。
まとめ
いかがだったでしょうか？
OpenAIのFDEは、顧客の難しい課題に取り組み、得た知見を製品やモデルの改善に生かすことで、次の顧客がより少ない個別開発でAIを導入できる状態を目指しています。Jarvis氏は、大規模言語モデルの開発では多くの場合、最も単純な解決策が最善だと述べ、現場の人が頼れる確実に動くものを作りたいとしています。
AIの能力が足りない業務でも、提供元と要件を共有して改善に取り組む進め方は、AIの導入を検討する企業にとって参考になりそうです。