AI APIのアテステーション検証手順

アテステーションは、期待する実行環境へ接続しているかを確認するための証拠です。 TEE対応という説明を読むだけでなく、クライアント側で検証する手順を、Tinfoilの公式CLIを例に整理します。

この記事は2026年11月8日の公式文書と公開リリース情報を確認して作成しました。編集部では今回CLIを実行しておらず、現時点の検証成功や実推論を確認した記事ではありません。コマンドの実行結果は、利用時のCLI・証明形式・サービス状態で確認してください。

取得・検証・推論を分ける

成功表示の意味は、何を期待値として渡したかで決まります。提供元の任意のコードなら何でもよいのか、特定のリリースだけを許可するのかを先に決めます。

1. 公式CLIと対象を確認する

公式CLIのリポジトリ ↗（外部サイト・新しいタブで開きます）と導入手順 ↗（外部サイト・新しいタブで開きます）から、OSに合うリリースを取得します。可能ならリリース版と配布物のハッシュを記録します。公開チェックサムとの一致は配布物の照合であり、発行元を信頼しなくてよくなる仕組みではありません。

導入後、手元のヘルプで構文を確認します。

tinfoil --help
tinfoil attestation verify --help

本記事では認証情報の設定や推論APIの呼び出しは扱いません。対象ホストと期待するワークロードの対応は公式資料から確認し、応答したホストが自己申告する名前だけを期待値にしないようにします。

2. 期待するワークロードを指定して検証する

公式資料のルーター検証例は次の形です。

tinfoil attestation verify \
  -e inference.tinfoil.sh \
  -r tinfoilsh/confidential-model-router

JSONの検証記録を保存する例もあります。

tinfoil attestation verify \
  -e inference.tinfoil.sh \
  -r tinfoilsh/confidential-model-router \
  -j > verification.json

この例は特定のルーターを期待値にしています。ホストとリポジトリを変えれば、検証する対象も変わります。CLIの終了コードと出力を確認し、失敗した場合は機密データを送る処理へ進めない構成にします。

3. 成功時に何を確認するか

公式の検証説明 ↗（外部サイト・新しいタブで開きます）と基盤の説明 ↗（外部サイト・新しいタブで開きます）に沿って、次を照合します。

• ハードウェアの証明と証明書チェーンが有効か。
• 測定値が、期待するビルドやワークロードに対応するか。
• 期待するリリースやアーティファクトの制約を適用したか。
• 証明に含まれる鍵と、実際の接続先の鍵が結び付くか。
• 鮮度を確認する方式と、その有効期間を理解しているか。

鍵の結び付きがなければ、正しい環境の証明を見せながら、データは別の場所へ送る構成を排除できません。実際に推論する場合は、検証済みの接続を使う公式SDK等の経路まで確認します。

4. 失敗を分類して記録する

タイムアウトをTEEが破られた証拠と解釈することも、検証を無効化して成功扱いにすることも適切ではありません。日時・CLI版・対象・期待値・終了コードを記録します。検証ログを公開する前には、組織名や内部ホスト名等が含まれないかも確認してください。

ゲートウェイの先まで証明されるか

ルーターが正しいコードで動くことと、その先のGPU・モデル・個別リクエストが何によって結び付くかは別の確認です。CPUの証明だけを見て、特定のモデルの全計算を証明したとは書けません。

TEE対応の窓口と実行主体で経路を整理し、処理後の保持条件はZDR比較で確認します。技術による確認と契約上の確認を組み合わせて、必要な範囲を決めてください。

公式の検証手順・公開リリース情報の最終確認日: 2026-11-08（0日前）