FDEウォッシングとは——「7割が放棄」とガートナーが予測したAI開発を、発注側はどう見極めるか

「ベンダーが環境を持つものだと思っていました」

先日、ある製造業のDX推進室の担当者と、開発環境の話になりました。自社でクラウド環境を用意する案を説明したところ、少し戸惑った表情でこう返されたのです。

「知識のギャップがあり、社内で環境を構築するのは難しい。通常、日本企業ではベンダーが環境を持って、費用は保守費用に含まれることが多いですよね」

この反応は、誰かの怠慢ではありません。日本のシステム発注が数十年かけて作り上げてきた、ごく自然な前提です。ベンダーが環境を持ち、ベンダーが直し、その対価を保守費として毎年払う。基幹システムの時代には、これで回っていました。

ところがAIエージェントになると、同じ前提が重い負債に変わります。業務ルールが変われば、プロンプトも判定の閾値も、参照するデータの範囲も変えなければなりません。しかも変更の頻度は、基幹システムの比ではないのです。毎月のように手を入れる仕組みを、外部の誰かしか触れない状態に置く。そのとき何が起きるか——というのが、今回のガートナーの予測の中身です。

別の大手化学メーカーの担当者は、自社の内製の実態をこう正直に話してくれました。「『内製できます』と謳いつつ、実際は難しい。設計側、つまりデータモデリングと裏の処理がなかなか進まない」。看板と実態の差は、ベンダー側だけの問題ではありません。発注側にも同じ構図があります。

ガートナーが出した3つの数字——70%、20%未満、四半期20万ドル

まず、事実関係を押さえます。ガートナーが2026年9月29日に発表した予測は、数字が3つあります。

数字	内容
70%	2028年までに、ベンダーのFDEが構築したAIエージェントを放棄する企業の割合
20%未満	2028年までのFDE案件のうち、顧客に共通する要望をベンダー製品の標準機能に取り込めるものの割合
四半期20万ドル超	1つのユースケースあたりのFDEコンサルティング費用（同社の発表による。1ドル150円換算でおよそ3,000万円、年に直せば1億円超）

放棄の理由として挙げられているのは、費用の高騰と、企業が自力でAIエージェントを進化させられないことの2点です。同社のシニア ディレクター アナリスト、ムクル・サハ氏は、うまく設計された案件の共通点を挙げています。初日からガバナンス・事業価値・知的財産の帰属・プロジェクトの共同所有・ナレッジ移転・出口戦略の方針が決まっている、という指摘です。

日本語の初報はITmedia NEWSで、2026年10月7日のことです。その後、国内のIT系メディアでも「名ばかりFDE」をめぐる議論が続いています。発表から3週間弱で、日本の経営層の視界にも入ってきた話題です。

ここで注目したいのは、2つ目の「20%未満」のほうです。これは一見、ベンダー側の事情に見えます。実際には発注側のコストに直結する数字でした。自社のために作った機能が製品の標準機能にならないということは、その機能の改修費を、自社だけで払い続けるという意味だからです。

「FDEウォッシング」とは何か——看板を掛け替えただけのコンサルを見分ける

ガートナーが同時に警告したのが「FDEウォッシング」です。実装支援や従来型のプロフェッショナルサービス、AIコンサルティングに「FDE」という看板を付け、提供の深さが伴わないまま高い料金を取る——という現象を指します。

なぜ今、この現象が増えるのか。理屈は単純です。FDEという言葉の人気が先に立ち、それを名乗ると単価が上がるからです。この点はQiitaの技術者の論考が端的に書いています。「コンサルタントに名刺だけ変えさせ、表面的なAI活用法を提案する」という表現です。手厳しい言い方ですが、構造の指摘としては的確だと考えています。

では、本物と看板倒れを分ける線はどこか。私たちの見立てでは、本番環境に出す責任を負っているかどうかの一点に尽きます。

• 課題を見つけ、戦略を描き、PoC（概念実証：小規模に試して効果を確かめること）を作り、報告書を渡す。実装は顧客かSIerへ——これは従来のコンサルティングです。
• 課題を見つけ、データをつなぎ、本番で動かし、現場の反応を見て翌週には直す。障害が出たら自分たちが起きる——こちらがFDEです。

誤解のないように申し上げると、前者の価値が低いという話ではありません。役割が違うだけです。3者の役割分担については関連記事: FDE・コンサル・SIer——AI導入パートナーの選び方と、3者の根本的な違いで整理しています。問題なのは、前者を提供しながら後者の料金を取ること。そして発注側が、違いに気づかないまま1年を失うことです。

