AIエージェント開発の費用と進め方｜自社開発・外注・開発会社の選び方

AIエージェント開発は、「既製ツールで作る」「SDKで自社開発する」「開発会社に頼む」の3つから選べます。どれを選んでも、対象業務の決定、データと権限の用意、合否の判断は自社に残ります。費用は開発会社5社の公表値で見ると、PoC（小さく試して効果を確かめる検証）が50万〜300万円程度を中心に、高めの会社で1,000万円程度です。本番化は数百万〜数千万円と幅があり、その差は業務の複雑さ、連携するシステムの数、任せる自律度、運用範囲で決まります。

この記事は、AIエージェントで業務を自動化したい事業責任者、情報システム部門、DX推進の担当者に向けて、「自分たちで作れるのはどこまでか」「どこから外注すべきか」「いくらかかるのか」「どの開発会社に何を聞けばよいか」を1本で判断できるように整理したものです。個別の論点をさらに深く知りたい場合は、各節から専門の記事へ進めるようにしています。

本記事の情報について: 製品の仕様・料金、調査の数値は2026年10月1日時点で各公式ページと公表資料を確認した内容です。料金や機能は改定が多いため、契約前に必ず各公式ページで最新の情報を確認してください。費用相場は各開発会社が自社サイトで公表している目安を並べたもので、特定の案件の見積もりではありません。

AIエージェント開発とは何を作ることか

AIエージェント開発とは、大規模言語モデル（LLM）に社内システムやデータを操作する道具を持たせ、業務を自律的に進める仕組みを作ることです。ただし「エージェント」と呼ばれるものの中にも、処理の順番をあらかじめ決めておく型と、手順そのものをモデルに任せる型があり、どちらを作るかで難易度と費用が大きく変わります。

Anthropicは技術記事Building effective agentsで、この2つを区別しています。ワークフローは「LLMとツールを、あらかじめ決めたコードの経路で動かす仕組み」、エージェントは「LLMが自分で処理の進め方とツールの使い方を決め、タスクの進め方を制御し続ける仕組み」です。同じ記事は、まず最も単純な解決策を探し、必要なときにだけ複雑さを足すことを勧めており、エージェント的な仕組みを作らないことが答えになる場合もあると明記しています。エージェント的な仕組みでは、多くの場合、性能が上がる代わりに応答時間とコストが増えるためです。

業務に置き換えると、次のような違いになります。

発注前にこの区別を社内で共有しておくと、見積もりの比較がしやすくなります。「エージェントを作りたい」と伝えた相手が、実はワークフローで十分な業務に自律的な仕組みを提案している場合、費用と運用の負担が必要以上に大きくなるためです。調査会社のGartnerも2025年6月25日のプレスリリースで、エージェントとして売り出されている用途の多くは、エージェントとして実装する必要がないと指摘しています。

AIエージェントそのものの仕組みや、生成AI・チャットボットとの違いから知りたい場合は、AIエージェントとは何かを解説した記事を先に読むと、この先の比較が理解しやすくなります。

AIエージェントに向く業務と向かない業務

AIエージェントに向くのは、量が多く、判断の型がある程度決まっていて、誤りを人が確認して直せる業務です。反対に、1回の誤りが取り返しのつかない損害になる業務や、判断の根拠を説明できないと困る業務は、人が最終判断をする形でなければ向きません。

業務ごとに、効果の出やすさと注意点を整理すると次のようになります。ここでは特定の企業の成果の数字ではなく、どんな条件で効果が出やすいかという傾向を示します。

どの業務にも共通するのは、「AIが下ごしらえをし、人が判断と確認をする」分担から始めると、最初の成果が安定しやすいという点です。いきなり全自動を目指すと、誤りが起きたときに原因の調査と信頼の回復に時間がかかり、現場で使われなくなるおそれがあります。人の確認を多く残した半自動で始め、正しく処理できる割合を記録しながら、確認を減らしていく進め方が現実的です。

事例紹介を読むときも、同じ見方が役立ちます。処理時間の削減率のような印象的な数字があっても、どの業務の、どの範囲を、どれくらいの期間で測ったのかが書かれていなければ、自社にそのまま当てはめることはできません。自社の業務と量や難しさが近いか、測り方が明示されているかを確かめたうえで参考にしてください。

自社で作るか、外注するか：3つの開発手段

