「Claude 1Mトークン」がAIの記憶力向上ではない理由

0. はじめに

M1までで、retrievalの4層構造をひととおり見ましたね。今回のM2では、そのすぐ横にくっついているテーマ、「LLMが記憶する」という言い方の実体 を扱います。retrievalとmemoryは根っこは同じなのに、動き方はけっこう違うので、一度分けて見たほうがニュースのヘッドラインが正しく読めます。

最近どこかでこんな文言を見た記憶があるはずです。「Claudeがついに100万トークンをサポート」とか、「Gemini 2Mコンテキストで AIの記憶力が劇的に向上」のような表現。私も最初に見たときは「おお、AIがこれからは古い会話もよく覚えてくれるな」と思いました。ところが実際に使ってみると、やはりセッションを閉じて開き直すと、AIは昨日の話を忘れています。なぜでしょうか。

答えは単純です。その「1Mトークン」が指しているのは「記憶力」ではなく「一度に広げられる作業机の大きさ」です。 そしてその作業机の大きさは、「セッションを越えて記憶する能力」とはまったく違う軸です。ここが混ざってしまうと、プロダクトを選ぶときも、APIコストを見積もるときも、プロンプトを組むときも、ずっと嚙み合いません。

今回の記事は、長いコンテキストと記憶という言葉の中に混ざっている3つの別の概念を、一つずつ分けて見ることが目標です。Context Window、Session Memory、Persistent Memory という3つの軸です。名前が似ているので紛らわしいですが、内部のメカニズムはまったく違います。これを分けて見られるようになると、「Claude 1Mトークン」のようなニュース1行から得られる情報量が大きく変わります。

進度に合わせて言うと、FシリーズとBシリーズでトークンとattentionまで見て、M1でretrievalを見たので、今回の回は その知識の上に重ねる最後の一層 と思ってください。話し口調でゆっくり進めます。

1. 「Claude 1Mトークン」というヘッドラインが取りこぼすもの

まずヘッドラインをひとつ。2025年後半にAnthropicからClaude Sonnetの1Mトークン版が出ました。そのとき技術コミュニティでもっとも多く見た反応がこういうものでした。「AIがついに本1冊を丸ごと覚えるね。」似た反応はGemini 2Mのときもあったし、GPTのコンテキストが伸びるたびに繰り返されます。

ところが 「記憶」という単語がここでは間違っています。

この「1Mトークン」がやっていることは正確にこうです。あなたが1回のAPI呼び出しに入れられるプロンプトの最大長さが、100万トークン程度まで伸びた。本1冊でも、コードベース全体でも、1年分の議事録でも、プロンプトに貼って一度に入れれば、モデルがそれを「この回の返答で参考にする材料」として読んでくれる。返答が終わればその材料は消えます。次の呼び出しではまた入れ直さないといけません。

これは「記憶」というよりも 「今回、机に乗せられる紙の量が増えた」 に近いです。試験のとき机の上に教科書を1冊広げられる状況と、10冊広げられる状況の違い、みたいなものです。机は大きくなったけれど、試験が終われば机は初期化されます。「あの生徒が勉強をいっぱいしている」ではなく、「あの生徒が試験1回で参照できる本が増えた」が正しい解釈です。

なぜこの区別が大事かというと、この2つを混ぜるとプロダクトの判断がぜんぶ狂い始めるんです。例えば「AIの記憶力が上がったから、うちのサービスはユーザープロフィールを別途保存しなくてよくなるね」と誰かが言ったら、それは間違った推論です。1Mトークンはそのプロフィールを保存してくれません。毎回プロンプトに貼って初めてモデルが見ます。貼る行為自体にトークンコストがかかりますし。

反対方向に狂うケースもあります。「記憶機能が入ったなら、ChatGPTが私の恋愛の悩みを一生覚えてくれるんだ」みたいな解釈。これは2024年にChatGPT Memory機能が出たとき、実際によく見た反応です。その機能は あなたが言ったことのうち数個の短いノートだけを取り出して別途保存しておく装置 であって、モデル自体があなたの恋愛史を学習したわけではありません。メカニズムがまったく違うんです。

だからこの記事の目標はこうです。「長いコンテキスト」と「記憶」を混ぜずに、3つの層に分けて見ること。3つの層はそれぞれ context window、session memory、persistent memory です。ここから1つずつ入っていきます。

2. Context Window — 作業机に乗せられる紙の最大量

P4でattentionを丁寧に見ましたね。そこでの核はこの一行でした。「全てのトークンが全てのトークンを見る。」 この性質が コンテキストウィンドウ の大きさに直結します。

