FDEという言葉を、この数か月で何度も目にした人がいると思います。AWSは2026年6月に、Forward Deployed Engineeringの専任組織を作るために10億ドルを投じると発表し、10月1日にはパートナー向けの育成の経路を公開しました。Anthropicは10月2日に、人材育成に1億ドルを投じて2027年末までに1万人のFrontier Deployed Engineerを育てると発表しました。そしてGartnerは9月29日に、こう予測しました。企業の7割が、2028年までに、ベンダーのFDEで作られたAIエージェントの利用をやめる。

当社はFDE型支援を提供する側です。社外の推進チームとして会社の中に入り、業務にAIを組み込んで動く状態まで作り、運用を社内に残して離れる。これをFDE型支援と呼んで売っています。だから、この予測は他人事ではありません。利用をやめる7割の側に顧客を入れないために何をしているか、Gartnerの言葉を借りて点検するのが、この記事の目的です。

読者は、FDEという名前で支援を受けることを検討している経営者と、社内でAI・DXを任されている担当者です。FDEと内製とSIerの違いは前の記事社外のAI推進チームという選択肢。内製・SIer・FDEの選び方に書きました。この記事はその続きで、FDE型を選んだあとに、頼む側が何を確かめるべきかを書きます。

結論を先に書きます。

  1. Gartnerは、FDEの失敗は技術より先に構造で起きる、と言っています。 知識が社内に移らない、費用が続かない、出口が決まっていない。この3つは、契約の前に決めておくことができ、支援の途中と移行のときに進み具合を確かめられます。だから、頼む側の確かめ方が有効です
  2. 真のFDEの3原則は、どれも頼む側の行動に翻訳できます。 製品の専門知識や環境との統合が要る問題に使う、社内の専門家と利用者に知識を移す、出口を最初から決める。当社はこの3つを、最初の質問、毎週同じ窓口、数えられる卒業の条件として設計しています
  3. 出口の条件を自社で書けるようになることが、インハウス経営の最初の一歩です。 インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）は、支援を受けながらでも、受けずにでも、出口の条件を自社の言葉で書けるかどうかで決まります

Gartnerは何を予測したか

出どころを先に書きます。Gartnerは2026年9月29日に、「Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028」という題のプレスリリースを出しました。当社はGartnerの原文を直接は取得できず、Publickeyが2026年10月7日に出した記事と、CX Todayが10月5日に出した記事で内容を確かめました。確認日は2026年10月13日です。

予測の中身は3つです。

  • 企業の70%が、2028年までに、ベンダーのFDEで作られたAIエージェントの利用をやめる。 7割は企業の割合で、作られたAIの個数の割合ではありません
  • 顧客から繰り返し寄せられる要望をベンダーの中核製品に反映できるFDEの案件は、2028年までに20%未満にとどまる
  • FDEウォッシングのリスクが高まる。 普通のコンサルティングサービスを、FDEという名前で売ることを指します

Gartnerのシニアディレクターアナリストである Mukul Saha 氏の言葉として、Publickeyはこう紹介しています。多くのベンダーが、製品導入、プロフェッショナルサービス、ソリューションエンジニアリング、AIコンサルティングの呼び名として「フォワードデプロイド」を使っている。その結果、本来の定義に合わない取り組みが増え、技術面で失敗する前に、構造面で失敗する。CX Todayはこの部分を、"FDE engagements often fail structurally before they fail technically." と原文で引いています。

ここで言うFDEの本来の意味も確認しておきます。Publickeyの説明では、ソフトウェアベンダーのエンジニアが顧客企業の現場に入り、顧客固有の課題に合わせて、AIによるサービスやソフトウェアを共同開発する開発モデルです。Palantirがこの職種を先駆けて設けたと自社の採用ページで説明していて、AnthropicなどのAI企業でも職種名として使われています。

そしてGartnerは、真のFDEの3原則を挙げました。Publickeyの訳を、当社の言葉で短くします。

  1. 製品への深い専門知識、速い適応、またはベンダーの技術と運用環境の密接な統合を必要とする問題に、FDEを使う
  2. FDEを社内の業務の専門家、技術者、利用者の中に入れて、重要な知識を共有し、作業に反映させる
  3. 出口戦略を最初から明確にしておく

