ServiceDock
2026年8月17日 更新
約4分で読めます
AIとの会話で「さっき言ったこと」を覚えていられるのは、履歴を毎回まるごと送り直しているからです。記憶しているわけではありません。
20往復の会話を積み上げたところ、全部送る構成は9往復目で上限に当たりました。古いものから捨てる構成では、20往復目に最初の12往復が消えています。
20往復ぶんを積み上げました。全部送る構成は9往復目で上限を超え、捨てる構成では最初の12往復が完全に失われます。
短期記憶がどこで限界に当たるのかを、往復ごとに積み上げました。条件は1往復900トークン、履歴の上限8000トークンです。
断っておくと、これは実際の会話を計測したものではありません。1往復あたりの量を置いて積み上げた計算です。置いた値はコードに書いてあります。
const TURNS = 20;
const PER_TURN = 900; // 1往復あたりのトークン量（置いた値）
const LIMIT = 8000; // 履歴に許す上限
const SYSTEM = 400; // 毎回必ず送る指示
const SUMMARY_TOK = 250; // 要約1つぶんの量
// 2: 古いものから捨てる（最初の指示や前提が消える）
function dropOldest() {
const fit = Math.floor(LIMIT / PER_TURN);
// 直近 fit 往復ぶんだけを残す。それより前は完全に消える
}
1往復 900 tok、履歴の上限 8000 tok で 20往復したとき 往復 全部送る 古いのを捨てる 要約して残す 5回 4900 tok 4900 tok 4900 tok 8回 7600 tok 7600 tok 7600 tok 10回 上限超過 7600 tok 7850 tok 15回 上限超過 7600 tok 7850 tok 20回 上限超過 7600 tok 7850 tok 全部送る構成が上限を超えるのは 9往復目 古いのを捨てる構成が 20往復目に持っている最古の往復: 13往復目 → 1〜12往復目の内容は完全に消えている 要約して残す構成が 20往復目に要約している往復数: 12往復ぶん
8往復目までは3つとも同じ値です。差が出るのは上限に当たってからで、そこから扱い方の違いが現れます。
古いものから捨てる構成では、20往復目に残っているのは13往復目以降だけです。最初の12往復で決めたことは、参照できません。
会話の最初は前提を確認する部分になりがちです。ですから消える順序としては、いちばん困る側から消えていきます。
要約して残す構成では、12往復ぶんが250トークンに圧縮されています。痕跡は残りますが、圧縮の過程で細部は落ちます。
落ちやすいのは数値と固有名詞です。「予算の話をした」は残っても、「320万円」は残らないことがあります。
上限に当たるのは避けられない。選べるのは何を失うかだけ。
As conversations grow, you'll eventually approach context window limits.原文Claude Platform Docs「Context windows」 この内容の有効期限2027-02-17
覚えているのではなく、毎回まるごと送り直しています。ですから送れる量に上限があります。
短期記憶と呼ばれているものの正体は、会話の履歴をそのまま送り直しているという動作です。AIの中に何かが保存されているわけではありません。
Anthropicの説明でも、会話が進むにつれて利用者の発言とAIの応答が積み上がり、それまでの往復はそのまま保たれるとされています。要約されるのではなく、丸ごと残る形です。
ですから10往復目には10往復ぶんが送られます。1往復目の内容も、そのときと同じ形で毎回送り直されています。
積み上がる場所には容量の上限があります。同じ文書には、会話が長くなればいずれ上限に近づくと明記されています。
この上限は応答の生成ぶんも含みます。ですから履歴で埋まるほど、返せる答えの長さも短くなっていきます。
短期記憶は1つの会話の中だけのものです。会話を閉じれば消えます。会話をまたいで保つには、外部に保存する仕組みが別に要ります。
運用してみて分かったのは、大事な前提を会話の中だけに置くと必ず失われることでした。編集部では、守ってほしい決まりごとは毎回送る指示のほうに書き、作業の進み具合はファイルに残すようにしています。計画が履歴から消える問題はPlan-and-Executeの記事でも扱っています。
Progressive token accumulation: As the conversation advances through turns, each user message and assistant response accumulates within the context window, and previous turns are preserved completely.原文Claude Platform Docs「Context windows」 この内容の有効期限2027-02-17
上限を広げるだけでは解決しません。消えて困るものを履歴の外に出しておくのが確実です。
短期記憶の限界への備えは、何を失ってよいかを先に決めておくことから始まります。失わない選択肢は存在しないためです。
まず出てくる案が、上限の大きいモデルに変えることです。到達する時期は遅くなりますが、往復を重ねれば同じところに行き着きます。
しかも副作用があります。Anthropicも、上限が大きいほど長い入力を扱えるが、文脈が多ければ自動的に良くなるわけではないとしています。
3番目の扱いが効きます。読み込んだ内容をそのまま履歴に積まず、要約だけ残すと、上限に当たる時期をかなり遅らせられます。この切り出し方はサブエージェントの記事で数字とともに扱っています。
実装に入る前に、上限に当たったときの動きを決めてください。止まるのか、古いものから落とすのか、要約に切り替えるのか。決めていないと、想定していない形で情報が消えます。
また、いつ何が落ちたかを記録しておくと、答えがおかしくなった原因を追えます。記録の設計はエージェント可観測性の記事で扱っています。
上限を広げても到達する。消えて困るものを外に出すしかない。
A larger context window allows the model to handle more complex and lengthy prompts, but more context isn't automatically better.原文Claude Platform Docs「Context windows」 この内容の有効期限2027-02-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る