作った AI エージェントが使われなくならないために：開発を外部に頼む前に確認したい 3 つのこと

AI エージェントや業務アプリの開発を、外部のエンジニアに頼もうと考える会社が増えています。社内に AI 開発の経験者が少ないうちは、現場に入り込んで一緒に作ってくれる支援は心強い選択肢です。

ところが、そうして作ったものが使われなくなる可能性を指摘する予測が出ました。この記事では、その予測を手がかりに、開発を外部に頼む前に事業責任者が確認しておきたい 3 つの観点を整理します。

ガートナーの予測：FDE で作られた AI エージェントの 7 割が放棄される

米調査会社のガートナーは 2026 年 9 月 29 日に、「ベンダーの FDE（フォワードデプロイドエンジニアリング）で開発された AI エージェントの 70％が、2028 年までに放棄される」という予測を発表しました。Publickey の紹介記事（2026 年 10 月 7 日）によると、FDE とは、ベンダーのエンジニアが顧客企業の現場に入り込み、顧客固有の課題に合わせて AI を使ったサービスやソフトウェアを共同で開発する人、あるいはその開発モデルを指します。

ガートナーは、FDE を使うときの次の 3 原則を示し、満たさないと失敗しやすいと警告しています。

• FDE は、深い製品専門知識と迅速な適応が必要な問題に限って使う
• FDE を社内の業務専門家・技術者・エンドユーザーに浸透させ、知識を共有する
• 出口戦略を最初から明確にする

これらの原則を満たさないまま「フォワードデプロイド」という言葉が、実装やプロフェッショナルサービスの呼び名として使われるケースが多いとも警告しています。また、FDE の名前でコンサルティングが売られる危険（記事の見出しでは「FDE 洗浄」）が高まるとしています。さらに、FDE で得た顧客のニーズをコア製品に反映できるベンダーは 20％未満としています。

なお、これは調査会社の予測であり、実際に 7 割が放棄されると決まったわけではありません。また、ガートナーの原文（プレスリリース）は私たちが直接確認できておらず、ここでの内容は Publickey の要約によるものです。ただ、示されている 3 原則のうち後半の 2 つは、FDE という形態に限らず、外部に開発を頼むときに共通して確認しておく価値があると私たちは考えています。

観点 1：作ったものを自社で動かし続けられる状態で引き渡されるか

ガートナーの原則の 2 つ目は、知識を社内に共有することでした。外部の人が現場に入って作ったものが、その人たちがいなくなったとたんに誰にも直せなくなる、というのは容易に想像できる状況です。

ここで確認したいのは、次のような点です。

• 作ったものの設計や判断の理由が、文書として残るか
• 開発のルール、テスト、CI など、変更しても壊れていないことを確かめる仕組みが一緒に引き渡されるか
• 納品後に、自社のエンジニアや別の会社が変更を加えられるか

AI にコードを書かせる開発では、特に 2 つ目が重要になると私たちは見ています。AI は指示に沿ってコードを大量に書けますが、既存の仕組みを壊していないかを確かめる仕組みがなければ、変更のたびに品質が不安定になりかねません。AI 開発用のルールやテストは、人が入れ替わっても品質を保つための「引き継ぎ資料」の役割も果たします。

観点 2：「出口」がはじめに決まっているか

原則の 3 つ目は、出口戦略を最初から明確にすることです。外部の支援は、いつかは終わります。そのとき、自社だけで運用するのか、別の会社に引き継ぐのか、継続して支援を受けるのか。これが契約の前に決まっていないと、支援が終わる時点で選択肢が限られます。

出口を考えるときは、次の問いが役に立ちます。

• どこまでを外部が作り、どこからを自社で持つのか（役割分担の境目）
• 支援が終わったあとの運用や改修を、誰がどう担うのか
• 継続して支援を受ける場合に、何を頼めて何は自社で行うのか

たとえば、納品後は自社で AI を使って開発を進めたい会社と、引き続き開発を任せたい会社とでは、必要な引き渡し物がまったく違います。前者であれば、前述のルールやテストの整備が中心になりますし、後者であれば、依頼のしかたや進め方の取り決めが中心になります。どちらを選ぶのかを、作り始める前に話し合っておくことが大切です。

観点 3：最初に小さく動かして、業務で使えるか確かめているか

ガートナーが示した原則は 3 点ですが、それとは別に、実務上の対策としてもう 1 つあります。それは、大きく作る前に、小さく動かして確かめることです。これは予測の中に書かれているものではなく、私たちの考えです。

AI を使うと、動くプロトタイプを短期間で作れます。実際に業務で使う人が触れる状態にして、本当に使われそうかを確かめてから本格的な開発に進めば、「作ったのに使われなかった」という失敗の確率を下げられるはずです。確認したいのは次の点です。

• 主要な業務の流れを 1 本、実際の環境に近い状態で動かせるか
• 現場の担当者が実際に触れて、使い勝手や抜けを指摘できるか
• その結果を、次に作る範囲の判断に反映できるか

「AI で作ったプロトタイプは捨てるか育てるか」では、プロトタイプを本番開発の土台につなげる準備を扱いました。小さく試すことと、土台として育てられる形で作ることは、あわせて考えると効果的です。

依頼先に聞いてみたい質問

ここまでを、依頼先との打ち合わせで使える質問にまとめます。

1. 納品物に、設計の記録、開発ルール、テスト、CI は含まれますか
2. 納品後に、自社（または別の会社）が変更するとき、何を手がかりにできますか
3. 支援が終わる時点の選択肢（自社運用、引き継ぎ、継続支援）を、契約前に整理できますか
4. 本格的に作る前に、小さく動かして確かめる段階はありますか
5. 「FDE」や「伴走」といった言葉は、具体的に何をどこまでやることを指していますか

最後の質問は、特定の会社を疑うためのものではありません。呼び名が同じでも、支援の中身は会社ごとに異なります。言葉ではなく、成果物と役割分担で比べるのが確実です。

まとめ

ガートナーの予測は、外部に開発を頼むこと自体を否定するものではありません。ガートナーが示した原則のうち、知識の共有と出口戦略は、依頼する側が事前に確認できるものです。確認しておけば、使われなくなるリスクを減らせると私たちは考えています。

• 自社で動かし続けられる状態（ルール、テスト、CI を含む）で引き渡されるか
• 支援の終わりのあとの姿が、はじめに決まっているか
• 小さく動かして、業務で使えるかを確かめてから進めているか

私たちは、本開発の前に技術的に実現できるか（PoC）や、ユーザーに使ってもらえるか（MVP）を短期間で確かめる「AIプロトタイプ・MVP開発」と、要件定義から公開後の改善までを一貫して支援する「SaaS・業務アプリ開発」を提供しています。依頼先に聞く質問リストの作成や、いま検討中の依頼内容の見直しのご相談にも応じています。業務アプリや SaaS の開発の進め方でお悩みでしたら、お気軽にご連絡ください。