エージェンティックAIは、わずか18ヶ月の間に研究段階のプロトタイプから企業の実用フェーズへと移行しました。Gartner社は、2024年には1%未満であったエージェンティックAI機能が、2028年までに企業向けソフトウェアアプリケーションの3分の1以上に組み込まれるようになると、2025年末時点で予測しています。[1] Salesforceは「Agentforce」を立ち上げ、Microsoftは「Copilot Studio」にエージェントのオーケストレーション機能を組み込みました。ServiceNow、SAP、その他数十の企業もこれに続いています。企業にとっての課題は、もはやAIエージェントを導入するかどうかではなく、問題が発生する前に「エージェンティックAIガバナンス」を確立できているかどうかにあります。

この緊迫感には確かな理由があります。エージェンティックAIシステムは、従来のほとんどのガバナンスフレームワークが想定していたAIとは質的に異なります。分類器はラベルを付与し、チャットボットはテキストを生成します。これに対し、エージェントは目標を追求します。複数ステップのワークフローの計画、ツールの選択、アクションの実行、結果の観察、そして反復処理を、人間による最小限の介入のみで、時には数十回もの意思決定にわたり自律的に行います。この「運用の自律性」こそがエージェントの価値であると同時に、ガバナンスを困難にする要因でもあります。エージェンティックAIガバナンス（自律型AIエージェントが許容可能なリスク境界内で動作することを保証するための一連のポリシー、管理策、監視体制）は、もはや将来の検討課題ではなく、企業にとって今すぐ取り組むべき急務となっています。

本ガイドでは、企業向けエージェンティックAIガバナンスの実践的なフレームワークを提示します。エージェンティックAIシステムとは何か、なぜ独自のガバナンス対応が必要なのか、既存の規制がどのように適用されるのか、企業が実装すべき中核的なガバナンス管理策、そしてエージェントがもたらす革新性を阻害することなく、これらの管理策を実務に組み込む方法について解説します。

エージェンティックAIは何が異なるのか

「エージェンティックAI」という用語は、単に人間が消費するための出力を生成するだけでなく、目標に向けて自律的なアクションを実行できるAIシステムを指します。この違いは重要です。なぜなら、それによってリスクプロファイルが根本的に変化するからです。

従来のAIシステムは「要求と応答（リクエスト・レスポンス）」のパラダイムで動作します。ユーザーがインプットを提供し、システムがアウトプットを生成し、ユーザーがそれをどう扱うかを決定します。重要なすべてのステップに人間が関与し続けています。これに対し、エージェント型システムはこのパターンを打ち破ります。大まかな目標を受け取ると、それをサブタスクに分解し、各ステップを達成するためのツールを選択して呼び出し、中間結果を評価し、アプローチを調整します。これらの一連のプロセスは、各段階での完全な承認から、完全な自律実行にいたるまで、さまざまな度合いの人間による監視のもとで行われます。

エージェンティックAIを従来のシステムと区別し、特有のガバナンス上の課題を生み出す3つの特徴があります。

自律的なアクションの実行

エージェントは単に推奨するだけでなく、自ら行動します。メールの送信、コードの実行、データベースの変更、APIの呼び出し、ファイルの作成、外部サービスとの連携などを行います。それぞれの行動は、元に戻すことが困難または不可能な形で世界の状況（ステート）を変化させます。誤って分類された画像は修正できますが、間違った受信者に送信されたメール、上書きされたデータベースレコード、あるいは誤って実行された金融取引は、単純に元に戻すことはできません。

複数ステップの推論チェーン

エージェントは、各ステップが前回のステップに基づいて構築される長期的な推論チェーンに沿って動作します。「この未充足のポジションに最適な候補者を見つける」という1つの大まかな指示だけでも、どのデータベースを検索するか、どの基準を重視するか、どの候補者を最終候補リストに残すか、彼らとどのようにコミュニケーションを取るかといった、数十の中間意思決定がトリガーされる可能性があります。単一の意思決定システム向けに設計されたガバナンスフレームワークでは、このように連鎖する複雑さに対処するのは困難です。

動的なツールの呼び出し

