AnthropicのEnterprise Frontier Safeguards｜悪用検知のログとゼロデータ保持の衝突を、顧客側クラウド保管でどう解くのか

LLMベンダーが悪用を検知するには、リクエストを一定期間ためて時間軸で相関させる必要があります。一方で、規制業種の情報システム部門やセキュリティ部門は「ベンダー側に自社データを残さない」ゼロデータ保持(ZDR)を求めます。この2つは、そのままでは両立しません。Anthropicが2026年9月1日に発表したEnterprise Frontier Safeguards(EFS)は、この衝突を「保存する場所と鍵と、フラグを見る人を顧客側に移す」という形で解こうとするものです。この記事では公式発表と公式ドキュメントに書かれている事実を整理したうえで、日本企業の情報システム/セキュリティ担当が自社のLLM利用について「ログがどこに残るのか」を棚卸しするための観点をまとめます。

何が発表されたのか#

Anthropicの公式発表(2026年9月1日付)は、EFSを「ゼロデータ保持(ZDR)のプライバシーと、悪用検知のための最先端のセーフガードを組み合わせたソリューション」と説明しています。仕組みは単純で、データをAnthropicではなく顧客が管理するクラウドインフラに保存する、というものです。公式に明記されている範囲を先に列挙します。

本記事の事実関係は、Anthropicの公式発表ページ、Claude Help Centerの「Covered Models」、Anthropic Privacy Centerの「Data retention practices for Covered Models」、Claude Platform Docsの「API and data retention」「Access Transparency」「CMEK」を一次情報としています。報道由来の記述は都度出典を明示します。いずれも2026年9月7日時点の記載で、条件は変わりえます。

見落とされやすい記述もあります。「これらのコントロールは、Anthropicから直接Claudeにアクセスする場合でも、クラウドパートナー経由の場合でも同じように動作するよう設計されている」という一文です。AWS・Google Cloud・Microsoft Azure上の顧客は同等のコントロールを得て、活動データは自分のクラウドアカウントに置かれると説明されています。

なぜ「衝突」が起きていたのか#

EFSは唐突に出てきた製品ではなく、2026年6月に始まった保持ポリシーの変更への応答です。ここを押さえないと何を解いているのかが見えません。

Covered Modelsと30日保持#

Anthropicは、能力が高く追加のセーフガードが必要と判断したモデルを「Covered Models(対象モデル)」として指定する仕組みを持っています。公式のヘルプ記事に現在の指定一覧が載っています。

Covered Modelsに適用されるポリシーとして、公式は「既定で30日の最低保持」を挙げています。プロンプトとモデルの出力は少なくとも30日保持されたのち自動削除され、安全性調査の対象になっている場合や法的に保持が必要な場合は例外になります。そして重要なのが次の一文です。Covered Modelsにアクセスできるワークスペース、Claude Enterprise組織、サードパーティのプラットフォーム(例としてAzureサブスクリプション)では、ゼロデータ保持は利用できないと明記されています。

Anthropic Privacy Centerの記事は理由を具体的に説明しています。一部の攻撃は複数リクエストにまたがってはじめて可視化される、というのが趣旨です。例として挙げられているのは、プロンプトの微妙な差分を数百通り送りつけて1つでも通ることを狙うBest-of-Nジェイルブレイク、国家支援型のスパイ活動、データを人質にした恐喝キャンペーンです。分類器が多数のリクエストを俯瞰してはじめて浮かび上がるため、プロンプトと出力を一時的に保持して一緒に分析する必要がある、という組み立てです。なお「この方針はエンタープライズデータで学習したいという動機によるものではない」という説明は、Privacy Centerではなく今回の公式発表のほうに書かれています。

規制業種側の事情は「監視そのもの」ではなかった#

公式発表は、顧客から実際に何を言われたのかを分けて記述しています。反対の中心は「監視されること」ではなかったことが分かります。

