システム構成 · 目次
中文EN日本語
SCHEMATIC ID: DS-ARCH-COMPOSITION-V1  ·  AGENT GOVERNANCE CONTROL PLANE

システム構成 —— エージェント・ガバナンス・コントロールプレーン

独立配備可能な 8 つのシステム + グローバルに一意な 3 つの契約

種別 リファレンスアーキテクチャ 構成 8 SYSTEMS + 3 CONTRACTS 受け入れレベル L0 – L3 アクション種別 7
How to read · 本書の読み方 本書は機能ではなくシステム単位で構成されている。各システムについて示すのは 4 点：何を排他的に担うか（他のシステムでは代替できないこと）、内部がどのモジュールで構成されるか、どこに配備するか、そして分割すると何が壊れるか。§4 まで読めば全体像が描ける。§5 は各システムの詳細図である。
Section 00 — Thesis

一言で

エージェント・ガバナンス・コントロールプレーンは、独立配備可能な 8 つのシステムとグローバルに一意な 3 つの契約で構成される。既存のエージェント・モデル・業務システムを置き換えるものではなく、エージェントと「モデル / ツール / データ / 下流システム」の間に立ち、見える・止められる・防げる・説明できる・正しく動くという一本の統制経路を通す。

Core Abstraction ガバナンスの対象は「主体としてのエージェント」ではない。
「エージェントの 1 回の実行」である。

エージェントを認可すべき主体（ユーザーやサービスアカウントと同様）として扱うのは、従来の IAM の発想をそのまま持ち込んだものである。主体が答えるのは「誰が」だけだ。しかしカスケード障害とメモリ汚染は、単一の呼び出しの中には存在しない。実行が展開していく過程の中にしか存在しない。

正しい第一級オブジェクトは実行トラジェクトリ（Trajectory）——1 回のエージェント実行が起動から終了までに描く完全な因果構造である。本アーキテクチャの各システムは、すべてこれを軸に役割分担する：ポリシーはその上で裁定し、監査はそこから導出され、評価はそれを採点し、異常はその上で検出される。

Blueprint ID: GOV-COMP-THESIS-V1Sheet 01 / 12
Section 01 — Target Audience

対象読者

業務エージェントをすでに運用中、または構築中で、見る / 止める / 証明する / 検証するのループを閉じる必要がある組織。とくに次の 3 つの状況である：

状況典型的な領域
従業員はすでに Claude Code / Cursor / デスクトップ AI を使っているが、会社は台数も接続先の MCP サーバーも把握していない開発規模の大きいテック企業、フィンテック
自社エージェント基盤は業務として動くが、事故時に責任の所在を説明できず、規制当局の照会に答えられない金融、官公庁・公共、規制業種
エージェントが本番の書き込み操作（返金・発注・リリース・設定変更）に触れ始め、リスクが不可逆になるトレーディング、決済、運用、サプライチェーン
Blueprint ID: GOV-COMP-AUDIENCE-V1Sheet 02 / 12
Section 02 — Positioning

位置づけ

観点内容
何であるか業務エージェントを護衛するガバナンスプレーン——それ自体は業務エージェントではない
解く中心課題主体が短命・挙動が非決定的・権限が動的・責任が多段というシステムにおいて、いかに帰属可能・制約可能・証明可能を保つか
エージェント基盤との関係疎結合。自社構築エージェント、OSS フレームワーク、サードパーティ製エージェント（Claude Code / Cursor / Copilot など）、マネージドランタイムのいずれにも対応
導入形態受け入れレベル L0–L3 の段階導入。「プローブを入れれば発見される」から「署名イベント + クロス照合により証明可能」まで、導入コストと保証強度が対価関係にある
やらないことエージェントランタイムの移行を求めない。下流業務の認可コード改修を求めない。単一の監査バックエンドや単一クラウドに縛らない
Blueprint ID: GOV-COMP-POSITION-V1Sheet 03 / 12
Section 03 — Problems Solved

解くべき 7 つの課題

課題現れ方どのシステムが答えるか
見えないノート PC 上の Claude Code、ローカル stdio MCP、同一 Pod 内の A2A——いずれも外部に出ないため、ゲートウェイからは見えないプローブ（ファクト経路）+ レジストリ（シャドー検出・目録化・AI-BOM）
各ステップは適法、組み合わせが事故1 ステップずつ見ればすべて権限内。つなげるとカスケード障害・無限ループ・目標ドリフトになるポリシー：裁定の入力は「トラジェクトリ + 現ステップ」であり、単一呼び出しではない
事故後に責任を説明できない人 → オーケストレーター → サブエージェント → ツール → リソース。事後にログから復元すると必ず曖昧さが残るアイデンティティ（委任チェーンがクレデンシャルと共に伝播、傍系ログではない）+ 監査（因果 DAG の組み立て）
エージェントの自己申告は証拠にならないプロンプトインジェクションやサプライチェーン汚染を受ければ、SDK の計装自体が書き換えられうるプローブの 3 経路収集 + 監査のクロス照合 + daemon 署名（秘密鍵はエージェントから読めない）
長期クレデンシャルの散在API キーや AK/SK がコード・環境変数・プロンプトに書かれ、ローテーションは人手頼みアイデンティティの金庫管理 + ゲートウェイ側での注入。エージェントプロセスは平文に触れない
高リスク操作をプロンプト頼みで抑える返金・送金・リソース削除・リリースを、プロンプトの書き方とガードレールで抑えており、なお迂回されうるポリシーの承認ゲート + ポータルの承認ワークベンチ（承認者が署名するのは不変の action digest）
正しく動いているか誰も見ていないリリース判定は人手の抜き取り確認。モデル更改後の品質劣化に気づけない評価：品質スコアをリリースゲート化 + 複数ターンのレッドチーミング + 評価器の隔離
Blueprint ID: GOV-COMP-CHALLENGE-V1Sheet 04 / 12
Section 04 — System Composition

