AIエージェント導入の5つの手順　コールセンターでチャットボット導入と変える点

コールセンターにAIエージェントを入れる手順は、5つに分けられます。任せる手続きを選ぶ、手続きを分解して権限を決める、本人確認と人の承認を組み込む、手続きが完了したかで評価する、権限を段階的に広げる。チャットボットの導入と違うのは、AIが顧客に答えるだけでなく、注文の変更や住所の更新といった書き込みまで行う点で、手順の大半はこの書き込みをどう管理するかに使います。

ここでいうAIエージェントは、総務省・経済産業省のAI事業者ガイドライン（第1.2版）の定義に沿って、目標を達成するために環境を感知し、自律的に行動するAIシステムを指します。コールセンターでは「配送日を変えたい」と言われたら、注文を探し、変更できる条件かを確かめ、システム上で日付を変え、確認の連絡を送るところまでを1つの会話の中で行うAIです。

最初に任せる手続きは、件数の多さではなく、間違えても取り消せるかで選ぶべきだと見ています。件数の多い手続きから始めると、効果は大きく見えますが、誤操作の後始末も件数分だけ発生します。

チャットボットとの違いを、導入時に決めることで並べるとこうなります。

導入時に決めること	答えるチャットボット	手続きまで行うAIエージェント
接続するシステム	FAQ・ナレッジ（読み取り）	注文・顧客・決済などの基幹システム（読み書き）
誤りの影響	誤った案内（訂正の連絡で直せる）	誤った変更（データの修正・返金・再配送が要る）
本人確認	一般的な質問なら不要	書き込みの前に必須
人の関わり方	答えられないときに引き継ぐ	高リスクの操作の前に承認する
評価の単位	回答が正しいか	手続きが正しく完了したか
ログ	会話ログ	会話ログと操作ログ（誰の権限で何を変えたか）

1. 任せる手続きを「取り消せるか」で選ぶ

最初の手順は、候補の手続きを棚卸しすることです。コールリーズン（問い合わせ理由）の上位から候補を挙げ、手続きごとに書き込み先、取り消しやすさ、金額への影響、本人確認の強さを並べます。

OpenAIが公開したエージェント構築の実務ガイドは、エージェントに渡す道具（ツール）ごとに、読み取りか書き込みか、取り消せるか、必要な権限、金銭への影響をもとに低・中・高のリスクを付け、高リスクの操作の前に確認を挟むか人に回すよう勧めています。この考え方を、そのまま棚卸し表にできます。

例として、通販のコールセンターを想定した棚卸し表を載せます（手続きと判定は説明用の仮のものです）。

手続き	書き込み先	取り消し	金額への影響	リスク	最初の扱い
配送状況の確認	なし（読み取り）	不要	なし	低	AIが完結
配送日時の変更	注文システム	出荷前なら可	なし	低	AIが完結（出荷後は有人）
登録住所の変更	顧客システム	可（履歴から戻せる）	間接的（誤配送）	中	AIが実行し、確認メールを送る
注文のキャンセル	注文・決済システム	難しい	あり	高	AIが準備し、人が承認
返金	決済システム	不可	あり	高	当面は有人
解約	契約システム	難しい	あり	高	当面は有人

最初の対象を決めるのは、表の右端の列。この例なら、配送状況の確認と配送日時の変更から始め、住所変更を次に置く。返金と解約は、件数が多くても後回し。

もう1つ確かめるのは、その手続きを人が処理するときに判断の余地がどれだけあるかです。OpenAIの同じガイドは、エージェントが向く業務として、例外や文脈で判断が分かれる業務、規則が複雑で保守しきれない業務、自然言語の読み取りが中心の業務を挙げています。逆に、条件が決まっていて分岐が少ない手続きは、AIエージェントでなくても従来の自動化（IVRの分岐やWebフォーム）で済む場合があります。Anthropicもエージェント構築についての解説で、できるだけ単純な方法から始め、必要なときだけ複雑にするよう勧めています。

2. 手続きを手順書に分解し、使える操作と権限を絞る

2つめの手順は、選んだ手続きを、AIが従う手順書に書き直すことです。OpenAIのガイドは、既存の業務手順書、応対スクリプト、規定をもとにエージェント向けの手順を作るよう勧め、カスタマーサービスならナレッジベースの記事1本がおおむね1つの手順に対応するとしています。オペレーター向けのマニュアルがそのまま出発点になります。

