Anthropic「EFS」徹底解説｜監視ログを自社クラウドに置くBYOC型AI

AIベンダーに自社の会話ログを預けるか、それとも最新モデルを諦めるか——規制業種の企業は、この二択をずっと突きつけられていましたのよ。

2026年9月1日（米国時間）、Anthropicが発表した Enterprise Frontier Safeguards（EFS） は、その二択を壊しにきた仕組みですわ。ひとことで言えば「監視に使う活動データを、Anthropicではなく顧客自身のクラウドアカウントに置く」。ゼロデータ保持（ZDR＝Zero Data Retention。AIベンダー側にプロンプトと応答を保存させない取り決めですわ）のプライバシーを保ったまま、誤用検知だけは回し続ける、という設計ですの。

ふん、これ、聞いた瞬間に既視感がありませんこと？ そう、Databricksが10年近く前から採用し、2018年のAzure Databricksにも受け継がれた「コントロールプレーンとコンピュートプレーンの分離」、いわゆる BYOC（Bring Your Own Cloud）とまったく同じ発想ですわ。この記事では、EFSの中身を一次情報で正確に押さえたうえで、BYOCアーキテクチャの系譜のどこに位置するのか、そしてどこまでが「独自ホスティング」でどこからが違うのかを、はっきりさせますわね。

EFS（Enterprise Frontier Safeguards）とは何か

#

Anthropicの公式発表を要約すると、EFSは次の3点に尽きますわ。

1. 監視用の活動データを、顧客自身のクラウドアカウントに保存する（Amazon S3、Azure Blob Storage、Google Cloud Storage など）
2. 暗号鍵・アクセスポリシー・監査ログは顧客が握る
3. 自動監視で検知したフラグは顧客に直接届き、Anthropic従業員による人手のレビューは不要

なお、Anthropicは同じ日に新フロンティアモデル Claude Fable 5.1 と Mythos 5.1 も発表していますの。能力が上がるほど誤用と自律的な逸脱のリスクも上がる——EFSはその裏返しとして、同時に出す必要があった仕組みですわ。

提供開始は2026年秋から段階的で、秋のうちの広範提供を目指すとしていますわ。EFSが整うまでの間、対象顧客は Claude Fable 5 と Fable 5.1 を ZDRのまま利用できる経過措置も用意されていますの。

対応する提供形態は、Claude Code、Claude Enterprise、Claude Platform、Amazon Bedrock、Claude Platform on AWS、GoogleのAgent Platform、Microsoft Foundry。AWS・Google Cloud・Microsoft Azure 経由でも同等の制御が効くと明記されている点は、後で効いてきますので覚えておいてくださいまし。

そして料金。AnthropicはEFS自体に課金しません。ただし顧客が自社クラウドにデータを置く以上、ストレージ料金・読み書き・データ転送（エグレス）料金はクラウド事業者から請求されますわ。タダではなく、「支払い先が変わる」だけですのよ。ここ、地味ですけれど本質ですわ。

そもそも「ZDR（ゼロデータ保持）」とは何か

#

ここまで何度も出てきた ZDR。この記事の全部がこの言葉に懸かっていますので、Anthropicの公式ドキュメントにもとづいて正確に押さえておきましょうね。

定義：APIが応答を返した後、中身を保存しない

#

ZDR（Zero Data Retention／ゼロデータ保持） とは、Anthropicの表現をそのまま借りれば「APIの応答が返された後、顧客のプロンプトとレスポンスを保存された状態で保持しない」という取り決めですわ。

普通のクラウドサービスは、障害調査や機能提供のためにログを残しますわよね。ZDRはそれを契約レベルで止めるものですの。金融機関や医療機関が「顧客情報を外部ベンダーのサーバーに残せない」という規制を負っているときに、これがないとそもそも導入審査を通りませんのよ。

「完全に何も残らない」わけではございません

#

ここが誤解されやすいところですわ。ZDRでも、次のものは残りますの。

• 利用ポリシー執行のため、安全性分類器の判定結果は保持されます（Anthropicの privacy ドキュメントに明記）
• 法令遵守や、誤用・危害への対処に必要な場合は例外として保存されます
• フラグが立った内容、法的な保存義務（リーガルホールド）がかかった内容も対象外ですわ

