FDEが採れない。求人を出しても応募が来ない、来ても年収が合わない。2026年10月時点で、この状況は多くの日本企業に共通しています。

採用が詰まったとき、残る道は2つです。外部のFDEに任せ続けるか、社内のエンジニアを育てるか。外部に任せ切りにすると、契約が終わった途端にノウハウが消えます。かといって育てる道を選ぶなら、「誰を」「何を」「どの順で」「どう評価するか」を先に決めておかないと、肩書きだけのFDEが生まれます。

社内エンジニアをFDEに育てるための選び方・スキル・進め方・評価を、公開情報で確認できる範囲と事業者の主張とを分けて整理します。

この記事でわかること

  • FDE育成が「採用の代替」ではなく、外部FDEからの知識移転とセットで設計すべき理由
  • どの職種のエンジニアがFDEに転換しやすいか、職種ごとに何を補えばよいか
  • 身につけるスキルを4つの層に分けた育成設計
  • 研修から独り立ちまでの段階と、外部FDEとのペアの組み方
  • 評価・キャリア設計と、肩書きだけのFDE（FDEウォッシング）を防ぐ方法

FDE育成は「採れないから育てる」だけでは成立しない

FDEの育成とは、客先や事業部門の現場に入り込み、課題の定義からAIシステムの本番運用までを一人で通せるエンジニアを、社内の人材から作ることです。通常のエンジニア育成が「決められた仕様を実装できる人」を作るのに対し、FDE育成は「仕様が決まっていない状態から、現場と一緒に仕様を作れる人」を作ります。

最初に押さえておきたいのは、育成には時間がかかり、即戦力にはならないという事実です。

大手は採用と買収で動いている

FDEの需要は急拡大しています。AWSは2026年6月にFDE専門組織の新設を発表し、初期コミットは10億ドルと報じられています。5〜6人のポッドが1顧客に入り、数週間で顧客が自走できる状態に引き渡す体制です。

人の確保手段も大手は割り切っています。AWSのFDE担当VPはFDE人材を「ユニコーン」と呼び、当面は同種の仕事を最前線で経験済みの即戦力に絞って厳選する方針です（Business Insider Japan）。OpenAIは英国のコンサルティング会社Tomoroの買収で、約150人のFDE・デプロイメントスペシャリストを初日から確保しました（Pulse 2）。

大手の公開情報で見えるのは「採用と買収」で、社内転換の型は見当たりません。一般企業が同じ土俵で採用競争をしても勝ちにくい。ここが「育てる」を真剣に検討する出発点になります。

外部FDEに任せ切りにしない動機

外部のFDEに頼る選択肢はあります。ただし、ベンダーFDEが開発したAIエージェントの70%が2028年までに企業で使われず放棄される、という予測が出ています。出口戦略、つまり「いつ、誰に引き渡すか」を最初に決めていない案件は、納品して終わりになりやすいのです。

この予測はベンダーFDEの調達について述べたもので、社内育成を推奨したものではありません。それでも、買い手側が知識移転を求める理由は明確です。引き渡す先、つまり社内に受け皿となる人がいなければ、移転のしようがない。社内FDEは、外部FDEの成果を受け取って育て続ける側の人材になります。

育成の限界を先に認めておく

育成には限界もあります。即戦力として現場に出せるまでには、基礎の習得と実案件の経験が要ります。期間は事業者によって4週間から36か月まで開きがあり、標準と呼べるものは公開されていません。

向き不向きも分かれます。次の表で、自社がどちらに近いかを確認してください。

状況向いている進め方
数か月以内に成果を出す必要がある外部FDEを先に入れ、社内候補は同行から始める
実装できるエンジニアが社内に複数いる社内公募で候補を選び、育成を主軸にする
運用を長く続けたいAI案件がある引き渡し前提で外部FDEと社内候補をペアにする
実装できる人が社内にほぼいないまず開発の土台づくり（研修）から始める

育成と外部活用は二者択一ではありません。早く動くために外部を使い、残る力を社内に積むのが現実的な組み合わせです。

育成設計で決めるのは、誰を候補にするか、何を身につけさせるか、どの順で進めるか、どう評価するか、の4点です。時間がない方は、スキルの4層と段階設計の表だけ読めば全体を掴めます。人事の方は評価の節から、開発責任者の方は育成対象の節から読んでも通じます。

育成対象はソフトウェア実装力のある人から選び、足りない要素を補う

候補者選びで外してはいけない軸は、ソフトウェアの実装力です。AWSが求める要素の1つに「深いソフトウェア専門知識」があり、Palantirの新卒向け求人もPython、Java、C++、TypeScript/JavaScriptなど1つ以上のプログラミング言語への習熟を求めています（Palantir求人）。顧客対応が得意でも、実装できなければ本番運用まで通せません。

