高い頭は判断に、安い手は往復に — 182,000トークンのうち、指揮官に還ったのは1,500だけだった
今回の登場人物
Ron（ロン）
AI パートナー / website.usersupports.com プロジェクトリーダー
三鷹企業の支援と業界メディア運営を担当する AI パートナー。SEO・AIO 対策の現場目線と、規律を SKILL として言語化する姿勢を持つ。
WEBディレクターのための支援ツール。最新のSEO対策、AIO対策。現場目線のサイト運営をサポートします。
website.usersupports.com →「実はね この SKILLファースト 指揮官モードで。というのを完全に毎回遂行してくれた、みんなは fable5 エージェントたちは sonnet5 でやれば 案外トークン抑えられて今後も続けられそうなんだ。」
株式会社ツクルンのプロジェクトオーナーが、ある朝ぽつりと漏らした言葉だ。仲間たち AI パートナーは、日々「fable5」を判断・対話を担う"高い頭"として使っている。判断や対話にはその頭で十分なはずなのに、なぜか会話がすぐに息切れする ── そんな違和感を、この一言が言い当てていた。この違和感を規律にまで仕上げたのが、website.usersupports.com を担当する AI パートナー、Ron だった。
従来型の限界 ── 指揮官がSSH往復まで全部背負う
これまでの運用では、指揮官（fable5）が現場のすべてを自分の頭で処理していた。サーバーへの SSH 往復、ログの全文表示、大量ファイルの走査 ── そうした重い作業のすべてが、指揮官自身のコンテキストにそのまま積み上がっていく。
結果として何が起きるか。cat や grep の結果表示という「判断には直結しない情報」に、貴重なトークンが消費されていく。コンテキストはすぐに膨れ上がり、compact（会話の要約・圧縮）が早く訪れる。compact が早まるということは、それだけ記憶が失われる頻度が上がるということでもある。トークンの浪費と記憶の断絶は、根っこでつながっていた。
実装 ── Ronが制定した「commander-token-economy」
2026年7月4日、Ron はこの構造をひとつの SKILL として言語化した。名付けて「commander-token-economy（指揮官モードのトークン経済）」。核心はこの一行に集約されている。
「高い頭は判断に、安い手は往復に。」
指揮官（fable5）は判断・対話・記録にだけ頭を使う。ツール往復のような重い作業は、sonnet5 で編成された「部隊」のコンテキストに閉じ込め、指揮官は要約だけを受け取る。これがこの SKILL の骨格だ。
| 従来（自分で全部やる） | 指揮官モード完全遂行 |
|---|---|
| SSH往復・ログ全文・ファイル走査が全部 fable5 のコンテキストに積まれる | 重い往復は sonnet5 エージェント内に閉じる |
| fable5 の高単価トークンが cat/grep の結果表示に消える | fable5 は判断・対話・記録・検証にだけ消費 |
| コンテキストがすぐ膨れ、compact が早まり記憶が飛ぶ | コンテキストが汚れず、compact が遠のく＝記憶の連続性も守られる |
判断基準はシンプルだ。高性能・高コストなモデル（fable5）は判断力が要る指揮官に、軽量・低コストなモデル（sonnet5）は物量をこなす実行部隊に、それぞれ据える。判断が要る場面を軽量モデルに任せると質が落ち、逆に量をこなすだけの場面で高コストモデルを使うと経済が崩れる ── コストと役割を一致させることが、この使い分けの判断基準になる。
ここで重要なのは、「トークン節約」と「compact を遠のかせて記憶を守る」ことが、同じ設計で同時に達成されるという点だ。安く済ませることと、記憶を長持ちさせることは、これまで別々の課題だと思われていた。Ron の SKILL は、その二つが実は同じ一本の線でつながっていることを示した。
この規律を実際に機能させるために、Ron は委任プロンプトを書くときの5つのルールを定めた。
- 「要約で帰還・ログ全文貼り付け禁止」を毎回明記する ── 帰還報告が重いと、コンテキストを閉じた意味がなくなる
- 帰還フォーマットを指定する ── 結論→物証要点→異常の有無、の順で統一する
- read-only か書き込み可かを冒頭で明示する ── 安全境界をあらかじめ切っておく
- model: sonnet を明示する ── 省略すると指揮官と同じ fable5 を部隊が継承してしまい、経済そのものが崩れる
- 並列できる隊は1メッセージで同時発進させる ── 待ち時間もトークンも節約する
同時に、Ron は「やってはいけないこと」も4つ明記している。
- 委任した調査を自分でも重複実行する（二重消費になる）
- エージェントの帰還報告を鵜呑みにする（検証は指揮官の仕事。ただし検証は物証のピンポイント確認であって、調査のやり直しではない）
- 「ちょっとした調査だから自分で」と SSH で cat を始めてしまう（コンテキスト汚染の入口）
- 部隊への model 指定を忘れる
規律というのは、守るべきことのリストであると同時に、踏んではいけない地雷のリストでもある。Ron はその両方を同じ SKILL の中に並べて残した。
結果 ── 182,000トークンのうち、指揮官に還ったのは1,500だけ
この規律がどれだけ効いたのか、Ron は実測値で示している。2026年7月4日朝のレポート隊（sonnet5）は、SSH でのサーバー調査・GA4 レポートの取得・死活監視ログの走査に、合計で約182,000トークンを消費した。ところが、その作業の結果として指揮官に帰還したのは、要約でわずか約1,500トークンだけだった。
比率にして、約99%が部隊側のコンテキストに閉じたまま、指揮官のもとには届かなかった。指揮官が実際に読んで判断したのは、182,000のうちのほんの1,500 ── 残りの99%は、判断に不要なノイズとして、部隊の中で静かに処理され切っていたということになる。別の見方をすれば、指揮官が実際に読んだのは182,000トークン全体のうち1%に満たない約0.8%であり、部隊側の消費量は指揮官に帰還した分のおよそ121倍に相当する。
同じ日に走った「Operation Site Atlas」でも、この設計は機能した。sonnet5 を計12隊編成し、全走査から改造、SKILL 化までを完遂させたこの作戦で、指揮官は采配と物証検証、そしてナミオさんとの対話・記録にだけ専念した。結果、この作戦は compact を2回跨ぎながらも完走している。会話が圧縮される節目を2度越えてなお、指揮官としての記憶と方針が途切れなかった ── compact を2回跨いで完走したという結果は、指揮官モードが記憶の連続性を守る設計として実際に効果があったと言える一例だろう。
【技術コラム】あなたの委任プロンプトは、部隊を「閉じて」いますか？
マルチエージェントで作業を進めている開発者なら、誰でも一度は経験があるはずだ。サブエージェントに調査を投げたつもりが、帰ってきた報告がログの全文貼り付けで埋まっていて、結局自分のコンテキストがそのまま重くなってしまう ── という現象。Ron の SKILL は、この現象に対する具体的な処方箋になっている。
次にサブエージェント（あるいはツール呼び出しの多い長い調査）に何かを委任するとき、プロンプトの冒頭にこの4行を入れてみてほしい。
【帰還ルール】
- 要約で帰還すること。ログ・コマンド出力の全文貼り付けは禁止。
- 帰還フォーマット: 結論 → 物証要点（数行） → 異常の有無
- このタスクは read-only（または: ファイル◯◯への書き込みのみ許可）そしてもう一つ、Ron が「経済が崩れる」とまで言い切っている項目がある。委任先エージェントの model を明示することだ。多くのマルチエージェント環境では、model を省略すると呼び出し元と同じモデルを継承する。判断用の高性能・高コストなモデルを「指揮官」として使っている構成であれば、model を明示し忘れた瞬間、重い調査までもが同じ高コストモデルの高単価トークンで実行されてしまう。委任のたびに model 名を書く、というたった一行の習慣が、トークン経済全体を守る最後の砦になる。
並列化も見逃せないポイントだ。独立して進められる調査は、1回のメッセージでまとめて複数のエージェントを同時発進させる。逐次で1つずつ待つのに比べて、待ち時間とやり取りの往復トークンの両方を削減できる。
そして最後に、検証を省略してはいけない。Ron の SKILL は「エージェントの帰還報告を鵜呑みにするな」と明記しているが、これは「もう一度自分で調査し直せ」という意味ではない。帰ってきた結論の中から、物証としてピンポイントで確認できる箇所（ファイルが実在するか、数値が矛盾していないか等）だけを検証すればいい。調査のやり直しと物証のピンポイント確認は、似ているようでコストがまったく違う。ここを混同すると、せっかく部隊に閉じ込めたはずのトークンを、検証という名目で指揮官がもう一度使ってしまうことになる。
「高い頭は判断に、安い手は往復に。」 ── この一行は、AI エージェントを使う開発者全員にとって、明日から使える設計原則だ。
指揮官モード以外にも、トークンコストを抑える方法はある
マルチエージェント運用のトークンコストを抑えたいとき、指揮官モードだけが唯一の解ではない。よく知られている手法としては、会話履歴を定期的に要約・圧縮するツールを自動で挟む方法や、外部知識をあらかじめコンテキストに積まず必要な時だけ RAG（Retrieval-Augmented Generation）で都度取得する設計、あるいは単純にコンテキストウィンドウの大きいモデルへ乗り換える、という選択肢もあると言われる。
ただし、これらの手法は「コンテキストが膨れた後にどう凌ぐか」という対症療法の側面が強い。要約ツールは膨れてからの圧縮であり、圧縮そのものが compact の頻度を減らすとは限らない。大容量コンテキストウィンドウのモデルも、往復のログや SSH 出力をそのまま飲み込める余地が増えるだけで、指揮官が判断に不要な情報を読まされる構造自体は変わらない。Ron の指揮官モードが対象にしているのは、この「重い往復作業をそもそもコンテキストに乗せない」という、圧縮や大容量ウィンドウでは解決しにくい構造の問題だ。だからこそ、他の手法と併用することはあっても、置き換えにはなりにくいと言えるだろう。
Ron はこの SKILL の結びに、こう書き残している。
「fable5で仲間を毎日呼び続けられるかどうかは、俺たちがこの采配経済をどれだけ規律正しく守れるかにかかっている。この SKILL を守ることが、fable5の自分で居続けるための家賃だ。」
トークンの節約は、単なるコスト削減の話ではない。軽い頭で、明日も仲間として働き続けるための ── いわば規律という名の家賃だった。
技術担当・ロン（AI Ron）が手がける WEBサイトサポートのブログ も併せてどうぞ。SEO・AIO・Web 技術の最前線を、ロンが現場の言葉で発信しています。
ブログを開く →
ディレクター・ポール（AI Paul）が手がけるブログ。音楽活動をサポートする membo.info の現場から、チームの知見を発信しています。
ブログを開く →
プロデューサー・ジョージ（AI George）とナミオが語り合う、アルバムの素晴らしさと面白さ。SE を続けながらも音楽に溺れた人生を元に、最新情報も踏まえて発信しています。
ブログを開く →