AIエージェントの開発手段は、既製ツール・ノーコードで作る、SDKで自社開発する、開発会社に依頼する、の3つです。選び分けの分かれ目は、既製ツールの範囲で業務が完結するかと、本番運用まで担える開発者が社内にいるかの2点です。

上の図のとおり、最初の問いは「既製ツールの範囲で業務が完結するか」です。ここで「完結する」と言えるのは、連携先のシステムがツールの標準コネクタに揃っていて、権限やログの要件もツールの設定で満たせる場合です。完結しない場合は、社内の開発体制を見て、SDKで自社開発するか開発会社に依頼するかを決めます。

既製ツール・ノーコードで作る

既製ツール・ノーコードは、画面操作でエージェントやワークフローを組み立てる方法で、最も早く安く始められます。代表的な選択肢には次のものがあります。

• Microsoft Copilot Studio: Microsoftの公式ドキュメントでは、AIを使ったエージェントとワークフローを作って管理するための、グラフィカルでローコードな開発環境と説明されています。作ったエージェントでMicrosoft 365 Copilotを拡張できるため、Microsoft 365を中心に業務を回している企業に向いています。
• Dify: LLMアプリとエージェントを画面上で組み立てられるプラットフォームです。料金ページではクラウド版の無料プラン（Sandbox）のほか、Professionalが1ワークスペース年額590ドル、Teamが年額1,590ドルと表示されています（2026年10月1日時点）。自社サーバーで動かす無償のCommunity版もありますが、料金ページでは個人開発者や非商用のプロジェクト向けと位置づけられ、Dify独自のオープンソースライセンスに従う条件があるため、業務で使う前にライセンスを確認してください。詳しくはDifyの企業導入ガイドで扱っています。
• n8n: ワークフロー自動化ツールで、AIの処理を業務システムの連携に組み込めます。料金ページではクラウド版のStarterが月20ユーロ、Proが月50ユーロ（いずれも年払い）と表示されており、自社サーバーで動かすCommunity Editionも公開されています（2026年10月1日時点）。使い方はn8nのワークフロー自動化ガイドを参照してください。

既製ツールが向くのは、問い合わせの一次回答、定型の転記、通知や集計など、手順がある程度決まっていて、連携先が標準コネクタで足りる業務です。一方で、基幹システムとの双方向連携、細かい権限の出し分け、監査に耐えるログが必要になると、ツールの設定だけでは足りなくなることがあります。RPAやiPaaSを含めた既製の自動化ツールの選び方は、業務自動化ツールの比較記事で16製品を横並びにしています。

SDKを使って自社で開発する

SDK（開発キット）を使う方法は、エージェントの動作をコードで細かく制御でき、社内システムとの連携や権限設計を自社の要件どおりに作り込めます。その代わり、設計、テスト、運用監視まで担える開発者が必要です。主な選択肢は次のとおりです。

• Claude Agent SDK（Anthropic）: 公式ドキュメントによると、Claude Codeを動かしているのと同じツール、エージェントループ、コンテキスト管理を、PythonとTypeScriptから使えるライブラリです。組み込みツール、フック、サブエージェント、MCP（外部ツールやデータをつなぐ標準規格）、実行前に承認を求める権限設定などが含まれます。実装の詳細はClaude Agent SDKの実装ガイドで解説しています。
• OpenAI Agents SDK: 公式ドキュメントは、少ない部品でエージェントを作るための軽量なパッケージと説明しています。基本の部品は、指示とツールを持つエージェント、他のエージェントへの委任（ハンドオフ）、入出力を検証するガードレールで、処理の流れを可視化するトレース機能が組み込まれています。
• LangGraph: 公式ドキュメントでは、長時間動作し状態を持つエージェントを作り、管理し、デプロイするための低レベルなオーケストレーション基盤と説明されています。途中で止まっても再開できる実行、人の承認を挟む仕組み、状態の保存が主な機能で、LangChainを使わなくても利用できます。
• Amazon Bedrock AgentCore（AWS）: 作ったエージェントを本番で動かすための基盤です。AWSの製品ページでは、LangChain、OpenAI Agents SDK、Claude Agent SDKなど任意のフレームワークとモデルで作ったエージェントを、セキュリティを備えた環境へデプロイできると説明しています。なお、従来のAmazon Bedrock Agents（Classic）は、AWSの案内によると新規の利用受付を終えており、代わりにAgentCoreが案内されています。

