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億トークン」って実際どれくらい使えるのか、全部測ってみた話
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 で受ける予定です。