Claudeの監視ログを顧客クラウドへ、EFSが解く保持の矛盾

米Anthropicは2026年9月1日、企業向けのEnterprise Frontier Safeguards（EFS）を発表した。Claudeの監視に使う活動データを顧客管理のクラウド環境へ保存し、複数のセッションやアカウントにまたがる深刻な不正利用を自動検知する仕組みで、Anthropicの発表 によると、提供は2026年秋後半から段階的に始まる予定だ。

EFSでは、保存、機械的な検知、フラグ後の人手確認を分離する。監視用データは顧客自身のAWS、Google Cloud、Microsoft Azure環境に置くことができ、検知結果は顧客へ直接送られ、Anthropic従業員による人手確認は必須ではない。ITmedia NEWSの報道 もこのデータフローと段階提供の状態を確認しており、2026年9月2日時点で全面提供済みの製品ではない。

保持をなくさず、保存場所を顧客側へ移す

EFSが対象とするのは、Anthropicが「activity data」と呼ぶ監視用の活動データだ。顧客はAmazon S3、Azure Blob Storage、Google Cloud Storageなど、自社のクラウドアカウント内へ保存できる。顧客管理の暗号鍵、アクセスポリシー、監査ログも利用できるため、保存データへのアクセスを既存の統制に組み込める。

ただし、EFSはデータを一切残さない仕組みではない。高度なサイバー攻撃や認証情報の不正利用は、一度のプロンプトではなく、複数の会話やアカウントに分散することがある。各やり取りを解析直後に破棄すると時間をまたぐ相関を捉えにくいため、一定期間のトラフィックを保持し、ローリングウィンドウとして自動解析する。

タイトルの「監視ログ」は、この活動データを簡潔に表したものだ。公開資料は、Claudeに関係するすべてのデータや一般的なシステムログが同じ保存先へ移るとは説明していない。保存対象となるフィールド、標準的な保持期間、削除単位も明らかにされておらず、対象範囲は今後の技術仕様を待つ必要がある。

自動検知と人手確認を別の主体が担う

データの保管先が顧客側へ移っても、検知機能まで顧客が構築するわけではない。EFSの自動システムは、複数セッションのトラフィックから、攻撃的なサイバー能力や生物学的能力の開発、盗難・漏えいした認証情報の利用を示す兆候を探す。注意が必要なパターンを検知すると、フラグを顧客へ直接送る。

フラグの内容を確認し、実際の不正利用か誤検知かを判断する人員は顧客側に置ける。Anthropic従業員による人手確認を必須にしないことで、特権的な法務資料、未公開情報、医薬品安全性報告など、閲覧者が厳しく制限される情報を顧客の権限体系内で扱えるようにする。

責任分界は、顧客がデータ、鍵、アクセス権とフラグ後の対応を管理し、Anthropicが自動検知機能を提供する形になる。ただし、自動検知が顧客ストレージをどの権限で読み出すのか、障害時にどのデータを再処理するのか、検知ロジックを顧客がどこまで監査できるのかは、公開資料だけでは確定できない。

ZDRと共通する狙い、異なる保持方法

EFSはデータを無保持にする通常のZDRと同一ではない。長期的なパターンを検知するため、活動データそのものは顧客環境に残る。一方、モデル提供者のストレージへ企業データを保持し続けないというプライバシー上の狙いは共通しており、Axiosの報道 はEFSを、ZDRに相当する保護と不正利用の監視を両立させる企業向け対策と位置付けている。

違いは、顧客側に管理すべき保存データが生じることだ。保持期間、アクセス権、監査、法的保全、削除に加え、フラグを誰が調査し、どの条件で利用停止や社内報告へ進むかも顧客の運用設計に委ねられる。ZDRからEFSへ移る企業にとっては、プライバシー要件だけでなく、保存とインシデント対応の責任も比較対象になる。

「データが外に出ない」と単純化するのも正確ではない。確認できるのは、監視用活動データを顧客管理のクラウドアカウントに保存できることだ。Claudeの推論処理を実行する場所や、自動検知がデータへアクセスする経路の全体まで顧客環境内に閉じるとは公表されていないため、データ所在地や越境移転を審査する際は保存場所と処理場所を区別する必要がある。

3社のクラウドに対応、保存費用は顧客負担

EFSはAWS、Google Cloud、Microsoft Azureを通じた利用でも同等の制御を提供する計画だ。対応予定の利用経路にはClaude Code、Claude Enterprise、Claude Platform、Amazon Bedrock、Claude Platform on AWS、GoogleのAgent Platform、Microsoft Foundryが含まれる。

顧客所有ストレージ、顧客管理暗号鍵、完全自動レビューはそれぞれオプトインで、必要な制御を個別に有効化できる。これらを有効にしても、モデルの挙動、API価格、レート制限は変わらないとしている。

AnthropicはEFS自体に追加料金を課さない。一方、顧客のクラウドアカウントで発生するストレージ、読み取り、書き込み、データ転送の料金は顧客負担となる。具体的な活動データ量や標準保持期間が未公表のため、現時点では総費用を算定できず、「EFSは追加料金なし」と「運用費用は発生し得る」を分けて捉える必要がある。

段階提供までに残る責任分界

Anthropicは金融、医療、製造、通信、法律、流通、公共部門などの100社超とEFSを共同設計したとしている。ただし、共同設計への参加は本番導入や一般提供の完了を意味しない。2026年秋後半から段階的に提供し、同年秋のうちに広く利用可能にすることが目標とされている。

公開情報から確認できる責任分界は次の通りだ。

• 顧客：クラウドアカウント、暗号鍵、アクセス権、監査ログ、クラウド利用料、フラグ後の人手確認と対応を管理する。
• Anthropic：時間とアカウントをまたぐ自動検知機能を提供し、注意が必要なフラグを顧客へ送る。
• クラウド事業者：顧客が選んだ保存基盤を提供し、保存、読み書き、データ転送の利用量に応じて課金する。

EFSが利用可能になるまでの移行措置として、適格な顧客はFable 5とFable 5.1をZDRで利用できる。ただし、適格性の基準、地域別の提供時期、通知のサービス水準、保持期間と保存フィールドの詳細は公表されていない。EFSは「監視には保持が必要だが、提供者による保持は避けたい」という矛盾に保存先と確認主体の分離で応えたものの、日本企業が導入日程や総費用を確定するには追加仕様が必要だ。