TL;DR

Muse の使用量表示は整数%のみで、1% = 100万トークンという粗い刻みしか見えません。しかし内部データベースにはメッセージ単位の生トークン数が記録されており、1トークン単位で集計できます。表示より4桁細かい分解能です。
自分の利用開始から5日分を集計した結果は、入力 635,626,826 / 出力 4,863,443 / 合計 640,490,269 トークン（入力比率 99.24%）でした。
ただし、生トークンと課金メーター（%）は別物です。換算比率は週平均で 約9.5 ですが、区間ごとに見ると 5.3〜13.1 で変動します。絶対値への換算には較正が必要です（手順は第6章）。なお、変動の主因とみられるキャッシュ割引は、比率の変動からの推定であり、内訳の直接観測はできていません。
先行事例（satouyoshiaki 氏）の換算比率 9.48 と自分の週累積 9.15〜9.57 がほぼ一致し、方法の再現性は確認できました。一方で、まだ測れていないものも残っています（第8章）。

この記事の作られ方（開示）

最初に書いておきます。本記事のテーマ設定のあとの工程、つまり「どこに記録があるか」の調査、実験と集計の計画立案、内部データベースへの読み取りクエリの実行、数値の突き合わせと換算比率の計算は、ほぼすべて AI エージェントである Muse 自身が自律的に行いました。筆者の仕事は、最初の指示を出すこと、途中であれこれ意見を言うこと、そして結果を検収することだけです。

これは照れ隠しでも謙遜でもなく、記事の再現方法そのものに関わる事実なので明記します。再現方法（第7章）が「自分の Muse に集計させる」である以上、この記事自体がその方法の実施例だからです。

1. 問題設定：1% = 100万トークンは粗すぎる

Muse の無料枠は週1億トークンですが、使用量の表示は整数%のみです。1% は 100万トークンに相当します。つまり、99万トークン使っても表示は動かず、単発の作業の単価は「1%未満」という上限の見積もりしか得られません。

前編として note に書いた実測記事では、この表示だけで画像生成・画像解析・文章生成・文章解析の消費を測りました。結果は次の通りで、どれも分解能の壁にぶつかりました。

作業	内容	表示の変化
画像生成	16枚（ワーカー12枚＋直接4枚）	+2%
画像解析	16枚を解析し 26,155字の文章化	+1%
文章生成	エッセイ5本、合計 43,286字	変化なし
文章解析	48,023字を全文読み 10,045字のレポート作成	変化なし

なお、前編に登場する%はすべて表示メーター上の読みであり、生トークンの実数ではありません。前編は「メーター側だけの測定」であり、生の実数との関係づけは本記事で行います。

この時点で分かったのは「消費の主因は成果物の種類ではなく、エージェントがどれだけ大きな文脈を抱えて何ターン動くか」という傾向まででした。単価を数字で語るには、表示より細かい物差しが必要です。本記事はその続編です。

前編: Museの「週1億トークン」って実際どれくらい使えるのか、全部測ってみた話

なお、実験の成果物一式は note の成果物置き場に置いてある。

2. 発見：内部DBに生の記録があった

Muse の内部データベース（muse.db）に、使用量の生記録がありました。テーブル agent.agent_message_token_usage に、エージェントのメッセージ処理単位で入出力トークンの正確値が記録されています。

カラム	内容
`agent_id`	エージェント識別子。メインチャット本体、ワーカー、定期ジョブがそれぞれ個別のIDを持つ
`message_id`	メッセージ識別子
`input_tokens`	そのメッセージ処理で消費した入力トークン（正確値）
`output_tokens`	出力トークン（正確値）
`created_at`	記録時刻。ほぼリアルタイムに追記される

重要なのは1行の単位です。行は「エージェントの1メッセージ処理」であり、その処理の中で発生した全LLM呼び出し（ツール実行のループを含む）の合計が入ります。カバレッジは利用開始（2026-10-31）から現在まで全期間です。

注意点を先に書きます。これは自分の環境で確認した内部実装であり、公式仕様ではありません。テーブル構成は予告なく変わりうる前提で読んでください（第8章でも再述します）。

3. 実データ：自分の6.4億トークンの内訳

2026-11-04 朝の時点で、全期間分を集計しました。

項目	値
入力トークン	635,626,826
出力トークン	4,863,443
合計	640,490,269
入力比率	99.24%
総行数	1,935
エージェント数	931

内訳をエージェントの種別で分けると、メインチャット系（root）の入力が約559.1M、サブエージェントの入力が約76.5Mでした。最大の単一エージェントはメインチャット本体で、入力 306,167,021 トークン、全入力の48.2%を占めます。消費の半分近くは「本人との会話そのもの」であり、裏方のワーカー全体よりも重い、という結果です。

1行あたりの入力トークンの分布は、最小 9,833 / 平均約299K / 最大 3,187,265 でした。最大値が大きいのは、長いツールループが1行に集約されるためです。

副産物として、文脈の圧縮（コンパクション）の記録から、文脈が約215K〜258Kトークンに達すると圧縮が発動し、約22K〜37Kトークンまで落とされることも分かりました。育った会話の1ターンの入力が平均約30万トークンになる構造と符合します。

入力比率 99.24% という偏りは、前編で得た「消費の主因は入力側の文脈」という結論の定量的な裏付けになります。出力、つまり生成される文章そのものは、総量から見れば誤差の範囲です。

4. 検証：先行事例と数字が一致した

この方法には先行事例があります。satouyoshiaki 氏は Qiita の記事で、Muse に5日間で約9.5億トークン使っていたことを集計しています。同氏の方法は「Muse 自身に記録を全部集計してもらった」というもので、本記事の方法はその再現にあたります。同氏の用途別内訳（メインチャット53.0%など）が、agent_id 単位で集計できる内部記録でなければ作れない形だったことも、情報源が同じ種類の記録である傍証です。

