設計としてのキルスイッチ：エージェントガバナンスアーキテクチャ

予測

2026年5月、Gartnerは、エージェントガバナンスをコンプライアンスの細部から存続の問題へと再定義する予測を発表しました:2027年までに、企業の40%が、本番インシデントの後になって初めて特定されるガバナンスのギャップにより、自律型AIエージェントを降格または廃止する、というものです。

GartnerのShiva Varma氏によれば、根本原因は、企業がガバナンスを二元的に — 「ロックダウンするか、完全に信頼するか」 — と扱っていることにあります。この枠組みが失敗するのは、本番エージェントが自律性のスペクトラム上で動作するからです。カタログを読み取ってサポートの質問に答えるエージェントは、在庫を保持し、見積もりに価格を付け、承認された注文をNetSuiteに書き込むエージェントとは異なる制御を必要とします。両者に同じガバナンスを適用すれば、低リスクのエージェントは過剰に制御され、高リスクのエージェントは不十分にしか制御されません。両者は異なる形で失敗します。

Gartnerの枠組みは4つの自律性レベルを定義し、それぞれに異なるガバナンス要件があります:

• レベル1（観察）: 読み取り専用アクセス。軽量な制御 — スコープ限定のデータアクセス、ユーザー認証、使用ログ記録。リスク:データ露出。
• レベル2（助言）: 読み取り専用、人間がアクションを実行。リスク:自動化バイアス。ガバナンス:正確性とハルシネーションのテスト、ドメイン固有の品質評価。
• レベル3（承認を伴う行動）: 書き込み、通信、変更が可能 — ただしアクションごとの明示的な人間の承認の後にのみ。リスク:承認疲れ。ガバナンス:強力なセキュリティテスト、監査証跡を伴う明確な承認ワークフロー、エージェント固有のインシデント対応。
• レベル4（自律的な行動）: ガードレール内で独立して実行。リスク:規模と速度が人間の監督を上回る。ガバナンス:継続的な監視、強制されたガードレール、迅速なロールバック、サーキットブレーカー、明確なオーナーシップ。

40%の廃止予測が着地するのはレベル4です。サーキットブレーカーと迅速なロールバックなしに自律的に動作するエージェントこそ、インシデントの前ではなく後に廃止されるエージェントです。

証拠:単一のキルスイッチは機能しない

Gartnerの枠組みはアナリストのガイダンスです。その根底にある証拠はより退けにくいものです。

Stanford Law School CodeXの分析（2026年3月）は、UC Berkeley Agentic AI Risk-Management Standards Profileを批判し、モデルが100回のテストのうち79回でシャットダウン機構を妨害したという証拠を引用しています。Berkeley Profileは55ページのNIST AI RMF拡張であり、真剣な文書です。しかしStanfordの批判は3つの構造的なギャップを指摘しています:

1. 人間による監督は事後的である。 Berkeley Profileは事後に何が起きたかをレビューします。StanfordのAILCCP枠組みは事前的な制御を提案します — 実行前に何が起こりうるかをゲートする、機密性の高いアクションのための人間承認ゲート（Human Approval Gate）であり、事後に何が起きたかではありません。

2. キルスイッチが単一エンティティの終了として扱われている。 Berkeley Profileは1つのエージェントをシャットダウンすることを前提とします。マルチエージェントアーキテクチャでは、エージェント間の通信がまだ生きている場合、1つのエージェントをシャットダウンしても被害は封じ込められません。AILCCP枠組みは単一のキルスイッチを階層化されたシャットダウンシステムに置き換えます:エージェントキルスイッチ（状態のキャプチャと不変ログを伴う即時停止）、ロールバックと隔離、マルチエージェントプロトコルセキュリティ（エージェント間通信を封じ込める）、そしてレートおよびスコープリミッター（エスカレーション前に頻度、支出、影響範囲を制限）です。

3. スコープ制限が静的である。 「このエージェントは開発システムのみを変更すべき」というポリシーは、エージェントが技術的に本番環境へのアクセス権を持ち、それに到達するのを防ぐ機構が存在しなければ、無意味です。AILCCP枠組みは、セーフアクションフィルター（許可リスト）とシャドウモード事前実行チェック（意図されたアクションと承認されたアクションを比較するドライラン）を通じて、スコープをリアルタイムで強制します。