データ保管については、企業にとって「信頼できるデータベンダー」を1社増やすこと自体が重い作業だという説明が置かれています。ベンダーが誰であるかを自社の顧客に通知し、契約を更新する必要がある。機微度の高いデータを安全に保管し監査するための社内要件もある。だからEFSは、顧客が既存のクラウドインフラにデータを置ける設計にしたと書かれています。

人手レビューについてはさらに直接的です。自動レビューが有効になってきてもなお、フラグを人が見て悪用を確認し誤検知を潰す価値はある。ただし規制業種の顧客から聞いたのは「そのレビューをする人は自分たちの側の人間である必要がある」という要求だった、と説明されています。理由として、特権的な法務資料・非公開情報・医薬品安全性報告など誰が見てよいかを厳密に定めた規則の下で運用していること、自社のチームは既にその業務のための訓練と認可を受けていることが挙げられています。

EFSはどう解こうとしているのか#

3つのオプトインと、変えないもの#

公式発表の「How EFS works」節には、コントロールが3つ挙げられています。顧客所有のストレージ、顧客管理暗号鍵(Customer-Managed Encryption Keys)、完全自動レビューです。3つはそれぞれオプトインで、組織が必要なものだけを有効にできると書かれています。続く一文も重要です。「これらのいずれも、モデルの挙動、API価格、レート制限を変えるものではない」。EFSは、モデルの性能や課金体系をいじる話ではなく、データの置き場所とレビュー主体だけを動かす話だと位置づけられています。

自動監視の中身についても記載があります。自動システムがトラフィックのローリングウィンドウを分析し、深刻な悪用の兆候を探す。対象として名指しされているのは、攻撃的なサイバー能力や生物学的能力の開発の試み、そして盗まれた資格情報や漏洩した資格情報の兆候です。そのフラグは顧客に直接送られ、そこから先は顧客の担当者が引き取る。Anthropic従業員による人手レビューは不要、と明記されています。

変わらないもの#

EFSで監視が止まるわけではありません。Claude Help Centerの「Covered Models」記事には、暫定措置の説明に続けて次の趣旨が書かれています。この取り決めが影響するのは保存されたデータの保持とレビューだけであり、利用ポリシー(Usage Policy)、リアルタイムの安全分類器、Anthropicの執行システムはすべてのトラフィックに適用され続ける。そしてAnthropicは、悪用への対応を含めこの取り決めを変更または撤回することがある、と明記されています。

アラートの運用は自社に来る#

ここがEFSの実務上の勘所です。Anthropicが人手レビューをしないなら、フラグを最初に見るのは自社のセキュリティチームです。Help Net Securityの記事はこの点を「規制対象企業のセキュリティを担当しているなら、アラートキューを回すのは今後あなたたちだ」と表現し、Anthropicがローリングウィンドウの長さを公表していない点も指摘しています(いずれも同記事による指摘であり、Anthropicの公式記載ではありません)。

The Registerも同様の見方です。同記事は、企業はZDR契約を自動的に受け取るのではなく申請が必要であること、EFSはコンプライアンス上の利点と引き換えに、Anthropicの担当者が行っていたかもしれない監視業務を顧客が引き受けるコストを伴うことを指摘しています。あわせて、OpenAIが前月にPrivate Safety Processingという、ZDRのコミットメントを損なわずに顧客とモデルのやり取りがリスクに当たるかを確認する仕組みを発表したと報じています(OpenAI側の公式ページは本稿執筆時点で当方から取得できなかったため、この点は同報道に基づく記述として扱います)。

時期・費用・暫定措置を正確に読む#

公式は時期について確定的な日付を出していません。「段階的にロールアウトする」「今秋に広く利用可能にすることを目標とする」という書き方で、アクセスを希望する場合はフォームから申請するとされています。暫定措置は、Claude Help Centerの「Covered Models」記事のほうが詳しく書かれています。

課金は明確です。AnthropicはEFSに課金しませんが、顧客が自分のクラウドアカウントにデータを保存することを選んだ場合、そのストレージ、読み書き、データエグレスの料金は他のリソースと同じようにクラウド事業者から請求されます。「無料の機能が増える」話ではなく「支払先が変わる」話だと理解しておくのが正確です。