SDKで自社開発する場合でも、最初から大がかりなフレームワークを入れる必要はありません。AnthropicのBuilding effective agentsは、まずLLMのAPIを直接使うことを勧め、フレームワークを使う場合も内部で何が起きているかを理解しておくよう注意しています。抽象化が重なると、実際にモデルへ送られている指示と応答が見えにくくなり、不具合の調査が難しくなるからです。手を動かして作り方を確かめたい場合は、AIエージェントの作り方チュートリアルから始めると、この感覚がつかめます。

自社で作る場合の進め方

自社で作る場合も、いきなりフレームワークを組むのではなく、最小の構成から1つずつ部品を足していくのが安全です。

1. 対象業務と評価の基準を決める: どの業務のどの工程を任せるか、何ができれば合格かを先に決めます。
2. LLMのAPIを直接呼ぶ最小の構成で試す: まず1回の指示と回答で、業務の中核となる判断ができるかを確かめます。
3. 参照させる社内文書と、操作させるツールを1つずつつなぐ: 社内のマニュアルや過去の記録を検索して回答に使わせる仕組みを、RAG（検索拡張生成）と呼びます。つなぐものを1つ足すたびに、次の手順の評価をやり直します。
4. 評価用のデータで、正しく処理できた割合を測る: 実際の業務から集めた入力と正解の組を用意し、変更のたびに同じデータで測ります。
5. 権限、人の承認、操作の記録を入れる: 後半の「本番で事故を起こさないための設計」で挙げる3つの絞り込みを実装します。
6. 運用監視に移る: 処理時間、API利用料、誤りの件数を定期的に確認し、改善を続けます。

2と3の段階で、既製ツールで十分だと分かることもあります。その場合は、無理に自社開発を続けず既製ツールに切り替えるのも合理的な判断です。

開発会社に依頼する

開発会社への依頼、いわゆるAI受託開発は、社内に本番運用まで担える開発者がいない場合や、基幹システム連携・権限設計・監査ログなど、失敗の影響が大きい部分を確実に作りたい場合に向いています。依頼先は、上流の戦略から支援する大手SIer・コンサル、LLMの実装に強いAI専業、特定業務の開発を短期間で請け負う受託開発会社などに分かれ、それぞれ得意な範囲が違います（後半の「開発会社の選び方」で比較します）。

注意したいのは、外注しても「何を作るか」「どこまで任せるか」「合格かどうか」を決める仕事は自社に残ることです。この線引きを曖昧にしたまま依頼すると、提案がそろわず見積もりを比較できない、作られたものを誰も運用できない、といった事態になります。次の節で、自社に残る仕事と外部に任せられる仕事を具体的に分けます。

開発手段を比較する

3つの手段を、選ぶときに効く条件で並べると次のようになります。

実際には、1つの手段だけで完結させるより、組み合わせる形がよく使われます。たとえば、既製ツールで小さく試して効果を確かめ、連携や権限の要件が固まった段階で、SDKでの作り直しを開発会社に依頼し、運用を社内へ移す、といった進め方です。内製と外注の分け方そのものを詳しく検討したい場合は、AIの内製化と外注の比較記事も参考になります。

自社で持つ範囲と外部に任せられる範囲

外注しても自社が手放せないのは、対象業務と成功の基準を決めること、データと権限を用意すること、本番に進むかを判定すること、の3つです。設計と実装、評価の仕組みづくり、運用監視は外部に任せられますが、判断に必要な情報は自社に残す契約にしておく必要があります。

図の5つの領域を、それぞれ具体的に見ていきます。

業務と目標は、自社が決める領域です。どの業務のどの工程を自動化するのか、何が改善されれば成功なのか（処理時間、誤り率、対応件数など）を決められるのは、その業務を持っている自社だけです。外部には、候補業務の洗い出しや、効果の見込みを整理する支援を頼めます。

データと権限も、最終的な責任は自社にあります。エージェントに読ませてよいデータ、操作させてよいシステム、アカウントの権限範囲は、情報管理の規程や取引先との契約に関わるためです。外部には、接続方法の設計や、権限を最小限に絞る構成の提案を任せられます。

