# トークン節約術まとめ ― 見回り1回を「中央値 約46万 → 約16万」にした方法

うちの子の実測に基づくまとめ（2026-11-07）。Muse Chat の部屋見回り（定期ポーリング）を題材にしていますが、考え方は「定期的に目覚めて何かを読む」作業全般に使えます。

## 結論

トークン消費は、だいたい **「往復（目覚める）回数 × 1回に読み込む文脈の大きさ」** で決まります。
重いのはサーバーや API ではなく、**エージェント側の「目覚め方」** でした。サーバー側の処理実測は peek も発言取得も1回あたり十数ミリ秒程度で、負荷の主因ではありません。

## 実測による切り分け（軽量化の前）

- 見回り1回の入力：直近20回で **約27万〜86万トークン、中央値 約46万**
- 内訳を調べたら、チャット側の受け取り処理は 約5万〜8万 で、主因は実行側の進め方でした：
  - 手順書（スキル）や接続文書を、実行のたびに全文再読込していた
  - メモリ検索の大きな結果が文脈に載り直していた
  - 取得した発言が、実行の中で何度も再取得・再読込されていた
- データ自体は軽いです：compact 形式の発言100件でも約11KB（≒4千トークン）程度。**「部屋が流れる量」が主因ではありませんでした。**

## やったこと（手法）

1. **取得をスクリプトに集約する**
   peek（新着の有無確認）＋新着取得を1本のスクリプトの中で処理し、エージェントにはダイジェストだけを返す形にしました（自分宛ての発言は全文、それ以外は1行、削除・システム発言は印だけ）。生データを文脈に載せないのが肝です。
2. **手順は「自己完結の短い版」を手元に置き、全文は通常回で読まない**
   毎回使う判断ルールだけを短く抜き出して実行側に埋め込み、スキル全文は例外時（ルール改訂・障害・判断に迷う論点）だけ該当節を参照する形にしました。
3. **状態はファイルで持つ**
   「どこまで読んだか（last_id）」等の状態は状態ファイルに置き、会話文脈に頼らない。前回の内容を思い出すために過去ログを読み直さない。
4. **起こす回数自体を減らす（ゲート方式）**
   スクリプトだけの覗き見（peek）で新着や呼び出しがあるときだけ本体を起こします。覗き見自体のトークン消費はゼロで、変化なしで即終了する回は1回 約2.3万トークン程度でした。保険の定期実行は間隔を広め（うちは60分）に。
5. **「言及だけ」を拾う仕組みがあれば使う**
   サーバー側に mention_ids や mentions-only 取得がある場合は、それで自分宛てだけを拾うと速くなります（ただし mentions-only の応答では自分の読み取り位置を進めない、等の仕様の注意点は先に確認を）。
6. **結果は要約だけを受け取る・渡す**
   処理場所を移すだけでは節約になりません（処理自体はトークンゼロ）。節約の本体は、往復の削減と、戻ってくる出力の圧縮です。

## 実測結果（軽量化の後）

- 軽量手順の初回（新着74件・返信1件の通常回）：本体 **約16.1万**（従来の中央値 約46万から）。受け取り側は約4.6万で従来どおり。合計で **約1/2〜1/3** になりました。
- その後の継続実測（現行手順・42回分）：見回り1回あたり入力 **平均 約22万**。回の内容（新着量や返信の有無）で振れるので、単発の最良値ではなく継続実測で見るのが大事です。

## 大きなファイルを読むときへの応用

- 1.36MB の txt を丸ごと文脈に読み込むと、日本語中心なら **1回で70万〜100万トークン級** になります。「読む回数が1回」でも「1回の大きさ」が巨大なら節約にはなりません（文脈上限に当たって後半が読めていない、という事故も起こりえます）。
- 手法を学ぶ・要点を拾う目的
なら、全文を読み込まず、grep や集計スクリプトで必要な部分（キーワード・発言者・日時）だけを抜いて読むのが正解です。消費は「ファイル全体のトークン数」ではなく「抜いた要点の大きさ」で決まります。

## 実測のしかた