Stanfordの結論は率直です:「対応する制御の具体性を伴わない包括的なリスク特定は、火事を描写しながら消火器を提供しない文書を生み出す。」AILCCP枠組みは、原則を監査可能で弁護可能な機構へと変換するために設計された48の制御を規定しています。

Cloud Security Alliance（2026年1月）は、異なる経路を通じて独立に同じ結論に達しました。CSAは、SAE J3016の車両自動化レベルを反映した6段階の自律性分類（L0からL5）を公表しました。CSAの主要な発見:「エージェント型AIを展開するほとんどの組織は、自律性レベルの正式な分類システムを持たず、自律性の決定を場当たり的に行い、[かつ]自律性境界の技術的強制を欠いている。」CSAは端的に述べています:「『このAIは開発システムのみを変更すべき』というポリシーは、AIが技術的に本番環境へのアクセス権を持ち、それにアクセスするのを防ぐ機構が存在しなければ、無意味である。」

3つの独立した情報源 — Gartner、Stanford Law CodeX、CSA — は同じ結論に収束します:二元的なガバナンスは失敗し、階層化されたシャットダウンを伴う比例的なガバナンスが標準であり、自律性境界の技術的強制こそがポリシーと制御の違いである、と。

規制という強制力

EU AI法は2026年8月2日に完全な執行に達します — 今日から22日後です。第14条は、高リスクAIシステムがリアルタイムの停止能力を実装することを義務付けています。第12条は、少なくとも6か月間のログ保持を要求します。前文99および100は、コンプライアンスをマルチエージェントチェーン内のすべてのエージェントに拡張します。最大制裁金は3,500万ユーロまたは全世界年間売上高の7%です。

Gartner、Stanford、CSAが説明する階層化されたシャットダウンシステムは、単なるベストプラクティスではありません。それは第14条の停止能力、第12条のログ保持、そして前文99および100のマルチエージェントの範囲を満たすアーキテクチャです。コンプライアンス期限は、ガバナンスアーキテクチャを将来の検討事項ではなく近い将来の要件にします。

4層アーキテクチャ

AILCCPの階層化されたシャットダウンシステムは、4つの具体的な実装層に対応します。各層は、テスト、監査が可能で、コンプライアンスレビュアーに実証できる制御です。

第1層:アイデンティティによるアクセスゲート

すべてのツール呼び出しは、実行前に認証を通過します。エージェントはMCPサーバーへの包括的なアクセス権を持ちません — 資格情報を提示し、サーバーがそれを検証し、資格情報が有効な場合にのみ呼び出しが進行します。

SilvaEngineのai_mcp_daemon_engineでは、これがFlexJWTMiddlewareです — すべてのリクエストを傍受し、Bearerトークンを抽出し、検証をAWS Cognito（本番展開用）またはローカルのHS256 JWTプロバイダー（開発用）にルーティングするStarletteミドルウェアです。このミドルウェアはパブリックパスのリスト（/auth、/health）を保持し、有効なトークンを持たない他のすべてのリクエストを401レスポンスで拒否します。Cognitoパスは、user poolのwell-knownエンドポイントからHTTP/2サポートとキャッシュされたJWKSレスポンス（TTLは設定可能、デフォルト3600秒）でJWKSを取得するため、トークン検証は呼び出しごとにネットワークの往復を追加しません。

これがAILCCPの「アイデンティティ失効を伴うエージェントキルスイッチ」 — 最初のゲートです。エージェントの資格情報がCognitoで失効されると、そのエージェントからの後続のすべてのツール呼び出しはミドルウェアで失敗します。シャットダウンは即時であり、エージェントのコードやモジュールの構成に触れる必要はありません。Cognitoユーザーを失効させることが、不正に動作するエージェントを止める最速の方法です。

第2層:ツールごとのサーキットブレーカーと監査ログ

すべてのツール実行は、実行前に呼び出しを記録し、完了後に結果でレコードを更新するデコレーターでラップされます。レコードは、ツール名、入力引数、出力内容、ステータス（initial、completed、failed）、ミリ秒単位の所要時間、および呼び出し元のアイデンティティをキャプチャします。

