2026年6月、Amazon Web Services（AWS）が新たに Forward Deployed Engineering （フォワード・デプロイド・エンジニア）組織を立ち上げ、そこに10億ドルを投じるというニュースが出ました。
AWSはこの組織を通じて、顧客企業の現場にAIエンジニアを送り込み、業務・エンジニアリング・セキュリティチームと一緒に、実際に使えるAIシステムを構築していくと説明しています。
Reutersも、AWSが「forward-deployed engineers」と呼ばれるAIエンジニアを顧客チームに直接組み込み、45日程度の期間でAI導入を加速させる新部門を作ると報じています。初期顧客にはNBAやリコーが含まれるとのことです。
ですが、最近よく思うのは、
FDEとは本当に新しい概念なのか？
ということです。
FDEという言葉だけを見ると、いかにもAI時代の新しい職種に見えます。しかし、実際にやっていることを分解すると、従来のSIer、SES、業務コンサル、プリセールス、PM、カスタマーサクセス、受託開発とかなり重なる部分があります。
顧客の業務を理解する。
課題を整理する。
要件を定義する。
システムを設計する。
実装する。
運用に乗せる。
現場に定着させる。
こう書くと、昔からSIerや受託開発会社がやってきたことと、それほど大きく変わらないようにも見えます。
では、なぜ今あらためてFDEが注目されているのでしょうか。僕もよくわかっていないので、今日はそこを掘り下げて考えてみたいと思います。
FDEとは何か？
FDEは、一般的には Forward Deployed Engineer （フォワード・デプロイド・エンジニア）の略です。
直訳すると「前線配置されたエンジニア」のような意味になります。もともとはPalantirなどの企業でよく知られるようになった考え方で、エンジニアが顧客の現場に深く入り込み、顧客の課題を理解しながら、実際に動くシステムを作っていく役割です。WSJは、AIスタートアップがFDEを採用する動きを「新しくて古い秘密兵器」と表現し、企業が生成AIを実際に導入するには、顧客現場に入り込んでカスタマイズする人材が必要になっていると報じています。
このFDEがAI時代に再注目されている理由は、AIが「売って終わり」のプロダクトではないからです。
AIはデモアプリだけなら簡単に作れます。
チャットボットも作れます。
議事録要約もできます。
メール分類もできます。
社内文書検索もできます。
しかし、実際に企業の業務に入れようとすると、一気に難しくなります。
どの業務にAIを入れるのか。
どのデータを読ませるのか。
権限管理はどうするのか。
社内ルール上、どこまでAIに任せてよいのか。
人間の承認はどこに挟むのか。
間違った場合、誰が責任を持つのか。
現場の人が本当に使うのか。
既存システムとどうつなぐのか。
ここを解決しないと、AIは業務に入りません。
つまり、AI時代に必要なのは、単にAIモデルを提供する会社ではなく、AIを企業の現場業務に埋め込む人たちです。その役割として、FDEが注目されているのだと思います。
FDEはSESやSIerと何が違うのか
ここで当然、疑問が出ます。
FDEは、結局SESやSIerと何が違うのでしょうか。
正直に言うと、かなり似ています。
顧客先に入って、顧客の業務を理解して、システムを作って、運用まで見る。これだけを見れば、従来のSESやSIer、受託開発と大きな違いはありません。
特に日本のIT業界では、昔から「顧客の現場に入り込んで業務システムを作る」という仕事はありました。業務コンサルがいて、PMがいて、エンジニアがいて、要件定義をして、設計して、開発して、運用する。そういうプロジェクトは珍しくありません。
ではFDEの違いは何か。
よく言われる違いは、自社プロダクトを持つ会社が、そのプロダクトを顧客企業に深く導入するためにエンジニアを送り込むという点です。
SESは基本的には「人の稼働」を提供します。
SIerは「個別システムの構築」を提供します。
一方でFDEは、「自社プロダクトや自社AI基盤を、顧客の業務に深く適用する」役割で、のように言われています。
ただし、ここにも疑問があります。
自社プロダクトとは何でしょうか。
Salesforceでしょうか。kintoneでしょうか。
OpenAIやAnthropicのAIモデルでしょうか。
Microsoft Copilot StudioやGoogle Gemini Enterpriseのようなエージェント基盤でしょうか。
確かに、これらは自社プロダクトです。しかし、企業の業務に本当に合わせようとすれば、結局かなりカスタマイズが必要になります。
Salesforceを導入するとしても、そのまま使える会社は多くありません。顧客管理の項目、営業フロー、承認フロー、権限、外部システム連携、帳票、通知、分析画面などを作り込む必要があります。kintoneでも同じです。AIエージェントでも同じです。
そうなると、これはもう「プロダクトを売っている」というより、プロダクトを土台にした受託開発に近いのではないか、という疑問が出てきます。
じゃあ、やっぱり、今までのSESとかと変わんないじゃん、となりそうです。今までとの違いは自分でプログラミングするか、AI使ってプログラミングするかの違い？と。
「SaaSを売る」から「専用システムを作る」へ戻っているのではないか
従来のSaaSは、基本的には汎用品でした。
多くの会社に共通する業務を抽象化し、同じ画面、同じ機能、同じ料金体系で提供する。顧客はSaaSに業務を合わせる。これが従来型SaaSの基本的な考え方でした。
しかし、AI時代の業務システムでは、この考え方が少し変わってきているように感じます。
AIは、会社ごとの業務文脈に大きく依存します。
同じ「問い合わせ対応AI」でも、会社によって対応内容は違います。
同じ「請求書処理AI」でも、会社によって承認ルールは違います。
同じ「営業支援AI」でも、会社によって商談の進め方は違います。
同じ「社内文書検索AI」でも、会社によって文書の置き場所も、権限も、言葉の使い方も違います。
つまり、AIは汎用機能でありながら、実際にはかなり専用化しないと価値が出にくいのです。
ここで起きているのは、もしかすると「SaaSから受託開発への揺り戻し」かもしれません。
ただし、昔ながらの受託開発にそのまま戻るわけではありません。
昔の受託開発は、ゼロから作るため高額で、時間もかかりました。
一方で今は、AI、ノーコード、ローコード、既存SaaS、API、クラウド基盤を組み合わせることで、専用システムの構築コストが下がっています。
つまり、これから増えるのは、
汎用SaaSでもない。
完全スクラッチの受託開発でもない。
共通基盤を使いながら、会社ごとに専用構築するモデル。
ではないかと考えています。
私たちはこれを、仮に その企業向けの「専用SaaS」 と呼んでいます。
専用SaaSとは何か
専用SaaSという言葉は、一般的に定義された用語ではありません。弊社が考えている概念です。
意味としては、会社ごとに専用で構築されるが、毎回ゼロから作るわけではなく、共通基盤・共通部品・導入ノウハウ・運用体制を使って構築される業務システムです。
たとえば弊社が考えている「AI事務員」は、AIが事務員の代わりに様々な業務を行うものですが、完成済みのSaaSをそのまま売るものではありません。
「はい、これがAI〇〇サービスです。月額いくらです。ログインして使ってください」
というものではない。
なぜなら、会社ごとに事務作業は違うからです。
ある会社では、メールの一次分類が重要かもしれない。
ある会社では、見積書作成が重要かもしれない。
ある会社では、請求書処理が重要かもしれない。
ある会社では、Slack通知やGoogle Drive検索が重要かもしれない。
ある会社では、freeeやkintoneとの連携が重要かもしれない。
ある会社では、議事録からタスク化することが重要かもしれない。
このように、会社ごとに求められる仕事は違います。
だからこそ、弊社が提供すべきものは「完成済みAI事務員」ではありません。
提供すべきものは、
業務分析ノウハウ
導入ノウハウ
AI活用ノウハウ
業務改善の進め方
共通のAI部品
既存SaaSとの連携パターン
運用設計
人間の承認フロー設計
導入後の改善体制
です。
顧客から見える成果物は、会社ごとの専用AI事務員です。
しかし、裏側には弊社の共通基盤やノウハウがある。
この構造が重要です。
毎回作り直すなら、ただの受託開発ではないか？
ここも大事な論点です。
会社ごとに専用AIサービス、専用SaaSを作るなら、それはただの受託開発ではないか。
そう言われれば、半分はその通りです。
実際、顧客ごとの業務に合わせて設計し、実装し、運用するのであれば、受託開発的な要素はあります。
ただし、違いは「毎回ゼロから作るかどうか」です。
もし毎回ゼロからヒアリングし、ゼロから設計し、ゼロから実装し、ゼロから運用設計をしていたら、それは従来型の受託開発です。
しかし、案件を重ねるごとに、
よくある業務パターン
よくある失敗パターン
よくあるAI活用パターン
よくある連携パターン
よくある承認フロー
よくある現場定着の壁
よくある費用対効果の出し方
が蓄積されていけば、次の案件はより速く、より安く、より品質高く提供できます。
つまり、専用SaaSモデルで重要なのは、個別対応をしながら、裏側で共通資産を増やしていくことです。
これはFDEの考え方とも近いです。
FDEも、顧客現場に入り込んで個別に対応します。しかし、そこで得た知見を自社プロダクトや導入方法に戻していく。そうすることで、次の顧客への導入が速くなる。プロダクトも強くなる。
弊社の専用SaaS・AI事務員でも同じです。
A社で作ったメール分類の仕組み。
B社で作った議事録からタスク化する仕組み。
C社で作った請求書チェックの仕組み。
D社で作ったfreee連携の仕組み。
E社で作ったSlack通知の仕組み。
これらを単発の納品物で終わらせるのではなく、弊社内のテンプレート、部品、設計パターン、運用ノウハウとして蓄積していく。
そうすれば、会社ごとに専用構築しながらも、毎回ゼロから作るわけではないモデルになります。
FDEは「コンサル」x「エンジニア」
おそらく上流のコンサルティングスキルと、エンジニアのシステム開発力・技術力の両方が求められるのがFDEだと思います。
従来型のコンサルは、分析・提案だけして実際のシステム構築はしない。
一方、従来型のエンジニアは、技術力は高いけれども業務改善の提案はしてくれない。
その両方を持った人が、AIを使いながら業務分析し・提案・構築まで全部やる。これがFDEかと思います。
とするならば、一人でそれが全部できる人はそうそう居ない。。。
となると、やはり従来型のSIer、受託開発会社とコンサル会社が混ざったようなチームになりそうですね。
弊社はどう進めるのか
弊社では、今後「AI事務員」という考え方を軸に、企業ごとの業務に合わせた専用AIシステムの構築を進めていきたいと考えています。
ただし、完成済みのAI事務員をそのまま売るのではありません。
会社ごとに業務は違います。
課題も違います。
既存ツールも違います。
人の動き方も違います。
AIに任せてよい範囲も違います。
つまり、弊社が目指すのは、
毎回ゼロから作る受託開発ではありません。
完成済みSaaSを無理に当てはめることでもありません。
会社ごとの業務に合わせて専用構築しながら、裏側では共通部品とノウハウを蓄積していくモデルです。
これが、弊社の考えるAI時代の進め方です。
まとめ
AWSがFDEに10億ドルを投じるというニュースがあった。
AI時代の企業導入、プロダクトを売るだけでは足りないということを示唆
AIは、企業の業務に深く入り込んで初めて価値を出す。
FDEはその役割につけた名前かも。
従来のSIer、受託開発、業務コンサル、PM、SESと重なる部分も多い。
要は、FDEはコンサルできてエンジニアもできる人？
受託開発でもSaaSでもなく、共通部品とノウハウを活かして専用構築