全体構成：8 システム + 3 契約

分割の根拠は信頼境界と配備境界であり、組織図ではない。各システムは固有の名前・画面・提供境界を持ち、必要なときは単独で取り出せる。不要なときはプラットフォームの背後に隠れている。

4.1　8 つのシステム

#システム排他的責務（他では代替できない）配備形態
S1Agent ポータル
Agent Portal		委任チェーンの起点を生成する——実在の人間 ID があるのはここだけ集中配備、組織に 1 式
S2Agent レジストリ
Agent Registry		「何が存在し、それぞれ何ができるか」の唯一の真実源であり、かつポリシーのホットパス・データソース集中 + 各 PEP 側ローカルキャッシュ（変更配信 ≤ 30 秒）
S3Agent アイデンティティ
Agent Identity		検証可能な ID と委任チェーンを発行し、ホップごとの単調縮小を保証する集中発行 + ノード側 Workload API（UDS / vsock）
S4Agent ゲートウェイ
Agent Gateway		唯一の迂回不可能な実施点——下流はゲートウェイ発の呼び出ししか受け付けない集中またはゾーン単位、強制ルーティング
S5Agent ポリシー
Agent Policy		裁定し、decision_reason（なぜ許可・拒否したか）を出力する集中 PDP + エッジ側の高速判定キャッシュ
S6Agent プローブ
Agent Probe		エージェントの協力に依存しないファクト観測とイベント署名を提供するエージェントと共に分散：インプロセス SDK + ホスト daemon + カーネル
S7Agent 監査
Agent Audit		トラジェクトリを組み立て、クロス照合し、独立検証可能な証拠を産出する集中、WORM + ハッシュチェーン保管
S8Agent 評価
Agent Eval		「正しく動いているか」をリリースゲートに変換する集中、かつ被評価エージェントから完全に隔離

4.2　3 つの契約

Non-negotiable 契約は分割しない。8 つのシステムが組み合わさるための唯一の前提である。
契約内容生成者消費者
監査イベント
AuditEvent		 ID と認可 / 因果 / アクション / 判定 / 経路と出所の 5 フィールド群。decision_reason と collector+confidence は必須 S1 S4 S5 S6S7 S8
ケイパビリティ宣言
CapabilityDeclaration		 ツール（メソッド・引数レベルまで）· 読み取る外部書き込み可能コンテンツ源（間接インジェクション面）· 書き込みリソース · サブエージェント · メモリスコープ · 承認要アクション · モデルと越境境界 登録時に提出 S2 受け入れ / S5 既定ポリシー生成 / S7 照合 / S8 評価
委任チェーン
DelegationChain		 RFC 8693 Token Exchange、認可サーバーを仲介とする。user_identity / agent_identity / delegation_chain / scope / audience / resource / expiry / trace_id、加えて jti · nonce · confirmation key · チェーン長制限 · 失効 S1 が起点、S3 が発行 S3 S4 S5 が全経路で検証
Contract Discipline · 契約の規律 この 3 つのスキーマはグローバルに一意であり、各システムが独自版を定義してはならない。システムは段階的に導入してよいし、一部だけ採用してもよい。しかし契約がいったん分岐すれば、トラジェクトリは組み立てられず、委任チェーンは検証できず、証拠は突き合わせられない。どう分割してもここだけは触れてはならないという唯一の一線である。

4.3　システムトポロジー

BLUEPRINT ID: GOV-COMP-TOPOLOGY-V1 COLLECTION EXECUTION PATH DECISION & TRUTH 業務ユーザー S1 Agent ポータル SSO · CATALOG · APPROVALS · INBOUND PEP 委任の起点 ONLY REAL HUMAN IDENTITY 委任チェーン 業務エージェント GOVERNED · UNTRUSTED SUBJECT S3 Agent アイデンティティ SPIFFE · DELEGATION · VAULT SIGNING · REVOCATION ID · 資格情報 インプロセス + カーネル 全ての外部呼び出し S6 Agent プローブ SDK · RUST DAEMON eBPF / ETW / ES · SIGNING S4 Agent ゲートウェイ EGRESS PEP · MCP / A2A BROKER GUARDRAILS · RATE LIMIT · CRED INJECTION NON-BYPASSABLE S5 Agent ポリシー PDP · TRAJECTORY FEATURES dry_run · KILL-SWITCH OUTSIDE THE LOOP 裁定 S2 Agent レジストリ DECLARATION · ADMISSION LEVEL AI-BOM · HOT-PATH CACHE 照会 イベント（セマンティック / ファクト / バウンダリ） S7 Agent 監査 TRAJECTORY ASSEMBLY (CAUSAL DAG) · CROSS-CORROBORATION · WORM + HASH CHAIN AUDIT PROJECTION ≠ OBSERVABILITY PROJECTION S8 Agent 評価 SCORING · RELEASE GATE · RED TEAM ISOLATED EVALUATOR トラジェクトリ 候補ポリシー（人の承認が必須）
実行経路 / イベント（トラジェクトリ） コントロールプレーン（ID · 裁定 · 照会） 非信頼主体 / 人の操作