現代のエージェントアーキテクチャでは、システム設計時や評価時には想定されていなかった、API、データベース、ウェブサービス、コードインタープリタなどのツールを、実行時にエージェントが自律的に発見して呼び出すことができます。これはリスク評価とコンプライアンスにおいて「常に変化する標的」に対処するようなものです。月曜日時点でのシステムの機能が、金曜日には全く異なるものになっている可能性があるのです。

これら3つの特徴は互いに影響し合います。自律的なアクション実行能力を持ち、複数ステップの推論チェーンに沿って動作し、実行時に発見したツールを動的に呼び出すエージェントは、従来のAIシステムのガバナンスよりも単に難易度が高いというだけでなく、構造的に異なるガバナンス上の課題を突きつけます。

既存の規制はどのように適用されるか

現在のAI規制はエージェント型システムをカバーしておらず、ガバナンス義務が生じるには新たな法的枠組みが必要であるという誤解がよく見られます。これは誤りであり、「エージェント専用」の規制を待っている組織は、すでに施行されている法律のもとで不適合（違反）となるリスクがあります。

EU AI法

EU AI法第3条第1項における「AIシステム」の定義では、「様々なレベルの自律性を持って動作するように設計され、展開後に適応性を示す可能性があり、明示的または黙示的な目的のために、受け取ったインプットから、物理的または仮想的な環境に影響を及ぼし得る予測、コンテンツ、推奨、または決定などのアウトプットをどのように生成するかを推論する、機械ベースのシステム」と説明されています。[2]

この定義のあらゆる要素が、何の無理もなくエージェンティックAIをカバーしています。「様々なレベルの自律性」は、人間の指示による動作から完全な自律動作までのスペクトルを明確に想定しています。「黙示的な目的」は、主にプロンプトとして明示されるのではなく、設計や学習によって目的が暗示されるシステムを捉えるために起草されたものですが、エージェントが大まかな指示を分解する際に追求する、創発的なサブゴールをカバーするのに十分な広さを持っています。ただし、この解釈上の見解は、法執行やAIオフィスによる公式ガイダンスを通じてまだ検証されていません。[3] 「決定」は、エージェントが各ステップで行うアクションの選択を捉えています。そして「物理的または仮想的な環境に影響を及ぼし得る」という表現は、単なる受動的な出力生成を超えて、エージェントの行動を定義づける「環境を変化させるアクション」にまで及びます。

同法の義務適用は段階的に進められます。許容できないリスクをもたらすAIシステムの禁止は2025年2月2日に発効しました。汎用AI（GPAI）モデルに関する義務は2025年8月2日から適用されます。附属書IIIに基づく高リスクシステムに関する一連の義務は、2026年8月2日に全面施行されます。[4] 高リスクのユースケースでエージェント型システムを導入する組織にとって、準備のための猶予期間は狭まりつつあります。

エージェント型システムが附属書IIIにリストされている高リスクのユースケース（採用決定、与信評価、法執行、重要インフラの管理など）に該当する場合、一連の高リスク義務がすべて適用されます。これらには、リスク管理システム（第9条）、データガバナンス（第10条）、技術文書（第11条）、記録保持と自動ロギング（第12条）、透明性（第13条）、人間による監視（第14条）、ならびに正確性、堅牢性、サイバーセキュリティの要件（第15条）が含まれます。[5] 特に第12条は強調に値します。動的なツール呼び出しを伴う複数ステップの推論チェーンに沿って意思決定が展開されるシステムにとって、ロギング要件は技術的に最も要求が厳しく、かつ運用上最も正確に対応すべき重要な義務となります。

同法の運用フレームワークは、エージェント型ユースケース（特に、動的システムに対する適合性評価、エージェントがサードパーティ製ツールを呼び出す場合における「プロバイダー」と「デプロイヤー」の責任分担、および1秒間に数十回ものマイクロ意思決定を行うシステムにおいて「均衡の取れた」人間による監視が何を意味するかなど）において課題に直面しています。[6] しかし、規制の適用範囲は明確です。エージェンティックAIシステムは同法における「AIシステム」であり、義務が適用されます。

GPAIモデルの義務

多くの企業向けエージェントは、サードパーティ（Anthropic、OpenAI、Google、Metaなど）が提供する汎用AI（GPAI）モデルをベースに構築されています。EU AI法は、第51条から第56条において、技術文書の作成、著作権ポリシーの透明性、そしてシステム的リスクをもたらすと指定されたモデルに対する敵対的テスト（レッドチーム演習）やインシデント報告など、GPAIモデルプロバイダーに対して特定の義務を課しています。[7] 2025年末に最終決定された「GPAI実施規範（Code of Practice）」は、これらの義務を満たすためのコンプライアンス経路を提供しています。