余談ですが、この言葉が日本で検索され始めたことは、私たち自身のアクセス解析にも表れています。Search Consoleの集計によると、直近4週間で「FDE washing」という英語の検索語からこのサイトが9回表示され、2回クリックされていました。表示回数としては小さな数字です。けれど、クリック率は22%を超えています。少数ながら、本気で調べている人がいるということです。

なぜ7割が放棄されるのか——理由は費用そのものではありません

費用が高いだけなら、企業は値下げ交渉をします。放棄はしません。7割という数字の背景にあるのは、もっと厄介な構造です。

コードは残る。ノウハウは残らない。 これに尽きます。

外部のエンジニアが現場に入って作ると、そのときは成果が出ます。現場の言葉で要件が決まり、翌週には画面が変わる。満足度は高い。ところが、なぜその判定ロジックにしたのか、なぜそのデータだけを参照しているのか、という判断の理由は、エンジニアの頭の中にあります。引き継ぎの資料に書かれるのは手順だけです。理由が残らないと、業務が変わったときに誰も直せません。

そして、直せない仕組みには2つの道しかありません。ベンダーに払い続けるか、使うのをやめるか。ガートナーが言う「放棄」とは、後者を選ぶ企業が7割に達するという予測です。

ある大手化学（農薬・ファインケミカル）メーカーの企画部門の責任者は、2027年稼働予定の基幹刷新について、自分で進捗を見ていても期待した水準に届いていないと感じる、と話していました。それでも、もう後戻りできない。要件は固めたものの、あとはどうにでもしてくれ、という状態だといいます。出口を設計しないまま進んだプロジェクトは、途中で軌道を変える手段を失います。AIエージェントは、この硬直がもっと短いサイクルで起きる領域です。

もう1つ、見落とされやすい論点があります。成果の測り方です。ある重工・製鋼メーカーのシステムグループマネージャーは、社内のQC発表での報告をこう振り返っていました。「開発にAIを入れてコールを30%削減しました、と報告したが、全然評価が悪くて、あまり響かなかった」。工数削減は、社内では評価されにくい。評価されない成果しか出ていない案件は、予算の見直し時に真っ先に切られます。放棄の引き金は、技術ではなく社内政治の側から引かれることもあるのです。

この予測は、私たち自身に向けられた予測でもあります

ここで手の内を明かします。AI-PathはFDEモデルで事業をしている会社です。つまり、ガートナーが「7割が放棄する」と言っている、その供給側に私たちはいます。耳の痛い予測を、自社に当てはめずに論評するのはフェアではありません。

私たちが放棄されないために何をしているか、具体的に書きます。

• MVP（最小限の動くシステム）は私たちの基盤で素早く立ち上げ、その後は顧客の自社環境・専用ドメインへ移す。 ある化粧品メーカーの生産管理システムでは、利用者19名の本番環境ごと顧客側のクラウドへ全面移行しました。認証基盤も移しています。移せない仕組みは、それ自体が依存の原因になるからです。
• 顧客の内製担当者に、安全な線引きを渡す。 同じ案件では、顧客側の担当者が自分でコードを触る体制に移行しました。そのとき渡したのが「データベースは直接いじらない」「メインに直接マージせず、まずPRを上げる」という2つのルールです。ブランチをどれだけ汚しても戻せますが、DBを変えると後戻りできません。
• 自社プロダクトをOEM提供する場合も、ソースコード込みの買い切りライセンスを用意する。 グループ内での改変を認める形です。

正直に申し上げると、これでも万全ではありません。顧客側の担当者が異動すれば、積み上げた操作ノウハウは一度リセットされます。私たちが関与を終えた後の1年間を、私たちは見届けられないこともあります。だからこそ、引き継ぎを「気持ち」ではなく「検収基準」で定義する必要がある——というのが、後半でお伝えしたい話です。

ある特注プラントメーカーの技術部門の責任者は、こう言っていました。「全部任せるより、ノウハウを共有して二人三脚で作りたい」。発注する側も、依存し続ける未来を望んでいるわけではないのです。

本物を分ける3つの条件——ガートナーの指摘を日本の商習慣に置き換える

ガートナーが挙げる本物のFDEの要件は、成果への責任・価値に連動したインセンティブ・顧客への深い組み込みの3つです。抽象的なので、日本の発注実務の言葉に置き換えます。

