トークノミクス概論

トークノミクス(Token Economics)はMoAI-ADK v3.0の第一の柱です。トークン単価が下がっても、エージェント的開発はトークンを大量に消費するため、コストを決めるのはモデル価格ではなくトークンの運用方法です。このページはトークノミクスの全体構造を概観し、各サブトピックの深掘りページへリンクします。

エージェントが複数走り、コンテキストが長くなり、推論が深まるほど、単一セッションのトークン消費は急激に増加します。トークン単価の下落がトークン使用量の増加に追いつかない状況では、ハーネスがトークンをどのように測定し、ルーティングし、ダイエットし、防御するかがコスト競争力の中核になります。

MoAI-ADKの答えは3点です。

1. タスクごとに適切なモデルと推論深度を割り当てる — 計画は深く、実装は安く、検証は独立して。
2. コンテキストをダイエットする — 常時ロードされる指示を最小化し、プロンプトキャッシュ命中率を測定する。
3. 予算をシステムが守る — トークン使用を追跡し、しきい値超過前に安全に停止する。

v3.0の製品差別化は3本柱で構成されます。トークノミクスはその最初の柱であり、残り2本柱と密接に接続されます。

トークノミクス (このページ) — 測定し、ルーティングし、ダイエットし、防御する。

自律連続ループ — いつ止まり、いつ続くか。自律連続ループページで扱います。

エージェント的ハーネス — どのエージェントが、どのプロファイルで、どう進化するか。3層アーキテクチャ、プロファイルマトリクス、ハーネス自己進化ページで扱います。

トークノミクスは4つの層で構成されます。各層は独立して動作しながら相互に補完します。

