AIに機密情報を入れてよいか——Anthropicのログ保管方針の変更と、日本法で変わらない線
Anthropic は2026年9月1日、企業向けに「Enterprise Frontier Safeguards(EFS)」を発表しました。AI に渡した会話の記録を、AI 会社側ではなく顧客自身のクラウドに保管する仕組みです。 これは「ゼロデータ保持(AI 会社側にデータを残さない契約)を取れば安心」という、これまでの実務の落としどころを、AI 会社の側から動かす発表でした。ただし日本の法律で見ると、変わるのは保管の場所と監視の担い手だけで、その情報を AI に渡してよいかどうかの判断そのものは変わりません。この記事では、発表内容を事実として押さえたうえで、社内で「AI に何を入れてよいか」を決める立場の人が、明日から使える形に翻訳します。

Enterprise Frontier Safeguards とは何か
EFS とは、ゼロデータ保持(AI 会社にデータを残さないこと)と、悪用の自動監視を両立させる仕組みです。監視に使う利用記録を、Anthropic ではなく顧客が持つクラウド(Amazon S3・Azure Blob Storage・Google Cloud Storage)に、顧客の暗号鍵と権限設定のもとで保管します。
Anthropic は公式発表で、監視の担い手についてこう書いています。
"EFS has automated safety monitoring, no Anthropic human review required."(EFS の安全監視は自動で行われ、Anthropic 側の人間によるレビューは不要です) — Anthropic「Developing Enterprise Frontier Safeguards with our customers」2026年9月1日
つまり自動検知は続くけれど、検知した中身を人が見るとしたら、それは顧客側の担当者になる、という設計です。提供開始は2026年秋に段階的で、利用料は無料(ただしクラウドの保管・読み書き・持ち出しの費用は各クラウド会社から顧客に請求されます)。移行までの間、対象顧客には Fable 5 と Fable 5.1 でゼロデータ保持が提供されます。出典は Anthropic 公式発表(新しいタブで開く)、および報道として The Register(2026年9月2日)(新しいタブで開く) です。
なぜこれが「実務の落としどころ」を動かすのか
生成 AI に機密情報を入れてよいかという議論は、これまでほぼ一本道でした。「学習に使われない・保存されない契約(ゼロデータ保持)を取れば、実務上は許容できる」という線です。法律事務所や専門メディアの解説も、多くがこの結論で締めくくられています。
この線には、あまり語られない弱点がありました。データを一切残さないと、AI 会社は「同じ利用者が何日もかけて危ない使い方を積み上げている」ような、時間をまたぐ悪用に気づけません。安全のための監視と、秘密を守るための不保持は、まっすぐ対立します。
EFS は、その対立を「記録は残すが、置き場所を顧客側にする」という形で分けました。プライバシーと監視のどちらかを選ぶ問題を、置き場所と担い手の設計問題に置き換えたわけです。
これまでの前提
- ゼロデータ保持=記録がどこにも残らない
- 悪用の検知は AI 会社が引き受ける
- 契約書を1枚取れば運用は終わり
- 判断材料は「保存されるか否か」
EFS 後の前提
- 記録は残る。ただし置き場所が自社のクラウド
- 自動検知の結果は自社に通知され、見るのは自社の担当者
- 保管・鍵・権限・通知対応という運用が自社に増える
- 判断材料は「誰が扱い、どこにあり、誰が見るか」
日本法では「どこに置いたか」より「誰が扱うか」で決まる
ここが、この発表をめぐる解説でいちばん誤読されやすいところです。保管場所が自社クラウドに移っても、日本の法律上の評価が自動的に軽くなるわけではありません。
理由は単純で、日本の個人情報保護法も、士業の守秘義務も、「データがどのサーバーに置かれたか」ではなく「誰が、どういう立場で取り扱ったか」を軸に組み立てられているからです。AI に文章を送った時点で、その情報は AI 会社の手元をいったん通ります。置き場所の話は、そのあとの話です。
3つの層に分けると、変わるところと変わらないところがはっきりします。
| 論点 | 根拠となる考え方 | EFS で変わるか |
|---|---|---|
| 顧客の秘密を第三者に開示したことにならないか | 契約上の守秘義務・士業の守秘義務(弁護士法・刑法の秘密漏示罪など) | 変わらない。AI 会社に送信する事実自体は残る |
| 個人データを第三者に渡したことになるか | 個人情報保護法の第三者提供と、業務の「委託」の区別 | 変わらない。委託と評価できるかは契約と実態で決まる |
| 外国にある第三者への提供にあたるか | 個人情報保護法の越境移転規制 | 原則変わらない。移転の有無は取扱者で決まり、保管先の選択だけでは決着しない |
| 記録の保管・鍵・アクセス権を誰が管理するか | 安全管理措置 | 変わる。自社の管理対象が増える |
| 悪用検知の通知に一次対応するのは誰か | 社内の運用体制 | 変わる。自社の担当者に回ってくる |
この表の言いたいことは一つです。EFS は安全管理措置の設計を変える話であって、「その情報を AI に渡してよいか」という入口の判断を代替しません。 入口の判断は、これまでどおり、契約の守秘条項・個人情報保護法・自社の規程を突き合わせて決めることになります。
本記事は一般的な整理であり、個別の法律相談ではありません。条文とガイドラインは改正されます。実際の判断は e-Gov の個人情報の保護に関する法律(新しいタブで開く) と 個人情報保護委員会(新しいタブで開く) の最新のガイドラインで原典を確認してください。越境移転の考え方は 海外AIサービス利用と個人情報保護法、守秘義務まわりは AI議事録・文字起こしツールと秘密保持契約 に分けて書いています。
「監視の通知が自社に来る」の重さを見落とさない
EFS のニュースで、いちばん見落とされやすいのがここです。自動検知が何かを見つけたとき、その信号は顧客に直接送られます。The Register は同じ点を指摘し、規制対応が楽になる一方で「これまで Anthropic 側の担当者が担っていたかもしれない監視の実務を、自社で引き受けることになる」と書いています。
これは机上の負担ではありません。通知が来るということは、次の4つを事前に決めておく必要がある、ということです。
とくに2つ目は厄介です。悪用を確認するためにログを開く行為そのものが、社内での秘密の閲覧にあたります。 ゼロデータ保持で「誰も見ない」ことにしていた情報を、自社の担当者が見られる状態に置き換えた、とも言えます。安全になった面と、新しい線引きが必要になった面が同時にあります。
私たちが「渡さないもの」を設定で切っている話
ここからは自分たちの一次記録です。私たちは JurisCode.AI の日次運用を AI エージェント(Claude Code)にかなり任せていて、この記事を含めて公式サイトの記事155本(2026年9月4日時点)を、その運用の中で作っています。つまり毎日、業務のファイルを AI に読ませている側です。
そこで実際にやっているのは、契約でどうにかすることではなく、そもそも読ませない範囲を設定ファイルで機械的に切ることでした。手元の設定(~/.claude/settings.json)には、いま次の内容が入っています。
- 明示的に禁止しているルールが8件。うち2件は認証情報の置き場所そのものの読み取り禁止(SSH 鍵ディレクトリ・クラウド認証情報ディレクトリ)
- 前職に関わるフォルダへの書き込みと編集の禁止(守秘義務が残っている領域を、うっかり触らせない)
- 確認なしで実行してよい操作は10件だけ。いずれも「この絶対パスのこのスクリプト」という粒度まで固定
- 機密データの所在をあらかじめ書き出しておき、外部の貼り付けサービス(公開 gist など)は信頼境界の外だと明示
ポイントは、禁止が「方針」ではなくファイルに書かれた規則になっていることです。人が気をつける方式は、疲れた日曜の夜に破れます。設定ファイルは疲れません。この考え方は AIエージェントへの「全許可」をやめた理由 に詳しく書きました。
EFS のような発表が来ても、この層は無駄になりません。「渡さなかった情報」は、どこに保管されようと、誰に通知されようと、そもそも問題になりようがないからです。契約や保管方式の話は、渡すと決めた情報についての二段目の防御にすぎません。
社内で許可を出すときの確認手順
EFS の話を踏まえて、「うちで生成 AI を業務に使ってよいか」を決める立場の人が踏む手順を、順番に並べます。上から順に、下の答えが変わったら上に戻ります。
- 入れようとしている情報を3つに仕分ける。①社外秘でも個人データでもない ②個人データを含む ③守秘義務の対象(顧客・患者・依頼者の情報)
- ①だけを対象にする運用でまず始める。この段階では契約の議論はほぼ要らない
- ②③に踏み込むなら、契約を確認する。学習に使われないこと・応答以外の目的に使われないこと・提供者側が守秘義務を負うことの3点を、規約か個別契約の条文で特定する
- 提供者の所在と、データが渡る先の国を確認する。外国にある第三者への提供にあたる場合の手当て(本人同意など)を、どの経路で満たすかを書き出す
- 保管方式を決める。ゼロデータ保持か、EFS のような自社クラウド保管か。後者を選ぶなら、鍵・権限・保管期間を誰が管理するかまで決める
- 監視通知の一次対応者と、ログを開いてよい範囲を決める。ここまで決まって、はじめて運用として閉じる
- 決めた内容を1枚に書き、使う人が読める場所に置く。禁止は文章より、可能なら設定で機械的に切る
順番が大事です。多くの事故は3の契約確認を飛ばして起きるのではなく、1の仕分けを飛ばして起きます。 何を入れようとしているのかが曖昧なまま「AI を使ってよいか」を議論すると、答えが出ません。
なお、この記事では社内 AI 利用規程のひな形そのものや、モデルごとの性能・料金の比較は扱っていません。前者は「条件の決め方」が固まってからの作業で、後者は「入れてよいか」の判断を前に進めないからです。個人データを預かるアプリを作る側の視点は 個人データを扱うアプリが守るべき法律の基本 にまとめてあります。
この発表を一言でいうと
AI 会社が「安全のために見る」ことと、顧客が「秘密を守る」ことの折り合いを、置き場所と担い手の分担で付け直した——これが EFS の中身です。歓迎すべき方向だと考えていますが、同時に、自社側の運用が増える変更でもあります。
そして日本法の入口の判断は、これで軽くなりません。渡してよい情報かどうかを決めるのは、いまも自分たちです。 その意味では、いちばん効く対策は今日も昨日と同じで、渡さなくてよい情報を渡さない設計を先に作ることだと思っています。
よくある質問
Q. ゼロデータ保持の契約を結んでいれば、顧客の情報を AI に入れても守秘義務違反になりませんか。
自動的に免れるとは言えません。守秘義務の評価は、保存されたかどうかだけでなく、そもそも第三者に開示したと評価されるかで決まります。実務では、学習に使われないこと・応答以外の目的に使われないこと・提供者が守秘義務を負うことなどを総合して判断されると説明されることが多く、契約1本で終わる話ではありません。顧客との契約に個別の同意条項があるかも併せて確認してください。
Q. EFS を使えば、外国への個人データ移転の問題は消えますか。
消えません。越境移転の規制は、保管場所の選択だけで決着する仕組みにはなっていません。誰が取扱者で、どこの国の事業者に渡っているかが軸になります。自社が日本国内のクラウドに監視ログを置いたとしても、AI 会社にデータを送った事実そのものが消えるわけではないためです。詳しくは 海外AIサービス利用と個人情報保護法 を参照してください。
Q. EFS は誰でも使えますか。費用はかかりますか。
Anthropic 側の利用料は無料と発表されています。ただし提供は2026年秋から段階的で、対象は条件を満たす企業顧客とされています。また、ログを置くクラウド(S3 など)の保管・読み書き・データ持ち出しの費用は、各クラウド会社から自社に請求されます。個人利用や小規模チームがすぐ使える性質のものではありません。
Q. 監視の通知が自社に来ると、何が困りますか。
一次対応の担当者を決める必要が出ます。さらに、通知の内容を確かめるためにログを開くと、そこには自社が AI に入力した情報——場合によっては顧客の秘密——が含まれます。「誰がどこまで見てよいか」を先に決めていないと、安全のための確認作業が、社内での情報漏れの経路になりかねません。
Q. 結局、いま社内で何から手を付ければよいですか。
入れようとしている情報の仕分けからです。社外秘でも個人データでもない情報だけを対象にした運用なら、契約の議論をほぼ飛ばして今日から始められます。そのうえで、業務上どうしても踏み込みたい範囲が出てきたときに、はじめて契約・保管方式・監視体制の順で詰めるのが、行き止まりの少ない進め方です。
コメント
#AIニュース#AI法律#個人情報保護法