今話題の AI 職種「FDE」とは？未経験から目指すためのロードマップ

この 2 年間、AI 業界で最も引っ張りだこだった人材は、モデルを開発する人と AI プロダクトを作る人だった。

ところが 2026 年に入ると、もう一つの職種が突如として台頭してきた。それが FDE だ。

正式名称は Forward Deployed Engineer（フォワード・デプロイド・エンジニア）。正直なところ、名前を聞いただけでは、具体的に何をする仕事なのか分からない人も多いだろう。

まず、いくつかの数字を見てみよう。

• LinkedIn のレポートによると、FDE 関連の求人は 2023 年から 2025 年にかけて 42 倍に増加した。
• OpenAI は 2026 年 5 月にデプロイメント・カンパニーを設立し、初期投資は 40 億ドル以上、買収によって約 150 人のデプロイエンジニアと専門家を迎え入れた。
• AWS はその後 10 億ドルを投資し、数千人のエンジニアを顧客チームに送り込んでいる。

大手テック企業がこぞってこうした人材を確保しようとしているのは、風向きの変化を示している。モデルのリーダーボードでの 0.1 ポイントの差は顧客には伝わらないかもしれないが、レガシーシステムに統合でき、ワークフローの中で稼働し、最終的にお金を節約できる AI システムには、顧客は継続的にお金を払う用意がある。

AI 業界は「モデル比較」の時代から「実装力比較」の時代へと移り変わった。

AI 転換を検討している人も、次のキャリアを探している人も、この記事で 3 つのことが明確になるだろう。FDE とは何か、日々何をしているのか、そしてプログラミング未経験者が段階的に転身する方法だ。

1. FDE とは一体何なのか？

私は次のように説明するのが好きだ。

FDE とは、顧客の実際のビジネスに入り込み、AI をデモから本番環境まで導く人材のことだ。

顧客が「AI カスタマーサービスを作りたい」と言ったとしよう。一般的な要件定義であれば、まず機能の作り込みから始まるかもしれないが、FDE はもっと深く掘り下げなければならない。

• カスタマーサービスは現在、1 日に何件のチケットを処理しているのか。
• AI はどの質問に答えられるのか。
• どの返信は人間の確認が必要なのか。
• 顧客データはどこに保存されているのか。
• AI の誤りはどのように取り消すのか。
• リリース後、追跡すべきは応答速度なのか、解決率なのか、それとも人件費なのか。

こうした質問が明確になって初めてコーディングが始まる。システムを作り終えたら仕事は終わりではない。データの連携、権限設定、評価、本番リリース、利用状況のモニタリングまでを行い、現場で遭遇した問題をプロダクトチームにフィードバックする必要がある。

一連のワークフローは、次の 6 つのステップに集約できる。

1問題発見
2→ プロセスの分解
3→ ソリューションの作成
4→ システム構築
5→ 本番リリース
6→ 結果のモニタリング

要件は出発点にすぎない。成果こそが納品物だ。

そのため、FDE はしばしば 3 つのことを同時にこなさなければならない。

コードを書ける人はたくさんいるが、顧客の現場に足を運び、混乱した状況を整理してリリース可能な状態にまで持っていく人ははるかに少ない。これが、FDE の採用が難しく、報酬が高騰している理由だ。

2. FDE は一日中何をしているのか？

小売チェーンが AI ベンダーを見つけ、「スマート発注エージェント」を作りたいと言ったとしよう。一見明確に聞こえるが、FDE が現場に着くと、あちこちから疑問が湧いてくる。

• どの店舗が最も欠品しやすいのか。
• 発注は売上、天候、祝日、プロモーション計画のどれを考慮するのか。
• エージェントは提案するだけなのか、それとも発注書を直接作成するのか。
• 一定額を超える場合、手動承認が必要なのか。
• 在庫の更新は 1 日 1 回で十分なのか。
• 推奨が間違っていた場合、売り損じと損失は誰が責任を負うのか。

