第1章 ステートレス性 — AIは「覚えていない」

1.1 毎回が白紙からのスタート

LLMの最も重要な性質はステートレス（状態を持たない）であることだ。

人間の脳は、昨日の会話を覚えている。神経回路の結合が物理的に変化して、記憶として定着するからだ。LLMはそうではない。モデルのパラメータ（数千億個の数値の集合）は、訓練が終わった時点で固定されている。ユーザーとの会話によってパラメータが書き換わることはない。

この違いは根本的だ。人間と1時間議論すれば、その人の頭の中には議論の記憶が残る。翌日に話しかけても、昨日の続きから始められる。LLMにはこれが起きない。1時間の対話が終わった瞬間、モデルの側には何も残らない。翌日のセッションは、文字通りまっさらな状態から始まる。

つまり、毎回のリクエストで起きていることはこうだ：

1. システムがコンテキストウィンドウを組み立てる（システムプロンプト＋過去のやり取り＋今回の入力）

2. その「テキストの塊」をモデルに丸ごと渡す

3. モデルはそれだけを見て応答を生成する

4. 生成が終わったら、モデル側には何も残らない

ステップ4が決定的だ。モデルは「さっき何を生成したか」すら保持しない。次のリクエストが来たとき、前回の応答はステップ1でシステムがコンテキストに含めてくれるから「知っている」だけだ。モデル自身が記憶しているわけではない。

1.2 「記憶」の正体

AIが「覚えている」ように見える場面は2種類ある。しかしどちらも、人間が想像する「記憶」とは仕組みがまったく異なる。

同一会話内の「記憶」

今の会話でAIがさっきの発言を踏まえて応答できるのは、「覚えている」からではない。会話の全履歴がコンテキストウィンドウに毎回入力として渡されているからだ。AIは毎ターン、会話の最初から全部読み直しているようなものである。

これは「記憶」というより「カンニングペーパー」に近い。人間が記憶で話しているのに対し、AIは毎回ノートを全ページ読み返してから答えている。結果だけ見れば同じように「覚えている」ように見えるが、仕組みは根本的に違う。

この仕組みには重要な帰結がある。会話の3ターン目でも30ターン目でも、AIはすべてのターンを等しく「読んでいる」。人間なら30ターン前の細かい発言は忘れているかもしれないが、AIはコンテキストに入っている限り読んでいる。逆に、コンテキストから落ちた瞬間に完全に消える。「薄れていく記憶」ではなく「ある/ないの二値」だ。

会話をまたぐ「記憶」

前回の会話の内容を踏まえた応答ができるのは、外部のシステムが記憶データベースから関連情報を検索し、今回のコンテキストウィンドウに注入しているからだ。モデルが「思い出している」のではなく、「読まされている」。

具体的には、AIサービスの裏側でこういうことが起きている：

1. 過去の会話からキーワードや要約が外部データベースに保存される

2. 新しい会話が始まると、システムがデータベースを検索する

3. 関連しそうな情報をコンテキストウィンドウに「メモリ」として注入する

4. モデルはそのテキストを読んで、あたかも覚えているかのように応答する

つまり「記憶」の実体は、モデルの外側にあるデータベースとそれを検索・注入するシステムだ。モデル自体は何も覚えていない。

この理解は実用上極めて重要だ。「昨日の会話でAIに伝えた前提が、今日は反映されていない」という不満は、メモリシステムがその情報を検索・注入しなかった（あるいはできなかった）結果であり、AIが「忘れた」のではない。確実に伝えたい前提があるなら、毎回明示的に伝えるか、ファイルに書き出して参照させる方が確実だ。

ここで「メモリ機能があるなら、わざわざファイルに書き出す必要はないのでは」と思うかもしれない。しかしメモリ機能には構造的な限界がある。何を記憶し何を忘れるかはシステムが自動的に決めるのであり、ユーザーがコントロールできない。「この前提条件は絶対に次回も反映してほしい」と思っても、システムの検索アルゴリズムがそれを選び出す保証はない。日常的な使い方——「前回話した趣味の続き」「いつもの文体の好み」——にはメモリで十分だ。しかし、プロジェクトの状態管理のように、特定の情報が確実に引き継がれなければ作業が破綻する場面では、メモリ機能だけに頼ることはできない。この区別は第8章で改めて整理する。

1.3 コンテキストウィンドウ — AIの「作業机」

コンテキストウィンドウとは、1回のやり取りでモデルが「見える」範囲のことだ。システムプロンプト、ユーザーの入力、過去のやり取り、ツール呼び出しの結果——これらすべてがこのウィンドウに収まっている必要がある。

窓の外にあるものは、モデルにとって存在しない。

アナロジーとしては「作業机」が分かりやすい。机の上に載っている書類だけを見て仕事をする。机に載せていない書類は、どれほど重要でも、参照できない。机の広さ（コンテキストウィンドウのサイズ）には物理的な上限がある。

現在の主要なモデルのコンテキストウィンドウは数万〜数十万トークン（おおよそ数万〜数十万語に相当）だ。一見巨大に見えるが、長い対話やシステムプロンプト、ツール定義、メモリ注入などで意外にすぐに埋まる。

auto-compact — 机の書類が要約される

会話が長くなってウィンドウの上限に近づくと、システムが古い部分を要約・圧縮して空きを作る。これを auto-compact と呼ぶ。単純に切り捨てるのではなく、重要なコードや判断を残そうとする要約処理だ。しかし要約である以上、細部は失われる。元の会話の微妙なニュアンスや、具体的な数値、一度だけ言及された前提条件——こうした情報は要約から漏れやすい。

重要なのは、モデル自身はこの要約プロセスに関与しないということだ。システムが裏側で会話履歴を圧縮し、次のターンではその圧縮後のテキストがコンテキストウィンドウに入る。モデルは「要約された履歴」を読んでいるだけであり、「元の会話を覚えている」わけではない。要約に含まれなかった情報は、モデルにとって最初から存在しなかったのと同じだ。

auto-compactの発動タイミングはツールによって異なる。Claude Code（エージェントツール）では、コンテキスト残量のインジケーターが表示され、残量が25〜30%程度になると自動的に発動する。ユーザーは /compact コマンドで手動実行したり、何を優先的に保持すべきか指示することもできる。一方、チャットUI（claude.ai等）ではこうした制御手段が限られており、ユーザーが気づかないうちに文脈が失われることがある。あるターンまでは会話の冒頭を踏まえた応答をしていたのに、次のターンで突然「その話は初耳です」という反応になる——これが起きたら、auto-compactで文脈の一部が要約から漏れた可能性が高い。

実用上のポイント: 重要な指示や前提条件は、会話の途中で繰り返し伝えた方が確実である。「最初に言ったから覚えているはず」という前提は、アーキテクチャ上保証されない。長い対話の中で重要な結論が出たら、その時点で外部ファイルに書き出しておくことが、情報を失わないための最も確実な方法だ。