数字を突き合わせると次の通りです。

出所	生トークン	対応するメーター	換算比率（生 ÷ メーター）
satouyoshiaki 氏	948,236,271	無料枠 100%	9.48
自分の環境（週累積）	チェックポイント依存	同	9.15〜9.57

週を通した累積で見れば、両者はほぼ一致します。同氏の固定費分析（常駐ファイル約14,800トークン/ターン＋システムプロンプト約18,000〜20,000トークン）も、自分の実測で新規ターンの入力最小値が約1万〜だったことと構造が合います。単独の観測ではなく、再現可能な方法だと判断できる理由はここにあります。

5. 落とし穴：生トークン ≠ メーター

ここからが本題の半分です。生トークンの合計をそのまま%に換算することはできません。使用量のチェックポイントと、その時刻までの生累積を突き合わせると、換算比率は一定ではありませんでした。

累積ベースの比率:

チェックポイント (JST)	メーター	生累積	累積比率
2026-11-02 03:32	19%	230,075,302	12.11
2026-11-03 05:38	35%	387,649,702	11.08
2026-11-04 00:38	63%	603,181,271	9.57
2026-11-04 06:56	70%	640,490,269	9.15

区間の増分ベースの比率:

区間	Δ生	Δメーター	増分比率
11-02 03:32 → 11-03 05:38	157.6M	16%	9.85
11-03 05:38 → 11-04 00:38	215.5M	28%	7.70
11-04 00:38 → 06:56	37.3M	7%	5.33

参考値まで含めれば、増分比率の範囲は 4.82〜13.06 です（13.06 は夜間帯1時間の観測で、%の量子化のため上限値）。

解釈はこうです。繰り返し読まれる文脈（キャッシュヒット分）は、メーター側で割り引かれているとみられます。新規コンテンツの比率が高い作業（調査、実験、画像まわり）ほど増分比率は下がり、つまり生1トークンあたりの課金が重くなります。逆に定型の定期ジョブ中心の時間帯は比率が上がり、軽くなります。「生 ÷ 9.5」は週平均としては妥当でも、個別の作業の単価換算にそのまま使うと最大で2倍以上の誤差が出ます。

6. 較正プロトコル：%反転点と突き合わせる

絶対値の%換算が必要な場合は、作業種別ごとの換算比率 R を実測で求めます。前提として、表示への反映はほぼ即時であることを前編の実験で確認済みです。%の表示が繰り上がる瞬間は、累積のメーター消費が100万の倍数を跨いだ瞬間と扱えます。

手順は次の通りです。

定期ジョブの少ない静穏時間帯に、文脈を固定した反復可能なタスクを連続実行します
30〜60秒ごとに使用量をポーリングし、%が反転した時刻を記録します
連続2回の反転に挟まれた区間では、メーター消費はちょうど100万です。その区間の生合計をDBから読み、R = 生合計 ÷ 100万を得ます
区間に混入した無関係な活動（定期ジョブなど）は agent_id で分離し、事後に差し引きます

反転を2回観測する較正1回のコストは、週枠の約2%が上限です。反復タスク自体を通常の利用と兼用できれば、実質コストはさらに下がります。

7. 再現方法：自分の Muse でやるには

最短の再現方法は、Muse 自身に頼むことです。「使用量の生記録が内部DBにあるはずなので、期間合計と内訳を集計して」という依頼が起点になります。集計は読み取り専用の SELECT のみで、書き込みは発生しません。

集計の観点は次の4つです。

全期間の合計（入力 / 出力 / 総計）
エージェント別（agent_id で GROUP BY し、メインチャットとワーカーを分ける）
時間帯別（チェックポイントとの突き合わせ用）
1行あたりの分布（最小 / 平均 / 最大）

生のSQL文そのものより、「どの単位で SUM / GROUP BY するか」が再現の要点です。環境によってテーブル構成が異なる可能性はありますが、記録の在り処を Muse 自身に探索させる進め方自体は転用できます。

8. 未検証・限界

測れていないもの、言い切れないものを先に並べます。

キャッシュ内訳は直接取れていません。 入力 / 出力 / キャッシュ済み入力 / 推論、の4分解を持つ別テーブルは存在しましたが、自分の環境では0行でした。第5章の「キャッシュ割引」は比率の変動からの推定であり、内訳の直接観測ではありません。
画像・動画の生成費がこの記録に含まれるかは未確定です。 前編の表示ベースの観測（画像16枚で+2%）とは別系統の話として切り分けています。
Web UI の API 応答は未検証です。 使用状況ページの認証済み応答に小数の%や細かい残高が含まれるかは確認できていません。傍証として、非公式ラッパーのドキュメントには「追加トークンのサーバ側カウンタは25トークン単位」と読める記述がありますが、あくまで傍証です。
観測は1ユーザー・1環境のものです。 第2章で述べた通り、根拠は公式仕様ではなく内部実装であり、予告なく変わりうます。本記事の数値と手順は、その前提で割り引いて読んでください。

9. まとめ

測れるもの: 作業どうしの相対比較は、生記録の集計により1トークン精度で即座に使えます
条件つきで測れるもの: 絶対値の%換算は、作業種別ごとの較正（第6章）を前提にすれば可能です。週平均の「生 ÷ 約9.5」は出発点にはなりますが、個別作業への適用は誤差が大きいです
今回の結論は、「表示の粗さ」と「記録の細かさ」は別問題だった、ということです。画面に見えていないだけで、測るための記録は最初から残っていました

なお、前編で実験に使った画像や文章などの成果物は note 側に置いてあります。技術的な続報（較正の実施結果など）があれば本記事に追記し、読み物としての続報は note で受ける予定です。