署名付きReceiptは何を証明し、何を証明しないのか

🎥 YouTubeでも公開しています

AIエージェントの外部実行をどう証明するかPipelock ReceiptとAI Execution Boundaryの設計

Books: Runtime AI Governance 実践ガイド: Knowledge Flow・Trust Engine・Decision Traceによる動的AIガバナンス設計

PipelockのReceiptは、AI Agentの外部通信を仲介する実行境界において、

いつ、どのAgentまたはワークロードが、どの宛先へ、どの種別の通信を試み、どのポリシー評価を受け、許可または拒否されたか

を署名付きで残す仕組みである。

これは単なるアプリケーションログより強い。後からログを編集して「この通信は許可されていなかった」「この遮断は起きていない」と書き換えることを難しくし、署名を検証できる第三者に対して、境界装置が記録した判断結果を提示できるからである。

たとえば、AgentがMCP Toolを通じて外部APIへアクセスしようとしたとする。Pipelockが宛先、送信内容、秘密情報の混入、内部ネットワークへの到達可能性、危険な指示やツール汚染の兆候などをポリシーに照らして評価し、拒否したなら、その判断をReceiptとして残せる。

その意味でPipelockは、AI Agentの「外界へ作用する直前」を守るExecution Boundaryであり、そこで生じた判断をDecision Traceとして残す有力な部品である。

しかし、ここで注意すべきなのは、Receiptが証明するのはあくまで、

その境界装置が、その時点で有効だったルールに従って、ある判断を行った

という事実である。

Receiptだけからは、組織全体が適切に統制されていることまでは導けない。

1. ルールそのものの正しさは証明しない

Pipelockは、設定されたポリシーを実行する。したがって、宛先の許可リストが広すぎる、秘密情報の検知ルールが弱い、あるいは「外部送信を許可する」というルールが誤って設定されている場合、その誤ったルールに従って許可したReceiptも発行される。

署名付きReceiptが示すのは「ルールどおりに動いた」ことであり、「ルールが妥当だった」ことではない。

ここには、ポリシー作成者、承認者、変更者を分ける職務分掌と、ルール変更の承認・期限・レビューが必要になる。特に本番環境では、誰が、どの業務目的のために、どの接続先・データ種別・操作を許可したのかを、Pipelockの外側で管理しなければならない。

2. 境界を通らない通信は記録できない

AgentがPipelockを経由するよう正しく構成されていても、別のネットワーク経路、別の認証情報、未管理のMCP Server、直接のSDK呼び出し、あるいは開発者が持ち込んだ外部ツールを使えば、その通信はPipelockの観測・制御範囲外になる可能性がある。

これは「門の監視が厳重でも、建物の裏口が開いていれば意味が薄れる」という問題に近い。

したがって、実行境界を有効にするには、プロキシ導入だけでは足りない。egressを原則遮断し、許可された経路だけを通すネットワーク設計、認証情報をAgentの環境へ直接置かないSecret管理、MCP Serverの登録・署名・棚卸し、コンテナや実行環境の権限分離が必要である。

3. 通信が安全でも、Agentの判断が正しいとは限らない

Pipelockは「その送信が危険か」「その宛先へ出してよいか」を判断できる。しかし、Agentが業務上の文脈を誤解している、古いデータを参照している、委任の目的を取り違えている、あるいは重要な例外条件を見落としている場合でも、通信自体がポリシーに適合していれば許可されうる。

たとえば、調達査定Agentが、正規の取引先APIに正規の形式で見積情報を送ったとしても、その見積を送ること自体に担当者の承認が必要だったなら、通信の安全性と業務判断の正しさは別問題である。

ここで必要になるのが、業務レベルのDecision Traceである。

• 何を目的に処理したのか
• どのデータ、ルール、根拠を使ったのか
• どの権限と委任契約に基づくのか
• なぜActではなくAskまたはStopにしなかったのか
• 誰が、どの時点で承認・上書き・差戻しをしたのか

こうした記録があって初めて、通信記録は業務上の意思決定記録と結び付く。

4. Receiptは「誠実な運用者」までは保証しない

Receiptの署名鍵を運用者が自由に扱え、ポリシー変更もログ保管も同じ管理者が単独で行えるなら、強い監査証跡には限界がある。管理者が不正なルールを入れ、都合のよいReceiptだけを保管する、鍵を差し替える、境界を迂回する経路を用意するといった問題は、Receipt単体では解決しない。

この限界を小さくするには、少なくとも次の設計が必要になる。

• ポリシー変更をGit等で版管理し、承認履歴を残す
• Receiptの署名鍵をHSMやKMSで保護し、鍵の利用権限を分離する
• Receiptを改ざん耐性のある外部LedgerやWORM保管へ転送する
• ポリシー版、Agent版、MCP Server版、実行環境の構成ハッシュをReceiptへ結び付ける
• 高リスク操作はHuman Gateを通し、承認記録とReceiptを相互参照できるようにする
• 定期的に、実際のegress経路とReceiptの記録が一致しているかを監査する

つまり、ReceiptはTrustを「生成」するものではない。Trustを検証可能にするための、重要だが限定された証拠である。

Runtime OSにおける位置づけ

Runtime OSでは、Pipelockは主にExecution Boundary層を担う。

Pipelockを導入する意味は、「Agentを安全にする」ことを一つの製品に丸投げすることではない。

むしろ、Agentの行為を、少なくとも外部への実行段階では必ず検査可能な境界へ通し、その判断を検証可能な形で残すことである。そのReceiptを、委任契約、権限、Human-in-the-loop、業務ルール、Decision Trace Ledgerと接続して初めて、組織として説明可能で止められるAI運用基盤になる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance