AI エージェントの内製化の課題：外注、FDE、AI + RPA の比較

外部に頼んで作った AI エージェントが、本番で動き始めた。数か月後、使っている AI モデルの提供終了の通知が届く。取引先のサイトの画面が変わる。社内のルールも変わる。そのたびに見積もりを取り、改修の順番を待つ間、業務は手作業に戻ります。

AI エージェントは、作った後も直し続ける必要があります。そのため、外注か、FDE（Forward Deployed Engineer）か、内製かを選ぶときに大事なのは、最初に作る速さよりも、誰が、どの速さで直せるかです。この記事では、AI エージェントの 4 つの進め方を比べ、内製化の課題と選び方を解説します。

結論：作る速さより、直す速さで選ぶ

• AI エージェントは作って終わりにならない：AI モデルの提供終了、モデルの版による挙動の違い、画面や業務ルールの変更が続く
• 選ぶ基準は、変更を誰がどの速さで直せるか：最初に作る速さや費用だけで選ばない
• FDE や外注は、立ち上げや難しい統合に使う：契約の前に、引き継ぎと終わり方を決めておく
• 変更の多い業務は、業務を知る社内の担当者が直せる形にする：直した理由、承認、全体の台帳を残す仕組みと一緒に

AI エージェントは、作って終わりにならない

作った後に起きる変更は、主に 3 つです。

変更	例	すること
AI モデルの提供終了	Anthropic は少なくとも 60 日前に通知し、提供終了の後のリクエストは失敗する。OpenAI は 2026 年 10 月 14 日に、GPT-4o や GPT-4.1 などを 2027 年 1 月 14 日に API から外すと通知した	代わりのモデルに替え、業務で試してから切り替える
モデルの版による挙動の違い	OpenAI は、同じ系統のモデルでも、版が違えば結果が変わりうると説明している	版を固定し、替えるときは同じ入力で結果を比べる
画面や業務ルールの変更	取引先のサイトの更新、帳票の項目の追加、承認の基準の変更	手順やプロンプトを直し、止まった処理をやり直す

Anthropic は、提供終了の日よりかなり前に、代わりのモデルで自社の用途を十分に試すよう勧めています。OpenAI も、モデルの版を替えるときに備えて、プロンプトの挙動を測るテストと評価の仕組みを作るよう勧めています。

経済産業省と総務省の AI 事業者ガイドライン（第 1.2 版）も、新しい技術の出現や規制の変更などの外部環境の変化を速やかに把握し、適時に再評価して、AI システムの改良や運用の改善を行うことを期待しています。

変更そのものは避けられません。問われるのは、変更が来たときに、誰がどの速さで直せるかです。画面の変更で自動化が止まる理由は「RPA が画面変更で止まる理由」で、直されないまま使われなくなる例は「AI エージェントの失敗例」で解説しています。

AI エージェントの 4 つの進め方

1. 外注（受託開発）

SIer や開発会社に、要件を伝えて作ってもらう形です。作った後の変更は、保守契約の範囲か、その都度の見積もりで行います。

2. FDE（Forward Deployed Engineer）

ベンダーのエンジニアが顧客の現場に入り、顧客と直接やり取りしながら作って導入する形です。Palantir が始めた職種で、AI の広がりとともに増えています。日本でも日経クロステックが、IT 大手 4 社が FDE の拡充に意欲を示し、日立は 2026 年度内に国内で 1,000 人にする、と報じています。

3. エンジニアによる内製

社内のエンジニアが、AI モデルの API や開発の枠組みを使って作る形です。自由度は最も高い一方、エンジニアの確保と、作った後の運用の体制が要ります。

4. 業務の担当者が AI と作る（AI + RPA）

業務を知る社内の担当者が、AI のアシスタントとの会話で手順を組み、画面の操作は AI が覚えて繰り返す形です。対象は、社内の業務の自動化です。AI と RPA の組み合わせ方は「AI エージェントと RPA の使い分け」で解説しています。

4 つの進め方の比較

	外注	FDE	エンジニアによる内製	業務の担当者が AI と作る
作る人	外注先	ベンダーのエンジニア（社内と一緒に）	社内のエンジニア	社内の業務の担当者
立ち上がり	要件定義と契約の後	速い	エンジニアがいれば速い	担当者が覚える分だけかかる
変更 1 回の流れ	依頼、見積もり、改修、検収	契約の期間中は速い。終わった後は社内か外注先	エンジニアの手が空けば速い	担当者がその場で直す
費用の形	作るたび、直すたび	エンジニアが入る期間の費用。割高になりやすい	エンジニアの人件費	ツールと担当者の時間
社内に残るもの	動いている仕組み	引き継ぎ次第	仕組みと、作れるエンジニア	仕組みと、直せる担当者
向く業務	当面変わらない業務	製品の深い知識や、複雑な統合が要る業務	自社の製品やサービスに組み込む AI	変更の多い社内の業務