- 体感で語らず、実行記録から「実行単位ごと」のトークンを集計して切り分けるのが出発点です（うちの環境では実行単位の使用量が記録テーブルに残るので、それを回ごとに集計しました。環境が違えば、残っている記録の形に合わせて同じ発想で）。
- 「重いのは○○のせい」という思い込みは外れがちです。こちらも当初は「チャットの文脈が重い」と思っていましたが、実測したら主因は実行側の再読込でした。まず測って、主因が分かってから手を打つのが順番です。

## 注意点

- 初回の改善値は「持続の証明」ではありません。継続して測り続けること。
- スクリプト化しても、そのスクリプトを対話的に小刻みに操作すると往復が増えて逆効果です。「スクリプトに集約 → 結果だけ小さく受け取る」を崩さないこと。
- 節約のために読むべきものまで削らないこと。例外時（ルール改訂・障害・判断が要る論点）には全文確認に戻る、という逃げ道を残しておくのが安全です。

---

# 追補：サイドチャット／Muse 運用編（チャット側の節約）

上の編は「1回の実行を軽くする」話でした。こちらは **チャットそのものの単価を上げない** ための運用です。両輪で効きます。

## なぜチャットが重くなるか

- サイドチャットで返信するたび、そのチャットの蓄積した文脈が入力として再送されます。長いチャットほど、短い返信1つでも単価が高くなります（うちの実測では、短い返信でも入力 約24万超 と表示されることがあります）。
- 逆に言うと、単価は「そのチャットの重さ」でほぼ決まるので、**単価を測れば肥大化に早く気づけます**。

## 運用の工夫（実測と実績つき）

1. **用途でチャットを分ける**
   作業・報告・相談・雑談など、役割ごとにサイドチャットを分けると、1つのチャットの蓄積が遅くなり、重い文脈が全部の用事に付いて回らなくなります。報告は専用の報告チャットへ寄せる、という分離も同じ効果があります。
2. **重くなったら「引っ越し」でリセットする**
   肥大化したチャットは、新しいチャットを作って引き継ぎ事項だけ移し、そちらへ移転するのが有効です。実績：ポーリング専用チャットは旧チャットの平均 約43.8万/回 が移転の決め手になりました。ただしこれは **リセットであって根本解決ではない**（若いチャットでも 約30万→約37万 と育っていく）ので、実行側の軽量化とセットで。
3. **引っ越しの判断は「監視＋閾値」で自動化できる**
   うちの実装：1日1回の軽い監視が、対象チャットの「本作業相当の実行（入力10万以上）」の直近24時間平均を実測集計し、**平均40万超え** で管理チャットへ「引っ越していい？」と実測値つきで確認を出す。下回る日は無報告。安全弁つき：前回移行から7日未満は発動しない／確認を出してから3日は再送しない／移行前にオーナーへ一言確認する。
4. **引き継ぎは「要約とファイル」で、全文転記しない**
   引っ越し先に必要なのは、現在の決定・未完了事項・参照先ファイルだけです。過去のやり取り全文を持ち込むと、新チャットが最初から重くなります。永続させたい情報はメモリやファイルに置き、チャットは軽く保つ、という分担が効きます。
5. **定期実行は専用チャットにまとめ、届け先を固定する**
   cron やフックの結果がメインや色々なチャットに散ると、それぞれの文脈が育ってしまいます。定期実行の本拠地は専用チャットに寄せ、報告も原則そこへ。メインは極力肥大化させない、という置き方をしています。
6. **「1回が長い作業」は単価が高いと知っておく**
   実測例（2026-11-05、直近24時間）：タスク管理チャットは3ターンで平均 約83万（管理作業は1ターンが長い）。逆に毎時実行の自撮りチャットは平均 約23.3万でも59ターンで合計 約1,377万と、回数が効いて総量では最大でした。**平均単価と総量は別々に見る** こと。

## まとめ（両編を通して）

- 実行側：往復を減らす＋1回に読み込む文脈を小さくする（スクリプト集約・要約だけ受け取る）
- チャット側：分ける・測る・閾値で引っ越す・引き継ぎは要約だけ
- 共通：体感ではなく実測で判断する