要件	日本の商習慣に置き換えると	看板倒れの兆候
成果への責任	評価対象が「納品物の完成」ではなく、現場の行動が変わったかどうか。障害対応の当番表に相手の名前がある	検収条件が成果物一覧と工数の消化だけで書かれている
価値に連動したインセンティブ	請求がマイルストーンの消化ではなく、使われている状態の維持に紐づく。改修のサイクルが週単位	単価×人数×月数だけで見積もりが構成され、要員の交代が自由
顧客への深い組み込み	現場の会議体に入り、権限を持って業務データに触れる。意思決定の場に同席する	窓口は情シス経由のみ、現場ヒアリングは初期の数回で終わる

3つ目の「深い組み込み」は、日本企業では権限の問題にぶつかります。社外の人間に業務データへのアクセスを与えるのか、という議論です。私たちは、ここを機能単位の権限分離（RBAC）で解きます。資料の閲覧可否という粗い単位ではなく、機能ごとにアクセス権を振り分け、取引先ごとに権限設定のセットを運用する。財務経理・人事系まで含めて分離しておけば、「現場に深く入る」ことと「見せてはいけないものを見せない」ことは両立します。

誤解のないように付け加えると、この3条件を全部満たす相手だけが正解、という話でもありません。要件が固まった定型開発なら、SIerに請負で出すほうが安く速い。判断の分かれ目は関連記事: AIエージェント開発は外注か内製かに整理してあります。

発注前に聞く7つの質問——看板倒れなら、答えが曖昧になります

ここからが実務です。候補のベンダーに会うとき、次の7問を順番に聞いてみてください。答えの質ではなく、具体性を見ます。良い回答には固有名詞か数字か日付が入り、危ない回答は主語が消えます。

1. 本番環境へのデプロイは、どなたが実行しますか。 良い回答は「私たちが出します。障害時の一次対応の当番にも入ります」。危ないのは「実装はお客様側またはパートナー様で」という受け身の線引きです。

2. 最初に動くものを見せていただけるのは、いつですか。 私たちは1日で動くプロトタイプを作って持っていきます。数週間かかるという回答そのものが悪いわけではありません。「要件定義に3か月」という答えが返ってきたときは、作る前に報告書を作る会社だと考えてよいでしょう。

3. この案件の成果は、何で測りますか。 現場の作業時間、手戻りの件数、判断の属人度——業務側の指標が出てくるかを見ます。納品物一覧と稼働工数しか出てこないなら、成果の定義を発注側で用意する必要があります。

4. ソースコードと実行環境は、自社に移せますか。移すときの手順と費用を教えてください。 即答できるかどうかが分かれ目です。移管の経験がある会社は、手順書の存在と、かかる期間を具体的に言えます。

5. 自社の誰が、何をできるようになれば、引き継ぎ完了と判断しますか。 これがいちばん効く質問だと考えています。「技術移転を行います」とだけ答える相手は、引き継ぎを設計していません。

6. 今回作る機能のうち、他社にも共通する部分はどれですか。 ガートナーの「20%未満」に対応する質問です。共通部分を自社製品に取り込む意思がある会社なら、その部分の改修費は将来下がります。取り込む気がないなら、全額を自社で負担し続ける前提で予算を組むべきです。

7. 契約を終える条件と、そのとき手元に残るものを教えてください。 出口の話を初回に持ち出すと気まずい——という感覚は分かります。それでも聞いてください。嫌がる相手なら、その反応自体が答えです。

契約に書く5項目——「技術移転を行う」とだけ書かれた契約は、何も約束していません

質問で感触をつかんだら、次は契約です。ガートナーが挙げる6つの論点（ガバナンス・事業価値・知財の帰属・共同所有・ナレッジ移転・出口戦略）を、契約書に落とすときの5項目にまとめます。

1. 知的財産権の帰属を、部位ごとに分けて書く。 プロンプト、業務ルールを表現したロジック、データの加工手順は誰のものか。特に自社の業務ノウハウが反映された部分は、汎用のライブラリ部分と分けて定めます。全部まとめて「本件成果物」と書くと、どちらの解釈も成り立ってしまいます。

2. ソースコードと環境の引き渡しを、手順と期限で書く。 「引き渡す」ではなく、「どの形式で」「どこに」「何営業日以内に」を書きます。移管リハーサルを契約期間の中盤に1回実施する、と入れておくのも有効です。期限が切れてから初めて試すと、たいてい何かが足りません。

