業務に入る AI エージェントの作り方と発注の仕方（任せる業務の決め方・作り方の選び方・費用の内訳）

業務に入る AI エージェントを作るときは、ツールや開発会社を選ぶ前に「どの業務のどの判断を AI に任せ、どの判断を人に残すか」を決めるのが先です。任せる範囲が決まれば、作り方（SaaS の設定・ノーコード・個別開発）は連携先の数と権限の細かさから自然に絞れ、発注先に渡す要件も「データの置き場・権限・評価の基準」の3点に落ちます。費用は相場の数字で比べるより、期間と体制の内訳で比べたほうが判断を誤りにくくなります。

AI エージェントは「判断を伴う一連の作業」を任せる仕組みになる

AI エージェントは、質問に答えるだけの生成 AI と違い、目標に向けて自分で手順を選び、他のシステムを操作して作業を進める点が特徴です。総務省と経済産業省の AI 事業者ガイドラインは、2026年3月の第1.2版で AI エージェントを「特定の目標を達成するために、環境を感知し自律的に行動する AI システム」と定義しました。脚注では、ここでいう自律は高度な自律状態だけを指すのではなく、ある程度の自律性を持つものも含むとしています。

出所: 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日）

ガイドラインの改定にあわせて公表された更新内容の資料は、AI エージェントの便益として、複数のシステムと連携した自律的な行動による調整・分析・意思決定の効率化を挙げています。同時に、リスクとして「自律的な動作の中で人間の意図しない商品の注文やファイル削除等の動作を行う可能性」と、外部システムとの連携の過程で内部データが意図せず外部へ送信される可能性を追記しました。

出所: 総務省・経済産業省「AI事業者ガイドラインの令和7年度更新内容」（2026年3月12日）

つまり、AI エージェントの開発は「賢い回答を作る」仕事というより「業務の中で何を実行させてよいか」を設計する仕事です。どこまで実行させるかを決めないまま作り始めると、便益とリスクの両方が大きくなります。AI エージェントに関する他の記事は AI エージェントのカテゴリ から読めます。

作る前に、任せる判断と人に残す判断を分ける

最初の作業は、対象業務を作業単位に分け、それぞれの判断を「AI に実行させる」「AI が案を作り人が承認する」「人が行う」の3つの区分に振り分けることです。振り分けは業務の手順書に書き込める粒度で行い、1つの作業に1つの区分を割り当てます。

日本企業の現状を見ると、生成 AI による業務変革に組織として取り組んでいない会社が、まだ3割近くあります。令和8年版の情報通信白書によれば、「組織的な取組はない」と答えた日本企業は27.0%で、米国（1.4%）、ドイツ（4.9%）、中国（2.6%）より大幅に高い水準でした。

出所: 総務省「令和8年版 情報通信白書（概要）」（2026年7月）

振り分けの基準として使えるのが、ガイドラインの AI 利用者向けの項目です。更新内容の資料は、出力によって重大な影響または被害が生じ得る場合には「人間の判断を介在させる仕組みに基づいた判断」が重要だと追記しました。AI 提供者向けの項目でも、判断が必要となる事項を重要度に応じて整理し、適切に対象を選ぶことを求めています。

出所: 総務省・経済産業省「AI事業者ガイドラインの令和7年度更新内容」（2026年3月12日）

実務では、次の2つの問いで振り分けると判断がぶれにくくなります。

たとえば、社内向けの資料の下書きや、問い合わせの分類、定型の集計は取り消しが利き、影響も社内に留まるため、AI に実行させる候補になります。一方で、社外への送信、契約や金額の確定、採用や評価のような人の処遇に関わる判断は、AI が案を作っても最終判断は人に残すのが基本です。この表は振り分けの出発点であり、業界の規制や社内規程がある業務では、そちらを優先します。

作り方は3通りあり、連携先の数と権限の細かさで選ぶ

