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