最終更新日:
エージェンティックAIガバナンスとは、予測やコンテンツの生成のみを行うシステムとは異なり、自律的に計画を立てて行動を実行するAIシステムの制御を指します。これには、エージェントに許可される権限、自律性の制限、行動のログ記録方法、およびエージェントが誤った行動をとった場合の責任の所在などが含まれます。
AIモデルのガバナンスと何が異なるのでしょうか?
予測AIや生成AIモデルのガバナンスは、正確性、バイアス、説明可能性、コンテンツの安全性など、その「出力の品質」に焦点を当てています。一方で、エージェントには「振る舞い」という第2の側面が加わります。エージェントは自身で手順を選択し、ツールを呼び出し、重要なシステムの状態を変更します。そのため、ガバナンスにおける問いは、エージェントが何に触れることを許されるか、許可なしに何を実行できるか、人が介入するまでにどこまで処理を進められるか、そして事後にどのような記録が残るか、という点に移ります。モデルが誤った回答を出力した場合は「誤った意思決定」が生じますが、エージェントが誤った行動を取った場合は「誤った取引が完了」してしまいます。
エージェント固有の統制にはどのようなものがありますか?
主に次の4つのグループが機能します。自律性分類(Autonomy classification)は、提案のみを行う段階から、承認を得て実行する段階、完全に単独で実行する段階まで、対象となるエージェントにどの程度の独立性を与えるかを規定します。アクション権限付与(Action permissioning)は、エージェントが実行できる具体的な操作やアクセス可能なシステムを定義します。これは通常、継承元の人間が持つ権限よりも限定されたものになります。エスカレーションと閾値(Escalation and thresholds)は、金銭的価値、確信度、あるいは未知の状況など、人間の判断を必須とする条件を設定します。アクションログ記録(Action logging)は、後からその振る舞いを再現できるように、すべてのツール呼び出しと状態変化を記録します。
規制上の要件はどこから生じているのでしょうか?
エージェント型AIを直接対象とする単一の法令は存在せず、要件は複数のソースから構成されています。欧州の「EU AI法」は、リスク分類、透明性、および人間による監視の義務を通じて適用されます。シンガポールのIMDAは、2026年1月に「Model AI Governance Framework for Agentic AI(エージェント型AI向けモデルAIガバナンスフレームワーク)」を公表しました。米国銀行業界における「SR 26-2」は逆のアプローチを採用し、エージェント型AIを適用対象外としています。これにより、各金融機関は自社独自の基準を策定し、それを説明できるように準備する必要があります。セキュリティの観点では、「OWASP Top 10 for Agentic Applications」が共通のリスク評価語彙を提供しています。
マルチエージェントシステムにおいて、何が管理を難しくしているのでしょうか?
エージェントが他のエージェントを呼び出すようになると、前提条件の多くが崩壊します。権限が「推移的」になるため、限定的な権限しか持たないエージェントであっても、より広範な権限を持つ別のエージェントに処理を依頼することで、権限以上の操作を行えてしまう可能性があります。また、エラーが伝播し、チェーンの初期段階における誤った出力が、それ以降のすべてのプロセスで「事実」として扱われます。さらに、どのエージェントがその結果を引き起こしたのかを特定するために、すべてのエージェント間で関連付けられたログを追跡する必要があるため、原因帰属が極めて困難になります。したがって、ガバナンスは個々のエージェントを孤立して管理するのではなく、システム全体に対して機能させる必要があります。これには、呼び出しをまたいで保持されるアイデンティティと、チェーン全体を網羅する追跡(トレース)体制が求められます。
本番導入前に、どのような準備が必要でしょうか?
まず、AIインベントリ(資産目録)に、責任者を明記した上でエージェントを登録すること。次に、目的と許可されたアクションを明記した文書を整備すること。自律性のレベルと、それをオーバーライドするためのエスカレーション条件を設定すること。認証情報は人間から借用するのではなく、エージェント自身にスコープを限定したものを使用すること。エージェントが「何を、なぜ行ったのか」を説明できる十分なログを記録すること。そして、明確に定義された強制停止スイッチと、それを操作する責任者を決めておくことです。エージェントが関与する重大なインシデントのほとんどは、基盤となるモデルの失敗ではなく、これら前提条件のいずれかが欠如していることに起因しています。
実際の導入事例:
調達チームは、サプライヤーの請求書をレビューし、それらを購入注文書と照合して、支払いを承認するエージェントを実行します。このエージェントは、2,500ポンドを超える場合は「要確認」、それ以下の場合は「自律実行」として分類されます。データベースの資格情報はエージェント固有のものであり、購入注文書の読み取りと支払い承認の書き込みに範囲が制限されており、サプライヤーの銀行詳細へのアクセス権はありません。解決できない不一致が発生した場合は、指定された承認者にエスカレーションされます。すべての照合と承認は、請求書参照番号および適用されたルールとともにログに記録されます。サプライヤーが説明フィールドに指示テキストを埋め込んだ請求書を送信した場合、エージェントが取得したコンテンツと指示を分離しているため、ゴールの乗っ取り(ハイルジャック)が防止され、その試みはセキュリティチームのためにログに記録されます。





