「書類をAIに読ませたら間違いが見つかった」なんて話、最近よく聞きますよね。 便利は便利なんですが、ふと「あの値、送った後どうなってるんだろう」と気になったことはありませんか。 今回はその「送った後」を、図を使いながらのんびり追いかけてみます。

この記事からわかること

  • LLMに文書を「送信」「推論」「保存」「学習」は、それぞれ別の段階であること
  • 送信したデータが必ず学習に使われるわけではないこと
  • 「学習されない」からといって外部サービスへ送信していないわけではないこと
  • 決算書や請求書などの数値データを投入する際、特に確認すべき論点
  • サービス形態(個人向け・法人向け・API)によってデータの扱いが異なること

決算書類の確認を、AIに複数の書類を読ませて数字を突き合わせたら 記入漏れや数字の不整合を発見できた。

こうした使い方は、LLMの用途としてはごく自然なものです。複数の文書を横断して、

  • 数字の突合
  • 合計値の確認
  • 記入漏れの検出
  • 文書間の不一致の検出 といった作業を行わせることは、人間が一つずつ確認する作業をLLMに補助させる、実用的な使い方だからです。

ただし、ここで一つ分けて考える必要があります。

「LLMがその数字を読んだ」ことと、「その数字がLLMの学習データになった」ことは同じではありません。

では、LLMに決算書や請求書などの数値入り文書を投入すると、データは実際にどこへ流れるのでしょうか。クラウド型LLMサービス一般の仕組みに沿って整理します。


1. 見た目の単純さと、実際の経路

数値チェックにLLMを使う場合、利用者から見た用途はシンプルです。

図1

一見すると「文書→LLM→回答」だけに見えますが、多くのクラウド型LLMサービスでは、この裏側に複数のデータ処理経路が存在します。


2. 全体像

図2

ここで重要なのは、

入力された文書が必ずそのままモデル学習に使われるわけではない

という点です。多くの主要LLMサービスでは、サービスの契約・プラン・設定によって、

  • 推論処理のために一時的に処理される
  • 会話履歴・監査ログ・安全対策用ログとして保存される
  • 人間によるレビュー対象になる場合がある(不正利用対策など)
  • モデル改善・学習に利用される場合がある
  • 学習には利用されないが、一定期間保持される というように扱いが分かれるのが一般的です。実際、多くの事業者向け・API向けプランでは「デフォルトで学習に利用しない」ことを明示している一方、個人向けの無料プランなどでは学習利用がデフォルトで有効になっている場合もあり、この違いはサービスごとに確認が必要です。

したがって、

「LLMに入力した瞬間、その数字が学習モデルへ直接書き込まれる」

という単純な構造ではありません。一方で、

「学習されないなら、外部サービスへデータを渡していない」

という意味でもない点に注意が必要です。


3. 「数字」がどう扱われるか

例えば、次のような文書を投入したとします。

2026年度 決算書
 
売上高       128,400,000円
売上原価      71,200,000円
営業利益      18,600,000円
現預金        42,300,000円
借入金        15,000,000円

これに対して、

この決算書の数字を確認して、
合計値や前年比の矛盾を指摘してください。

と送ります。概念的な処理の流れは次のようになります。

図3

ここで、

「モデルが数字を読んで回答した」

ことと、

「数字が将来のモデル学習データとして利用された」

ことは、分けて考える必要があります。


4. シーケンス図:文書を投入して回答を得るまで

図4

この段階で、元の文書は少なくとも推論処理のためにLLMサービス側へ送信されています。ここから先には、

  • どのデータが保存されるのか
  • どの期間保存されるのか
  • 安全対策等に使われるのか
  • モデル改善に使われるのか という別の論点が出てきます。

5. 「事業者側に吸収される」を分解する

「事業者側に吸収される」という表現を、そのまま「学習される」という意味に受け取ると、少し雑な理解になります。技術的には、少なくとも次の段階に分けて考えられます。

図5

つまり「送信された→推論に使われた→保存された→モデル改善に使われた→将来のモデルに反映された」という5つは、それぞれ別の状態です。特に、

「LLMが回答のために数字を読んだ」

ことと、

「その数字が将来のモデルの学習データとして利用された」

ことは、別の事象です。


6. モデル学習まで含めたシーケンス

モデル改善にユーザーデータが利用されるサービス・プラン・設定の場合は、さらに別の経路が存在します。

図6

ここでも、「入力したデータが存在する」ことと、「そのデータが学習データセットへ入る」ことは別です。


7. ユースケース

数値入り文書をLLMに扱わせる用途には、例えば次のようなものがあります。

図7

問題になるのは、そのために元データを外部LLMサービスへ送信する必要があることです。


8. 数値データの場合に特に問題になる理由

決算書や請求書などは、単なる一般的な文章とは性質が異なります。例えば、

売上高       128,400,000円
営業利益      18,600,000円
現預金        42,300,000円
借入金        15,000,000円

のようなデータには、売上規模・利益規模・現金保有額・借入額・取引金額・単価・件数・契約金額・原価・支払条件などが含まれます。これらは文章の意味を解析するだけでなく、企業・個人・取引先の財務状態を推測できる情報になり得ます。