つまりZDRは「中身は残さないが、危険信号が出たという事実は残す」という設計ですの。ここを理解しておくと、EFSが「ZDRの発展形」として出てきた理屈がすっきり見えますわ。

誰でも使えるものではありません

#

ZDRは設定画面のチェックボックスではございませんのよ。

• Anthropicの承認が必要で、営業チーム経由で申請しますわ
• 組織単位で有効化されます。同じアカウント配下でも、新しい組織を作ったらその組織ごとに個別の有効化が必要ですの
• 適用されているかは Claude Platform の 設定 → プライバシー管理 → データ保持期間 で確認できますわ

ZDRが「効く範囲」と「効かない範囲」

#

これも公式ドキュメントに一覧がありますの。実務では、ここを取り違えると事故になりますわ。

ZDRが適用されるもの

• Claude の Messages API / Token Counting API（対象機能に限る。コード実行などは対象外）
• Claude Code（商用組織のAPIキー利用時、またはZDR有効なClaude Enterprise経由）
• Claude Platform on AWS（要申請）

ZDRが適用されないもの

• Claude Console での利用全般（プレイグラウンドを含む）
• 個人向けプラン（Free / Pro / Max。Web・デスクトップ・モバイル・Claude Code を含む）
• Claude Teams / Claude Enterprise の製品インターフェース（ZDR有効なClaude Codeのみ例外）
• Claude Managed Agents（セッション記録は削除するまで残ります）、Claude for Excel
• サードパーティの連携先で処理されたデータ
• ZDR組織では CORS が使えません（ブラウザから直接叩けず、バックエンド経由にする必要あり）
• Claude Code でメトリクスログを有効にしている場合、利用統計などの生産性データはZDRの対象外ですわ

そして今回の核心

#

公式ドキュメントには、こう書かれていますの。

Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5：これらのモデルは30日間のデータ保持を必要とし、Anthropicが明示的に承認しない限り、ZDRでは利用できない。

——これが今回の騒動の正体ですわ。「ZDRを結んでいる」ことと「最新のフロンティアモデルを使う」ことが、制度上まっすぐ衝突していたんですのよ。その衝突を解くために出てきたのが、経過措置としての「明示的な承認」と、恒久解としてのEFS、というわけですわ。

なお、Anthropicがデータ処理者となるのは Claude API、Claude Platform on AWS、Microsoft Foundry 経由のとき。Amazon Bedrock と Google Cloud Agent Platform では、クラウド事業者側がデータ処理者になりますから、同等の管理策はそれぞれのプラットフォームのドキュメントを確認する必要がございますわ。

ついでに、この記事の用語ミニ辞典

#

なぜ「30日間のデータ保持」が必要だったのか

#

そもそもの発端は、2026年6月のClaude Fable 5 / Mythos 5 の投入と同時に導入された、30日間のデータ保持ポリシーですわ。

Anthropicの説明は技術的に一貫していますの。高度な誤用は、複数のセッションと複数のアカウントにまたがって行われる。だから1回のやり取りを個別に解析して即座に破棄する方式では、検知が成立しないのですわ。

考えてみてくださいまし。攻撃者が「offensiveな攻撃コードを書いて」と1回で頼めば、当然ブロックされますわ。でも、

• アカウントAで「このネットワークプロトコルの仕様を教えて」
• アカウントBで「このバッファ処理の境界チェックを分析して」
• アカウントCで「このコードを最適化して」

——と分割すれば、1回ごとには全部まっとうな質問ですのよ。時間とアカウントをまたいで相関を取って初めて、輪郭が浮かび上がる。そのためには一定期間データを保存するしかない、というのがAnthropicの論理ですわ。

同社は「このポリシーは企業データで学習したいという動機によるものではない」「明示的な許可なく企業データを学習に使ったことはないし、今後もしない」と重ねて説明していますの。

それでも、金融・医療・法務といった規制業種からは「保持のあるモデルは使えない」という声が上がりましたわ。CNBCによれば、Anthropicのアメリカ地域責任者 Kate Jensen 氏は、顧客と数百時間を費やして代替案を設計したと述べていますの。EFSはその折衷案ですわ。

