まだ発表していない製品の仕様書を、AIと一緒に読みたい。契約書の細部も、社内の調査資料も、そのまま渡せたら仕事は進む。けれど「学習には使いません」と言われても、少し引っかかる。
では、その文章はどこに残り、誰が見られるのだろう。
これは、AIを信用するかしないかだけの話ではない。顧客から預かった情報なら、自分の判断だけで第三者へ開示できないこともある。使いたいからこそ、仕組みを知りたい。その要求に対し、AnthropicとOpenAIが、監視用データの置き場所と閲覧権限を組み直そうとしている。
「学習しない」と「保存しない」は、別の約束だった
架空の例で考えよう。社員が新製品の設計資料をAIに送り、問題点を探してもらう。少なくとも、次の処理は別々に起こりうる。
| 処理 | 何をしているか | 混同しやすいこと |
|---|---|---|
| 回答のための処理 | 今回の問いに答えるため、内容をモデルへ渡す | 学習に使わなくても、回答には内容の処理が必要 |
| 履歴・ログの保存 | 会話の再表示、業務記録、監視などに残す | 保存があるだけで、モデルの訓練に使われたとは限らない |
| 不正利用の検知 | 攻撃や認証情報の盗用などの兆候を調べる | 自動検知と、担当者が文章を読むことは同じではない |
| モデルの訓練 | 将来のモデルの振る舞いを改善する材料にする | 「訓練しない」だけでは、上の処理の条件は決まらない |
表は概念の整理で、すべてのサービスが同じ処理をするという意味ではない。契約で「学習利用なし」を確認できても、監視用ログが別の場所に残るなら、その取り扱いも知りたくなる。
ログを自社に置き、検知はAI企業に任せる
Anthropicが2026年9月1日に発表したEnterprise Frontier Safeguards（EFS）は、この分業を提案している。監視用の活動データを、顧客が管理するS3、Azure Blob Storage、Google Cloud Storageなどに置き、顧客側の暗号鍵やアクセス管理を使う。自動監視が見つけた兆候は顧客に送られ、人による確認を自社の担当者で行える設計だ。AnthropicのEFS発表
流れを短くすると、こうなる。
業務中の活動データ → 自社管理の保存先 → 自動監視 → 自社の担当者が確認
「設計資料に不審な利用があった」と警告されたとき、もともとその機密を扱う権限のある社内チームが、正常な仕事なのかを確認する。外部の担当者に全文を見せることを前提としない点が大きい。発表で説明されているのは「Anthropic従業員の人間レビューを必須にしない」ことであり、あらゆる事情で誰も一切アクセスできないという包括的な保証ではない。
なおEFSは、2026年秋以降の段階展開を予定する発表だ。今すべての利用者が設定画面で切り替えられる機能ではない。
OpenAIは、本文ではなく限定的なシグナルを受け取る
OpenAIが8月19日に予告したPrivate Safety Processingも、関連する複数のやり取りを自動で調べる。そのうえで同社へ渡すのは活動の種類を示す限定的なシグナルとし、保持された本文を同社の担当者へ見せない設計を説明している。顧客管理の基盤を使う方式に加え、顧客管理鍵で暗号化してOpenAI側のストレージを使う選択肢も開発中だ。Private Safety Processingの説明
たとえば警告が誤りだと思ったら、顧客は自分の記録を調べ、必要な情報を共有するか選ぶ。検知をやめるのではなく、検知に必要な情報と、人間が読める内容を切り分けようとしている。
同社は初期顧客との試験と、9月の段階提供を予告している。法令上の報告に関わる特定画像の保持など、ZDRにも明記された例外はある。「ゼロ」という単語だけで、契約全体を読み終えたことにはならない。
Azureや自社運用とは、何が違うのか
Microsoft Foundryにも、自動検知と、必要な場合の権限を限定した人間レビューがある。一定の条件を満たした顧客は、人間レビューなどを変更するmodified abuse monitoringを申請できる。すべての顧客・モデルで無条件に外せる設定ではない。Microsoftの監視仕様
| 選択肢 | 変えようとしている場所 | 企業側に残る仕事 |
|---|---|---|
| Anthropic EFS | 監視用データの保管を顧客管理下に置き、警告を顧客へ | 自社ストレージ・権限・警告後の調査運用 |
| OpenAIの新方式 | 保持本文への担当者アクセスを避け、限定シグナルで検知結果を扱う | 自社記録での確認、必要に応じた異議申立て |
| Azureの監視変更 | 適格な利用について、人間レビュー等の扱いを変更 | 申請条件の確認と、検知通知への対応 |
| モデルを自社で運用 | 推論処理とデータの所在そのものを自社側に置く | 機器、更新、アクセス管理、監視なども自ら担う |
前三者は各社の公表資料に基づく設計・提供条件の比較。最後の行は、外部送信しない構成を選んだ自社運用の一般的な説明であり、特定製品の保証ではありません。検知性能を同条件で測った比較ではありません。
特に間違えたくないのは、監視用ログを自社に置くことと、モデル自体を社内で動かすことは違うという点だ。EFSを使うだけで、Claudeの推論まで自社サーバーに移るわけではない。
また、暗号鍵を自社で持つことも、「暗号化された文章を、誰も処理せず魔法のように理解する」という意味ではない。自動システムが内容を扱える条件と、人間が閲覧できる条件を分けるのが設計の要点だ。実際の採用では、利用するサービス・接続先・保存機能まで含めて、その境界を確認することになる。
昨日まで断られた仕様書が、使えるようになる条件
たとえば、顧客から預かった未発表製品の仕様書。会社がAI利用を止めていた理由が、「契約で認めた外部サービスによる処理は可能だが、監視のために別の会社の担当者が原文を見ることは認められない」だったとする。以下は仕組みを理解するための仮想例だ。
従来の利用条件で、その人間レビューを避けられなければ、担当者は使いたくても使えない。モデルがどれだけ賢くても、そこは解決しない。
そこで、監視ログを会社がすでに管理しているクラウドへ置く。閲覧できるのは、その仕様書を扱う権限のある社内チームだけにする。誰が読んだかも記録し、警告が届いたらそのチームが調査する。モデル提供者による推論処理そのものも契約で認められ、必要な設定を実際に有効にできるなら、禁止の理由だった「社外の人が原文を読む」を解消し、利用を再検討できる。
ここで変わるのは、「機密だから駄目」という一括判断が、「この情報を、この契約・設定・担当者の範囲なら扱える」という具体的な判断になることだ。自動的に利用許可が出るわけではなく、以前は満たせなかった条件を満たす道ができる。
反対に、顧客との約束が「データを外部の推論処理へ一切送らない」なら、ログの保存先を変えるだけでは足りない。送信してよい範囲まで情報を減らす、契約を見直す、外部送信しない構成のモデルを使う。違う解き方が必要になる。
最後に穴が開きやすいのは、AIの「周り」
AI本体の条件を整えても、社員が別の拡張機能へ同じ資料を渡したら、その拡張機能の条件が加わる。たとえば、AIが社内文書を読めても、検索のために秘密の製品名を外部サイトへ送ってよいとは限らない。生成した要約を、別のチーム全員が読める共有フォルダへ保存してしまうこともある。
だから、試し始めるなら、まず架空の仕様書で一往復させてみる。入力から回答、監視ログ、検索先、保存先まで、どこを通ったかを担当者と確認する。ログだけでなく、出力された要約やアプリ側の履歴にも、同じ機密が残りうるからだ。これは本稿からの検証提案であり、各社が自動で実施してくれる工程ではない。
警告への対応も仕事として残る。自社でレビューするなら、誰が受け取り、誤検知をどう切り分け、漏えいの疑いがあれば誰へ連絡するのか。鍵と保存先を用意しただけで、監視を引き受けたことにはならない。
なおAnthropicの発表では、自社ストレージ、顧客管理鍵、人間レビューを不要にする自動レビューは、それぞれ選んで有効化する仕組みだ。EFSという名前が契約に載っただけで、希望する設定が全部入ったと思わないこと。確認すべきなのは、実際に使う環境のデータ経路と、有効になっている条件である。EFSの設定・展開方針
「使えません」を減らすための、設計の話
私は、この動きを単なる安全機能の追加とは見ていない。今までなら「重要な情報なのでAIには渡せません」で閉じていた仕事を、開ける可能性があるからだ。
契約を読める人が限られるなら、その範囲でAIと働く。機密の監視を外部へ委ねられないなら、社内の権限を持つ人が確認する。守るべき条件を捨てずに、賢いモデルを仕事へ近づける。
「企業を信じてください」から、「誰が何を扱えるかを設計しましょう」へ。機密を守りながらAIを使うために、欲しかった議論はこの具体さなのだと思う。
2026年9月7日確認。新機能の提供範囲・保持条件は、利用契約と最新の公式資料での確認が必要です。実環境でのセキュリティ監査結果ではありません。
