FDEのベンダーロックインを防ぐには|出口条項と内製化の3段階、求人511件に見る引き継ぎの記載

なぜ2026年10月に、FDEの「出口」が論点になったのか?

FDEを売る側の発表が出そろったあとで、買う側の論考が追いかけてきたからです。2026年5月から6月にかけて、調達・サプライチェーンのソフトウェア会社が相次いでFDEを使うサービスを始め^[6][7][8]、6月30日にはAWSが10億ドルを投じるFDE組織を発表しました^[5]。9月29日にGartnerが、ベンダーのFDEに頼った企業がコストの上昇と自社で手を入れられない状態に陥ると予測し^[4]、10月19日以降、その予測を受けて「FDEが去ったあとに何が残るのか」を問う論考が続き^[1][2]、FDEに頼ること自体を批判する論考も出ました^[3]。

1. 2026年5月12日

   CoupaがFDEを含むCatalystを発表

   調達・支出管理のCoupaが、成果に連動する価格の新製品と、FDEとソリューションアーキテクトによるAI変革サービス「Catalyst」を発表^[6]

2. 2026年6月2日

   ZipとKinaxisが同じ日にFDEを打ち出す

   調達のZipが自社のFDEが顧客の環境で専用のエージェントを作る「AI Spend Automation」を^[7]、サプライチェーン計画のKinaxisが新しい関わり方としてForward Deployed Engineeringを発表^[8]

3. 2026年6月30日

   AWSが10億ドルのFDE組織

   AWSが、顧客がデプロイの終わりに自立できるよう設計したFDE組織を発表^[5]

4. 2026年9月29日

   Gartnerが「7割放棄」を予測

   2028年までに7割の企業が、ベンダーのFDEが作ったエージェント型AIを放棄すると予測。契約前・期間中・出口の3段階の手順を示す^[4]

5. 2026年10月19日

   調達側のニュースレターが「退去計画」を提案

   Bertrand Maltaverne氏が、FDEを受け入れる企業に、初日から退去(move-out)を計画するよう勧める^[1]

6. 2026年10月19日

   Rod Johnson氏が「FDEは有害」と批判

   FDEの急増は製品の欠陥の表れであり、顧客の利益にならないと主張^[3]

7. 2026年10月20日

   FDE Hubが「退去条項」を論評

   現役のFDEのMilos Mandic氏が、前日の調達側の提案を受けて、何が本当に引き継がれるべきかを論じる^[2]

Maltaverne氏は、調達テクノロジーの世界に新しい職種名が来たと書き出し、ベンダーのエンジニアが顧客のもとに座って設定・連携・修正をする仕事は、かつて導入コンサルタントと呼ばれていた、自分もその一人だったと振り返っています^[1]。そのうえで、FDEは組織と技術の両方が「未熟」な今の時期に合わせた古い職種であり、今は理にかなうが、売る側の誰も口にしたがらない危険があると書きます。AIを動かすための知識が、他人のものになるという危険です^[1]。

FDEのベンダーロックインとは、何が誰のものになることなのか?

FDEのベンダーロックインとは、FDEが顧客の現場で掘り起こした業務の意味(定義・ルール・例外)が、FDEの頭とベンダーの環境に残り、顧客が自分の業務の論理を借りる立場になることです。Maltaverne氏は、FDEが案件の中で作るものとして連携、エージェントの設定、プロンプト、ワークフローを挙げ、それ以上に重要なのは、承認の暗黙のルールや方針どおりに動かない品目など、調達の業務が実際にどう回っているかを学ぶことだと書いています^[1]。案件が終わると、その知識はFDEの頭とベンダーの環境に残り、顧客の組織にはほとんど残らないといいます^[1]。

同氏は、これが従来の導入プロジェクトのロックインより悪い理由を2つ挙げています^[1]。1つは、従来の導入には少なくとも建前のうえでは終わり(本番稼働、引き継ぎ、稼働直後の手厚い支援)があったのに、エージェント型のシステムは変わり続けるので、知識を返す自然な区切りが来ないことです。もう1つは、FDEが握るのが業務の意味の層であり、それがAI導入で最も価値のある資産だということです^[1]。

同氏は、自社が「囚われ」始めている兆候として次の4つを挙げています^[1]。

FDE側から同じ構造を書いたのが、15件を超える顧客の案件を並行して手がけてきたという現役のFDE、Mandic氏です^[19]。同氏は、契約で扱えるのはコード・プロンプト・設定・業務ルールの所有権までで、FDEが3か月かけて顧客の買掛金処理や配車計画の現場で学んだこと、つまり例外や書かれていない閾値、2019年の失敗のせいで残っている手順は、契約では扱えないと書いています^[2]。FDEは顧客のルールを他社に売ることはできないが、似た業務の会社、多くは競合他社と次に向き合うときに、学んだことを使うといいます^[2]。

