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は監視の一部です。本番変更、送信、削除などの高リスク操作には、最小権限、人の承認、停止手段、復旧手順が別途必要です。
参考資料
Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組みを実務で理解するための補足
実務で最初に確認すべきこと
「Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組み」の観点では、連携系の技術は、接続方法より先に「どのデータを読めるか」「どの操作を書き込めるか」「失敗時にどこで止めるか」を決めることが重要です。読み取り、下書き、確定処理を分離し、AIエージェントへ一度に広い権限を渡さない設計にします。RAG、MCP、API、Function Callingは目的が異なるため、業務要件に必要な最小構成から始めます。
導入手順
「Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組み」の観点では、現行業務を可視化し、必要な情報源を特定し、読み取りだけで試験し、評価ケースを作成してから書き込み系ツールを追加します。評価では最終回答だけでなく、検索結果、ツール選択、引数、実行結果を分けて確認します。
AIエージェントとの関係
「Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組み」の観点では、AIエージェントは、必要な情報を取得し、状況に応じてツールを選び、複数工程を進める上位の実行概念です。接続方式そのものをAIエージェントと呼ぶのではなく、業務全体のワークフローとして設計すると混乱を避けられます。
導入・利用前チェックリスト
- 情報の出典と更新日を確認する
- 自社データを扱う場合の保存・学習条件を確認する
- AIエージェントへ与える権限を最小化する
- 代表ケースで品質を評価する
- 失敗時に人へ引き継ぐ手順を決める
- モデルや仕様変更時に再評価する
Accomplirでは、AI、RAG、MCP、AIエージェント、FDE人材、DXを個別の流行語としてではなく、現場の業務を改善するための組み合わせとして扱います。導入内容がまだ固まっていない段階でも、現状業務と課題から整理できます。
Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組みを業務で活用するための実務整理
実務論点 1
「Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組み」では、連携技術の記事では、接続できることと業務上接続してよいことを分けて考えます。RAGは情報検索、APIやFunction Callingは決められた操作、MCPは共通接続、AIエージェントは複数工程を進める役割というように、技術ごとの責任範囲を整理すると実装判断がしやすくなります。
実務論点 2
「Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組み」では、本番環境では、検索・閲覧・下書き・確定・削除を一つの権限にまとめません。モデルが誤った判断をしても、ツール側の型検証、業務ルール、認可を越えられない構成にします。外部APIが失敗した時の再試行回数と、人へ引き継ぐ条件も先に定義します。
実務論点 3
「Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組み」では、評価では最終回答だけでなく、必要な文書が検索できたか、正しいツールを選んだか、引数が正しかったか、API結果を正しく解釈したかを分けて測ります。層別に測ることで、モデル変更が必要なのか、検索やツール定義を直すべきなのかを判断できます。
実務論点 4
「Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組み」では、複数システムをつなぐ場合は、顧客ID、商品コード、日付、金額などの共通データ定義も重要です。AIは曖昧さを補完してしまうため、マスタの表記揺れや古いデータがあると誤処理の原因になります。接続技術と同時にデータ品質を確認してください。
検証から本番運用まで
Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組みを実際の業務へ取り入れる場合は、対象業務を一つに絞り、現状の処理時間と失敗を記録し、代表ケースで小さく検証します。評価では、AIの文章の自然さだけでなく、必要情報の取得、根拠、操作の正確性、人の修正時間、1件あたり費用を確認します。十分なデータがない場合は、自動化範囲を広げず、まず情報整備を行います。
AIエージェント化する場合の確認
複数工程をAIエージェントへ任せる場合は、開始条件、完了条件、利用できるツール、禁止操作、最大実行時間、最大費用、人へ引き継ぐ条件を明文化します。モデルが高性能でも、権限と完了条件が曖昧なら安定運用できません。ツール側でも入力値と権限を検証し、モデルの指示だけで重要操作が確定しないようにします。
記事情報の更新方法
AI関連技術は更新が速いため、製品仕様、価格、提供地域、セキュリティ条件など変化しやすい項目は、公式情報で確認日を残します。更新時は古い記述を単純に削除するのではなく、何が変わったかを記録し、検索利用者が現在の状態を判断できるようにします。一次情報と実務上の解釈を分けることが、長期的な記事品質につながります。
業務導入チェック
- 対象業務と成果指標が明確か
- 利用するデータの正本と更新頻度が分かるか
- AIエージェントの権限が必要最小限か
- 失敗時に人へ戻せるか
- 代表ケースで再現性を測ったか
- 費用と人の確認時間を含めてROIを見ているか
- モデルや仕様更新時の再評価手順があるか
Anthropic EFSとは。ゼロデータ保持とAI不正利用監視を両立する仕組みの実務導入をさらに深掘りする
要件定義
連携技術では、接続可否だけでなく、データの正本、ツールの入出力スキーマ、認証方式、冪等性、再試行、タイムアウトまで確認します。AIエージェントが誤った引数を作っても、API側の検証と認可で重大操作を防げる構成が重要です。
要件書には、対象ユーザー、開始条件、入力データ、期待する成果物、完了条件、利用可能なツール、禁止操作、最大実行時間、最大費用、エラー時の処理、人の承認条件を記録します。「高精度に回答する」のような曖昧な要件ではなく、代表ケースで合否を判定できる形式にします。
評価設計
通常ケースだけでなく、情報不足、表記揺れ、古い文書、外部API失敗、権限外の依頼、悪意ある入力を含む評価セットを作ります。最終回答だけでなく、検索、ツール選択、引数、外部処理結果、人への引き継ぎを分けて評価すると、改善箇所を特定できます。
本番運用
本番では、起動者、利用モデル、主要なツール呼び出し、結果、承認、エラーを実行IDで追えるようにします。個人情報やAPIキーをログへ過剰保存しないようマスキングし、保持期間と閲覧権限を設定します。異常時に停止でき、手動運用へ戻せる手順も用意します。
コストとROI
モデル料金だけでなく、検索、ストレージ、外部API、インフラ、人のレビュー、保守を含めて1件あたり総コストを測ります。処理時間、手戻り、回答速度、売上機会、教育効果と比較し、十分な成果が出た工程だけ自動化範囲を広げます。
更新と再評価
AI分野ではモデル、価格、MCPサーバー、外部API、利用規約が変わります。変更時に固定評価セットを再実行し、品質、速度、安全性、費用が許容範囲か確認します。一次情報の確認日を残し、記事として公開する情報も定期的に更新します。
AIエージェント化の判断
単発の質問応答だけなら、必ずしもAIエージェントは必要ありません。複数工程をまたぎ、状況に応じて検索やツールを選び、途中状態を保持しながら完了まで進める業務で価値が出やすくなります。自律性を上げるほど権限・監査・評価も強くする必要があります。
導入チェックリスト
- 目的と業務KPIが決まっている
- 正本データと更新責任者が分かる
- 権限が必要最小限である
- 代表ケースと異常ケースで評価した
- 重要操作に承認または別認可がある
- ログから失敗原因を追える
- 停止・復旧・手動切替ができる
- モデルや仕様変更時に再評価できる