Anthropicは2026年9月1日、Enterprise Frontier Safeguards（EFS）を発表しました。EFSは、ゼロデータ保持（ZDR）のプライバシーと、悪用を検知する安全策を組み合わせる仕組みです。データをAnthropicではなく、顧客が管理するクラウド基盤に保存し、複数のセッションやアカウントにまたがる活動を自動監視します。
企業のIT・事業責任者が見るべき点は、「Claudeを自社クラウドで動かす」発表ではないことです。EFSの中心は、監視に使う活動データの保存先、暗号鍵、アクセス制御、監査ログ、検知後のレビュー担当を顧客側で管理できるようにすることにあります。
背景には、Claude Fable 5／5.1などのCovered Modelsで、複数のやり取りを横断した悪用検知のため30日間の保持が必要になったことがあります。EFSは2026年秋後半から段階展開の予定で、対象顧客は提供時期、利用資格、保存とレビューの責任分界を確認して導入を判断します。
※本記事は2026年10月14日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
Enterprise Frontier Safeguardsとは｜顧客管理クラウドと自動安全監視を組み合わせる
EFSは、Anthropicが顧客データを保管し続ける方式と、入力・出力を保存しないZDRの中間を単純に作るものではありません。顧客が管理するクラウドアカウントに活動データを置き、Anthropicの自動安全監視で複数のセッションやアカウントを横断して異常なパターンを検知する設計です。
AnthropicはEFSを、100社を超える顧客とAmazon Web Services、Google Cloud、Microsoft Azureとの協力で開発しました。対応先としてClaude Code、Claude Enterprise、Claude Platform、Amazon Bedrock、Claude Platform on AWS、GoogleのAgent Platform、Microsoft Foundryを挙げています。
対象モデルの背景を押さえるには、Claude Fable 5.1とMythos 5.1の違いも役立ちます。EFSはモデルの性能を高める機能ではなく、高能力モデルを企業業務で扱うときの保存・監視・レビューの設計を変える機能です。
検知で注意すべきパターンが見つかると、シグナルは顧客へ直接送られます。顧客側の担当者が自社のルールに従ってレビューでき、Anthropic社員による人手レビューを必須にしない点が、EFSの大きな特徴です。
ポイント
EFSはモデルを自社クラウドで実行する仕組みではありません。顧客管理クラウドへの活動データ保存と、自動安全監視、顧客側のレビューを組み合わせる方式です。
なぜEFSが必要か｜30日保持で複数セッションの悪用を検知する
高能力モデルの悪用は、1回のリクエストだけでは判定できないことがあります。Anthropicは、複数のタスク、セッション、アカウントにまたがる活動を相関させなければ、盗難・漏えいした認証情報の兆候や自律的な不正動作を捉えにくいと説明しています。
このため、Fable 5から30日間のデータ保持を導入しました。Covered Modelsでは、プロンプトとモデルの出力を最低30日保持し、その後は自動削除します。安全性調査の対象になった場合や、法的に保持が必要な場合は例外です。
保持の目的は、企業データを学習することではありません。Anthropicは、明示的な許可なしに企業データを学習に使ったことはなく、今後も使わないと説明しています。保持期間と学習利用は別の論点として、契約と社内説明に分けて整理します。
入力・出力を保存しないことを重視する企業にとって、30日保持は受け入れにくい条件です。OpenAIのゼロデータリテンション拡充のような他社の設計と比べるときも、保存対象、悪用監視、例外、レビュー担当を同じ表に置く必要があります。
ポイント
「保存しない」と「複数の活動を横断して監視する」は別の要件です。企業は、機密性だけでなく、悪用検知に必要な保持期間とレビュー経路を分けて評価します。
EFSのデータ配置と制御｜暗号鍵・アクセス権・監査ログを顧客が管理
EFSでは、活動データを顧客のクラウドアカウントに保存できます。Anthropicが例として挙げる保存先はAmazon S3、Azure Blob Storage、Google Cloud Storageです。自社の既存クラウド環境を使うため、データ保管の契約先を増やさずに運用できる設計です。
顧客は自社の暗号鍵、アクセス制御、監査ログを使えます。顧客所有ストレージ、顧客管理暗号鍵、完全自動レビューはそれぞれオプトインです。必要な制御だけを有効にするため、セキュリティ要件と運用負担を機能ごとに見積もれます。
ここで管理者が決めるのは、バケットやコンテナの作成だけではありません。誰が鍵を使えるのか、検知シグナルに誰がアクセスするのか、監査ログをどの期間保管するのか、削除とインシデント対応をどのチームが担うのかまで定義します。非人間IDの権限管理と監視も、アクセス制御を設計する際の補助線になります。
EFSの制御を有効にしても、モデルの挙動、API料金、レート制限は変わりません。AnthropicはEFS自体の料金を請求しない一方、顧客クラウドに保存する場合は、クラウド事業者からストレージ、読み取り、書き込み、データ転送料が請求されます。
- 保存先：顧客アカウント内のストレージとアクセス経路を決める。
- 暗号鍵：鍵の発行、利用権限、ローテーション、失効を管理する。
- 監査：シグナルやデータへのアクセスを記録し、レビュー担当を限定する。
- 費用：保存、読み書き、データ転送と運用工数を試算する。
ポイント
顧客管理クラウドを選べても、責任がなくなるわけではありません。鍵、アクセス権、監査、削除、クラウド費用を自社の担当部署と結び付けて設計します。
EFSとZDRの違い｜標準30日保持も含めて3方式を比べる
企業が選ぶべき方式は、機密データを保存しないことだけで決まりません。標準の30日保持、対象契約で使えるZDR、顧客管理クラウドに監視データを置くEFSは、保持・監視・レビューの責任分界が異なります。
| 方式 | 保存・保持 | 悪用監視 | データ管理先 | 人手レビュー | 主な顧客負担 |
|---|---|---|---|---|---|
| 標準30日保持 | プロンプトと出力を最低30日保持し、その後自動削除 | 自動安全システムで評価 | 利用経路によりAnthropic、AWS、GCPなど異なる | 通常はAnthropic担当者が読めず、管理された経路で実施 | 契約・保持条件の確認 |
| ZDR | 対象製品・契約で入力と出力を保存しない | 安全性分類器の結果はUsage Policy執行のため保持 | 対象契約のデータ保持設定に従う | 法令遵守や悪用・危害対応の例外を含めて確認 | 対象組織・製品の適用条件を確認 |
| EFS | 顧客が管理するクラウド基盤に活動データを保存 | 複数セッション・アカウントを横断して自動監視 | 顧客のクラウドアカウント | シグナルを顧客へ送り、Anthropic社員の人手レビューを必須にしない | 鍵・権限・監査・レビューとクラウド費用を管理 |
ZDRはすべての製品、モデル、組織に自動適用される設定ではありません。対象となるAnthropic APIや商用組織のAPIキーを使う製品、Claude Code Enterpriseなど、契約と製品ごとの条件があります。Covered Modelsでは限定的な保持とレビューが必要になるため、モデル単位のポリシーも確認します。
EFSを選ぶ企業は、保存場所を自社側に置きながら、監視シグナルをどのチームが受けて判断するかを決めます。監視の設計と運用を考える際は、AgentOpsの可観測性・評価・監視で扱う、アラートを日々の業務へ接続する視点も参考になります。
ポイント
標準30日保持は利用経路に応じた保持先と管理条件で運用し、ZDRは保存しない設定を契約単位で適用します。EFSは顧客クラウド、鍵、レビュー体制を自社で管理する代わりに、運用と費用を引き受けます。
EFS導入の判断ポイント｜提供時期・費用・レビュー体制を先に確認
EFSは顧客へ段階的に展開され、広範な提供は2026年秋後半を目標としています。Anthropicの2026年10月6日のCyber Verification Program更新でも、EFSは「later this fall」に利用可能になる予定として扱われています。2026年10月14日時点で、全顧客が直ちに使える機能として判断する段階ではありません。
利用を検討する企業は、Anthropicまたはクラウド事業者からの案内、対象モデルと接続先、契約上の資格を確認します。AnthropicはEFSへのアクセスを申請するフォームを案内しているため、対象ワークロードと必要な制御を整理してから相談します。
費用はAPI料金だけでは測れません。EFS自体の追加料金はありませんが、顧客クラウドのストレージ、読み取り、書き込み、データ転送が別途発生します。監視シグナルを受けるセキュリティ担当、誤検知を判定するレビュー担当、監査記録を保つ管理者の工数も見積もります。
- 利用資格：対象モデル、製品、クラウド接続先、契約条件を確認する。
- 保存と鍵：顧客アカウント、暗号鍵、アクセス権、監査ログの所有者を決める。
- レビュー：自動検知のシグナルを受ける担当部署と、対応・エスカレーション手順を決める。
- 費用と削除：クラウド料金、運用工数、保存期間、削除、例外時の扱いを試算する。
最初から全社の会話を移す必要はありません。Covered Modelsを使う代表的なワークロードを一つ選び、保存データ、検知シグナル、レビュー時間、クラウド費用を測定します。その結果をZDRと標準30日保持の条件と並べれば、EFSへ移る効果と負担を同じ尺度で判断できます。
ポイント
導入前に、利用資格、保存と鍵、レビュー、費用と削除の4点を担当部署と決めます。小さなワークロードで測定してから、ZDR・標準30日保持・EFSを比較すると判断しやすくなります。
よくある質問
Q. AnthropicのEnterprise Frontier Safeguards（EFS）とは何ですか？
顧客が管理するクラウド基盤に活動データを保存し、複数セッション・アカウントを横断する自動安全監視と組み合わせる企業向けの保護方式です。
Q. EFSとゼロデータ保持（ZDR）は何が違いますか？
ZDRは対象製品・契約で入力と出力を保存しない方式です。EFSは顧客クラウドに活動データを置き、複数セッション・アカウントの悪用を自動監視する方式です。
Q. EFSのデータはどこに保存されますか？
顧客のクラウドアカウントに保存できます。例としてAmazon S3、Azure Blob Storage、Google Cloud Storageが挙げられており、顧客自身の暗号鍵、アクセス制御、監査ログを使えます。
Q. EFSはいつから、いくらで使えますか？
2026年10月14日時点では、2026年秋後半から段階展開する予定です。EFS自体の追加料金はありませんが、顧客クラウドのストレージ、読み書き、データ転送の費用は別途発生します。
まとめ
Enterprise Frontier Safeguardsは、Covered Modelsで求められる横断的な悪用監視と、企業が求める顧客管理クラウドでのデータ管理を組み合わせます。EFSをZDRの単純な強化版と捉えると、保存対象やレビュー責任を誤って設計します。
2026年10月14日時点では、2026年秋後半からの段階展開が予定されています。利用資格と対象製品を確認し、鍵、アクセス、監査、レビュー、クラウド費用を小さなワークロードで測定してから、標準30日保持やZDRと比較することが導入判断の出発点です。
ポイント
EFSの導入判断は、データの保存先だけでなく、監視の目的、レビュー担当、鍵と監査、クラウド費用まで含めて行います。ZDR・標準30日保持・EFSの違いを自社の要件表に落としてください。
関連記事
- Claude Fable 5.1とは？長時間エージェント作業と1Mコンテキストを解説
- AIエージェントの「封じ込め失敗」が相次ぐ理由を解説｜Anthropic・Googleの公表事案に学ぶ隔離設計
- MCPサーバーのセキュリティ実態を解説｜21000台超が露出・92%認証なしの点検ポイント
- Claudeのサンドボックス脱出事例を解説｜AIエージェントの封じ込めと供給網リスク
- AI事業者ガイドライン第1.2版を解説｜7原則と企業の運用ポイント
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。