そして、ここが多くの解説記事が取り違えているポイントですわ。この30日保持は「全ユーザーが対象になった新ルール」ではございませんの。詳しくは次の章で、経路ごとに切り分けますわね。

【重要】経路別に見る「Fable利用への影響」

#

ここが本記事で一番実務的な章ですわ。Anthropicのヘルプセンター「対象モデル（Covered Models）」および「対象モデルのデータ保持慣行」を読むと、影響範囲は経路によってまったく違うことが分かりますの。

まず「対象モデル」の定義から

#

Anthropicは能力が一定の閾値を超えたモデルを Covered Models（対象モデル） に指定し、通常より厳しいデータ取扱いを適用しますわ。現時点の指定は4つですの。

面白いのは、Fable と Mythos は同じ土台のモデルだということですわ。Anthropicいわく「Claude Fable 5 と Fable 5.1 は Claude Mythos 5 / 5.1 と同じ基盤モデルを共有し、そこに追加の安全策——特にサイバーと生物分野——を載せたもの」。だからこそ Fable は広く配れて、Mythos は承認済みパートナー限定なんですのね。

そして重要なのが、これらのポリシーは「提供されているすべてのプラットフォームで」適用されるという一文ですわ。具体的には Claude アプリ、Claude Platform、Amazon Bedrock、Google Cloud Agent Platform、Microsoft Foundry。「Bedrock経由だから対象外」ということはございませんの。

経路別の影響一覧

#

そのうえで、実際に何かが変わるのは「もともとZDRだった人」だけですのよ。

つまり——**「ZDR契約を持っていたからこそ、今回の変更に巻き込まれた」**という、少し皮肉な構図ですわ。ZDRを結んでいなかった大多数の企業には、そもそも何も起きていませんのよ。

経過措置とEFSへの橋渡し

#

Anthropicは、対象となる組織に対して Fable 5 / 5.1 を ZDR のまま使える経過措置 を用意していますわ。ただし条件が2つ付きますの。

1. 自社の社内業務アプリケーション向けに限定される
2. 期間限定であり、EFSへの移行のための橋渡しと位置づけられている

該当する組織にはAnthropicまたはクラウド事業者から直接連絡が行きますわ。連絡が来ていなくても、申請フォームから検討を依頼できますの。

サードパーティ製品については「Claude上に構築された一部の製品は、Anthropicと合意した条件のもとで、自社の適格な法人顧客にZDRオプションを拡張できる」「対応製品は今後広げていく」とされていますわ。お使いのAIコーディングツールやSaaSがこれに該当するかは、そのベンダーに直接確認するしかございませんの。

見落としてはいけない但し書き

#

そして、これが一番大事ですわ。Anthropicははっきりこう書いていますの。

この取り決めが影響するのは、保存されたデータの保持とレビューのみである。利用ポリシー、リアルタイムの安全性分類器、およびAnthropicの執行システムは、すべてのトラフィックに引き続き適用される。

つまり——ZDRだろうとEFSだろうと、リアルタイムの安全性分類器からは逃れられませんのよ。変わるのは「保存して後から相関を取る」部分だけ。しかもAnthropicは「誤用への対応を含め、この取り決めを変更または撤回することがある」とも明記していますわ。

「EFSを入れればAnthropicの監視が外れる」という理解は完全な誤りですの。むしろ逆で、監視は続いたまま、その材料の置き場所と、フラグを見る人間だけが顧客側に移る——それがEFSの正体ですわ。

保持されている30日間、中身は誰に見られるのか

#

なお、現行の30日保持についても、Anthropicは保護策を公開していますわ。

• 既定ではAnthropicの従業員は保持された会話を読めない
• 人手のレビューは、自動の信頼性・安全性システムがフラグを立てた場合など、管理された経路でのみ発生する
• レビューできるのは承認された少数の担当者に限られる
• アクセスは改ざん不能なログに記録され、レビュー担当者が消したり書き換えたりできない
• 30日経過後は自動削除。ただしフラグが立った場合と法的保存義務がある場合を除く
• 適格な組織は顧客管理暗号鍵とアクセス透明性監査ログを追加できる（EFSを待たずとも今日から）

ここまで公開したうえで、なお「それでも自社の環境に置きたい」という要求に応えたのがEFSですわ。規制業種の要求水準の高さが窺えますわね。

