Anthropic の Enterprise Frontier Safeguards — 監視をやめずにデータ保持をやめる、という解き方
Anthropic が Enterprise Frontier Safeguards(EFS)を発表した。2026-06 に導入した「Fable / Mythos クラスの全トラフィックに30日間のデータ保持」というポリシーが、規制産業を中心に導入障壁になっていたことへの回答である。解き方は、監視をやめるのでも保持をやめるのでもなく、保存先を Anthropic から顧客管理のクラウドへ移すというもの。活動データは顧客の S3 / Azure Blob / GCS に、顧客の暗号鍵とアクセスポリシーと監査ログのもとで保存される。顧客所有ストレージ、顧客管理暗号鍵、完全自動レビューの3つがそれぞれ個別のオプトインで、いずれもモデル挙動・API価格・レート制限を変えない。Anthropic は EFS 自体に課金しない。提供は段階的で 2026年秋の広範提供が目標。それまでの間、対象顧客は Fable 5 / 5.1 でゼロデータ保持を受けられる。
ニュース原文を読む ↗要約
2026-09-01、Anthropic が Enterprise Frontier Safeguards(EFS) を発表しました。同日の Claude Fable 5.1 / Mythos 5.1 の公開と対になる発表です。
背景から説明します。
2026-06、Anthropic は Fable 5 / Mythos 5 の公開に合わせて、これらのモデルの全トラフィックに30日間のデータ保持を要求しました。 目的はサイバー攻撃への悪用の検知で、Anthropic はそのデータを学習に使わないと明言していました。
しかし、規制産業の顧客にとってこれは重い制約でした。 金融・医療・法務のような領域では、「外部ベンダーに顧客データが30日間保持される」という一点だけで、導入審査が通らないことがあります。データを保持する事業者が増えるたびに、自社顧客への通知と契約更新が必要になり、社内のデータ保管・監査要件も適用される。「もう1つ信頼できるデータベンダーを増やす」ことのコストは、技術的な話ではなく手続き的な話として重い。
EFS は、この問題を「監視をやめる」でも「保持をやめる」でもない方法で解きました。保存先を変えたのです。
監視に使う活動データを、Anthropic ではなく顧客が管理するクラウドインフラに保存する。 Amazon S3、Azure Blob Storage、Google Cloud Storage——顧客自身のアカウントに、顧客自身の暗号鍵とアクセスポリシーと監査ログのもとで保存されます。
そして、検知した signal は顧客側へ送られ、顧客自身のスタッフがレビューします。 Anthropic の人間がデータを見る経路を通さずに、悪用検知の枠組みだけを成立させる、という構成です。
Anthropic は、この設計を100社超の顧客と共同で作ったとしています。 金融・ヘルスケア・製造・通信・法務・小売・公共の各産業から。参加組織には、米大手銀行の CISO が集まる ARC(Analysis and Resilience Center for Systemic Risk) や、Comcast、KPMG、Mastercard、Salesforce、Visa が含まれます。クラウドパートナーの AWS / Google Cloud / Microsoft Azure とも協働しています。
EFS は3つの制御からなり、それぞれが個別のオプトインです。
(1) 顧客所有ストレージ。(2) 顧客管理の暗号鍵(CMEK)。(3) 完全自動レビュー——Anthropic の人間によるレビューを介さない監視。
必要なものだけを有効にできる、という設計です。そして重要なことに、いずれもモデルの挙動、API 価格、レート制限を変えません。
Anthropic は EFS 自体に課金しません。 顧客が自社クラウドへ保存する場合、そのストレージ・読み書き・エグレスの費用はクラウド事業者から顧客へ請求されます——通常のリソースと同じ扱いです。
提供は段階的で、2026年秋(fall)の広範提供が目標です。 EFS が使えるようになるまでの間、対象顧客は Fable 5 / Fable 5.1 でゼロデータ保持を受けられます。 つまり、EFS を待たずに今から使い始められる経路が用意されています。
ただし、注意すべき例外があります。非エンタープライズの購読者が Mythos クラスのモデルを使う場合、2026-06 のデータ保持ポリシーは引き続き適用されます。 EFS はエンタープライズ向けの解決であって、全利用者への適用ではありません。
何が変わったか
- Enterprise Frontier Safeguards(EFS)を発表。 監視用の活動データを顧客管理のクラウドインフラに保存する方式
- 3つの制御はそれぞれ個別のオプトイン: 顧客所有ストレージ / 顧客管理暗号鍵(CMEK) / 完全自動レビュー
- 保存先は Amazon S3、Azure Blob Storage、Google Cloud Storage の顧客アカウント。顧客自身の暗号鍵・アクセスポリシー・監査ログが適用される
- 検知 signal は顧客へ送られ、顧客のスタッフがレビューする(Anthropic の人間によるレビューを介さない選択肢)
- モデル挙動・API 価格・レート制限は変わらない
- Anthropic は EFS に課金しない。 顧客クラウドへの保存費用(ストレージ・読み書き・エグレス)はクラウド事業者から顧客へ請求
- 直接契約でもクラウド経由でも同等の制御。 AWS / Google Cloud / Microsoft Azure の利用者は同等の制御を受ける
- 対応面: Claude Code、Claude Enterprise、Claude Platform、Amazon Bedrock、Claude Platform on AWS、Google の Agent Platform、Microsoft Foundry
- 提供時期: 段階展開。2026年秋の広範提供が目標。 それまで対象顧客は Fable 5 / 5.1 でゼロデータ保持
- 例外: 非エンタープライズ購読者の Mythos クラス利用は 2026-06 のポリシーのまま
業務インパクト(一般企業向け)
まず、対象になる組織を明確にします。
2026-06 のデータ保持ポリシーを理由に、Fable / Mythos クラスの導入を止めていた組織——これが直接の対象です。金融、医療、法務、公共、その他の規制産業。「モデルの性能ではなく、データの扱いで止まっていた」ケースが該当します。
そういう組織にとって、再検討の条件が揃いました。 しかもEFS の完成を待つ必要がありません。 対象顧客は Fable 5 / 5.1 でゼロデータ保持を受けられるため、今から評価を始められます。
ただし、EFS を「導入すれば終わり」の機能と考えると失敗します。
EFS は、監視の責任を一部こちら側へ移す仕組みです。 検知した signal は顧客へ送られ、顧客自身のスタッフがレビューします。 これは裏返せば、**「レビューする人と手順を自社で用意する必要がある」**ということです。
ここは真剣に見積もってください。 誰が signal を見るのか。どのくらいの頻度で来るのか。判断基準は何か。エスカレーション先はどこか。インサイダーリスクの監視体制を持っている組織なら、その延長線上に置けます。 持っていない組織にとっては、新しい運用機能を1つ立ち上げる話になります。
Anthropic 自身も「企業は長らくインサイダーリスクの監視をしてきており、いまそれをエージェントへ拡張したいと考えている」と説明しています。 つまり EFS は、既存の監視体制がある組織を想定した設計です。
次に、ストレージ費用は自社負担になります。
EFS 自体は無料ですが、顧客クラウドへの保存費用は顧客持ちです。 ストレージだけでなく、読み書きとデータエグレスも掛かります。 活動データの量は利用量に比例するため、大規模に使うほど費用が効いてきます。 導入計画では、この費用を見積もりに含めてください。「無料」という言葉だけを持ち帰ると、後で数字が合いません。
そして、法務・調達との連携が必要です。
EFS の価値の大半は、「外部ベンダーにデータを預けなくてよくなる」という手続き上の利点です。 これが実際に効くかどうかは、自社の契約・通知・監査の要件がどう書かれているかによります。 技術部門だけで「これで解決」と判断できる話ではありません。
実務としては、EFS の3つの制御のうち、自社の要件を満たすのに必要なのはどれかを法務と一緒に確認するところから始めるべきです。3つとも有効にする必要はなく、個別のオプトインである設計はそのためにあります。
最後に、見落としやすい例外を強調しておきます。
非エンタープライズ購読者が Mythos クラスを使う場合、2026-06 のポリシーが続きます。 「Anthropic がデータ保持ポリシーを撤回した」という理解は誤りです。変わったのはエンタープライズ向けの提供方法であって、方針そのものではありません。 社内説明でここを混同すると、後で訂正が必要になります。
副業・個人活用視点
まず率直に言うと、EFS は個人利用者向けの機能ではありません。 エンタープライズ契約が前提で、申請フォーム経由の対象要件確認があります。
それでも、フリーランスや小規模事業者が知っておく価値は3つあります。
1つ目は、規制産業の顧客と仕事をするときの前提が変わったことです。
「Claude はデータ保持があるから使えない」と言われて提案が通らなかった案件が、この発表で条件を満たしうる状態になりました。顧客側がエンタープライズ契約を持っているなら、EFS を前提にした提案が組めます。
ただし、あなたが個人として使う Claude と、顧客のエンタープライズ環境の Claude は別物です。 ここを曖昧にして「Claude ならデータは安全です」と説明すると、後で契約条件を確認されたときに破綻します。 「顧客のエンタープライズ契約下では EFS が使える。私が個人で使う環境は別」——この区別を明示できることが、信頼につながります。
2つ目は、この設計自体が提案の型として学べることです。
「監視をやめる」でも「保持をやめる」でもなく、「保存先を変える」という解き方。 対立して見える2つの要求——安全性の担保とプライバシーの確保——を、どちらかを諦めるのではなく、構造を変えて両立させたわけです。
この型は、顧客との要件調整でそのまま使えます。 「A か B か」で膠着したとき、両者が本当に譲れないのは何かを分解すると、実は別の軸で解けることがある。 Anthropic が分解したのは「監視には時間軸とアカウント横断の観測が要る」と「顧客が譲れないのは第三者への預託である」の2つで、この2つは実は両立可能でした。
3つ目は、コストの構造を読む練習になることです。
「Anthropic は課金しない」が「無料ではない」。 クラウド事業者への支払いが発生します。提供元が無料と言っているものの総保有コストを計算する——これは受託の見積もりで頻繁に必要になる技能です。
顧客に「これは無料です」と説明されている機能について、「実際には誰にいくら掛かるか」を分解して見せられる人は重宝されます。ベンダーの言葉をそのまま運ばず、構造に分解して伝える。 これは EFS に限らず、この仕事の基本動作です。