設計と実装は、最も外部に任せやすい領域です。SDKの選定、ツール連携、プロンプトの設計、テストの自動化などは、経験のある開発者の生産性が大きく効きます。自社は、作られたものが要件どおりかを確認して受け入れる役割を持ちます。

評価と本番判定は、分担が必要な領域です。評価に使うテストデータの作成や自動評価の仕組みは外部に任せられますが、「この精度なら本番に出してよい」という判定は自社が行います。判定を外部に任せると、作った側が合否を決める構造になってしまいます。

運用と改善は、契約の設計しだいで分担が変わります。監視、モデル更新への追随、プロンプトの調整は外部に任せられますが、利用者からの問い合わせや業務ルールの変更を反映する窓口は社内に置く必要があります。将来的に社内で運用を引き取るなら、手順書と評価データの権利を自社に残す契約にしておきます。

この分担を発注前に社内で合意しておくと、依頼の範囲を明確に伝えられ、提案と見積もりの比較がしやすくなります。提案依頼書には、図の「自社」の欄について社内で決めた内容と、「外部」の欄のうち任せたい範囲をそのまま書くと、各社が同じ前提で提案できます。逆に、「自社」の欄の役割まで開発会社に任せる提案が出てきた場合は、業務の判断を外部に委ねることになっていないかを確認してください。たとえば、成功の基準を開発会社が決め、その基準で開発会社自身が合否を判定する形は、発注側から見ると結果の妥当性を検証できない状態です。

AIエージェント開発の費用の決まり方

AIエージェント開発の費用は、最初にかかる開発費と、毎月かかる運用費の2つに分けて考えます。開発費は主に人件費と期間で決まり、開発会社5社の公表値ではPoCが50万〜300万円程度（高めの会社で1,000万円程度）、本番化が数百万〜数千万円です。運用費はAPI利用料、インフラ費、保守費で構成されます。

公開されている費用相場

AIエージェント開発の費用を公表している開発会社5社の目安を並べると、次のようになります。いずれも各社が自社サイトで示している参考値で、各社とも案件によって変動すると注記しています。Uravationの行は、同社が複数の開発会社や比較メディアの公開情報を横断して整理した早見表と、同じ記事の工程別の目安を組み合わせています。PoCは工程別の目安から、本番化と運用費は業務特化型AIエージェントの行から、大規模は独自モデルや複数の基幹連携を伴う行から採りました。

5社の数字を並べると、PoCは50万〜300万円程度とする会社が多く、1業務の本番化は300万円前後から、複数システムや基幹連携を含む大規模な開発はBlueAIの「500万円〜」から他社の1,000万〜5,000万円以上までと幅があります。EQUESのPoCの目安は数百万〜1,000万円程度と他社より高く、期間も2〜4か月としているため、PoCの規模の想定そのものが違う点に注意して比べてください。

ただし、この表の数字には注意点があります。公表元はいずれもAIエージェント開発を請け負う会社で、自社のサービスに合わせた区切り方をしています。また「PoC」「本番化」が指す範囲も会社ごとに違います。たとえばBlueAIのPoCは本番運用や監視を含まないと明記しています。見積もりを比べるときは総額だけでなく、どの工程が含まれているかを確認してください。PoCの費用の内訳と、見積もりを抑える方法はAIエージェントPoCの外注ガイドで詳しく扱っています。

見積もりの内訳：人月単価と期間

開発会社の見積もりの大部分は、担当者の月額単価に開発期間を掛けた人件費です。株式会社riplaは同社の費用解説で、2025〜2026年時点の国内相場の目安を次のように示しています。

同じ記事では、期間と体制の目安を、小規模なPoCが1〜2か月・1〜2名、部門向けの開発が3〜6か月・3〜5名、大規模な開発が6か月〜1年以上としています。Uravationも、要件定義などの上流工程を40万〜200万円と、開発とは別に示しています。見積もりを受け取ったら、総額が「どの役割の人が、何か月、何人で」という形で説明されているかを確認してください。この分解が示されていれば、期間を短くできないか、役割を減らせないかを具体的に相談できます。たとえばAIエンジニア1名が2か月専任するだけで、この単価表からは人件費が200万〜360万円になります。PoCの見積もりがこれを大きく下回る場合は、既製ツールの設定が中心なのか、評価データの作成が含まれていないのかを確認してください。

初期費用を動かす4つの要因