転換元職種ごとに補うポイントが違う

職種ごとの転換しやすさについて、公的なデータや大手の公開情報はありません。以下は事業者資料と転職体験談から組み立てた補強ポイントの仮説です。自社の人材に当てはめるときの出発点として使い、断定はしないでください。

転換元強み補う要素
ソフトウェアエンジニア実装力、設計力顧客・現場との折衝、課題を定義する経験
社内SE社内ユーザーとの調整経験製品レベルのコード、AIシステムの評価・運用
SRE・インフラ障害対応の規律、運用の知識製品コード、非エンジニア向けの報告・デモ
ソリューションアーキテクト顧客との対話、全体設計手を動かして本番まで持っていく実装
ITコンサル課題整理、業務理解実装スキル全般
プロダクトマネージャー要件の言語化技術実装力

社内SEは、社内のユーザーが「顧客」にあたるため、調整経験をそのまま活かせます。SREは、障害対応の経験がAIシステムの保守に直結します。一方で戦略コンサルのように実装経験が薄い職種は、コーディングの習得が壁になり、転換に時間がかかると事業者資料は述べています。ただし、年数の数字には根拠が確認できません。

現場に入る意欲を、スキルより先に確認する

スキル以外で見るべき点があります。顧客や事業部門に入り、相手の言葉で課題を聞き出すことを、面倒ではなく面白いと感じるかどうかです。AWSのFDE担当VPは、スタートアップ的な考え方の人が成功しやすいと話しています。

社内公募で希望者を募るのが最も確実です。指名で選ぶと、「いつもの開発に戻りたい」という本人の意思と食い違い、定着しにくくなります。事業者の資料は、業務を分解できる人を候補にして週に一定の学習時間を確保することを最低条件に挙げています。学習時間を確保せず現業と掛け持ちさせる運用は、典型的な失敗パターンです。

最初から全エンジニアを対象にするのも避けてください。1〜3名で始め、うまくいった型を2期目に広げます。育成する側のFDE（外部でも社内でも）の時間が、必ず足りなくなるからです。

スキルは4つの層で考える

必要なスキルは膨大に見えますが、層に分けると育成の順序が決まります。

層中身具体例
技術本番システムの設計・実装・運用AIエージェントの構築、ガードレール実装、モデル選定、モデル更新への対応、セキュリティポリシーの適用
現場理解業務とデータの理解業務フローの分解、現場の言葉の聞き取り、データ層・統合層の知識
対人顧客との協働と説明非エンジニア向けの報告・デモ、コンテキスト整理、合意形成
引き渡し相手が自走できる状態を作る知識の移転、運用手順の整備、出口の設計

技術層の具体例は、AWSが実務として挙げているガードレール実装・コスト面で最適なモデルの選定・モデル更新への対応・セキュリティポリシー適用です。ガードレールとは、AIが誤った出力や危険な操作をしないよう、入出力や権限に歯止めをかける仕組みのことです。現場理解層と対人層は、KPMGのFDE担当者（個人インタビューであり、同社の公式見解ではありません）が挙げる「AIに渡すコンテキストを集めて成果物に展開する力」と「明確なコミュニケーション」に対応します（Business Insider Japan）。

育てる順序は、技術層と現場理解層を先に、対人層と引き渡し層を実案件の中で、が基本です。技術と現場理解は研修や演習で形にできますが、対人と引き渡しは実際の相手がいないと鍛えられません。

意外に見落とされるのが、引き渡しの層です。AWSのFDEは最終的に顧客が自力運用できる状態を目指しますし、Gartnerも出口戦略を最初に決めることを買い手に求めています。社内FDEにとっては、「社内の現場担当者が自分でAIを運用できる状態にする」ことが仕事の完成形です。

AIの周辺の仕組み（ルールファイル、プロンプト、ツール接続）を継続的に調整する技術は、技術層の中でもFDEの価値が出る部分です。詳しくはハーネスエンジニアリングとは？で整理しています。

候補者を決める前に、育てる範囲と外部に任せる範囲を分ける

職種そのものの定義はFDE（Forward Deployed Engineer）とは？、外部サービスの選び方はFDEサービスとは？に整理してあります。

社内の人材をどこまで育て、どこから外部FDEと組むか迷う場合は、お問い合わせフォームからFDE支援について相談できます。候補者が決まったら、次は育成の進め方です。

育成は「基礎→同行→主導」の3段階で進める

育成の段階は、基礎を揃える、経験者と一緒に現場に入る、自分で主導する、の3つです。期間は各社で異なるので、期間ではなく「次の段階に進む条件」で区切ります。

事業者が示す期間は4週間から36か月までバラバラ

公開されているFDE育成プログラムの期間は、事業者によって大きく違います。