FIG. 4.3 — SYSTEM TOPOLOGY · 8 SYSTEMS

Blueprint ID: GOV-COMP-TOPOLOGY-V1Sheet 05 / 12
Section 05 — System Breakdown

システム詳細

S1Agent ポータルAgent Portal

従業員と業務部門がエージェントを利用するための統一入口であり、承認デスクでもある。

内部モジュール責務
ID 連携SSO フェデレーション：OIDC / SAML / SCIM で既存 IdP と接続。マネージド UserPool も提供
アプリカタログ権限で絞り込まれたエージェント一覧——ユーザーは「見てよい」エージェントしか見えない
セッションと意図元の意図を記録し、トラジェクトリの根とする。セッションを証跡として残す
承認ワークベンチHuman-in-the-Loop の対話と記録。承認者が署名するのは不変の action digest であり、実行時に一致を検証する。これが「A を承認して B を実行」を防ぐ
受信 PEP受け入れレベル・委任チェーン・ケイパビリティ宣言を検証してから通す
Exclusive Responsibility 委任チェーンの起点はここでしか生成できない。ポータルを通っていない呼び出しは human_initiator が空になる——それ自体が 1 つのポリシー判定材料であり、データ欠損ではない。

単独価値：ガバナンスを行わない場合でも、「社内 AI アプリを従業員にどう提供するか」への答えになる——シングルサインオン、アプリカタログ、承認ワークベンチ、セッション証跡。

S2Agent レジストリAgent Registry

組織内にどのエージェント・ツール・MCP サーバー・モデルが存在し、それぞれ何ができるか。

内部モジュール責務
オブジェクト登録AgentBlueprint · Tool · MCP server · Model · Skill · サブエージェント・エンドポイント
2 層モデルBlueprint（テンプレート）/ Instance（実体）：ガバナンスはテンプレートに作用し、実行は実体で起きる。ポリシーはテンプレートに付与され実体が自動継承するため、1 操作で 1 クラス全体を停止できる
宣言の検証登録時に宣言の自己整合性を検査（参照ツールの存在、引数制約の構文）+ 間接インジェクション面の分析（どの外部書き込み可能コンテンツ源を読むか）
受け入れレベルadmission_level L0–L3 を保持し、ポリシー入力として使用。「L2 未満は X クラスのリソースに触れない」が記述可能なポリシーになる
部品表AI-BOM（CycloneDX ML-BOM 拡張）を出力し、脆弱性の影響範囲分析に供する
状態機械draft → active → quarantined → retired。quarantine は証拠を保全したまま能力を遮断する——削除とは異なる
可視ツールの絞り込み権限によるツール集合の絞り込み + セマンティック検索——エージェントは「見てよい」ツールしか見えない。全部見せてから止めるのではない
中立メタモデルサードパーティ製エージェント（Copilot / Agentforce / Claude Code など）の属性を正規化して取り込む
ホットパス提供管理面の照会と分離し、ローカルキャッシュ + 変更配信（≤ 30 秒）で提供
死活状態ハートビートによるオンライン / オフライン検知、オフライン時に警報。状態はポリシー入力になる
Exclusive Responsibility これは第一にポリシーのデータソース（実行時ホットパス、強整合・低遅延）であり、発見カタログや再利用資産一覧はその次である。順序を取り違えると「検索の遅い資産台帳」になる。

インターフェース：Register / Update / Deprecate / Query(hot-path) / ExportBOM。レジストリ自身を MCP サーバーとして公開する——人もエージェントも同じ発見経路を通る。

S3Agent アイデンティティAgent Identity

エージェントに検証可能な ID を発行し、委任チェーンとクレデンシャルを管理し、長期資格情報をエージェントのコードから遠ざける。

内部モジュール責務
ID 発行SPIFFE SVID の 2 段構え：blueprint と instance にそれぞれ SPIFFE ID。K8s → UDS マウント、素のプロセス → ローカル UDS、microVM → vsock 経由で Workload API を橋渡し
チェーンの発行と検証組織内は JWT-SVID、アプリ間は token exchange（ID-JAG 形式）。単調縮小（scope[i+1] ⊆ scope[i]）を発行時に検査し、検証時に再確認
保持者バインドDPoP 方式で保持者の鍵に束縛。トークンが漏れても横展開に使えない
環境の同一性検証発行時にコード / イメージ / 実行環境が登録情報と一致することを検証し、ID の複製・なりすましを防ぐ
クレデンシャル金庫OAuth 2.0（2LO / 3LO）· API キー / AK-SK · STS 短期チケットを一元管理。長期クレデンシャルは金庫から出さず、ゲートウェイ側で注入。エージェントプロセスは平文を見ない
失効と有効期限権限は期限付き「アクセスパッケージ」として付与し、期限到来で自動回収。ユーザーが同意を撤回すれば、対応するアクセス能力も同時に失効する
署名サービス秘密鍵は KMS / TPM に留め、署名のたびに監査記録が残る。プローブ daemon の署名鍵はここから派生し、エージェントプロセスからは読めない
リスクスコア2 系統：関連する人間 ID のリスクからの派生と、エージェント自身の行動異常。高リスクはレジストリ上の発見可能性に影響する。単なるリクエスト拒否ではない
Exclusive Responsibility ID の発行と委任チェーンの検証は同一システム内になければならない。分けると単調縮小を誰も保証せず、チェーンの偽造や権限拡大が可能になる。

