AIエージェントは、目標に向けて情報を集め、必要なツールを選び、複数の処理を進める仕組みです。単に質問へ文章で答えるチャットボットとの違いは「業務の手順を進めるか」にあります。ただし、AIが自律的に動くことと、外部送信やデータ更新まで無制限に任せることは別です。
01チャットボットとの違いを一つの例で見る
「この商品はいつ届きますか」と聞かれたとき、案内文だけを返すのが一般的なチャットボットの使い方です。AIエージェントなら、注文番号を確認し、権限の範囲で配送システムを照会し、状況をまとめ、返信案を作るところまで進められます。確認できない注文なら、無理に答えず担当者に引き継ぎます。
基本となる要素は、判断に使うモデル、参照や操作に使うツール、目的と制約を示す指示です。ツールをつなげただけで信頼できる仕組みになるわけではありません。アプリケーション側で権限と入力を確認し、人が介入する点を決める必要があります。
02AIエージェントに向く業務と向かない業務
向いているのは、手順に沿って進められるが、入力文書や例外にばらつきがある業務です。問い合わせの分類と回答案、社内資料を探したうえでの案内、会議メモからのタスク整理などが候補です。結果を担当者が確認できることも重要です。
一方、条件が明確な転記や単純な通知は通常のプログラムで十分な場合があります。また、支払い、契約変更、重要データの削除などは、最初から自動実行させず、明確な承認を挟むべきです。「AIを使うこと」自体を目的にしない方が、費用とリスクを抑えられます。
03導入前に決める四つのこと
- 対象業務：どの入力から始まり、何ができたら完了か
- 参照と操作：どの資料を読めるか、何を変更できるか
- 人の承認：どの場面で確認し、誰が最終責任を持つか
- 評価：現行時間、誤り、修正時間、引き継ぎ率をどう比較するか
たとえば問い合わせ対応なら「分類と返信案まではAI、送信は人」と線を引きます。この一文が決まるだけでも、必要なツールやテストケースを絞れます。
04小さな試験で確かめること
個人情報を除いた過去の問い合わせを用意し、普通の質問だけでなく、情報不足、複数の用件、古い資料、対象外の相談を混ぜます。出力を「分類・根拠・返信案・確認が必要な点」に分けて、人が判定します。正しい回答数だけでなく、判断できないときに止まれたか、確認に何分かかったかも記録します。
結果が安定すれば、対象を少しずつ広げます。うまくいかない場合は、プロンプトを長くする前に、参照資料の品質や業務ルールを見直します。最初から複数のエージェントを組み合わせる必要はありません。
05まず何をすればよいか
一つの業務について「入力、期待する出力、参照資料、禁止する操作、承認者」を書き出してください。決められない項目があれば、それが導入前に解決すべき課題です。具体的な設計と試験の進め方は「AIエージェントの作り方」の記事で整理しています。
06具体例：問い合わせ一件を最後まで追う
架空の問い合わせ「先週注文した商品がまだ届きません。いつ届きますか」を受けたとします。単純なチャットボットは一般的な配送案内を返します。AIエージェントとして設計する場合は、注文番号がなければ聞き返し、番号を受け取ったら本人確認済みの利用者がその注文を見られるかをアプリ側で判定し、配送情報を読み取ります。配送記録が見つかれば「注文番号、現在の状態、確認時刻、根拠」を付けて返信案を作り、担当者へ渡します。ここまでが初期版の完了です。メールの送信ボタンは人が押します。
同じ質問でも、注文番号が他人のものなら照会を拒否し、配送APIが止まっていれば「確認できない」と伝え、到着予定が資料にないなら日付を作りません。この分岐がないまま「自律的に回答する」とだけ決めても、業務には投入できません。逆に、注文番号が決まれば固定のデータを表示するだけなら、従来のプログラムで足りる場合があります。文章の解釈や複数資料の照合が実際に必要かが採用の判断軸です。
試験では、正常な問い合わせ、番号不足、他人の注文、API障害、同じ内容の再送を用意します。各ケースで「返した回答」だけでなく「どのツールを呼んだか」「送信や更新が実行されなかったか」を確認し、担当者の確認時間と誤案内を記録してください。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。