【FDE完全入門 1/8】FDEとは？仕事内容・役割・必要なスキルを解説

「FDE完全入門」連載・第1回（全8回）

「AIでコードを書く時間が短くなったら、エンジニアは何で価値を出すのだろう」。そんな疑問を考えるうえで、知っておきたい働き方がFDEです。

FDEはForward Deployed Engineerの略で、顧客の業務に深く関わりながら、課題の整理と技術の実装を進めるエンジニアを指します。

単にAIツールの使い方を教える担当でも、依頼された機能だけを作る担当でもありません。

この連載では、FDEの基礎からキャリア、架空の問い合わせ対応を題材にした設計演習までを扱います。

第1回は「誰のために、何をする仕事なのか」を整理しましょう。求人・公開情報の確認日は2026年10月21日です。

FDEは、顧客の課題と技術をつなぐ仕事

分かりやすくいうと、FDEは「顧客の現場で、使われる仕組みを作るエンジニア」です。

現場で起きている問題を理解し、必要なデータや既存システムを調べ、動くものを作り、実際の業務で役立つかを確かめます。

例えば、企業から「問い合わせ対応をAIで自動化したい」と相談されたとします。

すぐにチャットボットを作り始めるのではなく、まず担当者が何に時間を使っているのかを確認します。

回答文の作成より、注文情報を探す作業のほうが負担かもしれません。問題が違えば、作るべき仕組みも変わります。

なお、FDEという名称に業界共通の資格や統一された業務範囲があるわけではありません。

勤務先の製品、顧客、契約によって役割は異なります。顧客に近いことは、必ずしも毎日客先に常駐することと同じではありません。

生成AIによって初めて生まれた職種ではない

Palantirは2019年4月8日の公式記事で、製品開発のエンジニアとForward Deployed Software Engineerの役割を説明しています。

現在の生成AIブームより前から、顧客への導入を担う働き方が存在していたことが分かります。

FDEは「AIが作った全く新しい仕事」と理解するより、以前からある役割がAI導入の文脈でも注目されている、と捉えるほうが正確です。

Palantir公式の職種解説

FDEは具体的に何をするのか

1. 業務を理解し、解く問題を絞る

最初の仕事は、要望をそのまま機能一覧にすることではありません。

誰が、どの場面で、何に困っているのかを明らかにすることです。

「回答が遅い」という問題でも、資料が散らばっているのか、確認権限が足りないのか、担当者が不足しているのかで対処は変わります。

業務の流れを一枚に整理し、今の作業時間や手戻りの原因を記録すると、改善後の比較もしやすくなります。解決策がFAQの整理や画面の改善で済むなら、無理にAIエージェントを使う必要はありません。

2. 小さく作り、現場で確かめる

次に、最小限の試作品を作ります。問い合わせ対応なら、まず社内向けの回答下書きに限定する方法があります。

承認なしで顧客に送信する機能まで最初から含めると、間違った回答が外部へ出るリスクが増えます。

試作品を使う人に見せると、「文章は正しいが長すぎる」「返品規定の例外が抜けている」といった問題が見えてきます。

こうした反応を受け、設計と実装を繰り返し調整します。実装の速さだけでなく、問題を早く見つけることにも価値があります。

3. 本番で使える状態に整える

デモが動くことと、毎日の業務で安心して使えることは別です。

誰がどの情報を見られるか、間違ったときに誰へ引き継ぐか、費用が増えたらどう止めるか。こうした運用上の決め事が必要になります。

FDEがすべてを一人で担当するとは限りません。

顧客の業務責任者、セキュリティ担当、開発チームと役割を分担します。重要なのは、部署の間に落ちてしまいがちな課題を見つけ、責任者と対応方法を明確にすることです。

4. 現場の学びを次の改善につなげる

一社でしか使えない場当たり的な対応を増やすと、後から保守が難しくなります。

顧客固有の設定と、他の顧客にも使える機能を分けて考えることが大切です。

共通する問題は製品開発チームに共有し、再利用できる手順や部品として残します。

OpenAIの東京向けFDE求人では、課題発見から本番展開までの担当範囲に加え、導入後の利用や業務への効果を重視する姿勢が示されています。これは一社の職務例であり、すべてのFDE求人が同じ条件という意味ではありません。

OpenAIの東京向けFDE求人

なぜAI導入で、この役割が重要になるのか

AIの出力が自然でも、そのまま仕事が終わるとは限りません。

社内資料を参照できない、権限のない情報を扱ってしまう、回答の正しさを確認できない。こうした問題を解くには、モデルの性能だけでなく業務の理解が必要です。

また、担当者に使われなければ、システムは成果につながりません。

使い慣れた画面から呼び出せるか、確認作業が増えすぎないか、例外時の対応が分かるか。技術と運用を一緒に考える人が必要になる理由はここにあります。

ただし、FDEがいれば必ず成功するわけではありません。

顧客側にも、業務上の判断をする人、データを管理する人、導入後に運用する人が必要です。

エンジニアに丸投げするのではなく、一緒に改善する体制が前提になります。

従来のSEやITコンサルとは何が違う？

FDEだけが顧客の課題を解決しているわけではありません。

SEも要件定義や運用に関わりますし、ITコンサルが開発を担うこともあります。境界を職種名だけで決めると、実際の仕事を見誤ります。

比較するときは、①顧客と直接課題を決めるか、②自分で実装するか、③本番導入後まで関わるか、④特定の製品を基盤にするか、という四つの軸を見ると分かりやすくなります。

FDEはこれらを横断する役割として設計されることが多いものの、最終的には求人票や契約の確認が必要です。

FDEに求められる四つの力

• 実装力：画面、API、データの流れを理解し、問題が起きたときに調べて直す力。
• 課題整理力：要望の背景を聞き、優先順位と成功条件を決める力。
• 説明・調整力：技術的な制約を、現場担当者や経営者が判断できる言葉で伝える力。
• 業務理解：担当者の手順、例外、ルールを学び、システムに反映する力。

最初からすべてに熟達する必要はありません。例えば開発経験があるなら、次の案件で利用者へのヒアリングと導入後の振り返りまで担当してみる。その経験が、自分に足りない力を見つけるきっかけになります。

日本でも普及する？職種名より役割に注目しよう

東京での求人が確認できる一方、日本全体の採用数がどの程度増えているかは、個別求人だけでは判断できません。

FDEという名前を使わず、似た仕事をしている企業も考えられます。

転職を考える人は肩書きだけでなく、顧客との距離や実装範囲を確認しましょう。

導入を考える経営者は、「何を納品するか」に加え「誰が使い、何を改善し、導入後は誰が運用するか」を支援会社と話し合うことが大切です。

まとめ：作る力を、使われる仕組みにつなげる

FDEは、業務理解と技術実装の間を行き来する働き方です。

コードを書く力を不要にする仕事ではなく、その力を顧客の成果につなげる範囲が広い仕事と考えると理解しやすいでしょう。

次回は、OpenAI・Palantir・AWSの公開情報をもとに、なぜ今この役割が注目されるのかを掘り下げます。

企業の投資、求人、エンジニアの意識調査を分けて、市場の動きを確認します。