CX Todayは、これを頼む側の行動として3つに言い換えています。契約前に範囲を決めること、納品の期間中にベンダーのエンジニアを社内チームに組み込んで知識を実際に移すこと、社内チームの準備ができていないからといって関係を延長せず、出口の計画を実行すること。同じ記事の筆者は、2年以内に7割が手放すという予測を「それは言い過ぎかもしれない」と書いてもいます。数字の確かさはGartnerの調査の中身次第なので、当社は7割という数字そのものより、3原則のほうを重く読みました。

なぜ技術より先に、構造で失敗するのか

Gartnerの言葉で当社がいちばん引っかかったのは、構造で失敗する、の部分です。技術が動いていても、知識の移転や費用や運用の責任の問題で、使い続けられなくなる場合がある。そういう場合に何が起きるかを、当社の経験に照らして、想定する一例として循環の形で書きます。

ベンダーのFDEが作ったAIが構造から失敗する循環。要望が出る、ベンダーが作る、知識が社内に残らない、次の変更もベンダーに頼む、費用が続かない、使わなくなる、の順に回る

出発点は、現場の要望です。この作業をAIに渡したい。ベンダーのエンジニアが現場に入り、要望に合わせて仕組みを作ります。ここまでは、FDEの定義どおりです。

問題はその次です。作った仕組みの動かし方、止まったときの見方、変えたいときの手順が、ベンダーのエンジニアの頭の中にだけある。社内の人は、使い方は知っているが、仕組みの中は知らない。すると、業務が少し変わったときに、自分たちで直せない。次の変更も、ベンダーに頼むことになります。

変更のたびにベンダーが入ると、変更に対応する追加の費用が、成果に見合わなくなっていきます。製品のライセンス料とは別に、人の時間を買い続ける形になるからです。経営者は、この費用がいつまで続くのかを聞きます。ベンダーは、社内チームの準備ができるまで、と答えます。その準備の中身を、誰も決めていない。

そして、予算の見直しの時期に、使うのをやめる。仕組みは動いているのに、動かし続ける費用と手間が、仕組みが生む価値を上回ると判断される。これが、技術で失敗する前に構造で失敗する、という言葉の中身だと当社は読んでいます。

この循環で問題になっているのは、技術そのものではなく、知識がどこに残るか、費用が誰の時間に紐づくか、終わりを誰が決めるか、の3つです。3つとも、契約の前に責任と確かめ方を決めておくことができます。そして、支援の途中と移行のときに、知識の移転と運用の準備が進んでいるかを確かめられます。

AWSとAnthropicが同じ月に出したもの

Gartnerの警告と同じ時期に、FDEを職種や能力として定義し直す動きが2つ出ました。頼む側が「FDEと名乗る相手が何をできるのか」を測る基準になるので、短く書きます。

AWSは2026年10月1日に、パートナー向けのFDEパスウェイを公開しました。6月に発表した、10億ドルを投じて専任のFDE組織を作る取り組みを、パートナーにも広げるものです。経路は3つで、Skill Builderを通じて無料で提供されます。

経路 対象 問い
Ground 信頼できる企業データ、システム、業務の用語体系、業務の文脈 システムは業務を理解し、信頼できる情報を使えているか
Orchestrate 信頼できるエージェント、ツール、ワークフロー、ID管理、障害からの回復 システムは実際の作業を確実にやり遂げられるか
Prove 評価、可観測性、セキュリティ、ポリシー、人による制御 顧客は本番環境でシステムを信頼できるか

FDE Validatedには、AssociateかProfessionalの有効なAWS認定と、少なくとも1つの経路の必須の検証活動の完了と、3つの経路を通じた所定の合計ポイントが必要です。FDE Advancedには、AWS Certified Generative AI Developer（Professional）の有効な認定と、3つの経路すべての検証要件の完了が必要です。評価は受講の修了ではなく、実際に示せた能力に基づく、と書かれています。要件はAWS Skill Builderの現行の内容が正と明記されているので、詳細はそちらで確認してください。