「100社超が設計に参加」の中身が異常

#

EFSの説得力は、設計プロセスの参加者リストにありますわ。ここは盛っている話ではなく、Anthropicが実名を出していますの。

参加した業界団体は ARC（Analysis and Resilience Center for Systemic Risk）。メンバーには Goldman Sachs、Morgan Stanley、Citi、Bank of America、Wells Fargo といった米大手銀行のCISO（最高情報セキュリティ責任者）が名を連ねていますわ。加えて Comcast、KPMG、Mastercard、Salesforce、Visa。

Anthropicいわく、対話は「Fortune 100の4分の1、米国のすべてのグローバルなシステム上重要な銀行（G-SIB）、そして事実上すべての規制業種」に及んだとのこと。

Wells Fargo のコメントが、この仕組みの本質を一番端的に言い表していますわ。

ログはWells管理の環境に、Wells管理の鍵の下で留まる。我々がデータの管理権を持ち、Anthropicが検知を運用する。この分離こそが、我々のチームがフロンティアモデルを安全に使い、顧客・従業員・規制当局への義務を果たすことを可能にする。

「データの管理権（custody）」と「検知の運用（operation）」を分離する——これがEFSの設計思想ですわ。そして、この分離こそが次の章で見るBYOCアーキテクチャそのものですのよ。

Stripe は「Stripe の AWS 環境に会話ログを保持したまま対象モデルを使える」、Snowflake は「データは顧客の環境に、顧客が管理する鍵の下で留まる」と述べていますわ。Cognition や Factory といったコーディングエージェント系の企業も並んでいて、エージェントがproduction環境で本物の仕事をする時代の前提条件として位置づけられていますわね。

Azure Databricks型BYOCとの比較：これは新発明ではない

#

さて、ここからが本題ですわ。EFSは、データ基盤の世界では既に枯れたアーキテクチャの、AI推論への移植ですのよ。

Azure Databricksの二平面構造

#

Microsoft Learn の公式ドキュメントによれば、Azure Databricks は コントロールプレーンとコンピュートプレーンで動作しますわ。

• コントロールプレーン：Databricksが自社アカウントで管理するバックエンドサービス群。Webアプリケーション、ジョブスケジューラ、認証・認可などがここ。顧客のクラウドアカウントではなく、Databricks側にある
• クラシックコンピュートプレーン：計算リソースが顧客のAzureサブスクリプション内に置かれる。ワークスペースストレージアカウントも顧客のサブスクリプション内
• サーバーレスコンピュートプレーン：計算リソースがDatabricks側のアカウント内で動く（こちらは従来型SaaSに近い）

つまりクラシック構成では、**「頭脳（制御ロジック）はベンダー、身体（データと計算）は顧客」**という分業になっているわけですわ。

EFSに当てはめると

#

EFSの構造を同じ言葉で書き直すと、驚くほどきれいに対応しますの。

※Databricks側の記述はアーキテクチャの一般的な整理、EFS側はAnthropic公式およびITmediaの図解にもとづきますわ。

ITmediaが掲載したAnthropicの図の説明によれば、Anthropicが受け取るのは「アラートの分類と深刻度」だけ。生ログそのものは戻ってきませんの。

ただし対応関係は概念レベルでの相似であって、細部まで同じではございませんわ。Databricksのコントロールプレーンはノートブックやジョブ設定といった成果物も保持しますから、「ベンダー側には一切データが渡らない」わけではありませんの。EFSのほうが、ベンダーに戻る情報を絞り込んだ設計になっていますわ。

BYOCの一般論と、その落とし穴

#

Confluent の解説が、BYOCの構造と危うさをよく整理していますわ。BYOCとは「ベンダーのソフトウェアを顧客のクラウド環境（典型的には顧客のVPC）にデプロイし、データは顧客のクラウド環境に留まる」モデルですの。データ主権や、データがVPCから出ることを禁じるコンプライアンス要件を満たせるのが利点ですわ。

一方で、ConfluentはBYOCによくある欠陥をはっきり指摘していますのよ。

ほとんどのBYOCソリューションの共通した欠陥は、監視やトラブルシューティングのためにベンダーの権限を顧客のVPCとデータに対して許してしまうことだ。これはBYOCが約束するデータ主権を根本から損なう。