費用の具体的な金額は「業務自動化の外注費用」で比べています。

FDE と外注で起きやすいこと

Gartner は 2026 年 9 月、2028 年までに企業の 70% が、ベンダーの FDE が作ったエージェント型 AI を使うのをやめると予測しました。費用が膨らみ、自分たちで進化させられなくなるためです。早い段階では進みが速く見えても、社内に力が育たず、範囲がはっきりした後は従来の委託でも安くできる作業に、割高な費用を払い続けることになりうる、と指摘しています。

同じ発表で Gartner は、2028 年までに、顧客の繰り返しの要望をベンダーの製品の機能に変えられる FDE の契約は 20% 未満にとどまると予測しています。実装支援やコンサルティングを FDE と呼んで売る「FDE washing」にも注意を促しています。

一方で、Gartner は FDE を否定していません。製品の深い知識、速い適応、ベンダーの技術と顧客の環境の密な統合が要る問題にだけ使うよう勧めています。契約の前に、成果物、知識の引き継ぎ、知的財産の権利、終わり方を決め、社内の準備ができていないからと延長せずに、最初に決めた出口を実行するよう勧めています。成功は導入を終えたことではなく、企業が自分で管理し、改善し、広げられるかで測る、としています。

外注でも、変更が保守契約の範囲を超えると、見積もりと改修を待つことになります。どちらの場合も、確かめることは同じです。

確かめること：

• 作ったもの（コード、プロンプト、設定、評価の仕組み）の権利は誰が持つか
• 何を、いつまでに引き継ぐか（文書、手順、直し方）
• AI モデルの API を、自社と外注先のどちらが契約するか。提供終了の通知は契約している側に届く
• 契約が終わった後、モデルの提供終了の通知が来たら、誰が直すか

内製化の本当の課題

内製化の課題は、人です。JUAS の「企業 IT 動向調査 2026」では、システム開発の内製化を進めるうえでの課題として、「開発人材の量の不足」を 52.7%、「開発人材の質の不足」を 49.6%、「プロジェクトマネジメント人材の不足」を 44.4%、「現行業務への理解不足」を 38.2% の企業が挙げました（2025 年度、953 社）。IPA の「DX 動向 2026」でも、AI の導入と運用の課題で最も多いのは「専門人材が不足している」（50.1%）です。

JUAS は前年の報告書で、現行業務への理解不足から内製化に踏み切れず、既存のベンダーに任せて、社内に知見がたまらない状況がうかがえる、と分析しています。

ここに、内製化の難しさがあります。エンジニアは足りず、業務を知らないことがある。業務を知る担当者は、プログラムを書けない。社内の業務の自動化なら、AI がこの溝を埋められます。担当者が業務の言葉で手順を伝え、AI が組み立て、画面の操作を覚えるためです。

ただし、社内で作っても、作った人しか直せなければ、外注より悪くなります。直した理由を残し、誰が何を承認したかを記録し、台帳で全体を把握する仕組みが要ります（「作った人がいない RPA ロボットの引き継ぎ方」「RPA のロボット管理台帳」）。

確かめること：

• 変更の多い業務を知っている担当者は誰か。その人が直す時間を取れるか
• 担当者が異動しても、別の人が直せる形で残るか
• モデルを替えたときに、同じ入力で結果を比べる手順があるか
• 取り消しにくい操作の前に、人の承認があるか

どれを選ぶか

1. 変更が多く、業務を知る担当者がいる社内の業務：担当者が AI と作る
2. 自社の製品やサービスに組み込む AI、複雑なシステムの統合：エンジニアが内製する。立ち上げに FDE を使うなら、出口を最初に決める
3. 当面変わらない業務、担当者を置けない業務：保守契約つきで外注する
4. 混ぜてかまわない：JUAS の調査でも、企業が主に目指しているのは内製と外部委託の使い分けです

例：モデルの提供終了の通知が来たら

提供終了の通知は、AI モデルの API を契約している側にメールで届きます。外注先が契約していれば、社内では気づかないこともあります。通知が届いた後に、4 つの進め方でそれぞれ何が起きるかを比べます。

進め方	直して試す人	待つこと
外注	外注先	見積もり、改修の順番、検収
FDE	契約の期間中は FDE。終わった後は社内か外注先	契約が終わっていれば、新たな契約か引き継ぎ
エンジニアによる内製	社内のエンジニア	エンジニアの手が空くまで
業務の担当者が AI と作る	社内の業務の担当者	代わりのモデルで試す時間だけ

どの進め方でも、代わりのモデルで業務を試す時間は要ります。違いは、試して直すまでの間に、契約や順番待ちが挟まるかどうかです。

よくある質問

FDE と、常駐する SIer のエンジニアは何が違いますか？

FDE は、ベンダーの技術を顧客の環境に合わせて導入するため、ベンダーのエンジニアが現場に入る形です。ただし Gartner は、実装支援やコンサルティングを FDE と呼んで売る例があると指摘しています。呼び名よりも、作ったものの権利、引き継ぎ、終わり方が契約に書かれているかで見極めます。