実務:自社のログがどこに残るかを棚卸しする#

ここからは、EFSの提供を待つかどうかに関わらず、いま手を動かせる部分です。多くの組織で足りていないのはベンダーの方針の知識ではなく、自社の利用経路の一覧です。

観点1:経路を先に並べる(APIか、コンソールか、SaaS組み込みか)#

同じClaudeでも、どこを経由して呼ぶかで保持の扱いが変わります。Claude Platform Docsの「API and data retention」は、ZDRが何をカバーし何をカバーしないかを列挙しています。カバーしないものとして挙げられているのは、Claude Console(playgroundを含む)、Claude Managed Agents(セッション記録は削除するまで残る)、消費者向けプラン、Claude TeamsとClaude Enterpriseの製品インタフェース(例外はZDRを有効化したClaude Enterprise経由のClaude Code)、Claude for Excel、サードパーティ連携、そしてCovered Models自体(Anthropicが明示的に許可した場合を除く)です。ZDR契約の組織ではCORSがサポートされず、ブラウザから直接呼ぶ構成はバックエンドのプロキシ経由に変える必要があることも同じ一覧に書かれています。

同ドキュメントのFAQには、さらに実務的な説明があります。ZDRで「No」と表示されている機能を使ってもリクエストはブロックされず、Batch APIはジョブを、Files APIはファイルを、コード実行は永続コンテナを保存する。これらを使うことは、その特定のデータについてZDRの取り決めの外に出る選択をしたことになる、と書かれています。ブロックされないからこそ、開発者が気づかないまま範囲外に出る点は社内周知に値します。

Claude Codeの公式ドキュメントは、さらに細かい注意点を挙げています。ここで説明されているZDRはClaude for Enterpriseの適格アカウント向けで、標準プランには含まれず管理画面からは有効化できません(Claude Platform側のドキュメントでは、商用組織のAPIキーでClaude Codeを使う経路もZDRの対象として併記されています)。有効化は組織単位で、同じアカウント配下でも新しい組織には自動適用されず、開発者が個人アカウントや別組織のAPIキーでサインインしたセッションはカバーされないと明記されています。ZDRを有効にすると、Claude Code on the Web、デスクトップアプリのクラウドセッション、Claude Tag、Artifacts、フィードバック送信、Remote Controlがバックエンドで無効化されます。

観点2:プロバイダの保持既定は「機能ごと」に見る#

「このベンダーは何日保持か」という粒度の質問は、たいてい答えが出ません。公式ドキュメントは機能ごとに条件が分かれているからです。Anthropicのドキュメントでは、ZDRとHIPAA対応の枠組みの外に別の保持モデルが存在すると明記され、Activity Feedは6年間保持、ローカルセッション記録(CoworkやClaude Codeなど利用者の端末上のセッションから取得されるもの)とリモートセッション記録は既定で6年間と書かれています。

他社も同じ構造です。GoogleのGemini Enterprise Agent Platformのデータガバナンス文書は、ZDRを達成するには領域ごとに顧客が特定の対応を取る必要があるという前提を明示し、機能別に条件を並べています。

Microsoftの「Data, privacy, and security for Foundry Models sold by Azure」も、悪用監視のデータストアと人手レビューについて具体的に書いています。悪用の兆候が検知されると顧客のプロンプトと出力のサンプルがレビュー対象になることがあり、レビューは既定でLLMを含む自動的手段によって行われ、必要に応じて人間のレビュアーによる追加レビューが行われるという記述です。人間のレビュアーがアクセスできるのは、既にフラグが立てられたデータか悪用の疑いがある利用パターンの一部に限られ、権限を持つMicrosoft従業員がリクエストIDによるポイントワイズクエリ、セキュアアクセスワークステーション、管理者によるJust-In-Timeの承認を経てアクセスすると説明されています。

