AIエージェント開発では、LLMに業務を丸ごと任せず、対象業務を1つに絞り、許可する操作・人の承認・停止条件・評価基準を先に設計します。読み取りと提案から始め、品質と費用対効果を確認しながら更新操作へ段階的に広げるのが安全です。
AIエージェント開発の基本と向いている業務
AIエージェントとは、LLM（＝大量の文章を学習し、指示に応じて回答や判断候補を生成するAI）が目的に合わせて手順を選び、許可されたAPI（＝システム同士を接続する窓口）や社内データを利用しながら、複数工程の処理を進める仕組みです。
一般的な生成AIチャットボットが「質問に回答する」ことを中心とするのに対し、AIエージェントは次のような一連の処理を担えます。
- 問い合わせ内容を分類する
- 顧客情報や契約状況を検索する
- 社内ルールを参照して対応案を作る
- 担当者へ承認を依頼する
- 承認後にメール送信や業務システムへの登録を行う
- 実行結果を記録する
ただし、AIエージェントは「AIに自由にパソコンを操作させる仕組み」ではありません。実務では、AIが担当する判断と、通常のプログラムが強制するルールを明確に分けます。認証、アクセス権限、金額計算、入力値の検証、送信先の制限などをLLMの指示だけに委ねてはいけません。
AIエージェントを構成する要素
| 構成要素 | 主な役割 | 発注時に確認すること |
|---|---|---|
| LLM | 文章生成、分類、手順候補の作成 | 利用モデル、データ利用条件、出力の検証方法 |
| オーケストレーター | 処理順序、分岐、実行状態の管理 | 最大実行回数、タイムアウト、異常時の停止方法 |
| ツール | 検索、登録、通知などの個別機能 | 参照と更新の分離、利用権限、入力値の制限 |
| 状態管理 | 途中経過や承認待ち状態の保存 | 障害後の再開方法、二重処理の防止 |
| 承認機能 | 人が内容を確認して実行を確定 | 承認者、承認対象、変更前後の表示 |
| 監査ログ | 入力、判断、操作結果の記録 | 記録項目、保存期間、個人情報の扱い |
| 評価基盤 | 変更前後の品質を比較 | テストデータ、合格基準、再評価の手順 |
向いている業務と向いていない業務
AIエージェントが有効なのは、文章の理解や状況に応じた分岐が必要で、複数の情報源を横断する業務です。一方、手順が完全に固定されている処理は、ワークフローやRPA（＝画面操作などの定型作業を自動化する仕組み）の方が安定し、費用も予測しやすい場合があります。
| 向いている業務 | 慎重に検討すべき業務 |
|---|---|
| 問い合わせの分類と回答案作成 | 人の確認なしで行う返金・送金 |
| 社内文書や顧客情報の横断検索 | 法的判断や医療判断の自動確定 |
| 商談記録からの入力案作成 | 誤りを後から訂正できない処理 |
| 複数システムからの情報収集 | 正解や完了条件を定義できない業務 |
| 定型的な申請内容の事前確認 | 発生件数が少なく、開発費を回収しにくい業務 |
発注前には、次の条件を満たす業務から候補を選ぶと判断しやすくなります。
- 月間の処理件数と人手の所要時間を把握できる
- 正しい完了状態を説明できる
- AIの出力を確認できる担当者がいる
- 誤りが起きても送信・更新前に止められる
- 参照するデータや社内ルールが整理されている
- 導入前後の時間、修正率、処理費用を比較できる
「AIエージェントを導入すること」自体を目的にせず、削減したい作業時間や改善したい応答速度から逆算することが重要です。
自動化レベルは段階的に上げる
| レベル | AIの役割 | 人の関与 | 導入判断 |
|---|---|---|---|
| 0. 支援なし | 従来どおり人が処理 | 全工程を人が実施 | 現状値を測る基準にする |
| 1. 提案 | 分類、検索、回答案作成 | 人が修正・実行 | 最初の本番導入に向く |
| 2. 承認付き実行 | 操作案を作り、承認後に実行 | 全件を人が承認 | 更新処理の検証段階に向く |
| 3. 条件付き自動実行 | 低リスク条件だけ自動処理 | 例外と高リスク処理を確認 | 十分な実績とログが必要 |
| 4. 高度な自動実行 | 複数工程を自律的に実行 | 監視と例外対応 | 限定的な業務にのみ適用 |
最初からレベル4を目指す必要はありません。レベル1でも、検索時間や下書き作成時間を短縮できれば、十分な投資効果が得られることがあります。
要件定義と評価基準の決め方
AIエージェント開発の成否は、モデル選びよりも要件定義（＝作るものと満たす条件を決める工程）に左右されます。「営業を自動化したい」のような広い依頼ではなく、「問い合わせメールを分類し、顧客情報を検索して、返信案を作成する」程度まで対象を絞ります。
最初に決める業務要件
発注者側で最低限整理したい項目は次のとおりです。すべてを技術文書にする必要はありませんが、現行の画面、帳票、判断ルール、例外事例は開発会社に共有してください。
- 目的：何の時間やコストを減らしたいか
- 開始条件：メール受信、フォーム送信など、処理が始まるきっかけ
- 完了条件：回答案の保存、担当者への通知など、どこまでを完了とするか
- 入力：メール、PDF、チャット、データベースなど、何を受け取るか
- 出力：文章、分類結果、登録データ、通知など、何を返すか
- 参照先：社内文書、顧客管理システム、在庫情報など
- 更新先：どのシステムのどの項目を変更するか
- 承認条件：誰が、何を確認し、どの操作を許可するか
- 例外処理：情報不足、権限不足、システム障害時に誰へ引き継ぐか
- 禁止事項：削除、送金、対象外顧客への送信など、実行させない操作
- 利用量：月間件数、繁忙時間帯、1件当たりのデータ量
- 責任分界：業務部門、情報システム部門、開発会社が担う範囲
外注先へ依頼する内容を整理する場合は、RFPの作り方｜システム開発の依頼準備も参考になります。RFP（＝開発会社へ要件や提案条件を伝える文書）には、機能一覧だけでなく、業務目的、利用データ、許容できない失敗、検収条件を記載することが大切です。
AIに任せる判断とプログラムで固定するルール
LLMは表現の揺れを含む文章の分類や要約には向いていますが、同じ入力に必ず同じ答えを返すとは限りません。そのため、次のように役割を分けます。
| AIに任せやすい処理 | 通常のプログラムで制御すべき処理 |
|---|---|
| 文章の分類・要約 | ログイン確認とアクセス権限 |
| 回答案や入力案の生成 | 金額、税率、割引率の計算 |
| 検索キーワードの作成 | 入力形式、上限値、必須項目の検証 |
| 複数候補の優先順位付け | 送信可能な宛先や更新可能な項目の制限 |
| 不足情報の指摘 | 二重登録、二重送信の防止 |
プロンプトに「間違えないでください」「権限を守ってください」と記載するだけでは、システム上の制御にはなりません。禁止操作は、AIが指示しても実行できない構造にする必要があります。
評価データと合格基準を先に作る
AIの品質は、デモ画面を数回操作しただけでは判断できません。実際の業務を代表する固定テストデータを用意し、モデルや指示文を変更するたびに同じ条件で比較します。これは回帰評価（＝変更によって以前できていた処理が悪化していないか確認する評価）と呼ばれます。
初期のPoC（＝本格開発前に実現性を確かめる小規模検証）では、代表例、難しい例、失敗させるべき例を含めて数十〜100件程度から始める方法があります。ただし、適切な件数は業務の種類、データのばらつき、誤操作時の影響によって異なります。
テストデータには、次のケースを含めます。
- 一般的な正常処理
- 情報が不足している依頼
- 内容が曖昧または矛盾している依頼
- 対象外業務や権限外操作の依頼
- 悪意のある命令が含まれるメールや文書
- APIや外部システムが停止したケース
- 同じ処理が再実行されたケース
- 長文、添付ファイル、表記揺れを含むケース
| 評価指標 | 確認する内容 | 基準の決め方 |
|---|---|---|
| タスク完了率 | 期待する終了状態に到達した割合 | 現在の人手運用と比較する |
| 分類・抽出精度 | 必要な項目を正しく判定できた割合 | 重要項目を分けて評価する |
| ツール選択の正確性 | 適切なAPIと操作を選べた割合 | 参照・更新・禁止操作ごとに集計する |
| 人による修正率 | 提案内容が修正された割合 | 誤りの種類と修正時間も記録する |
| 重大誤操作 | 誤送信、不正更新、情報漏えいにつながる操作 | 高リスク操作は技術的に実行不能にする |
| 処理時間 | 開始から完了までに要した時間 | 利用者が待てる時間と比較する |
| 1件当たり費用 | モデル、検索、外部APIなどの変動費 | 削減できる作業時間と比較する |
| 保留・引き継ぎ率 | AIが判断せず人へ渡した割合 | 無理に自動化せず安全性と併せて評価する |
重大誤操作については、テスト中に0件だったとしても、将来の発生確率が0だと証明できるわけではありません。評価だけに頼らず、権限制御、承認、送信先制限などを重ねて防ぎます。
AIエージェント開発の費用・期間と見積もり
AIエージェント開発の費用は、LLMの利用料よりも、既存システム連携、データ整備、承認画面、セキュリティ、評価、運用設計によって大きく変わります。一般的な目安は次のとおりですが、対象業務や既存環境によって上下します。
| 段階 | 費用の一般的な目安 | 期間の目安 | 主な成果物 |
|---|---|---|---|
| 構想・業務整理 | 50万〜150万円程度 | 2〜4週間 | 対象業務、効果仮説、リスク整理、PoC計画 |
| PoC | 150万〜500万円程度 | 1〜3か月 | 試作、固定テスト、精度・費用・課題の評価 |
| 限定的な本番開発 | 500万〜1,500万円程度 | 3〜6か月 | 認証、権限、承認画面、ログ、1〜3システム連携 |
| 複数部門・複数システムへの展開 | 1,500万〜5,000万円以上 | 6〜12か月以上 | 複雑な連携、監視、冗長化、全社的な権限制御 |
| 保守・運用 | 月額20万〜100万円以上 | 継続 | 監視、障害対応、モデル変更、再評価、改善 |
簡易的な社内検証であれば目安を下回ることもあります。一方、金融、医療、個人情報を多く扱う業務、24時間対応、厳しい監査要件がある場合は、設計・試験・運用費が増えます。各段階の金額は単純に合算するものではなく、PoCで作った部分を本番へ流用できるかによっても変わります。
PoCの費用や外注範囲を詳しく検討したい場合は、生成AI PoCの費用相場｜進め方と外注先選びもあわせてご覧ください。
費用を左右する主な要因
| 費用要因 | 安くなりやすい条件 | 高くなりやすい条件 |
|---|---|---|
| 対象業務 | 1業務に限定 | 複数部門の業務を横断 |
| システム連携 | 既存APIが利用可能 | APIがなく個別改修が必要 |
| 操作範囲 | 検索・提案のみ | 登録、送信、決済、削除を含む |
| データ | 整理済みで更新担当が明確 | 文書が散在し、内容も古い |
| 評価 | 正解を明確に定義できる | 主観的な評価が多い |
| セキュリティ | 一般的な社内情報 | 機密情報、個人情報、厳格な監査要件 |
| 可用性 | 営業時間内の利用 | 24時間稼働や迅速な復旧が必要 |
| 利用量 | 少量で安定 | 大量処理または急激な増減がある |
発注のご相談を受ける開発会社の立場では、「どのLLMを使うか」よりも、「既存システムに安全なAPIがあるか」「正解データを誰が作るか」「誰が承認するか」の方が、見積もりへの影響が大きいケースが多くあります。
見積書で確認する項目
見積もりを比較するときは、総額だけでなく、前提条件と対象範囲をそろえてください。
- 業務分析と要件定義が含まれているか
- データ整備、正解データ作成を誰が担当するか
- 既存システム連携の本数と更新範囲が明記されているか
- 承認画面、権限制御、監査ログが含まれているか
- セキュリティテストと異常系テストが含まれているか
- モデル利用料、クラウド費、外部検索費が別途か
- PoCの成果物を本番開発へ流用できるか
- ソースコード、設定、アカウントの所有者が明確か
- モデル変更時の再評価が保守範囲に含まれるか
- 障害対応時間と復旧目標が定められているか
PoCのように不確実性が高い段階では、準委任契約（＝一定の作業遂行を委託する契約）で仮説検証を進め、要件が固まった本番開発では請負契約（＝合意した成果物の完成を求める契約）を選ぶ方法があります。契約名だけで判断せず、完成条件、検収方法、仕様変更の扱いを確認してください。
安全な設計・実装・本番移行の手順
実装は、読み取り専用の小さな試作から始めます。最初からメール送信、契約変更、データ削除まで許可すると、問題が起きた際に原因を切り分けにくく、承認や権限制御の不足も見落としやすくなります。
手順1：現行業務と基準値を記録する
現在の業務フロー、1件当たりの作業時間、月間件数、差し戻し率、例外の種類を記録します。導入前の基準値がなければ、AI導入後に効果を説明できません。
業務担当者へのヒアリングでは、標準手順だけでなく、「判断に迷う事例」「熟練者しか知らない例外」「処理してはいけない条件」を収集します。
手順2：読み取りと提案だけのPoCを作る
最初のPoCでは、データ検索、分類、要約、入力案作成など、実データを変更しない範囲に限定します。PoCの目的は、見栄えのよいデモを作ることではなく、次の問いに答えることです。
- 必要な情報を取得できるか
- 業務担当者が許容できる品質か
- どの条件で失敗するか
- 人が確認する場合に何秒・何分かかるか
- 1件当たりの費用は投資効果に合うか
- 本番化に必要な追加開発は何か
手順3：ツールと権限を小さく設計する
AIが利用するツールは、「顧客を検索する」「注文状況を取得する」「回答案を保存する」のように、目的ごとに小さく分けます。検索と更新を同じツールにまとめず、権限も分離します。
各ツールには次の制限を設けます。
- 入力できる項目、形式、文字数、件数の上限
- 利用できるユーザー、部署、顧客の範囲
- 呼び出し回数と処理時間の上限
- 許可された送信先や更新項目の一覧
- 実行前に承認が必要となる条件
- 失敗時の再試行回数
- 同じ処理の重複実行を防ぐ識別子
最後の仕組みは冪等性（＝同じ処理を再実行しても二重登録や二重送信を起こさない性質）と呼ばれます。通信障害後の再試行を考えると、更新系の処理には欠かせません。
手順4：停止条件と承認を実装する
AIエージェントが処理を続けすぎないよう、最大ステップ数、タイムアウト、利用金額の上限を設定します。同じツールと同じ入力を繰り返した場合も停止させ、人へ引き継ぎます。
外部送信、契約変更、返金、削除などは、AIが直接実行せず、操作案を承認待ちとして保存します。承認画面には、単なる「承認」ボタンだけでなく、次の情報を表示します。
- 変更前と変更後の値
- メールや通知の送信先
- AIが参照した情報と根拠
- 実行されるツールと対象システム
- 信頼度が低い項目や不足情報
- 承認後に取り消せるかどうか
承認件数が多すぎると、内容を読まずに承認する状態になりやすいため、承認率だけでなく確認時間や修正率も測定します。
手順5：プロンプトインジェクションと情報漏えいを防ぐ
プロンプトインジェクションとは、メール、Webページ、添付文書などに悪意のある命令を埋め込み、AIの本来の指示を無視させようとする攻撃です。外部データは「参考情報」であり、「実行すべき命令」ではないものとして扱います。
本番運用では、少なくとも次を確認します。
- システムの指示と外部文書を明確に分離する
- ツールごとにサービス用アカウントと権限を分ける
- 顧客・部署・役職単位でアクセス範囲を制限する
- APIキーやパスワードをAIへの入力に含めない
- ツールからAIへ返す情報を必要最小限にする
- 個人情報や秘密情報をログ上でマスキングする
- 入力、モデル、指示文の版、ツール操作、承認者を記録する
- 利用するAIサービスの学習利用条件とデータ保存先を確認する
- AIを停止し、従来の業務フローへ戻す手順を用意する
手順6：固定テストと業務担当者の受入試験を行う
開発会社だけでテストを完結させず、実際の業務担当者が結果を確認します。文章として自然でも、社内ルールや顧客対応方針に合っていない場合があるためです。
不合格例は削除せず、原因を「検索失敗」「判断失敗」「データ不足」「ツール障害」「要件の曖昧さ」などに分類します。モデル変更だけで解決しようとせず、業務ルールの明文化やツール設計の修正も検討します。
手順7：提案、全件承認、条件付き自動化の順で広げる
本番移行時は、次の順序が現実的です。
- シャドーモード：AIに処理させるが、結果は業務に反映せず人の処理と比較する
- 提案モード：AIが回答案や登録案を作り、人が修正して実行する
- 全件承認モード：AIが操作案を作り、すべて人の承認後に実行する
- 条件付き自動化：十分な実績がある低リスク条件だけ自動実行する
- 対象範囲の拡大：部署、データ、ツールを一つずつ追加する
段階を進める条件は、「一定期間が経過したから」ではなく、修正率、重大誤操作、保留率、処理費用などの数値で決めます。モデルやプロンプトを変更した場合は、固定テストを再実行してから反映します。
開発会社を選ぶチェックポイント
AIのデモを短期間で作れることと、安全に本番運用できることは別です。提案や面談では、次の点を確認してください。
- AIに任せる処理と通常のプログラムで制御する処理を説明できる
- PoCの合格基準と中止基準を提案できる
- 正常系だけでなく、権限外操作や外部サービス障害を試験できる
- 参照権限と更新権限を分けて設計できる
- 承認、監査ログ、二重処理防止を見積もりに含めている
- モデル変更時の再評価方法を説明できる
- モデル利用料を含む運用費を試算できる
- データ保存先、学習利用、秘密情報の扱いを説明できる
- ソースコード、クラウド、AIサービスのアカウント帰属が明確である
- 問題発生時にAIを停止し、従来運用へ戻せる設計を提案できる
提案書には、構成図、利用ツールと権限の一覧、評価計画、セキュリティ対策、運用体制、概算費用、対象外事項を含めてもらうと比較しやすくなります。対象業務の切り出しやPoC範囲から整理したい場合は、開発のご相談はこちらからご相談ください。
まとめ
- AIエージェント開発は、対象業務を1つに絞り、完了条件と禁止事項を定めるところから始めます
- AIには分類、要約、提案を任せ、認証、権限、金額計算、入力検証は通常のプログラムで制御します
- 最初は読み取りと提案に限定し、全件承認、条件付き自動化の順に権限を広げます
- PoCはデモではなく、品質、失敗条件、修正時間、1件当たり費用を確認する工程です
- 開発費の一般的な目安は、PoCで150万〜500万円程度、限定的な本番開発で500万〜1,500万円程度ですが、連携数や安全要件で変動します
- 最大実行回数、タイムアウト、権限制御、承認、冪等性、監査ログを組み合わせて誤操作を防ぎます
- 本番導入後も固定テストとログ分析を継続し、モデルや対象業務を一度に変更しないことが重要です
よくある質問
Q1. AIエージェントと生成AIチャットボットの違いは何ですか？
生成AIチャットボットは主に質問への回答や文章生成を行います。AIエージェントは目的に応じて複数の手順を選び、許可されたAPIや社内データを利用して処理を進めます。ただし、重要な更新操作は通常のプログラムと人の承認で制御します。
Q2. AIエージェント開発の費用と期間はどの程度ですか？
一般的な目安として、PoCは150万〜500万円程度・1〜3か月、限定的な本番開発は500万〜1,500万円程度・3〜6か月です。複数システム連携、個人情報、24時間運用、厳格な監査要件がある場合は費用と期間が増えます。
Q3. どの業務からAIエージェントを導入すべきですか？
問い合わせ分類、社内情報の検索、回答案や入力案の作成など、人が結果を確認できる低リスク業務から始めます。返金、契約変更、送金、データ削除のように誤操作の影響が大きい業務を、最初から全面自動化することは避けてください。
Q4. AIエージェントの暴走や誤操作はどう防ぎますか？
利用できるツールと権限を限定し、入力検証、最大実行回数、タイムアウト、費用上限を設定します。更新操作には人の承認と二重処理防止を適用し、AIが誤った指示を出しても禁止操作を実行できない構造にします。
Q5. PoCでは何を評価すればよいですか？
タスク完了率、分類・抽出精度、ツール選択、人による修正率、重大誤操作、処理時間、1件当たり費用を評価します。正常例だけでなく、曖昧な依頼、権限外操作、悪意のある命令、外部システム障害を含む固定テストデータを使用してください。