そのデータ、どこに何日残りますか? 「うちの顧客データを入れて、大丈夫なんですか?」

カレンダーを抱えたラピットくんと、そのデータどこに何日残る?というタイトル

「そのAI、賢いんですか?」

研修や導入相談で、この質問をされることはほとんどありません。かわりに、ほぼ毎回聞かれるのがこちらです。

「うちの顧客データを入れて、大丈夫なんですか?」

正直に言うと、僕はこの質問にうまく答えられていませんでした。「たぶん大丈夫です」では、経営者の方は動けません。かといって、規約を全部読んでくださいとも言えない。

先日、Claude の新しいモデルについて「30日ログを取られるのか」を調べる機会がありました。整理してみたら、思っていたよりずっと構造がはっきりしたので、まとめておきます。

世の中に出回っているAIの比較記事は、ほとんどが性能の話です。ベンチマークのスコア、コーディング能力、応答の速さ。大事なのはわかります。でも、稟議を通す側や、情報セキュリティに責任を持つ側が本当に知りたいのは、そこではありません。

知りたいのは、3つだけです。

  1. 入力したデータは、サーバーに残るのか。何日か。
  2. 残ったデータは、AIの学習に使われるのか。
  3. それを、誰が見られるのか。

この記事では、性能の話は一切しません。この3点だけで「どのプランを契約し、どのモデルを使ってよいか」を決める方法を書きます。

※ 本記事に記載した保持期間・条件は、すべて 2026年8月28日時点 の Anthropic(Claude)の公開情報にもとづきます。ポリシーは変更される可能性があるため、実際の判断にあたっては最新の規約・自社の契約書を必ずご確認ください。なお、ここで使う「3つのレイヤー」の考え方自体は、他社のAIサービスを評価するときにもそのまま応用できます。

ZDRの保持なしから6〜7年までの保持期間を比較した図
まず全体像。同じ「Claude」でも、契約とモデルによって残る期間はここまで違います(2026年8月28日時点)

1. 話が噛み合わない理由は、3つが混ざっているから

調べていて最初に気づいたのは、自分がまったく別の3つの話を「ログ」の一言で混ぜていたことでした。ここを分けるだけで、かなり見通しがよくなります。

保持・学習利用・モデル固有の下限という3つのレイヤーを示した図
①②は契約や設定で動かせます。でも③は、モデルを選んだ時点で決まってしまう

①と②は別物です。「30日保持される」ことと「学習に使われる」ことは、まったく違う。ここを混ぜたまま議論すると、いつまでも結論が出ません。

そして2026年6月から、③という新しいレイヤーが加わりました。今回いちばん驚いたのが、ここです。

順番に見ていきます。


2. レイヤー①:保持は「プラン」で決まる

Claude / Claude Code の場合、アカウントの種類で保持期間が変わります。

プラン・契約形態サーバー側の保持備考
個人プラン(Free / Pro / Max)
学習利用 ON
5年モデル開発・安全性改善のため
個人プラン(Free / Pro / Max)
学習利用 OFF
30日設定でいつでも変更可
商用(Team / Enterprise / API)標準30日
商用 + ZDR(ゼロデータ保持)保持なし適格な組織のみ。営業窓口経由で個別に有効化
Amazon Bedrock / Google Cloud / Microsoft Foundryクラウド事業者側のポリシーに従うデータ管理者がAnthropicではなくクラウド事業者になる

調べていて「これは見落としていた」と思った点が、3つありました。

見落とし1:個人プランは「商用規約」ではない

Pro や Max は消費者向けプランです。便利で安いので、つい業務でも使い続けてしまう。僕もそうでした。

でも、顧客から預かったデータを個人プランに入れるのは、契約の建て付けとして本来おかしい。学習利用の設定をOFFにすれば保持は30日になりますが、規約の種類そのものが変わるわけではありません

「Max プランで顧客案件をこなしている」個人事業主や小規模事業者は、たぶんかなり多いはずです。顧客データを扱うなら、商用契約(Team / Enterprise / API)へ移る。ここが最初の分岐でした。

見落とし2:ローカルにも平文で残っている

クラウドの話ばかり気にしていましたが、Claude Code はセッションの記録を自分のPC上に平文で30日間保存しています(~/.claude/projects/ 配下。cleanupPeriodDays で変更可)。

顧客ファイルを読み込ませた会話も、ここに残ります。ZDR契約を結んでいても、これは消えません。

冷静に考えると、サーバー側の保持より、PCの盗難・紛失、バックアップ経由の流出、共有フォルダへの同期のほうがよほど起こりやすい。順番としては、こちらを先に手当てすべきでした。

見落とし3:Enterprise には別枠の6年保存がある

Enterprise 組織で監査目的のコンプライアンス機能を使っている場合、ユーザーのPC上のセッション記録が、既定で6年間サーバー側に保存されます(ZDR有効・HIPAA対応有効の組織からは取得されません)。