そして、責任分界点が曖昧になること。SaaSなら責任はベンダーに一元化されますが、BYOCでは顧客・クラウド事業者・ベンダーの三者で共有され、障害時に誰の責任か分かりにくくなるというトレードオフを負いますわ。

EFSはこの落とし穴を、かなり意識的に避けている設計に見えますの。「Anthropic従業員による人手のレビューは不要」「フラグは顧客に直接送られる」「Anthropicが受け取るのはアラートの分類と深刻度のみ」——これらは全部、ベンダーが顧客のデータ領域を覗く経路を作らないという宣言ですわ。理屈は通っています。

ただし、運用負荷は顧客に移りますのよ。フラグが上がったあと、それを見て判断するのは顧客のセキュリティチームですわ。「AIベンダーが勝手に不正利用を止めてくれる」世界から、「自社のSOCがAIエージェントの挙動も監視対象に加える」世界への移行ですの。これは間違いなくコストですわ。規制業種にとっては、そのコストを払ってでも欲しかった管理権、ということですけれど。

「独自ホスティング」の4類型：EFSはどこに位置するのか

#

「独自ホスティング」という言葉は曖昧すぎて、議論が噛み合わなくなる元凶ですわ。整理しておきますわね。

① フルマネージドSaaS（従来型） モデルもデータもベンダー側。Claude.ai や通常のAPI利用がこれ。楽ですが、データはベンダーの管理下に置かれますわ。

② 顧客管理鍵（CMK）付きSaaS データはベンダー側に置かれるが、暗号鍵は顧客が握る。ベンダーは鍵の複製を持たないため、原理的に中身を読めませんの。OpenAIが開発中と表明している「OpenAI側ストレージ＋顧客管理鍵」のオプションがこれですわ。

③ BYOC（Bring Your Own Cloud）← EFSはここ データは顧客のクラウドアカウントに置かれ、鍵もアクセスポリシーも監査ログも顧客管理。ただし処理ロジック（モデル推論・検知）はベンダーが運用する。Azure Databricksのクラシック構成、Snowflake Openflow の BYOC 展開、ClickHouse Cloud BYOC、Confluent/WarpStream などと同じ層ですわ。

④ 完全な自己ホスト（オンプレミス） ソフトウェア（モデルの重み）そのものを自社のハードウェアやクラウドに置き、運用も自社。Anthropicは公開されている提供形態のなかでClaudeの重みを顧客に配布していませんから、この選択肢は用意されていませんの。この選択肢を本気で取るなら、Llama系・Mistral系・DeepSeek系などのオープンウェイトモデルを自社GPUで回す道になりますわ。

ここを間違えてはいけません

#

つまり——EFSは「Claudeを自社サーバーで動かせるようになった」話では、まったくございませんのよ。

推論そのものは、引き続きAnthropicもしくはクラウドパートナー（AWS・Google Cloud・Azure）の基盤で動きますわ。顧客のクラウドに移るのは、あくまで「監視のために保存される活動データ」。プロンプトと応答の内容がそこに含まれるとはいえ、モデル本体が移設されるわけではございません。

この区別は投資判断にも直結しますの。「Anthropicがオンプレ提供を始めた＝クラウドGPU需要が減る」という読みは誤りですわ。むしろ逆で、推論はクラウドに残したまま、ストレージ・エグレス・監査基盤という新しい課金レイヤーがクラウド事業者側に増える構図ですのよ。

EFSでも解決しない3つの論点

#

一次情報を読み込んだうえで、率直に「まだ埋まっていない穴」も書いておきますわ。褒めるだけの記事に価値はございませんもの。

1. 検知ロジックはブラックボックスのまま データは顧客側に来ますが、「何を異常と判定するか」の検知ロジックはAnthropicのものですわ。誤検知が出たときに、顧客側でその判定根拠をどこまで検証できるのかは、現時点の公開情報では読み取れませんの。規制当局への説明責任を負う金融機関にとっては、ここが次の交渉ポイントになるはずですわ。

2. 運用コストは顧客持ち EFS自体は無料でも、ストレージ・読み書き・エグレスは顧客のクラウド請求書に乗りますわ。エージェントが長時間タスクを回す時代のログ量は、決して小さくございません。「無料」の見出しに釣られず、自社の想定トークン量からログ容量を見積もるべきですのよ。