Attentionがやっていることを思い出しましょう。文の中にN個のトークンがあると、各トークンは自分のQueryを持って残りN個のKeyと比較し、スコア表を作ります。だから大きさN×Nのスコア表ができます。トークン数が2倍になるとスコア表のマス数は 4倍 。これが O(n²)複雑度 と呼ばれる話の実体です。

ここで「1Mトークンをサポートする」という言葉の重みが見えてきます。トークンが2,000個だった時代のスコア表は400万マス。トークンが100万個になるとスコア表は 1兆マス 。同じattention計算をするには、メモリと計算量が25万倍に跳ねます。GPU1枚ではとても無理です。

だから実際に1Mコンテキストをサポートするモデルたちは、いくつか工学的な工夫を使います。Flash Attentionでメモリアクセスを最適化したり、Sliding Window Attentionで全トークンでなく近いトークンだけを見るようにしたり、Linear Attentionのような近似計算で複雑度を下げたり。こういう技術が積み重なって「1Mをサポート」が実現されます。つまりこの「1M」という数字の裏には、「元のattentionをそのまま回すと無理なコストなのを、あれこれ工夫して回るようにした」 という技術的な痛みが隠れているんです。

では、なぜこんな工夫をしてでもコンテキストを大きくするのか。理由は 「作業机」が大きくなるとできることが増えるから です。例えばこういうことが可能になります。

• 長い論文1本を丸ごと入れて「この論文の核となる主張を3文で要約して」と依頼
• コードベース全体を入れて「この関数はどこから呼ばれている?」と質問
• 1年分の議事録を入れて「昨年、Aプロジェクト関連で下した決定3つ何だった?」と質問

従来はこういうことをやるには、retrievalで関連部分を先に取り出すしかありませんでした。長いコンテキストのおかげで「全部投げておいて、うまく探して」が可能になったんです。便利になりました。

でも、覚えておいてほしいことがあります。この「作業机」は揮発性です。 返答が終われば、机に乗せた紙は全部払い落とされます。次の呼び出しでは空っぽの机からスタートします。だから1Mトークンを「AIの長期記憶」と呼ぶのは正確ではありません。長期記憶は次の呼び出しにも残らないといけないのに、これは今回の呼び出しの中でしか生きていない空間ですから。

一行にまとめるとこうです。Context windowは1回の呼び出しで「モデルが読む材料」の最大長。記憶の容量ではない。 この感覚を握って次のセクションに行きましょう。

3. 長いコンテキストで崩れる問題 — 「Lost in the Middle」

大きな作業机には罠が1つあります。机が広くなったからといって、すべての紙を同じようにちゃんと読んでくれるわけではない。

StanfordのLiuらが2023年に出した「Lost in the Middle: How Language Models Use Long Contexts」という題の論文があります。ここで著者らがある実験をしました。モデルに長〜い文書をひとつ渡し、その中のどこかに「正解文」を埋め込んでおいて、質問を投げる。正解文を 文書の前のほう に置いたとき、中央 に置いたとき、後ろのほう に置いたときで、それぞれの正解率を比較する。

結果はかなり印象的でした。前と後ろに正解があるときは、モデルはちゃんと見つけました。ところが 正解が文書の中央 にあるときは、正解率がガクッと下がります。モデルによって差はありますが、多くの場合、中央の正解率が前/後ろの半分くらいまで落ちることもありました。論文はこの現象を 「Lost in the Middle(中央で迷子になる)」 と呼びました。

比喩にしてみますか。100ページの教科書を1日で読み通さないといけないとしましょう。最初の10ページは集中して読みます。最後の10ページは終わりが見えるのでまた集中します。ところが40ページ〜60ページの間は眠くて目が滑る。人間もそうだし、モデルもそういう傾向があります。これがなぜ起きるのかは完全に解明されたわけではないですが、いくつか仮説があります。位置エンコーディングが長い距離で薄れる影響、学習データ自体の分布(文書の前と後ろに重要な文が多い偏り)、attentionが近いトークンに少し寄る傾向、などなど。

この現象が実務に与える教訓はこうです。「1Mコンテキストに全部入れれば勝手に見つけてくれるだろう」が、つねに真ではない。 重要な情報を文書の真ん中奥深くに埋めておくと、モデルが取り出してこない可能性があります。だから長いコンテキストを使うときも、retrievalで「本当に必要な部分だけ絞って上や下に配置する」方法が依然として効きます。M1で見たretrievalがlong-context時代でも死なない理由の1つがここにあります。