同ドキュメントには、悪用監視の変更(modified abuse monitoring)を承認された顧客の扱いも記載があります。承認されるとデータ保管と人手レビューのプロセスは行われませんが、自動レビューは引き続き実施されることがあり、深刻または反復的な悪用を示す可能性のあるコンテンツが検知された場合は顧客がアクセス制限の対象になりうると明記されています。加えて、承認後に実際にログ保存が止まっているかを顧客側で確認する手順(Azureポータルのリソース概要のJSONビュー、またはAzure CLIでのContentLoggingの値の確認)まで案内されています。

観点3:ZDRの適用条件を、契約とプランの単位で確認する#

ZDRは機能名ではなく取り決めです。Anthropicの公式ドキュメントは、ZDRを求める場合は営業チームに連絡すること、ZDRは組織単位で有効化され同一アカウント配下の新しい組織には自動的に拡張されないことを明記しています。そのうえで、取り決めがあっても保持が発生する条件が別に定義されています。ZDRやHIPAA対応の取り決めがある場合でも、法律で要求される場合、またはAnthropicの自動的なトラスト&セーフティシステムによってフラグが立った場合にはデータが保持されることがあり、その結果、入力と出力が最大2年間保持されることがあると書かれています。

観点4:監査ログと「悪用検知のログ」は別物#

EFSの説明に出てくる「顧客自身の監査ログ」と、AnthropicのAccess Transparencyのような「ベンダー側の人手アクセスの記録」は、目的も範囲も違います。

Access Transparencyの公式ドキュメントは、機能の限界を率直に書いています。記録されるのは人間によるアクセスのみで、Anthropicの自動安全システムや分類器は通常運用の一部として顧客のコンテンツを処理し続けるが、その処理はanthropic_accessイベントを生成しないと明記されています。そして決定的な一文があります。「フィードが空であることは、Anthropicの人間が誰もあなたのコンテンツを閲覧していないことを意味する。それはあなたのコンテンツが自動システムで処理されなかったことを意味しない」。

タイミングにも制約があります。イベントはアクセスや保全から2営業日以内にCompliance APIのフィードへ配信され、リアルタイムのアラート経路として扱うべきではないと書かれています。対象範囲も限定的で、Claude API・APIキーを使うClaude Code・Claude Platform on AWSは対象ですが、Batch APIとFiles API、claude.aiのEnterpriseシート、消費者向けプラン、Consoleのplayground、Microsoft Foundry、Amazon BedrockとGoogle Cloudは対象外です。

もう1つ、CMEKと組み合わせたときの挙動が実務上重要です。公式ドキュメントは、安全性レビューが深刻な有害コンテンツを確認し進行中の調査のために標準の保持期間を超えて保全する必要があるまれなケースがあると説明し、その際は保全されたコンテンツが顧客管理鍵の外で再暗号化されると明記しています。顧客の鍵とは独立して調査を継続できるようにするためです。この保全はcmek_preserveイベントとして記録され、他の保持コンテンツは顧客の鍵の下に残るとされています。

CMEKには機能面の副作用も多く、導入前に読む価値があります。公式ドキュメントによれば、Claude PlatformではConsoleのplaygroundとCompliance APIのうち生のコンテンツを返す部分が、Claude Enterpriseでは会話履歴の検索・プロジェクトナレッジの検索(RAG)・監査ログのエクスポートが無効化されます。さらに、いったん鍵をワークスペースに紐づけると切り離しも入れ替えもできず、データ保持設定がロックされてゼロデータ保持に戻すには新しいワークスペースへの移行が必要になり、鍵の失効や無効化はそのワークスペースのCMEK保護データを恒久的にアクセス不能にすると書かれています。

観点5:悪用検知を切ることのトレードオフを言語化する#

「悪用監視をオフにできるなら、オフにしたほうが安全ではないか」という議論は必ず出ます。失うものと残るものを分けて書くのが有効です。