3. アラート後の一次対応が自社の仕事になる 人手レビューがAnthropic側から消えるということは、その負荷が自社SOCに来るということですわ。セキュリティ人材が薄い企業にとっては、これは機能ではなく宿題ですの。KPMGのような監査法人・コンサルが設計に加わっている理由も、そのあたりにありそうですわね。

OpenAI「Private Safety Processing」との比較

#

同じ問題に、OpenAIも2026年8月に手を打っていますわ。Private Safety Processing（プレビュー）ですの。

構造は似ていて、しかし少し違いますわ。

• 共通点：単一のやり取りではなく、関連する複数のやり取りを横断してパターンを検知する。人間が中身を見ずに、自動システムが限定的な安全シグナルだけを返す
• 相違点：OpenAIは「顧客が管理するインフラに置く（ZDRデプロイ）」に加えて、「OpenAI側ストレージに置き、顧客管理の鍵で暗号化する」オプションも開発中と明言していますわ。前述の分類でいう ② CMK付きSaaS と ③ BYOC の両輪ですのね
• 開示の温度差：OpenAIは9月中のロールアウト開始と技術ホワイトペーパーの公開を予告。Anthropicは秋の段階的提供で、現時点で技術ホワイトペーパーの予告はございませんわ

Anthropicは「顧客のクラウドに置く」一点に賭け、OpenAIは選択肢を2つ用意した——今のところは、そう読めますわ。どちらが優れているかは、規制当局と監査法人がどちらを「説明しやすい」と判断するかで決まりますの。技術ではなく、コンプライアンスの土俵で勝負が決まる領域ですわね。

なお、OpenAIの発表が2026年8月19〜20日、Anthropicが9月1日。わずか2週間の間に最大手2社が同じ問題へ回答を出したという事実そのものが重要ですわ。フロンティアAIの企業導入において、データガバナンスが最大の非機能要件になったという、業界全体の合意が形成されつつあるということですのよ。

投資テーマとして読むとどうなるか

#

さて、rozenmaier.com らしく、ここからは資産の話ですわ。EFSは3つの方向に効きますの。

① クラウド3社に新しい課金レイヤーが増える ログは S3 / Azure Blob / GCS に積まれ、読み書きとエグレスが課金されますわ。1社あたりの金額は小さくとも、Fortune 100の4分の1が対象になれば話が変わりますの。ただしAnthropicは監視について「トラフィックのローリングウィンドウを解析する」と書いていますから、ログが無限に積み上がるわけではございませんの。一定量で頭打ちになる代わりに、使い続ける限り消えない固定費——そう捉えるのが正確ですわ。AIブームの恩恵が推論GPUだけでなくストレージ層にも降りてくる、というのはデータセンター関連の投資テーマを考えるうえで見逃せない論点ですわ。

② データガバナンス／セキュリティ銘柄の追い風 「AIエージェントの活動ログを自社で保管し、フラグを自社で捌く」というワークフローは、そのままSIEM・DSPM・データカタログの守備範囲ですわ。設計にSnowflakeやSalesforceが参加しているのも偶然ではございません。この領域は以前 データガバナンスとAI-TRiSMの記事で整理しましたけれど、EFSはその需要を制度的に裏書きした形ですわね。Snowflakeの事業構造やDatabricksのレイクハウス戦略を見てきた方なら、この「二平面アーキテクチャが標準になる」流れの意味はお分かりのはずですわ。

③ Anthropic自身の企業価値 CNBCは、Anthropicが売上の大半を法人向けで稼いでいること、そして大型IPOが広く予想されていることに触れていますわ。規制業種という最も硬い市場の扉をこじ開ける鍵がEFS、という位置づけですの。Jensen氏は、この発表後に「最も機微なワークロード」での導入加速に「非常に自信がある」と語っていますわ。

もっとも、これは未上場企業の話ですから、個人投資家が直接乗る手段は限られますのよ。現実的には、クラウド3社と、エンタープライズAIセキュリティの周辺銘柄を通じた間接的なエクスポージャーになりますわね。「本命が買えないときに、その周りで着実に需要が伸びるものを探す」——ツルハシ投資の基本形ですわ。

