Michael Johnson10月22日、OpenAIはFDEの業務内容を公開した。FDE（forward-deployed engineering）チームは、企業顧客と協力し、AIを具体的な業務プロセスに適応させる。部門責任者のコリン・ジャービスは、エンジニアが顧客の業務を調査し、品質基準をすり合わせ、個別の解決策を再利用可能なコンポーネントへと変える方法を説明している。
同社は、テスト用のプロンプトに対するモデルの結果と、実環境でタスクを安定して実行できるシステムとの隔たりをこう説明している。ボトルネックが製品や統合にある場合、チームは顧客とともに解決策を改善する。モデルがタスクの要件を満たせない場合は、OpenAIの研究者が加わる。
顧客の課題から測定可能な成果へ
2025年半ばの事例では、約15人のOpenAIエンジニアが大手半導体メーカーと協力し、指向性テストの生成、不具合原因の特定、設計支援など、10を超える用途に取り組んだ。OpenAIによると、最初の3〜6カ月でそれらの用途は本番環境に導入され、初期利用が始まった。同社は、テスト生成にかかる時間が約48%短縮され、デバッグ期間が数週間から数時間に減ったと報告している。
これらの数値は、OpenAIが説明した特定の顧客の業務プロセスに関するものだ。導入で重要なのは、その手法にある。実務担当者と成功基準を事前に合意し、実際の事例を集め、人による確認も含む業務プロセス全体の成果を測定する。
個別の統合から再利用へ
メーカー向けの初期ソリューションには、多くの個別コードが必要だった。OpenAIによると、Codexを中心にアプリケーションを再構築する際、個別のインターフェースを共通ツール、プラグイン、スキルに置き換えた。同社は、説明した各プロジェクトでカスタムコードを約90%削減したとしている。2026年8月の事例では、最初の導入に2カ月かかった一方、2つ目のチームの導入は1日で完了した。
自社の試験導入では、初回導入と次の部門への展開にかかる作業量を分けて計測するとよい。コネクター、手順、品質チェックを再利用できれば、解決策の展開に必要な個別開発を減らせる可能性がある。OpenAIが示した期間は同社の特定事例であり、あらゆるプロジェクトで同じペースが保証されるわけではない。
顧客の試験導入から税務製品へ
OpenAIが挙げる別の事例は、Thrive Holdingsと共同で会計事務所Crete向けに開発したTax AIだ。同社の発表によると、試験導入中にシステムは7,000件の税務申告書を処理し、処理能力は約50%向上した。難しい用途の一つである賃貸不動産の申告書では、90%の精度と網羅率を達成するため、6週間のエンジニアリング作業と専門家による確認が必要だった。
OpenAIによると、そこで得られたテンプレートは、その後、Tax AIを他の複雑な税務明細へ拡張する際にも役立った。この種の試験導入を実務的に評価するには、正しい結果の割合だけでなく、人手による確認の量、処理速度、次の書類タイプへ解決策を移すのに必要な作業も考慮すべきだ。
統合を変えるべきか、モデルを変えるべきか
大手通信事業者との別のプロジェクトでは、チームが音声サポートを開発した。OpenAIによると、本番導入への適性を評価する主要な社内テストで、当初のシステムのスコアは約60%だった。6カ月後には80%に上がり、導入エンジニア、顧客、研究チームの共同作業を経て、さらに90%を超えた。OpenAIは、顧客対応のシナリオにおける音声認識、指示への追従、関数呼び出しのテストが改善につながったとしている。
このプロセスにより、必要な作業が統合やインターフェースにあるのか、それともモデルが指定された機能を実行する能力にあるのかを特定しやすくなる。OpenAIが説明しているのは同社の社内評価と顧客プロジェクトであり、これらの結果は導入の進め方を示すもので、他の顧客に対する普遍的な予測ではない。
自社の試験導入で確認すること
導入を拡大する前に、現行の作業方法、人手による確認の量、受け入れ基準を記録しておく。まれなエラーを含む実際の事例でシステムを検証し、結果が承認されるまでの時間、修正率、統合の保守コストを測定する。別のチームへ展開する際には同じ指標を比較し、データソースの接続やアクセス権限の設定にかかる作業も個別に算出する。
OpenAIの説明から得られる実務的な指針は、測定可能な課題から始め、実際の業務環境で解決策を検証し、次の導入が前回の成果を活用できるようコンポーネントを構築することだ。個別の試験導入を再現可能な展開へつなぐのは、まさにこの考え方である。