この話からもうひとつ引き出せる洞察があります。コンテキストを大きく使うことと、コンテキストをうまく使うことは別の問題だ という感覚。大きさは容量の話、活用は配置と構造の話です。良いプロンプトエンジニアリングのけっこうな部分が「同じ情報をどこに置くか」を悩むことになるのは、ここに理由があります。

4. Session Memory — 対話の「記憶」は実は再添付

さて、1つめの軸(context window)は「1回の呼び出しで使える材料の量」でした。ではChatGPTで対話をやり取りするとき、前に話した内容がつながるのは何でしょうか。2つめの軸、session memory です。ところがこれは名前と実体がけっこう違うので、バラしてみましょう。

想像してみてください。あなたがChatGPTにこう言います。「こんにちは、私の名前はユンジです。」モデルが「こんにちは、ユンジさん、よろしく」と答えます。何ターンか後にあなたが「私の名前、何だったっけ?」と聞くと「ユンジでしたね」と答える。記憶しているように見えますね。

実際には中でこういうことが起こっています。2つめの質問を投げる瞬間、アプリがモデルにこういう形のプロンプトをまるごと送っています。

ユーザー: こんにちは、私の名前はユンジです。
モデル: こんにちは、ユンジさん、よろしく。
ユーザー: (中間の対話ターン …)
モデル: (それへの返答 …)
ユーザー: 私の名前、何だったっけ?

見てのとおり、モデルはあなたの名前を「記憶した」のではありません。アプリが 前の対話全体を毎回プロンプトに再添付して 送っているんです。モデルはそのプロンプトの上のほうで「ユンジ」という文字列を見て、「あ、今回の質問で参照する名前がここにあるな」と答えています。2つめのターンが終わるとその記憶はまた消えます。3つめのターンでは、また最初から貼って送ります。

言い換えれば Session memoryは「モデルの記憶」ではなく「アプリが毎回前の対話を再添付する行動」 です。記憶の錯視。この区別がなぜ大事かというと、実務で起こる多くの問題がこの錯視のせいで発生するからです。

例えばこういう質問。「ChatGPTの対話が長くなると、前半の内容をやたら忘れるんですけど、なぜですか?」本当の原因はこうです。対話が長くなるにつれて、再添付されるプロンプトの長さがモデルのコンテキストウィンドウの上限に近づく。アプリは上限を越えないように、いちばん古い対話ターンから切り捨てたり要約して貼り直したりします。 だから最初にあなたが言った「私の名前はユンジです」が、あるタイミングでプロンプトから消えていて、モデルはその時点から名前を「忘れたかのように」振る舞います。モデルが忘れたのではありません。アプリが見せていないんです。

もうひとつ。「API呼び出しコストが対話ターンが増えるにつれて指数関数的に増えます。」理由も同じです。再添付されるプロンプトが毎ターン長くなるので、入力トークンコストが累積して増えます。10ターン目の呼び出しは1ターン目よりプロンプトがずっと長い。だから長い対話は高くならざるを得ません。

これがわかるとChatGPTがなぜ長い対話で急におかしくなるのか、なぜ同じ質問を新しいタブで投げると答えが違うのか、同じ質問を繰り返しながらなぜコストが跳ね上がるのか、ぜんぶ同じ根っこから説明できます。Session memoryはモデル側ではなくアプリ側のテクニック という感覚がつかめると、これらの疑問がまとめて解けます。

5. Session Memoryの現実的な限界

Session memoryが「前の対話を再添付すること」なら、当然ついてくる限界があります。3つだけ挙げます。

ひとつ、トークン上限に引っかかると前の対話が切られる。 先に話したままです。モデルのコンテキストウィンドウが200Kなら、再添付されたプロンプトが200Kを超えた瞬間に前の対話が消えます。これが「対話が長くなると前の内容を忘れる」現象の正体です。1Mコンテキストのモデルでは上限がずっと大きくなりますが、それでもいつかは引っかかります。

ふたつ、セッションを閉じるとすべて消える。 ブラウザを閉じて明日またChatGPTを開くと、昨日の対話のコンテキストは完全にリセットされています(もちろんアプリが「対話履歴」を保存するUIはありますが、それはアプリがテキストログをDBに保存しただけで、モデルが覚えているわけではありません)。新しいセッションを始めると、モデルの立場ではあなたは初対面のユーザーに戻っています。昨日の対話の内容を今回のセッションに引き継ぎたいなら、あなたが 自分でコピー&ペースト する必要があります。