flowchart TD
    A["Layer A — Metering
per-SPEC トークン会計"]
    B["Layer B — Routing
Tier × Phase 宣言的モデル/effort"]
    C["Layer C — Verify-diet
verbatim 証拠はファイル、コンテキストには要約"]
    D["Layer D — Budget defense
90% hard-limit graceful stop"]

    A --> B
    B --> C
    C --> D

全エージェント呼び出しのトークン使用量をper-SPEC単位で会計します。moai spec audit出力のトークンカラムとprogress.mdのトークン会計セクションがこの層の成果物です。何がトークンを消費したかを知らなければ最適化できません。

維持される各エージェントにモデルと推論深度(effort)を宣言的に割り当てます。アクティブプロファイル(high/medium/low)がプロファイルマトリクスの 1 列を選択し、各エージェントをその作業に見合った推論深度の段に配置し、Sonnet は単発の機械的な行に限定して、コスト対品質を最大化します。詳細なプロファイルマトリクスはプロファイルマトリクスページを参照してください。

検証コマンドの長文出力をディスクファイルにリダイレクトし、コンテキストにはexit codeとbounded tail(最大50行)のみ残します。このファイルリダイレクト契約(file-redirect contract)は検証証拠の完全性を維持しながらコンテキスト消費を削減します。詳細なメカニズムはトークン予算管理と安全な中止ページを参照してください。

エージェントのトークン使用量がhard-limit(デフォルト90%)に達すると安全な中止(graceful abort)を実行します。進行状況をprogress.mdに保存し、ペースト可能なresumeメッセージ(paste-ready resume)を発行し、自動/clearは決して行いません。詳細な手順はトークン予算管理と安全な中止ページを参照してください。

トークノミクスでよく見落とされるコスト構造がプロンプトキャッシュ (以前に送信した入力を一時的に保存しておく機能) です。Anthropic のプロンプトキャッシュは、レンダリングされたリクエストの先頭部分 (tools → system → messages の順序) に対してプレフィックス一致で動作します。最初の 1 回はそのプレフィックスをキャッシュに記録する必要があるため 1.25 倍のコストがかかりますが、以降同じプレフィックスを再利用するターンでは 0.1 倍のコストで読み出せます。1 ターンの入力を 10 倍近く安くできる構造です。

ここには 2 つの落とし穴があります。

第一に、キャッシュの寿命は 5 分です。ただしこの 5 分は「5 分後に期限切れ」ではなく「5 分を超える空き時間が挟まると期限切れ」です。ユーザーゲートで回答を待つ時間が長びくとキャッシュが期限切れとなり、次のターンはプレフィックス全体を改めて 1.25 倍で記録し直さなければなりません。だからこそ、遅くに尋ねる質問ほどコストが大きくなります。

第二に、キャッシュは書き込み中には読めません。同じ定義を持つエージェントを複数同時に立ち上げると、同時に出発したリクエストは最初の 1 つがキャッシュに書き込んでいる間を待ってくれないため、すべてがコールド (cold) 状態でプレフィックスをそれぞれ記録し直すことになります。

flowchart TD
    T1["ターン 1
指示・ルールのプレフィックスを
初めて送信"]
    W["キャッシュ記録
コスト 1.25 倍"]
    T2["ターン 2 ~ N
同じプレフィックスを再利用"]
    H["キャッシュヒット
コスト 0.1 倍"]
    GAP["5 分を超える空白
ユーザーゲート待ちなど"]
    MISS["キャッシュ期限切れ
再び 1.25 倍で再記録"]

    T1 --> W
    W --> T2
    T2 --> H
    H --> T2
    T2 --> GAP
    GAP --> MISS
    MISS --> W

この構造のため、MoAI-ADK は実行順序を意識的に調整します。ユーザーゲートはコンテキストが小さいうちに早めに尋ね、同じ種類のエージェントを並列に立ち上げるときは 1 つを先に立ち上げてキャッシュを温めてから残りを続けて立ち上げ (stagger-spawn)、セッション開始時にロードされる指示ファイルを途中で編集せず作業の終わりに回します。キャッシュはゲートの意味を変えません。承認ゲートはそのまま必須であり、ただそのゲートを「いつ、どの順序で」尋ねるかだけを抑えるのがキャッシュ認識実行です。

Layer Bのルーティングを具体化するのがモデルプロファイルポリシーです。MoAI-ADK v3.0はHaikuをルーティングモデルセットから除外し、作業の性格に合わせた3層構造で作業を分散します — 単発の行にはSonnet、エージェンティックな階梯全体にはOpus、呼び出し頻度が最も低い2行にはmax effortです。この設計の根拠とプロファイルマトリクス実装は次の2ページで扱います。

• 3層エージェントアーキテクチャ — なぜHaikuを除外したか、DeepSWEリーダーボード根拠
• プロファイルマトリクス — 単一の 3 列 per-agent プロファイルマトリクス

moai cgはClaudeリーダーとGLMワーカーを組み合わせたハイブリッドモードです。戦略、計画、監査はClaudeが担当し、大規模実装作業はGLMが担当します。実装中心の作業で60-70%のコスト削減効果があります。

GLM-5.3は1Mコンテキストの単一モデルで、z.ai暗黙プロンプトキャッシュが自動適用されます。トークン単価はz.aiがまだ公表していません。前世代のGLM-5.2は1Mトークンあたり入力$2 / 出力$8でした。定額のCoding Planで使う場合、この単価が請求を左右することはありません。Claude Code が報告する context_window_size は Claude スロット基準であるため、GLM セッションでは生の値が ~180K と出ても、MoAI が 1M に修正して 50% 閾値で運用します。statusline の CW% ゲージを信頼してください。CGモードとGLM単独セッション(moai glm)の詳細はMulti-LLMセクションを参照してください。

このページの記載内容のうち、実装状態を明確に区別します。

実装完了 (配信中) — 4層構造(A/B/C/D)全層、3層モデルポリシー(プロファイルマトリクスリゾルバ)、CGモード、検証ダイエットファイルリダイレクト契約、安全な中止メカニズム。

設計段階 (ロードマップ) — GLMバックエンドeffortオーバーレイのwire有効性はライブGLMセッションのアウトバウンド観測が必要な実証課題です。プロファイルマトリクスページでこの区別を明示します。

• トークン予算管理と安全な中止 — Layer Dの深掘り (モデルごとのしきい値、paste-ready resume構造)
• 3層エージェントアーキテクチャ — ハーネスアーキテクチャの基礎
• プロファイルマトリクス — 単一の 3 列 per-agent プロファイルマトリクス