任せる範囲が決まったら、作り方を選びます。選び方の軸は「つなぐシステムの数」と「AI に渡す権限をどこまで細かく制御したいか」の2つです。

最初から個別開発を選ぶ必要はありません。1つのツールで済む作業は SaaS の設定から始め、連携先が増えた段階や、権限を作業単位で絞りたくなった段階で個別開発へ移るのが現実的です。

発注するときは、自社がどの役割を担うのかも確認しておきましょう。AI 事業者ガイドラインは、AI 開発者・AI 提供者・AI 利用者の3つの主体を分けています。更新内容の資料によれば、一般には AI 開発者が API の仕様策定や入出力の設計、AI モデルを動かすインフラ整備を担い、AI 提供者が UI/UX の設計や既存の業務システムとの統合を担うという整理です。外部に開発を頼んでも、社内システムとの統合や運用を自社で持つなら、自社は AI 提供者と AI 利用者の両方の役割を負うことになります。

出所: 総務省・経済産業省「AI事業者ガイドラインの令和7年度更新内容」（2026年3月12日）

発注の前に社内で決めておくことは3つある

発注先に渡す前に社内で決めておくのは、データの置き場、権限、評価の基準の3つです。この3つが曖昧なまま見積もりを取ると、提案ごとに前提が違い、比較ができません。

データの置き場

AI エージェントが参照する社内データを、どこに置き、誰が更新するかを先に決めます。ここは日本企業がまだ手薄な部分です。白書によれば、生成 AI による業務変革の環境整備として「生成 AI に社内データを学習させたり、生成 AI が参照可能なデータベースを構築したりしている」と答えた企業は、日本で24.5%でした。米国は57.2%、ドイツは54.4%、中国は73.0%です。

出所: 総務省「令和8年版 情報通信白書（概要）」（2026年7月）

同じ調査で「社員が生成 AI を活用したアプリや AI エージェントを開発可能な技術環境がある」と答えた日本企業は15.3%でした。開発を外に頼む場合でも、データをどの環境に置くか（自社のクラウドか、委託先の環境か）は、契約終了後に何が手元に残るかを左右します。

出所: 総務省「令和8年版 情報通信白書（概要）」（2026年7月）

権限

権限は、AI エージェントがどのシステムで何をしてよいかを一覧にして決めるものです。ガイドラインの更新内容は、AI 提供者向けに「ユーザーやシステムに付与する権限を業務遂行に必要な最小限に設定する」ことと、ホワイトリスト方式で連携ツール・システムを制限することを追記しました。扱うデータも、AI の判断に必要な最小限の範囲に限定することが求められています。

出所: 総務省・経済産業省「AI事業者ガイドラインの令和7年度更新内容」（2026年3月12日）

実務に落とすと、「読むだけのシステム」「書き込んでよいシステム」「触らせないシステム」を一覧にし、書き込みの中でも取り消せない操作（送信・削除・確定）には人の承認を挟む、という形です。前の節で決めた振り分けを、そのまま権限の表に写せば足ります。

評価の基準

評価の基準は、何をもって「動いている」とみなすかを作る前に決めておくものです。ガイドラインは AI 利用者に対し、AI システム・サービスが想定された仕様に基づき適切に動作しているかを確認することと、利用過程の記録（操作履歴、入力・出力の記録）の管理体制を整えることを求めています。自律的に動く AI エージェントについては、ログを定期的にレビューし、異常な操作を検知したら即時に報告する体制の重要性も追記されました。

出所: 総務省・経済産業省「AI事業者ガイドラインの令和7年度更新内容」（2026年3月12日）

評価の基準として書いておくべきなのは、たとえば「どの入力に対して、どの出力なら合格か」の例の集まりと、人が差し戻した件数や理由を記録する方法です。基準が無いまま PoC（＝本番前の小さな検証）を始めると、検証の終わりに「便利そうだった」という感想しか残らず、続けるかやめるかを決められません。