さらに複数資料を投入すると、次のように単一文書では分からなかった関係まで見えるようになります。

図8

9. データフローとして置き換える

図9

ここで問題になるのは「AIが数字をチェックできるか」だけではありません。同時に、「その決算書類を、そのLLMサービスへ送信してよい契約・運用になっているか」を確認する必要があります。


10. 人間による確認との違い

人間が決算書を確認する場合はシンプルです。

図10

一方、LLMサービスを使う場合は次のようになります。

図11

つまりLLMを利用する場合、「誰が読むのか」だけでなく、「どの事業者のシステムを通過するのか」もデータ管理上の論点になります。


11. 「AIに全部読ませればいい」はどこまで正しいか

決算書A
請求書B
売上一覧C
        ↓
       LLM
        ↓
「この3つの数字を照合してください」
        ↓
不一致箇所を列挙

という処理は、LLMのユースケースとして十分成立します。しかし、ここには二つの別の判断が含まれています。

図12

LLMの精度が高くても、データ管理上の制約が消えるわけではありません。


12. 「AIに食わせると全部学習される」は正確ではない

次の3つは分けて考える必要があります。

状態 意味
推論 入力データを回答生成のためにモデルへ渡す
保存 履歴・ログ・安全対策等の目的でデータを保持する
学習 データをモデル改善・訓練工程へ利用する

したがって、「AIに送信した ≠ AIの学習データになった」です。一方で、「AIに送信した = 少なくともサービス提供者の処理環境にデータを渡した」という点は、別問題として残ります。


13. サービス形態による違い

図13

ここは「LLMだからこうなる」のではなく、「利用しているサービスのデータポリシーによって決まる」部分です。同じモデルでも、個人向けUI・法人向け契約・APIではデータ利用条件が異なることが一般的にあります。


14. 「学習されない」だけでは確認が終わらない

例えば「入力データをモデル学習には利用しません」という条件があったとしても、次のデータフロー自体が消えるわけではありません。

図14

したがって、「学習には使われない」と「外部サービスへ送信されない」は同じ意味ではありません。


15. RAGなら「学習」とは別

社内文書をLLMに検索させるRAG(検索拡張生成)構成では、次のような構造になります。

図15

この場合も「RAGで参照した ≠ モデルを再学習した」です。ただし、RAGの構成によっては、検索対象文書や取得したチャンクを外部LLMサービスへ送信することになります。したがって「学習されるか」とは別に、「どこへ文書を送信しているか」を見る必要があります。


16. 特に避けるべき入力

機密性の高い文書をLLMへ投入する場合、次のような情報には特に注意が必要です。

図16

特にパスワード・APIキー・秘密鍵・クレジットカード情報・未公開の財務情報・顧客名簿・個人の口座情報などは、「AIが正しく処理できるか」より前に、「外部サービスへ渡してよいデータか」を判断する必要があります。


17. 実際に確認すべき項目

機密性の高い文書をLLMへ投入する場合、少なくとも次を確認します。

確認項目 確認する内容
送信先 どの事業者・どのサービスへ送られるか
保存 入力データや会話が保存されるか
保存期間 いつまで保持されるか
アクセス 誰・どの仕組みがアクセス可能か
安全対策 不正利用検知等で利用されるか
モデル改善 学習・モデル改善に利用されるか
オプトアウト 学習利用等を拒否できるか
契約 個人向け・法人向け・API等で条件が違うか
削除 データ削除が可能か
委託先 第三者・関連事業者等へ渡る可能性があるか

18. 最も重要な整理

ここまでを一つの図にまとめると、次のようになります。

図17

つまり、

送信 ≠ 保存 ≠ 学習

です。さらに、

学習されない ≠ 外部サービスへ送信されない

でもあります。


19. まとめ

LLMへの文書投入を、「文書 → AIが読む → 答えが出る」だけで捉えると、データ管理上の経路を見落とします。実際には、

文書
 ↓
LLMサービスへ送信
 ↓
推論
 ├─→ 回答
 ├─→ ログ・履歴
 ├─→ 安全対策・不正利用検知
 └─→ 条件によってはモデル改善用データ
             ↓
          学習工程
             ↓
          将来のモデル

という複数の経路を考える必要があります。特に、

「学習されるかどうか」と「外部サービスへデータを渡すこと自体」は別問題

です。「学習には使われません」というサービスであっても、入力データがサービス側の処理基盤を通過すること自体まで否定しているわけではありません。

そのため、機密性の高い文書をLLMに投入する場合は、「どこへ送信されるか → 何を処理するか → 何が保存されるか → 誰が利用できるか → 何の目的で利用されるか → モデル改善・学習に利用されるか」まで分けて確認する必要があります。


参考

  • OWASP Top 10 for LLM Applications 2025 — LLM02:2025 Sensitive Information Disclosure(2025年版で第2位に位置づけられているリスク項目。学習データの記憶・再現や、システムプロンプト・機密情報の意図しない開示などを扱う) ※ 実際のデータ利用条件は、LLMサービス・プラン・契約・API利用・設定等によって異なります。機密情報を扱う場合は、対象サービスの最新の利用規約・プライバシーポリシー・データ利用条件を必ず確認してください。