「法人契約なので、入力は学習に使われません。ですから、機密情報を入れても差し支えありません。」
このような判断が、実際に行われています。
学習に使われないというのは、正しい説明です。問題は、そこから「機密情報を入れてよい」が出てこないことです。
学習とは、モデルの中身を書き換えることです
文章を扱う生成AIのサービスは、LLM（大規模言語モデル）を呼び出して動いています。このLLMで「学習」と呼ばれている手法は、3つあります。
| 呼び方 | 何をするか |
|---|---|
| 事前学習 | 大量の文章を読ませて、モデルの中身（重み）を作ります。モデルそのものを作る工程です |
| 事後学習（ファインチューニング） | できあがったモデルに追加の学習をさせ、用途に合わせて中身を作り直します |
| 継続学習 | 運用しながら、新しいデータで中身を更新し続けます |
3つに共通するのは、入れたデータがモデルの中身に焼き付き、元に戻せなくなることです。書き換わった中身は、全利用者に共有されます。そして、一度中身に溶け込んだデータを、顧客の側から確認する方法はありません。ファイルが在るか無いかを確認できる従来のクラウドとは、質が違います。「学習に使っていません」は、技術的に検証できない、契約上の約束です。
文脈内学習・RAG・メモリは、学習ではありません
| 呼び方 | 何をするか |
|---|---|
| 文脈内学習 | 指示文や貼り付けた資料を読ませ、その場の応答に反映させます |
| RAG（Retrieval-Augmented Generation——検索した内容を読ませる仕組み） | 手元の文書を検索し、見つかった文書をモデルに読ませます |
| メモリ | 過去のやりとりや利用者の情報を保管しておき、次回以降の応答に反映させます |
3つとも、モデルの中身は変わりません。入れたデータが送られてきたときだけ、応答に影響します。送られてこなければ、影響しません。
しかし「文脈内学習」という名前が付いているため、実際には区別されずに語られています。事前学習・事後学習・継続学習と、文脈内学習・RAG・メモリを区別せずに「学習」と呼ぶと、「学習に使いません」と言われたときに、実際には何が約束されているのかが分からなくなります。
文脈内学習・RAG・メモリは、データが保管されることを前提にしています
モデルの中身を変えずに、入れたデータを出力へ反映させるためには、そのデータがどこかに保管されていなければなりません。保管されていなければ、次の応答に反映させることができません。
RAGが、最も分かりやすい例です。社内の規程や設計書を読ませて答えさせたい、という使い方がこれに当たります。文書の数が多ければ、質問のたびに全部をモデルに読ませることはできませんので、あらかじめ検索できる形に変換して保管しておき、質問のたびに関係する部分だけを取り出して送ります。
LLMの運営事業者（以下、「LLMの事業者」といいます）側の機能を使う場合、社内の機密文書そのものが、検索できる状態が続くかぎり、LLMの事業者側で保管され続けます。
ここから、情報セキュリティの観点で疑問が出てきます。
- 登録した文書は、どこに保管されるのか
- いつまで保管されるのか
- 誰が閲覧できるのか
- 削除できるのか。削除したとき、検索用に変換した後のデータまで削除されるのか
「学習に使いません」が対象としているのは、事前学習・事後学習・継続学習の3つだけです。文脈内学習・RAG・メモリは範囲外にあり、LLMの事業者側で保管されたデータが、モデルの応答に影響し続けます。
「学習に使いません」が約束しているのは、入れたデータがモデルの中身に取り込まれないことだけです。入れたデータがどこに保管され、いつまで残り、誰が閲覧できるのかについては、何も約束していません。
学習されないほうが、原文のまま残ります
モデルに学習されて残る場合と、データそのものが保管されて推論に使用される場合では、性質が違います。
| モデルに学習されて残る場合 | データそのものが保管され、推論に使用される場合 | |
|---|---|---|
| 形 | 他の情報と混ざり、薄まります | 元の文章のまま残ります |
| 範囲 | 全利用者に共有されます | 契約している組織の範囲に集中します |
| 期間 | 恒久的です | 保管されている間、持続します |
| 自社からの確認 | できません | 機能によっては確認できます |
一般には、学習されると危険で、学習されないなら安全だと考えられています。しかし、データそのものが保管されて推論に使用される場合は、機密が元の文章のまま、契約している組織の範囲に集中して残ります。
学習に使われないことは、安全であることを意味しません。
データが保管されるのは、文脈内学習・RAG・メモリだけではありません
入力したデータと出力されたデータは、次のような場合にも保管されます。
- 処理のために一時的に保持される
- 動作の記録や監査の記録として保管される
- 不正な利用の点検のために保管され、人が読む対象になる
- LLMの事業者が使っている別の会社へ渡る
- 法令に基づいて保持され、開示される
いずれも、学習に使わないという約束を守っていても起こります。
確認すべきことは、「学習に使われるか」ではありません。入力したデータと出力されたデータが、どこに、いつまで、誰が閲覧できる形で保管され、削除できるのか。これを一件ずつ確認する必要があります。
ここから、確認の方法です
確認しなければならないことは、はっきりしました。しかし、何から手を付ければよいのかは、まだ分かりません。
Claude.ai の法人向けプラン（Enterprise）を対象として、何が保管されるのかの確認を行いました。以下、その過程を段階ごとに述べます。自分の使っている環境で同じことを行うとき、何を、どの順で確認するのかを示すためです。
確認は、2026年7月下旬に公開されていた公式文書によります。委託先の数も、契約の定めも、保持の期間も、後から変わります。
8つの段階があります。前の段階の結果が次の段階の入力になるため、順序を入れ替えることはできません。
段階1——どんな機能があるのかを洗い出す
最初に分からないのは、そのサービスに何ができるのかです。
機能が分からなければ、データがどこへ行くのかも分かりません。画面に表示されている機能だけを数えても足りません。設定の画面の奥にある機能、管理者だけが使える機能、既定で有効になっていて利用者が意識していない機能があります。
そこで、公式ヘルプセンターの索引（約290記事の題名）、プランの比較表、直近1年分のリリースノートを読みました。利用者向けの案内文ではなく、索引と一覧を読みます。索引は、LLMの事業者が「これは説明すべき機能である」と判断した機能の一覧だからです。
Claude.ai の法人向けプラン（Enterprise）には、85の機能がありました。
85は、記録の単位として数えた数です。作業を任せる仕組み、会話が長くなったときに過去のやりとりを要約する仕組み、組織の管理者が全員のメッセージに差し込める指示文——このような個々の機能を1件とし、10のまとまりに分けています。
この数は、使う側の実感とかけ離れています。日常的に使っているのは、そのうちのごく一部です。しかし、使っていない機能でも、既定で有効になっていればデータは動きます。確認の対象は、使っている機能ではなく、有効になっている機能です。
段階2——機能ごとに公式文書を読む
機能があると分かっても、そのデータがどこに保管され、いつまで残り、削除できるのかは分かりません。
そこで、ヘルプセンターの記事の本文、プライバシーセンターの記事、技術文書を読み、機能ごとに、保管先・保持期間・削除できる範囲・止める手段を確認しました。
ここで、2つのことが判明します。
第一に、公式文書に書かれていない項目があります。保管先が示されていない、保持期間が示されていない、削除の可否が示されていない。このような項目は「未確認」として記録し、推測で埋めていません。「おそらく削除されるはずだ」と書いた時点で、確認したことになりません。
第二に、削除の対象にならないデータがあります。
Anthropic の場合、利用規約に違反する疑いがあると判断されて印が付くと、入力と出力は最長2年、内容の分類に使われた数値は最長7年保管され、削除の対象になりません。これは個人向けと法人向けの双方に共通して定められています。
この条件は、利用者の側では選べません。疑いが立つかどうかを決めるのはLLMの事業者側の判定であり、特定の機能を使わないという方法で避けることもできません。
学習には使われません。それでも、この期間は保管されます。
段階3——データが通る道筋を整理する
保管先が分かっても、そのデータがどこで生じ、どこを通って保管先に着くのかが分からなければ、途中で止められるかを判断できません。
そこで、クラウドのLLMサービスを4つの層に分けて、機能ごとに、どこで生じ、どこを通り、どこに保管されるかを確認しました。
| 層 | 何があるか |
|---|---|
| クライアント層 | ブラウザ、事業者の公式アプリ、自社で作ったアプリ。入力と表示を行います |
| オーケストレーション層 | 毎回モデルへ送る文章を、一本にまとめて組み立てます。会話履歴の再送、あらかじめ与える指示文の差し込み、メモリの読み出し、RAGの検索、ツールの実行、安全性フィルタ。すべてモデルの範囲外です |
| モデル推論層 | 中身が固定された、記憶を持たない計算の仕組み |
| 周辺ストレージ層 | 会話履歴、メモリ、登録した知識ファイル、呼び出しの記録、監視の記録、フィードバック。持続するデータは、すべてここにあります |
この分け方から、重要なことが出てきます。
モデルは、前のやりとりを記憶していません
モデル推論層は、呼び出しをまたぐ記憶を持ちません。会話の履歴を保管しているのは、モデルではなく周辺ストレージ層です。
それでも会話が続いているように見えるのは、オーケストレーション層が、毎回、それまでの会話を全部まとめて送り直しているからです。
なお、処理を速くするために、計算の一部を再利用する仕組みがあります。入力に由来するデータが、モデル推論層に短期のあいだ保持されます。保持される場所も、期間も、公表されていません。利用者から見える面がなく、止める手段も示されていません。
ここから、「会話を終えれば消える」が何を指しているのかが分かります。消えているのは、次に送る文章にその会話を含めなくなるということです。仕組みがデータを削除しているのではありません。会話の履歴は、LLMの事業者側に保管されたまま残っています。
モデルへの入口は、一本のトークンの列だけです
トークンとは、文章を機械が扱えるように切り分けた単位です。モデル推論層が受け取るのは、この一本の列だけです。周辺ストレージ層とも、インターネットとも、直接つながっていません。読み出すことも検索することも、オーケストレーション層の仕事です。
そして、その一本の列には、8つの区分が混ざっています。
| 区分 | 誰が書いた内容か | いつ入るか |
|---|---|---|
| システムプロンプト・ツール定義 | LLMの事業者 | 毎回自動 |
| 組織の指示 | 組織の管理者（組織の全メンバーの全メッセージに入ります） | 毎回自動 |
| ユーザー設定・カスタム指示 | 利用者（過去の設定） | 毎回自動 |
| メモリ | システムが抽出した情報（利用者が書いたものではありません） | 毎回自動 |
| プロジェクト知識・添付 | 利用者（登録済み） | 毎回自動 |
| 会話履歴の全文 | 過去のやりとり（モデル自身の過去の出力を含みます） | 毎回自動 |
| 今回のメッセージ | 利用者（今） | 今回のみ |
| ツール結果 | 外部（内容は検証されていません） | 条件により |
システムプロンプトとは、LLMの事業者があらかじめ与えている指示文です。どう振る舞うか、何を答えないか、どのツールを使えるかが書かれています。利用者からは見えません。
上から3つは、いずれも毎回自動で入る指示文です。しかし、書けるのは、LLMの事業者、組織の管理者、利用者と、それぞれ別です。まとめて「システムプロンプト」と呼ばれることがありますが、書ける人が違います。
由来も、信頼できる度合いも違う8つの区分が、モデルにとっては区別のない一本の列になります。
そして、利用者が直接書いたのは、8つのうち3つだけです。残りは、LLMの事業者、組織の管理者、システムが抽出した情報、過去のモデル自身の出力、外部から取得した内容です。
「モデルに送る内容を管理する」とは、この8つの区分それぞれについて、誰が書けるのか、何が書かれているのかを管理することです。
段階4——データの所在を書き出す
どこに保管されるかは、機能ごとに確認しました。しかし、それだけでは足りません。
入力した文章を例にします。
入力した文章は、会話の履歴として保管されます。画面から会話を削除すれば、この履歴は削除されます。
しかし、入力した文章は、会話の履歴だけに保管されているわけではありません。
応答に対して評価や意見を送った場合（フィードバック）は、その時点の会話の全体が複製され、別に保管されます。この複製は、元の会話を削除しても残ります。
そして、メモリ機能があります。
メモリ機能とは
やりとりの中から、利用者に関する情報をシステムが自動で抜き出し、保管しておく仕組みです。次回以降、別の会話を始めたときにも、その情報が自動で読み出され、モデルに送られます。
利用者が書いて登録するものではありません。何を抜き出すかを決めるのは、システムの側です。業務の内容、担当している案件、取引先の名前、進めている検討の中身——会話の中に出てきた情報が、抜き出される対象になります。
そして、抜き出された情報は、会話とは別の場所に保管されています。
ですから、会話を削除しても、そこから抜き出されたメモリ機能の記録は削除されません。
「削除したのに、内容を覚えている」という状態が、一時的なずれではなく、そのまま続きます。メモリ機能の記録を削除したい場合は、メモリ機能の側で別に削除の操作を行う必要があります。
入力した文章1つで、これだけの確認が必要です。会話の履歴、フィードバックによる複製、メモリ機能の記録。保管されている場所ごとに、保持される期間も、削除の操作ができるかどうかも違います。
そこで、機能ごとではなく、データが保管される場所ごとに書き出しました。そのデータが何か、どこで生じるか、どこに保管されるか、誰が運用しているか、いつまで残るか、誰が閲覧できるか、削除の操作ができるか、止める手段は何か。これを1つずつ記録します。
ここで、さらに2つのことが判明します。
保管されているかどうかが公表されていないデータがあります
その機能を使えば何かが保管されているはずなのに、公式文書に記載が無いデータです。保管先も、保持期間も、削除の可否も示されていません。
このようなデータも、一覧に含めています。記載が無いことを理由に外すと、確認して問題が無かった項目と、確認できなかった項目が、どちらも「一覧に無い」状態になります。後から見返したときに、区別が付きません。
本人には確認できるのに、組織からは確認できないデータがあります
モデルに一連の作業を任せる機能（エージェント機能）で生成されたファイルが、これに当たります。
このファイルは、利用者のアカウント側に保管されます。本人は画面から確認でき、削除の操作もできます。しかし、組織の監査の記録にも、組織全体のデータを書き出す機能にも含まれません。
組織の管理者から見ると、この活動は存在しないことになります。何が生成され、何が保管されているかを、組織の側から確認する手段がありません。
本人が確認できることと、組織が確認できることは、別々に判定する必要があります。片方から判断すると、もう片方が抜けます。
段階5——1件ずつ、手を打てるかを確認する
どこに何が保管されるかが分かっても、それぞれについて自社で対処できるのかは、まだ分かりません。
そこで、書き出した1件ずつについて、手段があるかを確認しました。削除の操作ができるか、その機能を停止できるか、保持される期間を設定できるか、閲覧できる範囲を制限できるか、契約で約定されているか。このいずれかで実際に対処できるかどうかです。
手段が無い項目が残ります。設定でも運用でも避けられず、契約でも変えられないデータです。
このうち、性質が他と違う項目があります。推論の計算をしている間のデータと、画面に表示されている間のデータです。
他の項目は、手段が用意されていないだけです。LLMの事業者が機能を追加すれば、対処できるようになる可能性があります。この2つは違います。仕組みの上で、対策を書くことができません。
なぜ書けないのか
暗号化でデータを守れるかどうかは、状態によって違います。
| 状態 | 暗号化で守れるか |
|---|---|
| 保管しているとき | 守れます |
| 通信しているとき | 守れます |
| 計算に使っているとき | 守れません |
モデルは、文章を読まなければ次の語を予測できません。ですから、計算をしている間、データはメモリ上で平文と同じ状態になります。これは設計の選択ではなく、計算の仕組みから来ています。
トークンにすることは、暗号化ではありません。公開されている対応表による1対1の変換であり、鍵もなく、元の文章に戻せます。保護の強さは、平文と変わりません。
利用者の側の設定で、この状態をなくすことはできません。保管しているときの暗号化を強めても、通信を専用の経路にしても、計算をしている間は平文です。
画面に表示されている間のデータも、同じです。表示しなければ利用できません。
なお、手段が無いことと、危険であることは別です。どこに自社で対処できないかを、先に確定させています。
段階6——契約で何が約束されているかを確認する
設定の画面で止めたつもりでも、契約上は保持され得ます。そこで契約を確認しました。
ここで、設定の画面をいくら探しても出てこないことが分かります。学習に使うかどうかの既定が、契約の種類で決まっていることです。
| 契約の種類 | 適用される契約 | 対象 |
|---|---|---|
| 消費者向け | 消費者向け規約とプライバシーポリシー | 無料のプラン、個人の有料プラン |
| 法人向け | 商用利用規約とデータ処理付随契約 | 法人向けプラン、API |
消費者向けの契約では、学習に使う設定が既定で有効です。法人向けの契約では、顧客の入力と出力を学習に使わないことが規約に明記されています。
有料かどうかは関係ありません。個人向けの上位プランは、月額が高くても消費者向けの契約です。「お金を払っているから大丈夫」は、成り立ちません。
そして、法人向けにも例外が3つあります。
評価や意見を送ったとき（フィードバック）。利用者が自分から送った内容は、学習の対象になり得ます。
顧客が自分でモデルを追加学習させるとき。この用途は、学習禁止の適用外と定められています。
開発への参加を有効にしたとき。任意の設定であり、有効にすると、提出したデータを学習に使えるようになります。
このうち後の2つは、主たる規約ではなく「サービス個別条件」という別の文書が定めています。そして同条件は、主たる規約に優先すると自ら定めています。
主たる規約に「学習に使いません」と書かれていても、それだけでは、実際に何が禁じられているかは分かりません。優先すると定められた側の文書を読む必要があります。
段階7——誰に渡るかを確認する
ここまでは、LLMの事業者の内側の話です。しかし、預けたデータは、LLMの事業者だけが扱っているわけではありません。
そこで、公式の委託先一覧、契約文書、機能ごとの記事から、どの会社へ渡るかを確認しました。
データが保管されている設備は、LLMの事業者のものではありません
LLMの事業者側に保管されるデータは、Google Cloud、AWS、Microsoft Azure という3社のクラウドの上にあります。通信の経路には Cloudflare が使われています。
つまり、データを預けた相手はLLMの事業者ですが、そのデータが実際に保管されているのは、別の会社の設備です。
業務ごとに、別の会社へ渡ります
委託先は20社あります。
このうち、サポート業務を担っているのは、南アフリカとカナダの会社です。問い合わせの内容や、そこに添付した資料は、この会社が扱います。
Web検索の機能を使うと、検索の語は Brave Search と TurboPuffer という2社へ送られます。いずれも米国の会社です。
ここから分かるのは、渡る先の国が一つに定まらないことです。保管される場所は米国だけで、他の地域を選ぶ設定はありません。処理が行われる場所には、米国に限る設定があります。ただし、この設定を明示的に行わなければ、既定では世界のどこかで処理されます。そして、米国に限る設定を行っても、委託先の会社の所在までは決まりません。サポートに問い合わせれば、その内容は南アフリカかカナダの会社へ渡ります。
ここで、調べ尽くしても分からないことが出てきます。
公式の委託先一覧に記載されているのは、会社名、何の役務を担っているか、どの国にあるか、どの製品が対象か——この4つだけです。
各社へ何が渡り、どれだけ保持されるかは、記載されていません。
各社が自ら公表している資料もありますが、それはその会社の一般的な方針であって、LLMの事業者がその会社へ何を渡しているかを示すものではありません。
つまり、渡る先は分かります。渡る中身は分かりません。
これは、確認の仕方が足りないのではありません。公表されていないため、利用者の側に確認する手立てがありません。
段階8——自社の区分に当てはめる
ここまでで、何がどこに保管され、どこまで対処でき、誰に渡るかが分かりました。
しかし、「機密情報を入れてよいか」には、まだ答えていません。
答えるには、もう1つ必要な情報があります。自社が、どの情報をどれだけ守るべき情報として扱っているかです。
同じデータでも、会社によって扱いが変わります。顧客の名簿を最も重い区分としている会社もあれば、営業秘密だけを最上位としている会社もあります。国外への持ち出しを禁じている会社もあれば、定めの無い会社もあります。
ですから、ここから先は各社ごとに違います。
この段階で行うのは、自社の情報の区分と、ここまでで確認した事実を突き合わせることです。
- 自社の最も重い区分の情報は、削除の操作ができない保管先に残ってよいか
- 保管されているかどうかが公表されていないデータがあることを、受け入れられるか
- 組織の側から確認できない活動が成立することを、受け入れられるか
- 米国に保管され、20社の委託先へ渡り、その中身が公表されていないことを、受け入れられるか
受け入れられない項目があれば、その原因になっている機能を使わないという判断になります。すべての機能を使わなければ、呼び出して答えを受け取るだけの使い方に近づきます。一部を使えば、その分だけ、確認できないデータが残ります。
扱う情報の重さと、機能から得られる利益との釣り合いで決めることになります。
確認したのは、Claude.ai の法人向けプランです。しかし、確認した順序そのものは、どのサービスでも同じです。
| 段階 | 前の段階までで分からないこと | その段階で判明したこと |
|---|---|---|
| 1 機能を洗い出す | そのサービスに何ができるのかが分かりません。機能が分からなければ、データの行き先も分かりません | 法人向けプランには85の機能がありました。日常的に使うのはごく一部ですが、既定で有効な機能もデータを動かします |
| 2 機能ごとに公式文書を読む | 機能があると分かっても、保管先・保持期間・削除の可否が分かりません | 公式文書に記載の無い項目があります。規約違反の疑いで印が付くと、入力と出力は最長2年、分類に使われた数値は最長7年、削除の対象になりません |
| 3 データが通る道筋を整理する | 保管先が分かっても、どこで生じどこを通るのかが分からなければ、途中で止められるかを判断できません | 持続するデータは、周辺ストレージ層に集まります。会話を終えても履歴は残ります。モデルに入る一本の列は8つの区分から成り、利用者が直接書いたのは3つだけです |
| 4 データの所在を書き出す | 機能ごとの保管先だけでは、同じデータが複数の場所に複製されることを捉えられません | 入力した文章は、会話の履歴・フィードバックによる複製・メモリ機能の記録に分かれて保管され、削除の操作の可否がそれぞれ違います。保管の有無が公表されていないデータと、組織からは確認できないデータがあります |
| 5 手を打てるかを確認する | 所在が分かっても、自社で対処できるのかが分かりません | 手段が無い項目が残ります。このうち計算をしている間のデータと表示されている間のデータは、仕組みの上で対策を書くことができません |
| 6 契約を確認する | 設定の画面で止めたつもりでも、契約上は保持され得ます | 学習に使うかどうかの既定は、契約の種類で決まります。法人向けにも例外が3つあり、うち2つは、主たる規約に優先すると自ら定める別の文書にあります |
| 7 誰に渡るかを確認する | 事業者の内側だけを確認しても、外部の会社へ渡る分が分かりません | 委託先は20社です。渡る先は分かりますが、各社へ何が渡り、どれだけ保持されるかは公表されていません |
| 8 自社の区分に当てはめる | 事実が揃っても、「入れてよいか」の答えは出ません | 判断は、自社が何をどれだけ守るべき情報としているかで変わります。ここから先は、各社ごとに違います |
前の段階の結果が次の段階の入力になりますので、順序を入れ替えることはできません。機能が分からなければデータの行き先も分からず、行き先が分かっても、途中で止められるかは判断できません。
そして、すべての段階を踏んでも、分からないことが残ります。保管されているかどうかが公表されていないデータ、委託先へ渡る中身。これは、調べ方が足りないのではありません。
どこが分からないのかを特定できたことが、確認の結果です。
「学習に使わないから大丈夫」という判断では、この検討手順の全部が抜け落ちます。学習に使わないという約束は守られています。それでも、データはどこかに保管され、誰かに渡り、消せないデータが残ります。
答えを出すのは、読者の組織です。この記事が示したのは、答えではなく、確認の対象と順序です。
なお、Amazon Bedrock について同じ確認を行った記事があります。AWS の内側でモデルを呼び出す形の場合に、何が保管され、どこで処理されるかを、機能ごとに確認したものです。