Anthropicは2026年10月2日に、Claude Frontier Academyを発表しました。1億ドルを投じ、2027年末までに1万人のFrontier Deployed Engineerを育てる計画です。最初のプログラムは、数日の対面の集中研修で模擬の企業導入を通し、ユースケースの選定からセキュリティのレビュー、引き渡しまでを経験して実技試験を受け、合格するとClaude Resident Engineerのバッジを得る。そのあと12週間、所属する組織で実際のユースケースを主導し、再評価に合格するとClaude Frontier Deployed Engineerになる、という2段です。参加は組織からの推薦制で、開催はサンフランシスコ、ニューヨーク、ロンドン。最初の認定者は2027年初頭の見込みと書かれています。

2つに共通するのは、FDEを「現場に入れる人」ではなく、「本番で信頼できる仕組みを作り、引き渡せる人」として定義していることです。AWSの3つ目の経路Proveは、評価と可観測性と人による制御を扱います。Anthropicの研修は、引き渡しまでを模擬で経験させます。どちらも、本番で運用するために必要な能力を重く見ています。ただし、これらは技術の能力の定義であって、顧客への知識の移転や、支援を終える条件の設計を、そのまま意味するものではありません。Gartnerの3原則の2つ目と3つ目は、これとは別に確かめる必要があります。

当社は日本の中小企業向けの小さな会社なので、AWSの認定もAnthropicのアカデミーも、そのまま当社の資格にはなりません。それでも、頼む側が相手を測る基準として、この2つの定義は使えます。作ったものを、誰が、どう測って、どう引き渡すのか。 FDEと名乗る相手に、この質問をしてみてください。答えがなければ、Gartnerの言うFDEウォッシングの可能性があります。

知識が移るか、出口があるか

ここまでを、頼む側が自分の状況を置ける形にします。横軸に知識が社内に移る仕組みがあるか、縦軸に出口が決まっているかを取ると、支援の形は4つに分かれます。

AI・DX支援の形を、知識が社内に移る仕組みがあるかと、出口が決まっているかの2軸で4つに分けた図。両方ある右上が卒業設計型

  • 知識が移らず、出口もない。 Gartnerが警告した形です。作った仕組みを動かし続けるために、ベンダーの時間を買い続けます。変更の追加費用が成果に見合わなくなると、予算の見直しで止まります
  • 知識は移らないが、出口はある。 納品で終わる受託開発に近い形です。システムは残りますが、業務が変わったときに自分たちで直せるかは、納品後の変更の担当が決まっているかで変わります。ここを確かめます
  • 知識は移るが、出口がない。 研修や伴走を続けている形です。社内の人は育ちますが、いつ自分たちだけで回すのかが決まっていない。悪い形ではありませんが、訪問の回数とは別に、成果と続ける理由を確かめたほうがよい形です
  • 知識が移り、出口もある。 当社が目指す形です。社内の担当者と手順書と評価の仕組みを残し、数えられる条件で離れます

自社が受けている支援、受けようとしている支援が、この4つのどれかを考えてみてください。右上でないなら、契約に何を足せば右上に動くかが、次の節の話です。

Gartnerの3原則に、当社の卒業設計を当てはめる

当社の卒業設計の中身は、前の記事に4段階で書きました。週1の常駐で分解と構築、社内の担当者と手順書、評価の仕組みを社員が回す、関与を減らして離れる。ここでは、その設計をGartnerの3原則に1つずつ当てはめて、どこが対応していて、どこが足りないかを書きます。

Gartnerが挙げた真のFDEの3原則と、当社の卒業設計の対応表。対象を絞る、知識を移す、出口を最初に決める、のそれぞれに当社が何をしているかを並べた

