1,247件中247件がサイレントに欠落しても気づけない — AIエージェントに「証明可能な説明責任」を持たせる「Verified Loop」という設計パターン

8月11日、1Passwordが「Verified loops: Building AI agent trust and accountability」と題した記事を公開した。AIエージェントが自律的にアクションを取る時代における信頼性と説明責任の担保を、「Verified Loop（検証済みループ）」というアーキテクチャパターンで実現する手法を解説している。

「もっともらしい結果」は「検証済みの結果」ではない

1Password が直面した問題を示す具体例がある。1,247コミットを含むリリースのリリースノートをエージェントに生成させた場合、出力は一見完全に見える。しかしGitHub の比較APIは最初の1,000件しか返しておらず、247件のコミットがサイレントに欠落している。エージェントはそれを知る術がない。

従来の対策—ツールのインベントリ管理やスコープ付き認可—では、エージェントがAPIを呼んだこと、リポジトリを読めたことは証明できる。しかし「フルのコミット範囲を受け取ったか」「各記述を承認済みのソースに紐付けたか」は証明できない。このギャップが、Verified Loop が解こうとする問題だ。

Verified Loopの構造

Verified Loopは以下の3層で構成される。

ジョブマニフェスト（人間が定義する検証境界）：エージェントが実行前に何を達成すべきかを宣言する。プロンプトが「どう動くか」を伝えるのに対し、マニフェストは「何に触れてよいか」「何を証明しなければならないか」「どのパーミッションを獲得できるか」を定義する。

version: release-notes-v3
job: release-notes
owner: release-team
subject:
  repository: product
  from: v4.1.0
  to: v4.2.0
  head_sha: abc123
required:
  - commit-range-reconciled
  - every-claim-has-approved-source
  - missing-metadata-reported
may_earn:        # deny by default; nothing else is grantable
  - github.open-draft-pull-request
never_earn:      # cannot be added to may_earn by any revision
  - github.merge
  - release.publish

never_earn フィールドが重要で、ポリシーを弱体化させることによる迂回を防ぐ。マージや公開の権限はリリースオーナーに留まる。

システム発行のエビデンス（エージェント自身は書けない）：1Password は OpenTelemetry トレースをランの生イベント記録として使用する。スパンはツールゲートウェイが発行し、エージェントは自分の行動の公式記録を書くことができない。エビデンスには発行者の認証、転送・保存の保護、エージェントの実行コンテキスト外での署名が必要だ。

truncatedなリリースノートのケースでは、検証ハーネスが以下のようなレシートを生成してfailを記録する：

{
  "claim": "commit-range-complete",
  "evidence": [
    { "source": "github-compare-api", "commitCount": 1000, "responseHash": "sha256:917c…" },
    { "source": "git-local",          "commitCount": 1247, "responseHash": "sha256:30ea…" }
  ],
  "check": { "name": "commit-range-reconciled", "result": "fail" },
  "requestedAction": "github.open-draft-pull-request",
  "decision": "deny",
  "signature": "ed25519:4f89…"
}

アクションゲートウェイ（状態に束縛されたケイパビリティ）：レシートはコミット abc123 に対して発行される。ブランチが def456 に進んだ後は、そのレシートで認可されたアクションは実行できない。ケイパビリティはリソースバージョン・許可アクション・有効期限・レシートダイジェストを持ち、アクションゲートウェイが使用時に再検証する。

実践事例：SAGE（セキュリティレビューの自動化）

1Password が社内で構築した SAGE（Security Analysis Guidance Engine） は、この仕組みの具体的な応用だ。詳細は別記事「Scaling security reviews with an AI-powered pipeline」で紹介されている。

SAGEは汎用コードレビューエージェントと並走し、Finder・Critic・Judge という役割を持つ複数モデルが連携して、セキュリティ上の知見を開発サイクルの早い段階にフィードバックする。エンジニアリング判断をアーキテクチャドキュメント・リポジトリ固有のルール・セキュリティポリシー・決定論的テストという「検査可能なインプット」に変換した点が核心だ。

結果、SAGEが指摘した発見の70%以上が、Product Securityのレビュー前にリゾルブされた。これはモデルの正確さを証明するものではなく（偽陰性率は未測定）、「関連するエビデンスを早期に移動させながら、マージの決定責任を保持し続けられる」ことを示している。

「自己修復」は境界の内側に限定する

エージェントの自己修復能力（タイムアウトのリトライ、期限切れ認証情報のリフレッシュ等）は有用だが、ポリシー回避の隠れ蓑にならないよう境界を明示する必要がある。

マニフェストはリトライ可能な失敗・許可されたフォールバック・最大試行回数・ループが停止すべき条件を宣言する。エージェントが拒否されたアクションに対して別の認証情報を探したり、未承認ツールに切り替えたりすることは権限昇格またはゴールドリフトとして扱われる。

最初の一歩：狭いループから始める

記事では、最初のVerified Loopを構築するための5つのアーティファクトが示されている。

アーティファクト	内容
ジョブマニフェスト	オーナー、必須入力、承認済みツール、獲得可能/不可能なアクション、停止条件
権限マップ	ソース、認証情報、書き込みパス、システム境界（最初は読み取り専用推奨）
エビデンススキーマ	各レシートが含むべきソース・スコープ・リソースバージョン・チェック結果
評価セット	成功例、欠損入力、矛盾するソース、既知の偽陰性・偽陽性
人間の判断ポイント	どの判断が人間に残るか、その人が受け取るエビデンスは何か

重要なのは、「エージェントのアウトプットが改善したから」という理由でプロモートしないこと。次の特定のパーミッションを与えることが安全だとエビデンスが示したときだけ、ループを昇格させる。

設計思想の核心

エージェントのアウトプットは確率論的なままだが、その権限を統治するルールは明示的かつ決定論的に執行されなければならない。Verified Loop が解決しようとするのは、エージェントの能力の問題ではなく、「誰が行動したか」「どの権限を受けたか」「何のエビデンスを生成したか」「次のアクションに対してどの権限を得るべきか」という説明責任の問題だ。

詳細はVerified loops: Building AI agent trust and accountabilityを参照していただきたい。