みっつ、複数の対話をまたぐとすべて別物。 あるセッションで「自分のプロジェクトAについて深く議論」し、別のセッションで「プロジェクトA関連で続きを話そう」と言っても、2つめのセッションのモデルはプロジェクトAを知りません。対話履歴を一緒に再添付しないと、つながりません。

この限界を知ると「AIを長期のアシスタントとして使うには、他に何が必要か」という問いが自然に浮かびます。それが3つめの軸、persistent memory です。

6. Persistent Memory — セッションを越える記憶の4つのやり方

Persistent memoryは文字どおり「セッションが終わっても残る記憶」です。ただ、この「記憶」を実装する方法がいくつもあります。ひとくくりに1語で呼ばれますが、中身はけっこう違うので4つに分けてみます。

(a) RAG — 必要なときに外から持ってくる

M1で丁寧に見た相棒ですね。文書を前もってchunkに切ってベクトルDBに入れておき、質問が来ると関連チャンクをretrievalでプロンプトに貼る方式です。この構造の記憶は 「モデルの外にある検索可能な保管庫」 にあります。セッションが閉じても保管庫は残ります。次のセッションで質問を投げると、また retrieval で取り出して貼ります。

これは「記憶」というより 「外部の検索エンジンをいつも横に置く」 のほうに近いです。モデル自体は何も記憶していません。外の保管庫が記憶しているんです。

長所は 最新性と大容量の処理 。保管庫をリアルタイムに更新でき、数十GBの文書も扱えます。企業の社内文書検索、顧客サポートのチャットボットのようなところに基本構造として使われる理由がこれです。

短所は retrieval品質に完全に依存する こと。検索が見当違いのチャンクを取ると、モデルも見当違いの答えを返します。M1で見た「retrievalの4層」がしきりに出てくる理由がここです。

(b) Summary Memory — 長い対話を定期的に要約して保存

2つめのやり方はこうです。対話が長くなるとアプリが 前のほうの対話を定期的に要約 して短い文章に置き換えていきます。次の呼び出しでは原本の対話全体でなくその要約だけを再添付します。トークンを節約しつつ「おおよその文脈」は維持するテクニックです。

比喩すると 議事録を毎時間、1行に縮めておく ようなもの。原本の録音は捨てて「この時間にはA議題を通した」と1行だけ残すわけです。録音のディテールは消えますが、全体の流れは保てます。

ChatGPTやClaudeの長いセッションが実際に内部でこれを使っています。対話が上限に近づくと前半のターンを自動で要約に置き換えます。ユーザーが知らないうちに行われる処理です。

短所は 要約の過程でディテールが飛ぶ こと。「5ターン目で私が特定の数字を言ったんだけど、あの数字は何だった?」のような質問は、要約以降は答えられない可能性があります。要約がその数字を重要だと判断しなかったら、捨てられているかもしれないですから。

(c) Vector Memory (Episodic Memory) — 対話の断片をembeddingで索引化

3つめのやり方はRAGを「対話履歴」に適用したバージョンです。対話中に出た重要な事実や発話をembeddingベクトルにして別途の保管庫に積んでいきます。次のセッションで新しい質問が来ると、その質問と関連する過去の発話をベクトル検索で取り出してプロンプトに貼ります。

例えばこういう感じ。あなたが先月「私は猫を飼っている」と言ったとすると、その文はembeddingベクトルとして保管庫に入っています。今日「うちの猫が餌をあまり食べない」と言うと、システムが「猫を飼っている」という過去の発話を取り出してプロンプトに貼ります。モデルはまるで記憶したかのように答えます。

これを学界では Episodic Memory と呼ぶこともあります。エピソードのように小さな断片を索引化して、必要なときに取り出す方式だから。ChatGPTのMemory機能が大筋この系列に近いです(後ほど詳しく)。

長所は パーソナライズがきめ細かくなる こと。ユーザーごとに別々の保管庫を作って「このユーザーだけの記憶」を積める。

短所は 検索精度の問題とプライバシー問題 。見当違いの発話が検索されると対話がおかしくなるし、機微な情報が保管庫に残ると漏洩リスクが生まれます。

(d) Memory Adaptation (Doc-to-LoRA) — モデルの重みに直接編入

4つめの方式がいまの3つといちばん違います。モデル自体を小規模に学習させて、記憶を重みの中に入れてしまう 方式です。代表格が Doc-to-LoRA です。