同氏はこれを抜け穴ではなく仕組みそのものだと書きます。取材したFDEの責任者はみな、ある顧客で学んだことを製品に持ち帰り、次の顧客が早く成果を得られるようにするのがこの仕事だと説明し、元FDE責任者の1人は、FDEの成果のうち製品に戻るべき割合はおよそ70%だと話したといいます^[2]。同氏の言葉では、それはベンダーにとっては発見であり、買い手から見れば、自社の業務の知識が他人の製品計画になることです^[2]。

FDEの求人票は、顧客への引き継ぎと製品への還元のどちらを職務に書いているのか?

編集部が求人票を数えたところ、製品への還元を書いた会社が大半で、顧客への引き継ぎを職務に書いた求人は少数でした。2026年10月20日に133の公開ジョブボード(うち131が応答)から取得し、職種名にForward Deployed・FDE・FDSEを含む求人511件(77社)の本文を検索し、該当箇所を1件ずつ読んで数えました。

職種名にForward Deployed・FDE・FDSEを含む求人

511件・77社

編集部が集計。2026年10月20日に133の公開ジョブボードから取得(131が応答)

顧客への引き継ぎ・顧客の自立を職務に書いた求人

34件・14社

knowledge transfer、handover、handoff、self-sufficient、customer can operate などの記載を1件ずつ読み、本番環境への移行、社内向けの職務、エージェント間やシフトの引き継ぎを除いた。勤務地違いの同じ職種を含む。編集部が集計(2026年10月20日取得)

現場の学びを製品・再利用できる資産に戻すことを書いた会社

55社

product feedback、roadmap、reusable、customer feedback などの記載がある会社(77社中)。会社ごとに1件以上を読んで確かめた。編集部が集計(2026年10月20日取得)

一方で、現場の学びを製品に戻すことは、77社中55社の求人に書かれていました。OpenAIの求人は、現場から上がる評価結果をもとに製品とモデルのロードマップを変えることを成功の物差しに挙げています^[20]。n8nは、顧客ごとの要件がいつ再利用できる部品や製品機能になるべきかを見極めることを求め、Figmaは、学んだことを顧客のコードを恒久的に抱え込むのではなく、次の顧客のための再利用できる道筋に変えることを求めています^[12][15]。

ベンダーは「顧客の自立」をどう約束しているのか?

公式発表で顧客の自立を最も具体的に約束しているのはAWSで、調達系のベンダーは成果や価値の実現を前面に出し、引き継ぎには触れていません。AWSは、FDEの3つの違いの1つに、デプロイが終わったときに顧客が自立できるよう設計していることを挙げ、案件が進むにつれて顧客のエンジニアが観察者から共同開発者、自律的な運用者へ進むと説明しています^[5]。

Maltaverne氏は、AWSが「依存し続けるのではなく自立できるよう組み立てたシステム」を届けると言っているのは良い文だとし、調達部門はその文をベンダーとの契約に入れるよう求めるべきだと書いています^[1]。また、Coupaの発表の注記に、外部連携とMCP(Model Context Protocol)、A2A(Agent2Agent)への対応は2026年9月の予定とあることを例に、モデルやプロトコルが毎週のように変わる技術側の未熟さもFDEが求められる理由だとしています^[1][6]。

受け入れる企業は、どんな段階でFDEから引き継ぐのか?

Maltaverne氏が勧めるのは、社内に小さなCoE(センター・オブ・エクセレンス)を置き、FDEの横で学ぶ段階、業務の意味の層を受け持つ段階、自分で運用して拡張する段階の3つで引き継ぐ形です^[1]。CoEに要るのは人数ではなく、業務プロセスの知識、データの理解、FDEが作るものを追える程度の技術の素養を併せ持つ人だといいます^[1]。

1. 第1段階

   Shadow(同席して学ぶ)

   FDEが作り、CoEは横に座って記録し、質問する^[1]

2. 第2段階

   Co-build(一緒に作る)

   CoEが意味の層(定義・業務ルール・例外)と文書を受け持ち、FDEはエンジニアリングを担う^[1]

3. 第3段階

   Own(自分で持つ)

   CoEがデプロイ済みのエージェントを運用・拡張し、ベンダーは新しい機能が要るときだけ呼ぶ^[1]

この3段階は、AWSが説明する顧客のエンジニアの進み方(観察者、共同開発者、自律的な運用者)^[5]や、Gartnerが勧める3段階の手順^[4]とほぼ重なります。違うのは、何を基準に区切るかです。