企業デプロイヤー（導入組織）にとって、GPAIプロバイダーの義務とデプロイヤーの義務との相互作用は、階層的なコンプライアンスの構図を生み出します。基盤モデルプロバイダーが特定の責任を負い、導入組織がその他の責任を負います。エージェントフレームワークが、GPAIモデル、オーケストレーションレイヤー、およびサードパーティ製ツールを組み合わせて複合システムを構築する場合、バリューチェーン全体での義務の割り当ては、それ自体がガバナンス上の課題となります。これについては、以下のマルチステークホルダーに関するセクションで直接説明します。

ISO/IEC 42001

2023年12月に発行されたAIマネジメントシステムに関する国際規格は、AIマネジメントシステム（AIMS）の確立、実施、維持、および継続的改善のためのフレームワークを提供します。[8] エージェンティックAIを明確に特定しているわけではありませんが、リスク評価、人間による監視、継続的モニタリングに関する管理策は直接適用可能です。ISO 42001の認証取得を目指す組織は、自社のAIマネジメントシステムが従来のAIアプリケーションだけでなく、自律型エージェントの導入も明確にカバーしていることを確認する必要があります。

NIST AIリスクマネジメントフレームワーク

NIST AI RMFの4つのコア機能（「ガバナンス（Govern）」、「マッピング（Map）」、「測定（Measure）」、「管理（Manage）」）は、エージェント型システムにも自然に拡張できる構造化されたAIリスク管理アプローチを提供します。[10] 文脈に応じたリスク評価と継続的モニタリングを重視するこのフレームワークは、エージェントの行動が動的に変化するという特性に特に適しています。生成AIのリスクに関するコンパニオンガイドライン（NIST AI 600-1）は、プロンプトインジェクションや意図しないデータ漏洩など、ツールを使用するエージェントに関連する複数のリスクを扱っています。[10] また、AIシステムの定義においてEU AI法第3条第1項に影響を与えたOECDも、自律性のレベルを次元の1つとして含む分類フレームワークの策定を積極的に進めており、この取り組みは国際的なエージェンティックAIガバナンスの発展に大きな影響を与えると考えられます。[11]

台頭する州レベルおよび業界固有の要件

2026年2月に施行予定のコロラド州AI法（係属中の法改正案を条件とする）は、高リスクAIシステムの開発者および導入者に対し、重大な意思決定におけるアルゴリズムによる差別を回避するための「合理的な配慮」を行うよう求めています。[12] 採用、金融、保険、住宅に関する意思決定に直接的または実質的な影響を与えるエージェント型システムは、間違いなくこの適用範囲に含まれます。金融サービス分野では、リスク評価や意思決定に使用されるAIエージェントに対して省庁間のモデルリスク管理ガイダンス（連邦準備制度理事会のSR 11-7および通貨監督庁のOCC 2011-12）が適用されますが、これらは従来の統計モデルを想定して設計されたものであるため、自律的なツールアクセスを持つ基盤モデルベースのエージェントに適用する際は、慎重な解釈が必要です。[13]

エージェンティックAIガバナンスフレームワーク

エージェンティックAIを管理するには、前述の特徴（自律的なアクション実行、複数ステップの推論、動的なツールの呼び出し）に対処する管理策が必要です。Enzaiが企業のガバナンスチームと共同で開発したこのフレームワークは、これらの管理策を「自律性の分類」、「アクションのホワイトリスト登録」、「エスカレーションロジック」、「トレーサビリティ」、「継続的モニタリング」の5つのレイヤーに整理しています。各レイヤーは、その前のレイヤーの上に構築されます。

レイヤー1：自律性の分類

すべてのエージェントに同じレベルのガバナンスが必要なわけではありません。人間が確認して承認するためにメールの返信案を作成するエージェントと、財務取引を自律的に実行するエージェントでは、リスクプロファイルが根本的に異なります。エージェンティックAIガバナンスプログラムの最初のステップは、各エージェントの自律性レベルを分類し、その分類に応じた適切な管理策をマッピングすることです。

