8. トークンエコノミー — コンテキストに入れるものと、外に置くもの

これは Alice Way シリーズの第8回だ。第1回から第7回まで、意図の負荷をどこで、どのように、誰と分散させるかを扱った。この投稿はそれらすべての決定が依存する最も根本的なリソース — context window、つまりトークンについて書く。

0. トークンエコノミーは意図に入れるものを意図的に絞ること

協働者の context window は有限だ。すべてが入るわけではない。しかしより重要な事実 — 何が入るかが判断の質を決める。ノイズで埋まれば、シグナルが弱くなる。シグナルに圧縮すれば、同じウィンドウがはるかに深い判断を運べる。

トークンエコノミーとはだから、コスト削減だけではない。コンテキストに入れるものを意図的に選択することだ。自動ロード vs オンデマンド、メモリ vs メモリ外、メイン vs サブ — シリーズが扱ったすべての決定は、ひとつのリソース配分問題に収束する。

この投稿は、その配分の4層配置の記録、トークン節約が判断品質にどう変換されるか、そして積み重なったコンテキストを整える監査ツールの記録だ。

1. 4層配置 — トークンが入ってくるチャンネル

収束したトークン配置は4層ある。

層	何	いつ入るか	トークンコスト
L1 インライン	ペルソナ・判断権限・安全ガード	毎セッション自動	常時（最高コスト）
L2 自動ロード	メモリインデックスの先頭 N 行、プロジェクト CLAUDE.md	毎セッション / ディレクトリ入場時	常時（条件付き）
L3 オンデマンド Read	メモリ本体、言語別ルール、コードファイル	その領域の作業に入るとき	その作業のときだけ
L4 外部参照	コードベース全体、ビルドログ、外部 API レスポンス	Subagent が受け取る / メインは要約のみ	メインは要約だけ見る

核心は — L1・L2 は頻繁に見るため短くなければならない。L3・L4 はまれにしか見ないので長くてよい。同じ情報が間違った層にあればトークンが無駄になる。

誤配置	結果
L4 → L1（コード全体をペルソナに）	毎セッションのコンテキスト消費が膨大
L1 → L4（役割定義を外部ファイルに）	協働者は毎セッション自分のペルソナを知らない
L2 → L3（メモリインデックスをオンデマンドに）	協働者は自分のメモリが存在すること自体に気づかない
L3 → L2（全メモリ本体を自動ロードに）	インデックスの自動ロードが意味を失う

2. トークン節約 → 判断品質 — 因果の連鎖

なぜトークン節約がコスト問題だけでなく判断品質の問題なのか。

2.1 シグナル対ノイズ比

100k の context window を仮定する。ペルソナ + メモリ + 関係ない自動ロードが 80k を占めると、判断グレードのシグナルに残るのは 20k だけ。同じウィンドウで自動ロードを 30k に縮めると、シグナルの空間は 70k に育つ。同じ判断がはるかに深く展開される。

判断品質はコンテキストサイズではなく、シグナル比でスケールする。

2.2 注意の拡散

協働者も人と同様、コンテキストが増えるほど何が重要かの判断に揺らぎが生じる。100k の中からキーとなる行を見つけるのは 30k の中から見つけるより精度が落ちる。ノイズを削るだけで判断品質が上がる。

2.3 最初のトークンまでのレイテンシ

トークンが少ないほど応答が速くなる。応答が速いほど運営者のフローが保たれる。途切れないフローは運営者の意図の負荷も減らす。運営者側でも品質が上がる。

3. 実際のローテーションの節約パターン

トークン節約のために積極的に実行していること。

3.1 メモリインデックスを 200 行以下に

MEMORY.md のインデックスは 200 行以下に保つ。それを超えると自動ロードウィンドウの外に落ち、意味を失う。200 行のプレッシャー自体が刈り込みのモチベーションになる。

3.2 ディレクトリ全体を読まない

大きなディレクトリをワンショットで読み込むとトークンが爆発する。まず ls でリストアップし、grep で絞り込み、特定のファイルだけを Read する。ペルソナの安全ガードとして焼き付けられている。

3.3 500 行超のファイルはヘッダー/範囲を先に

大きなファイルを端から端まで読まない。まず先頭 100 行で構造を確認し、必要な範囲だけを Read する。同じ判断が 1000 行ではなく 200 行のコンテキストに対して行われる。