ガバナンスとしては正しい設計です。ただ、社内に「30日で消えます」とだけ説明していると、あとで食い違います。


3. レイヤー②:保持と学習は、別の話

保持されていることと、学習に使われることは違います。

区分学習利用保持
個人プラン(設定 ON)使われる5年
個人プラン(設定 OFF)使われない30日
商用(Team / Enterprise / API)規約上、使われない
※開発パートナープログラム等に明示的に参加した場合を除く
30日

つまり、個人プランを業務で使っているなら、最初にやるべきは学習利用設定の確認です(claude.ai の設定 → データプライバシー管理)。

僕も確認しました。ここがONのまま業務で使っている人は、珍しくないと思います。5年か30日か、そして学習に使われるかどうかが、チェックボックス1つで変わります。


4. レイヤー③:モデルが契約を上書きする

ここが本題です。

2026年6月9日、Anthropic は一部のモデルを「Covered Models(対象モデル)」に指定しました。該当するのは Claude Fable 5Claude Mythos 5 です。

対象モデルには、こういうルールが適用されます。

プロンプトと出力は、安全性業務のために30日間保持される。これは、当該モデルが提供されるすべてのプラットフォームにおいて適用される。

そして、決定的なのがこの一文でした。

Claude Fable 5 および Claude Mythos 5 は30日間のデータ保持を必要とし、ZDR(ゼロデータ保持)のもとでは利用できない。

読んだとき、少し手が止まりました。

API では、保持設定を満たしていない組織からのリクエストは 400 invalid_request_error で拒否されます。「契約でゼロ保持にしているから、どのモデルでも安全」が、成立しなくなった。

なぜこんなルールができたのか

理由は「能力が上がったモデルほど、単発のリクエストを見ているだけでは悪用を検知できないから」です。

例に挙げられているのが Best-of-N ジェイルブレイクという手口。プロンプトの微妙な変種を何百回も投げ続けて、そのうち1つが通るのを狙います。1リクエストずつ見ても、どれも「ちょっと変わった質問」にしか見えません。

複数のリクエストをまたいで見て、初めてパターンが浮かび上がる。だから一定期間データを持たないと防げない、というロジックです。これは納得できました。

保持されたデータは誰が見るのか

ここは公式に、はっきり線が引かれていました。

  • 既定では、Anthropic の社員は保持された会話を読めない
  • 人間のレビューは、統制されたアクセス経路を通る場合のみ(例:自動の安全システムがフラグを立てたとき)
  • すべてのアクセスは改ざん防止ログに記録され、レビュアーはその記録を修正・削除できない
  • 30日経過後は自動削除。例外はフラグが立った場合と、法的に保存義務がある場合のみ
  • 保持データは、明示的な許可なくモデルの学習には使われない(=安全対策目的に限定)

「保持される」と聞くと反射的に身構えてしまいますが、中身を読むとかなり絞られています。

これが実務で何を意味するか

今までは、契約(ZDR)を結べば、どのモデルを使っても保持されませんでした。モデル選定は性能の問題だった。

これからは違います。モデルの選択が、契約条件を上書きすることがある。

つまり、顧客に「ゼロデータ保持で運用しています」と説明している会社が、開発者の善意で最新モデルに切り替えた瞬間に、その説明が虚偽になる。悪意はどこにもないのに、事故が起きる。

この構造が、いちばん怖いと思いました。


5. 契約に関係なく残るもの

「ZDRなら何も残らない」も、正確ではありませんでした。契約の種類にかかわらず残るものがあります。