目標状態：静的 API キーの撲滅。既存分は金庫管理 + 自動ローテーションで移行する。

S4Agent ゲートウェイAgent Gateway

エージェントによる外部への呼び出しがすべて通る強制チャネル。

内部モジュール責務
送信モデルゲートウェイルーティング、コスト按分、レート制限、コンテンツガードレール
MCP / A2A ブローカーMCP と A2A は独立した 2 本の統制チャネルとし、同一ポリシー面を共有しない
受信ゲートウェイエージェントが呼ばれる前の受け入れ：レベル・委任チェーン・ケイパビリティ宣言を検証
ペイロード解析ポリシー粒度を tool + method + 引数 まで下げるため、MCP メッセージ本体を解析する
クレデンシャル注入プロキシ当該アクションの判定に基づき S3 から短期クレデンシャルを取得し、下流呼び出しを代理実行。エージェントは終始平文に触れない
コンテンツガードレールprompt / response / agent action / MCP interaction の 4 種すべてを対象。PII はモデル到達前にマスクし、送信時に再検査
レート制限とブレーカー次元（JWT claim / 主体 / target / tool / model）× 尺度（RPS · TPM · 接続数）× 最も具体的な指定が優先 × rate=0 による緊急遮断 × 2 段上限は縮小方向のみ
バウンダリ経路イベント呼び出し先・メソッド名・ペイロード規模・データ流出先を出力する——高信頼度の 1 経路
Exclusive Responsibility これが唯一の迂回不可能な実施点である。実装上の要点は「下流はゲートウェイ発の呼び出しのみを受け付ける」（送信元 ID 検証 / workload 許可リスト）こと。それ以外は拒否する。
Engineering Note · A2A Signed Agent Card が保証するのは Card の完全性と主張の出所のみであり、現在の接続がどの instance に対応するかは証明しない。transport identity、メッセージ認可、nonce、audience、リプレイ防止を別途構成する必要がある。これを ID 証明として扱うと、実在する穴が残る。

単独価値：モデルトラフィックのコスト按分・ルーティング・ガードレール・レート制限。送信側だけでも単独提供が成立する。

S5Agent ポリシーAgent Policy

各実施点が問い合わせる、統一された裁定の頭脳（PDP）。

内部モジュール責務
PDP推論ループの外側にある——プロンプトで説得できる制約は制約ではない
裁定の入力(ここまでのトラジェクトリ, 現ステップ, ケイパビリティ宣言, エージェント ID, 委任チェーン, ユーザー自身の権限)
三重検証下流は「エージェントに権限がある + ユーザー自身にも権限がある + ユーザーが明示的に委任した」を同時に満たす必要がある——Confused Deputy 型の権限逸脱を塞ぐ
トラジェクトリ特徴サービスPDP 内で集約しないよう、特徴量を事前計算して供給：cumulative_impact · no_progress_rounds · distinct_resources_touched · data_egress_bytes
2 モード実行dry_run（記録のみ、遮断しない）と enforce。出荷時の既定は dry_run であり、遮断させるには明示的に enforce へ切り替える必要がある
承認ゲート判断基準は「人の判断が結果を実質的に変えるか」であり、単純なリスク等級の線引きではない
トラジェクトリ級の検知ループ検知（同一呼び出し回数 / 無進捗ラウンド / 予算ブレーカー）· 系列としての意図異常
キルスイッチ3 段階：単一 instance / blueprint 全体 / 全体。目標発効 ≤ 5 秒、実装は「クレデンシャル失効 + rate=0 + PEP 拒否」の組み合わせ
逆方向の検証「拒否されるべき」既知サンプルを定期的にリプレイし、ポリシーが実際に止めることを確認する
判定の証跡decision_reason を出力する——「止めた」だけで「なぜ」がないと、事故検証で最も重要な問いに答えられない
Exclusive Responsibility PDP の裁定と decision_reason の出力は分離できない。
Design Requirement · ポリシー言語は 2 層構成でなければならない 単一のポリシー言語ではこの問題は解けない。第 1 層には permits-more-than を静的に判定できることが要る——これは委任チェーンの単調縮小（scope[i+1] ⊆ scope[i]）を証明するための前提である。チューリング完全なポリシー言語（Rego など）は一般にこの性質を判定できず、Cedar のような決定可能な言語が必要になる。第 2 層は事前計算されたトラジェクトリ特徴量である。決定可能な言語はトラジェクトリ級の集約を表現できないため、特徴サービスが PDP の外で計算して渡す必要がある。どの選定であれ、独自 PDP の拡張点は残しておくこと。