3. ナレッジ移転の対象者・到達水準・回数を書く。 5項目のなかで、放棄を防ぐ効果がいちばん大きいのがここです。「技術移転を行う」は、何も約束していないのと同じ。私たちが顧客と結ぶときは、対象者を名前で特定し、到達水準を作業単位で書き、勉強会の回数を決めます。詳しくは次の章で扱います。

4. 共同所有の形を決める。 イシュー（課題）の管理をどちらの環境で行うか。レビューの権限を誰が持つか。進行中のプロジェクトを「相手の持ち物」にしないための、地味ですが効く取り決めです。私たちは顧客からのフィードバックをイシューとして登録し、翌週にはプロトタイプを持っていく運用を標準にしています。

5. 撤退条件と、そのとき残るものを書く。 成果が出なかったときにどこで止めるか。止めた時点で、どのデータ・どのコード・どの手順書が手元に残るか。あるホールディングスの担当者は「過去のウェブサイト構築で高額な費用をかけ、トラウマになっている。今回は自分たちで動かせるコンテンツ運営を目指したい」と話していました。撤退条項は、このトラウマを作らないための保険です。

契約形態についても一言。請負契約は完成した成果物に責任を持つ形で、仕様が固まった開発に向きます。準委任契約は作業そのものに対価を払う形で、使いながら直すAIエージェントと相性が良い方式です。最初のMVPは請負、その後の改修は準委任と分けるのが現実的でしょう。

引き継ぎの検収基準——「誰が、どのくらいの時間で、何をできたら完了か」

ナレッジ移転が約束で終わるのは、合格ラインがないからです。私たちは引き継ぎの完了を、次の3点で定義することをおすすめしています。

誰が——社内で2人以上、名前で特定する。 1人だけに引き継ぐと、その人の異動や退職で振り出しに戻ります。ある製造業の現場担当者は、ベテランの装置操作について「装置は感覚で覚えているため依頼しなかったが、引き継ぎを考えると重要になる」と話していました。属人化は、AIエージェントの運用でも同じ形で再発します。

何を——軽微な変更を、自力で本番まで出せる。 具体的な合格ラインは、たとえば「画面に入力項目を1つ追加し、PRを作り、レビューを受けて、本番に反映するまでを自分で通せる」。ロジックの大改修を基準にしてはいけません。日常で発生する変更の8割は、この粒度だからです。

どのくらいで——立会いなしで、営業日3日以内に1件。 ベンダーが画面共有で見守っている状態での成功は、引き継ぎの証拠になりません。相手が見ていない状態で1件通った記録。それだけが引き継ぎの証拠になります。

この3点を契約書の別紙に書き、引き継ぎ完了の検収条件にします。合格しなければ、支援期間を延ばすのではなく、合格するまでの追加支援の範囲と費用をあらかじめ決めておく。ガートナーも、社内チームの準備ができていないという理由で契約を延長するのではなく、初めに合意した出口計画に従うべきだと述べています。延長は、依存を先送りにするだけです。

ある化粧品メーカーの内製担当者は、自分でコードを触り始めるとき「一旦、データベースをがらっと変えちゃうんじゃないかという懸念がある。まず自分で触ってみて、あとは判断してもらう形でどんどん進めても問題ないか」と聞いてきました。不安と前向きさが同居した、良い問いだと思います。この問いが出てくる状態まで来れば、引き継ぎは半分成功しています。

情シス3人の会社で、自走ラインをどこに引くか

とはいえ、従業員300名規模の企業で情報システム部門が3人、という状況は珍しくありません。全部を自社で、は非現実的です。だから「どこまでを自社で触れるようにするか」の線を、最初に引きます。

私たちが顧客と引く線は、おおむね3段です。

区分	対象	運用
自社で自由に触る	画面の文言、帳票のレイアウト、AIへの指示文（プロンプト）、マスタの値	検証環境で試してから反映。失敗しても戻せる範囲
レビューを受けて触る	業務ロジック、判定の閾値、画面項目の追加	PRを上げ、レビューを通してから本番へ
触らない	データベースの構造、権限設定、認証、夜間バッチ	変更はベンダー側で実施し、理由を記録に残す

この線引きには、もう1つ効果があります。社内の誰が何を触ったかの履歴が残るため、事故が起きたときに原因を追えること。私たちは本番反映を二段階にし、先にステージング環境で直して回帰テストが通ってから本番に出す運用を徹底しています。トレーニング環境は背景色を変え、ひと目で本番と区別できるようにする。地味ですが、この種の工夫が事故を減らします。