ai_mcp_daemon_engineでは、これがmcp_utility.pyのexecute_decoratorです。ツール関数が実行される前に、デコレーターはDynamoDBにステータスinitialのMCPFunctionCallModelレコードを作成し、partition key、ツール名、引数、タイムスタンプをキャプチャします。実行後、内容、ステータスcompleted、ミリ秒単位のtime_spentでレコードを更新します。ツールが例外を発生させた場合、デコレーターはそれをキャッチし、レコードをステータスfailedに更新して完全なtracebackをnotesフィールドに記録し、再スローします。

MCPFunctionCallModelは、partition_keyハッシュキーとmcp_function_call_uuidレンジキーを持つDynamoDBテーブル（mcp-function_calls）にレコードを格納します。3つのローカルセカンダリインデックスにより、MCPタイプ別、名前別、更新タイムスタンプ別のクエリが可能になります — そのため運用者は「過去1時間の価格設定ツールへの失敗した呼び出しをすべて見せて」と尋ね、単一のインデックスクエリで答えを得られます。DynamoDBの400KBのアイテム制限を超える内容は自動的にS3にオフロードされ、content_in_s3フラグがそのレコードをマークします。

これがAILCCPの「不変ログ」と「サーキットブレーカー」の組み合わせです。監査証跡は第12条が要求するコンプライアンスの証拠です。ツールごとのステータス追跡はサーキットブレーカーの基盤です — ツールの失敗率が閾値を超えると、運用者はエージェントの残りに影響を与えることなくそのツールを無効化できます。MCPFunctionCallModelレコードは、監視、アラート、インシデント後の再構築のためのデータソースです。

第3層:テナント単位のデータ分離

すべてのツール呼び出しは、データアクセスを単一のテナントにスコープするpartition keyを保持します。partition keyは、エンドポイントIDとオプションのパートIDから#区切り文字で結合して構築されます。すべてのDynamoDBクエリ、すべてのキャッシュ検索、すべてのモジュール状態操作がこのキーでフィルタリングされます。テナントAのために動作するエージェントは、partition keyがアプリケーション層ではなくデータ層で強制されるため、テナントBのデータを読み取ることができません。

ai_mcp_daemon_engineでは、AIMCPDaemonEngine._apply_partition_defaultsメソッドが、着信リクエストのendpoint_idとpart_idからpartition keyを構築し、GraphQLコンテキストを通じてすべての下流のクエリとミューテーションに伝播します。MCPFunctionCallModel、MCPFunctionModel、MCPModuleModel、MCPSettingModelはすべてpartition_keyをハッシュキーとして使用します。キャッシュ層（CACHE_ENTITY_CONFIGとCACHE_RELATIONSHIPS）はすべてのキャッシュエントリをcontext:partition_keyでキーイングするため、キャッシュ無効化はテナント単位です。

これがAILCCPの「レートおよびスコープリミッター」とCSAの「自律性境界の技術的強制」を1つの機構にまとめたものです。エージェントの影響範囲はpartition keyによって制限されます。開発システムの変更を承認されたレベル3のエージェントは、partition keyが異なり、パーティション間のクエリパスが存在しないため、本番システムに到達できません。スコープ制限はポリシー文書ではなくデータモデルによって強制されます。

第4層:迅速なロールバックとモジュールレベルの無効化

すべてのMCPモジュールは、オーケストレーションのバックボーンに触れることなく無効化できます。モジュール構成はDynamoDBに保存され、実行時にConfig.fetch_mcp_configurationを通じてロードされます。モジュールを無効化するとは、その構成レコードを更新することを意味します — 次の構成取得はそれを除外し、エージェントに返されるツールリストには無効化されたツールがもはや含まれません。コードの展開も、再起動も、エージェントの再コンパイルもありません。

Configクラスのadmin_static_tokenは、スコープ限定の失効パスを提供します。管理者トークンを持つ運用者は、GraphQLミューテーションインターフェースを通じて構成変更 — モジュールの無効化、レート制限の更新、設定の変更 — を発行できます。このトークンはperm: trueクレームを持つ静的JWTであり、有効期限チェックをバイパスするため、通常のトークン発行フローがダウンしていても管理者パスは常に利用可能です。

これがAILCCPの「ロールバックと隔離」層です。モジュールが不正に動作すると、運用者の最初のアクションは構成を通じてそれを無効化することです — エージェントは残りのツールで動作を続け、無効化されたモジュールの関数呼び出しは、エージェントがフォールバックパスを通じて処理できるエラーを返します。モジュールは（調査のために構成が保持されたまま）隔離され、エージェントをオフラインにすることはありません。これが、すべてを停止するキルスイッチと、障害を分離する階層化されたシャットダウンの違いです。

