本稿でいうトラステッドインスタンスとは、AIエージェント（またはLLM実行環境）が「どのコード／どの設定／どの権限境界で起動し、何を実行し、どんな外部ツールと通信したか」を、**インスタンス単位で検証可能（cryptographically verifiable）**に示せる実行形態を指します。ゼロトラストの前提（侵害を前提に、明示的に検証し、最小権限で運用する）に沿って、AIの“実行主体”を「信用する」のではなく「証明できる状態」に寄せていく考え方です。
エグゼクティブサマリ
調査時点（日本時間 2026年3月3日）では、「トラステッドインスタンス」を製品として端から端まで実装している例は限定的ですが、要素技術は急速に揃いつつあります。特に、エージェントがIDE/CLIやクラウド上で自律的に動くほど「信頼境界」が広がり、**インスタンスの実在性（attestation）と行動の証跡（verifiable logs/provenance）**が中核になっています。
大手ベンダーの“近さ”を整理すると、（用途は異なるものの）AppleのPrivate Cloud Compute（PCC）は「検証可能性（verifiable transparency）」の設計思想を前面に出した代表例です。一方で、開発者向けエージェント運用という観点ではAnthropicのClaude Codeが、権限ベース設計・サンドボックス・監査ログ・MCPの安全設計といった「運用上のトラステッドインスタンス要素」を最も多く公開しており、現時点で最も“近い”側にあります。
ただし現実の課題として、**「起動前に信頼判断をすり抜ける」**タイプの脆弱性が実際に発生しており、設定ファイルやフック、MCP接続が“受動的メタデータ”から“能動的実行面”へ変わったことが、ゼロトラスト上の難所になります。
技術的には、トラステッドインスタンスを支える柱は大きく三つに収束します。
インスタンス単位の署名（起動と環境の保証）／行動単位の証明（実行ログと成果物の証明）／Reasoningログの検証可能化（推論や判断の“監査可能な圧縮表現”と、必要ならZK/TEEでの“正しく計算した”証明）です。
各社の現状とトラステッドインスタンスへの距離
下表は、各社が公開している「機能（現状）」「トラステッドインスタンスに近い要素」「一次ソース」を、できるだけ公式ドキュメント／公式ブログ／論文／標準文書に寄せて整理したものです。未公開の点は明確に「未公開/非公開」と記します。
補足として、日本語メディアでは「Claude Code Security」を“推論型の脆弱性発見・修正提案”として紹介する記事も出ており、AIが開発/セキュリティ基盤に入り込む流れ自体は日本でも加速しています。
実現技術の中核
トラステッドインスタンスは「ゼロトラストの理念」を、AIエージェントの実行形態に落とし込む試みです。実装を分解すると、**起動（環境）と行動（実行）と判断（推論）**の三層で「証明可能」にしていくのが整理しやすいです。
インスタンス単位の署名とアテステーション
インスタンス単位の署名は、端的に言えば「このAI実行環境は“期待した状態”で起動している」と示すための仕組みです。標準化の軸では、IETF のRATSアーキテクチャが、Attester/Verifier/Relying PartyやEvidence/Claimsといった概念を整理し、プロセッサやプロトコルに依存しない枠組みを提供しています。
アテステーションの“運搬形式”としては、EAT（Entity Attestation Token）が「デバイスやソフトウェア等のエンティティに関するclaimsをまとめたトークン」であり、JWT/CWTで表現できることが仕様化されています。これにより、インスタンスの状態（例：測定値、構成、信頼度）を、Relying Partyが機械的に評価しやすくなります。
クラウド各社は、この“証明の根”をハードウェアTEEと結びつけて提供します。たとえば Amazon Web Services のNitro Enclavesは、Nitro Hypervisorをroot of trustとして、エンクレーブのハッシュや署名鍵等を含むアテステーションドキュメントを生成でき、鍵管理（AWS KMS）がアテステーションドキュメントを確認した上で“エンクレーブの公開鍵で暗号化した形で”データを返す仕組みを説明しています。
同様に、MicrosoftはAzure Attestationを「証拠を受け取りclaimsに変換し、ポリシー検証して暗号学的な証明を出す」サービスとして説明し、GoogleはConfidential VM/Confidential Spaceの文脈で「TEE上で正当な状態のVM/ワークロードであることを検証する」ためのアテステーション文書を公開しています。
AppleのPCCは、端末側がクラスタの“同一性と構成”を検証できるアテステーションを提示し、さらに研究者がPCCソフトウェアを検証できる「verifiable transparency」を取る点が特徴的です（用途は“AI推論基盤”ですが、思想としてはトラステッドインスタンスに直結します）。
実装上の要点は、次の三点に集約されます。
第一に、鍵はインスタンスに閉じる（TEE内で生成し、外へ出さない／短命にする）。第二に、鍵の使用許可をアテステーション結果に結びつける（例：KMSが“正当なエンクレーブ”にだけ復号素材を渡す）。第三に、署名/測定結果を改ざん困難なログへ残す（後述の透明ログや追記専用ログ）。
行動単位の証明
「行動単位の証明（Proof of Action / Proof of Execution）」は、AIエージェントの“実行”そのものを、後から検証できる形で残すアプローチです。実務的には次の二層に分かれます。
一つ目は、行動メタデータの署名です。ソフトウェアサプライチェーン分野では、in-toto Attestation Frameworkが「ソフトウェア成果物に関する署名付きメタデータ」を表現し、SLSA Provenanceは「どこで・いつ・どう作られたか」を検証可能にするための形式を提示しています。これをAIエージェントに当てはめると、(入力のハッシュ, 使用ツール, 出力のハッシュ, 権限境界, ポリシーID, トレースID) といった“行動記録”を署名し、後から検証できるようにする設計になります。
二つ目は、改ざん耐性ログ（透明ログ）への登録です。代表例がCertificate Transparency（RFC 6962）で、Merkle treeに基づく追記専用ログにより、証明書の「存在」とログの「追記専用性」を監査可能にします。この設計思想は汎用ログ（Trillian、Sigstore Rekor）にも拡張され、Sigstore Rekorは署名付きメタデータを追記専用ログに格納し、包含証明等で検証できることを説明しています。
「Proof of Execution」をより強くする選択肢としては、ZK（ゼロ知識証明）を使って**“正しくそのプログラムが実行された”ことをレシート（receipt）で証明**する方式があります。例としてRISC Zeroは、zkVMがプログラム実行の正しさを証明するレシートを生成できると説明しています。これをエージェントの一部（重要処理や検証器）に適用すると、行動ログの“改ざん耐性”だけでなく“正しく計算した”側に寄りますが、計算コストと設計難度が上がります。
実装例として、AnthropicのClaude Codeはそもそも「権限ベース＋サンドボックス」で行動境界を狭め、クラウド実行では分離VMと監査ログを設けるなど、暗号学的証明ではないものの“行動の統制”に寄せた設計を公開しています。
Reasoningログの検証可能化
“Reasoningログ”は、ここでいう「推論過程（内部の思考そのもの）」をそのまま残すというより、現実的には 判断の根拠となった入出力・中間状態・ポリシー評価の痕跡を、監査可能な形に圧縮して残すことが主戦場になります。理由は、完全な推論ログはプライバシー・機密情報・モデルIP（あるいは安全上の事情）と衝突しやすく、保存・共有のコストも高いからです。
現実解としての設計パターンは三つあります。
第一に、**トレーシング＋プロヴナンス（来歴）**です。OpenTelemetryは、ログにトレースコンテキスト（trace id等）を付与して相関できる設計を示しており、W3C PROVはエンティティ/活動/主体の関係として来歴を表現するための標準モデルです。エージェントの“推論ログ”を、①入力（Entity）②ツール呼び出し（Activity）③出力（Entity）④実行主体（Agent）としてPROVで表現し、OpenTelemetryのtraceでシステムログと結び付けると、「なぜこの結論に至ったのか」を“行動の連鎖”として検証しやすくなります。
第二に、整合性だけを暗号で担保するコミットメント方式です。ログ本文は要約・マスキングした形で保存しつつ、原文（高機密）や中間状態（巨大）についてはハッシュでコミットし、必要時だけ開示して検証できる形にします。これは透明ログ（Merkle tree）と相性がよく、CTやRekorの思想を“Reasoningログの要約”に転用できます。
第三に、**推論そのものの検証（zkML/zkLLM系）**です。ZKMLの研究は、現実的なMLモデル推論に対してZK-SNARKを生成する最適化システムを提案しており、LLM推論に対するZK証明（例：zkGPT）も研究として公開されています。これらは「その出力が所定のモデル（あるいはコミットされた計算）から来た」ことを証明する方向ですが、現時点では計算コスト、モデル表現、入出力秘匿、運用の複雑さが大きく、全面適用より“重要判断だけ”に限定する設計が現実的です。
実装事例とプロトタイプ
ここでは「学術論文」「特許」「OSS」「企業PoC/公式実装」の順に、トラステッドインスタンスに直結する例を短く列挙します（リンクは一次ソース優先、可能なものは日本語も併記します）。
AppleのPCC検証用コード公開（OSS）
PCCの検証可能性（verifiable transparency）に関する取り組みの一部として、研究者が参照できる形で公開されているリポジトリです。https://github.com/apple/security-pccAnthropicのサンドボックスランタイム（OSS）
Claude Codeの安全な自律実行を支える研究プレビューとして、OSプリミティブ（macOS sandbox-exec/ Linux bubblewrap等）でファイル・ネットワーク制限をかける実装を公開しています。https://github.com/anthropic-experimental/sandbox-runtimeClaude Codeのセキュリティ設計（公式ドキュメント）
権限モデル、サンドボックス、MCP安全設計、クラウド実行時の監査ログ等をまとまった形で公開しています。https://code.claude.com/docs/ja/securityMicrosoftのConfidential AIサンプル（OSS/PoC）
Confidential Computing上でAIワークロードをホストするサンプル群として公開され、「本番利用非推奨の作業中」と明記されています。https://github.com/microsoft/confidential-aiAzure Attestation（公式ドキュメント）
証拠をclaimsに変換しポリシーで検証し暗号学的証明を出す、という“検証サービス”の考え方がまとまっています。https://learn.microsoft.com/ja-jp/azure/attestation/overviewGoogle Cloud Attestation / Confidential VM attestation（公式ドキュメント）
TEE上で動くVMが想定状態であることの検証プロセスを文書化しています。https://docs.cloud.google.com/confidential-computing/docs/attestation?hl=ja/https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/attestation?hl=jaAWS Nitro Enclaves attestation（公式ドキュメント）
エンクレーブのアテステーションドキュメントと、KMSがそれを検証して“エンクレーブ鍵で暗号化して返す”設計が明記されています。https://docs.aws.amazon.com/ja_jp/enclaves/latest/user/set-up-attestation.html/https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/cryptographic-attestation.htmlSigstore Rekor（OSS/仕様・実装）
署名付きメタデータを追記専用透明ログへ格納し、包含証明等で検証する透明ログの実装です。https://github.com/sigstore/rekor/https://docs.sigstore.dev/logging/overview/Trillian（OSS：汎用透明ログ）
Certificate Transparencyの考え方を一般データに拡張する透明ログ基盤として文書化されています。https://google.github.io/trillian/docs/TransparentLogging.htmlIETF SCITT（標準化：透明ログ＋主張の流通）
ソフトウェアサプライチェーンで、主張（attestation）を透明ログに登録し検証する“部品”の相互運用を目指すWGです。https://datatracker.ietf.org/group/scitt/about/zkML（学術：ZKでML推論を証明）
ZK-SNARKで現実的なML推論を証明する最適化システムを提案しています。https://dl.acm.org/doi/10.1145/3627703.3650088zkGPT（学術：LLM推論のZK証明）
LLM推論に対する非対話ZK証明フレームワークの例です。https://www.usenix.org/system/files/usenixsecurity25-qu-zkgpt.pdfAttestable Audits（学術：TEEで“監査”を検証可能に）
TEE内で監査を実行し、モデル提供者と監査者が相互不信でも検証可能にする枠組みを提案しています。https://arxiv.org/html/2506.23706v1特許：TEE＋署名＋分散台帳で実行結果を検証（例）
実行インスタンスごとに鍵ペアを生成し、TEE内で実行結果署名を作り、台帳に記録して検証可能にする発想が明示されています。https://patents.google.com/patent/US11954226/en特許：台帳ベースの検証可能コード実行（例）
タスクと出力（コミットメント含む）を台帳に記録し、検証者が競合出力を出して合意をとる枠組みが説明されています。https://patents.google.com/patent/US20230047924A1/en
技術的ギャップと導入上の課題
最大のギャップは、「AIエージェント実行の信頼境界」が設定ファイル・外部ツール接続・自動化フックへ拡張したのに対し、従来の開発運用（レビュー、権限設計、監査）がその速度で追随しきれていない点です。実例としてClaude Codeでは、信頼確認（trust prompt）より前に“プロジェクト設定が影響してしまう”類型の脆弱性が報告され、CVEとして公的DBにも記載されています。これは“トラステッドインスタンス”が目指す「信頼判断の前に実行しない／実行するなら証明する」を、実装で一貫させる難しさを示します。
次に大きいのは、運用コストとスケーラビリティです。アテステーションは鍵・証明書・証拠収集・ポリシー評価・失効（revocation）を伴い、しかもクラウドやTEE方式ごとに癖があります。現場知見として、クラウドごとのリモートアテステーション差分や“何が保証されているか分かりにくい”点を指摘する資料も出ています。
プライバシーと監査のトレードオフも避けられません。Reasoningログを厚く残すほど、個人情報・機密情報・モデルやプロンプトの秘匿性と衝突します。そこで、OpenTelemetryのように相関可能な形でログを標準化しつつ、本文は要約・マスクし、厳密性はハッシュ・透明ログで担保する、といった“圧縮監査”が現実的になります。
さらに、**インターオペラビリティ（相互運用）**は“最後の難関”です。RATS/EATやSCITTのような標準化は進む一方、実際のクラウド実装・証拠形式・ポリシー表現はまだ統一されていません。トラステッドインスタンスを「一社の製品内」ではなく「複数社・複数ツールにまたがる実行境界」として実装するなら、標準の採用と、監査ログ／署名／アテステーションの“翻訳層”が必要になります。
参考キーワード集
トラステッドインスタンスを設計・議論する際に、参照頻度が高いキーワードを整理します（読者が追いやすいよう“探す単語”として列挙します）。
- Zero Trust（侵害前提・明示的検証・最小特権）：Claude Codeの権限モデルやクラウド境界設計は、この思想の実装例として読めます。
- TEE / Confidential Computing（SGX/TDX、SEV-SNP、Nitro Enclaves、Confidential VM/Space、Secure Enclave）
- Remote Attestation / RATS：アテスター・検証者・依拠者、Evidence/Claims/Resultsの整理。
- EAT（Entity Attestation Token）：アテステーショントークン（JWT/CWT）としてclaimsを運ぶ。
- MCP（Model Context Protocol）：外部ツール連携の標準化。連携は利便性と攻撃面を同時に広げるため、安全設計と隔離が重要。
- Verifiable Logs / Transparency Logs（Merkle tree、CT、Trillian、Rekor）：追記専用性と包含証明で改ざん検知する。
- Provenance / Attestation（in-toto、SLSA）：行動/成果物の来歴を署名付きで残す。
- Observability / Correlation（OpenTelemetry、W3C TraceContext）：エージェント行動をトレースとログで相関。
- zk-proofs / zkML / zkVM：推論や実行の“計算正当性”を（必要に応じて）証明する。
- DLT/Blockchain for attestations：台帳に実行記録・署名を残し検証する設計（特許例含む）。
結論
トラステッドインスタンスは、ゼロトラストをAIエージェントの“実行単位”へ拡張する概念であり、2026年時点では「監査ログ」「閉域化」「サンドボックス」「アテステーション」「透明ログ」「ZK証明」が、各社・各OSSの断片として揃い始めています。AppleはPCCで“検証可能性”を強く打ち出し、Anthropicは開発者向けエージェント実行に必要な信頼境界（権限・隔離・監査）を具体的に公開しており、現状の実装に最も近い一角です。一方で、設定ファイルやツール接続が“実行面”になったことで「信頼判断の前に動いてしまう」リスクも顕在化しており、今後の主戦場は、アテステーションと鍵管理を結合し、行動レシートを透明ログへ積み、Reasoningログは圧縮監査＋重要判断のみ強検証へ、という段階的アーキテクチャに収束していくと見立てます。
