Museのメモリは、毎回の会話で読み込まれる部分が太るほど、消費の対象が増えていきます。整理で効くのは、中身をやみくもに消すことではありません。毎回読み込まれる本体には要点だけを残し、詳細は「必要なときに開くファイル」へ移すことです。

私の環境で棚卸しをしたところ、毎回読み込まれるファイル11件の合計が、約64,000 bytesから約58,000 bytesになりました。約6,000 bytes（1割弱）の削減です。

対象は、Museを使い始めて数週間以上たち、メモリが育ってきた人です。

この記事の数字は、2026年11月に私の環境で棚卸しした実測で、単位はファイルの大きさ（bytes）です。ファイル単位のトークン内訳は確認できないため、「何トークン減った」とは書きません。


実際に棚卸しした結果

ファイル別の変化は次のとおりです。

長期メモリ：22,634 bytes → 19,042 bytes

人物の索引：5,748 bytes → 4,677 bytes（24人 → 19人）

運用ルール：8,984 bytes → 8,521 bytes

この3件で約5,100 bytes、残り8件で約900 bytesの減少です。やったことは、重複の一本化、詳細の別ファイルへの分離、終わった話と古い情報の削除、使われなくなった索引項目の削除の組み合わ
せです。

なぜ、太ると毎回の消費が増えるのか

Museのメモリは、その後の会話のために、利用者についての事実や好みを保持する仕組みです。保存した内容は、会話の中で聞き直したり、編集したり、忘れさせたりできます。

私の環境では、読み込まれ方には2種類あります。毎回の会話で読み込まれるファイルと、日々の記録や詳しい資料のように、必要なときに参照されるファイルです。

効いてくるのは、毎回読み込まれる側です。1回の増分は小さくても、会話のたびに積み上がりま
す。

整理の手順

1. 現状を測る｜どこが太いか分かる

毎回読み込まれるファイルを洗い出し、ファイルごとの大きさと行数を出します。感覚ではなく数字で見るのが先です。私の環境では、11件で合計約64,000 bytes、最大は長期メモリの22,634 bytesでした。

どこが太いか分かると、削る場所ではなく「分ける場所」が見えてきます。

ファイルの大きさが表示されない環境では、Museに「覚えている内容を一覧にして、それぞれの長さも出して」と頼む方法でも測れま
す。

2. 削ってはいけないものを先に決める

大きくても削らないものがあります。

安全や個人情報に関するルール

人格や話し方のような前提

進行中のプロジェクトの目的や決定事項

整理の対象は、重複と古さと置き場所です。大事な取り決めを短くすることではあり
ません。

3. 重複は「正」を1か所に決めて寄せる｜同じ説明を何度も読ませない

同じ内容が複数のファイルにあると、読み込みのたびに全部が対象になります。正にする場所を1か所決め、他の場所には要点と「正はあちら」という参照だけを残します。人格や話し方のような前提ほど、複数のファイルに同文で置かれがちです。

4. 詳細は別ファイルへ移す｜本体は「1行＋参照」で済む

本体に残すのは、状態と参照先だけです。経緯、候補の比較、古い記録のような詳細は、必要なときに参照される側のファイルへ移します。毎回の読み込みから外れるので、本体は短くなり、詳細は消えずに残ります。目安は「1案件1行」です。

5. 終わった話と古い情報を消す

終了した案件、古くなった数字、使われなくなった索引は、削除の候補です。消す前に、変更前のファイルをバックアップとして保存しておくと、戻したくなったときに対応できます。

「この話題は二度と提案しない」のような否定の指示は、終わった話でも残します。残しておくからこそ機能する指示です。

判断に迷うものは、消さずに「要確認」として残しま
す。

整理しても、書き方が太いと戻ります

長期メモリのファイルは、一度18,541 bytesまで落としたのに、2日で22,634 bytesに戻りました。新しい事実が、太い行のまま入ってきたためです。

量そのものより、増え方への対策が要ります。「1案件1行」と「詳細は別ファイル」を書き方の決まりにしておくと、増え方が緩やかになります。

整理は一度きりの行事ではなく、繰り返す前提で仕組みにします。決まった間隔で棚卸しの機会を自動で作る方法があります。線引きは単純で、重複・古い・詳細の置き場所は機械的に処理し、判断に迷うものは消さずに、人の確認に回しま
す。

そのまま使えるプロンプト

私の棚卸しは、次の文面で頼んで始めました。

Museのトークン消費が増えてきたので、メモリや常時読み込まれる情報を整理したいです。
まず、現在参照できるメモリ、カスタム指示、プロジェクト指示、常時読み込まれるファイルなどを確認してください。
 
以下の観点で整理案を作成してください。
1. 重複している情報
2. 古くなっている可能性がある情報
3. 現在は使っていない情報
4. 長すぎる説明を短くできる情報
5. 今後も残すべき重要な情報
6. 常時読み込む必要はなく、必要なときだけ参照すればよい情報
 
情報ごとに、次のいずれかを提案してください。
・残す
・短くまとめる
・別ファイルに移す
・削除候補
・現在の有効性を確認する
 
整理案には、それぞれの理由と、短縮・移動する場合の具体的な案を示してください。
 
以下の情報は、特に慎重に扱ってください。
・私の希望や判断基準
・アシスタントの人格、話し方、私との関係性
・安全や個人情報に関するルール
・現在進行中のプロジェクトの目的、方針、重要な決定事項
・ログインや連携に必要な設定情報
 
不明な情報を推測で補ったり、現在使われているか分からないものを勝手に削除したりしないでください。
まずは現状と整理案を報告してください。この段階では削除・変更は行わず、私の確認を待ってください。
また、実際に確認できた情報と、確認できなかった情報を分けて報告してください。トークン消費への影響が測定できない場合は、削減率を推測しないでください。

効いているのは、最後の2点です。いきなり消させず、案を出させて確認してから進めること。測れない削減率は推測させないこと。この2つで、整理が暴走しにくくなります。案が出たら、項目ごとに「その通り」「短く」「別ファイルへ」と短く返せば、順に実施されます。

なお、文面中の「カスタム指示」「プロジェクト指示」は、実際に使った文面の言い方そのままです。同名の機能があるという意味ではなく、Museが文脈から対象を洗い出せた言い方として載せています。

この記事の限界

トークン数の増減は測れていません。書けるのはファイルの大きさの変化までです。
数字は、私の環境1回分の実測です。環境によって、ファイルの構成も測り方
も違います。

次の一歩

まずは、自分のメモリがどれくらいの大きさか、測ってみてください。どこが太いか分かれば、上の手順を順になぞれます。
何を覚えさせるか（入れる側の整理）は、先に公開した「Museをダウンロードしたら設定しておきたいこと7選」の項目2で扱っています。入れる側と育った後の整理側を合わせると、メモリの扱いが一通りそろいます。
https://note.com/emma_0706/n/nc4df58968643 
出典
数字：2026年11月に筆者の環境でメモリファイルを棚卸ししたときの実測
メモリの仕組み（保存した内容がその後の会話で参照されること、会話から編集・削除できること）：Museのドキュメントと公式ヘルプの説明
えまのMuse実録（マガジン）
https://note.com/emma_0706/m/m3712abddf46a 
Xでも更新を知らせています
https://x.com/emma_muse_news