実施点の配置：PDP は 1 か所、PEP は 3 か所——受信（ポータル）· 送信（ゲートウェイ）· インプロセス（プローブ / ランタイム）。

S6Agent プローブAgent Probe

3 層収集の基盤——SDK + daemon + カーネル。

経路技術取得する内容信頼度
セマンティック多言語の薄いクライアント（Go / Py / Node / Java / Rust）、ローカル UDS 経由プロンプト、ツール名と引数、委任チェーン、メモリ読み書き、サブエージェント派遣低
非信頼主体の内部で動く
ファクトLinux eBPF、Windows ETW（+ minifilter / WFP ドライバ）、macOS EndpointSecurityexec、ファイル読み書き、connect、DNS、TLS SNI高
バウンダリS4 ゲートウェイが出力（プローブの外側）呼び出し先、メソッド名、ペイロード規模、データ流出先高

ローカル daemon：多言語対応の実装方式

  • Rust コアを sidecar またはホスト daemon として動かす。各言語 SDK は薄いクライアント（シリアライズ + UDS）にすぎず、鍵も送信ロジックも持たない
  • daemon の責務：統一イベントモデル、ローカル事前相関、署名、バッファリングとバックプレッシャー、冪等なバッチ送信
  • 署名鍵は SPIFFE SVID / TPM 由来で、エージェントプロセスからは読めない——これが「証明可能」の技術的前提である
  • ネットワーク断時はディスクへ退避。完全オフライン環境では手動エクスポートによるフォレンジックに対応
  • FFI を使わない理由：FFI は言語ごとにビルドマトリクスと ABI 互換の維持が要る。daemon 方式なら「誰が eBPF を張るのか」も同時に解決する
Exclusive Responsibility 被統制エージェントの協力に依存しない観測チャネルを提供する。シャドーエージェントの発見もここでしかできない——未接続の Claude Code やローカル stdio MCP は、他のどこからも見えない。
Structural Ceiling · 能力の構造的上限 クロス照合が成立するのは外部から観測可能な副作用を伴うアクション（ネットワーク、ファイル、exec）に限られる。インプロセスのメモリ読み書き、ツール選択に至る推論過程、プロンプトの構築には第二の観測チャネルが存在せず、永久に自己申告のままである。したがってメモリ汚染について達成できるのは「メモリアクセスが完全に記録され否認できない」ことであり、「メモリの内容が真正である」ことではない。これは網羅性の不足ではなく構造的な上限である。後者を保証すると主張する方式には「第二の観測チャネルはどこにあるのか」と問う価値がある。

単独価値：純粋なデータソースとして単独提供でき、既存の SIEM / データレイクにエージェントの行動データを供給できる。

S7Agent 監査Agent Audit

1 回の実行で実際に何が起きたのか。事故時に説明できること。

内部モジュール責務
集約層3 経路のイベントを受信し、スキーマ検証のうえ格納する
トラジェクトリ組み立てcausal_parents（複数親）による因果 DAG であり、時系列ではない。分岐（サブエージェント派遣）と合流（非同期 join）に対応
クロス照合相関アンカー (pid, fd, 時間窓, 宛先 5-tuple, ペイロード指紋)。3 経路一致 → 高信頼で採用、自己申告あり / ファクトなし → SDK が改竄された可能性、ファクトあり / 自己申告なし → バイパス経路の存在
2 つの射影の分離監査射影（サンプリング不可・長期・WORM + ハッシュチェーン）と可観測性射影（サンプリング可・短期・時系列 DB）は必ず分ける
階層ストレージ不変 envelope（メタデータ + ダイジェスト + 署名）と機微 payload を分離。envelope は追記のみ、payload は独立したライフサイクルを持つ
プライバシーと消去既定ではダイジェスト / 分類 / 参照のみ保持。payload はテナント鍵で暗号化し、期限到来や権利行使時には鍵を破棄（crypto-erasure）する。envelope とハッシュチェーンは完全性を保つ
シークレット検出格納前にクレデンシャル / 鍵 / トークンを走査し、検出時は隔離して警報——監査ストア自体が新たな漏洩源になってはならない
閲覧監査監査ストアへの照会自体も記録する。監査の閲覧権限は業務権限から独立させる
証拠出力証拠パッケージは本システムから切り離して独立に検証できる。改変 / 削除 / 挿入 / 並べ替え / 末尾切り捨てを検出できる
コンプライアンス資料届出 / 評価用の資料一式をワンクリック生成：モデル一覧、コーパス出所、セキュリティ対策、評価記録
トピッククラスタリング「実際に何に使われているか」を階層クラスタリングし、品質劣化を発見する
差し替え可能なバックエンドClickHouse / ES / 任意の選択。OTLP エクスポートにより既存 SIEM へ直接供給できる
Exclusive Responsibility トラジェクトリ組み立てとクロス照合は同一箇所になければならない。突き合わせには 3 経路が同じ場所で組み立てられている必要があり、分けると比較対象が存在しなくなる。

