機密を含むAIチャットでは、安全判定のために誰へ会話を渡すかが設計上の問題になる。
Tinfoilが2026年9月14日に公表し、9月16日に更新した方式は、保護された実行環境の中で会話を判定し、運営者へ本文を渡さずに違反を通知する。
ただし判定は応答と切り離して進むため、その場の有害な回答を止める防御にはならない。公式発表
この方式を採用する判断軸は、会話の秘匿、応答速度、危険な出力の即時阻止のうち、どこまでを同時に要求するかだ。
2026年9月17日時点の公式発表、技術文書、公開リポジトリのREADMEに基づく設計解説である。発表ではTinfoil Chatへ今後数週間で展開するとしており、全利用者への適用完了を確認したものではない。評価数値は同社の報告で、筆者による追試ではない。
暗号化した会話を、どこで判定するのか
通信経路をTLSで暗号化しても、サーバーが受け取って復号した後のデータまで自動的に保護されるわけではない。安全判定サービスへ平文を転送すれば、そのサービスも会話を扱う主体になる。
Tinfoilは、CPU・GPUの機密計算機能を用いたenclave、つまりホスト側から隔離された実行環境で推論を行う。データは保護された環境の内部で処理される。暗号文のまま任意の計算をするという意味ではない。技術概要
新しい安全判定も、この保護境界の中に置く。公開READMEによる処理の流れは次のとおりだ。Confidential Safeguards
- モデルルーターと同じenclaveに置いたsidecarが会話を受け取り、キューに入れる。
- 別の検証済みenclaveにある
gpt-oss-safeguard-120bが、会話をポリシーに照らして分類する。 - 違反候補だけを、さらに別のenclaveの
kimi-k3が再審査する。 - 確定した違反について、利用者の認証情報と会話IDを管理系へ報告する。
管理系へ渡す違反報告には、会話本文、違反カテゴリ、判定理由を含めない。次の図はその境界を簡略化したものだ。
この構造でも、誰に違反が発生したかという情報は保護境界の外へ出る。会話本文の秘匿と、利用履歴を含めた完全な匿名性は別の要件である。アカウント停止を行う設計なら、違反を利用者へ結び付ける情報が必要になる。
応答の同期経路から、安全判定を外す
ルーターのREADMEでは、利用者へ実際に返した応答を会話履歴へ加え、非同期でsidecarへ渡すとしている。安全判定の完了を待ってから返答する構造ではない。ルーターの安全判定仕様
以下は処理の順序から導ける一般的な比較であり、製品間の実測比較ではない。
| 比較項目 | 出力を検査してから返す同期方式 | Tinfoilの非同期方式 |
|---|---|---|
| 判定と応答の順序 | 判定を終えてから公開 | 応答経路と判定を分離 |
| その回答の差し止め | 判定に基づき可能 | この仕組みでは不可 |
| 利用者の待ち時間 | 判定時間が加わる | 判定完了を待たない |
| 主な用途 | 出力直前の制御 | 継続的な違反への対応 |
「判定を待たない」と「計算資源を消費しない」は違う。分類モデルと再審査モデルの推論は別途必要であり、混雑すれば未処理の会話が増える。非同期化によってなくなるのは、応答を返す前に判定を完了させる依存関係だ。
API利用まで監視されるとは読まない
同じREADMEには適用範囲も明記されている。対象は /v1/chat/completions と /v1/responses に対する、自社チャットのアクセストークンで認証された通信であり、APIキーによる通信はこのsidecarへ送られない。適用条件
したがって、Tinfoilの推論APIを組み込めば自社サービスにもこの監視が付く、とは判断できない。独自アプリケーションでは、どの要求を判定するのか、判定結果で何を制御するのかを別途定義する必要がある。
二段階判定の数値は、何を示しているか
公開評価リポジトリは、提供前のモデル審査と、会話を判定する監視器の評価を分けている。ここでは後者の数値を読む。評価リポジトリ
実行時監視の評価には、前処理後で約120万件のWildChat会話を使った。一次判定で1,402件を検出し、二次判定で846件を維持したと報告している。公式発表・図2
この2つの件数から計算できるのは、一次判定が付けたフラグのうち、二次判定が取り消した割合だ。
$$
\frac{1402-846}{1402}\times100\approx39.7%
$$
公式記事はこれを約40%のfalse-positive rateと呼んでいる。しかし、通常の統計的な偽陽性率は、実際に問題のない会話を分母とする。
$$
\mathrm{FPR}=\frac{\mathrm{FP}}{\mathrm{FP}+\mathrm{TN}}
$$
上の件数だけでは、この分母は分からない。さらに、二次判定の維持・取消がすべて正解であるとも限らない。
したがって、実務上は「二次判定が一次判定の候補を約4割減らした」と読むのが適切だ。「無害な会話の4割を誤検知した」「最終段では誤検知がなくなった」のいずれも、この集計からは言えない。
一次判定で見逃した会話は二次判定へ進まないため、再審査を足すだけで検出漏れが解消するわけでもない。評価では、フラグが減った量に加えて、無作為抽出した未検出会話や、文脈の長い会話での見逃しを別に測る必要がある。
attestationが保証する対象を絞って理解する
enclaveを使うという説明だけでは、そこにどのプログラムやモデルが置かれているかは分からない。そこで使うのがremote attestation、実行環境の測定値を外部から検証する仕組みだ。
Tinfoilの技術文書では、クライアントがハードウェア署名付きの測定値と公開ビルドの情報を照合し、接続先TLS鍵も証明情報に結び付ける。モデル重みの読み取り専用ボリュームには dm-verity による検証を用いる。検証アーキテクチャ
これが支えるのは、接続先と実行構成を確かめるための根拠だ。分類モデルの判断が正しいことを、ハードウェアが証明するわけではない。
たとえば、公開された判定ポリシーに従うモデルが、婉曲表現を誤読することはあり得る。実行構成が期待どおりであることと、その構成が十分な安全性を持つことは、別々の検証課題として扱う必要がある。
限界は、会話を見られない運用にも現れる
判定前に応答が届き、判定自体が失われる場合もある
公式発表は、enclaveの版が変わると審査待ちの会話データが失われ、版をまたいで永続化されないと説明する。またsidecarのREADMEでは、モデル呼び出しに失敗した会話を破棄し、次のターンで再び拾う方針としている。更新時の扱い・エラー時の扱い
ここから、全会話について必ず最終判定が得られる、と仮定してはいけない。次のターンがなければ、再処理の機会もない。これはデータ保持を抑える利点と、監視の網羅性を維持する難しさが同じ場所に現れる例だ。
本文を持たないため、通常の問い合わせ対応も変わる
運営者へ判定カテゴリや理由を送らない構成では、担当者が保存済みの本文を開いて誤判定を直す、という対応はできない。異議申立てを設計するなら、利用者が自発的に提出する情報をどう扱うか、通常の監視とは別のデータ経路として検討する必要がある。
対象ポリシーは限定されている
公開ポリシーの主な対象は、児童への危害、大規模な暴力・テロ、自傷に関する有害な出力だ。利用規約が扱う範囲はこれより広い。Safety & Safeguards
したがって、この仕組みを企業の秘密情報流出防止、法令適合性の確認、回答の事実検証まで含む汎用的な審査とみなすことはできない。また、enclave内部では会話が処理されるため、ハードウェア、ファームウェア、検証処理、内部ソフトウェアへの依存も残る。
採用前に、応答制御と監視を別々に決める
この設計から得られる実務上の示唆は、安全判定を一つの「ガードレール」設定で済ませないことだ。次の3項目を、サービスの要求として明文化すると判断しやすい。
- その場で止める対象。 有害な出力を利用者へ一度も渡せないなら、公開前の同期判定や、実行権限の制限を別途設ける。非同期監視だけでは要求を満たさない。
- 境界の外へ出せる情報。 本文だけでなく、会話ID、利用者識別情報、違反の発生というメタデータも棚卸しする。
- 判定を完了できない場合の動作。 キュー滞留、更新、呼び出し失敗時に、応答を継続するのか、機能を制限するのかを決める。
運用指標も、分類精度だけでは足りない。対象会話に対する判定完了率、判定までの時間、更新時の未処理件数を併せて測る。これらは本記事からの設計提案であり、Tinfoilが公表した達成値ではない。
会話の秘匿を重視し、継続的な違反への対応を非同期で行うサービスなら、この分離は検討に値する。一方、最初の一回の危険な出力を防ぐことが要件なら、出力前に働く制御を中心に設計する必要がある。
参考リンク
Tinfoil — Safety Without Compromising on Privacy（2026年9月14日公開、9月16日更新）
Tinfoil — Safety & Safeguards（2026年9月17日参照）
Tinfoil — System & Technology（2026年9月17日参照）
Confidential Safeguards — README（2026年9月17日参照）
Confidential Inference Router — Acceptable use safeguards（2026年9月17日参照）
Tinfoil Documentation — Backend infrastructure（2026年9月17日参照）
Tinfoil Safeguards — 評価リポジトリ（2026年9月17日参照）