原則1、専門知識や統合が要る問題に使う。 Gartnerの言い方は、製品への深い専門知識、速い適応、またはベンダーの技術と運用環境の密接な統合を必要とする問題にFDEを使う、です。当社の場合、製品は自社のものではなく、Microsoft 365やGoogle Workspace、Claudeのような他社の道具です。そこで当社は、3つの条件のうち、社内の運用環境との統合が要る問題を重く見て、そういう問題に入る方針にしています。これは当社の方針で、Gartnerの原則そのものより狭い読み方です。

具体的には、初回の打ち合わせで聞く質問が、この原則の実装です。去年、AIがなくても解決したかった問題は何でしたか。答えが、既製の機能の設定で済むなら、研修で渡します。要件を書いて渡せる大きな刷新なら、SIerを勧めます。業務を作業の粒まで割り、権限と承認の流れを設計に入れ、既存の仕組みとつないで動かす必要がある問題だけ、FDE型で入ります。

原則2、社内の専門家と利用者に知識を移す。 当社の実装は2つです。1つは、毎週同じ人を社内の窓口に立ててもらうこと。専任でなくてよく、交代制で共有できる体制があるならそれでも構いませんが、当社は毎週同じ人をお願いしています。もう1つは、手順書を推進チームだけで書かないこと。仕組みの動かし方、止まったときの見方、変えたいときの手順を、担当者と一緒に書き、実際に使って確かめます。

ここで当社が足りないと感じているのは、知識が移ったことの測り方です。手順書があることと、担当者が手順書を使って自分の担当範囲を直せることは違います。当社は、業務の変更が起きたときに、担当者が自分で直した変更を、難しさの段階ごとに数えることにしています。推進チームに聞かずに直せた変更が、難しい段階まで増えていれば、知識が移っていると見ます。

原則3、出口戦略を最初から明確にする。 当社がいちばん重く見ている原則で、サービスページにも、開始時にいつどう離れるかを一緒に決める、と書いています。出口の条件は、業務ごとに2つです。1つは品質で、対象の件数に対して、人が直さずに通せて、あとから見ても正しかった割合のように、数えられる形にします。通せた回数だけでは、正しさを別に見ないと品質とは言えないからです。もう1つは、社員が運用と変更とトラブル対応を担えるかで、前の段落の、難しさの段階ごとの自分で直した変更の数で見ます。

CX Todayが紹介したGartnerの助言に、社内チームの準備ができていないからといって関係を延長しない、というものがありました。当社はここを、準備ができていないときは延長ではなく、準備の中身を決め直すと読んでいます。延長すると、何が足りないかを決めないまま時間だけが延びます。足りないのが手順書なら手順書を、足りないのが担当者の時間なら経営者との相談を、先にやります。

契約前に確かめる6つの質問

ここまでを、頼む側が契約前に使える質問にします。FDEと名乗る相手に限らず、AI・DXの支援を頼むときに聞いてみてください。当社に聞いてもらっても構いません。

FDE型支援を頼む前に確かめる6つの質問を、なぜ聞くかと具体的な答えの例とともに並べた表。出口の条件、手順書を書く人、社内の窓口、測る数字、作ったものの所有、止まったときに直す人

出口の条件は何ですか。 いつ、どうなったら離れるのかを、数えられる形で答えられるか。社内チームの準備ができたら、という答えは、準備の中身が決まっていない限り、出口ではありません。

手順書は誰が書きますか。 支援する側が書いて納品する、という答えなら、使われないまま残る可能性があります。社内の担当者と一緒に書き、実際に使って確かめる設計かどうかに加えて、社員が自分の担当範囲を手順書で実行できるかを、どう確かめるのかも聞いてください。

社内の窓口は誰が、どのくらいの時間を使いますか。 頼む側が答える質問でもあります。毎週同じ人を立てられないなら、当社の進め方のFDE型は向いていません。研修で候補を作るところから始めるほうが、遠回りに見えて近道です。

何を測って、誰が報告しますか。 人が直さずに通せて正しかった割合、止まった件数、担当者が自分で直した変更の数。測る数字が決まっていて、報告が社員からできるようになる設計かどうか。支援する側が報告し続ける設計なら、離れたときに報告が止まります。