3.4 深い作業を Subagent に渡す

検索、レビュー、ビルド、テストはサブで深く。メインは要約だけを見る。メインコンテキストは判断モードに留まる。（参照: Part 6 — Multi-agent 委任）

3.5 メモリ刈り込みのサイクル

プロジェクトメモリは月次、フィードバックメモリは四半期、リファレンスメモリは半年ごと。古くなったコンテキストが意味のないスロットを占有すべきではない。このサイクルが動作するメモリ構造自体は Part 3 — Memory システム で扱う。

3.6 トークン監査ツール

/token-audit のようなツールを定期的に実行する。60 日以上参照されていないエントリ、膨張したメモリ、使われていない自動ロードを報告する。刈り込みの判断の根拠になる。

4. コストが高いコンテキストの場所 — どこから刈り込むか

トークンコストは場所によって異なる。同じ 100 行でも配置によって 10 倍コストが変わりうる。

場所	一行あたりのコスト（相対値）	刈り込み優先度
ペルソナ（L1）	毎セッション × 毎レスポンス	★★★ 最優先
メモリインデックス（L2）	毎セッション	★★
プロジェクト CLAUDE.md（L2）	そのプロジェクトでの毎セッション	★★
メモリ本体（L3）	Read されたときだけ	★
コードファイル（L4）	Read されたときだけ	（刈り込みでなく分割）

ペルソナが最もコストが高い。ペルソナの同じ 100 行は、毎セッション × 毎レスポンスの掛け算でコストが積み上がる。だからペルソナは最も小さくし、最も頻繁に刈り込む。

5. 落とし穴 — トークンエコノミーが崩れるパターン

5.1 「念のため」インライン

いつか役立つかもしれないからとガード一つ、ポリシー一つ、例一つをペルソナに追加する。一年後にペルソナは 1000 行になっている。→ 原則を守る：「実際に2回トリガーされてから初めてペルソナに格上げ。」

5.2 メモリ本体がインデックスにコピーされる

メモリ本体の一部を「要約」としてインデックスにコピーする。インデックス自体が膨張する。→ インデックスは常に一行の hook だけ。本体はそれぞれのファイルに。

5.3 定期的なトークンレビューなし

毎日使っているのにトークンがどこへ行くか知らない。→ トークン監査をスケジュールする。どの自動ロードが大きいか、どのメモリが使われていないか。

5.4 サブの結果をメインに丸ごと吸収する

サブが 1000 行を返してメインがすべてを吸収する。サブを使う理由が失われる。→ サブの結果は常に要約（メイン用）+ 全文（ファイルまたは次のサブ呼び出し用）に分割する。

5.5 コンテキスト上限に達する

トークンがウィンドウの末端に達して自動コンパクションが発動するか、最も古いコンテキストが切り落とされる。切り落とされた部分が運営者が意識的に追っていなかった重要な情報かもしれない。→ コンテキスト使用量を常に把握する。80% に達したら整理する。

6. トークンエコノミーを意識し始めてからの変化

トークンエコノミーを一級のものとして扱い始めてから変わったこと。

項目	導入前	導入後
セッション開始のコンテキスト	一定 60〜70k	インデックス + ペルソナ = 15〜20k
深い作業に使えるトークン	30〜40k	80〜85k
コンテキストコンパクションの頻度	頻繁	まれ
同じ作業での判断品質	普通	深い（ノイズが少ない）
応答速度	普通	速い

核心は最後の二つ — 同じ作業がより深い判断に展開され、より速く展開される。トークン節約は判断品質に直接変換される。

7. 一つの原則に圧縮する

トークンエコノミー設計の核心は一文に圧縮できる。

「毎セッション必ず目にするものだけインライン。頻繁に目にするものは自動ロード。ときどき目にするものはオンデマンド Read。ほとんど目にすべきでないものは外部。高コストのミスは間違った層への配置だ。」

これが成立するとき、トークンエコノミーは判断品質のアクセラレーターになる。壊れるとき — ノイズが判断の空間を食い荒らし、協働者は何が重要かを見失う。

次の投稿が最後だ。ペルソナ、メモリ、Skills、Hooks、Multi-Agent、検証、トークン — これらすべてが実際に毎日どのように起動して終了するかを扱う。Part 9 — Session プロトコル