この分類はモデル固有ではなく、ユースケース固有である必要があります。同じ基盤モデルが、ある導入環境では階層1の支援型として動作し、別の導入環境では階層3の制約付き自律型エージェントとして動作することがあります。ガバナンス義務は、モデルではなく、実際のシステム展開（デプロイメント）に対して発生します。

レイヤー2：アクションのホワイトリスト登録と制限付きアクションスペース

エージェンティックAIに対する最も効果的な管理策は、その行動範囲を制限することです。発生し得るすべての障害モードを予測して防止しようとするのではなく、アクションのホワイトリストを定義することで、エージェントが実行を許可されているアクション（呼び出し可能なツール、呼び出し可能なAPI、アクセス可能なデータ、変更可能なシステム）を明確に定めます。

これは「許可リスト」アプローチであり、禁止リスト（ブラックリスト）アプローチではありません。デフォルトの姿勢として、明示的に許可されていないアクションはすべて禁止されます。これは、ソフトウェアシステムにおける一般的なセキュリティモデル（明示的に禁止されていないものはすべて許可される）を逆転させたものであり、エージェンティックAIシステムが設計者の想定していなかったアクションを自ら発見し、試みる可能性があるという現実を反映しています。

具体的な実装では、以下の3つのレベルでアクションの境界を定義します。

• ツールアクセス： エージェントが呼び出すことのできるAPI、データベース、サービス、およびコード実行環境

• パラメータの制約： エージェントが各ツールに渡すことができるインプット（例えば、データベースクエリを実行するエージェントに対して、特定のテーブルへの読み取り専用操作のみに制限するなど）

• 影響制限： 単一のアクションが及ぼす影響の範囲に対する閾値（例えば、人間による承認なしにエージェントが承認できる取引金額の上限を設定するなど）

運用の実務において極めて重要な考慮事項として、ツールの状況が変化するのに合わせてホワイトリストを維持管理しなければなりません。基盤モデルプロバイダーがモデルの動作を変更するアップデートを提供した場合や、エージェントのアクションスペースに新しいツールが追加された場合は、ホワイトリストを再確認して検証し直す必要があります。ホワイトリストを、常に変化する「生きた」ガバナンス資産としてではなく、一度設定したら固定の静的な構成として扱うことは、よくある失敗パターンの1つです。

レイヤー3：エスカレーションロジック

たとえ制限されたアクションスペース内であっても、エージェントは自身の能力や権限を超える状況に遭遇することがあります。効果的なガバナンスには、エージェントが自律動作を継続するのではなく、いつ人間に制御を戻すべきかに関する明確なルール（事前定義されたエスカレーションパス）が必要です。

エスカレーションをトリガーする条件には、以下を含める必要があります。

• 確信度の閾値： 選択したアクションに対するエージェントの確信度が、定義されたレベルを下回った場合

• 影響範囲の閾値： 提案されたアクションが、事前定義された影響制限（金銭的価値、影響を受けるレコード数、不可逆性など）を超える場合

• 異常検出： エージェントの行動が想定されたパターンから逸脱した場合

• 領域の境界： エージェントが、定義された適用範囲外のタスクや領域に遭遇した場合

• エラー状態： ツールの呼び出しが失敗したか、予期しない結果が返された場合

エスカレーションメカニズムの設計は、そのトリガー条件自体と同等に重要です。エスカレーションはエージェントにとって摩擦のないものである必要があり（エスカレーションを実行したエージェントに不利益を与えるような設計パターンによって、エージェントがエスカレーションを回避しようとする「動機」を与えてはなりません）、人間にとっても実行可能である必要があります（エスカレーションの際、人間がエージェントの推論チェーン全体を最初から再構築することなく、十分な情報に基づいて迅速に意思決定を行えるだけのコンテキストを提供する必要があります）。

レイヤー4：トレーサビリティと監査証跡

EU AI法に基づく法的要件（高リスクシステムに対する第12条）および実務的なインシデント対応の双方が、エージェント活動の包括的なロギングを要求しています。[14] エージェント型システムにおいては、単にインプットとアウトプットを記録するだけでなく、推論の全プロセス、ツールの呼び出し、中間結果、および各ステップでの意思決定をキャプチャすることを意味します。

エージェンティックAIの効果的な監査証跡には、以下の内容を記録する必要があります。

• エージェントに提供された最初の目標または指示