最初の 1 週間は、コードを 1 行も書かないかもしれない。まず店長に話を聞き、現在の発注プロセスを把握し、サプライチェーン担当者とルールを確認し、IT とインターフェースを調整し、セキュリティ部門と権限について協議する。プロセスが明確になってから、エンジニアリングのフェーズに入る。

• 在庫・売上・注文システムを連携させる。
• 過去のデータをクレンジングする。
• モデル呼び出しとエージェントワークフローを実装する。
• 従業員が実際に開きたくなるページを構築する。
• ログイン、権限、ログ、モニタリングを追加する。
• テストデータを準備する。
• 手動レビューと障害時のフォールバックを設定する。

リリース後もモニタリングを継続しなければならない。店舗が実際に使っているか、提案の採用率、欠品率が下がったか、従業員がこっそり Excel に戻っていないか、その理由は何か――すべて彼らの仕事だ。

利用率が低すぎるのに「ユーザーが使い方を知らない」と言って帰ってしまえば、プロジェクトは失敗するだろう。ページ、プロセス、モデルの出力のうち、どの部分が使いにくいのかを突き止め、修正する。

FDE が届けるのは、すでに稼働しているビジネスプロセスだ。きれいなデモを作るのは、山の半分に登ったにすぎない。

3. FDE とプログラマー、プロダクトマネージャー、プリセールスの違いは？

これらの職種は同じチームで仕事をすることが多く、役割の境界は重なり合っている。最もシンプルな区別方法は、それぞれが何に責任を持つかを見ることだ。

FDE の担当範囲はより広い。午前中に顧客とビジネスミーティングをし、午後にデータベースを調べ、夕方にインターフェースを修正する――すべて同じ日に起こり得る。

ただし、誤解してはいけない。FDE の E はやはり Engineer（エンジニア）を意味している。

OpenAI の現在の FDE 採用要件では、プロダクションレベルのフロントエンドおよびバックエンドのコードを書けてレビューできることが明示的に求められている。Palantir の新卒向けポジションでも、少なくとも 1 つのプログラミング言語に精通していることが必須だ。つまり、コンピューターサイエンスのバックグラウンドがなくても転向は可能だが、コードを完全に避けて通ることはできない。

ビジネスや顧客との関わりが好きで、長期的にプロダクションコードを書き続けたくない場合は、デプロイメントストラテジスト、AI プロダクトマネージャー、業界ソリューションコンサルタント、カスタマーサクセス、AI コンサルティングなどの職種を検討するといい。これらの役割も AI 実装のチェーンに含まれるが、エンジニアリングの責任はより軽い。

4. なぜいま FDE が注目されているのか？

理由はシンプルだ。AI が強力になるほど、実装の問題が顕在化するからだ。

デモは 1 日でできるが、本番はそんなに甘くない

モデルの API を接続し、ドキュメントを放り込み、チャットページを作れば、1 日で上司を感心させられる。しかし、いざリリースを準備すると、汚いデータ、乱雑な権限、旧システムのインターフェース不足、モデル出力のぶれ、セキュリティ監査、従業員の習慣などが一斉に表面化する。

モデルのアップグレードでは現場の混乱は解決できない。企業はビジネスの現場に飛び込み、こうした問題を一つひとつ解決できる人材を必要としている。

エージェントが実際に「動く」ようになった

チャットボットが間違った回答をしても、ユーザーは採用しない選択ができる。しかし、エージェントがメールを送信し、注文を修正し、承認を提出するようになれば、エラーは直接ビジネスに影響を及ぼす。

本人確認、権限、評価、ログ、手動レビュー、例外処理はすべて欠かせない。企業ごとにシステムが異なるため、この作業を汎用マニュアルで完了するのは難しい。

AI 企業は顧客に製品を使ってもらう必要がある

