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