• 各推論ステップと、アクション選択の根拠（理由）

• すべてのツール呼び出し（呼び出されたツール、渡されたパラメータ、受信した応答を含む）

• 実行されたアクションとその結果

• エスカレーションイベントと人間による介入履歴

• エージェントのアクションに起因する環境状態の変化

• 関連するイベントを紐付けるタイムスタンプとセッション識別子

これらのログは、インシデント発生後の調査、法規制への準拠、ガバナンス管理策の継続的な改善、および問題発生時の責任追跡など、複数の目的に使用されます。改ざんを防止するため、ログは不変（イミュータブル）で、タイムスタンプが付与され、エージェントシステム本体とは独立した安全な場所に保存される必要があります。

レイヤー5：継続的モニタリング

導入前にエージェントを評価し、その後も準拠し続けると仮定する「静的な時点評価」は、機能や行動が動的に変化する可能性のあるシステムにおいては不十分です。エージェンティックAIガバナンスには、複数の側面にわたる継続的なモニタリングが不可欠です。

• パフォーマンス監視： エージェントのアウトプットが品質および正確性の閾値を満たしているか

• 行動監視： エージェントの行動が想定されたパターンの範囲内に収まっているか。アクションの分布に経時的なシフトが見られないか

• コンプライアンス監視： エージェントのアクションが許可されたアクションスペース内に収まっているか。エスカレーションプロトコルが遵守されているか

• 公平性監視： 個人に関する意思決定を行う、またはその決定に影響を与えるエージェントについて、保護されるべき属性に関わらず結果が公平であるか

• セキュリティ監視： エージェントが敵対的なインプット、プロンプトインジェクションの試み、またはその他の操作にさらされていないか

モニタリングはガバナンスの管理策にフィードバックされる必要があります。モニタリングによって異常（許可リスト以外のアクション、出力分布のシフト、敵対的な操作を示唆するパターンなど）が検出された場合、可能な限り自動化された対応（エージェントの一時停止、エスカレーションのトリガー）を行い、人間のレビュー用に文書化する必要があります。

エージェントが行動したときの責任の所在は？

エージェンティックAIガバナンスにおいて最も困難な側面の1つは、責任が複数のアクターに断片化していることです。典型的な企業向けエージェントの導入には、少なくとも4つの関係者が関与します。基盤モデルプロバイダー（OpenAI、Anthropic、Google、Metaなど）、エージェントフレームワークまたはオーケストレーションレイヤー（サードパーティ製プラットフォーム、または自社開発のもの）、導入組織、そしてエージェントが実行時に呼び出すツールやAPIのプロバイダーです。

EU AI法はプロバイダーとデプロイヤーの間で義務を分割しており、一部の規定では輸入業者や販売業者にも言及しています。[15] しかし、この二者択一的な構図は、エージェントの複雑なバリューチェーンにすっきりと当てはまりません。サードパーティ製の基盤モデルと、外部APIを呼び出す自社開発のオーケストレーションレイヤーを組み合わせたエージェントの「プロバイダー」は誰になるのでしょうか。第25条は、サードパーティがAIシステムを修正または再利用し、潜在的に自らがプロバイダーとなる状況を扱っていますが、動的に構成されるシステムにおけるその境界線は依然として曖昧なままです。[16]

この責任の断片化は、多くの組織が見落としがちな基盤モデルのサプライチェーンリスクも生み出します。モデルプロバイダーがアップデート（新しいモデルバージョン、変更された安全性フィルター、修正された動作パターンなど）を配信すると、以前のバージョンに対して検証されたガバナンス管理策が維持されなくなる可能性があります。アクションのホワイトリスト、エスカレーションの閾値、および適合性評価はすべて、特定のモデルの基本動作を前提としています。デプロイヤー側での変更がないにもかかわらず、裏側で行われるサイレントモデルアップデートによって、それらの前提が無効化されてしまうリスクがあります。

実務的なガバナンスは、この断片化を考慮に入れなければなりません。エージェンティックAIを導入する組織は、以下の取り組みを行うべきです。

• 各エージェントの導入に関するバリューチェーン全体をマッピングし、すべての関係者とそのガバナンス責任を特定する

• ツールおよびAPIプロバイダーとの間で、データの取り扱い、法的責任、およびインシデント対応を明確にした契約を締結する

