先に結論
日本でも、FDE（Forward Deployed Engineer）という職種を目にするようになりました。
少なくともOpenAIは、東京でFDEを明示的に募集しています。
ただ、少し乱暴に言うと、
日本には「FDEという役割の人」は増えても、「FDEとして結果を出せる人」は、まだそれほど多くない
のではないかと思っています。
FDEは、顧客の願いを聞いて持ち帰る人ではありません。
本当のFDEは、曖昧な願いを分解し、データ、モデル、業務、評価、運用を何度も混ぜ合わせ、現場で効く処方を作る人です。
つまり、錬丹師です。
FDEは「顧客担当エンジニア」ではない
OpenAIの東京向け求人を見ると、FDEは以下を一気通貫で担当すると説明されています。
- 課題の発見
- 技術スコープの定義
- システム設計
- 実装
- 本番展開
- 利用定着と効果測定
OpenAI募集内容（2026/07/10時点）：
成功の基準も「PoCを完成させたか」ではありません。
本番環境で使われているか、業務に測定可能な変化が出たか、現場のフィードバックを製品改善につなげられたかです。
FDEの原型を作ったPalantirも、FDEを顧客の隣で働き、難しい課題を理解し、設計からデプロイまでを自ら動かすエンジニアと説明しています。
つまり、FDEは単なる窓口ではありません。
顧客の前にいるSoftware Engineerです。
「願い事をするFDE」と「願い事をする顧客」
うまくいかないプロジェクトでは、次のような会話が起きます。
顧客：
AI Agentで問い合わせ対応を自動化したいです。
自称FDE：
分かりました。社内に持ち帰って検討します。
その後、デモ画面と説明資料が作られます。
しかし、次のことは決まっていません。
- どの問い合わせを自動化するのか
- 現在の対応時間とコストはいくらか
- 何％の誤回答まで許容できるのか
- 判断できない場合は誰に引き継ぐのか
- 正解を評価するデータはあるのか
- 本番運用の責任者は誰なのか
顧客は「AIで何とかしてほしい」と願う。
FDEも「モデルが何とかしてくれる」と願う。
願い事をする人が2人集まっても、成功事例は生まれません。
本当のFDEは「錬丹」する
錬丹とは、材料を集めて一度混ぜれば完成する作業ではありません。
配合を変え、火加減を変え、失敗を観察し、効く組み合わせが見つかるまで実験を繰り返します。
FDEの仕事も同じです。
- 業務課題
- 顧客データ
- AIモデル
- プロンプト
- 評価データセット
- セキュリティ
- 人間へのエスカレーション
- 既存システムとの連携
- 現場の運用ルール
これらを組み合わせ、小さく作り、実際の業務で試します。
精度が低ければ、プロンプトだけでなくデータや業務フローを見直す。
利用されなければ、UIだけでなく権限、責任分担、導入方法まで見直す。
効果が出たら、その方法をツール、Playbook、共通部品として再利用可能にする。
OpenAIも、FDEの役割として、最初のプロトタイプから安定した本番環境までを担当し、成功パターンをツールやPlaybookとして体系化することを挙げています。
これが「錬丹する」ということです。
顧客も共同開発者になる必要がある
もちろん、FDEだけが優秀でも成功しません。
顧客側にも必要なものがあります。
それは、完璧な要件定義書ではありません。
業務を説明できる人、データへのアクセス、判断できる責任者、効果を測る指標、そして業務そのものを変える意思です。
OpenAIが説明するFDEの活動も、経営者、技術責任者、業務担当者、現場チームと一緒に、価値の高い業務を選び、設計、実装、テスト、本番展開まで進めるものです。
FDEと顧客は、発注者と御用聞きの関係ではありません。
同じ炉の前に立つ共同開発者です。
まとめ
FDEは肩書きではありません。
顧客の曖昧な願いを、
- 検証可能な仮説に変える
- 動くシステムに変える
- 測定可能な成果に変える
- 再利用可能な知識に変える
能力です。
願い事をするFDEと、願い事をする顧客から、成功事例は生まれません。
本当のFDEは願いを受け取る人ではなく、現場に入り、手を動かし、失敗を観察し、効く処方ができるまで錬丹を続ける人です。
そして最終的には、
「AIを導入しました」ではなく、「この業務が、これだけ変わりました」
と言える状態まで責任を持つ人なのだと思います。