費用は相場ではなく、期間と体制の内訳で比べる

AI エージェント開発の費用は、作り方と任せる範囲で大きく変わるため、一般的な相場の数字を当てはめても判断の材料になりません。比べるべきは、見積もりの中身が次のどの工程をどれだけの期間・体制で含んでいるかです。

契約形態も費用の比べ方を左右します。成果物の完成を約束する受託開発は、作るものが固まっている場合に向きます。任せる範囲を現場で確かめながら進める段階では、期間あたりの体制で契約する準委任のほうが、途中で範囲を変えやすくなります。

FDE 型の支援を使うと、業務の分解から運用の引き継ぎまでを1つの体制で進められる

FDE 型の支援を使う利点は、業務の分解、実装、評価、運用の引き継ぎを、別々の会社に分けずに同じ担当者が進められることです。FDE（Forward Deployed Engineer）の定義は Offers FDE の解説 に譲り、ここでは発注する企業の側で何が変わるかだけを書きます。

要件定義と実装の担当が分かれていると、「任せる判断と人に残す判断」の振り分けが要件書の言葉に置き換わる段階で抜け落ちやすくなります。同じ担当者が現場の業務を見たうえで実装まで持つと、振り分けをそのまま権限の設計と評価の基準に写せます。

Offers AX は、コンサルティング、AI エージェント開発、内製化支援の3つを組み合わせて提供しています。構築はお客様の環境（GCP・Azure・AWS）で行い、当社の環境に顧客データを抱えないため、契約が終わっても作ったものはお客様の環境に残ります。AI の出力は下書き・参考情報の位置づけで、事実認定・合否・処遇は人が判断する前提です。効果が出ない場合に中止を選べることも、最初から契約の前提に含めています。

出所: 株式会社overflow「Offers AX」サービスページ（2026年10月25日時点）

任せる業務の振り分けから一緒に進めたい場合は、Offers AX のサービスページ で進め方を確かめられます。相談の内容が決まっているなら、無料相談の申込ページ から日程まで決められます。

うまくいかない進め方にも共通点がある

AI エージェントの開発が止まる理由は、技術の不足よりも、作る前に決めるべきことが決まっていないことにある場合が多くあります。よく見かけるのは次の3つです。

1つ目は、最初から人の承認を挟まない全自動を狙うことです。取り消せない操作まで AI に任せると、一度の誤りで現場の信頼を失い、以後は使われなくなります。承認を挟む運用から始め、差し戻しの記録を見て任せる範囲を広げるほうが、結果的に早く進みます。

2つ目は、AI が出す理由の説明を、判断の根拠としてそのまま記録することです。ガイドラインの更新内容は、LLM が結果とその根拠を出力するように求められても、それは AI 内部の決定ロジックを説明しているわけではなく、もっともらしい組み合わせを出しているにすぎない点に注意するよう明記しました。監査に使う記録は、AI の説明文ではなく、入力・出力・操作の履歴で残す必要があります。

出所: 総務省・経済産業省「AI事業者ガイドラインの令和7年度更新内容」（2026年3月12日）

3つ目は、作ったあとの保守の担い手を決めないことです。ガイドラインは、AI エージェントによってコード生成が容易になることを踏まえ、生成物の保守・更新が難しくなる可能性と、社内にノウハウを蓄積することの重要性を追記しています。外部に頼む場合でも、引き継ぎの範囲と、社内で誰が手順を理解しておくかを、発注の時点で決めておくべきです。

出所: 総務省・経済産業省「AI事業者ガイドラインの令和7年度更新内容」（2026年3月12日）

AI エージェントは、任せる判断が明確な業務ほど成果につながり、境界が曖昧な業務ほど手戻りが増えます。発注の前に、振り分けの表、権限の表、評価の基準の3つを社内で用意しておけば、どの作り方・どの発注先を選んでも、比べる物差しを自社で持てます。