• 明確な内部説明責任構造を維持する（各エージェント導入のオーナーは誰か、モニタリングの責任者は誰か、介入またはシャットダウンを行う権限を持つのは誰か）

• 基盤モデルのバージョン固定（バージョンピン留め）および変更管理プロセスを実装し、プロバイダーがアップデートをリリースした際の再検証トリガーを設定する

• 規制監査をクリアできる方法で責任の配分を文書化する

エージェンティックAIにおけるインシデント対応

ガバナンスとは、単に障害を防止するだけでなく、障害が発生したときに効果的に対応することでもあります。エージェンティックAIシステムには、その自律的かつ複数ステップにわたる特性を考慮したインシデント対応手順が必要です。

エージェンティックAIのインシデント対応計画には、以下を含める必要があります。

• キルスイッチ： エージェントの実行を即座に停止し、ツールアクセスを無効化してそれ以上のアクションを防ぐ機能。これは技術的に高い信頼性（エージェント自身の「協力」に依存しない設計）を持ち、指定された担当者が数秒以内に作動できる必要があります

• ロールバック手順： 可能な限り、エージェントによって実行されたアクションを元に戻すための事前定義された手順。すべての行動を元に戻せるわけではないため、被害範囲を限定する上で、上記の監査証跡と影響制限の設計が極めて重要になります

• 通知義務： 規制対象となる業界においては、特定のエージェント障害が報告義務をトリガーする場合があります。金融サービスにおいては、不正な取引が発生した場合、数時間以内の規制当局への通知が求められることがあります。EU AI法のもとでは、高リスクAIシステムが関与する重大なインシデントは、市場監視当局に報告しなければなりません

• 根本原因分析： インシデント発生後の調査において、レイヤー4でキャプチャされた監査証跡を使用し、最初の目標から各ツールの呼び出し、意思決定、そして障害発生地点にいたるまでの推論チェーン全体を追跡します

インシデント対応計画は、最初の障害が発生してからではなく、システム導入前に策定されるべきです。アクション境界の突破、エスカレーションの失敗、侵害されたツールからの応答などをシミュレートした机上訓練（テーブルトップエクササイズ）を行うことで、チームはプレッシャーの下でも効果的に対応できる筋肉（習熟度）を鍛えることができます。

エージェンティックAIガバナンスの実務への落とし込み

ガバナンスフレームワークは、実務において実装されて初めて価値を持ちます。エージェントがもたらすはずのイノベーションを阻害するほどの摩擦を生むことなく、これらを実装する必要があります。フレームワークと実務の間のギャップを埋めるのに役立ついくつかの原則があります。

ガバナンスをエージェントのライフサイクルに統合する

ガバナンスは、エージェントの開発や導入と並行して進める別個のワークストリームであってはなりません。それは開発パイプライン自体に組み込まれるべきです。具体的には、設計段階での「自律性の分類」、開発時の「アクションのホワイトリスト登録」、導入前の「エスカレーションロジックのテスト」、そして本番環境での「継続的モニタリング」です。これは、セキュリティにおける「シフトレフト」の動きと同じです。ガバナンスは事後的に追加するものではなく、最初から組み込まれている必要があります。

ガバナンス管理策を自動化する

手動のガバナンスプロセスでは、機械のスピードで動作するエージェントのペースについていくことができません。アクションのホワイトリスト登録は、ポリシー文書を通じてではなく、プログラム的に適用されなければなりません。エスカレーションのトリガーは、人間がログを監視することに依存するのではなく、自動的に実行される必要があります。コンプライアンスチェックは、開発チームに面倒な申請書の記入を求めるのではなく、CI/CDパイプライン内の自動化されたゲートとして実行し、エンジニアリングチームに明確な合格/不合格（パス/フェイル）シグナルを提供するようにすべきです。

AIインベントリ（目録）にガバナンスを組み込む

すべてのエージェンティックAIシステムは、自律性の分類、許可されたアクションスペース、エスカレーションプロトコル、モニタリング構成、責任の割り当て、および基盤モデルのバージョンを記録する「中央集中型のAIインベントリ」に登録される必要があります。このインベントリはガバナンスプログラムの土台です。これなしでは、組織はどのようなエージェントが導入されているか、何を行う権限が与えられているか、そして誰に責任があるのかという基本的な質問に答えることができません。