事業者の例期間型
研修事業者A4週間動画教材と週次の演習。対象は実務2〜4年の中堅エンジニア
研修事業者B90日業務理解30日（コードなし）→AI活用30日→クライアントワーク30日
研修事業者C6〜12か月講義・演習・架空案件への適用で構成
コンサル事業者D18か月上級FDEと常時ペア→並走→独立主導
研修事業者E24〜36か月基礎→実案件参加→独立担当

すべて事業者の自社資料であり、公的な根拠や大手の公開情報はありません。共通しているのは、短期の研修で知識を入れ、実案件を経験しながら時間をかけて独り立ちさせる二段構えになっている点です。そのまま採用せず、自社の案件の難しさに応じて長さを決めてください。

段階ごとの到達条件を先に決める

期間の代わりに、次の段階へ進む条件を置きます。

  1. 基礎: AI開発の基本スキルを揃える。業務を分解して、AIで解く部分とそうでない部分を説明できる。この段階ではコードより業務理解が中心になる
  2. 同行: 経験者のFDEと同じ案件に入る。現場での聞き取り、設計、デモのうち1つ以上を、先輩のレビュー付きで自分で担当する
  3. 主導: 自分が主担当として、現場で課題を定義し、本番運用まで通す。先輩はレビューに回り、並行して後進のペア役を務め、手順を社内に残す

基礎の段階では、AI駆動開発研修のような研修でAIを使った開発の土台を揃えると、同行に入ったときに先輩の作業内容が理解できます。

各段階に進む判断は、本人の自己申告ではなく、成果物とレビューで行います。事業者のプログラムには、業務理解・AI活用・クライアントワークなどの評価軸を決め、全軸が一定水準以上で卒業とする設計例があります。この考え方は自社でも真似できます。

外部FDEとのペアが現実的な近道になる

社内に経験者がいない場合、「同行」の相手は外部のFDEになります。事業者の資料でも、外部FDEと伴走するハイブリッド型が現実的な形とされています。

ペアを組むときは、契約に知識移転を明記してください。成果物だけでなく、判断の理由と運用手順を社内の人に渡すことを成果に含めます。ベンダーFDEの調達では、成果物・知識移転・知的財産・移行責任を契約で定めることが推奨されています。

OJTを機能させる最大の条件は、同行の期間に候補者が「見ているだけ」にならないことです。毎回の案件で、設計、聞き取り、デモのいずれか1つは必ず本人に任せます。

案件ごとの回し方の型

同行期間の1案件は、次の流れで回すと、候補者の担当範囲が少しずつ広がります。

  1. 現場への聞き取りに同席し、候補者が議事を取って課題を言語化する
  2. 経験者が設計の方針を示し、候補者が設計案の下書きを作る
  3. 経験者がレビューし、判断の理由を口頭で説明する
  4. 候補者が実装し、現場にデモする。経験者は同席するが話さない
  5. 運用手順を候補者が書き、現場担当者が読んで動かせるか確認する

この型は案件を重ねるごとに、下書きを作る役から最初の案を出す役へ、デモに同席する役から単独で進める役へと、役割が移ります。主導の段階に入る目安は、1〜5を経験者の手出しなしで通せたかどうかです。

最初の題材は小さく、現場が近いものを選ぶ

最初の案件が大きすぎると失敗します。事業者が挙げる失敗パターンにも、学習時間の未確保と並んで、最初の題材の大きさがあります。現場の担当者がすぐ近くにいて、成果が1〜2か月で見える業務を選んでください。

同行の相手には当協会のFDE支援も使える

当協会は、導入直後のAIを現場に合わせて育てる段階で、AIエージェントの調整・最適化、システム障害時の保守対応、運用の伴走や質問対応といったFDE支援を、主に客先常駐の形で提供しています。社内FDE候補の「同行」の相手としても、この形態は使えます。実際の見え方はFDEの導入事例で確認できます。

評価とキャリアは工数ではなく成果で設計し、ウォッシングを避ける

FDEの評価は「どれだけ働いたか」ではなく、「現場がどれだけ自走できるようになったか」で行います。この設計を最初に決めないと、肩書きだけのFDEが量産されます。

評価指標は成果と自走度を軸にする

公開されている評価制度の事例は少なく、大手の人事制度は確認できていません。事業者の提案では、主要な指標を次の3つに絞る例があります。

指標内容
現場の満足度社内顧客（事業部門）からの評価を四半期ごとに取る
業務の改善幅導入前の基準値と、導入後の実績との差
自走化の達成度現場が自力で運用できる状態に近づいたか

工数で測ると、現場に長くいる人ほど評価され、引き渡しが遅れます。自走化を評価に入れておけば、FDEは自分が不要になる方向に動くので、構造的にウォッシングを避けられます。