前の3つはぜんぶ「モデルはそのまま、外から情報を取ってきてプロンプトに貼る」構造でした。Doc-to-LoRAは その前提を壊す 方式です。文書を先にモデルへ学習させて、軽い重み差分(LoRAアダプタ)として持っておきます。クエリのときはプロンプトに貼らなくても、モデルはすでに「知っている」状態です。

比喩すると 「毎回参考書を持って試験を受ける(RAG)」と「参考書を勉強して頭に入れて試験を受ける(Doc-to-LoRA)」の違い です。前者は参考書が増えるとカバンが重くなるけど最新内容を使いやすい。後者はカバンは軽いけど勉強した内容しか使えない。

これはセッションを越えても完全に生きている、本当の意味での「記憶」にいちばん近い構造です。モデルの重みに入っているので、アプリが再添付するしないにかかわらず、モデルがすでに内容を持っている。

短所は 学習コストと更新の手間 です。LoRAはフルのfine-tuneより安いですが、タダではありません。文書が変わったら学習し直す必要もある。だから頻繁に変わる動的データには合いません。逆に ほとんど変わらないのに毎回プロンプトに入れるには大きすぎる文書 (会社のオンボーディングハンドブック、数百ページの方針書のようなもの)には非常にフィットします。

この4つの方式を覚えておいてください。次のセクションでChatGPTのMemory機能がこの4つのどれに当たるかを解きます。

7. ChatGPT/Claudeの「Memory」機能は何なのか

2024年の初めからChatGPTに「Memory」という機能が追加されました。Claudeも2025年に似た機能を追加しています。この機能を初めて見たとき、多くの人が「ついにAIが私を覚えてくれる」と受け取りました。実体はどうでしょうか。

機能がやっていることから見ていきます。ユーザーが対話の中で「私の子の名前はジフ」「私はビーガン」のような発言をすると、ChatGPTが 短いノート を自動で作って、アカウントに保存します。ユーザーが「Manage memories」画面を見ると、実際にこういうノートがリストで並んでいます。「User’s child is named Jihoo」「User is vegan」のような行です。

次の対話では、このノートたちが システムプロンプトのように先頭に自動で貼られて モデルに渡されます。だから新しいセッションを始めても、モデルが「こんにちは、ジフのお父さん」のように反応できるんです。

これをさっきの4つの方式と比べると、これが (b) Summary Memoryと(c) Vector Memoryのハイブリッド です。要約したノートを積んでおき(summary)、検索可能な形で索引化(vector)して必要なときにプロンプトに貼る構造ですね。モデルの重みはそのままです。Doc-to-LoRAレベルの本当の編入ではありません。

つまり ChatGPT Memoryはモデルがあなたを「学習」したのではありません。OpenAIがあなたのアカウントに小さなノートファイルを作っておき、あなたが対話するたびに自動でそのノートをプロンプト先頭に添付してくれる機能 です。実体を知ると、次のようなことが自然に理解できます。

• ノートはユーザーが直接見て編集できます。 なぜ? 保管庫の中のテキストだから。モデルの重みならユーザーが取り出せません。
• ノートを消すと記憶が消えます。 なぜ? 保管庫から消えれば次のセッションで添付するものがなくなるから。
• この機能は同じモデルを使う他のユーザーには影響しません。 なぜ? ノートはあなたのアカウントだけに紐づいているから。モデル自体が変わったわけではない。
• データプライバシーの懸念は「モデルに私が学習された」ではなく「OpenAIのサーバーに私のノートが保存されている」です。 懸念の性格が違います。

この感覚をつかむと、「AIの記憶機能」関連ニュースをずっと冷静に読めます。大半の商用プロダクトで「記憶」は(a)〜(c)の組み合わせで、(d)ではない。(d)は企業の内部デプロイや特殊なオンプレ環境で登場する程度です。

8. 長いコンテキスト vs メモリ — いつどちらを

3つの軸を全部見たので、いよいよ実務で「いつどれを使うか」を整理します。これが意外とこんがらがるので、表みたいにしてみます。

Context windowが有利な状況:

• 1回の作業で参照する資料が大量だけど、この1回だけ 参照すればいいケース。例: 長い論文の要約、大容量コードレビュー、1回限りの大量データ分析。
• 資料どうしの 関係 を把握する必要があるケース。例: 「この100個の文書で互いに矛盾する部分を見つけて。」こういうのはretrievalで断片ずつ取ると関係が見えません。全部一緒に並べて見る必要があります。
• 素早くプロトタイプを作るとき。あえてベクトルDBを立てず、プロンプトに全部貼って実験してみられます。

