結論：ZDRという一語でなく、検知データの流れを確認する
Anthropicの公式発表によると、EFSは顧客が管理するクラウドインフラへ活動データを保存し、顧客の暗号鍵、アクセス方針、監査ログで管理できるようにする計画です。Amazon S3、Azure Blob Storage、Google Cloud Storageなどが例示されています。検知システムが重大な不正利用の兆候を見つけたとき、信号は顧客側へ渡り、顧客の担当者が確認します。
これは「Anthropicが何も処理しない」「自社クラウドなら自動的に安全」という意味ではありません。モデルへの入力・出力、監視用の活動データ、検知結果、レビュー記録、バックアップをデータフローとして分け、どこに誰がアクセスできるかを決める必要があります。一般的な入力情報の整理はClaude APIの個人情報とデータ扱い、企業全体の責任分界は企業セキュリティ確認も併読してください。
ZDR・従来の保持・EFSを比較する
| 観点 | ZDR | 30日保持を含む運用 | EFSの発表内容 |
|---|---|---|---|
| 主な目的 | 顧客データを保持しない構成 | 時間をまたぐ相関分析と安全監視 | 顧客管理保管と高度な自動監視の両立 |
| 保存先 | 契約・サービス条件で確認 | Anthropic側の保持条件を確認 | 顧客のクラウドインフラを想定 |
| 検知の見方 | 保持が少ない分、相関の範囲を確認 | 複数session・accountの兆候を分析 | 検知信号を顧客がレビュー |
| 人間レビュー | 契約・機能で確認 | 契約・機能で確認 | Anthropicの人間レビューを必須にせず顧客が確認する設計 |
| 導入判断 | 保持を最小化したい業務 | 安全監視を優先する業務 | 規制、保管、監視を同時に管理したい顧客 |
表の「EFSの発表内容」はサービス仕様の完成版や価格表ではありません。公式発表は段階展開を示しており、開始時期、対象モデル、契約条件、利用できるクラウド、ログの具体的な項目は公開直前にreadbackする必要があります。
導入前に行う9手順
- 対象モデル、Claude Code、Claude Enterprise、Claude Platform、各クラウド基盤を利用面ごとに一覧化します。
- 入力・出力、tool操作、セッション情報、監視データ、検知信号、レビュー記録を分類します。
- 各データに保持期間、削除者、バックアップ、リージョン、法的保全の条件を付けます。
- 顧客クラウドのアカウント、バケット、暗号鍵、IAM、ネットワーク境界を決めます。
- 検知シグナルを誰が見て、誤検知をどう解除し、重大な兆候を誰へ報告するかを決めます。
- Anthropic、顧客のセキュリティ部門、委託先の責任分界をRACIで記録します。
- 通常の利用ログと安全監視の活動データを同じ目的で再利用しないよう、目的とアクセス権を分離します。
- 削除、鍵の失効、インシデント時の保全、契約終了時の返却・消去をテストします。
- 段階展開の対象、開始時期、対応基盤、料金、利用条件を公式窓口で再確認してから小規模導入します。
最初から全社データを接続する必要はありません。影響が限定された検証用プロジェクトを選び、検知の精度を数値化するより、誰がどの証跡を見て、どの条件で処置するかを先に確認します。検知があっても、顧客側の担当者が判断・記録・停止をできなければ、保管場所を移しただけになります。
顧客クラウド保管で追加するチェック
顧客側に保存できることは、責任が消えることではありません。バケットの公開設定、クロスアカウントIAM、鍵のローテーション、アクセスログ、バックアップの複製先を確認します。監視データに入力本文や認証情報が含まれるなら、保存前のマスキング、検索権限、アラートの通知先を分けます。セキュリティチームだけでなく、法務、プライバシー、SOC、業務責任者が同じデータ分類を使うことが重要です。
特に「顧客がレビューする」と「誰でも顧客社内で見られる」は異なります。高機密の法務資料、非公開情報、薬の安全性報告などは、閲覧者を訓練・承認済みの担当者へ限定し、誤検知の解除理由も残します。既存のClaude Codeの監査ログと同じ考え方で、アラート自体だけでなく、確認者、判断、処置、例外を保存します。
提供開始前に公式readbackする項目
EFSはAnthropicのFable 5.1とMythos 5.1の説明や、利用する基盤の契約条件と切り離して判断できません。公式発表ではClaude Code、Claude Enterprise、Claude Platform、Amazon Bedrock、Claude Platform on AWS、GoogleのAgent Platform、Microsoft Foundryへの対応が示されていますが、すべての顧客が同日に利用できるとは記載されていません。
公開直前には、正式名称、対象モデル、ZDRの定義、保持期間、保存リージョン、鍵の所有者、Anthropicと顧客のレビュー範囲、価格、サポート窓口、終了時の消去を文書で確認します。EFSを「30日保持の代替」とだけ説明すると、検知用の活動データまで保持しないと誤解されます。事実、契約、社内判断を資料上で分けてください。
導入判断チェックリスト
- EFSは段階展開予定で、現在の一般提供と断定していない
- モデル入力・出力と監視用活動データを分類した
- 顧客クラウド、鍵、IAM、リージョン、バックアップを決めた
- 検知信号を確認する顧客側担当者と権限がある
- 自動検知、顧客レビュー、Anthropicの関与範囲を分けた
- 保持・削除・契約終了・インシデント保全をテストした
- Fable 5.1など対象モデルと基盤の条件を公式readbackした
- 価格、契約、利用開始時期を公開情報だけで推測していない
ZDRと安全監視は本来、単純な優劣ではありません。保持を最小化したい理由、相関検知が必要な脅威、顧客側の保管能力、レビューできる人員を同じ判断表に置いてください。無料診断では、データフロー、クラウド責任、監視、削除、例外の5層へ分解し、導入前の確認事項を整理します。
FAQ
- Enterprise Frontier Safeguardsはすぐ使えますか？
- 公式発表では段階的に展開され、開始は2026年秋の後半とされています。利用可能と断定せず、Anthropicや契約窓口へ確認します。
- EFSはデータを一切保存しませんか？
- EFSはZDRと顧客側インフラへの保存を組み合わせる構想です。監視に使う活動データの保存先、保持期間、鍵、閲覧者を契約と設計で確認します。
- EFS導入前の設計を相談できますか？
- できます。ログ、クラウド、暗号鍵、検知、レビュー、削除の責任分界を無料診断（60秒）で整理します。