実用性を考慮して段階的に実装する

数十のエージェントを導入する組織が、すべての導入環境に対して5つのガバナンスレイヤーすべてを同時に実装することは不可能です。実践的な推奨順序は以下の通りです。

1. インベントリの作成から始める： 可視化されていないものは管理できません。非公式に立ち上げられたシャドーAIも含め、導入されているすべてのエージェントをカタログ化します。

2. 自律性レベルを分類する： 各エージェントを階層（ティア）にマッピングします。これにより、その後に適用される各管理策の適切な強度（バランス）が決定されます。

3. 階層3および階層4のエージェントからアクションのホワイトリストを優先実装する： これらは最も高いリスクを伴うため、制限付きアクションスペースによる恩恵を最も大きく受けます。

4. 初日から監査証跡を構築する： ロギングは、早い段階で実装するコストが最も低く、後から追加（レトロフィット）するコストが最も高くなる管理策です。

5. 導入が進むにつれて継続的モニタリングを重ねる： まずはコンプライアンス監視（エージェントがホワイトリスト内に留まっているか）から開始し、時間の経過とともに、行動や公平性のモニタリングへと範囲を広げていきます。

ガバナンスを競争上の優位性として捉える

ガバナンスを単なるコンプライアンスコストと見なす組織は、投資を怠り、結果としてエンジニアリングチームの不満を募らせることになります。より良いアプローチは、ガバナンスを「スケール（規模拡大）のための必要条件」と捉えることです。体系的な管理策がなければ、より野心的な取り組みに対する適切な監視体制を実証できないため、エージェントの導入は低リスク・低価値のユースケースに限定されてしまいます。ガバナンスこそが、企業が慎重な試験運用（パイロット）プログラムから、真のビジネスインパクトをもたらす本格的な本番導入へと移行することを可能にする原動力です。

今後のエージェンティックAI規制の展望

エージェンティックAIガバナンスを取り巻く環境は、今後2年間で急速に進化する見通しです。CENおよびCENELECは、合同技術委員会21（JTC 21）を通じて、EU AI法のもとでの整合規格（Harmonised Standards）の策定を進めており、標準化プログラムの加速を反映して2025年6月にそのマンデートが修正されました。[17] これらの規格は、あらゆる場面で人間の介入を求めることなく、高度に自律的なシステムにおいて「バランスの取れた」人間による監視（制限付きアクションスペース、構造化されたチェックポイント、監査証跡、介入メカニズムなど）がどのような形をとるべきかに対処する必要があります。

欧州委員会は、新たなエージェント特有のリスクが発生した際、法改正プロセスを経ることなく、委任権限を通じて附属書IIIの高リスクユースケースリストをアップデートする権限を持っています。[18] 欧州委員会のガイダンスは、プロバイダーとデプロイヤーの責任の枠組みがエージェントのバリューチェーンにどのようにマッピングされるか、また実行時のツール呼び出しが第3条第23項における「実質的な変更（substantial modification）」にどの時点で該当するかを明確にする役割も果たします。第56条に基づく実施規範（Codes of Practice）は、GPAIモデルレイヤーにおけるエージェント特有のリスク（制御機能、ツール使用のロギング、およびアクションスペースの制限など）に対処するための、もう1つの重要な手段を提供します。[19]

IAPPやOECDを含む業界団体も、自律型AIのためのガバナンスガイダンスの策定に積極的に取り組んでいます。[20] ISO/IEC JTC 1/SC 42は、ISO 42000シリーズのAI標準規格の拡張を継続しており、導入環境が成熟するにつれて、エージェントに特化した新たな作業項目が登場することは十分に予想されます。

これらの規格やガイダンスが確立されるのを待ってから行動を起こす組織は、最初からガバナンスを想定して設計されていないエージェント導入環境に対して、後からガバナンスを改修して組み込むことになります。これは、多大なコストと運用の混乱を伴う作業になります。より賢明なアプローチは、今すぐガバナンスのインフラを構築し、規制や規格に基づく要件が具体化するのに合わせて、柔軟に適応させていくことです。