Persistent memoryが有利な状況:

• 同じ情報を 繰り返し 参照するケース。例: 個人プロフィール、会社のオンボーディング文書、FAQベース。毎回プロンプトに貼るとトークンコストが累積します。
• セッションを越えて 維持される必要があるケース。例: ユーザー嗜好ベースのパーソナライズ、持続するプロジェクト状態の維持。
• 資料が 大きすぎて context windowに入らないケース。例: 数GBの社内文書ベース。

この2つは 代替ではなく補完 関係にあります。ほぼすべての実システムで両方を混ぜて使っています。RAGで必要な部分をさらってきて、long-contextの中にきれいに並べる、という具合に。

感覚を渡すための原則をひとつ。「頻繁に変わる・量が多い・今回1回見ればいいものはcontext、頻繁に変わらない・繰り返し参照されるものはmemory。」 この基準で資料を分類してみれば、各資料をどこに入れるかが自然に決まっていきます。

9. 実務パターン — Claude Code・Cursorはどう記憶するか

具体的なプロダクトをひとつバラしてみます。Claude CodeやCursorのようなコーディングアシスタントは、どう「プロジェクトの文脈」を持っているでしょうか。これはよいケーススタディです。

まず結論から。Claude Codeは「記憶の錯視」を使いません。代わりに明示的な再ロードとcompactionで運用します。

分解するとこうです。

(1) セッション内のworkspaceファイル状態。 Claude Codeはプロジェクトディレクトリを認識します。セッション中にファイルが変わったらtool callでファイル状態を読み取ってcontextに反映します。これはsession memoryの自然な拡張です。前の対話で編集したファイルの新しい状態を毎回読み直しているわけです。

(2) 明示的な再ロード (AGENTS.md・CLAUDE.md・memoryファイルの読み戻し)。 新しいセッションを開いたとき「このプロジェクトはこういうものだ」をモデルが理解するには、プロジェクトルートにある CLAUDE.md や AGENTS.md のようなファイルを、毎セッション初めに 意図的に読み戻します。これはpersistent memoryの(a) RAG系の処理です。保管庫がただのファイルシステムで、セッションが始まれば無条件でこのファイルを添付するというルールがあるわけです。

この「明示的な再ロード」が妙に正直な設計です。ユーザーが どの情報がいつモデルにロードされるかを直接見て制御できる。ファイルを編集すれば、次のセッションのモデルの振る舞いが変わります。「AIが魔法のように私を覚えている」フリをせず、「このファイルを読ませたから、この文脈を知っている」とはっきり見せているんです。

(3) Compaction。 セッションが長くなるとコンテキストが埋まります。Claude Codeは一定のタイミングで前半の対話を自動で 要約版に置き換え します。このとき、もとのtool call結果やファイル内容は要約されて簡潔になりますが、重要な部分は残ります。ユーザーは「これからcompactします」という通知を受けて、セッションが続きます。

Compactionがおもしろいのは、単に要約して捨てるのではなく、原本の状態をプロジェクトファイルから読み直せるように残しておく構造 だということ。要約が雑すぎて何かが抜けたと感じたら、モデルがファイル読み取りツールで原本を取り直します。だから「要約のせいで大事なものが飛んだ」という状況が比較的まれです。要約は要約で、原本はディスクにそのままあるので。

この構造が良い理由を ビジネスコーディング以前の状態 → 介入 → 以後の状態 で見るとこう解けます。

• 以前: 従来のコーディングアシスタントはIDEの中にポンと落ちていて、セッションごとに毎回「どのプロジェクトかまた説明しないと」だったり、あるいは「サーバーが勝手に覚えます」と言いながら何を知っていて何を知らないのか曖昧でした。開発者はモデルの「記憶状態」を制御できずに推測するしかなかった。
• 介入: Claude Codeは「毎セッション開始時に特定のファイルを読む」というルールを置いて、モデルの文脈構築を開発者がファイルで制御できるようにしました。そこにcompactionで、長いセッションでも核の状態を維持します。
• 以後: 開発者は「このファイルだけ直せば、次のセッションのモデルの振る舞いがこう変わる」を予測でき、長いリファクタリングのセッションも途切れずに続けられます。結果として「AIがうちのプロジェクトを理解しているか」という曖昧な問いが、「自分がAIに何を読ませたか」という制御可能な問いに変わります。