Maltaverne氏は、この提案に対して出がちな反論にも答えています^[1]。FDEの技能は希少なのに調達部門がどう雇うのか、という反論には、CoEはFDEを雇う必要はなく、FDEがいる間に社内で育てる、業務知識の厚い少人数でよい、それが第1段階の目的だと答えます。CoEは過去にボトルネックになったり、誰も読まない文書を作ったりしてきた、という反論には、統治の憲章ではなく、引き継ぐ特定のデプロイにCoEを結び付けることが違いになると答えます。技術が毎週変わるならCoEは引き継げないのでは、という反論には、全部は無理なので、業務プロセス・意味・統治という安定した中核を持ち、新しい機能は外部の助けを借りるのが現実的だとしています^[1]。

FDEを受け入れる契約には、何を書いておくのか?

Maltaverne氏は、引き継ぎは善意では起きないので契約に書く必要があるとし、次の5つを挙げています^[1]。Gartnerも、契約前の段階で、成果物・知識移転・知的財産権・移行と撤退の責任を、調達部門の範囲を超える重要な契約要件として決めるよう勧めています^[4]。

1. 01知識移転を、受け入れ基準のある名前の付いた成果物にする^[1]
2. 02自社のために作られたコード・設定・プロンプト・業務ロジックの所有権と知的財産権^[1]
3. 03文書の基準と、ベンダーの環境の外からも文書を読めること^[1]
4. 04契約期間が進むにつれてFDEの稼働時間が減っていくこと^[1]
5. 05方針を変えるときの撤退支援^[1]

Maltaverne氏は、契約の前にベンダーへ尋ねる質問として次の6つを挙げ、最後の質問が最も多くを明らかにすると書いています^[1]。明確な答えを持つベンダーは、FDEが今の時期のための橋だと理解しており、答えを持たないベンダーは、顧客がその橋を渡りきらないことを当てにしている可能性が高い、という理由です^[1]。

1. 01具体的に誰が自社と働くのか。その人は調達の領域でデプロイした経験があるか^[1]
2. 02作ったもののうち何が自社に残るのか。どんな形で残るのか^[1]
3. 03知識はどう自社のチームに移るのか。移ったことをどう確かめるのか^[1]
4. 04試験導入のあと、1年目のあと、FDEの支援にいくらかかるのか^[1]
5. 05FDEが抜けたり契約を終えたりしたら、自社のエージェントとワークフローはどうなるのか^[1]
6. 062年以内に自社がベンダーを必要としなくなるための計画は何か^[1]

4つ目の質問には、費用の構造が関わります。成果報酬や利用量連動など、FDEの費用の払われ方ごとの違いはFDEの費用は誰がどう払うのかで整理しています。

本当に引き継ぐべきものは、文書ではなく何なのか?

Mandic氏の答えは、業務の担当者が自分で業務ルールを見て変えられる仕組みです。同氏は、調達側の提案の「知識移転を成果物にする」という条項は、見た目ほど強くないと書いています^[2]。成果物にするには移すべき知識の本体がなければならないが、自分が担った案件では初日にマニュアルはなく、業務の論理は担当者の頭の中にあった、それを引き出すことが仕事の前半で、作ったあとの論理は、元の担当者の頭、自分の頭、自分が書いたプロンプトとルール表の3か所にあった、というのです^[2]。

同氏によれば、一緒に働いた買い手が実際に求めたのは、もっと狭く、もっと役に立つものでした。どの地域にどの曜日に出荷するか、いくら以上を誰が承認するか、何を一致する請求書とみなすか、といった業務ごとの主要なルールを、コードより簡単な何かで自分たちで変えられることです。開いて、ルールを見て、変えると、翌日にはエージェントの振る舞いが変わる、それをFDEである同氏に依頼を出さずにできることだといいます^[2]。

同氏は、業務プロセスの持ち主が自分でルールを編集できるシステムは、FDEがまだいてもいなくても、すでに引き継がれている、ルールがエンジニアにしか分からないプロンプトの中にあるシステムは、どれだけ文書を添えても引き継がれていない、と書きます^[2]。そのうえで、引き継ぎ先のチームの人選に注意を促します。システムを運用できるからとIT部門から人を出したくなるが、ルールがまだ正しいかを判断できるのは、その業務の中で働く担当者だ、という指摘です^[2]。

もう1つ、同氏が区別するのが「ベンダーの人からの独立」と「ベンダーのプラットフォームからの独立」です^[2]。前者は達成でき、既定の目標にすべきだが、後者は別の判断だといいます。プラットフォームの価値は、社内のチームがFDEなしで隣の解決策を作れることにあり、プラットフォームを離れればそれも失うからです。多くの場合、プラットフォームは残して人への依存をなくすほうが役に立つが、それはプラットフォームが、ルールを見て変える自由、作ったものを広げる自由、それが成り立たなくなったら去る自由を社内のチームに与える場合に限る、としています^[2]。

