[AI書房] 第7章 モデルが数えるトークンと作業記憶: 一度に読める範囲
Claude Code完全攻略
第3部
第7章 モデルが数えるトークンと作業記憶: 一度に読める範囲
金京鎮
導入
Claude Code に競合他社の分析を任せて、さまざまな修正をやり取りしているうちに、対話が長引いてしまいました。最初は正確なチャートと清潔な PDF を作成していたエージェントが、ある瞬間から奇妙なデータを引っ張り出すようになりました。確かに、先ほどお伝えしたブランドカラーを無視し、すでに回答済みの質問を再度尋ねてきます。
画面下部に目をやると、「コンテキストの 23% が残っています」というメッセージが表示されています。エージェントのメモ帳がいっぱいになったのです。この現象を理解するには、まずエージェントが私たちの言葉をどのように読み取っているかを知る必要があります。
モデルが数える「トークン」とは何か
人間は単語単位で文章を読み取りますが、AI は異なります。AI はモデルが数える文字の断片である「トークン」という単位で読み取ります。
モデルが数えるトークン1つが、必ずしも単語1つとは限りません。大まかに言えば、英字3〜4文字が1つのトークンに相当します。カンマ1つや「in」といった短い前置詞も、それぞれ1つのトークンとして数えられます。空白文字さえもトークン計算に含まれます。一貫した規則があるように見えますが、実際にはかなりばらつきがあります。
大まかな目安として、英語ではモデルが数えるトークン1つは、単語の約75%に相当します。
韓国語の場合は状況が少し異なります。韓国語の1文字が複数のトークンに分割されるケースが多いため、同じ意味の文であっても、英語よりも多くのトークンを消費します。
なぜこれが重要なのかというと、トークンは金銭だからです。Claude Codeを含むすべての大規模言語モデルは、トークン単位で料金を計算します。サブスクリプションプランを利用する場合でも、一定期間内に使用できるトークンの総量には上限があります。トークンを無駄遣いすると、その上限をすぐに使い果たしてしまいます。
[図7-1] 英語文がトークンに分解される例。「Hello, how are you?」が ["Hello", ",", " how", " are", " you", "?"] に分割される視覚的図解
一度に読める範囲の大きさと限界
Claude にはメモ帳が一つあると想像してください。会話を始めると、Claude はこのメモ帳に、ユーザーの発言、自身の回答、システムプロンプト、MCP ツールのリスト、プロジェクトファイルの内容をすべてびっしりと書き込みます。このメモ帳こそが、一度に読める範囲(コンテキストウィンドウ)です。
このメモ帳のサイズには物理的な限界があります。現在の Claude モデルの標準的な一度に読める範囲は、約 200,000 トークンです。数字だけ見ればかなり大きく思えますが、予想よりも速く埋まっていきます。メモ帳に収容される項目を列挙してみましょう。
プロジェクト規模が大きくなるほど、MCP 接続サーバーを複数接続するほど、これらの項目がメモ帳を急速に占有していきます。/context コマンドを入力すると、現在モデルがカウントしているトークンの使用状況を確認できます。例えば、あるセッションで Claude Opus 4.6 モデルのトークン使用量が 22,000/200,000 である場合、すでに全体の 11% を消費したことになります。
[図 7-2] /context コマンド実行結果の例。システムプロンプト、システムツール、MCP ツール、会話記録がそれぞれどの程度のトークンを占めているかを示す棒グラフのスクリーンショット]
文脈が漏れる現象
メモ帳が半分ほど埋まると、微妙な変化が始まります。最初は正確だったエージェントが次第におかしな答えを返すようになります。すでに提供した情報を再度要求したり、存在しない事実をでっち上げたりします。この現象を「コンテキスト・ロット(Context Rot)」と呼びます。
その原因は、大規模言語モデルが長い文脈を処理する仕組みにあります。モデルが数えるトークンが積み重なるにつれて、モデルの品質と精度が顕著に低下します。会話の最初と最後の情報は比較的よく記憶されますが、中間にある情報は埋もれやすくなります。これを「真ん中で忘れられる(Lost in the Middle)」現象と呼びます。
グラフを描いてみましょう。横軸はモデルが数えるトークンの使用量、縦軸は回答の品質です。使用量が50%を超えると品質の曲線は緩やかに下降し始め、70%を超えると急激に転落します。この現象はClaudeに限らず、すべての大規模言語モデルで観察されます。
[図7-3] コンテキスト使用量(横軸)と回答品質(縦軸)の関係を表す曲線グラフ。60%の地点に垂直の点線を引いて「警告区間」を示す
実際の作業で経験する症状は次の通りです。エージェントが突然架空の情報を生成します。事前に保存したファイルの経路を誤って記憶します。同じ質問を繰り返します。これらの兆候が検出されたら、モデルが数えるトークンのメモ帳を整理する時が来たのです。
60%ルール
競合他社分析のワークフローを実行し、結果を検証し、修正事項をやり取りしていると、画面下部のコンテキスト残量表示が気づけば50%を下回っています。"45% of your context remaining until auto-compact"という文言をご覧になったことがあるでしょう。
実務において有用な基準が一つあります。コンテキストの60%が埋まったら整理を開始するというものです。これを60%ルールと呼びます。
なぜたまたま60%なのでしょうか。その時点を超えると、コンテキストの遅延が実際に体感され始めるからです。もちろんClaude Codeには自動圧縮(Auto-compact)機能が内蔵されており、限界に達すると会話を自動的に圧縮します。しかし、自動圧縮ではエージェントがどの情報を保持し、どの情報を削除するかを独自に判断します。重要な判断事項が圧縮プロセスで失われる可能性があります。
したがって、能動的に60%の地点で直接整理を行う方が安全です。では、整理はどのように行うのでしょうか。そのためのツールが2つあります。
/compact: 会話を圧縮しつつ記憶は残す
/compactコマンドを入力すると、Claude Codeはこれまでの会話記録を要約版に圧縮します。長い会話が核心を抜いた短い要約に変わることで、モデルがカウントするトークン使用量が大幅に減少します。まるで長文の議事録を主要な決定事項のリストに整理するのと似ています。
圧縮後でも、エージェントは以前どのような作業を行ったかを概ね記憶しています。作成したファイル、実行したツール、到達した結論 — これらの情報が要約版に残されているため、会話を継続することができます。
しかし、さらに一歩踏み出すことも可能です。/compactコマンドの後に、保存したい情報を直接指定することです。
このように入力すると、エージェントは API に関する決定事項とスキーマ情報を圧縮プロセスで優先的に保持します。ブランド資産のパスを失いたくない場合は、/compact keep brand asset paths と記述できます。これは、プロジェクトの核心となる文脈をユーザー自身が直接指示する行為です。
これが選択的保持戦略です。エージェントに「すべて覚えておいて」と指示する代わりに、「これだけは必ず覚えておいて」と伝える方がはるかに効果的です。
/clear: 完全な初期化
時には圧縮ではなく、白紙の状態が必要です。/clear コマンドは会話履歴を丸ごと削除します。エージェントは以前の会話で何を行ったかを全く記憶していません。
ただし、重要な点があります。/clear を実行してもプロジェクトのファイルはそのまま残ります。claude.md ファイル、ワークフロー文書、ツールスクリプト、ビジネスプロファイル JSON — ディスクに保存されたすべてのファイルは手つかずです。エージェントが新しい会話を開始すると、claude.md を最初から読み直し、必要なファイルを再度探索します。まるで新しく出勤した秘書が業務マニュアルを広げるようなものです。
/clear を使用するのに適したタイミングは以下の通りです。
「/compact」と「/clear」、いつ何を使うべきか
両コマンドの違いを整理します。
[図 7-4] /compact と /clear の動作の違いを左右比較で示したダイアグラム。左側は会話履歴が要約へと圧縮される様子、右側は会話履歴が消去され claude.md のみが残る様子
実戦パターン
実務においてこれらのツールを活用する流れは以下の通りです。
作業を開始します。エージェントと何度も対話を交わします。画面下部の残量表示が40%を下回ったら、ここで「/compact keep brand assets and competitor list」を実行します。モデルがカウントするトークンが確保され次第、作業を続行します。作業が完了したら、次の作業は全く異なるテーマになります。その際は「/clear」を実行して新規で開始します。
このリズムに体が慣れれば、エージェントの品質は対話の長さに関わらず一定に保たれることを実感できるようになります。モデルがカウントするトークンと一度に読める範囲は、初めて接する際には技術的に思えるかもしれませんが、核心は結局一つの習慣です。「メモ帳が半分か埋まったら整理する」のです。
エージェントの記憶を管理する方法を習得したので、いよいよその記憶の最初のページに当たる文書、つまりエージェントが毎回最も最初に読むそのファイル」をどのように作成すべきか、検討する時が来ました。