評価者は、直属の上司だけでなく、案件を共にした社内顧客と先輩FDEも加えます。FDEの仕事は上司からは見えにくいからです。

処遇は専門職の等級として別に用意する

FDEの処遇相場は公的データがなく、事業者の推計にとどまります。国内の求人では年収1,000万〜1,500万円の提示例がありますが、社内転換で等級や報酬をどう設計するかの公開事例は確認できていません。

人事の方には、次の2点を提案します。まず、既存の開発職とは別の専門職の等級を用意し、FDE経験が昇格の条件に入るようにします。次に、管理職にならなくても上に進めるキャリアを明示します。育成した人材が、より高く買ってくれる転職先に流れるのを防ぐには、等級の見える化が最低限必要です。

配置先は客先ではなく自社の事業部門が基本になる

FDEは客先に入る職種ですが、社内FDEの「客先」は自社の事業部門です。営業部門や製造現場、カスタマーサポートなど、AIを使う側の部門に入り込みます。

開発部門に席を置いたまま月に数回だけ現場に顔を出す形では、FDEとして機能しません。一定期間は現場の近くに席を移すか、案件単位で現場に常駐する形が必要です。配置を決める責任者は人事ではなく、開発責任者と事業部門長の合意で決めてください。

肩書きだけのFDEを防ぐ設計

FDEの名称だけを導入し、実態は別物になる「FDEウォッシング」が指摘されています。ベンダー側ではプロフェッショナルサービスやソリューションエンジニアリング、AIコンサルをFDEとして売る動きがあります。社内でも、同じことが起きます。

PalantirでFDE育成を担当した人物は、FDEを営業エンジニアや売上目標を持つ営業職のように扱う企業への警鐘を鳴らしています。名称だけ導入し営業目標や個別案件への対応に偏ると、顧客の知見を製品に戻す仕組みが機能しなくなるからです（ビジネス+IT）。

社内FDEを育てるときは、次のチェックで防げます。

避けたい状態防ぐ設計
発注側が細かく指示し、指示待ちになる課題を定義する権限を本人に渡す
PoCを量産して本番に載らない各案件の最初に、本番運用する担当者と引き渡し条件を決める
現場の知見が開発側に戻らない製品・基盤の担当チームと定例を持つ。FDEをプロダクトチームの延長に置く
個別案件の対応だけで終わる繰り返し使える部品や手順を社内に残すことを成果に入れる
属人化する手順書とレビューの記録を残し、後進のペア役を決める

PoCの量産を直接検証した公的データは確認できていません。それでも、本番の担当者と引き渡し条件が最初に決まっていない案件が、検証止まりになりやすいのは構造の問題です。

よくある質問

Q. FDE人材の育成にはどれくらいの期間が必要ですか？

公的な標準期間はありません。事業者の資料では4週間から36か月までバラバラです。短期の研修で基礎を揃え、実案件で時間をかけて独り立ちさせる二段構えで考えてください。

Q. どの職種のエンジニアがFDEに転換しやすいですか？

実装力のあるソフトウェアエンジニアが出発点として有力です。社内SE、SRE、ソリューションアーキテクトも候補ですが、職種ごとに補う要素が違います。転換期間を示す公式データはありません。

Q. 外部FDEを使うなら、育成は不要ですか？

不要になりません。外部FDEが成果を出しても、受け取って運用し続ける社内の人材がいなければ、契約終了後に使われなくなります。ペアで知識移転を受ける形が現実的です。

Q. 非エンジニアでもFDEに育てられますか？

本番システムを実装できることがFDEの前提なので、まずは開発の土台づくりが必要です。業務を分解して自動化する社内FDEなら非エンジニアを候補にする設計もありますが、開発組織のFDEとは役割が異なります。

Q. 育成した人材が辞めるのを防ぐには？

専門職の等級を別に用意し、管理職にならなくても昇格できる道を示してください。評価を工数ではなく成果で行い、FDE経験が処遇に反映される状態を作ることが最低条件です。

まとめ

最初にやることは、候補者を1〜3名に絞り、次の3点を決めることです。誰とペアを組むか（社内の経験者か外部FDEか）、最初の題材は何か、評価に「現場の自走度」を入れるか。この3点が決まれば、育成は動き始めます。

育成は即戦力を作る手段ではありません。大手が採用や買収で急いでいる間に、自社の現場を知る人材を時間をかけて育てる、長い投資です。だからこそ、肩書きだけのFDEを作らない設計を最初から入れる必要があります。

まず試すなら、小さな業務で外部FDEと候補者のペアを1組作ること。これだけで、自社に足りない層が見えてきます。

社内エンジニアをFDEに育てる計画や、外部FDEとの組み方について相談したい方は、お問い合わせフォームからFDE支援について相談できます。

次に読みたい関連記事