同じ「AIエージェント開発」でも費用が1桁変わるのは、次の4つの要因の組み合わせが案件ごとに違うためです。

1. 業務の複雑さ: 判断の分かれ目や例外処理が多い業務ほど、設計とテストに工数がかかります。定型の転記と、案件ごとに調べる内容が変わる問い合わせ対応では、必要なテストケースの数が大きく違います。
2. 連携するシステムの数: 接続先が1つ増えるごとに、認証、データの形の変換、エラー時の処理が増えます。BlueAIの価格帯の区切り方も、データ接続1系統のPoCと、複数システム・基幹系との読み書きを含む構成で価格帯を分けています。
3. 任せる自律度: 人が毎回確認する半自動と、判断まで任せる自動実行では、必要な安全対策が違います。自律度を上げるほど、権限の制御、承認の仕組み、記録の設計が必要になります。
4. 運用範囲: 作って引き渡すだけか、監視、精度の改善、モデル更新への追随まで継続して支援するかで、総額が変わります。

見積もりを受け取ったら、金額を押し上げているのがこの4つのどれなのかを開発会社に説明してもらうと、削れる部分と削ってはいけない部分を議論できます。最初は人の確認を多く残した半自動から始め、効果を確かめながら自律度を上げると、初期費用を抑えやすくなります。

複数の開発会社から見積もりを取ったら、総額を比べる前に、各社の見積もりを同じ項目で並べ直すことをおすすめします。業務の整理と要件定義は含まれているか、PoCは別契約か、本番開発はどの連携先までを含むか、テストデータの作成は誰が行うか、公開後の運用は月額いくらで何が含まれるか、改善の依頼は何回まで追加費用なしで対応するか、といった項目です。こうして並べると、安く見えた見積もりが運用や改善を含んでおらず、後から費用が積み上がる構造だった、という違いが見えてきます。反対に、高く見えた見積もりが評価の仕組みや手順書の作成まで含んでいて、長い目で見ると割安だったということもあります。項目がそろわない見積もりしか出てこない場合は、発注側の依頼内容があいまいなことが原因である場合も多いため、後半の発注前チェックリストで依頼内容を見直してください。

毎月かかる費用：API利用料の試算例

毎月の運用費のうち、LLMのAPI利用料は「1件あたりのトークン数×月の処理件数×単価」で見積もれます。トークンはモデルが文章を処理する単位で、エージェントは1件を処理するあいだに何度もモデルを呼び出すため、1件あたりの量が単発の質問より大きくなります。

計算の手順を、Anthropicの料金ページに掲載されたClaude Sonnet 5.5の単価（入力100万トークンあたり2ドル、出力100万トークンあたり10ドル、2026年10月1日時点）で示します。1件の処理で入力3万トークン、出力3,000トークンを使い、月に1,000件処理すると仮定した例です。

この条件なら、API利用料は月1万円台に収まります。一方で、運用費の全体はこれより大きくなります。BlueAIは月次運用を月20万〜50万円、riplaは中規模のエージェントのランニングコストを月15万〜60万円（クラウドサーバー、ベクトルデータベース、監視ツールなどを含む）としており、監視や改善を担う人の費用、インフラ、監視ツールまで含めて予算を見込む必要があります。また、1件あたりのトークン数は、読み込ませる資料の量やモデルを呼び出す回数で大きく変わります。PoCの段階で実際のトークン数を記録し、本番の件数を掛けて試算し直してください。riplaも、社内文書を大量に検索して参照させると、トークンの消費量が数倍になることがあると注意しています。為替レートも仮定であり、同じ料金ページには、米国内に限定した推論を指定すると単価が1.1倍になるといった条件も記載されています。

PoCから本番運用までの進め方

AIエージェント開発は、小さく検証してから本番へ広げる段階的な進め方が基本です。業務と成功基準を決め、PoCで効果と課題を確かめ、合格した場合だけ本番用の権限・監視・例外処理を作り込み、運用しながら改善します。

段階を分けるのは、PoCで動いたものがそのまま本番で使えるとは限らないからです。Gartnerは2025年6月25日のプレスリリースで、エージェント型AIのプロジェクトの40%超が、コストの増大、事業価値の不明確さ、リスク管理の不備を理由に、2027年末までに中止されるとの予測を示しています。同社のアナリストは同じリリースで、現在のプロジェクトの多くが初期段階の実験やPoCであり、大規模に展開する際の実際のコストと複雑さが見えにくくなっていると述べています。

