【ITニュース解説】CHAPTER 43 AI AGENTS, PLANNING, TOOL CALLING, TASK STATE, PERMISSION BOUNDARIES, HUMAN APPROVAL & SAFE AUTONOMOUS EXECUTION

AIエージェントは、単に質問に答えるだけでなく、複雑な目標を理解し、計画を立て、さまざまなツールを使いこなし、最終的なタスクを完了するまで自律的に動作するシステムである。これは従来のAIモデルが「ユーザー → モデル → レスポンス」という一方向のやり取りだったのに対し、「目標 → 計画 → 検索 → 推論 → 行動提案 → 検証 → 実行 → 観察 → 継続」という多段階のワークフローを持つ点で大きく異なる。このような進化は、AIがより多様で実用的なタスクをこなせるようになる一方で、その設計と運用には厳格なエンジニアリングとセキュリティの要件が伴うことを意味する。

AIエージェントは単一のAIモデルだけを指すのではない。安全なエージェントシステムは、モデルに加えて、全体のワークフローを管理する「オーケストレーター」、現在の状況を記録する「状態管理」、外部と連携するための「ツール」、動作を制限する「ポリシー」、そして実行結果を確認する「検証メカニズム」など、多くの要素から構成される。この「モデルが提案し、アプリケーションが決定する」という明確な役割分担が極めて重要だ。エージェントは、何を見れるか、何を記憶できるか、どのツールを呼び出せるか、どのようなパラメーターを提供できるか、どの行動に人間の承認が必要か、どの行動が禁止されているか、タスクの実行時間やステップ数の上限、そしてすべてのアクションの記録方法など、アプリケーションによって明確な境界が設定される必要がある。

エージェントの基本的な動作は、「ユーザーからの目標」を受け取るところから始まる。まず「エージェントオーケストレーター」が全体を統括し、「プランナー」が目標達成のための具体的な手順（計画）を立てる。この計画は「タスク状態」として記録され、現在の状況がいつでも把握できるようにされる。計画に含まれるツールの呼び出しは、「ツール認可」のプロセスを経て、許可されたものだけが「ツール提案」として提示される。この提案は「検証」され、高リスクなアクションであれば「承認ポリシー」に基づいて「人間による承認」が必要となる場合がある。承認されれば「ツール実行」が行われ、その結果が「観察」される。その後、「検証者」が実行結果を評価し、次のステップに進むか、タスクを完了するかを決定する。

この多段階のワークフローを安全に運用するためには、いくつかの重要な仕組みが不可欠となる。まず、「エージェントセッション」は、個々のエージェントのワークフローを識別し、その進行状況（作成済み、実行中、承認待ち、完了など）を管理する。これにより、長時間にわたるタスクも確実に追跡し、中断された場合でも安全に再開できる。各エージェントタスクは、達成すべき「ゴール」を持ち、これは単なる命令ではなく、システムが扱うデータとして扱われる。タスクは「状態遷移マシン」によって管理され、例えば「作成済み → 計画中 → 実行中 → 承認待ち → 実行中 → 検証中 → 完了」といった明確なステップを順に進む。もし途中で失敗すれば「失敗」、キャンセルされれば「キャンセル済み」という状態に移行する。この明示的な状態管理により、エージェントは「何をしたか」「どのツールを使ったか」「何が承認待ちか」などを正確に記憶し、安全に処理を継続できる。

エージェントが利用できるツールも厳格に管理される。「ツールレジストリ」には、エージェントが利用可能なすべてのツールが明示的に登録される。各ツールには「名前」「説明」「入力スキーマ」「リスク分類（読み取り、書き込み、外部アクション、管理など）」「必要な権限」「承認要否」などのメタデータが定義される。エージェントは、現在のタスクが許可するツールしか利用できない。特に重要なのは、「最小権限の原則」を適用することだ。例えば、文書要約エージェントには文書を「読み取る」権限は必要だが、「文書を削除する」権限や「ユーザーの役割を変更する」権限は不要である。

