はじめに
AI について話していると、「この会話を AI が学習した」「この資料を AI に覚えさせた」という表現をよく耳にします。
もちろん、日常会話としては通じます。ただ、AI をサービスや業務に組み込むときには、学習したのか、入力として参照しただけなのかを分けて考えたほうがよいと思っています。
プロンプトに資料を貼り付けること、RAG（Retrieval-Augmented Generation）で検索結果を渡すこと、エージェントに過去の会話を参照させること、ファインチューニングを実行すること。これらは、どれも AI の応答を変える可能性があります。しかし、同じ「知識が増えた」という言葉でまとめると、保存場所も有効期間も削除方法も分からなくなります。
この記事では、AI に関わる「学習」と「一時的な記憶」を、いくつかの層に分けて整理します。特定のサービスの利用規約を解説する記事ではなく、AI の機能を設計・説明するときの考え方をまとめる記事です🧭
まず「学習」という言葉を分ける
厳密には、学習はデータそのものではありません。データを使ってモデルのパラメーターを更新し、次に入力されたものへの振る舞いを変える訓練の過程です。
そのため、「学習に使うデータ」と「学習した結果としてできたモデル」は別のものです。会話ログを保存しているだけでは、それだけでモデルが学習したことにはなりません。
ここで区別したいのは、モデルの訓練と、それ以外の仕組みです。モデルの訓練では、データや報酬を使ってパラメーターを更新します。ファインチューニングでは、すでにあるモデルに追加のデータを与えて、特定のタスクや形式に向くように訓練します。
一方で、プロンプトや添付資料は、そのリクエストのコンテキストとして渡されます。RAG では検索した情報を推論時のコンテキストに加えます。アプリケーションの記憶では、会話の要約や利用者の属性などを別の場所に保存し、次回のプロンプトに含めることがあります。これらはモデルのパラメーターを更新しなくても実現できます。
応答が変わったからといって、すぐに「学習した」とは言えません。まず、モデル自体が変わったのか、モデルに渡された入力が変わったのかを確認する必要があります。
モデルを作るときの学習
一般的な LLM は、大量のデータを使った事前学習によって、言語のパターンや知識の表現をモデルのパラメーターに取り込みます。ここでいう「取り込む」は、データベースの文章をそのまま検索できる形で保存する、という意味ではありません。
その後、望ましい応答の例を使った教師ありファインチューニングや、人間・評価器からのフィードバックを報酬として利用する強化学習系の手法などが使われることがあります。
ここで、強化学習も「人間の会話をそのまま記憶する仕組み」と捉えないことが大切です。報酬や評価を手がかりに、より望ましい振る舞いになるように訓練する仕組みです。何を報酬とするか、どのデータを使うか、どの手法を使うかは、サービスや訓練段階によって異なります。
ファインチューニングは、すでにあるモデルに対して追加の訓練を行うものです。「あとから知識を付け足す」という説明が便利な場合もありますが、実際には単純な知識ベースの追加とは違います。特定の形式、タスク、文体、判断の傾向を身につけさせる用途として説明したほうが誤解が少ないでしょう。
「このデータを学習に使う」という説明を見たら、モデルのパラメーターを更新する訓練なのか、保存・評価・検索に利用するだけなのかを確認しましょう。
プロンプトとコンテキストは「その場で渡す情報」
プロンプトに資料を貼り付けると、モデルはその資料を踏まえた回答を生成できます。しかし、それは通常、モデルそのものが資料を学習したという意味ではありません。
資料はリクエストの入力、つまりコンテキストとして扱われます。応答を生成するためには役立ちますが、別のリクエストで自動的に同じ知識を使えるとは限りません。コンテキストウィンドウの上限や、会話履歴をどこまで送るかという実装上の制約もあります。
この違いは、回答ができるまでの流れを思い浮かべると分かりやすくなります。訓練データは訓練を経てモデルのパラメーターに影響します。一方、プロンプト、会話履歴、RAG の検索結果、アプリケーションに保存された記憶は、推論の直前にコンテキストとしてモデルへ渡されます。モデルは、それらのコンテキストと自分が持つパラメーターを使って回答を生成します。
同じ回答の中に、モデルがもともと持っていたパターン、今回のプロンプトから得た情報、検索結果、アプリが保存していた記憶が混在することがあります。利用者から見ると一つの「AI の知識」に見えますが、システムの中では出どころが違います。
RAG は「知識をモデルに焼き付ける」ことではない
RAG は、質問に関連する文書を検索し、その結果を生成モデルへの入力に含める構成です。元論文では、モデル内部のパラメトリックな記憶と、外部インデックスのような非パラメトリックな記憶を組み合わせる考え方として説明されています。
したがって、RAG のインデックスに文書を追加したことを、「LLM がその文書を学習した」と表現すると、少しずれます。多くの場合、変わったのはモデルの重みではなく、検索対象のデータと検索・注入の処理です。
この違いは、文書を扱う仕組みを設計するときに重要です。文書を差し替えれば検索結果を更新できます。アクセス権を確認して、利用者ごとに検索対象を変えることもできます。逆に、検索が失敗したり、古いインデックスを見ていたりすれば、モデルが知識を忘れたのではなく、参照経路に問題があるのかもしれません🔎
エージェントの「記憶」もいくつかに分かれる
エージェントが過去の会話を覚えているように見える場合も、実装はいくつか考えられます。直前の会話履歴を次のリクエストにも送っているだけかもしれません。過去の会話を要約してプロフィールやメモとして保存している可能性もあります。ベクトル検索で過去の発言を探し、関連するものだけをプロンプトへ渡している場合もあります。外部システムのデータをツール経由で取得していることもあるでしょう。また、その会話やデータが、将来のモデル訓練に利用されるケースもあります。
これらは、利用者からはどれも「覚えている」と見えます。しかし、削除の方法は同じではありません。会話履歴を削除しても、別に保存された要約や検索インデックスが残る設計はあり得ます。反対に、保存されていない一時的なコンテキストは、リクエストが終われば次回の入力には使われません。
そのため、AI 機能の仕様を書くときは、「AI が覚えます」とだけ説明しないほうが親切です。たとえば「会話を保存し、次回のプロンプトに要約を含めます」と書けば、アプリケーションの記憶であることが伝わります。「文書を検索インデックスに登録し、回答時に関連箇所を取得します」と書けば、資料を RAG の参照元として扱うことが分かります。
「使うほど賢くなります」という表現も注意が必要です。実際には、評価データを蓄積して後日のモデル改善に利用するのかもしれませんし、単に利用者の好みを保存して次回のプロンプトへ含めているだけかもしれません。「一時的に記憶します」という場合も、現在のリクエストのコンテキストとして参照するのか、一定期間だけ履歴に残るのかで意味が変わります。
「会話を学習に使う」のはどの層か
この表現が特に混乱を招きます。
あるサービスが「会話をモデルの改善に使う」と説明している場合、一般には、会話データが将来の評価や訓練のデータ候補になるという意味です。それは、今この瞬間のモデルが会話内容をパラメーターに反映したという意味でも、次の応答で必ずその会話を思い出すという意味でもありません。
一方、「この会話を次回も参照します」という機能は、会話履歴や保存メモリーなど、アプリケーション側の記憶である可能性があります。さらに、「この資料を使って回答してください」は、コンテキストや RAG の話です。
ここでは、まずどこに保存されるのかを確認する必要があります。そのうえで、次の応答で参照されるのか、モデルのパラメーターを更新する訓練に使われるのか、削除や利用停止をどの設定・手順で行えるのかを確認します。
この問いに答えられないまま「学習します」とだけ説明すると、利用者は保存、参照、訓練、公開範囲を混同してしまいます。逆に、この四つを順番に説明できれば、同じ「覚える」という言葉でも、どの仕組みを指しているのかを共有しやすくなります。
開発者が設計で意識したいこと
AI を組み込む側では、「知識を与える」と考える前に、どの層に何を置くのかを決めると整理しやすくなります。最新の社内文書を回答に使いたいのであれば、まず RAG や外部検索を検討します。その場合は、文書の更新、利用者ごとの権限、回答への引用、削除時の扱いが重要になります。
出力形式を安定させたいのであれば、プロンプトや例示を工夫し、必要に応じてファインチューニングを検討します。ここでは評価方法、再訓練の方法、モデル更新時の互換性が問題になります。利用者の好みを次回も反映したいのであれば、アプリケーションの記憶として保存し、保存期間や訂正・削除の方法を用意します。
望ましい振る舞いをモデルそのものに反映したい場合は、評価データや追加訓練の話になります。今回だけ資料を参照したいのであれば、コンテキストとして渡し、保持範囲、入力上限、ログへの記録を確認します。このように目的から逆算すると、「とりあえず学習させる」という発想を避けやすくなります。
機密性の高い情報を扱う場合は、モデルの性能だけでなく、データの保存先、アクセス制御、ログ、削除の伝播まで確認する必要があります。特に「学習には使わない」という説明だけでは、履歴や検索インデックスに保存されないことまで保証するとは限りません。
AI の仕様説明では、「モデルが知っていること」「今回参照したこと」「アプリが保存していること」「将来の訓練に使われる可能性」を別々に書くと、利用者との認識合わせがしやすくなります。
おわりに
AI が新しい情報を踏まえて答えたとき、私たちはつい「AI が学習した」と言いたくなります。
しかし実際には、モデルの訓練、ファインチューニング、プロンプトのコンテキスト、RAG の検索結果、エージェントの保存メモリーなど、異なる仕組みが同じような見た目の応答を作っています。
「学習」という言葉を広く使うこと自体が悪いわけではありません。ただし、設計やデータの取り扱いを考えるときには、どの層が変わったのかを言い直す必要があります。
会話を入れたらモデルが学習したのか。資料を渡したらモデルの知識になったのか。エージェントが覚えているものはどこに保存され、いつまで残り、どう削除できるのか。
この問いに答えられるようにしておくことが、AI を安心して使うための最初の設計だと思います🧠