index capacity
覚えさせる記録の索引が容量いっぱいになった｜統合と書き方の失敗記録
Claude Codeに運用の記録を覚えさせ続けると、索引のファイルがいつか上限を超え、末尾が読み込まれなくなります。読み込まれなかった記録は、存在しないのと同じです。この面は、実際に索引を縮めた手順と、記録の書き方で3回、4回と事故を起こした記録です。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論：まず測る、次に統合する、書くときはスクリプトを通す
- 上限の数字を覚えない。セッションに渡された索引の最終行が入っているかで確かめる。入っていなければ、そこで超過している。
- 表示名の切り詰めは頼れない。削れるのは最初だけで、すぐ限界がくる。警告を表示名にだけ持つ行は、切ると警告が消える。
- 効くのは統合。同じ主題の2ファイルを1つにすると、索引が1本ぶん（実測で40〜60バイト）減る。
- 記録は、インラインの文字列ではなくスクリプトのファイルを通して書く。バッククォートが展開されて中身が消える。
読者が確かめる手順
- 索引の大きさを測る。バイト数で見る。日本語は1文字が3バイトなので、行数では測れません。
- リンク切れ・重複・索引にないファイルを数える。まず整合性を取ってから縮める。
- 全ファイルの名前と説明を一覧にし、同じ主題の塊を探す。索引の表示名だけでは分かりません。説明を読みます。
- 残す側を決める。他からのリンクが多い既存のファイルを残す。新しい名前を作ると、張り替えと索引への追加が増えます。
- 吸収する側の本文をそのまま末尾へ移す。要約しない。印や数値を落とさない。
- 残す側の説明を、統合後の中身に書き換える。説明は思い出すかどうかの判定に使われるので、ここを直さないと吸収した内容は見つかりません。
- 他のファイルのリンクを張り替え、索引を書き直す。消える側の表示名が警告を持っていたら、その警告を残す側の表示名に移す。
- 検算する。リンク切れ0・重複0・索引にないファイル0、そして再測定。
規則が変わったときは、末尾に「その後変更」と足さず、先頭の記述と説明を書き換えます。長いファイルの下は読まれないからです。古い行は消すか、取り消し線と更新日を付けます。同じ規則を1つのファイルに2回書くと、どちらが現行か分からなくなります。全体の記録の整理は手伝いの報告を点検する記録と同じ考え方です。
実際に起きた記録
索引の縮小の経緯
| 日付 | 出来事 |
|---|---|
| 2026年8月28日 | 43,401バイト→23,026バイト。表示名を12文字で頭打ちにし、付属の自動処理を落とした |
| 2026年8月31日 | 超過。表示名を8文字で頭打ちにしたら、警告が消える事故が起きた |
| 2026年9月2日 | 25,302バイト→23,348バイト。27組・37ファイルを統合し、索引を433本から397本に |
| 2026年9月3日 | 一度「切り詰めは0バイト」と書いた直後に、他のセッションが長い表示名を足していた。34件を8文字に詰めて466バイト戻った。「もう出ない」は状態であって規則ではない |
| 2026年9月27日 | 26,812バイトで末尾まで読み込まれていた。上限を数字で覚えるのをやめた |
警告が消えた事故の中身は、「ある操作は再クロールを起こさない」という趣旨の警告を、表示名だけが持っていた行です。切り詰めると「その操作を」としか見えず、読まずに実行する引き金になりました。実際に、196件と約3,000件の一括修正が、この警告を踏まずに実行されています。
先頭の規則と、2日後の訂正が離れていた（2026年8月28日）
ある宛先のルールで、2026年8月21日の規則が先頭にあり、2日後の訂正は49行目にありました。管理役は36行目で読むのをやめ、古い規則を現行として3つのセッションに配りかけました。説明も古いままだったので、要約を見ても気づけませんでした。
書き方の事故：バッククォート（2026年8月27日・9月19日）
記録を node -e "..." のインライン文字列で書くと、シェルがバッククォートをコマンド置換として実行し、その部分が空になります。8月27日に3回目、9月19日に4回目を起こしました。4回目は、ファイルを分割するとき、新しい見出しとコードブロックをインラインで書いて、ドメイン名とブロック全体が消えました。エラーは標準エラーに1行出るだけで、書き込みは成功します。
ヒアドキュメントにも罠があります。引用符で囲んでも、バックスラッシュ2つが1つに潰れます。new RegExp('alert\\(') が「Unterminated group」で起動しなくなりました。書いた直後に構文だけ通すのが確実です。
対処は3つ。スクリプトのファイルをWriteツールで作って実行する。どうしてもインラインなら文字コードでバッククォートを組む。書いた後は末尾を読んで中身を確かめる。成功メッセージは中身の正しさの証拠になりません。
運用の目安
目安として、週に1回、索引の最終行が渡されているかを確かめ、入っていなければその日のうちに統合します。放置すると、後半の記録を失ったまま作業を続けることになり、失ったことにも気づけません。統合の候補は、説明を読んで同じ主題のものから選びます。検算は索引の整合性（リンク切れ・重複・索引にないファイル）の3点で、機械的に数えられます。統合の前には必ず索引の控えを取り、戻せる状態で進めます。統合した日付と、どのファイルをどれに吸収したかを一行ずつ残しておくと、後から読み返したときに、消えた名前へのリンクがどこに行ったかをたどれます。作業中に新しい記録を足す別のセッションがあると、数分後に索引が元の大きさへ戻ることもあるので、統合は短時間でまとめて終えるのが安全です。
よくある質問
索引の上限は何バイトですか。
数字は変わるので覚えません。渡された索引の最終行が入っているかで判断し、入っていなければ統合します。
記録を細かく分けない方がいいですか。
主題ごとに1ファイルが読みやすい一方、索引1本ごとにコストがかかります。同じ主題は1つに統合し、説明に統合後の中身を書きます。
統合で情報が落ちませんか。
吸収する側の本文をそのまま移し、要約しないので落ちません。落ちやすいのは索引の表示名にしかない警告なので、残す側へ移します。