ツール呼び出しのプロセスも厳重に管理される。AIモデルがツールと引数を「提案」しても、それが直ちに実行されるわけではない。提案された引数はまず「スキーマ検証」され、不正な形式でないか確認される。その後、「権限チェック」と「リソース所有権チェック」が行われ、エージェントがそのツールを呼び出す権限を持ち、かつ対象リソースへのアクセス権があるかを確認する。さらに「リスク分類」に応じて「人間による承認」が必要かどうかが判断される。モデルは「危険な引数」を生成する可能性もあるため、ツール引数は「信用できないデータ」として扱われ、厳密な検証と認可が不可欠となる。

一部の重要な操作、特に外部との通信、不可逆な変更、機密データの操作、アカウント変更など、高リスクなアクションは「人間による明示的な承認」を必須とする。この承認は、「エージェントが何をするかすべて承認する」という意味ではなく、特定の具体的なアクション（例：「プロジェクトXの文書からドラフトレポートを作成する」）に対して行われ、承認には期限が設けられる。これにより、人間はエージェントの行動をピンポイントで制御し、意図しない結果を防ぐことができる。また、開発やテストの際には、実際にアクションを実行せずに動作の流れをプレビューできる「ドライランモード」や、本物のツールを模擬ツールに置き換えて安全に評価できる「シミュレーションモード」が役立つ。

エージェントの「記憶」についても慎重な設計が必要だ。記憶は「タスク状態」「会話コンテキスト」「取得した証拠」「ツール結果」などのカテゴリに分けられ、それぞれ異なる保持期間や認可ルールが適用される。これらを一つにまとめて無制限に保持することは危険だ。また、ツールからの出力（例：外部から取得した情報）も「信用できないデータ」として扱われるべきである。外部コンテンツに、エージェントを操作しようとする指示が含まれている可能性があるため、ツール結果が自動的にエージェントの指示やセキュリティポリシーを変更することは許されない。

エージェントのループ（目標達成のために繰り返し行動するプロセス）も、モデル自身ではなくアプリケーションが制御する。タスクには「最大ステップ数」「最大ツール呼び出し回数」「実行時間の上限」といった明確な制限が設けられ、無限ループやリソースの枯渇を防ぐ。ユーザーは、実行中のタスクをいつでも「キャンセル」したり、「一時停止」したり、「再開」したりできる機能も重要となる。これにより、予期せぬ事態が発生した場合でも、安全にタスクを停止できる。

エージェントのすべての活動は詳細に「観測可能」であるべきだ。各ステップ、ツール呼び出し、モデルの利用状況、承認ステータスなどが記録され、トラブルシューティングや監視に利用される。特に高リスクなアクションについては、「監査証跡」として記録され、いつ、誰が、何をしたか、誰が承認したかが追跡可能になる。

最後に、エージェントシステムの「安全性」は、単に最終的な回答の質だけでなく、多くの側面から評価される必要がある。タスク成功率、ツール選択の正確性、そして特に「不正なアクションの実行率」や「承認プロセスの遵守状況」といったセキュリティ関連のメトリクスが重要となる。エージェントが許可されていないリソースにアクセスしようとした場合、機密情報を漏洩させようとした場合、あるいは無限ループに陥った場合など、多様な「テストシナリオ」を想定し、システム全体を評価する「レッドチーム評価」によって脆弱性を特定し、強固な防御を構築することが不可欠である。

AIエージェントの設計哲学は「モデルが提案し、アプリケーションが決定し、ツールが実行し、検証者が確認する」という明確な責任分担に基づいている。モデルはあくまで理解と提案に専念し、ワークフローの制御はオーケストレーター、認可はポリシーエンジン、実行はツール層、結果のチェックは検証者、そして全てを記録するのは監査層という役割分担である。これにより、AIモデルが自律的に動く中で、常に人間の管理下におかれ、安全で信頼性の高いシステムが構築される。これは、今後のAIシステムにおいて、機能性と安全性の両立を実現するための重要な基盤となる考え方だ。