エージェンティックAIのガバナンスという課題は非常に現実的ですが、全く前例のないものではありません。企業はこれまでにも、アルゴリズム取引から自動運転車、ロボティック・プロセス・オートメーション（RPA）にいたるまで、他の複雑で自律的な高リスクシステムを管理してきました。その基本原則は同じです。「リスクを分類し、行動を制限し、エスカレーションを義務付け、トレーサビリティを維持し、継続的に監視すること」です。新しい点は、エージェンティックAIが導入されるスピードと、それが企業の機能に触れる範囲の広さにあります。

それぞれ異なる自律性ティア、ツールアクセス構成、および規制義務を持つ数十のエージェント導入環境にわたって、これら5つのガバナンスレイヤーを実装することは、ポリシーの課題であると同時に、インフラの課題でもあります。Enzaiでは、自律性の分類やアクションのホワイトリスト登録から、EU AI法、ISO 42001、およびNIST AI RMFにわたる継続的モニタリングや規制コンプライアンスにいたるまで、こうしたインフラ構築の課題を解決するためにプラットフォームを設計しています。詳細については、ぜひデモをご予約ください。

Enzaiは、抽象的なポリシーから具体的な運用の監視体制への移行を支援するために構築された、最先端のエンタープライズAIガバナンスプラットフォームです。当社のAIリスク管理プラットフォームは、エージェンティックAIガバナンスを管理し、包括的なAIインベントリを維持し、EU AI法コンプライアンスを確実に達成するために必要な、特化したインフラを提供します。複雑なワークフローを自動化することで、Enzaiは企業がISO 42001やNISTなどのグローバルスタンダードとの整合性を保ちながら、確信を持ってAIの導入規模を拡大できるよう支援します。

参考文献

[1] Gartner, "Agentic AI: The Next Frontier of Enterprise AI," October 2024. Gartner社は、エージェンティックAI機能が2028年までに企業向けソフトウェアアプリケーションの33%に搭載されると予測しています。

[2] 欧州議会および理事会規則 (EU) 2024/1689、第3条第1項。欧州連合官報、Lシリーズ、2024年7月12日。

[3] 欧州委員会が発表したAIシステム定義に関する解釈ガイダンス（2025年発行）は追加のコンテキストを提供していますが、エージェントシステムにおける創発的なサブゴール分解について、具体的には言及していません。

[4] 規則 (EU) 2024/1689、第113条〜第114条（発効日および適用日）。

[5] 規則 (EU) 2024/1689、第III章、第2節、第9条〜第15条。

[6] これらの運用のひずみに関する詳細な分析については、Enzai, "The EU AI Act Bends. It Need Not Break," March 2026 を参照してください。

[7] 規則 (EU) 2024/1689、第V章、第51条〜第56条（GPAIモデルのプロバイダーに対する義務）。

[8] ISO/IEC 42001:2023、Information technology — Artificial intelligence — Management system。国際標準化機構、2023年12月。

[9] NIST、Artificial Intelligence Risk Management Framework (AI RMF 1.0)、NIST AI 100-1、2023年1月。

[10] NIST、Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile、NIST AI 600-1、2024年7月。

[11] OECD, "OECD Framework for the Classification of AI Systems," OECD Digital Economy Papers No. 323, February 2022。OECD AI原則は2024年5月に更新されました。

[12] コロラド州 SB 24-205、Concerning Consumer Protections for Artificial Intelligence、2024年5月署名。当初の施行日は2026年2月1日。係属中の法改正案を条件とします。

[13] 連邦準備制度理事会、SR Letter 11-7, "Supervisory Guidance on Model Risk Management," 2011年4月。通貨監督庁、OCC 2011-12。

[14] 規則 (EU) 2024/1689、第12条（高リスクAIシステムの記録保持 / 自動ロギング）。

[15] 規則 (EU) 2024/1689、第16条（プロバイダーの義務）および第26条（デプロイヤーの義務）。

[16] 規則 (EU) 2024/1689、第25条（AIバリューチェーンに沿った他の当事者の義務）。

[17] CENおよびCENELECに対する欧州委員会の標準化要求 M/593（2025年6月修正）。CEN-CENELEC JTC 21作業計画。

[18] 規則 (EU) 2024/1689、第7条（附属書IIIの修正）。

[19] 規則 (EU) 2024/1689、第56条（GPAIモデルの実施規範）。

[20] IAPP AI Governance Center、OECD AI Policy Observatory (oecd.ai)、ISO/IEC JTC 1/SC 42作業計画。