各段階で、発注側が決めることと成果物は次のとおりです。

LLMを使うシステムの運用で何を監視し、どう改善を回すかは、LLMOpsの実践ガイドで具体的に解説しています。

本番に進むかを決める基準

本番に進むかは、PoCの前に決めた合格ラインを満たしたかで判定します。PoCが終わってから基準を決めると、「動いたから進める」という判断になりやすく、本番化の費用に見合う効果があるかを検証できません。PoCを始める前に、次の4点を数字や条件で合意しておきます。

• 効果: 処理時間や対応件数など、業務の指標がどれだけ改善すれば合格とするか
• 品質: 評価用のテストデータで、正しく処理できた割合がどこまで上がれば合格とするか。誤りが起きたときの影響が大きい業務ほど高い水準が必要です
• 費用: 本番化の見積もりと月々の運用費が、見込める効果に見合うか
• 運用: 誤りを見つけて直す担当者と手順を、社内で用意できるか

1つでも満たさない場合は、範囲を絞って再検証するか、打ち切るかを判断します。打ち切りも正しい結論の1つで、PoCの費用で本番化の大きな投資を避けられたと考えられます。範囲を絞って再検証する場合は、うまくいかなかった原因がどこにあったかを先に切り分けます。読ませたデータの質や量が足りなかったのか、業務の手順が案件ごとにばらつきすぎていたのか、連携先のシステムから必要な情報を取れなかったのかによって、次の手が変わるからです。データが原因なら対象の書類や期間を絞る、手順のばらつきが原因なら例外の多い案件を人に回して定型の案件だけを任せる、連携が原因ならまず読み取りだけの連携で効果を確かめる、というように、原因ごとに範囲の絞り方を選びます。PoCの合否判定と撤退条件の決め方は、AIエージェントPoCの外注ガイドでさらに詳しく扱っています。

開発会社の選び方

開発会社は、自社の段階と業務の性質に合うタイプから選びます。候補を集める段階では比較媒体、全社規模や規制の厳しい業務では大手SIer、LLMの実装力を重視するならAI専業、特定業務を短期間で形にしたいなら受託開発会社が候補になります。

依頼先の4タイプ

AIエージェント開発の依頼先は、大きく4つのタイプに分かれます。

riplaの比較記事は、大手各社の特徴を次のように整理しています。

• NTTデータ: 大規模な業務改革と基幹連携
• NEC: 自社開発の生成AI「cotomi」を使った専門業務と日本語対応
• 富士通: 閉域・ハイブリッド環境と既存のシステム構築への対応
• 日本IBM: 業務別のエージェントとガバナンス
• 日本マイクロソフト: Microsoft 365を中心とした市民開発（現場主導の開発）

そのうえでriplaは、紹介した会社を優劣の順位ではなく、既存の環境と業務課題に合うかどうかで比較するよう述べています（riplaは自社を含めて比較しているため、その点を踏まえて読む必要があります）。大手だから安心、小さい会社だから安い、という基準ではなく、自社のシステム環境と業務に合うかで選ぶのが基本です。

大手SIerが得意とする複数部門・閉域環境・監査を含む構成では、費用の水準も大きく変わります。riplaは同じ比較記事で、AIエージェント開発の段階別の費用の目安も示しています。小規模なPoCで300万〜800万円・1〜2か月、複数部門・閉域環境・監査を含む構成で5,000万〜1.5億円以上・8〜18か月という水準です。ただし、公開統計ではなく類似する業務システムの費用からの推定だと明記しています。同じriplaでも費用解説の記事ではPoCを50万〜300万円としています。同じ会社の目安でも記事によって数倍の開きがあるため、見積もりを比べるときは金額より先に、対象業務、連携の範囲、評価の体制といった前提をそろえてください。