失うのは、時間軸をまたいだ検知です。Anthropicの説明もHelp Net Securityの記事も、資格情報の窃取を分かりやすい例として挙げています。盗まれた鍵から出るリクエストは1件ずつ見れば普通に見え、時間をかけて異常な振る舞いを見なければ気づけません。これは自社にとっての防御価値でもあります。自社の資格情報が盗まれて第三者にAPIを叩かれている状況を自社のアプリケーションログだけで検知できるかを考えると、監視の価値が見積もりやすくなります。

残るのは、リアルタイムの安全機構です。Anthropicは、暫定措置の取り決めが影響するのは保存されたデータの保持とレビューだけで、利用ポリシー、リアルタイムの安全分類器、執行システムはすべてのトラフィックに適用され続けると明記しています。Microsoftも、悪用監視の変更が承認された顧客についてデータ保管と人手レビューは行われないが自動レビューは実施されうると書いており、Googleも悪用監視の例外は申請するものだとしています。

つまり選んでいるのは「監視のオン/オフ」ではなく「保存の場所と、フラグを最初に見る人」です。EFSはこの構図をそのまま製品化したものと読むのが実態に近いと考えられます。

観点6:日本の実務で追加で押さえること#

日本で運用する場合、ベンダー側の設定確認は「やっておいたほうがよい心得」ではなく、監督官庁が名指しで挙げている確認事項に関係します。個人情報保護委員会は2023年6月2日付の注意喚起で、個人情報取扱事業者について、個人情報を含むプロンプトの入力は特定された利用目的の達成に必要な範囲内であることを十分に確認すること、そして本人の同意なく個人データを含むプロンプトを入力し当該個人データが応答結果の出力以外の目的で取り扱われる場合には法の規定に違反することとなる可能性があるため、提供事業者が当該個人データを機械学習に利用しないこと等を十分に確認することを求めています。

保持の設計は、この確認と地続きです。どこに、誰の管理下で、どれだけの期間残るのかを説明できなければ、利用目的の範囲内であることの説明も難しくなります。EFSのように保管先が自社クラウドに移る構成はこの説明を作りやすくしますが、それは材料が揃うという意味であって、法令適合の判断そのものではありません。

この発表から断定できないこと#

公式情報を読んだうえで、現時点では判断できない項目を明示しておきます。曖昧にしたまま社内資料を作ると、後で訂正が必要になります。

• 提供開始の具体的な日付。公式は「段階的」「今秋開始」「今秋に広く利用可能にすることが目標」としか書いていません。
• 適格性(eligible customers)の具体的な条件。公式は該当組織に直接連絡する旨とフォームからの申請を案内していますが、判定基準は公開されていません。
• 自動監視が見るローリングウィンドウの長さ。公式発表には記載がなく、Help Net Securityもこの点が非公表であることを指摘しています。
• 日本を含む各リージョンでの提供条件。EFSのページにリージョンごとの記載はありません(別機能のCMEKは、Claude Platform on AWSを除き現時点で米国リージョンのみと公式に記載されています)。
• 顧客のクラウドに置かれる「活動データ」の具体的なスキーマと粒度。

未確定項目は「分からない」と書いて残すほうが後から効きます。正式ドキュメントが出た時点で記述が具体化することが多いため、社内資料には確認日と参照URLを添え、再確認のタイミングを決めておくのが実務的です。

よくある質問#

まとめ#

EFSを一行にまとめると、「悪用検知に必要な保存を否定せず、保存する場所と鍵と、フラグを最初に見る人を顧客側に移した」となります。Anthropicが人手レビューをしない代わりに、その業務は顧客のセキュリティチームに移ります。コンプライアンス上は前進でも、運用の総量は減りません。

ベンダーの発表は、たいてい「こちらが引き取る負担」と「そちらが引き取る負担」を同時に動かします。EFSはその典型で、規制対応の説明可能性を上げる代わりに監視の一次対応を顧客側に置きます。どちらが自社に有利かは、規制の厳しさとセキュリティチームの体制で変わります。まずは自社の経路とログの残り方を一覧にし、その上で「待つ」「暫定措置を申請する」「そもそも当該モデルを使わない」の3択を比べるのが、いま取れる一番現実的な進め方です。