AIエージェントを業務へ組み込むときは、できることの多さより、どの操作を任せるかを具体化します。調べる、案を作る、承認を得る、実行するという段階を分けると、自律的に動かす範囲と人が判断する範囲を設計しやすくなります。
定型フローとの違いを押さえる
Anthropicは、事前に決められた経路でLLMやツールを動かすものをワークフロー、LLMが動的に手順とツール利用を決めるものをエージェントと区別しています。用語の使い方には幅があるため、製品名だけで自律性の範囲を判断しないことが大切です。Anthropicの設計解説
たとえば「問い合わせを分類し、担当部署へ送る」という固定処理と、「必要な資料を探し、不足情報を確認し、回答案を組み立てる」という処理では、求められる判断が異なります。定型処理で足りるなら、最初から複雑なエージェントを構成する必要はありません。
操作ごとに権限を決める
次は問い合わせ対応を想定した設計例です。実在サービスの権限仕様や当社の実績ではありません。
| 段階 | AIへ任せる範囲の例 | 人の確認・制御の例 |
|---|---|---|
| 調査 | 許可した社内資料の検索 | 閲覧可能な資料を限定する |
| 作成 | 参照資料を付けた回答案 | 根拠と不足情報を確認する |
| 承認 | 確認者へ案を提出する | 送信内容と宛先を判断する |
| 実行 | 承認済み内容の送信処理 | 承認した内容と実行内容の一致を検証する |
「人が承認する」とだけ書くと、何を承認したかが曖昧になります。宛先、本文、添付、対象データなど、実行を確定する情報を確認できる形にします。承認後に内容が変わった場合の再確認も設計項目です。
入力不足と失敗を通常の流れに含める
エージェントが判断できないとき、無理に処理を続けさせない出口を用意します。必要情報がない、参照先へ接続できない、根拠同士が矛盾する、といった状態を分け、人へ戻す際に何を報告するか決めます。
Anthropicの説明でも、ツールの結果などから進捗を確かめ、必要な時点で人の確認を挟むことや、反復回数の上限といった停止条件が扱われています。自律的な処理には費用や誤りの累積という考慮点があるため、制限した環境でのテストが重要です。同資料のAgents節
実務上は、時間・処理回数・費用の上限、失敗時の連絡先、途中で処理を取り消す方法を候補にします。どの上限を採るかは業務とツールの特性で判断してください。
実行結果を成功メッセージだけで判断しない
送信や登録を行う処理では、AIが「完了」と返しただけでは業務上の完了を判断できません。外部システムの処理結果、対象ID、状態を確認し、期待した変更が起きたかを照合する設計を検討します。
再試行にも注意が必要です。通信が途切れた場合は、処理に失敗したのか、成功後に応答だけ失われたのかを確認します。再送で重複し得る操作では、対象システムの照会や重複防止機能を使えるかを確かめ、無条件の再実行を避けます。これは個別APIの実装例ではなく、業務側が実装担当へ確認する観点です。
試行は閲覧と下書きから始める
最初の試行では、対象資料を限定し、外部への変更を行わない調査・下書きの段階で評価する方法があります。通常の入力に加え、情報不足や対象外の依頼を試し、人へ戻せるかを確かめます。その後、変更操作を追加する必要性と条件を判断します。
評価では、最終結果だけでなく、使った資料、選んだ操作、停止理由を確認できるようにします。機密情報を無制限にログへ残すのではなく、調査に必要な情報とアクセス権を設計してください。
AIエージェントの導入相談では、対象業務、連携先、許可する操作、人の確認箇所を整理すると議論を進めやすくなります。お問い合わせから現在の課題をお知らせください。