FDEとは何か
FDEとは、Forward Deployed Engineerの略です。顧客の現場に近い場所に入り、業務課題を理解し、設計し、必要に応じて自分で実装まで行うエンジニアを指します。
直訳すれば「前線に配備されたエンジニア」です。ただし、単なる客先常駐エンジニアではありません。営業に同行するプリセールスでもありませんし、提案書を作って終わるITコンサルでもありません。
FDEの特徴は、顧客の課題を聞くだけで終わらないことです。業務を見て、課題を切り分け、プロトタイプを作り、現場に当て、使える形に直していく。この一連の動きを担うのがFDEです。
Palantirの記事では、Forward Deployed Software Engineerを、顧客にソフトウェアを配備し、重要な業務課題に対して技術的な成果を出す役割として説明しています。通常のSoftware Engineerが「1つの機能を多くの顧客へ」届けるのに対し、FDEは「1つの顧客に多くの機能」を届ける役割だ、という整理です。
この対比は、FDEを理解するうえで分かりやすい整理です。一般的なエンジニアは、プロダクトの中から顧客を見ます。FDEは、顧客の現場からプロダクトを見ます。そして、顧客の現場で起きている曖昧な課題を、プロダクトや技術で解ける形に変えていきます。
FDEとコンサル/エンジニアとの違い
FDEは、コンサルにもエンジニアにも近い役割です。ただし、どちらとも少し違います。
コンサルは、顧客の課題を整理し、戦略や改善案を提示します。エンジニアは、仕様をもとに設計し、コードを書き、プロダクトやシステムを作ります。FDEは、その中間にいます。
顧客と話して課題を理解します。業務フローを見て、どこにボトルネックがあるのかを考えます。必要であれば、その場でプロトタイプを作ります。そして、実際に使う人の反応を見ながら、設計を変えていきます。
つまりFDEは、考えるだけでも、作るだけでもない役割です。FDEは「作れるコンサル」と言うこともできますが、それだけでは少し浅いです。むしろFDEは、現場の課題を、動くものに変えるエンジニアです。
たとえば、顧客が「問い合わせ対応をAI化したい」と言ったとします。通常のコンサルであれば、現状業務を整理し、AI導入案やロードマップを作るかもしれません。通常のエンジニアであれば、決まった要件に沿ってチャットボットやRAGを実装するかもしれません。
一方でFDEは、その前後をまたぎます。どの問い合わせならAIが答えてよいのか。どの問い合わせは人間に回すべきなのか。回答の根拠はどう出すのか。顧客情報をどこまで参照してよいのか。誤回答が出たときに、誰がどう確認するのか。現場担当者は、本当にその画面を開くのか。こうした論点を見ながら、まず小さく動くものを作ります。そして、現場で試し、使われる形に近づけていきます。
日本でFDEを説明すると、「客先常駐SESと何が違うのか」という疑問も出てきます。レバテックLABの記事でもこの論点が扱われており、FDEは顧客の個別課題に向き合いながら、その知見を自社プロダクトや仕組みに戻していく役割として語られています。
この違いは、顧客から言われた作業をこなすのか、それとも顧客課題と自社プロダクトの両方を前に進めるのか、という点にあります。FDEは、人月を売る仕事ではありません。現場で得た知見を、プロダクトや再利用可能な仕組みに戻していく仕事です。
なぜAI時代にFDEが重要になるのか
AI時代にFDEが重要になる理由は、シンプルです。AIは、導入しただけでは業務に入らないからです。
生成AIやAIエージェントは、従来のSaaSよりも自由度が高い技術です。文章を作ることも、データを読むことも、コードを書くことも、外部ツールを操作することもできます。ただ、自由度が高いということは、同時に、設計しなければ使われないということでもあります。
どの業務に使うのか。どのデータを見せるのか。どこまでAIに任せるのか。どこで人間が確認するのか。どうやって品質を評価するのか。本番導入してよいかを、何で判断するのか。ここを詰めないままAIを入れると、PoCで止まります。
OpenAIのForward Deployed Engineeringチームも、研究成果を顧客の本番システムに変える役割として説明されています。OpenAIのFDEは、発見、技術スコープ、システム設計、構築、本番展開までを担い、成功を本番利用、業務インパクト、評価フィードバックで測るとされています。
これは、AI導入の本質をよく表しています。AIで重要なのは、モデルを選ぶことだけではありません。そのモデルを、どの業務に、どの権限で、どの評価基準で、どう置くかです。
a16zも、エンタープライズAI製品では、社内データベース、API、ワークフローへ深く接続し、業務文脈を与える実装作業が必要になると論じています。AIエージェントを有効に使うには、単にソフトウェアを提供するだけでなく、顧客ごとの業務に合わせて実装・運用するチームが必要になる、という見方です。
AIは、単体では部品です。業務フロー、データ、権限、人間の確認、評価指標とつながって、初めて成果になります。だからAI時代には、AIを知っている人だけでは足りません。AIを業務に配置できる人が必要になります。その役割が、FDEです。
Atlas Supportが考えるFDE的支援
Atlas Supportでは、FDEを単なる職種名としてではなく、AI導入を前に進めるための実装スタイルとして捉えています。
企業がAIを活用しようとすると、多くの場合、最初に出てくるのはかなり曖昧なテーマです。社内ナレッジをAIで検索できるようにしたい。問い合わせ対応を自動化したい。営業資料作成を効率化したい。バックオフィス業務にAIを入れたい。AIエージェントで何かできないか考えたい。こうしたテーマは、そのままでは開発要件になりません。一方で、会議で議論しているだけでも前に進みません。
必要なのは、テーマを選び、業務を分解し、必要データを確認し、リスクを見て、小さく試せる形にすることです。Atlas SupportのAI Advisoryでは、毎月1つのAIテーマを選び、そのテーマについて、調査、設計、軽量検証、次アクション整理までを行います。
具体的には、月次AIテーマ評価レポート、プロンプト/設計メモ、業務フロー/AIエージェント設計図、簡易デモ/モックアップ、PoC計画書、KPI/ROI設計メモ、リスク/ガバナンスメモ、経営向け1枚サマリなどに落とし込みます。
目的は、AIを「なんとなく試す」ことではありません。投資判断できる状態にすることです。AI導入では、いきなり本格開発に進むと危険です。ただし、相談や研修だけでは何も残りません。その間にあるのが、FDE的な支援です。
現場の課題を聞き、技術的に解ける形に分解し、必要であれば簡易デモを作り、PoCに進むべきか、開発すべきか、保留すべきかを判断できる材料にする。Atlas SupportのAI Advisoryについて詳しく見ることで、この進め方を月額顧問型でどう導入できるかを確認できます。
AI導入テーマを検討する段階では、ユースケース一覧やInsights一覧も、対象業務や論点を絞るための参考になります。
まとめ
FDEは、単なる新しい職種名ではありません。AI時代に、ソフトウェアやAIを現場で価値に変えるための役割です。
コンサルのように課題を整理し、エンジニアのように実装し、プロダクトマネージャーのように使われ方を見ます。ただし、その中心にあるのは、いつも顧客の現場です。
AI導入で難しいのは、AIを試すことではありません。AIを業務の中に置き、使われる形にし、成果を判断できる状態にすることです。そのためには、技術と現場のあいだに立つ人が必要になります。
AI時代のボトルネックは、モデルそのものよりも、現場へのデプロイにあります。AI時代に強い企業は、AIを知っているだけの企業ではありません。AIを現場にデプロイできる企業です。
FDEは、そのための実装人材であり、これからのAI導入において重要な考え方になるはずです。
CTA
AI導入を本格化する前に、まずは実務で使えるかを小さく検証することが重要です。テーマを選び、業務を分解し、必要なデータやリスクを確認し、PoCに進むべきかを判断できる材料に変えていきます。
AI活用を、PoCで終わらせないために
Atlas SupportのAI Advisoryでは、毎月1つのAIテーマを選び、調査・設計・軽量検証・PoC計画まで整理します。