書き直すときは、各ステップで「何を確かめ、どの操作を呼ぶか」を明示します。配送日時の変更なら、注文番号を聞く、注文を検索する、出荷前かを確かめる、変更可能な日を提示する、選ばれた日に更新する、確認メールを送る。出荷済みだった、希望日が対象外だった、といった分岐も手順書に書いておきます。

次に、AIに渡す操作と権限を絞ります。セキュリティの非営利団体OWASPは、生成AIアプリの主要リスクをまとめたLLM Top 10の「過剰な権限」の項目で、原因を不要な機能、過剰な権限、高影響の操作を検証なしで実行できる自律性の3つに分けています。対策として挙げているのは次のようなものです。

• 必要な操作だけを渡す（汎用の操作より、目的を絞った操作を用意する）
• 読み取りで足りるところは読み取り専用にする
• 操作は、対応している顧客の権限の範囲で実行する
• 実行してよいかの判定は、AIではなく接続先のシステム側で行う

コールセンターで特に効くのは最後の点です。「この顧客の注文しか変更できない」「出荷後は日付を変えられない」といった制約を、AIへの指示文ではなく注文システムのAPI側に持たせる。指示文は会話で揺らぎますが、システム側の制約は揺らぎません。APIキーをエージェントに直接渡さない設計については権限設計の記事で詳しく扱いました。

3. 本人確認と人の承認を手続きに組み込む

3つめの手順は、書き込みの前に置く関門を決めることです。関門は2種類あります。

1つは本人確認です。チャットボットなら一般的な質問に本人確認は要りませんが、エージェントが顧客の注文を変えるなら、変える前に本人であることを確かめます。確認の強さは手続きのリスクに合わせ、棚卸し表の「中」以上ではSMSのワンタイムコードなど、会話の外の要素を使うのが安全です。

もう1つは人の承認です。OpenAIのガイドは、人の介入が必要になる典型として、失敗の上限を超えたとき（顧客の意図を何度か取り違えたなど）と、高リスクの操作（注文のキャンセル、高額の返金、支払い）の2つを挙げ、エージェントの信頼性が確かめられるまでは高リスクの操作に人の確認を置くよう勧めています。

承認の置き方は、コールセンターの体制に合わせて選びます。

• その場で承認: AIが操作内容をまとめ、待機中のオペレーターが承認してから実行する。顧客を待たせるので、承認担当の人数を確保できる時間帯に限る
• 後で承認: AIは「受け付けました、確認後にご連絡します」と伝え、承認後に実行する。即時性は落ちるが、人員の山に合わせやすい
• 承認の代わりに確認の連絡: 取り消しやすい手続きは実行後に確認メールを送り、顧客が気づいて止められるようにする

どの手続きをどこまで自動で確定させ、どこから人が承認するかの線引きは、自動確定と人の承認の境界を扱った記事でも型にしています。

4. 会話の正しさでなく「手続きの完了」で評価する

4つめの手順は評価の設計です。チャットボットでは「回答が正しいか」を見ましたが、エージェントでは「手続きが正しく終わったか」を見ます。会話は丁寧でも、別の注文の日付を変えていたら失敗です。

評価の単位を完了にすると、厳しい数字が出ます。エージェントの評価用に作られたτ-bench（タウベンチ）の論文は、模擬の顧客と、業務システムの操作と規定を与えられたAIを会話させ、手続きの結果で採点する方法を示しました。2024年6月の発表時点で、当時の最先端のモデル（gpt-4o）でも成功したタスクは5割未満で、小売の手続きで同じタスクを8回続けて成功する割合は25%未満でした。数字は当時のもので、モデルは更新されています。それでも、1回うまくいったことと毎回うまくいくことは別だという点は、導入の評価にそのまま当てはまります。

そこで、試験では次のように測ります。

• 手続きごとにテストの会話を用意する（素直な依頼、情報が足りない依頼、途中で気が変わる依頼、対象外の依頼を混ぜる）
• 会話の内容ではなく、終了後のシステムの状態（どの注文の何がどう変わったか）を正解と照らす
• 同じテストを複数回流し、毎回成功するかを見る
• 対象外の依頼で、操作せずに人へ渡せたかを成功として数える