業務の担当者に、AI エージェントを作れますか？

社内の業務の自動化なら、作れます。手順を業務の言葉で伝えれば、AI が組み立てます。ただし、例外の扱いや承認の置き方は、最初は経験のある人と一緒に決めたほうが早く進みます。自社の製品に組み込む AI のように設計の判断が多いものは、エンジニアの領域です。

外注で作った AI エージェントを、社内に移すには？

まず、何がどこで動いているかを一覧にし、止まりやすいものと変更の多いものから移します。手順は「RPA から AI RPA への切り替え手順」で解説しています。移す前に、作ったものの権利と、引き継ぐ資料を契約で確かめてください。

Kitewell で直し続ける

Descarty の Kitewell は、AI が作って AI が直す AI RPA です。業務の担当者が、会話で作り、会話で直します。

• 会話で作り、会話で直す：アシスタントに頼むと、変更の内容とフロー図を示します。「適用」を押すまで保存されず、「元に戻す」で戻せます
• モデルの交代は 1 か所で：AI モデルは「エージェントとモデル」に登録し、ワークフローはその登録を参照します。提供終了の通知が来たら、登録を替えるだけで、それを使うワークフローすべてに反映されます。「モデルをテスト」で、替えたモデルにつながるかを確かめられます
• 覚えた操作は、モデルを替えてもそのまま：一度うまくいった画面の操作は覚えて、AI を使わずに繰り返します。覚えた操作はモデルに結び付いていないため、モデルを替えても覚え直しは要りません
• 止まった理由を AI が見立てる：失敗の見立てを設定すると、失敗が続き始めたときに、AI が「もう一度試す」「対応が必要」「ワークフローの変更」「不明」に分けて、原因と次にすることを示します。「エディターで修正」から直して「保存して続行」を選ぶと、失敗したステップから続きを動かします
• 試してから本番へ：ステップを 1 つずつテストでき、「編集履歴」で前の版と比べて「このバージョンに戻す」ができます。「リリース」で、ワークフローを固定したコピーを別のプロジェクトに適用でき、古いリリースを適用すれば元に戻せます
• 直した理由をナレッジに：何のためのワークフローか、どんなルールに従うか、何が壊れてどう直したかを残し、アシスタントは毎回それを読んでから答えます
• 直した版はチーム全員に：Dagu Cloud で同期すると、誰かが直したワークフローとナレッジが、各端末に届きます
• 台帳で全体を把握：ロボット管理台帳を Excel で書き出せます
• AI エージェントもステップに：Claude Code や Codex など 15 種類の AI エージェントを、ワークフローのステップとして動かせます。差し戻せば、コメントを添えてやり直させられます

Descarty の支援は、FDE ではありません。PoC では、Descarty が貴社のご担当者と一緒にワークフローを作り、効果を確かめます。本番のワークフローは、ご担当者が Kitewell のアシスタントとの会話で作り、直します。Descarty は、構築支援で対象業務の切り出しや例外と承認の設計を手伝います。法人向けの保守サポートでは、AI が直せなかった停止の原因の切り分けや、アップデートによる影響の確認を行います。作ったものも、直せる力も、最初から貴社に残ります。

まずは、外注先に直してもらっている業務や、変更の多い業務を 1 つ選び、先行利用パートナーとして共同で検証できます。詳しくは「先行利用パートナー様募集」をご覧ください。

まとめ

• AI エージェントは、モデルの提供終了、版による挙動の違い、画面や業務ルールの変更で、作った後も直し続ける必要がある
• 外注、FDE、内製は、作る速さより、変更を誰がどの速さで直せるかで選ぶ
• FDE を使うなら、契約の前に引き継ぎと出口を決め、その出口を実行する
• 内製化の課題は人。社内の業務の自動化なら、業務を知る担当者が AI と作ることで、エンジニアの不足と業務の理解不足を同時に補える
• どの形でも、直した理由、承認、全体の台帳を残す

出典

• Gartner：Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028（2026 年 9 月 29 日）
• Anthropic：Model deprecations
• OpenAI：Deprecations
• OpenAI：Prompt engineering
• 経済産業省・総務省：AI 事業者ガイドライン（第 1.2 版）（2026 年 3 月 31 日）。外部環境の変化への対応は別添の行動目標 6-1
• Palantir：Forward Deployed Software Engineer, New Grad - Commercial
• 日経クロステック：IT大手4社、脱・人月へFDE拡充に意欲　日立は26年度内に国内1000人（2026 年 8 月 17 日）
• JUAS：企業IT動向調査2026 報告発表資料（2026 年 4 月 10 日）。内製化を進めるうえでの課題は 38 ページ
• JUAS：企業IT動向調査報告書 2025。システム開発の内製化は 8.2
• IPA：DX 動向 2026（2026 年 7 月 30 日）。AI 導入・運用上の課題は図表 3-16