これが今回の記事の非自明なポイントのひとつです。よいmemoryシステムは「記憶しているフリ」がうまいのではなく、「何を記憶して何を忘れるか」をユーザーが制御できるようにしてくれるもの。 Claude Codeの設計はこの基準でかなりよくできていると思います。

10. やらかしやすい3点

長いコンテキストとメモリを扱うときに、実務者がよくはまる3つの落とし穴を整理します。

(a) 「1Mトークンだから全部入れよう」

1つめの落とし穴。コンテキストが大きくなったから関連文書を全部プロンプトに注ぎ込むケース。2つの問題が起きます。

Lost in the middleで精度が落ちる。 3節で見たように、中央の情報はちゃんと読まれません。100万トークンを入れたのに、モデルが肝心の中央を取りこぼすなら、むしろ10万トークンに絞っておいたほうがよかったかもしれません。

コストが爆発する。 1Mトークンの入力コストが200Kトークンの5倍なのは当然として、問題は 1回の呼び出しでなく繰り返し呼び出しで累積する 点。同じ文書を100回使えば100倍請求されます。Prompt cachingで一部緩和はできますが、根本解決ではありません。

だからcontext windowが大きくなっても 「必要な分だけ入れる」という原則 は依然として有効です。Retrievalが死なない理由です。

(b) 「AIが記憶する」を過信する

2つめの落とし穴。ChatGPT Memoryのような機能があるから、機微な情報を「AIに任せれば勝手に記憶してくれる」と任せるケース。先に見たように、その「記憶」はOpenAIサーバーのノートファイルです。漏洩、共有、削除、ぜんぶあなたの制御の外で起こりうる。

実務ではこう接するのが安全です。「モデルに記憶させる」ではなく「保管庫に記録する」と考える。 保管庫に何が積まれていて、誰がアクセスして、どれくらい残るかを、全部チェックする必要があります。「AIが記憶する」という感覚を取り除くと、これが普通のデータ管理の問題だということが見えてきます。

企業環境なら特に重要です。ユーザーごとのmemoryを商用LLMサービスに預けると、GDPRや個人情報保護法のような規制の論点がすぐ上がってきます。「AIが記憶してくれる」が、法律問題に転化する瞬間がある。

(c) セッション終了=記憶リセット、を忘れる

3つめの落とし穴は少しソフトですがよくあります。昨日長い対話で複雑な文脈を積み上げたユーザーが、今日の新しいセッションで続きをやろうとしてもAIがまったく知らないふりをする。ユーザーは戸惑います。「昨日あれだけ話したのに、なぜ忘れているの。」

解法はシンプルです。セッション間の接続が必要だと認識し、明示的に文脈を引き継ぐ装置を置くこと。 Claude Codeの CLAUDE.md や個人のノートファイルを「セッション開始時に必ず読み込まれるファイル」にしておく方法が、もっとも単純で強力です。

ChatGPT Memory機能を使うとこの一部は自動化されますが、完全ではありません。「重要なものだけ」取り出されて保存されるのですが、その「重要なもの」の判断がAIに委ねられるからです。本当に重要な文脈は、自分で直接メモとして保存し、セッション開始時に貼るのが安全です。

11. Claude Codeのcompactionはなぜ賢い設計なのか

最後に、compactionというひとつの装置に絞って、なぜよい設計なのかを解いてみます。ここまで見てきた概念を総合する復習を兼ねて。

Compactionは長いセッションで前半の対話がコンテキスト上限を圧迫するとき、前半の対話を要約に置き換える手法です。一見「ただの要約置き換え」に見えますが、ディテールがいくつもあります。

(1) 自動要約と手動介入のバランス。 Compactionは自動で起こりますが、ユーザーはそのタイミングを把握できて、必要なら手動で発動もできます。これはモデルの「記憶の整理」をブラックボックスにせず、ユーザーに公開する設計です。先に話した「何を記憶して何を忘れるかが制御可能であるべき」という原則を守るやり方です。

(2) 原本の保存。 要約に置き換わるのは「プロンプトに貼るもの」であって、実際のファイルやツール呼び出しの結果はディスクにそのまま残っています。モデルが「あ、この部分の原本が必要だ」と判断すれば、ファイル読み取りtoolでまた取り出せる。要約の損失を後ろから回復できる経路が開かれている 構造です。これが単なる要約システムとの決定的な違い。

(3) セッションの持続。 Compactionのおかげで、対話が数百ターンに伸びてもセッションが途切れません。Context windowの限界を回避する実用的な装置になります。これはsession memoryの限界(トークン上限に引っかかれば前半が切られる)をソフトに解く方式です。