何がどれくらい
自動の安全システムにフラグされた入出力最大2年
その分類スコア最大7年
フィードバック送信(/feedback/bug/share5年(会話履歴=コードを含む)
セッション満足度調査で「トランスクリプト共有」に同意した場合最大6ヶ月
バッチ処理のジョブ29日
アップロードしたファイル明示的に削除するまで
コード実行コンテナのデータ最大30日

特にひやりとしたのが、フィードバック送信です。

不具合を報告しようとして /feedback を実行すると、会話履歴(読み込ませたコードや顧客ファイルの中身を含む)が送信され、5年保持されます。良かれと思ってバグ報告した結果、顧客の設計書が5年残る。

社内ルールとして「顧客案件のセッションからフィードバックを送らない」を決めておく価値があります。


6. で、どう選ぶか

ここまでを整理すると、選び方はこうなりました。モデルから選ぶのではなく、扱うデータから逆引きします。

データ区分ごとの推奨契約と使ってよいモデルの対応表
③の行だけ、契約ではなく「モデルの選択」が結論を決めます(2026年8月28日時点)
データ区分推奨する契約使ってよいモデル追加でやること
① 社内の非機密
自社コード、公開情報の調査、資料作成
個人プラン(Pro / Max)で可制限なし(Fable 5 も可)学習利用設定をOFFにする
② 顧客の業務データ
NDAあり、個人情報は含まない
商用契約(Team / Enterprise / API)へ制限なし(30日保持を顧客に説明できるなら Fable 5 も可)個人プランからの移行。ローカル保持期間の短縮
③「保持しない」が契約要件
顧客がゼロ保持を明示的に求める
商用 + ZDRFable 5 / Mythos 5 は選択肢から外す
ステートフル機能(ファイルアップロード、バッチ、コード実行)も使わない
使用可能モデルを案件ごとに文書で固定する
④ 個人情報・要配慮個人情報・医療情報(PHI)HIPAA対応が必要な領域だが、Claude Code はHIPAA対応の対象外ツール選定ではなく設計で解決する

導入前に確認する3つの質問

Q1. そのデータが30日間どこかに残っても、顧客に説明できますか?
→ できないなら、③のゼロ保持を前提とした設計に進みます。

Q2. 顧客と「データを保持しない」と約束していますか?
→ しているなら、Covered Model の使用禁止を社内ルールとして書いてください。 技術者の判断で切り替えられる状態にしておくと、いずれ崩れます。

Q3. 個人情報が混ざる可能性はありますか?
→ あるなら、契約でどうにかしようとせず、そもそもAIに渡さない設計に変える。これがいちばん確実です。

「設計で解決する」とは

香川大学の消化器内科向けに、大腸内視鏡の前処置ナビゲーションアプリを作ったことがあります。このとき、そもそも個人情報を1件も扱わない設計にしました。患者さんの氏名も、IDも、生年月日も持たない。

持たないものは、漏れません。

医療や個人情報が絡む領域では、「どのAIなら安全か」を探すより、「AIに渡さなくても成立する設計にできないか」を先に考えたほうが、早いし安い。契約書でリスクを移すのではなく、リスクそのものを消す。

情報セキュリティとしては当たり前の話ですが、AI導入の文脈だと、なぜか忘れられがちです。


7. 調べる前に、僕が誤解していた3つ

誤解1:「ZDR契約をすれば、全部消える」

消えませんでした。Covered Model は契約より優先されるし、フラグが立った内容・法的保全対象・ステートフルな機能(ファイル、バッチ、コード実行)のデータもZDRの対象外です。

「ZDR=完全にゼロ」ではなく、「標準的な推論の入出力については保持しない」。ここが正確なところでした。

誤解2:「保持されている=学習に使われている」

別の話です。商用契約では規約上、学習に使われません。Covered Model の30日保持も、目的は安全対策に限定されています。

ここを混同したまま「AIは全部学習に使われるから危ない」と説明すると、社内の判断が必要以上に保守的になって、使えるはずのものまで止まります。

誤解3:「ローカルで動かしているから安全」

これは僕も一瞬勘違いしていました。

Claude Code はローカルで動きます。でも推論のたびに、プロンプトも出力もネットワークに出ています。さらにセッション記録が、ローカルに平文で30日残る。

「ローカル動作」は「データが外に出ない」という意味ではありませんでした。むしろローカルに残る平文ログのほうを、社内規程(ディスク暗号化、持ち出しPCの扱い、バックアップ範囲)で先に手当てすべきです。


8. 導入前に決めておく5つのこと

  • 学習利用設定を確認した — 個人プランの場合。ONなら5年保持・学習利用あり
  • 業務で使うアカウントの契約種別を確認した — 顧客データを個人プランで扱っていないか
  • 案件ごとに「使ってよいモデル」を決めた — 性能ではなく保持要件で決める。ゼロ保持要件の案件では Covered Model を禁止
  • ローカルのセッション記録の扱いを決めた — 保持日数の短縮、ディスク暗号化、バックアップ範囲
  • フィードバック送信のルールを決めた — 顧客案件のセッションから /feedback を送らない

この5つを先に決めておくと、「AIを入れていいのか」の議論はかなり短くなります。逆にここが曖昧なままだと、あとから必ず止まります。


おわりに — 比較表に列を1本足す

モデルの性能は毎月変わります。半年前のベンチマーク比較は、もう使えません。

でも保持ポリシーは、契約と説明責任に直結します。そう簡単には変わらない軸です。そして2026年6月以降、「使うモデルによって保持の下限が変わる」という制約が加わりました。

社内でAIモデルを比較する表を作っているなら、「保持の下限」という列を1本足してみてください。 精度・速度・価格の隣にその列があるだけで、情報システム部門と事業部門の話が噛み合うようになります。

「賢いかどうか」より先に、「どこに何日残るか」。

この順番で考えるようになってから、僕自身、お客様への説明がだいぶ楽になりました。


※ 本記事の記載はすべて2026年8月28日時点の公開情報にもとづきます。各社のデータ保持ポリシーは予告なく変更されることがあります。実際の契約判断・顧客への説明にあたっては、必ず下記の一次情報および自社の契約書で最新の内容をご確認ください。

出典(2026年8月28日 参照)

株式会社AppTalentHub は、中小企業のAI・DX導入を「つくる側に回る」視点で支援しています。導入前のセキュリティ要件整理から、実装、社内定着までご相談ください。

この記事を書いた人