AIエージェントの内製化で目指すのは、すべてを自社開発することではありません。情報システム・開発部門が、外部支援を受けながらも、自社で評価・修正・運用できる状態へ移ることです。
2026年9月、Gartner発表の全文転載は「2028年までに、ベンダーのFDE（Forward Deployed Engineer）で構築したエージェンティックAIを企業の70%が放棄する」と予測しました。理由はコストの高騰と、自社で進化させられないことです。問われているのは作れるかどうかではありません。作った後に自社で育て続けられるかどうかです。
対象読者は、外部開発からの移行を判断する情報システム部門・開発部門の責任者です。知識移転と出口を契約前から設計できるよう、引き継ぐ対象、必要な役割、確認項目、段階的な移行条件を整理します。
この記事でわかること
- AIエージェントの内製化が「全部自社で作ること」ではない理由と、Gartnerの放棄予測が示す構造
- 外部から自社へ引き継ぐべき対象（プロンプト、ルール、ツール接続、評価データ、運用ログ）
- 内製化に必要な3つの役割と、評価の仕組みを先に作る理由
- 契約前に確認すべき項目と、FDEウォッシングの見分け方
- 契約前・実装中・出口の3段階で進める移行手順と、内製と外注の線引き
AIエージェントの内製化は「自社で改善し続けられる状態」を作ること
AIエージェントの内製化とは、開発を全部自社で行うことではなく、動いているエージェントを自社の人間だけで運用・改善・拡張できる状態にすることです。外部が作ったものを受け取るだけの「納品」と対比すると、違いは明快です。納品は成果物を渡して終わり。内製化は、その後に直し続ける力ごと渡します。
エージェントは作った時点が完成ではありません。業務ルールが変わる、モデルが更新される、現場から「この判断は違う」と指摘が入る。そのたびに調整が要るため、調整できる人が社内にいるかどうかが、使われ続けるかどうかを決めます。
70%放棄予測の中身は「コスト高騰」と「自力で進化させられない」
Gartner発表の全文転載が対象とするのは、ベンダーFDEが構築したエージェンティックAIです。AIエージェント全般の実測の失敗率ではありません。放棄理由として、コストの高騰と、利用企業が自力で進化させられない点が示されています。
FDEとは、ベンダーのエンジニアが顧客の現場に入り、顧客と直接組んで設計・構築・展開まで進めるモデルです。職種そのものの解説はFDE（Forward Deployed Engineer）の役割と導入判断に譲ります。ここで押さえたいのは、FDEは深く入り込める分、抜けるときに何も残らないと依存だけが残るという点です。
費用の面も見逃せません。Gartner発表の全文転載では、提供体制や変更管理の成熟度を伴わないまま、FDEの名称で割増料金を課す事業者がいると指摘しています。金額だけで判断せず、支援範囲、契約期間、知識移転、引き継ぎ後に残る運用費を確認してください。
日本でもFDEとエージェント型AIの議論が進んでいる
ガートナージャパンは2026年9月28日、公式アカウントで「日本におけるクラウドとAIのハイプ・サイクル：2026年」の発表を案内しました。この発表だけで個別企業の導入成否が決まるわけではありません。
採用判断では、話題性に加えて、自社に知識と運用の仕組みが残るかを確かめてください。
FDEが向く課題と、従来型の外注でよい課題
すべてのエージェントを内製にすべきではありません。深い製品知識、素早い適応、顧客環境との密な統合が要る課題には、FDEが向きます。Gartner発表の全文転載では、仕様が明確になった後の作業なら、従来型の契約やパートナーのほうが、費用や成果を予測しやすい可能性を指摘しています。
順序は「FDEで立ち上げる→知識を移す→自社の運用に切り替える」。最初から出口までを一本の線として設計するのが現実的です。
外部から自社へ引き継ぐ対象は「ハーネス」と「評価データ」と「運用ログ」
引き継ぎの対象は、ソースコードだけではありません。エージェントの挙動を決めているのは、モデルの周辺にある仕組み。プロンプト、ルールファイル、ツール接続、評価データ、運用ログです。これらが自社の手元にない限り、内製化は成立しません。
引き継ぎ対象の一覧と確認観点
この周辺の仕組みを、当協会ではハーネスと呼んでいます。詳細はハーネスエンジニアリングとはで扱っていますが、ここでは引き継ぎの視点で整理します。以下は当協会の実務上の整理であり、調査データに基づく分類ではありません。
| 対象 | 中身 | 引き継げているかの確認 |
|---|---|---|
| プロンプト・ルールファイル | エージェントの役割、禁止事項、判断基準を書いた文書 | 自社のリポジトリに置かれ、変更履歴を自社で追えるか |
| ツール接続 | 社内システムやAPIへの接続定義、認証の設定 | 接続先の認証情報の管理者が自社になっているか |
| 評価データ | 「この入力にはこう答えるべき」という正解例の集まり | 自社が追加・修正でき、変更のたびに実行できるか |
| 運用ログ | 実際の入出力、失敗例、利用者のフィードバック | 自社がログを参照・出力でき、保持期間と削除条件が決まっているか |
| 設計意図の文書 | なぜこの構成にしたか、何を試して捨てたか | 新任者が読んで直す箇所を判断できるか |
表のうち、特に確認したいのは評価データです。評価データがなければ、プロンプトを直したときに良くなったのか悪くなったのかを判断できません。ベンダーの頭の中にだけ「前はこうだった」が残っている状態では、自社では怖くて触れなくなります。
評価の仕組みを先に作る理由
内製化の最初の実作業は、機能追加ではなく評価の整備です。修正前後で同じ質問群を流し、結果を比べる。この最小の仕組みがあって初めて、自社の人間がプロンプトに手を入れられます。
質問群は最初は少数で構いません。実際に現場で起きた失敗事例と、必ず守らせたい境界ケースを混ぜてください。外部FDEが現場に入っている間に質問群を一緒に作ると、自社で品質を判断するための知識を引き継げます。
検証例として、社内規程を回答するエージェントでは、「参照権限がない文書は開示しない」「規程に根拠がなければ担当者へ確認を促す」を期待動作にします。修正後も同じ質問で確認し、通常の回答だけでなく、禁止した操作や人への引き継ぎも評価してください。
運用に必要な3つの役割
内製化に必要な役割は、企画、開発、運用の3つです。人数ではなく役割で考えます。小さな組織なら兼務で構いませんが、誰がどの役割かは名前で決めてください。
企画役は、どの業務にエージェントを使い、何をもって成功とするかを決めます。開発役は、プロンプトやツール接続を直し、評価を回します。運用役は、日々のログを見て異常に気づき、障害時に判断します。特に運用役の不在は、エージェントが放置される原因になりやすい点です（当協会の見立て）。
AIの判断範囲と、人間が確認する範囲を文書にしておくことも運用役の仕事です。総務省・経産省が公表したAI事業者ガイドライン第1.2版は、AIを開発・提供・利用する事業者が必要な取り組みを検討するための基本的な考え方を示しています。社内ルールを検討する際の確認項目として使えます。
この3役を担う人材は、採用だけに頼らず社内で育てる選択肢があります。AIを使った開発の基本から実務への落とし込みまでを体系的に学ぶ場として、AI駆動開発研修があります。導入全体の進め方はAI駆動開発の導入ガイドでも整理しています。
契約前に確認すべき点は、成果責任・知識移転・出口の3つ
ベンダーとの契約では、成果に責任を持つのは誰か、知識はどう移るのか、いつどう抜けるのか、の3つを確認します。曖昧なまま進めると、引き継ぎの範囲や責任を巡る認識のずれが生じやすくなります。
FDEの提供体制を見極める3つの観点
Gartnerは、導入支援やAIコンサルを「FDE」と呼び、提供体制に見合わない高額な料金を課す動きに注意を促しています。いわゆるFDEウォッシングです。
Gartner発表の全文転載が示す3つの観点は次のとおりです。
- 成果責任がある。納品物ではなく、事業成果と本番での安定稼働で評価される
- 事業成果で成功を測る。請求時間や特定製品の採用だけを成功指標にしない
- 顧客の現場と密に連携する。必要なアクセス権限を合意し、依頼票だけでは伝わらない業務上の判断も共有しながら改善する
これらは提供体制を評価する観点です。成果連動報酬や無制限のアクセス権限を必須条件とせず、見積もり時に責任範囲と成功指標、協働の方法を確認してください。
契約書に明記する項目
契約の確認項目は、出典の性質ごとに分けて整理すると混乱しません。Gartner由来の考え方を土台に、データの扱いとして国内のガイドライン類で論じられている論点、当協会の実務上の見立てを加えています。
| 区分 | 確認項目 |
|---|---|
| Gartnerの公式発表 | 成果責任を持つ役員を置く／成果物・知識移転・知的財産・出口の責任を契約に書く／出口を予定どおり実行し契約延長に流さない |
| データの扱い | データの持ち出し可否、保持期間、学習への利用有無、ログの帰属、削除、再委託先 |
| 成果物の権利 | プロンプト、設定、コード、評価データ、運用ログの帰属と利用権 |
| 当協会の見立て | 引き継ぎ資料の形式と更新頻度／ベンダーが抜けた後の問い合わせ窓口と期間／移行にかかる費用の事前合意 |
成果物の権利は、特に曖昧になりやすい箇所です。AIの開発契約では、学習済みモデルや成果物の知的財産、ノウハウの扱いを段階ごとに決めておく考え方が、経産省の「AI・データの利用に関する契約ガイドライン」AI編で整理されています。条項の具体例は法務の確認が前提で、本稿では個別の文言までは断定しません。
契約前にそのまま使える質問リスト
見積もりの打ち合わせで、次の質問を投げてください。答えが曖昧な項目は、契約前に責任者や条件を具体化してもらいましょう。
- このプロジェクトの成果責任は、御社側の誰が持ちますか。何をもって成功とみなしますか。
- 半年後に、御社のエンジニアが抜けても、当社の社員だけでプロンプトとツール接続を直せる状態にできますか。そのために何を渡しますか。
- 評価データと運用ログは、誰のものになりますか。契約終了後も当社で使えますか。
- 出口の期日と条件を契約に書けますか。延長する場合の判断基準は何ですか。
- 導入後にモデルや外部サービスを切り替えるとき、費用は誰が負担しますか。
5問目では、モデル切り替え時の費用の範囲を確認します。出力の品質、ツール呼び出しの形式、扱える文章量、コスト、評価基準の再確認を誰が担い、どう費用を見積もるかも合意してください。外部FDEサービスの比較軸そのものはFDEサービスの選び方にまとめています。
契約前・実装中・出口の3段階で、知識移転を計画に埋め込む
移行は、契約前に出口を決め、実装中に知識を移し、出口で自社運用へ切り替える3段階で進めます。既に開発済みなら、引き継ぎ対象と権限の棚卸しから始めてください。新規案件では、実装開始時から知識移転を計画します。
段階ごとにやることと完了の目安
| 段階 | やること | 完了の目安 |
|---|---|---|
| 契約前 | 成果指標と責任者を決める。移行と運用の責任者を自社から指名する。契約に知識移転・成果物の権利・出口を書く | 出口の期日と条件が書面にある |
| 実装中 | FDEを業務に詳しい自社チームに埋め込む。評価データを一緒に作る。AIの判断範囲と人の確認範囲を文書化する。段階ごとに業務検証する | 自社の担当者がプロンプトを直し、評価を回せる |
| 出口 | 自社が管理・最適化・拡張できるかを確認する。合意した移行条件を満たせば運用を切り替える。未達なら不足する作業・責任者・期限を明確にする | 外部の支援なしで、1サイクルの改善を自社で完了できる |
出口の判定は「動いているか」ではなく、「自社が直せるか」で行います。たとえば出口の直前に、現場から上がった不具合を1件選び、外部のエンジニアは見ているだけにして、自社の担当者に修正から評価までやらせてみてください。詰まった箇所が、そのまま引き継ぎの不足です。
FDEを使いながら移す期間の設計
外部FDEの稼働を、時間とともに絞るのが基本です。立ち上げ期は外部が手を動かし、自社が横で見る。中盤は自社が手を動かし、外部が確認する。終盤は自社だけで回し、外部は相談窓口に下がる。この役割の逆転を、計画に月単位で書いておきます。
逆転が進まないときは、自社の担当者が兼務で時間を取れていないかを確認します。外部が「直したほうが早い」と先に手を動かしていないかも見直してください。前者は担当業務を調整して時間を確保し、後者は成果指標に「自社担当者が自力で対応した件数」を入れるなど、支援の目的を揃えます。
導入した直後のエージェントは、現場に最適化されていません。当協会では、この「育てる」段階をFDEによる継続的な最適化・保守として支援しています。プロンプトやルールファイル、ツール接続といったハーネスを継続的に調整し、障害時の保守対応や運用の質問にも対応します。自社運用へ切り替えるまでの橋渡しが必要か、現在の体制から整理します。
内製と外注の線引きは「判断と評価は自社、共通基盤は外部」
内製か外注かの二択にはしません。判断と評価、データの設計は自社に置き、共通基盤や周辺業務は外部に任せる。外部で検証して、効果が確認できた部分だけを内製に移す。この分け方が、費用も人員も無理がありません。
| 自社に置く | 外部に残してよい |
|---|---|
| どの業務に使うかの判断、成功指標 | 共通基盤の構築・保守 |
| 評価データの設計と更新 | 定型的な周辺システムの開発 |
| 運用ログの確認と改善の優先順位づけ | 専門性が高く頻度の低い障害対応 |
| データの取り扱いと権限の方針 | 新しいモデルの検証の下調べ |
評価データと判断基準を自社が握っていれば、外部ベンダーを入れ替えても品質を比較できます。ベンダー依存の正体は、作る力の不足ではありません。良し悪しを判定する力が社外にあることです。
内製化を急がないほうがよい場合
効果が確認できていないエージェントの内製化を急ぐのは、順番が逆です。まずFDEや小さなPoCで価値を確かめ、本番で使われる見込みが立ってから、体制づくりに投資します。
もう一つ、運用役を置けない場合も内製化は危険です。担当者が決まらないまま引き継げば、放置されるだけです。その場合は外部の運用支援を契約に残したまま、自社の担当者を1人指名するところから始めてください。国内の導入事例の傾向はFDEの導入事例で確認できます。
よくある質問
Q. プログラミング未経験でもAIエージェントの内製化に参加できますか？
参加できます。業務担当者は、期待する回答例や失敗例を評価データにまとめます。API連携、認証、障害対応は開発担当者と分担し、担当者を置けない間は外部支援を残してください。
Q. 外部FDEを使うと、必ず依存してしまいますか？
必ず依存するわけではありません。契約で知識移転、成果物の利用権、出口の期日を合意します。出口では、自社担当者が外部支援なしで1回の修正と評価を完了できるか確認してください。
Q. AIエージェントの内製化費用は何を含めて見積もりますか？
初期開発と引き継ぎに加え、社内工数、モデル利用料、クラウド、連携ツール、評価、監視、保守を含めます。外注と比較するときは、対象業務、利用量、期間を揃えて見積もってください。
Q. 内製化にはどんな人材が必要ですか？
企画、開発、運用の3役です。企画役は対象業務と成功指標、開発役は修正と評価、運用役はログ確認と障害対応を担います。兼務でも、担当者名と判断範囲は文書で決めてください。
Q. 内製化にかかる期間はどう決めればよいですか？
対象業務、システム連携、担当者が確保できる時間で決めます。契約前、実装中、出口の3段階に期限を置き、自社だけで1回の修正、評価、障害対応を完了できることを最終条件にします。
まとめ
最初の一歩は、いま依頼している、または検討中のベンダーに、先ほどの5つの質問を投げることです。答えから、出口が設計されているかどうかがわかります。
次に、自社側の運用担当者を1人指名してください。兼務で構いません。そのうえで、評価データを、外部のエンジニアと一緒に作り始めます。外部とデータを共有する場合は、既存契約の利用範囲と機密情報の扱いを確認してから進めてください。
新規契約では、出口の期日と移行条件、成果物の利用権を契約前に合意します。既に契約中なら、次の更新を待たずに引き継ぎ範囲を確認し、必要な変更を協議してください。
自社の状況に合わせた移行設計や運用体制の整理を検討する場合は、月額AI顧問サービス（CAIO）でご相談を受け付けています。AI人材の育成を先に進めたい場合は、AI駆動開発研修を確認してください。