作ったものは誰のものですか。 作った仕組み、設定、手順書、評価の仕組みの所有と、支援が終わったあとの扱い。Gartnerの Saha 氏も、範囲の決まった良いFDEには、知的財産の所有と、プロジェクトを共同で担う責任の分担について明確な指針がある、と述べています。当社の場合、顧客の環境の中に作ったものは顧客のもので、当社が自社で運用する形で提供する道具だけ、利用の契約として分けます。

止まったときに、最初に誰が直しますか。 担当者が手順書を見て直し、直せないときに連絡する、という順番が設計に入っているか。止まり方の種類によっては、すぐ連絡したほうがよい場合もあるので、外に連絡する条件が決まっているかも聞いてください。

6つの質問は、契約の前に運用上の心配を見つけるための質問です。答えが曖昧な項目は、責任者と対応の方法を具体的にしてから契約してください。

注意点

7割の対象は、ベンダーのFDEで作られたAIを使う企業です。 Gartnerの予測は、ソフトウェアベンダーが自社製品を顧客に合わせて作り込む形のFDEを対象にしています。当社のように他社の道具を組み合わせる支援に、この予測をそのまま当てはめることはできません。当社は、知識の移転と出口の設計を点検するための参考として扱っています。

2028年の予測であって、起きたことではありません。 7割という数字は、Gartnerの予測です。当社はGartnerの原文を直接確認できておらず、Publickeyと CX Today の記事で確かめています。数字を引くときは、予測であることと、企業の割合であることと、出どころを書いてください。

当社もFDEを名乗る側です。 この記事は、FDE型支援を売っている会社が書いています。当社の設計がGartnerの3原則に合っていると書きましたが、合っているかどうかを決めるのは、頼む側です。前の節の6つの質問を、当社にも向けてください。

FDEの定義は、会社ごとに違います。 AWSとAnthropicの定義は、本番で信頼できる仕組みを作って引き渡す人、という方向で揃っていますが、日本の市場でFDEと名乗る支援の中身は幅があります。名前ではなく、出口と知識の移し方と測り方で判断してください。

KOIYALの見解

Gartnerの予測を読んで、当社が最初に思ったのは、利用をやめる側に顧客を入れないための設計は、すでに前の記事に書いたとおりだ、ということでした。知識を移し、出口を決め、数えられる条件で離れる。ただ、書いてあることと、できていることは違います。この記事を書きながら、知識が移ったことの測り方が弱いことに気づき、担当者が自分で直した変更を難しさの段階ごとに数える、という項目を足しました。

当社がFDE型支援を売りながら、離れることを使命にしているのは、顧客の会社が当社なしで回る状態を作りたいからです。常駐が続くほど当社の収益は安定しますが、顧客が自分たちで回せる状態に近づいていないなら、それはGartnerが警告した形に近づいています。読者の会社に残したいのは、当社との関係ではなく、出口の条件を自社の言葉で書ける力です。何ができたら支援を終えるのか、何を数えて判断するのか、誰が直すのか。これを自社で書けると、どの支援を頼むときも、出口と、知識をどこに残すかを自社で決められます。

インハウス経営は、支援を受けないことではありません。支援を受けるときに、出口と、知識をどこに残すかを自社で決められることです。AWSとAnthropicが大きな投資でFDEを育てている今、FDEを頼む側の目も、同じ速さで育つ必要があると当社は考えています。

次の行動

今、AI・DXの支援を受けている会社、受けようとしている会社に、1つだけ提案します。契約書か提案書を開いて、出口の条件が数えられる形で書かれているかを確かめてください。書かれていなければ、支援する側に、前の節の6つの質問を送ってみてください。

当社のFDE型支援は、開始時に出口の条件を一緒に書くところから始めます。初回の打ち合わせでは、去年AIがなくても解決したかった問題を聞き、FDE型で入るべき問題かどうかを当社の考えとしてお伝えします。統合が要らない問題なら、研修か設定の見直しを勧めます。FDE型支援の進め方をご覧いただくか、お問い合わせからご連絡ください。

参考