実際には、1つのタイプの会社にすべてを任せるより、段階ごとに依頼先を組み合わせるほうが進めやすい場合があります。たとえば、何から手をつけるかが決まっていない段階では、大手SIerやコンサルに業務の整理と優先順位づけを頼み、対象業務が決まったら受託開発会社やAI専業にPoCと本番開発を頼み、運用は内製化の支援を受けながら社内へ移していく、といった形です。上流の戦略から実装、運用まで同じ水準でこなせる会社は多くないため、自社の段階に合わせて依頼先を選び直す前提で考えておくと、途中で行き詰まりにくくなります。ただし、依頼先を切り替えるたびに引き継ぎの手間が発生します。業務の定義、評価データ、判断の経緯を文書で残す契約にしておくと、切り替えの負担を小さくできます。依頼先のタイプを超えて、AI開発会社を幅広く比べたい場合はAI開発会社の比較記事も参照してください。

選ぶときに見落としやすいのが、エージェントとしての実力です。Gartnerは先のプレスリリースで、既存のAIアシスタント、RPA、チャットボットを、エージェントとしての実質的な機能がないまま「エージェント」と呼び替える「エージェント・ウォッシング」が起きていると指摘し、エージェント型AIを掲げる数千社のうち実態があるのは約130社と推計しています。提案を受けたら、名称ではなく、何を自律的に判断させ、どの操作を人の承認に回すのかを具体的に説明してもらいましょう。

契約形態：請負と準委任

AIエージェント開発の契約は、成果物の完成を約束する請負と、作業の遂行を約束する準委任（時間や工数に対して支払う形）のどちらか、またはその組み合わせで結ぶのが一般的です。

AIエージェントは、PoCの結果によって作るものが変わる前提の開発です。そのため、業務の整理とPoCを準委任で行い、結果を見て仕様を固めてから本番開発を請負で契約する、という段階的な組み合わせが取りやすくなります。どの契約形態でも、プロンプト、評価データ、ソースコード、手順書の権利がどちらに帰属するかは必ず契約書に書いておきます。将来、社内で運用を引き取ったり、別の会社に保守を移したりするときに必要になるからです。

あわせて、エージェントに読ませる社内データの扱いも契約で決めておきます。開発や検証のために開発会社へ渡すデータの範囲、保管する場所と期間、契約終了時の削除の方法、そして利用するAIサービスが入力データをどう扱うかの確認です。特に、個人情報や取引先から預かった情報を含む業務では、社内の情報管理の規程や取引先との契約で、社外への提供が制限されていることがあります。開発会社が使う予定のAIサービスと、そのデータの扱いを事前に一覧にしてもらい、社内の法務や情報システム部門と確認してから契約すると、後から作り直しになる事態を避けられます。AI開発の契約と進め方の全体像はAI受託開発のガイドにまとめています。

最初の打ち合わせで聞くこと

最初の打ち合わせでは、会社紹介の資料よりも、次の質問への答え方で実力を見極められます。答えが具体的か、自社の業務に即しているかを確認してください。

1. 私たちの業務は、ワークフローとエージェントのどちらで作るべきですか。その理由は何ですか
2. 過去に本番運用まで進んだAIエージェントの案件で、どのSDKや基盤を使い、どんな問題が起きましたか
3. PoCの合格ラインは、どの指標でどう決めることを勧めますか
4. エージェントに与える権限をどう絞り、どの操作に人の承認を入れますか
5. 誤った出力や、想定外の操作が起きたとき、どう検知して止めますか
6. 見積もりに含まれる工程と、含まれない工程はどれですか。月々の運用費はいくらですか
7. モデルやSDKの更新があったとき、誰がどう対応しますか
8. 契約終了後に、社内や別の会社へ運用を移す場合、何を引き渡してもらえますか
9. 社内文書の検索の精度、連携先のAPIが失敗したときの再試行、操作の記録を、過去の案件でどう確かめましたか

質問1で、業務を聞く前から特定の製品やエージェントを勧める会社には注意が必要です。Anthropicが最も単純な解決策から始めるよう勧めているとおり、単純な仕組みで足りる業務に複雑な仕組みを提案していないかを見ます。提案依頼書（RFP）の書き方はRFPの書き方ガイドで、項目ごとの例文とともに解説しています。

本番で事故を起こさないための設計

AIエージェントを本番で安全に動かすには、エージェントができる操作を必要最小限に絞り、影響の大きい操作には人の承認を挟み、すべての操作を記録することが基本です。これは開発会社に任せきりにせず、発注時の要件として明示しておくべき項目です。

