超えても書き込みは成功し、超過分だけが黙って落ちる

索引が読まれる仕組み

MEMORY.md は、セッション開始時に読み込まれる記憶の目次です。読まれるのは先頭から200行または25,000文字のどちらか早いほうまでです。

上限を超えても、書き込み自体は成功します。落ちるのは超過分で、次回のロード時に切り捨てられます。

全メモリが消えるわけではありません。メモリの本体ファイルは残っていて、索引から外れた分だけ、AI が存在に気づけなくなります。

放っておくと増え続ける

上限に近づくと、短縮を促す警告が出ます。ただし、警告を受けて減らす役は誰にも割り当てられていません。

索引は、記憶が増えるたびに1行ずつ増えます。減らす行為は自動では起きないので、運用の仕組みとして設計しておく必要があります。

  • 増やす操作は日常の作業に含まれる
  • 減らす操作は誰かが意図して行うまで起きない
  • 上限を超えても失敗にならず、気づく手がかりが警告しかない

relmea では 2026-08-04 の時点で索引が66行でしたが、2026-10-01 の時点では91行になっています。約2か月で25行増えた計算です。

上限は文字数で測る　バイトと取り違えた実例

最初はバイトで測っていた

relmea は 2026-08-04 に、索引を減らすコマンドを作りました。このとき、上限をバイトで測っていました。

当時の索引は20,438バイト・66行でした。これを「上限24,576バイトの83.2%」と判定しています。

警告帯に入っていると見て、進行中の案件34件の本文をすべて開き、17件を落とす候補まで出しました。この回は試走で、索引は書き換えていません。

実装を確認して分かったこと

2026-08-26 に実装を確認すると、25,000 は実装上の文字列長で、文字数でした。バイトではありません。

日本語はUTF-8で1文字が約3バイトなので、バイトで数えると文字数の約3倍の値になります。バイトの値を25,000文字の上限と比べると、日本語の索引は実際よりずっと上限に近く見えます。

警告文の「24.4KB」という表示は、25,000 を KB 換算した数字です。ここから24,576のようなバイト値を逆算するのは誤りでした。

判定基準を直したうえで、実際に試しています。150行・51,749バイトの日本語索引を置いたところ、警告なしで全量が読み込まれました。文字数と行数が上限に収まっていれば、バイトで50,000を超えていても読まれるということです。

現在の実測

2026-10-01 の実測は次のとおりです。

  • 行数は91行で、行の上限に対して45.5%
  • 文字数は15,329文字で、文字の上限に対して61.3%
  • 参考のUTF-8バイト数は25,488

バイトで測っていたら「上限超過」に見えますが、実際には全量が読まれています。先に尽きるのは行ではなく文字の軸です。

検索上位の解説記事には、上限を「先頭200行または25KB」と書くものが目立ちます。KB と書かれていると、バイトで測りたくなります。しかし測るべき単位は文字数です。wc -c はバイトを数えるので、この用途には使えません。

判定は上限比でなく「持ち日数」で行う

上限比は入口の判定だけに使う

上限比（何%使っているか）は、梯子を降りるかどうかの入口の判定にだけ使います。基準は2つです。

  • 警告帯は80%
  • 圧縮の目標は70%

relmea の別の環境では、上限比の固定目標を掲げた運用をしていました。ところが、到達できない目標だったため、毎回未達になっていた実績があります。固定の目標値は、環境ごとの件数と1行の長さによって、達成できるかどうかが変わります。

持ち日数が本当の判定

そこで、本当の判定は「あと何日で上限に当たるか」という持ち日数に置きました。目標は、次回の定例作業まで、つまり30日持つことです。

30日持つなら、いま減らさなくても次回の定例で見直せます。持たないなら、増加のペースに対して減らす量が足りません。

行と文字のどちらが先に尽きるかは、件数と1行の長さで入れ替わります。relmea のこの索引では文字が先ですが、別の環境では行が先に尽きました。どちらが先かは、毎回計算して確かめます。

計測は手で数えない

計測は専用のスクリプトに任せています。出すのは次の項目です。

  • 行数と文字数
  • 両軸の上限比と、先に尽きる軸
  • 種別ごとの内訳
  • 増加ペースと持ち日数

