Anthropicは2026年9月、企業向けの新しい安全機能「Enterprise Frontier Safeguards（EFS）」を発表しました。AIの入出力をモデル提供者側へ保存しないゼロデータ保持と、危険な利用を継続的に検知する仕組みを両立させる構想です。活動データを顧客自身のクラウドへ置き、判定結果を顧客側の担当者が確認する点に特徴があります。
従来、強い監視を行うにはプロンプトや回答をベンダーへ保存する必要があり、機密性を優先すると監視情報が減るという課題がありました。EFSはその二者択一を解消しようとするものです。ただし、発表時点では段階的な提供を予定する仕組みであり、導入するだけで安全管理が完成するわけではありません。本稿ではAnthropicの一次情報を基に、EFSの構成、ゼロデータ保持との関係、費用、導入時の確認事項を整理します。情報は2026年9月5日時点です。
Enterprise Frontier Safeguardsとは
EFSは、Claudeを業務で使う組織が、機密データの保管場所を自社管理下に置きながら、不正利用や危険な挙動を検知するための企業向け安全機能です。Anthropicは100社を超える顧客との検討を通じて設計したと説明しています。
対象として、Claude Code、Claude Enterprise、Claude Platformのほか、Amazon Bedrock、AWS上のClaude Platform、Google Agent Platform、Microsoft Foundryが挙げられています。複数の提供経路を横断する構想ですが、各環境で同時に同じ機能が利用できるとは限りません。利用開始時期、設定方法、対象地域は契約窓口で確認が必要です。
EFSが目指すのは、単発の禁止語検知ではありません。複数のセッションやアカウントをまたぐ一定期間の信号を分析し、通常と異なる行動や組織的な悪用の兆候を見つける考え方です。AIエージェントが長時間動き、複数ツールを扱う環境では、一回のリクエストだけでは見えない連続性が重要になります。
ゼロデータ保持と監視をどう両立するか
ゼロデータ保持は一般に、モデル提供者が顧客の入力や出力を長期保存しない契約・技術構成を指します。機密情報を扱う企業にとって重要ですが、保存しないだけでは、顧客環境内の不正操作や侵害されたアカウントを検知できません。
EFSでは、活動データを顧客が管理するクラウドストレージへ保存し、Anthropicが保有する中央ログへ寄せない構成が示されています。顧客管理鍵を利用でき、判定された項目の確認も顧客側の担当者が行います。Anthropicの人間による確認を必須にしないため、調査のために機密プロンプトを外部担当者へ開示する範囲を抑えられる可能性があります。
ここで注意したいのは、「保持されない」と「どこにも記録されない」は違うことです。EFSを利用すれば、監視のためのデータは顧客のクラウド側に残ります。さらに、認証基盤、端末、接続先ツール、プロキシ、業務システムにもログが存在します。情報管理では、保存の有無ではなく、どこへ何が保存され、誰が読め、いつ削除されるかを一覧化する必要があります。
従来のフィルターとの違い
入口で特定の語句を止めるフィルターは、明確な禁止内容には有効です。しかし、正当な表現に見える小さな操作を何度も組み合わせる攻撃、複数アカウントへ分散した行動、徐々に権限を広げる試みは、単発判定では見つけにくくなります。
EFSが説明するローリングウィンドウの信号分析は、時間をまたぐ行動パターンを見るためのものです。例えば、通常は少量のコード補助しか使わないアカウントが、短期間に大量の認証関連コードを調べ、複数の外部接続を試す場合、個々の質問が許可範囲でも全体として追加確認が必要かもしれません。
ただし、連続監視には誤検知があります。セキュリティ担当者の正当な検証が危険行動に見える場合もあります。判定を自動的な懲戒や契約停止へ直結させず、対象業務、利用者の役割、承認済み作業を踏まえて人が調査できる手順が必要です。
顧客管理クラウドがもたらす利点
顧客管理の保存領域を使うと、既存のクラウド統制へ監視データを組み込みやすくなります。保存地域、暗号鍵、アクセスログ、保持期間、バックアップ、削除を、自社の規程に合わせて設定できます。既存のSIEMやインシデント管理へ連携できれば、Claudeだけを別管理にせず、端末やID、ネットワークの情報と突き合わせられます。
一方で、管理責任も顧客側へ移ります。保存先バケットを誤公開する、鍵管理者が広すぎる、監査担当がログを確認しない、保持期間が無期限になるといった問題は、EFS自体では解決しません。クラウド設定のレビュー、アクセス権の定期棚卸し、削除の検証が必要です。
顧客管理鍵も万能ではありません。鍵の作成、保管、ローテーション、失効、復旧を誤れば、監視データを読めなくなったり、逆に不要な担当者が復号できたりします。鍵管理サービスの権限と、EFSデータの権限を同じ管理者へ集中させないことも検討します。
費用と提供時期
Anthropicは、EFS自体について追加のAnthropic利用料を課さない方針を発表しています。ただし、顧客クラウドにおけるストレージ、読み書き、データ転送などの費用はクラウド事業者から請求されます。ログ量、保存期間、リージョン間転送、分析頻度によって総費用が変わります。
「無償」という表現だけで予算をゼロにしてはいけません。導入作業、クラウド設定、SIEM連携、監視担当者の調査時間、誤検知対応、監査証跡の保管にも費用がかかります。概算時は、一日当たりのイベント数、イベント平均サイズ、保持日数、参照頻度を置いて試算します。
発表では、同年秋の後半から段階的に展開する方針が示されています。発表時点で全顧客が利用できる完成済み一般提供機能とは限りません。製品ロードマップを前提に本番日程を固定せず、利用可能になるまでの代替監視も用意します。
導入に適する組織
EFSは、ソースコード、顧客情報、研究データなどを扱い、モデル提供者側への保持を制限しながら、AI利用の監視も求められる組織に適しています。金融、医療、製造、公共、高度なソフトウェア開発など、機密性と安全性を同時に求める環境が候補です。
Claude Codeのような開発支援では、コードそのものだけでなく、ファイル名、リポジトリ構造、エラーログ、接続情報が機密になり得ます。ゼロデータ保持と顧客管理ログを組み合わせる価値があります。一方、公開情報の簡単な要約しか行わない小規模利用では、導入・運用負担が効果を上回る可能性があります。
適否は業界名ではなく、扱うデータと操作権限で判断します。文章案だけを返すチャットと、本番環境へ変更を加えるエージェントでは必要な監視が異なります。後者ほど、EFSに加えて実行前承認、許可コマンド、ネットワーク制限、変更のロールバックが必要です。
導入前に確認するデータフロー
最初に、利用者からモデル、接続先ツール、監視、保存、調査担当者までのデータフローを描きます。入力本文、出力本文、メタデータ、判定スコア、添付ファイル、ツール実行結果を分け、それぞれの保存場所と管理者を確認します。
次に、通常のClaude利用で何がAnthropic側に保持されず、EFS利用時に何が顧客クラウドへ書き込まれるかを契約文書で確認します。障害調査や不正利用対応の例外、サポートへ送る情報、バックアップ、削除要求の扱いも対象です。製品紹介ページの「ZDR」という略語だけで判断せず、自社の契約条件を基準にします。
最後に、監視アラートが出た後の流れを定めます。一次確認者、対象アカウントの一時停止権限、証拠保全、本人への確認、法務・人事への連携、復旧条件を明確にします。通知先が存在しない監視は、検知しても被害を減らせません。
誤検知と従業員監視への配慮
行動を横断的に分析する仕組みは、セキュリティだけでなく労務・プライバシーの論点を生みます。何を収集し、どの目的で分析し、誰が見られるかを利用者へ説明する必要があります。秘密の評価指標で従業員を順位付けしたり、文脈を確認せず不利益処分へ使ったりする運用は避けるべきです。
アラートには理由を残し、人が反証できる材料を提示します。業務上承認されたペネトレーションテスト、インシデント対応、研究が危険と判定された場合に、承認番号や作業時間を照合できる仕組みが有効です。監視担当者自身の閲覧も監査し、必要以上の本文を開かずに初期判断できる画面を検討します。
EFSだけでは解決しないこと
EFSは不正利用の監視を支援しますが、IDの安全、端末の防御、接続先APIの権限、生成コードのレビュー、バックアップまで代替しません。盗まれたクラウド管理者資格情報で監視設定を無効化されれば、顧客管理という利点が弱点へ変わります。多要素認証、条件付きアクセス、職務分離が必要です。
また、モデルの事実誤りや業務品質を測る製品評価基盤とも別です。危険な利用でなくても、誤った契約文、壊れたコード、不正確な分析は生じます。セキュリティ監視と品質評価を分けて設計し、双方の結果を運用責任者が確認します。
実装チェックリスト
導入前には、対象製品と提供地域、ZDRの契約範囲、保存データの項目、顧客クラウドのリージョン、暗号鍵、保持期間、削除方法を確認します。運用面では、アラート分類、一次対応時間、停止権限、誤検知の再審査、インシデント報告を決めます。
技術面では、ID連携、最小権限、監視設定を変更できる管理者、クラウド監査ログ、SIEM連携、データ転送費を確認します。検証環境で通常業務と疑似的な危険行動を再現し、検知率だけでなく誤検知率、調査時間、説明可能性を測ります。
まとめ
Enterprise Frontier Safeguardsは、モデル提供者側で入力・出力を保持しない考え方と、継続的な不正利用監視を両立させようとする仕組みです。活動データを顧客管理のクラウドへ置き、顧客側の担当者が確認する構成は、機密性を重視する企業に有力な選択肢となり得ます。
ただし、発表時点では段階展開の予定であり、クラウド費用、設定責任、誤検知、従業員への説明が残ります。EFSを一つの機能として導入するのではなく、ID、権限、承認、SIEM、インシデント対応を含む統制へ組み込むことが重要です。Accomplirでは、AIガバナンスと実装の双方から、データフロー整理、クラウド統制、監視・監査設計を支援しています。
よくある質問
EFSを使えばAnthropicがプロンプトを保存しませんか
EFSはゼロデータ保持と顧客管理ストレージを組み合わせる構想です。ただし、適用範囲や例外は契約と機能によって異なります。自社クラウドには監視用データが保存されるため、保持期間と権限の管理が必要です。
EFSの利用料は無料ですか
AnthropicはEFS自体に追加料金を課さない方針を示しています。一方、顧客クラウドの保存、読み書き、転送、運用担当者には費用が発生します。
Anthropicの担当者がすべてのアラートを確認しますか
発表された構成では、顧客側の担当者が確認し、Anthropicの人による本文確認を必須にしない設計です。具体的なサポート時の取り扱いは契約で確認してください。
EFSを入れればAIエージェントを無人運転できますか
できません。EFSは監視の一部です。本番変更、送信、削除などの高リスク操作には、最小権限、人の承認、停止手段、復旧手順が別途必要です。