By Jay Revels, Ichizoku株式会社 CEO（読了目安時間：約10分）
本記事は、SIerが自社エンジニアをFDE（Forward Deployed Engineer）に育てるための5段階のロードマップと、研修を選ぶときの確認ポイントを解説します。
重要なポイント
- SIerが持つ構造的な優位性：日本ではICT人材の72.0%がICT企業に所属し、納品経験と顧客との関係を持つSIerがFDEを担いやすい構造
- 成果物で締める5つのステップ：課題発見から運用・事業化までの5段階を、それぞれ顧客に提出できる成果物で締めくくる育成設計
- 閉域環境と継続評価への対応：閉域網へのデプロイと、モデル更新後も精度を保つ継続的な評価が、デモで終わるか事業になるかの分かれ目
- FDE研修を選ぶ7つの確認ポイント：実案件の素材、課題発見、評価、閉域対応、ベンダー非依存、成果物、通常業務との両立を見る選定基準
4週間の「FDE育成プログラム」の第1回講義動画（約5分）を無料で公開しています。
研修の中身を確かめる材料としてご覧ください。
結論から言うと
FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア）とは、顧客の現場に入り込み、本当の課題を見極め、実際に動く小さな仕組みを素早く作り、顧客自身の数字で効果を示したうえで、本番運用に乗るまで伴走するエンジニアです。
SIerがFDEを育成するには、すでに開発・納品の経験があるエンジニアを①現場での課題発見、②Build-to-Learnによる検証、③ベンダーに依存しないAIエンジニアリング、④エンタープライズ環境へのデプロイ、⑤運用と事業化という5段階で育てていくのが現実的です。どの段階も「そのまま顧客に提出できる成果物」で締めくくることがポイントです。
FDE（フォワードデプロイドエンジニア）とは
【定義】
FDEとは、特定の顧客において、テクノロジーが測定可能な成果を生むところまで責任を持つソフトウェアエンジニアです。仕様書を渡して終わりにするのではなく、顧客のチームの中に入って仕事をします。
この職種を広く知られるようにした企業の一つがPalantirです。同社は違いを、通常のプロダクトエンジニアは「多くの顧客が使う一つの機能」を作り、FDEは「一つの顧客のために多くの機能」を実現する、と説明しています。（Palantir Blog）
生成AIの案件では、この違いがこれまで以上に重要になります。難しいのはモデルのAPIそのものではありません。プロジェクトが止まるのは、APIと業務の間にある部分です。管理者が決まっていないデータや、誰も想定していなかったセキュリティ審査がその典型です。
SIerのSEとFDEは何が違うのか
SIerの開発案件では、確定した要件をもとに設計・開発し、納品するのが一般的です。
FDEは、より早い段階から関わり、長く伴走します。何を作るべきかを顧客と一緒に検討し、そのためにまず試作品を作ってみることも少なくありません。成果はモデルの精度のスコアだけでなく、リードタイム、手戻り率、一次解決率といった業務指標に基づいて評価します。そして、開発したものが現場に定着するまで関わり続けます。
違いはコーディング力ではありません。私たちの経験では、FDEを目指すエンジニアに足りないのはほぼ例外なくコード以外の部分です。課題のヒアリング、信頼関係づくり、スコープの管理、社内調整、そしてモデルの指標を業務の指標に置き換えて説明する力です。
なぜSIerこそFDEチームを持つべきなのか
日本では、エンジニアの多くがベンダー側に所属しています。総務省の令和元年版情報通信白書が引用するIPAのデータによると、2015年時点でICT人材のうちICT企業に所属する人の割合は、日本は72.0%、米国は34.6%でした。（総務省 令和元年版 情報通信白書）この構造の是非はともかく、日本企業向けにAIシステムを作れる人材の多くはSIerにいるということです。
つまりSIerは、FDEという仕事において構造的に有利な位置にいます。納品経験のあるエンジニアがいて、NDAや入館手続きを含む顧客との関係があり、日本企業の稟議や承認が実際にどのように進むかを、経験から理解しています。
これから必要になるのは、AI時代でも成り立つビジネスモデルです。AIエージェントがコードの多くを書けるようになれば、人月単価での請求は説明することが難しくなります。先日出展したAI-PAX大阪でも、あるSIerの方が「人月のビジネスはもう続かない。エンジニアの役割そのものが根本から変わりつつある」という趣旨のお話をされていました。
ただ、これは悲観することではなく、提供するサービスを変えるきっかけだと私は考えています。大手ベンダーのAIプラットフォームも、複雑な社内システムとつなぎ、セキュリティ審査を通し、効果を測定し、モデルが更新された後も精度を保つ人がいなければ機能しません。そこで求められるのは、システム連携と判断力、そして結果への責任です。顧客はそこに対価を払いますし、簡単には自動化できません。
こうしたプラットフォームと組み合わせてFDEやインテグレーションのサービスを提供できるSIerは「このお客様の環境でプラットフォームが動いているのはこの会社のおかげだ」という存在になり、商流から外されることはありません。
AI-PAX大阪で、SIerと事業会社から聞いたこと
2026年10月、私たちはAI-PAX大阪 2026に出展しました。2日間で、製造業、大学、オーナー企業、社内情報システム部門、そして複数のSIerやコンサルティング企業など、20社の方々とお話ししました。繰り返し出てきたテーマがいくつかあり、それが以下のロードマップの土台になっています。
AI活用が「チャット止まり」になっている
ほとんどの企業が、すでにCopilot、ChatGPT、Gemini、Claudeのいずれかを導入していました。課題は、下書きまではAIで作れても、肝心の業務は結局手作業で完了させていることです。ある企業の方は、「社員がAIツール間で情報を運ぶ『運送屋さん』になっている」とおっしゃっていました。例えば、議事録をチケットに転記したり、システム間でファイルを手動で移動させたりする作業です。
この職種を広く知られるようにした企業の一つがPalantirです。同社は違いを、通常のプロダクトエンジニアは「多くの顧客が使う一つの機能」を作り、FDEは「一つの顧客のために多くの機能」を実現する、と説明しています。（Palantir Blog）
SIerは「FDEを学ぶ」だけでなく「FDEを売りたい」
お会いしたSIerの方々が求めていたのは、AIリテラシー研修ではありませんでした。ある企業は、約10名のエンジニアがいる部署をFDEチームに育てたいと考えていました。社内研修は基礎的な内容が中心のため、要件定義書や設計書、失敗事例など、実案件の素材を使った研修を求めていました。別のSIerからは、自社のFDE案件に私たちの支援の一部を組み込めないか、というご相談もありました。また、あるコンサルティング企業は、自社の支援は設計フェーズまでだが、顧客は今やエージェントが稼働するところまで任せたいと考えている、というお話もありました。
エンジニアはすでに手一杯
あるSIerでは、エンジニアの多くが客先に常駐しているため、研修に時間を割けるメンバーが限られているとのことでした。別の企業からは、通常業務と両立できるよう「細く長く」進めたいという声もありました。全員が業務を離れて参加することを前提にしたロードマップでは、継続が難しくなります。
閉域環境が前提
セキュリティの話題は約10社との会話で挙がり、最初の質問になることも少なくありませんでした。社外に一切出せないデータ、閉域のAzure環境、ネットワーク認証の制約で使えるAPIが限られる環境、LLMの前後で個人情報をどうマスキングするか、といった内容です。オープンなクラウドのサンドボックスにしかデプロイできないFDEでは、こうした企業の役には立ちません。
リリース後、誰が精度を守るのか
あるSIerからは、基盤モデルが変わったときにどうテストするのか、品質をどう継続的に評価するのか、と具体的に聞かれました。ハルシネーションを心配する顧客に対して、こうした問いに答えられるかどうかが、デモで終わるか、事業になるかの分かれ目となります。
最後に、マインドセットについて最も印象に残ったのは、ある企業の開発責任者の方がおっしゃった「エンジニアの役割は『ハンドルを握る人』から『ブレーキだけを踏む人』に変わりつつある」という言葉です。AIが作業の大半を担い、自動チェックがより多くのミスを拾い、人は承認に専念する。FDE研修では、ツールの使い方だけでなく、この意識の転換まで扱う必要があります。
SIerのためのFDE育成ロードマップ：5つのステップ
【定義】
FDE育成ロードマップとは、ソフトウェアの開発・納品経験があるエンジニアを、顧客の課題を見極め、小さな開発で価値を証明し、顧客の本番環境でAIシステムを運用できるチームへと段階的に育てる計画です。各段階の最後に、顧客に提出できる成果物を作成します。
第1段階に入る前に、次の3点を決めておきます。まず、少人数のチームを一つ編成すること。お会いした2社の企業は、最初は約10名から始めたいというお話がありました。次に、実際のユースケースを一つ選ぶこと。そして、成功の定義と現状のベースラインを書き出しておくことです。ベースラインがないと、次の予算を経営層に相談する段階で、印象論の議論になってしまいます。
1. 現場での課題発見
機能要望ではなく事実を聞き出すヒアリングの方法を学び、顧客が「求めていること」と「実際に起きている問題」を切り分けます。「AIの精度が低い」は症状にすぎず、根本原因はたいていデータ、業務プロセス、オーナーシップのいずれかにあります。データがどこにあり、誰が管理し、どの時点のものか、誰が閲覧でき、どこに個人情報が含まれるかを棚卸しします。閉域網、法務、監査は障害ではなく設計の前提条件として扱います。さらに、実際に意思決定しているのは誰かを把握します。日本企業では、それが肩書き上の決裁者とは限りません。
成果物： ヒアリング記録、1枚の課題診断書、データの実態調査、意思決定ルートのマップをまとめた「ディスカバリーパッケージ」
2. Build-to-Learnによる検証
Build-to-Learnとは、プロトタイプを最終システムの縮小版ではなく、仮説を検証するための実験として扱う考え方です。仮説、最小構成、使用データ、成功基準、中止基準をまとめた「1週間の実験ブリーフ」を作成します。デモは顧客自身のデータで行い、毎回のデモを要件を詰める場として活用します。そのうえで、精度・レイテンシ・コストを事業責任者が重視する業務上の指標に結びつける「メトリクスラダー」を作ります。
成果物： MVP実験ブリーフ、デモ台本、メトリクスラダー、定着化プラン
3. ベンダーに依存しないAIエンジニアリング
顧客はOpenAI、Anthropic、Google、Azure、AWS、オンプレミスなど、それぞれの環境を持っています。そのため、特定の製品ではなく設計パターンを学びます。ツール呼び出し、エージェントの設計（エージェントより単純なワークフローの方が適している場面の見極めも含む）、連携の標準としてのMCP、検索（RAG）の設計、評価です。中でも評価に最も時間を割きます。実際の利用データから評価セットを作ること、テキストの出力だけでなくツールの選び方やエージェントの挙動も評価すること、プロンプトインジェクションへの対策、システムへの書き込み前に人間の承認を挟むべき箇所の判断などです。
成果物： 業務API一つを対象にしたエージェント連携設計書（ツールスキーマ、連携方式、評価セット、安全対策を含む）
4. エンタープライズ環境へのデプロイ
顧客環境への導入やセキュリティ審査への対応は、SIerがこれまで培ってきた経験を活かせる領域です。顧客の環境にデプロイする練習を行います。コンテナ、最小限のCI/CDパイプライン、閉域網やプライベート接続の構成パターン、シークレット管理などです。あわせて、モデルとツールのすべての呼び出しのトレース、ユースケースごとのコストとレイテンシの監視を組み込み、セキュリティ審査を通すための資料を整えます。権限設計、データの境界、監査ログ、プロンプトやモデルの変更管理、段階的なリリース計画などです。
成果物： 監視設計を含むデプロイ・運用計画書、セキュリティ審査用の資料一式
5. 運用と事業化
SIerのビジネスモデルが変わるのは、本番運用の段階です。モデルが更新されても精度を維持し、定期的に品質を再評価し、その結果を業務の言葉で報告します。また、一社の案件で得たものを、設計パターン、評価セット、プレイブックといった次の顧客にも使える資産に変えていきます。この段階は、エンジニア個人よりも会社としての判断が問われます。「構築して引き渡す」のか、「継続的に運用する」のか、あるいはその両方を提供するのかを決めます。
成果物： 顧客の経営層向け運用レポート、次の案件に向けた社内プレイブック
ロードマップ早見表
| 段階 | 重点 | 終了時に できるようになること | 顧客に提出できる成果物 | 次に進む判断基準 |
|---|---|---|---|---|
| 準備 | スコープ設定 | チーム・ユースケース・ベースラインを一つずつ決める | 成功基準、ベースライン | 経営層が成功基準を承認 |
| 1. 現場での課題発見 | 課題発見・診断 | 本当の課題と意思決定者を特定する | ディスカバリーパッケージ | 顧客が診断内容に合意 |
| 2. Build-to-Learnによる検証 | 実験・価値の証明 | 1週間の実験を実施し、業務へのインパクトを示す | MVP実験ブリーフ、デモ、メトリクスラダー | 指標の改善を確認、または中止を明確に判断 |
| 3. ベンダーに依存しないAIエンジニアリング | エージェント・検索・評価 | ガードレールを備えたベンダー非依存のエージェントを設計する | エージェント連携設計書 | 評価セットが合意した基準を満たす |
| 4. エンタープライズ環境へのデプロイ | デプロイ・監視 | 顧客のセキュリティ境界内で稼働させる | デプロイ・運用計画書、セキュリティ資料 | セキュリティ審査を通過 |
| 5. 運用と事業化 | 精度の維持・サービス化 | 精度を保ちながら次の案件につなげる | 運用レポート、社内プレイブック | 継続契約、または2件目のユースケース |
SIerがFDE研修を選ぶときによくある失敗
最新ツールを学べることを重視してしまう
研修の初週が最新エージェントフレームワークの紹介で終わってしまう場合、育つのはFDEではなく、自社サービス向けのエンジニアです。ツールは数か月で入れ替わりますが、顧客の課題を見極める力は変わりません。
ゼロから作る演習だけの研修を選んでしまう
図面から提案書を作るパイプラインや、自社で構築した管理会計ポータルなどです。こうした方々に必要なのは、新しいアイデアではなく、それを本番運用に耐えうる水準に引き上げる支援です。実際の案件では、顧客がすでに作った仕組みを活かしながら改善する場面が多くあります。ゼロから作る演習しかない研修では、こうした場面に対応できません。
評価を扱わない研修を選んでしまう
AIツールが期待どおりに動かず、苦い経験をした企業は少なくありません。FDEには、機能の多さを並べるより、評価・監視・コスト管理から話を始める力が求められます。評価の方法を学ばない研修では、顧客の信頼を得られるFDEは育ちません。
FDE研修の選び方：比較・検討時に確認したい7つのポイント
FDE研修を比較・検討する際は、次の7点を確認することをおすすめします。多くの項目に明確に答えられない研修は、FDEの仕事ではなく、ツールの使い方を教えている可能性があります。
1. 実案件の素材を使っているか
公開データを使った簡単なデモだけでなく、実際の案件の要件定義書、設計書、失敗事例を教材にしているかを確認します。
2. 開発だけでなく、課題発見を教えているか
顧客へのヒアリング、本当の課題の見極め、モデルの指標を業務の指標に置き換えて説明する力まで練習できるかが重要です。
3. 評価が中核のテーマになっているか
実際の利用データから評価セットを作る方法、テキストの出力だけでなくエージェントの挙動も評価する方法、基盤モデルが変わったときの再テストの進め方を扱っているかを確認します。
4. 閉域網とセキュリティ審査に対応しているか
顧客のセキュリティ境界内へのデプロイ、データの境界設計、個人情報の取り扱い、監査ログが補足ではなく正式な内容として扱われているかを確認します。
5. 特定ベンダーに依存していないか
顧客が使うクラウドやモデルはさまざまです。OpenAI、Azure、AWS、Google、オンプレミスのどれにも応用できる設計パターンを学べるかを確認します。
6. 各モジュールが顧客に提出できる成果物で終わるか
ディスカバリーパッケージ、実験ブリーフ、セキュリティ審査資料などの成果物は、研修の確認テストの点数よりも、受講者の実力を正しく示します。
7. 通常業務と並行して続けられるか
客先に常駐しているメンバーも含め、自社のエンジニアの働き方に、研修の形式、ペース、受講の前提条件が合っているかを確認します。
IchizokuのFDE育成プログラムの考え方
IchizokuのFDE育成プログラムは、Head of Client Solutions and AI InnovationのFrancisco Soares（フランシスコ・ソアレス）が設計しました。Franciscoは奈良先端科学技術大学院大学（NAIST）で自然言語処理の修士号を取得し、Google、サイバーエージェント、Unityで経験を積んできました。
本プログラムは研究と現場、両方の経験をもとにしたカリキュラムです。課題発見からエンタープライズ環境へのデプロイまでを扱う4つのモジュールで構成され、各モジュールの最後に、顧客に提出できる成果物を作る実践演習があります。対象は、顧客向け開発の経験がおおむね2〜4年ある中堅エンジニアです。AIの専門知識は前提とせず、特定ベンダーに依存しない設計にしています。
標準的な受講期間は4週間です。4つのモジュールで、約88本の短い動画（合計約7時間20分）を視聴しながら進めます。お客様にはこの4週間を基本としてご提案していますが、条件に応じたカスタマイズも可能です。AI-PAX大阪 2026で伺ったご要望のように、自社の案件素材を使った研修や客先での業務と両立できる受講ペースへの調整などは、個別にご相談ください。
このプログラムは、教室ではなく実際の開発現場から生まれました。私たちはこれまでに20件以上のAIエージェント導入に携わってきました。その一つにソフトバンクグループの子会社での案件があります。AIエージェントの精度向上に取り組み、チャンキングやデータのベクトル化手法のベンチマーク、LLMアプリケーションのデータベース層の設計などを担当しました。こうした検索に関わる地道な作業こそが、エージェントの信頼性を左右します。これがロードマップの第3段階「ベンダーに依存しないAIエンジニアリング」で扱う内容です。
AI-PAX大阪 2026で伺ったお話は、すでにプログラムの内容に反映し始めています。特に、制約の多い環境への対応と、通常業務と並行して続けられるペース設計です。自社の事業の中でFDEをどう位置づけるかを検討されているSIerの方は、ぜひお気軽にご相談ください。まずは「これまでに何を作ってきたか」をお伺いするところから始めます。
4週間の「FDE育成プログラム」の第1回講義動画（約5分）を無料で公開しています。
【FAQ】よくある質問
1. FDE（フォワードデプロイドエンジニア）とは何ですか？
FDEとは、顧客の環境に入り、測定可能な事業成果をテクノロジーで実現するエンジニアです。本当の課題を見極め、実際に動く小さな仕組みを素早く作り、顧客のデータで効果を証明し、本番運用まで支援します。
2. FDEとSIerの一般的なエンジニアは何が違いますか？
SIerの開発案件では、確定した要件をもとに設計・開発し、納品するのが一般的です。FDEはヒアリングや短期間の実験を通じて要件づくりから関わり、成果を業務の指標で測り、定着・運用まで伴走します。
3. SIerのエンジニアはFDEになれますか？
なれます。SIerのエンジニアこそ、FDEに向いています。顧客向けのアプリケーションを納品した経験があるエンジニアは、技術的な土台をすでに持っています。加えて必要なのは、課題発見、Build-to-Learn型の進め方、評価、エンタープライズのセキュリティ要件下でのデプロイのスキルです。
4. FDE研修の受講者に、AIの深い専門知識は必要ですか？
必要ありません。それよりも、しっかりとしたエンジニアリングの経験が重要です。ツール呼び出し、エージェント、MCP、検索（RAG）、評価といったパターンは、AIを専門にしてこなかった経験豊富なエンジニアでも習得できます。
5. FDE研修の期間はどのくらいですか？
IchizokuのFDE育成プログラムは、標準で4週間です。4つのモジュールで構成され、各モジュールの最後に実践演習があり、約88本の短い動画（合計約7時間20分）で学びます。お客様には4週間を基本としてご提案していますが、条件に応じたカスタマイズも可能です。
6. AIによってSIerのビジネスは奪われますか？
人月型の請求モデルは、確実に見直しを迫られます。一方で、AIシステムの連携、評価、セキュリティ審査、継続的な運用といった新たな需要も生まれています。AIプラットフォームと組み合わせてFDEサービスを提供できるSIerは、その需要を取り込めます。
7. SIerはFDE研修をどのように始めればよいですか？
小さく始めることをおすすめします。約10名のチームを編成し、実際のユースケースを一つ選び、研修開始前に成功基準とベースラインを経営層と合意しておきます。そのうえで、成果を見ながら広げていきます。
8. 閉域網や厳しいセキュリティ要件には、FDE研修でどう対応しますか？
最初のヒアリングの段階から、セキュリティ上の制約を設計の前提条件として扱います。そのうえで、閉域網へのデプロイ、データの境界設計、監査ログ、個人情報の取り扱い、セキュリティ審査への対応までカバーします。
著者について
Jay Revels（ジェイ・レベルズ）。東京を拠点とするAIコンサルティング・FDE研修企業、Ichizoku株式会社 CEO & Founder。Marin SoftwareやAdobe Japanなど、日本のテクノロジー業界で20年以上にわたり経営に携わってきました。Ichizokuは日本企業向けAIエージェントの開発・導入支援、AIエージェントを本番環境で運用できるエンジニアチームの育成を行っています。