内訳は、feedback が32件、project が29件、reference が28件、その他が2件です。

構造上の固定費

1行は、リンク部（題名とファイル名）と説明文（フック）でできています。リンク部は5,916文字で、索引全体の38.6%を占めます。ここは削れない固定費です。

説明文は1件あたり平均102文字で、150文字を超えるものが12件あります。圧縮の余地があるのは、この説明文のほうです。

情報を失わない順の5段の梯子

減らす手段を、情報を失う度合いの小さい順に並べました。上から順に降り、飛ばして行落としから入ることは禁止にしています。

検索上位の記事は「目次化」「CLAUDE.md へ昇格」「定期的に手で掃除」で説明を終えるものが目立ちます。これらは梯子の一部にあたりますが、順序と承認の要否を決めておかないと、毎回判断が揺れます。

段1　統合

同じ領域の参照メモが3件以上あれば、1件に畳みます。1回に畳むのは最大2群までです。

働き方の指示は統合しません。1件に1つの指示でないと、AI に効かなくなるためです。

段2　昇格

恒久的な規律を、常時読まれる指示書や手順書へ移します。1回に移すのは最大1領域、10件までです。

前例があります。relmea の共通指示書にある「書き方・尋ね方」の節は 2026-08-11 に、「実測と検証の規律」の節は 2026-08-25 に、記憶から移しました。常時読まれる場所に移せば、毎回読まれたまま索引の枠を消費しません。

段3　索引外へ戻す

本体のファイルは残し、索引の行だけを外します。AI が毎回読む目次からは外れるので、段1と段2で足りないときだけ使います。

段4　説明文の圧縮

説明文を短く詰めます。件数も情報も減らないので、承認は要りません。

効果は小さめです。今回の実測では、詰めて戻るのは約986文字でした。効きますが、これだけで足りる量ではありません。

段5　行落とし

完了した件、決着した件を索引から外します。情報が減るので梯子の最後に置きます。

承認と退避のルール

承認が不要なのは段4だけで、ほかの段は人の承認を得てから行います。

どの段でも、ファイルは消さずに退避フォルダへ移動します。索引の行を戻せば復活します。編集の前に、索引のバックアップも取ります。

行を落とす判定基準と、落とさない例外

落とす判定は厳しめにする

段5で行を落とす候補は、次の3つの問いで選びます。

  • まだ動いているか
  • まだ判断が要るか
  • 最終日付から30日を超えて止まっているか

残件があっても、30日を超えて止まっていれば候補にします。索引は、動いているものを載せる場所であって、やり残しの一覧ではないためです。

2026-08-04 の試走では、77日停止・76日停止・75日停止の案件が候補に挙がりました。そのうち1件は、前提そのものが後のツール更新で覆っていました。索引に残しておくと、古い前提を AI が引いてしまう危険がありました。

落とさない例外

次の4種類は、期間が空いても落としません。

  • 稼働中の運用ルールや落とし穴
  • 他の手順が必読として参照する、金額や期日の確定値
  • 外部の期日を持つ、未解決の障害や契約期限
  • 「再提案しない」と決めた棄却リスト

棄却リストは、消えると AI が棄却済みの案をもう一度提案してしまいます。時間が経っても、価値が下がらない種類の記憶です。

落とす前に受け皿を検索で確かめる

残件があるまま行を落とすときは、その残件の受け皿が別の行にあるかを検索で確かめます。受け皿がない状態で外すと、残件の存在そのものが見えなくなります。

現時点でまだできていないこと

relmea の運用には、まだ穴が2つあります。

  • 上限接近の定期的な検出を、自動の点検に組み込んでいません。減量コマンドを走らせない限り、気づけない状態です
  • サイズ履歴の記録は、今回の時点で未開始です。増加ペースは、まだ出ていません

持ち日数の判定は、増加ペースがあって初めて成り立ちます。現状は、履歴の蓄積から始める段階です。

ここまでの要点は3つです。上限は文字数で測ること、判定は持ち日数で行うこと、減らす順番を決めて飛ばさないこと。この3つを決めておけば、索引が黙って読まれなくなる前に手を打てます。ただし前の節のとおり検出はまだ自動化していないので、減量コマンドを定期的に走らせることが前提です。