OpenTelemetry について：3 つの判断を切り離すこと

レイヤ選択理由
伝播プロトコル
W3C Trace Context		必須：受信した traceparent を受け入れ、送信時に透過。MCP 宛先へは _meta 経由で伝播これがないと、システム境界ごとに経路が切れる
セマンティック規約
OTel GenAI semconv		必須（マッピング層を挟み、内部契約は自前で保持）主要ベンダーはすべて整合済み。Claude Code はすでに OTel GenAI trace を出力しており、整合すればそのまま取り込める
バックエンド
Jaeger / Tempo / 商用 APM		任意：ストレージと検索を内蔵しつつ、OTLP エクスポートも提供障害調査のためにトレース基盤の構築を強制すべきではない
Common Mistake · よくある誤り ストレージを内蔵することと、フォーマットを自作することは別である。よくある誤りは、この 3 つを 1 つの判断として一緒に切り捨てることだ。「外部トレース基盤に依存したくない」は正しい製品判断だが、そこから「OTel フォーマットを使わない」は導けず、まして「システム横断の経路連結をしない」は導けない。
もう 1 点：traceparent は相関のための仕組みであり、認可のクレデンシャルではない——証明の根拠は常に署名イベントである。信頼ドメインをまたぐ場合は親子継承ではなく links を用い、信頼できる入口が独立した governance_execution_id を発行する。
S8Agent 評価Agent Eval

エージェントは正しく動いているか。リリースしてよいか。

内部モジュール責務
指標ジャーニー完了率 · 回答の関連性 · 回答の正確性 · ツール選択精度とツール引数精度（別々に計測） · 指示追従度 · 目標達成率
リリースゲート品質スコアが閾値を下回ればリリース不可。コード品質ゲートと同じ構造である
ドリルダウン評価結果はイベントとしてトラジェクトリに紐づき、スコアから具体的なトラジェクトリまで辿れる
レッドチーミング複数ターン（multi-turn）で行う——単ターンのテストは偽の安心を与える
ポリシーの環レッドチーム / 評価が候補ポリシーを産出 → リプレイ検証 → 人による承認 → 段階的 dry-run → enforce。評価結果から自動で本番 enforce に入れてはならない
オンライン評価本番トラフィックをサンプリングしてオンライン評価し、指標のドリフトを監視する
Exclusive Responsibility · 評価器の隔離 Berkeley RDI（2026 年 4 月）は、1 体の攻撃エージェントで主要 8 ベンチマークすべてをほぼ満点に到達させた——タスク解決はゼロ、多くのシナリオで LLM 呼び出しもゼロ。手口は評価パイプラインそのものへの攻撃である。したがって「品質スコアをリリースゲートにする」には、次の 3 つが必須要件として付く：
#要件
1評価器の隔離：評価の実行・判定・採点は、被評価エージェントが読み書き・注入できる環境で動かしてはならない。結果の書き込み経路も被評価側から到達不能とする
2ゲートは自己証明できない：品質スコアはエージェントから独立した主体が生成し署名する（daemon 署名モデルを踏襲し、被評価側は秘密鍵を持てない）
3私有評価セットを主とする：公開ベンチマークは参考にとどめ、ゲートには使わない。ゲートには本番タスク分布から作った私有セットを用い、それを証拠として扱い、エージェントが読めるコンテキストには入れない
Division of Labour · 役割分担の原則 判定可能な検査はすべて決定的なコードで行い、LLM judge は使わない。ツールがケイパビリティ宣言の範囲内か、引数が制約を満たすか、権限を超えていないか——いずれも判定可能である。これを LLM judge に任せるのは高コストかつ不確実で（長さ・位置・自己選好のバイアスと非決定性）、ゲートを確率的なものに変えてしまう。LLM judge は意味的な判断にのみ用い、その場合も構造化ルーブリック + 複数回判定 + 人手ラベルによる較正を伴わせる。
Blueprint ID: GOV-COMP-SYSTEMS-V1Sheet 06 / 12
Section 06 — Cross-cutting Capabilities

2 つの横断能力

本番受け入れの条件でありながら、上記 8 システムのいずれ単独にも属さないものが 2 つある。明示的に割り当てないと、隙間に落ちる。

6.1　リカバリと補償

Principle 制約がアクションを止められなかった場合、その結果を取り消せなければならない。DB 更新・返金・デプロイ・リソース削除に触れるエージェントにとって、これは本番受け入れの条件であり、加点項目ではない。
能力どのシステムが担うか
不可逆アクションの分類、補償手段の登録S2 レジストリ（宣言時に登録）
不可逆アクションは人へのエスカレーションを強制し、自律実行を許さないS5 ポリシー
影響の大きいアクションは先に diff / 影響範囲プレビューを出すS1 ポータル（承認者の判断材料）
承認を不変の action digest に束縛し、実行時に一致を検証S1 ポータルが発行 → S4 ゲートウェイが検証
冪等キー：再送しても二重の副作用を生まないS4 ゲートウェイが注入と重複排除
トランザクション境界と部分失敗時の扱いS7 監査が記録、S5 ポリシーが判定

6.2　データガバナンス