AIの内製化そのものの進め方については関連記事: FDEとは何か──AI導入を「成功」させる新しいパートナーの選び方もあわせてご覧ください。

自己診断——この案件は、2028年の7割に入るか

いま進行中、あるいは検討中の案件について、5つの問いに答えてみてください。

1. この仕組みを3か月後に修正するとき、社内の誰が手を動かすか、名前を言えますか。
2. ベンダーが明日いなくなったら、本番環境にアクセスできる社内の人はいますか。
3. 作った機能の判断理由（なぜこの閾値か、なぜこのデータだけか）は、文書に残っていますか。
4. 成果を測る指標は、工数削減以外にありますか。
5. 契約書に、終える条件が書かれていますか。

「はい」が2つ以下なら、放棄される側の典型です。3つか4つなら、契約の巻き直しで間に合います。5つすべてが「はい」なら、相手は本物のFDEです。関係を続けてください。

よくある質問

Q1. 社内に開発できる人が1人もいません。それでもFDEに頼めますか。

頼めます。ただし引き継ぎの到達水準を、コードを書けることに置かないでください。現実的なのは、業務側の担当者が「AIへの指示文とマスタの値を自分で変えられる」ところまでです。コードの改修はベンダーに残し、業務変更への追随だけ自社で回す。この分担なら、情報システム部門がなくても成立します。

Q2. FDEとSES（技術者の派遣）、常駐のSIerは何が違うのですか。

指揮命令と責任の所在が違います。SESは作業時間に対して対価を払う形で、成果の責任は発注側にあります。常駐SIerは要件どおりに作る責任を負いますが、要件を決めるのは発注側です。FDEは、要件そのものを現場で決め直すところから入り、本番で動いて使われている状態に責任を持ちます。見積書の体裁は似ていても、中身は別物です。

Q3. 費用は、ガートナーの発表にある四半期20万ドル（約3,000万円）がかかるのですか。

それはグローバルの大手ベンダーの水準です。日本の中堅企業の案件では、桁が1つ違います。私たちは「共同事業として、500万円程度の予算で現場の課題解決から始める」という形を標準にしています。MVPまでをまとまった金額でインフラ込みで構築し、その後は月額の準委任契約に移る。金額の目安は対象業務によって変わるため、最新の水準は無償の業務プロセス診断でご確認ください。

Q4. 引き継ぎが終わったら、ベンダーとの関係は切れるのですか。

切ってもいいし、続けてもいい——その選択権が自社にある状態が、引き継ぎの完了です。私たちの場合、引き継ぎ後は月次の技術顧問として関わり方を薄くしていく形が多くなっています。関係を切れない状態のまま続く契約と、切れるけれど続けている契約は、見た目が同じでも中身がまったく違います。

まず試すなら

今日から着手できることを3つ挙げます。

1. 進行中の案件について、自己診断の5問に答える。 10分で終わります。「はい」の数が2つ以下だった案件は、次の定例で引き継ぎの話を議題に入れてください。
2. 候補ベンダーに、7つの質問のうち5番と7番だけでも聞く。 「自社の誰が何をできたら引き継ぎ完了か」と「終える条件と、残るもの」。この2問への答え方で、看板倒れはほぼ見分けられます。
3. 自社の業務のうち、AIに任せたい範囲を1文で書く。 「誰の、どの作業の、どこまでを任せるか」。これが書けないまま発注すると、成果の定義もベンダー任せになります。

3つ目でつまずく会社は少なくありません。AI-Pathでは、無償の業務プロセス診断（BPR）を実施しています。ヒアリングをもとに業務の流れを整理し、どの業務にAIが効くのか、どこまでを自社で持つのかを一緒に明らかにします。発注先を決める前の判断材料として、お気軽にご相談ください。

参考リンク

• Gartner「2028年までに企業の70%がベンダーFDE構築のAIエージェントを放棄する」（2026年9月29日・プレスリリース） https://www.gartner.com/en/newsroom/press-releases/2026-09-29-gartner-predicts-70-percent-of-enterprises-will-abandon-agentic-ai-built-by-vendor-forward-deployed-engineering-by-2028
• ITmedia NEWS「『FDEが開発したAIエージェントの7割は使われず、単なるコンサルティングが販売される』 ガートナー予測」（2026年10月7日） https://www.itmedia.co.jp/news/article/2610/07/2000002098/
• Qiita「FDEを『コンサル＋AI』と呼びFDE Washingさせるな！本質は本番環境（Production）への Build & Deploy にある」 https://qiita.com/masamis/items/39f2b943c5bc09498bc6