契約を結ぶのは、ようやく扉をくぐっただけのことだ。モデルが中核プロセスに組み込まれて初めて、利用量の増加、契約更新、部門展開が生まれる。

FDE は顧客の成果に最も近く、AI 企業の収益にも最も近い。これが、OpenAI と AWS が巨額の投資を惜しまないビジネス上の理由だ。

AI プログラミングがゼネラリストの生産性を拡大する

かつてエンタープライズアプリケーションを一揃え構築するには、プロダクト、フロントエンド、バックエンド、データ、運用保守の各チームを待つ必要があった。今や、エンジニアリング力の高いゼネラリストなら、AI プログラミングを活用してプロトタイプの作成、統合、テスト、修正をより速く完了できる。

少数のメンバーが顧客チームに入り、数週間で最初のバージョンを構築し、実際のフィードバックに基づいて迅速に反復できる。これでようやく採算が合うようになった。

前のステージは「どちらのモデルが強いか」だった。今のステージは「誰がモデルをビジネスにフィットさせられるか」だ。FDE はまさにそのギャップを埋める存在である。

5. 普通の人にチャンスはどこにあるのか？

「これって結局、シニアプログラマー向けの話じゃないか？」そう思うかもしれない。

シニアエンジニアが有利なのは事実だ。しかし、FDE の能力は複数の方向から形成される。普通の人もゼロからやり直す必要はなく、すでに持っている経験を見極め、不足している半分を補えばいい。

ソフトウェアエンジニア：最も近い立場

プロダクションコードの書き方や、システムがクラッシュする理由はすでに理解しているはずだ。次に必要なのは、ユーザーインタビュー、ビジネスプロセス、要件の範囲、ROI、採用率への理解を深めることだ。

最も直接的な練習方法は、顧客ミーティング、プリセールス支援、社内の AI 実装プロジェクトに積極的に参加することだ。誰かが要件を Jira タスクに分解してくれるのを待ってはいけない。

データアナリスト：転向に非常に適している

データアナリストは通常 SQL を扱え、指標を理解し、ビジネス部門とのコミュニケーションに慣れている。不足しているのはエンジニアリングの部分だ。

• Notebook をサービスに変換する方法。
• API を連携する方法。
• ログインと権限を処理する方法。
• デプロイとモニタリングの方法。
• エラー発生後の復旧方法。

自分にしか実行できない分析を、同僚が毎日開けるツールに変えることは、FDE への大きな一歩となる。

プロダクト・コンサル・業界オペレーション：業界経験は貴重な資産

製造業で働いた経験があれば、生産計画や歩留まりを理解している。金融なら、監査やコンプライアンスを理解している。小売なら、在庫管理や店舗の実行力を理解している。こうした経験は、数回の講義で得られるものではない。

これにプログラミング、データベース、API、デプロイの知識を補い、実際に動くシステムを一から構築してみるべきだ。移行先の職種としては、以下のようなものがある。

• デプロイメントストラテジスト。
• AI プロダクトマネージャー。
• AI ソリューションコンサルタント。
• ソリューションエンジニア。
• 技術導入（テクニカルインプリメンテーション）。

まず AI 実装の現場に入り、そこから徐々にエンジニアリングの責任を拡大していくのが現実的だ。

プリセールス・導入・ソリューションアーキテクト：すでに半分達成しているかもしれない

顧客との関係に慣れており、企業における権限、調達、レガシーシステムの厄介さも熟知しているはずだ。次に必要なのは、コーディングの壁を越えること。デモ作成や製品設定から、開発、テスト、デプロイ、運用保守へと領域を広げていく。

このルートは、完全なキャリアチェンジよりはるかに短いのが普通だ。

まったくの初心者：まず一つの確かなスキルを磨く

技術経験も業界の蓄積もないまま FDE に飛び込むのは非常に難しい。まずはデータ分析、AI オペレーション、テクニカルサポート、導入コンサルティング、ジュニア開発、業界ソリューションアシスタントなどの職種から始めるといい。