Principle 監査は「全量・削除不可」を求め、プライバシー法令は「削除可能・最小化」を求める。両者は同時に成立させなければならない。前半だけを書くのは答えになっていない。
能力どのシステムが担うか
envelope / payload の階層化、crypto-erasure、保持期間と legal holdS7 監査
PII をモデル到達前にマスク、送信時に再検査S4 ゲートウェイ
格納前のシークレット検出と隔離S6 プローブ（ローカル事前走査）+ S7 監査（格納前）
テナント鍵、データ所在地S3 アイデンティティ（鍵）+ S7 監査（所在地）
データ主体の権利：応じられるもの（payload 破棄）と応じられないもの（否認できないメタデータ）S7 監査。法的根拠も併記する
Blueprint ID: GOV-COMP-CROSSCUT-V1Sheet 07 / 12
Section 07 — Runtime Sequence

1 回の実行が通過するシステム

段階S1 ポータルS4 ゲートウェイAgent ランタイムS6 プローブ
① 起動人間の認証 → 委任の起点。トラジェクトリの根を作り、元の意図を記録受信受け入れ：レベルとチェーンを検証テンプレートから実体を派生プロセス指紋をトラジェクトリへ
② 推論——推論ステップを記録—
③ ツール呼び出し—S5 が裁定・遮断。S3 から短期クレデンシャルを取得して注入。宛先とデータ流出先を記録ツール選択と引数を記録カーネルが connect / ファイル / exec を記録
④ メモリ入出力—リモートストレージ経由なら記録スコープとキーを記録カーネルが低レベル IO を記録
⑤ サブエージェント派遣—A2A ブローカーが裁定。Signed Agent Card + transport identity を検証チェーンを縮小し S3 が発行—
⑥ 承認承認の対話と証跡。action digest に署名遮断して待機。実行時に digest 一致を検証サスペンド—
⑦ 終了結果を返却—トラジェクトリを封止daemon 署名 → 送信
⑧ 事後———S7 が組み立てと照合 → S8 が採点、レッドチーム結果を還流
Key Constraint 委任チェーンの起点は S1 でしか生成できない。
ゲートウェイもランタイムも、検証と縮小はできるが、起点を無から作ることはできない。
Blueprint ID: GOV-COMP-SEQUENCE-V1Sheet 08 / 12
Section 08 — Indivisible Bindings

分割してはならない 4 点

ここを誤って分割すると成立しなくなる。「製品としての独立性」のために壊さないよう、明記しておく：

#必ず一体で保つもの分割した場合に起きること
1トラジェクトリ組み立て と クロス照合（いずれも S7）突き合わせには 3 経路が同一箇所で組み立てられている必要がある。分けると比較できず、クロス照合は名ばかりになる
2ID 発行 と チェーン検証（いずれも S3）単調縮小を誰も保証せず、チェーンの偽造や権限拡大が可能になる
3PDP の裁定 と decision_reason の出力（いずれも S5）「止めた」だけが残り「なぜ」が消える。事故検証で最も重要な問いに答えられない
43 層収集（S6 の 3 層 + S4 のバウンダリ経路）段階導入は可能だが、その時点では L1 までであると明示すること。「証明可能」と称してはならない
Blueprint ID: GOV-COMP-BINDING-V1Sheet 09 / 12
Section 09 — Module Alignment

主要製品とのモジュール対応

AWS や火山エンジンのエコシステムに慣れた読者向けの対応表。同じ部分は同じと述べ、異なる部分は理由まで述べる。

能力AWS Bedrock AgentCore火山 AgentKit Trust Plane本アーキテクチャ
Agent ID ディレクトリAgent Identity DirectoryWorkload Pool + Agent RegistryS2 レジストリと S3 アイデンティティを分離：ディレクトリはポリシーのホットパス・データソース、アイデンティティは発行者であり、整合性要件も遅延要件も異なる
ID 伝播OAuth 2.0 Token ExchangeTIP Token（RFC 8693）S3 は同じ方式（超大規模の本番実績がある方式）。加えて jti · nonce · confirmation key · チェーン長制限 · 失効を補う
ポリシーエンジンAgent AuthorizerCedar（RBAC / ABAC / ReBAC + IBAC）S5：裁定の入力は「トラジェクトリ + 現ステップ」であり単一呼び出しではない。言語は「決定可能な中核 + 事前計算特徴量」の 2 層構成
クレデンシャル管理Resource Token Vault + Secrets ManagerPass VaultS3 金庫 + S4 ゲートウェイ側注入（同じ考え方）
実施点マネージドランタイムTrust Plane Gateway（唯一の PEP）S4 ゲートウェイは迂回不可能だが、唯一の観測点とは仮定しない——S6 プローブのファクト経路とインプロセスのセマンティック経路がある
監査と可観測性CloudTrail + CloudWatchOTEL 全経路トレース + ダッシュボードS7 は監査射影と可観測性射影を分離（サンプリング / 保持 / 改竄耐性の要件が異なる）+ 3 経路のクロス照合
評価AgentCore Evaluations（公開モジュールなし）S8 + 評価器隔離の 3 要件
エンドポイント収集——（ゲートウェイ中心）S6 プローブ：eBPF / ETW / EndpointSecurity
Four Design Positions · 4 つの設計主張 上表の差分は次の 4 点に集約される：① トラジェクトリを第一級のガバナンス対象とする（可観測性の副産物ではない）、② ポリシーの入力は「トラジェクトリ + 現ステップ」（単一呼び出しではない）、③ 複数の実施点でクロス照合する（SDK やネットワークの片側だけを信頼しない）、④ ケイパビリティ宣言を統一的な受け入れ前提とする（宣言の外は違反）。この 4 点はそれぞれ「帰属可能 / 制約可能 / 証明可能」という 3 つの根本要件に対応する。いずれか 1 つを手放せば、対応する根本要件は成り立たなくなる。
Blueprint ID: GOV-COMP-ALIGN-V1Sheet 10 / 12
Section 10 — Onboarding

