Token Optimization

一言で

Agent ROI

🚀 月へロケットを送る方法は 2 つ。安いロケットを何発も打って「どれか当たれ」と祈るか、高品質な 1 機を作り込んで一発で当てるか。トークンが安かった頃は「数撃ちゃ当たる」でよかったが、今は 1 回で仕留める方が結局は安い。

複利でエラーが効いてくる（Compound Error Problem）

1 ステップあたり 99% の精度でも、50 ステップ のワークフローでは最終精度は 約 60% まで低下します。LLM は非決定的なので、小さな誤差は対処しないと 複利で効いてきます。最速のトークン削減策は、小さなミスを早めに見つけて「リトライを起こさせない」 ことです。

Advice 1 — context は「必要最小限」を渡す…

Context Engineering ↗ で見たとおり、context window はターンごとに膨らみ、詰め込みすぎると context rot（コンテキスト劣化） で agent はむしろ鈍くなります。

• copilot-instructions は短く ── 本当に「毎回」効くルールだけ残す
• skill を増やしすぎない ── React・TypeScript・Tailwind などは学習データで十分
• skill の中身も短く ── 「Caveman skill」は本文 1 行（Be concise）で置き換えられる
• path-instruction をフォルダ全体に撒かない ── そのフォルダでの呼び出しで毎回静かに読み込まれる
• 「念のため」のファイル先読みをしない ── 必要になったら agent に取りに行かせる

Advice 2 — …でも、必要な情報は省かない

レバーの反対側です。context が 不足 すると、agent は 仮定 で穴を埋めます。その仮定が、先ほどのグラフの「失敗ループ」になります。

• 目的・制約・「完了」の定義を明示する ── 曖昧な依頼は、agent が意図を推測しながらリトライを繰り返すぶん、饒舌な依頼より高くつく
• 正しいファイルを指定する ── リポジトリ全体を闇雲に grep させない
• 自明でない規約は前置きする ── 命名・エラー型・公開 API・セキュリティ境界など
• 触ってほしくない場所も伝える ── 後の「誤ファイル修正 → ロールバック」リトライを防げる
• エラーやログ行はそのまま貼る ── ツール呼び出しを 1〜3 回節約できる

Advice 3 — プロンプトエンジニアリング

💡 プロンプトは常時オン ── 一度送ると、以降のターンすべてで system + tools と一緒に課金されます。だからこそ、丁寧に書く価値があります。

Advice 4 — Research → Plan → Implement

タスクを分割統治する。 調査・計画・実装を 1 セッション でまとめてやらないでください。コンテキストが汚染され、エージェントが迷子になります。3 つの順次エージェントに分け、それぞれに必要最小限のコンテキストだけを渡します。

💡 Copilot CLI ↗ の /research・/plan・/fleet がこの 3 フェーズに対応しています。各フェーズは別のコンテキストウィンドウで走るので、肥大化した Research セッションが Implementer に届きません。

Advice 5 — 決定的なコントロール

テスト・リンター・型チェック・セキュリティスキャンは「人間のためのチェック」だけではありません ── 1 回のバグ修正が 4 段重ねの劣化スパイラルになるのを止める トークン節約のガードレール です。あれば 入った同じループでエラーが捕まり、無ければ CI 時間・Copilot レビュー往復・人間のトリアージ時間で支払う羽目になります。

📊 証拠: Copilot CLI チームのコードベースは 半分以上がテスト で構成されています。

Advice 6 — モデル選びと Auto モード

ティア選びを間違えると、同じタスクでも 約 24 倍のコスト差 が出ます。typo 修正に Reasoning モデルを使ってしまうのが一番ありがちなムダです。意図的に選ぶ ── または Auto に任せましょう。

Advice 7 — トークナイズは言語中立ではない

同じ意味の文でも、日本語は英語の 約 2〜3 倍のトークン を消費します。copilot-instructions.md・Skill の description・MCP のツール定義・コードコメントなど 常時オン のテキストでは、この差が 毎ループに課税 されます。

🔬 自分で確認: tiktokenizer.vercel.app ↗ や platform.openai.com/tokenizer ↗ に同じ指示文を英日で貼り付け、トークン数を見比べてください。

Advice 8 — エージェントが読める形式で知識を保存する

.xlsx / .docx / .pdf を渡すたびに、エージェントは「パーサを書く → 実行 → 散らかった出力を読み戻す」という 3 ステップの迂回路 に入ります。パース後のテキストは同じ情報の Markdown 版より 3〜10 倍長い ── レイアウト情報がノイズとして混ざるからです。

ナレッジ・仕様書・参照テーブルは Markdown / CSV / プレーンテキスト で保存しましょう。

上級者向け — パワーユーザーのヒント

ここから先は条件付き＆トレードオフあり。上の基本を入れ終えてから手を出す。

• 🖥️ CLI vs MCP — gh / kubectl / npm などの CLI に頼る方が、同等の MCP より軽いことが多い（モデルが既に知っているから）。
• ✂️ シェル出力をトリム — rtk-ai/rtk のようなツールは、よく使う開発コマンドで LLM のトークン消費を 60〜90% 削減 します。
• 📊 /chronicle tip を定期的に — Copilot CLI のセッションを分析し、改善点を具体的に教えてくれる。
• 🔁 ツール呼び出しをまとめる — copilot-codeact-plugin は複数のツール呼び出しを 1 ラウンドトリップに畳む。
• 🎚️ モデル別の細かいチューニング — 可能だがモデルの進化が速いので、超大規模運用のみ価値あり。
• ⌨️ VS Code ターミナルの Ctrl+I — コマンドラインへの単発の質問は、同じ Auto モードでも通常のセッションより 約 10〜30 倍 安い。コンテキストをほとんど読み込まないため、軽い確認に最適。

長期的なマインドセット

• 🧭 分析力を磨く。 開発者の真の価値はコーディングではなく分析力とドメインへの素早い習熟だった。ドメインの言葉でエージェントに正確に指示できる ことが最も価値のあるスキルになる。
• 🏛️ 良いアーキテクチャを適用する。 DDD・ヘキサゴナル・CQRS・Event-Driven ── 境界が明確だとエージェントの空振りが減り、コードを誤った場所に置かなくなる。「5 行関数」議論は重要度を落とし、アーキテクチャの重要度は上がる。
• 🔧 プロンプトと Config を反復する。 あなたはもう Context Engineer。エージェントの空振りはインシデント扱いし、Config を新鮮に保ち、/chronicle でパターンを探る。

今日から始められる 8 つ

1. ✅ 必要以上のコンテキストを渡さない。 インストラクションファイル・スキル・カスタムエージェントを整理し、手書きで書く。
2. ✅ ただし必要な分は必ず渡す。 仕様・例・制約を渡してワンショットで仕留めさせます。
3. ✅ プロンプトを設計する。 目的・出力形式・制約を明示。
4. ✅ Research → Plan → Implement。 3 フェーズをセッションまたはサブエージェントに分け、それぞれ別のコンテキスト・別のモデルで動かします。
5. ✅ 決定的なコントロールを用意する。 テスト・リンター・型チェック・セキュリティスキャンで、入った同じループでエラーを捕まえる。
6. ✅ タスクに合ったモデルを選ぶ ── または Auto に任せる。 Reasoning は計画、Mid は実装、Low は雑務に。
7. ✅ チームが読めるならハーネスは英語で書く。 トークナイザは日本語で 約 2〜3 倍のコスト。
8. ✅ エージェント向けにデータを Markdown で保存する。 バイナリ形式（xlsx・docx・pdf）はパースツール呼び出しで毎回 3〜10 倍のトークンを浪費します。