FDE がキャリアの最初の一歩になることはほとんどない。複数の経験が最終的に収束する地点こそが FDE なのだ。

6. 普通の人のための 6 ヶ月ロードマップ

求人情報を読んだ後、誰もがやりがちなのはコースをお気に入り登録することだ。6 ヶ月後、ブックマークは増えたのに、履歴書は空のままだ。

6 ヶ月あれば、FDE のポートフォリオを構築できる。採用されるかどうかは、既存の経験、エンジニアリングレベル、応募先企業の要件によって変わる。

1〜2 ヶ月目：エンジニアリングの基礎を固める

まず、最もよく使われるものを学ぼう。

• Python または TypeScript。
• SQL とデータベース。
• HTTP、JSON、API。
• Git。
• エラーハンドリングとテスト。
• Docker と基本的なデプロイ。

この段階の合格基準はただ一つ。データベースと API を備えた小さなアプリケーションを自走で構築し、デプロイ後、他の人が開いて使える状態にすることだ。

入力、処理、保存、エラー通知、デプロイまで一通り動かすこと。フレームワークが新しいかどうかは、今は気にしなくていい。

3〜4 ヶ月目：完全な AI アプリケーションを構築する

最初のバージョンのアプリケーションに、モデル API、RAG、ツール呼び出し、構造化出力、ログ、評価（Evals）、障害時のリトライ、手動レビューを追加していこう。

「PDF をアップロードしてチャットする」だけのものはやめて、具体的なタスクを選ぶこと。

• 営業のリード整理とフォローアップ提案を支援する。
• カスタマーサービスのナレッジ検索と返信ドラフト作成を支援する。
• 経理の経費精算書類のチェックを支援する。
• オペレーションのデータ整理と異常アラートを支援する。
• 製造チームの設備故障と保守記録の検索を支援する。

第 2 段階で重視すべき指標は 4 つある。

5〜6 ヶ月目：実際のユーザーを見つける

試用してくれる人を 3〜5 人見つけ、2 週間連続で使ってもらおう。従来のプロセスと新しいプロセスの所要時間、利用回数、採用された提案、手動対応が必要だったエラー、途中でユーザーが諦めた理由を記録する。

実際のユーザーは、隠れた問題をすべて明らかにしてくれる。汚いデータ、権限不足、使いにくい UI、絶えず変わるプロセス、高いモデルコスト。こうした問題を解決することで、あなたのプロジェクトは本物の FDE プロジェクトに近づく。

最後に、ケーススタディとしてまとめよう。

1ビジネスの背景
2→ 従来のプロセス
3→ この問題を選んだ理由
4→ システム構成
5→ データと権限
6→ 評価方法
7→ 利用結果
8→ 失敗と調整
9→ 再利用可能な部分

履歴書にフレームワークの名前を並べるのではなく、次の 3 点を明確に伝えること。誰が、どのくらいの期間使ったのか、そして指標がどう変わったのか。

7. 転職活動で「FDE」だけを検索してはいけない

この職種の名称はまだ完全には統一されていない。Forward Deployed Engineer 以外にも、次のようなキーワードで検索してみよう。

• Forward Deployed AI Engineer。
• Applied AI Engineer。
• AI Deployment Engineer。
• Solutions Engineer。
• AI Solutions Architect。
• Deployment Strategist。
• AI Application Delivery Engineer。
• AI Solution Engineer。
• Agent Engineer。

求人を見つけたら、次の 4 点を確認する。

1. 顧客や現場のユーザーに直接コンタクトするか。
2. プロダクションコードを自分で書く必要があるか。
3. 問題発見からリリースまで、すべての責任を負うか。
4. リリース後の採用率やビジネス成果まで追跡するか。

4 つすべてに当てはまるなら、仕事内容は FDE に近いだろう。

面接の準備方法