(4) Long-context時代でも有効な理由。 1Mトークンのモデルが出てもcompactionは必要です。なぜなら(a) 1Mトークンの入力は高い。パンパンに埋めて毎回送るとコストが積みあがります。(b) Lost in the middleがある。パンパンに埋めたからといって全部がちゃんと使われるわけではない。(c) 長いプロンプトはレイテンシが大きい。ユーザー体験が悪くなります。だからコンテキストがいくら大きくなっても「いま必要な分だけプロンプトに維持する」という原則は残ります。Compactionはそれを自動化するんです。

この設計が投げるメッセージはこうです。「長いコンテキストと持続記憶は二者択一ではなく、お互いを補うようにうまく紐づける問題。」 Claude Codeはセッション内のcontextをcompactionで管理し、セッション間のmemoryをファイルベースのpersistent memoryで管理します。2つの層が分かれていて、それぞれの役割が明確。だからユーザーが「AIの記憶状態」に戸惑いません。

このセクションが今回の記事の核となる洞察のひとつです。よいAIシステムは「1Mトークンを提供するか」や「memory機能があるか」のような単一の軸で判断されるものではなく、contextとmemoryの役割分離がきれいに設計されているか で判断されます。この感覚を持ってプロダクトを評価しはじめると、技術ニュースがまったく違って読めるようになります。

---

12. 一文で締めます

Context windowは「今回の呼び出しで使える紙の量」、session memoryは「アプリが前の対話を毎回再添付する行動」、persistent memoryは「セッションを越えて残る保管庫または重み」。 この3つはまったく違うメカニズムで、「Claude 1Mトークン」というヘッドラインはその中の1つ目だけを大きくしたもの。記憶力の向上ではなく作業机の拡張。この3つの軸を分けて見れば、長いコンテキスト、Memory機能、RAG、Doc-to-LoRAは、すべて同じ地図の上で読めます。

次に読む

• M3 — AI Agent深掘り — agentを5層に分解して評価する。
• M1 — Retrieval Layerがなぜ必要か — すでに公開済み。

シリーズの最初から: F1〜F6 基礎 · B1〜B3 背景 · M1 Retrieval

FAQ

Q1. では「Claude 1Mトークン」はなんの意味もないんですか?

意味がないわけではまったくありません。「1回の呼び出しで扱える資料の量」が劇的に大きくなった、というのは大きな進歩です。長い論文の要約、大容量コードレビュー、1回限りの大量データ分析のような作業は、以前とは比べ物にならないくらい楽になります。ただこれが 「セッションを越えて記憶する能力」の向上ではない という点がポイントです。作業机が大きくなっただけで、記憶力がついたわけではない。この2つを混ぜて過大評価しなければ、正確な期待値を立てられます。

Q2. ChatGPT Memoryに個人情報を任せてもいいですか?

機能自体の安全性はOpenAIのセキュリティ水準に依存します。技術的にはあなたのアカウントに紐づくノートファイルですが、外部サーバーに保存される点は忘れないでください。個人的な嗜好、食事制限、趣味のようなものなら任せても大きなリスクはありません。ただ 機微な医療情報、金融情報、会社の機密 を任せるのはおすすめしにくいです。一度保存されたノートはあなたが消せますが、ログやバックアップがどう管理されているかは透明ではありません。企業環境ならもっと慎重に。機微なものは自分の保管庫で管理し、一般的なものはAIに任せる二重構造が安全です。

Q3. 長いコンテキストとRAGのうち1つだけ選ぶとしたら?

1つだけ選ぶものではないのが核心なんですが、あえて選ぶなら 「資料が頻繁に変わるか変わらないか」 を基準にしてみてください。最新性が重要なリアルタイムデータ、周期的に更新される文書セットなら、RAGが有利。変わるたびに保管庫だけ更新すればいいので。逆に 1回限りの分析、資料間の関係把握、即席の実験 ならlong-contextが楽です。プロンプトに全部貼って一気に通すほうが速いから。実際のプロダクションシステムでは2つを混ぜて使います。RAGで関連部分を取り出して、long-contextの中にきれいに並べて処理する、という具合で。どちらかが死ぬようなことは当面ありません。

---

ニュースレターのご案内

毎週月曜日の朝、AI・LLM・エージェント関連の実務整理を1通お届けしています。こういう技術解説を落ち着いて積み上げたい方は、購読どうぞ。

ニュースレター登録(無料・30秒)

---

著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

ソースリスト

• テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
• AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 公式ドキュメント
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

---

著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。