試験の合格基準の置き方は、コールセンターAIのPoC評価項目の記事が下敷きになります。エージェントでは、そこに「システムの状態が正しいか」の列が1本加わります。

5. 段階的に権限を広げ、操作ログで監視する

最後の手順は、本番での広げ方と見張り方です。いきなり自動で確定させず、3段階で権限を広げます。

1. 提案のみ: AIは操作内容を組み立てるだけで、実行はオペレーターが行う。AIの提案とオペレーターの実際の操作が一致した割合を記録する
2. 承認付きの実行: 一致率が十分に高い手続きから、AIの実行に切り替え、実行前に人が承認する
3. 自動の実行: 承認でほとんど差し戻しが出なくなった低リスクの手続きから、承認を外す

段階を上げる条件は、事前に数字で決めておきます。たとえば「提案と実際の操作の一致率が4週続けて基準を超えたら次へ」のような決め方です（基準値は自社で置きます）。

監視では、会話ログに加えて操作ログを残します。AIがどの顧客の権限で、どのシステムの、何を変えたか。OWASPは被害を抑える策として、一定時間に実行できる操作の数を制限すること（異常に気づくまでの時間を稼ぐ）と、操作の記録と監視を挙げています。AI事業者ガイドラインの別添も、AIエージェントが自律的な動作の中で人の意図しない注文やファイル削除を行う可能性や、脆弱性を突かれて挙動を操作され、内部データが外部へ送られる可能性に触れています。いずれも、操作ログを見ていれば早く気づけます。

あわせて、止める手順も決めておきます。特定の手続きでエラーや差し戻しが急に増えたら、その手続きだけAIの実行を止めて有人に戻す。誰が止める判断をし、止めている間の電話をどこに流すか。止め方が決まっていない自動化は、問題が起きたときに止められません。

まとめ

• 最初に任せる手続きは件数ではなく、取り消せるかとリスクで選ぶ。棚卸し表の右端の列が出発点
• 手続きはオペレーター向けマニュアルから手順書に書き直し、AIに渡す操作と権限を絞る。制約はAIへの指示でなくシステム側に持たせる
• 書き込みの前に本人確認を置き、高リスクの操作には人の承認を挟む
• 評価は手続きの完了とシステムの状態で測り、同じテストを繰り返して安定性を見る
• 権限は提案、承認付き、自動の順に広げ、操作ログと停止の手順を用意する

自社で最初に任せようとしている手続きは、AIが間違えたとき、誰がどうやって元に戻すか決まっているでしょうか。

よくある質問

基幹システムにAPIが無い場合はどうしますか。

AIが操作する入口が無いので、手続きの実行まではAIに任せられません。まずは受け付けまでに絞り、AIが本人確認と変更内容の聞き取りを済ませて、人がシステムに入力する形から始めます。APIの整備はその間に、件数と取り消しやすさで優先順位を付けて進めます。

最初はどの手続きから任せるのがよいですか。

件数の多さより、間違えても取り消せるか、金額への影響が小さいかで選びます。配送状況の確認のような読み取りだけの手続きや、出荷前の配送日時の変更のような取り消しやすい手続きが候補です。

人の承認を挟むと、自動化の効果が無くなりませんか。

承認は最初から全手続きに置くものではなく、高リスクの操作と導入初期に置くものです。差し戻しがほとんど出なくなった低リスクの手続きから外していけば、効果は段階的に出ます。

チャットボットで使っていたFAQはそのまま使えますか。

回答の材料としては使えますが、手続きには足りません。手続きの手順、分岐、使う操作、承認の条件を書いた手順書が別に要り、オペレーター向けの業務マニュアルがその出発点になります。

注記

本記事は2026年10月16日時点で確認した公開情報（公的ガイドライン・事業者の公開資料・論文）と、編集部による導入手順の設計案に基づきます。表の手続き・判定・基準は説明用の仮のもので、実在企業のデータではありません。τ-benchの数値は2024年6月の論文発表時点のもので、現在のモデルの性能を示すものではありません。特定の製品の推奨ではありません。確認日: 2026年10月16日。

---

出典

• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）本編」
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）別添」
• OWASP Gen AI Security Project「LLM06:2025 Excessive Agency」
• OpenAI「A practical guide to building agents」
• Anthropic「Building effective agents」
• arXiv「τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains（Yao, Shinn, Razavi, Narasimhan, 2024）」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。