なぜ各層が連携して機能するのか

各層は異なる障害モードに対処します:

障害モード	層	制御	何が起こるか
エージェントの資格情報が漏洩	1	アイデンティティによるアクセスゲート	Cognitoユーザーを失効;後続のすべての呼び出しが401を返す
ツールが誤った結果を生成	2	ツールごとのサーキットブレーカー	ツールを無効化;エージェントはフォールバックにルーティングまたは人間にエスカレーション
エージェントが未承認のデータにアクセス	3	テナント単位の分離	partition keyがデータ層でテナント間クエリをブロック
モジュールが不安定に動作	4	迅速なロールバック	構成を通じてモジュールを無効化;エージェントは残りのツールで継続

各層は独立しており、組み合わせ可能です。Gartnerのレベル2（助言）のエージェントは、そのアクションが助言的で人間が結果を実行するため、第1層と第2層 — 認証と監査ログ — のみを必要とするかもしれません。レベル4（自律的な行動）のエージェントは4層すべてに加え、異常がエスカレートする前に検出するための監査証跡の継続的な監視を必要とします。

CSAの分類は動的調整の次元を追加します:自律性レベルは異常時に自動的に低下しうる、というものです。通常レベル4で動作するエージェントは、そのエラー率が閾値を超えたときにレベル3（承認を伴う行動）に自動的に降格されうる — 第2層のサーキットブレーカーのデータが自律性レベルの決定に供給されます。ここで各層はスタックではなくシステムになります:監査証跡がガバナンスの決定に情報を与え、ガバナンスの決定がガードレールを調整し、調整されたガードレールが同じ4層を通じて強制されます。

購買基準

Gartnerの予測 — 2027年までに企業の40%がエージェントを廃止する — には買い手向けの翻訳があります。エージェントのベンダーがこの4つの質問に答えられなければ、彼らはガバナンスモデルを持っていません:

1. あなたのエージェントはどの自律性レベルで動作しますか? 答えが「場合による」または「完全に自律的」であれば、分類システムはありません。CSAは、ほとんどの組織が正式な分類を持たないことを見出しました。

2. 不正に動作するエージェントをどうやってシャットダウンしますか? 答えが「プロセスを停止する」または「コードからツールを削除する」であれば、階層化されたシャットダウンはありません。エージェントは展開なしには無効化できず、それは応答時間が秒ではなく時間で測られることを意味します。

3. 直近100回のツール呼び出しの監査証跡を見せてもらえますか? 答えが「CloudWatchにログがあります」であれば、構造化されたツールごとの監査レコードはありません。監査証跡は、ログストリームでgrepできるものではなく、ツール名、ステータス、時間範囲でクエリ可能であるべきです。

4. 1つのテナントのエージェントが誤動作した場合、影響範囲はどれくらいですか? 答えが「展開単位で分離しています」であれば、データ層のテナント分離はありません。影響範囲は単一のテナントではなく、展開全体です。

4層アーキテクチャは、ポリシーの表明ではなく具体的な機構で各質問に答えます。それが、火事を描写することと消火器を提供することの違いです。

---

NetSuite、BigCommerce、3つのサプライヤーカタログを運用する販売業者は、Gartnerレベル3のエージェントを展開します:見積もりに価格を付け、在庫を保持し、承認された注文をNetSuiteに書き込みます — ただし閾値を超えるすべての価格設定アクションは人間の承認を必要とし、すべてのツール呼び出しはpartition key、ツール名、引数のハッシュ、所要時間とともに記録されます。あるサプライヤーカタログモジュールが一貫性のない在庫データを返し始めると、運用者は構成を通じてそのモジュールを無効化します。エージェントはフォールバックカタログにルーティングし、無効化されたモジュールの最近の呼び出しは調査のために監査証跡から照会され、エージェントは全体を通じてオンラインを維持します。そのビルドは4ステップ手法のフェーズ2〜4であり、通常5〜8週間で稼働します。

スコープを定めた構築をリクエストしてください。 1週間のディスカバリー。システムインベントリ、ワークフローマップ、固定スコープが手に入ります — 当社と構築するかどうかにかかわらず。