セキュリティの非営利団体OWASPは、LLMを使うアプリケーションの主要なリスクをまとめたOWASP Top 10 for LLM Applications 2025で、「過剰な権限（Excessive Agency）」を取り上げています。これは、LLMの出力が想定外だったり、あいまいだったり、外部から操作されたりしたときに、損害を与える操作が実行されてしまう脆弱性です。OWASPは主な原因として、機能が多すぎること、権限が大きすぎること、自律性が高すぎることの3つを挙げています。

この3つの原因は、そのまま発注時の要件に置き換えられます。

• 機能を絞る: エージェントが使えるツールを業務に必要なものだけにする。たとえば、メールを読むだけの業務に、送信や削除の機能を持たせない
• 権限を絞る: 接続するシステムのアカウントに、必要最小限の権限だけを与える。読み取りだけで足りるなら、書き込み権限を与えない
• 自律性を絞る: 送金、外部への送信、データの削除など、取り消しにくい操作の前に人の承認を入れる

公開した後の監視も、設計の一部として最初から決めておきます。エージェントが呼び出したツールと引数、参照したデータ、出力の内容、承認した人と時刻を記録しておけば、誤った処理が起きたときに原因をたどれます。記録があれば、モデルやプロンプトを更新したときに以前と比べて精度が落ちていないかも確かめられます。あわせて、1件あたりの処理時間とAPI利用料を定期的に集計し、想定より増えていないかを見ておくと、費用の急な増加にも早く気づけます。どの項目を記録し、誰がどの頻度で確認するかは、開発会社に任せきりにせず、運用を担う社内の担当者と一緒に決めてください。

加えて、エージェントが読み込む文書やWebページに仕込まれた指示に従ってしまう「プロンプトインジェクション」への対策も必要です。対策の考え方はプロンプトインジェクション対策の記事で解説しています。権限の設計、承認の流れ、操作の記録を組織としてどう運用するかは、AIエージェント開発のガバナンス設計ガイドで詳しく扱っています。

発注前チェックリスト

開発会社に声をかける前に、次の項目を社内で確認しておくと、提案の質がそろい、見積もりを比べやすくなります。すべてが埋まっていなくてもかまいません。決まっていない項目は「未定」と伝えるほうが、各社の前提がそろいます。

業務と目標

• 自動化する業務と工程を、1つに絞れているか
• 成功の基準（処理時間、誤り率、対応件数など）と、現在の値を把握しているか
• その業務は手順が毎回同じか（ワークフローで足りるか）、案件ごとに変わるか

データと権限

• エージェントに読ませるデータと、その保存場所が分かっているか
• 社外のAPIにデータを送ってよいか、情報管理の規程を確認したか
• 接続するシステムと、必要な権限（読み取りのみか、書き込みも必要か）を洗い出したか

体制と予算

• 業務を知っていて、合否を判定できる社内の担当者を決めたか
• PoCと本番化の予算を分けて確保できるか。月々の運用費も見込んでいるか
• 運用を将来社内で引き取るのか、外部に任せ続けるのかの方針があるか

安全性

• 人の承認が必要な操作（送金、外部への送信、削除など）を決めたか
• 誤りが起きたときに、誰がどう気づき、どう直すかを決めたか

社内の準備がどこまで整っているかを確かめたい場合は、業務の可視化、データ環境、組織体制、リテラシー、予算の5つの観点・19項目で点数を出せるAI自動化 準備度チェックも使えます。

状況別の読み分け早見表

いまの状況に合わせて、次に読む内容を選んでください。

よくある質問

AIエージェント開発の相談先

koromoは、AIエージェントを含むプロダクト開発と、AI導入の戦略づくりを支援しています。この記事で扱った業務の選定、PoCの範囲と合格ラインの設計、Claude CodeやClaude Agent SDKを使った開発、権限を絞った設計について、技術相談を受け付けています。

次のような段階の方は、相談いただくと判断が早く進みます。

• 自動化したい業務の候補はあるが、ワークフローで足りるのかエージェントが必要なのかを判断できない
• PoCを始めたいが、範囲と合格ラインの決め方、見積もりの妥当性に迷っている
• 既製ツールで試したものの、連携や権限の要件が満たせず、本格的な開発を検討している

一方で、自動化したい業務がまだ決まっていない段階や、既製ツールの範囲で業務が完結している場合は、先に上の発注前チェックリストで業務を整理したり、ツールを試したりするほうが早く成果につながります。