「そもそもFDEに頼るべきではない」という反論は正しいのか?

半分は正しく、半分は書き手の立場を割り引いて読む必要があります。FDEの急増を製品の空白の表れと見る指摘は、Maltaverne氏やGartnerの「段階を過ぎても続けば依存になる」という見方と重なります^[1][3][4]。一方で、批判の筆者は自社製品を勧めており、FDEをゼロにできるかは顧客の体制にもよります^[3][17]。

最も強い反論を書いたのがRod Johnson氏です。同氏はJavaの開発フレームワークSpringの作者で、現在はJVM向けのAIエージェント開発フレームワークEmbabelと、その上の製品Embabel Worldsを手がけています^[3][9]。同氏は、2001年にIBMのWebSphereを評価しなかったのは、IBMが自分でのインストールを許さず、担当者を送ると言い張ったからで、その間にWebLogicは数分で動かせた、結果として地雷を避けられた、という経験から書き始めます^[3]。2000年代半ばには、技術は評価しやすくあるべきで、そうでなければたぶん出来が悪い、という理解が広がっていたのに、25年後の業界はFDEの「軍団」を受け入れ、時に称賛までしていて後退した、という主張です^[3]。

同氏が例に挙げるのは、Anthropicが10月2日に発表した、1億ドルを投じて2027年末までに1万人のFrontier Deployed Engineerを育てる「Claude Frontier Academy」です^[3][16]。同氏は、これはAnthropicの利益にはなるが顧客の利益ではなく、大規模にソフトウェアの問題を解く方法ではないと書いています^[3]。過去の技術の波でも、多くの非ソフトウェア企業が同じ問題を自前で解こうとしたとき、それは新しい製品カテゴリーが必要だという合図であり、ERP、CRM、BI、アプリケーションサーバー、Webフレームワークがそうだった、とも指摘します^[3]。

同氏はFDEの急増が示すものとして、次の4つを挙げています^[3]。

ただし、この論考は後半で自社のEmbabel Worldsを紹介し、利用者ができるだけセルフサービスで進められるようにする、営業に問い合わせなくても今日から評価できる、と勧めています^[3]。文脈の層という製品カテゴリーで自社製品を売る立場から書かれた文章であることは、割り引いて読む必要があります。

反対の方向から限界を指摘する論考もあります。AWSの発表当日に公開された論考は、「離れるときに顧客が自立している」というAWSのモデルには下限があると書きました^[17]。AWSが名前を挙げた顧客はどれも、自律的な運用者に育つエンジニアのチームを持つ組織であり、エンジニアのいない地域の歯科グループや中小企業にとっては「作って去る」は「運用できないシステムを置いていく」ことになる、という指摘です^[17]。この筆者は、そうした企業のために運用を代行する事業をしていると自ら断っています^[17]。

日本の発注企業とFDEとして働く人にとって、何を意味するのか?

発注企業にとっては、FDEを受け入れる契約に出口を書き、引き継ぎ先に業務の担当者を置くことです^[1][2]。FDEとして働く人にとっては、求人票に書かれることの少ない引き継ぎの技能が、発注側から求められ始めていることを意味します。

日本でも、ベンダーの支援を受けながら社内でFDEを育てる動きが出ています。セールスフォース・ジャパンは2026年10月8日、SCSKがSalesforceのAgentforceを導入して営業のAIエージェントを内製化し、2027年までに社内でFDE人材を100名育てると発表しました^[18]。SCSKは、そこで得た知見を顧客向けのビジネスにも広げるとしています^[18]。同社がSalesforceの最上位のサポートプランを採用した理由として挙げたのは、Agentforceの構築・運用の内製化と、社内の技術ノウハウの早期の蓄積・標準化ができる点です^[18]。楽天グループがFDEの内製化を進めながらベンダーにも伴走してもらっている例は、FDEの費用は誰がどう払うのかで紹介しました。

SCSKの例は、Mandic氏の言う「プラットフォームは残し、人への依存をなくす」^[2]に近い形です。ベンダーのプラットフォームとサポートは使い続けながら、構築と運用の担い手を自社に置こうとしています。

発注企業にとって

FDEとして働く人・目指す人にとって

この記事の材料から分からないことは何か?

分からないのは、実際の契約に引き継ぎがどう書かれ、どれだけ守られているかです。論考は個人の見方で、ベンダーの発表は自社の説明、求人票は採用の文書であり、案件の実態を測ったものではありません。

まとめ

FDEのベンダーロックインを防ぐ鍵は、FDEが掘り起こした業務の知識を、業務の担当者が自分で扱える形で社内に残すことです。要点は次のとおりです。