Codexが登場したとき、チームの誰かが私にこう尋ねました。「この数ヶ月かけて構築してきたユースケースを、Codexが一発で解けるようになったら、私たちは何をすればいいのか?」
この問いは、OpenAIにおけるFDEの意味の核心を突いています。私たちは顧客とともに働き、彼らの最も難しい問題を理解し、頼りになるソリューションを構築します。そこで得た学びは、私たちの製品の形作りに役立ち、Researchに対して具体的な解決すべき問題を提供します。
それこそが進歩です。私たちが数ヶ月ごとに自らの時代遅れを実現できているなら、FDEチームはその役割を果たしているのです。
私は2025年初頭に、「展開のギャップ」と私たちが呼ぶものを埋めるためにこのチームを設立しました。それは 「展開のギャップ」: モデルが実際にできるように見えることと、人々が自分の仕事に確実に使えることとの間の距離です。
モデルの能力は、それを活用するために必要なシステムやプロセスよりも速く進化してきました。欠けている部分が製品であることもあれば、モデルがベンチマークでは良い成績を収めても、現実の変数や制約がある中では仕事を遂行できないこともあります。
私たちは顧客の最も難しい問題に焦点を当てます。今日のモデルで仕事が遂行できる場合は、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サーバーを組み込み、新しい評価(evals)を作成すること(これにも専用のスキルがありました)、そして稼働を開始するだけで、非常にシンプルに行えるものでした。
2026年8月の一例では、初期展開に2か月を要しました。そのソリューションを2番目のチームに拡張するには1日しかかかりませんでした。規模を拡大するにつれて、以降のチームのオンボーディングはさらに速くなりました。これは現在も続いており、2026年8月のユースケースでは、初期展開に2か月かかった後、2番目のチームには1日しかかかりませんでした。
それは、私たち自身を時代遅れにする一つの形でした。本番環境に到達するまでに行った作業は、何が重要であるかを明確にしました。基盤となる製品が向上するにつれ、私たちはカスタム実装の多くを置き換えながら、それがもたらしていた価値を保ち続けることができました。
こうして順番が重要になるのです。LLMによって高速に構築できるようになりました。そのスピードを活かして価値あるものをユーザーの手に届け、実践で何が機能するかを学び、そしてうまくいったものをスケールさせてください。
同じ原則がすべての案件に当てはまります。
OpenAI Presence、企業向け音声・チャットエージェント製品である当社製品は、実際の顧客導入事例から生まれました。この取り組みは、次のことから始まりました。 Swarm（新しいウィンドウで開きます） そして「the」を経て進化した Agents APIそして現在、ある顧客はそのコールの半分以上をAIで処理しています。
これらのデプロイを本番環境に投入する過程で、どの問題に独自のソリューションが必要で、どの構成要素を他のチームも利用できるかが見えてきました。私たちはそうした構成要素をPresenceに取り込み、開発者が基盤となるインフラを一から作り直すことなく、規制対応のワークフローを自動化しやすくしました。各デプロイは製品の形成に役立ち、次の顧客により良い出発点を提供しました。
With 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がこなせるようになったら、何をすればいいのでしょうか?
より難しい問題を探しに行くのです。