10月22日、OpenAIが「What FDE means at OpenAI」と題した記事を公開した。2025年初頭に設立した「FDE（Forward Deployed Engineering）」チームの役割・思想・実績について詳しく紹介しており、AIモデルの性能を実業務に着地させる新たな職種像を提示している。

「デプロイメントギャップ」とは何か

モデルのベンチマーク性能が高くても、実業務の変数や制約のある環境では機能しないケースは珍しくない。OpenAIはこの乖離を「deployment gap（デプロイメントギャップ）」と呼ぶ。FDEチームはこのギャップ——「モデルが実際にできることと、人々が仕事で使えることの間にある溝」——を埋めるために設立された。

記事を書いたのはFDEチームの創設者で、冒頭でこんな問いを紹介している。

「Codexが数ヶ月かけて構築してきたユースケースを一発でこなせるようになったら、私たちは何をすればいいのか？」

その答えが記事のテーマでもある。「もっと難しい問題を探しに行け」——これがFDEチームの基本姿勢だ。

FDEという職種の背景——コンサルでもなく、従来のSEでもない

FDEという職種の概念は、ソフトウェア業界に前例がないわけではない。Palantirが同名の「Forward Deployed Engineer」を採用・定着させたことで知られており、顧客の現場に常駐しながら製品をカスタマイズ・運用する役割として業界に認知されてきた。

OpenAIのFDEもその系譜に連なるが、従来のプロフェッショナルサービスやシステムインテグレーター（SI）との違いは明確だ。SIやコンサルが要件定義・設計・実装を分業するのに対し、FDEはエンジニアリングの実務そのものを現場で担いながら、同時にビジネス課題の定義にも踏み込む。いわば「コンサルレベルの関与度を持つ実装エンジニア」として機能する。

LLMの登場により、プロトタイプの立ち上げ速度が飛躍的に上がった現在、こうした現場常駐型エンジニアの重要性は増している。モデルを「APIとして提供するだけ」では顧客の業務変革に結びつかないケースが多く、OpenAIはその壁をFDEによって乗り越えようとしている。

半導体顧客での実績：カスタムコードを90%削減

記事で最も強力な実績として紹介されているのが、大手半導体顧客との取り組みだ。

2025年半ば、約15名のFDEが10以上のユースケースに並行して取り組んだ。ターゲットは半導体の検証プロセスのAI化で、具体的には以下の3領域：

• 指向型テスト生成（Directed test generation）
• 根本原因分析とデバッグ
• アーキテクチャアシスタント

半導体業界では、検証工程がプロジェクト全体の工数の約70%を占める。FDEの多くは入社直後で半導体の知識ゼロだったが、顧客の検証チームに常駐し、自習でチップ設計を学びながらeval（評価セット：モデルの性能を実業務の基準で測るためのテストケース群）を構築した。最初の3〜6ヶ月で全ユースケースが本番稼働し、以下の成果を記録している：

• AIによるテスト生成で約48%の時間削減
• カーネル最適化による中央値22%のパフォーマンス改善
• 数週間かかっていたデバッグが数時間に短縮

その後、Codexの能力向上に合わせてアーキテクチャを刷新。個別ユースケース向けに書かれていたカスタムコードを約90%削減し、MCP（Model Context Protocol：モデルが外部ツールやリポジトリと連携するための標準プロトコル）を活用した共通基盤へ移行した。その結果、2026年8月の事例では、初期デプロイに2ヶ月かかったソリューションが、2チーム目への展開では1日で完了している。

行動原則：「成果から始めよ、スケールは後から」

FDEチームが全セッションの冒頭で掲げるスライドには、次の一文が書かれている。

「Start with the outcome, do what it takes to succeed, then follow with scale（成果から始めよ、成功のために何でもやれ、スケールは後から追え）」

LLMは開発を速くする。その速さを使って、まず価値あるものをユーザーの手に届け、実務で何が通用するかを学び、それをスケールさせる——という順序が重要だと記事は強調する。

モデルの限界に当たったとき：研究チームを巻き込む

大手通信会社との取り組みでは、モデルがそもそも仕事をこなせないという局面に直面した。

音声対応の顧客サービス基盤を構築しようとしたところ、本番稼働に必要な評価指標でのスコアが**約60%**に留まり、関数呼び出しや指示追従の性能が不十分だった。FDEはこの状況を顧客に正直に説明した上で、Researchチームを参加させ、モデル改善と並行してプラットフォームを構築した。

評価にはAudio Big Bench（音声モデルの推論・指示追従能力を測るベンチマーク群）が用いられ、6ヶ月間で評価スコアは60%→80%→90%以上へ改善し、本番稼働に到達した。このモデル改善の成果は、当該顧客だけでなく、他の顧客サービス向けデプロイメントにも波及している。

FDEに求められる人物像

記事が示すFDEの特性は以下の通りだ。

• 入社初日に業界知識は不要だが、学ぶ責任はある
• 汎用人材と領域専門家を組み合わせたチーム構成
• 正しい判断ができるだけの知識と、現状の前提を疑う好奇心

ライフサイエンス分野では科学的なバックグラウンドを持つFDEが、前臨床創薬ワークフロー（ターゲットバリデーション、遺伝子発現解析、化学合成経路の再構築など）で研究者の信頼を獲得している事例も紹介されている。

コーディングアシスタントがソフトウェア開発を加速するほど、顧客のビジネスを深く理解することの比重が上がる——という観点は、AI時代のエンジニアの役割を考える上で示唆に富む。半導体事例における「知識ゼロからの現場常駐・eval構築」という姿勢は、FDEが単なる「技術支援者」ではなく、顧客の業務変革を共に推進するパートナーであるというOpenAIの意図を体現している。

詳細はWhat FDE means at OpenAIを参照していただきたい。