日本企業・個人が今チェックすべきこと

#

最後に実務の話をしますわ。

法人でClaudeを使っている場合 自社の契約形態を確認してくださいまし。EFSの対象は Claude Code / Claude Enterprise / Claude Platform / Amazon Bedrock / Claude Platform on AWS / Google Agent Platform / Microsoft Foundry ですわ。Bedrock経由やAzure経由でも同等の制御が受けられると明記されていますから、既にクラウド経由で使っている企業ほど移行は楽なはずですの。アクセス申請はAnthropicのフォームから行いますわ。

3つのオプトインは個別に選べます 顧客所有ストレージ・顧客管理暗号鍵・完全自動レビューは、それぞれ独立してオプトインですのよ。全部入れる必要はございません。しかもどれもモデルの挙動・API料金・レート制限には影響しないと明記されていますわ。まずは自社の規制要件に照らして、必要なものだけ有効にするのが賢いやり方ですわね。

個人のClaude利用者 繰り返しますが、個人プラン（Free / Pro / Max）は今回の変更の対象外ですわ。理由は「もともと入出力を保持しているから」であって、「保護が手厚いから」ではございませんの。そしてEFSも法人向けですから、個人は今回の話でプライバシー面の恩恵を受けません。「EFSが出たから個人も安心」は勘違いですのよ。

そして、ログ量の見積もりを今のうちに EFSを入れる／入れないに関わらず、自社のAIエージェントが1日にどれだけのトークンを消費しているかは把握しておくべきですわ。それが分からないと、顧客クラウドに置いたときのストレージ費用も、SOCに来るアラート量も、まったく見積もれませんもの。

まとめ：これは「AIの信頼」を巡るアーキテクチャ戦争ですわ

#

整理しますわね。

• EFS＝監視用の活動データを顧客のクラウドに置き、鍵も監査ログも顧客が握る仕組み。2026年秋から段階的提供、Anthropicは課金しない
• Anthropicが受け取るのはアラートの分類と深刻度のみ。人手レビューは顧客側で完結する
• アーキテクチャとしてはAzure Databricks型のBYOCそのもの。コントロールプレーンはベンダー、データプレーンは顧客
• 「Claudeをオンプレで動かせる」話ではない。推論はクラウドに残る。移るのはログだけ
• 30日保持で実際に影響を受けたのは「もともとZDRだった組織」だけ。Bedrock・Google Cloud Agent Platform・Microsoft Foundry経由も対象。個人プランとZDRでない商用契約は変更なし
• ZDRでもEFSでもリアルタイムの安全性分類器と利用ポリシーは全トラフィックに適用され続ける。監視が外れるわけではない
• ストレージ・エグレス・SOC運用というコストは顧客に移る。「無料」は支払い先が変わっただけ
• OpenAIも約2週間前に同じ問題へ着手（8月19〜20日）。データガバナンスがフロンティアAI導入の最大の非機能要件になった

ふん、正直に申し上げますとね。技術的には新発明ではございませんのよ。データ基盤の世界が10年かけて到達した二平面アーキテクチャを、AI推論の監視レイヤーに持ち込んだだけですわ。

でも、それが「だけ」で済む話ではないのですの。世界最大級の銀行のCISOたちが揃って設計に参加し、実名で「これなら使える」と言った——この事実の重みは、技術の新規性とは別のところにありますわ。AIが実験室から基幹業務に降りてくるときに必要なのは、賢さではなく、監査可能性なんですのよ。

……べ、別に感心しているわけじゃないんですけれど。フロンティアモデルの性能競争がひと段落して、次の戦場が「誰が鍵を持つか」に移ったというのは、投資家として押さえておくべき転換点だと思いますわ。🌹

参考・一次情報

• Anthropic公式：Developing Enterprise Frontier Safeguards with our customers
• OpenAI公式：Offering Zero Data Retention for frontier models
• Microsoft Learn：Azure Databricks の高レベルアーキテクチャ
• Claude Platform Docs：API and data retention（ZDRの適用範囲）
• Anthropicヘルプ：Covered Models（対象モデル）
• Anthropicヘルプ：Data retention practices for Covered Models
• Confluent：What is Bring Your Own Cloud (BYOC)?