FDE の面接では、非常に曖昧な問題が提示されることが多い。例えば「病院が AI を使って患者の待ち時間を短縮したいと考えている。あなたならどうするか？」

慌ててモデルを選んではいけない。まず、患者はどの段階で待っているのか、誰が順番待ちとトリアージをしているのか、現在の平均待ち時間はどのくらいか、データはどこに保存されているのか、どの意思決定は医療スタッフが必ず行わなければならないのか、プロジェクトの成功を測る指標は何か。これを明確にすべきだ。

問題が明確になったら、システム、権限、リリース範囲について話す。面接官が見たいのは、曖昧な問題を明確な問題に変換できるかどうかだ。モデルの名前を 10 個暗記しても、この関門は突破できない。

8. 「名前だけ新しくなった現場納品」に注意

FDE の人気が高まるにつれ、同じ名前でも中身が異なる求人が増えてくるだろう。中には、主要なコードを書き、採用を促進し、現場の経験をプロダクトにフィードバックするポジションもあれば、毎日現場の火消しに追われ、コードがメインリポジトリに入ることはなく、評価も人日数と検収だけで行われるポジションもある。

どちらも FDE と呼ばれるが、その職業的価値は大きく異なる。面接の際には、遠慮なく直接質問しよう。

1. FDE が書いたコードは、どのリポジトリに入るのか。
2. チームはプロダクト部門か、エンジニアリング部門か、それともプロジェクト納品部門か。
3. プロジェクトの評価指標は採用率やビジネス指標か、それとも期日通りの検収だけか。
4. 現場の問題はどのようにプロダクトのロードマップに反映されるのか。
5. プロジェクト終了後、長期的な運用は誰が担当するのか。
6. 過去 3 つのプロジェクトから、どのような再利用可能なコンポーネントが蓄積されたのか。
7. 出張、現場作業、オンコールに費やす時間の割合はどのくらいか。

判断基準はシンプルだ。

• 本物の FDE：プロダクションコードを書き、成果に責任を持ち、経験がプロダクトに還元される。
• 名前だけ変わった現場サポート：人日で請求され、検収が中心で、プロジェクトごとにゼロからやり直す。

会社から「成果に責任を持て」と言われているのに、データ権限、技術的な決定権、プロダクトのサポートを与えられないなら、その仕事は非常に消耗するものになるだろう。職名は新しいが、働き方は何も変わっていない可能性が高い。

最後に

FDE の急成長は、AI が次のステージに進んだことを示している。モデルは今後も強力になり続けるだろう。しかし、モデルと実際のビジネスの間には、さらに大きなギャップが生まれている。

顧客は、現場に足を運び、乱雑なデータ、レガシーシステム、ビジネスルール、実際のユーザーをつなぎ合わせてくれる人材を必要としている。この仕事のハードルは高い。コードを書き、ビジネスを理解し、顧客と向き合い、リリース後の結果に責任を持つことが求められる。

普通の人にとってのチャンスは、すでに持っている半分のスキルの中に隠れている。コードが書けるなら、ビジネスと顧客スキルを補おう。業界を知っているなら、エンジニアリングとデプロイを補おう。データ分析やプリセールス、導入の経験があるなら、今のスキルをもう一段押し上げよう。まったくの初心者なら、まず検証可能な一つの確かなスキルを磨こう。

いま、ひとつだけやるとしたら。

実際の問題を見つけ、本番稼働できるツールを構築し、3 人に 2 週間連続で使ってもらうこと。

それをやり遂げれば、あなたの仕事はすでに FDE の仕事に近づいている。肩書きは後から付いてくる。

参考リンク

• LinkedIn：働くことの未来を築く
• OpenAI：OpenAI が OpenAI デプロイメント・カンパニーを設立
• AWS：パートナー向け Forward Deployed Engineering の紹介
• OpenAI：Forward Deployed Engineer の求人情報
• Palantir：新卒向け Forward Deployed Software Engineer

**

著者について