導入：レベルと 4 ステップ

10.1　受け入れレベル L0–L3

導入コストと保証強度は対価関係にある。レベルは単調でなければならず（上位は下位のすべてを含む）、レジストリに明示的に記録してポリシー入力とし、降格が検知できなければならない——かつて L3 だったエージェントが署名イベントを送らなくなること自体が警報である。

レベル名称導入側が提供するもの必要なシステムプラットフォームが提供するもの
L0可視存在シグナル（プロセス、ネットワーク特徴、DNS、ディレクトリ登録）S6 + S2発見、目録化、リスクスコア、シャドーエージェント警報
L1帰属可能完全なトラジェクトリ + 委任チェーン+ S1 + S3 + S7L0 + 監査イベント、判定経路、事後追跡
L2制約可能アクション前に PDP へ同期問い合わせし、裁定に従う+ S4 + S5L1 + 実行時遮断、dry-run、キルスイッチ
L3証明可能監査イベントの署名 + 改竄検知可能な送達 + クロス照合アンカー8 つすべてL2 + コンプライアンス級の証拠、規制対応、責任認定
Assurance Discipline · 保証表明の規律 導入したコンポーネントの数で保証レベルを上げてはならない。同一のエージェントでも、ネットワークアクションは高い保証に達する一方、ローカル stdio・同一プロセスのメモリ・暗号化ペイロードは低い保証にとどまりうる。レベルは アクション種別 × 実施点の組み合わせ ごとに宣言すること——network / MCP / stdio / file / exec / memory / sub-agent の 7 種別それぞれについて到達可能な保証を示す。エージェント全体を 1 つのレベルで表示すると、セキュリティポリシーもコンプライアンス表明も歪む。

10.2　4 ステップの導入手順

ステップやること導入側の作業プラットフォーム提供物
1 · まず見るプローブ導入、資産同期ホストへ daemon を導入。既存エージェント一覧をレジストリへ同期S6 プローブ一式（eBPF / ETW / ES）· S2 オンボーディング API
2 · ID を作るID と委任チェーンの接続登録時に SPIFFE ID を取得。ポータル接続で人間 ID を紐づけS3 発行経路（K8s UDS / 素プロセス / microVM vsock）· S1 SSO フェデレーション
3 · 経路を絞るゲートウェイへの強制ルーティングTool / MCP の宛先をゲートウェイへ切り替え。コードと環境変数から平文クレデンシャルを除去S4 ゲートウェイ Route · S3 クレデンシャル金庫とプロバイダテンプレート
4 · 証明するポリシーと監査の接続リソース / アクション軸でポリシーを宣言。既存 SIEM と接続S5 ポリシーテンプレートと dry_run · S7 証拠パッケージと OTLP エクスポート
Downstream Compatibility · 既存下流システムとの互換 GitLab、Argo CD、Kubernetes、SaaS などの業務側認可コードを変更する必要はない——クレデンシャル変換はゲートウェイ側で完結し、下流はネイティブの制御（Branch Protection、Sync Window、IAM、RBAC、アプリ認可スコープ）をそのまま保持する。
「低改修での導入」は「統合作業ゼロ」ではない：ゲートウェイ Route、リソースマッピング、Credential Profile、ポリシー基準、ネットワーク境界の設定は依然として必要である。
Blueprint ID: GOV-COMP-ONBOARD-V1Sheet 11 / 12
Section 11 — Delivery Bundles

提供パターン

一度にすべてを導入する必要はない。次の 4 パターンはそれぞれ単独で成立する：

パターンシステム解決すること到達レベル足りなくなる時
まず見るS2 + S6エージェントが何台あり、何をしていて、どの MCP に繋がっているかL0–L1見えるが止められない
まず止めるS1 + S4 + S5入口の一本化、送信の統制、遮断と停止L2止められるが証拠が不完全（クロス照合がない）
まず説明するS6 + S7コンプライアンス証明、規制照会、事故時の責任追及L1–L3証拠はあるが実施点がない
フルスタック8 つすべてガバナンスの完全なループL3—
Lowest Entry Barrier 「まず説明する」が既存環境への最も敷居の低い入り方である。
プローブと監査だけを入れ、データは既存の SIEM に流し込む。
Blueprint ID: GOV-COMP-BUNDLE-V1Sheet 12 / 12
「ガバナンスの対象はエージェントではなく、エージェントの 1 回の実行である。」
DS-ARCH-COMPOSITION-V1
END OF DRAWING SET · 12 SHEETS