.NETやAzure・Microsoft製品で学んだことや気づいたことを共有しよう

@tomokusaba(Tomomitsu Kusaba)Team Tea & Waterin

FutureOne株式会社

GitHub Copilot app での無駄トークンは長い記事執筆セッションで増えやすい ─ 30日分のデータから見えた5つの節約術

Posted at 2026-07-06

はじめに

この記事は、GitHub Copilot app 上で /chronicle tips を実行して得られた分析結果をもとにしています。

GitHub Copilot app から日常的に使っていると、 /usage で利用量を見る機会は増えますよね。私もそうでした。ただ、「どれくらい使ったか」は見えても、なぜそこまで増えたのか は意外と分かりにくいです。

そこで今回は、直近 30 日分の利用データを見直し、どの使い方で billable トークン（課金対象トークン）が膨らみやすいのかを整理しました。結論を先に書くと、少なくとも今回のデータでは、重かった主因は「出力が長いこと」よりも、長いセッションの後半で同じ大きな入力コンテキストを何度も送り直していたことにありそうでした。ここが今回のいちばん重要な発見です。🪙

関連記事として、私はこれまで GitHub Copilot app / CLI の使い分けや複数エージェント設計についても書いてきました。今回の記事は、その実践編に近い位置づけです。

本記事は、すでに GitHub Copilot app から日常的に使っていて、これ以上便利さを落とさずに無駄トークンだけ減らしたい方に向けて書きます。単なる節約術ではなく、セッション設計の話として読んでいただけると嬉しいです。✨

今回のゴール

この記事では、次のことを目指します。

✅ 直近 30 日の Copilot 利用データから、何が重かったのかを整理する
✅ 入力コンテキストの再送が主因と見られることを、具体例つきで説明する
✅ /compact、/new、/delegate、/model、.github/copilot-instructions.md などを使い、無駄トークンを減らす実践策を 5 つに絞って示す
✅ /usage は役に立つが、節約はセッション構造の変更で起きることを明確にする

読み終えたときに、読者の方が「次の長い記事執筆や調査タスクでは、どこでセッションを切るか を先に決めよう」と思える状態を目指します。

分析対象と除外範囲

まず、今回見た範囲をはっきりさせます。

項目	今回の扱い	補足
🖥️ GitHub Copilot CLI	対象	課金対象利用の中心だったため
🤖 Copilot Coding Agent	参考扱い	1 セッション、billable トークン 0 で実質ゼロコスト
🔍 Copilot Code Review	除外	レビュー専用ワークロードで、対話型 CLI セッションと混ぜると比較しづらいため
💴 金額換算	しない	プランやモデル条件で変わるため、今回はトークンベースで見る
📎 Attachments	補助確認のみ	重いセッションの主因ではなかった

ここで 1 点だけ補足があります。実際の操作インターフェイスは GitHub Copilot app ですが、今回参照したセッションストアでは agent_name が Copilot CLI として記録されていました。そのため、本記事では操作体験としては app、集計ラベルとしては Copilot CLI という前提で数値を読んでいます。

今回の 30 日分では、課金対象のほぼすべてがセッションストア上の Copilot CLI ラベルに集中していました。225 セッションで、合計は約 195,166,995 トークンです。一方、Copilot Coding Agent は 1 セッションだけで、billable トークンは 0 でした。つまり、このデータセットに限れば、削減対象はほぼ普段使っている app 側セッションの設計そのものです。なお、本記事の数値は 2026-07-06 時点の集計です。

この記事で扱う「コスト」は、正確には金額ではなく billable トークンの無駄です。金額が気になる場面でも、まずはトークンが増える構造を潰す方が再現性のある改善になります。

今回触れる機能の一次情報

本記事で触れる GitHub Copilot CLI の機能は、次の GitHub 公式ドキュメントを前提にしています。

以降の改善案は、これらの機能説明と、今回の実測データの両方を踏まえて書いていきます。

では、最初に全体像を見ていきます。

まず見えた全体像

いちばん目立ったのは、記事執筆ワークフローの比重でした。

分類	セッション数	合計トークン	1 セッション平均
🧱 セッションストア上の Copilot CLI ラベル全体	225	195,166,995	867,409
📝 Fluent UI 関連の記事執筆	18	90,724,709	5,040,262
✍️ その他の記事執筆	22	100,165,318	4,552,969

この 2 行だけで、かなりはっきりしています。記事執筆セッション 40 本だけで、ほぼ 1.9 億トークンを使い切っている 状態です。しかも平均が 450 万〜500 万トークン台なので、短い相談ではなく、長く走り続けたセッションが多かったことが分かります。

モデル別に見ても、重い処理が特定モデルに寄っていました。ここでは、全体の中でも使用量が大きかった主要モデルを並べます。

モデル	合計トークン
🧠 claude-sonnet-4.6	74,783,370
⚙️ gpt-5.4	54,521,783
🛠️ gpt-5.3-codex	42,039,769
🌱 gpt-5.4-mini	9,813,273
✨ gpt-5.5	6,855,152
➕ その他	7,153,648

ただし、ここで大事なのは「どのモデルが悪いか」ではありません。長い文脈を抱えたまま何度も呼ぶと、どのモデルでもトークンは増える という点です。今回はその構造を見ます。

スラッシュコマンドの使い方も象徴的でした。

コマンド	30 日間の利用回数	読み取り
`/usage`	30	かなり使っている
`/new`	1	ほぼ使っていない
`/compact`	0	まったく使っていない
`/delegate`	0	まったく使っていない

つまり、測ることはしているが、切る・圧縮する・分離する行動にはつながっていないわけです。ここが改善余地として非常に大きいと感じました。

なぜ長いセッションほど高くなるのか

今回いちばん強く見えた無駄のパターンは、大きな入力コンテキストの再送 です。

代表的なセッションを並べると、傾向がよく見えます。

セッション	ターン数	課金イベント数	入出力比	観測できた増え方
🧾 Fluent UI 2 Text 記事執筆	9	201	83.8	入力が約 52K → 約 144K まで増加
🔤 Roslyn lexer article	10	147	90.5	前半平均 48,449 → 後半平均 69,940（+21,491）
🦴 Fluent UI 2 Skeleton 記事	6	99	84.6	前半平均 59,377 → 後半平均 98,587（+39,210）
✏️ Fluent UI 2 Textarea	-	-	-	-

特に Fluent UI 2 Textarea では、後半の 1 イベントあたり平均入力が 44,221 増えていました。後半を約 43 イベントとして単純試算すると、約 190 万入力トークン です。つまり、後半の会話で何か劇的に新しいことをしたというより、前半で積み上がった文脈を抱えたまま、同じような操作を繰り返していた可能性が高いわけです。

構造を図にすると、次のイメージです。

この図のポイントは、後ろのターンほど「今回の依頼」より「過去の履歴の同伴コスト」が大きくなることです。だから節約したいなら、セッションを切る / 圧縮する / 分離する 方が効きます。

では、ここから実践策を 5 つに絞って見ていきます。

Tip 1: まずオーケストレータの責務を軽くし、詳細ルールは skill / instructions 側へ逃がす

これは agent / skill 設計改善策です。今回のケースでは、ここがいちばん上流にある改善ポイントでした。

観測された原因

同じ執筆スタイルやワークフロー説明が、セッションごとに何度も再注入されていました。これは 1 回ごとの差は小さく見えても、積み上がると確実に効きます。

しかも今回は、単に「利用者が長い指示を書いてしまった」だけではありません。実際にこのリポジトリの zenn-article-orchestrator は、執筆 → 並列レビュー → 指摘統合 → 一括反映 → 完成判定までを回し、公開可能品質まで仕上げる設計になっています。つまり、記事を最後まで仕上げる前提の長い固定ルール が agent 側に集まりやすく、ここが太いままだと、利用者の工夫だけではコストを下げきれません。

根拠データ

write-qiita-article: 35 回、合計約 289,368 文字、平均約 8,268 文字
qiita-cli-workflow: 35 回、合計約 106,382 文字、平均約 3,039 文字
合計すると約 395,750 文字
現在のリポジトリには .github/agents と .agents/skills/ はあるが、.github/copilot-instructions.md はない
実際の zenn-article-orchestrator は、レビューラウンドと完成判定まで含めて記事を仕上げる統合エージェントとして定義されている

つまり今回の論点は、「skills がないから毎回長くなる」ではありません。skills はすでにあるのに、それでも orchestrator 側が仕上げまで抱え込みやすい ところにあります。

文字数をかなり粗い目安として 4 文字 = 1 トークンと仮置きしても、再注入ぶんだけで約 9.9 万トークン相当です。日本語では厳密換算ではありませんが、少なくとも「繰り返し貼っている前提が無視できない量になっている」ことは分かります。

改善前 / 改善後

状態	改善前	改善後
🎛️ オーケストレータ設計	skills があっても、エージェントが仕上げまで抱え込み、長い固定ルールを毎回前提にしやすい	agent は役割分担と流れだけを持ち、詳細ルールは既存 skills / instructions にできるだけ逃がす
📚 共有ルール	毎回プロンプトに長く貼る	`.github/copilot-instructions.md` に常設
🧩 再利用手順	skill があっても orchestrator 側に詳細ルールを重ね持ちしやすい	既存の `.agents/skills/` を活かし、agent 側の重複ルールを減らす
🚀 初回整備	セッションごとに都度説明	`copilot init` などの初期導線のあと、リポジトリ側に固定

このリポジトリのように .github/agents と .agents/skills/ がすでにあるなら、次の一歩は skill を新設することより、既存 skill と agent の責務分割を整理すること だと思います。

特に今回のような orchestrator 型では、改善対象は 3 層あります。

利用者のプロンプト: 毎回書いている長い背景説明を減らす
スキル: 既存の .agents/skills/ にある記事構成・フロントマター・リンク規約・レビュー観点を再利用し、重複を増やさない
エージェント定義: orchestrator 自体には「誰に何を委譲するか」「どこで収束判定するか」だけを残し、skill にある詳細な執筆規約はできるだけ再記述しない

要するに、人の使い方だけでなく、agent / skill の責務分割そのものを見直すのが本筋です。

具体的にどのルールを直すべきか

今回の定義を見る限り、特に見直し効果が大きいのは次のルールです。

ルール	今の置き場所	直し方
📝 フロントマター 5 項目（`title` / `emoji` / `type` / `topics` / `published: false`）	orchestrator の最終チェック / `write-zenn-article` skill の両方	skill 側を正本にして、orchestrator からは詳細列挙を外し「frontmatter は skill と既存 repo 規約に従う」に短縮する
🔢 14 桁 16 進スラッグと `npx zenn new:article`	orchestrator の Step 2 / `write-zenn-article` skill の両方	writer / skill 側の責務に寄せる。orchestrator は「writer が採番・生成する」とだけ持つ
🚫 `published: false` を維持する	orchestrator / skill の両方	repo-wide instruction か skill 側へ統一し、orchestrator では公開判定フローだけを持つ
🔗 Microsoft Learn 系リンクに `WT.mc_id=DT-MVP-5004827` を付ける	orchestrator 最終チェック / `write-zenn-article` skill の両方	skill または `.github/copilot-instructions.md` 側へ寄せる。orchestrator に細かい URL ルールを持たせない
🧱 記事の章立て・文体・絵文字運用	`write-zenn-article` skill に詳述済み。必要に応じて agent 側でも参照しやすい	skill のみで管理し、orchestrator では再記述しない
✅ 全コードブロックに言語名 / alt テキスト / TODO なし	orchestrator 最終チェック / skill にも事実上近いルールがある	機械的な最終検査だけ orchestrator、意味や理由の説明は skill 側に寄せる
🔄 レビューは read-only で並列、統合後に一括反映	orchestrator 固有	これは orchestrator に残すべき中核ルール。他へ逃がさない
📏 収束条件・最大ラウンド数・差し戻し条件	orchestrator 固有	これも orchestrator に残すべき中核ルール。品質ゲートなので agent 側で持つ

この整理で見ると、orchestrator に残すべきなのはフロー制御と品質ゲートです。逆に、書き方の規約、リンク規約、frontmatter 規約、Zenn 記事としての体裁ルールは skill 側の方が自然です。

言い換えると、zenn-article-orchestrator で本当に重いのは「レビューを並列で回すこと」そのものではなく、フロー制御に加えて執筆規約まで抱え込みやすいこと です。ここを切り分けるだけでも、エージェント定義の肥大化を抑えやすくなります。

推定できる効果

今回の観測範囲だけでも、少なくとも約 10 万入力トークン相当 は削減余地がありました。これは「同じ前提を会話に毎回流し込んでいる」ぶんだけの保守的な見積もりです。オーケストレータやスキル定義側まで整理できれば、反復ワークフロー全体ではこれより大きい効果も期待できます。

いつ使うか

毎回ほぼ同じ文体指示や出力形式を貼っているとき
チームや個人で「このリポジトリではこう振る舞ってほしい」が決まっているとき
複数セッション / 複数記事で同じ作法を繰り返しているとき
オーケストレータエージェントが毎回「仕上げまで」抱え込む設計になっているとき

長い system prompt 的な説明を毎回会話で送るより、リポジトリに寄せて再利用可能にする方がトークン的にも運用的にもきれいです。さらに、orchestrator 型の agent なら、既存の .agents/skills/ を活かしつつ、agent 本体の重複ルールを減らすところまでやると、改善の筋が通ります。

Tip 2: orchestrator の実行が返ってきた節目で `/compact` を使う

これはセッション圧縮策です。Tip 1 で上流の設計を軽くしたうえで、運用中の肥大化を抑える役目です。

観測された原因

記事の構成や前提が固まったあとも、同じセッションで本文追加・比較・言い換え・要約を続けると、固定済みの文脈まで毎回再送 されやすくなります。

根拠データ

/compact の利用回数は 30 日で 0 回
Roslyn lexer article では後半平均入力が +21,491
Fluent UI 2 Skeleton 記事 では +39,210
Fluent UI 2 Textarea では +44,221、後半だけで約 190 万入力トークンの上振れ

改善前 / 改善後

状態	改善前	改善後
🧠 会話の持ち方	調査 → 構成 → 初稿 → 修正を 1 本で続ける	orchestrator がいったん返ってきた節目で `/compact`
📦 保持する情報	過去のツール出力や言い換え履歴も抱え続ける	要点だけ要約した状態で後半へ進む
✍️ 次の依頼	「前の流れを踏まえて続けて」	「ここまでの決定事項はこれ。次は第 3 節だけ書いて」

具体的にどう運用するか

ここで前提にしたいのは、素の対話で記事を書くケースではなく、zenn-article-orchestrator で執筆 → レビューラウンド → 収束判定を回すケースです。その前提だと、Copilot が動いている最中に /compact を差し込むのは現実にはやりにくいです。なので、Tip 2 で言いたいのは「実行中に割り込む」ことではなく、orchestrator がいったん応答を返した節目で、次の再開前に会話を薄くする ことです。

/compact は「長くなったら何となく押す」より、再開前の節目でルール化して押す方が効きます。私なら次の 4 手順で運用します。

止めどころを決める
orchestrator なら「Step 1 の要件整理が終わって agent が返ってきた」「Step 2 の初稿が出て agent が返ってきた」「レビュー 1 ラウンド分を統合し終えて agent が返ってきた」のように、いったん制御が手元へ戻った時点で止めます。
決定事項だけを 3〜6 行に圧縮する
会話の経緯ではなく、現在のドラフト状態と次ラウンドの入力に必要な事実だけを書きます。
未解決論点を 0〜2 件だけ残す
未解決が多いまま /compact すると、次ラウンド開始時に背景説明をやり直しやすくなります。
compact 後の最初の依頼を 1 タスクに固定する
「続きを全部」ではなく、「次は Step 3 のレビューラウンドへ進めてください」「この指摘だけ反映してください」のように、orchestrator の次の 1 ステップに固定します。実行中に割り込むのではなく、次の起動入力を短くするイメージです。

どのタイミングで入れるか

タイミング	`/compact` 前に残すべきこと	compact 後の最初の依頼
🧭 Step 1 要件整理の直後	読者、記事タイプ、扱う範囲、完成判定の厳しさ	「この条件で Step 2 の初稿作成へ進めてください」
✍️ Step 2 初稿作成の直後	生成された記事ファイル、初稿の主張、残る不安点	「このドラフトを対象に Step 3〜5 のレビューラウンドへ進めてください」
🔄 1 ラウンド分の統合反映直後	今のドラフト状態、解消済み項目、残ブロッカー、次ラウンドで見る点	「同じドラフトの新スナップショットで次ラウンドへ進めてください」
✅ Step 6 最終チェックの直前	残りの機械的確認項目、公開しない条件、残 TODO の有無	「最終チェックだけ実施してください」

「実行中に差し込む」のではなく「返ってきた後に入れる」

ここは誤解しやすいポイントです。orchestrator が 1 回の流れを走っている最中に、利用者が横から /compact を差し込んで流れをねじ込む、という運用はあまり現実的ではありません。

むしろ実務上は、次のように考える方が自然です。

orchestrator が Step 1 まで終えて返ってくる
その節目で必要なら /compact する
要約済みの短い入力で Step 2 を再開する

つまり Tip 2 は、節目ごとの再起動コストを下げる策と読むのが正確です。

orchestrator 前提でのポイント

orchestrator は同じドラフトのスナップショットを固定して、3 本の read-only レビューを並列で走らせ、最後に一括反映します。つまり、/compact で残すべきなのは「会話履歴」ではなく、現在のドラフト状態 です。

特に残す価値が高いのは次の 5 点です。

現在のファイルパス
どの articles/<slug>.md を対象にしているか。
直前ラウンドで反映済みの修正
何をもう直したか。
未解決の指摘
❌ / ⚠️ / 構成ブロッカーなど、次ラウンドに持ち越すもの。
次に進むステップ
Step 3〜5 を回すのか、Step 6 に入るのか。
公開しない前提
published: false の維持や、未収束なら完成扱いにしないこと。

`/compact` に入れる要約の型

実際には、次の型で十分です。

/compact
ここまでの決定事項:
- 対象ファイルは articles/afdc7b2f8597cb.md
- Step 2 の初稿は作成済み
- Tip 1 は orchestrator と skill の責務分割を主題にする
- Tip 2 は orchestrator 運用での /compact の入れどころを説明する

未解決:
- レビューラウンド後に compact を入れる説明をどこまで具体化するか
- Step 6 直前の compact 例を入れるかどうか

次にやること:
- このドラフトを対象に、Tip 2 の「orchestrator 前提の運用手順」だけ追記する

ポイントは、経緯ではなく再開条件を書くことです。「こう考えてここに至った」は捨てて、「次のターンで必要な前提だけ残す」に寄せた方が短くなります。

compact 後の最初の依頼も短くする

/compact のあとに、すぐまた長文で背景を貼り直すと効果が薄れます。なので、compact 後の最初の依頼も短く保つ必要があります。

状態	改善前	改善後
🗣️ compact 後の依頼	「前の流れを踏まえて、Tip 2 をもっと詳しく、他の Tips との整合も見ながら、適宜表現も直して……」	「上の要約を前提に、Step 2 完了後の compact 運用だけ追記してください」
🎯 依頼の粒度	複数タスクをまとめる	1 タスクだけに絞る
📉 再送される文脈	また広がりやすい	最小限に抑えやすい

推定できる効果

今回の観測から単純試算すると、Textarea は約 190 万入力トークン、Skeleton は後半約 50 イベント × 39,210 で約 196 万入力トークン、Roslyn は後半約 73 イベント × 21,491 で約 157 万入力トークンの差分が出ます。したがって、6〜10 ターン級の長い記事執筆セッション 1 本あたり 150 万〜200 万入力トークン程度 は削減余地がありそうです。

逆に `/compact` しない方がよい場面

まだ記事の主張そのものが固まっていないとき
比較する案が 2〜3 本残っていて、どれを採るか未決定なとき
いままさに一次情報を集めていて、参照元をまとめきれていないとき
同一ラウンドの fact-check / proofread / flow-review がまだ出そろっていないとき
レビュー結果を統合する前で、何を採用して何を捨てるか未確定なとき

この段階で /compact すると、あとで「何を捨ててよくて、何を残すべきか」が曖昧なまま圧縮してしまい、かえって説明のやり直しが増えます。orchestrator 前提で言うと、/compact は同一ラウンドの途中に差し込むものではなく、Step 完了後かラウンド統合後に agent が返ってきたタイミング で置く方が向いています。

いつ使うか

Step 1 の要件整理が終わり、Step 2 へ進むだけになったとき
Step 2 の初稿ができて、次はレビューラウンドへ進むだけになったとき
1 ラウンドぶんのレビュー結果を統合反映し、次ラウンドの新スナップショットへ切り替えるとき
/usage を見て「このまま同じ会話を延ばすより、一度圧縮した方がよい」と判断したとき
Step 6 の最終チェックだけが残っているとき

/compact は、ラウンド境界の再開前圧縮ポイントとして使うのがよさそうです。

Tip 3: 調査・構成・執筆・仕上げを `/new` で分ける

これはフェーズ分離策です。

観測された原因

長い記事執筆セッションでは、別フェーズの情報を同じ会話に混ぜていた ことが重さにつながっていました。調査のログ、比較の試行錯誤、本文の草案、校正メモが 1 本に乗ると、後半の入力が膨らみやすくなります。

根拠データ

Fluent UI 関連記事執筆は 18 セッションで 90,724,709 トークン
その他の記事執筆は 22 セッションで 100,165,318 トークン
平均すると 1 セッション 450 万〜500 万トークン台
/new は 30 日で 1 回だけ

改善前 / 改善後

フェーズ設計	改善前	改善後
🔎 調査	本文と同じセッションで継続	調査専用セッションで結論だけ作る
🧱 構成	調査ログを抱えたまま章立て	`/new` で章立て専用セッションを開始
✍️ 執筆	構成議論や比較ログを引きずる	`/new` で初稿執筆セッションを開始
🎯 仕上げ	初稿の迷走履歴も残る	`/new` で最終整形だけに集中

追加で、フェーズを切ると /model も選びやすくなります。たとえば、調査後の章立て整理や表現の軽い整形では、毎回同じ重いモデルを使い続ける必要はありません。セッションを分けることが、モデル選択をしやすくする前提になります。

推定できる効果

今回の観測では、後半に入ってから 1 イベントあたり 2 万〜4 万入力トークンずつ余計に膨らんでいる例が見えました。後半フェーズを 40〜50 イベントぶん新しいセッションに逃がせるなら、1 記事あたり 100 万入力トークン前後、重いケースでは 150 万入力トークン超の削減余地があります。

いつ使うか

調査メモがそろい、「何を書くか」は決まったとき
章立てが決まり、「あとは本文」になったとき
本文ができて、「あとは表と締めだけ」になったとき

長いセッションを我慢して延命するより、フェーズ境界で気持ちよく切る 方がトークン的にはかなり有利です。

Tip 4: 横道にそれる調査は `/delegate` か別セッションに逃がす

これは調査文脈の隔離策です。

観測された原因

重いセッションでは、本文執筆と並行して横道の調査やシェル的な探索も多く走っていました。これがメインの会話に残ると、あとから本文を 1 段落書くだけでも、調査ログ全体を背負いやすくなります。

根拠データ

/delegate の利用回数は 0 回
Fluent UI 2 Text 記事執筆: shell-like 36 回 vs built-in read 66 回
Textarea: shell-like 30 回 vs built-in read 20 回
Roslyn lexer article: shell-like 27 回 vs built-in read 77 回
重いセッションは attachments 主体ではなかった

つまり、ファイル添付よりも、会話の中で生まれた探索ログとその再送 の方が効いていたと見た方が自然です。

改善前 / 改善後

状態	改善前	改善後
🔍 調査	本文セッションの中で、そのまま追加調査	`/delegate` か別セッションに切り出す
🧾 結果の持ち帰り	生ログや長文出力をメインに残す	要点 3〜5 行の要約だけ戻す
🛠️ ツール選択	広めの shell 出力を何度も貼る	可能なら built-in read/search を優先する

/delegate
Fluent 2 Textarea の仕様差分だけ調べてください。
最終的にメインの会話へは、見出し候補 3 つと要点 5 行だけ返してください。

推定できる効果

横道の調査を 10〜15 イベント分だけメインの会話から隔離できるだけでも、後半の入力膨張を抑えられます。1 イベントあたりの余剰入力を 2 万〜4 万トークンと置くと、20 万〜60 万入力トークン程度 / 長いセッションの削減余地があります。

いつ使うか

本文を書いている途中で、仕様確認のための別調査が発生したとき
grep / shell / ログ確認が増えてきたとき
「この調査結果は 3 行あれば十分」と分かっているとき

調査そのものを減らす必要はありません。調査の文脈をメインの記事執筆セッションに持ち込まないのがコツです。

Tip 5: `/usage` は診断、節約は `/compact` と `/new` の判断で起こる

これはチェックポイント運用策です。

観測された原因

今回は /usage 自体は使われていました。しかし、見たあとにセッション構造を変えていないため、利用量の把握が「事後確認」で止まっていたように見えます。

根拠データ

/usage: 30 回
/compact: 0 回
/new: 1 回
/delegate: 0 回

つまり、メーターは見ているのに、ブレーキやルート変更にはつながっていませんでした。

改善前 / 改善後

状態	改善前	改善後
📊 `/usage` の役割	使いすぎた後の確認	フェーズ終端のチェックポイント
🧭 次の行動	数字を見てそのまま続行	`/compact` するか、`/new` するかを決め、必要なら `/model` も見直す
🪙 効果	利用量を確認するだけでは節約にならない	構造変更の判断につなげると節約効果が出る

おすすめは、/usage を 5〜10 turn ごとに打つことではありません。そうではなく、章立て完了・表完成・初稿完了のようなフェーズ終端で確認し、次のアクションを決めることです。

/usage
# 確認後の判断
- このまま本文追加だけなら /compact
- フェーズが変わるなら /new
- 次は軽い整形だけなら /model も見直す

推定できる効果

/usage 単体のトークン削減効果は 0 です。ただし、これをチェックポイントにして /compact や /new に切り替えられれば、100 万〜200 万入力トークン級の上振れ を防げる可能性があります。/model は、その切り替え後に「次のフェーズに重いモデルが本当に必要か」を見直す補助策として使うのが自然です。

いつ使うか

見出しが固まったとき
大きな表や比較表を作り終えたとき
次が「本文生成」ではなく「整形・修正」になるとき

/usage は大切です。ただし、本当に効くのは数字を見たあとにセッションをどう切るかです。

すぐ使えるチェックリスト

最後に、次の長い GitHub Copilot app セッションからすぐ使える形でまとめます。

まずはオーケストレータエージェントが仕上げまで抱え込みすぎていないかを見直す
リポジトリ固有ルールは .github/copilot-instructions.md に寄せる
既存の .agents/skills/ と agent 定義でルールが二重化していないか見直す
次に、orchestrator が節目で返ってきたら、次の再開前に /compact が必要か判断する
調査・構成・執筆・仕上げを 1 本でやらず、フェーズ境界で /new を検討する
横道の調査は /delegate や別セッションに逃がし、メインには要点だけ戻す
/usage は「反省会」ではなく「次の分岐点」のために使う
フェーズが軽くなったら /model で過剰な構成を見直す

まとめ

今回の 30 日分のデータでは、課金対象のほぼすべてがセッションストア上の Copilot CLI ラベルに集中していました。そして、重かった主因は単純に長文を出させたことではなく、長い記事執筆セッションの後半で、大きな入力コンテキストを何度も送り直していたこと にありそうでした。

言い換えると、節約の本丸は プロンプトの言い回しではなくセッション設計 です。

仕上げまで自動で抱え込む orchestrator 型なら、まず agent / skill の責務分割を見直す
毎回貼る前提は .github/copilot-instructions.md や既存の .agents/skills/ へ
orchestrator が返ってきた節目で、必要なら /compact
フェーズが変わったら /new
横道は /delegate
/usage は見るだけで終わらせず、次の構造変更に使う

この 5 つだけでも、長い記事執筆セッションの無駄はかなり減らせるはずです。私自身、今後は「どのモデルを使うか」より先に、どこでセッションを切るか を意識して使っていこうと思います。まずは次の 1 本の記事執筆から、試してみてください。🚀

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

GitHub Copilot app での無駄トークンは長い記事執筆セッションで増えやすい ─ 30日分のデータから見えた5つの節約術

はじめに

今回のゴール

分析対象と除外範囲

今回触れる機能の一次情報

まず見えた全体像

なぜ長いセッションほど高くなるのか

Tip 1: まずオーケストレータの責務を軽くし、詳細ルールは skill / instructions 側へ逃がす

観測された原因

根拠データ

改善前 / 改善後

具体的にどのルールを直すべきか

推定できる効果

いつ使うか

Tip 2: orchestrator の実行が返ってきた節目で /compact を使う

観測された原因

根拠データ

改善前 / 改善後

具体的にどう運用するか

どのタイミングで入れるか

「実行中に差し込む」のではなく「返ってきた後に入れる」

orchestrator 前提でのポイント

/compact に入れる要約の型

compact 後の最初の依頼も短くする

推定できる効果

逆に /compact しない方がよい場面

いつ使うか

Tip 3: 調査・構成・執筆・仕上げを /new で分ける

観測された原因

根拠データ

改善前 / 改善後

推定できる効果

いつ使うか

Tip 4: 横道にそれる調査は /delegate か別セッションに逃がす

観測された原因

根拠データ

改善前 / 改善後

推定できる効果

いつ使うか

Tip 5: /usage は診断、節約は /compact と /new の判断で起こる

観測された原因

根拠データ

改善前 / 改善後

推定できる効果

いつ使うか

すぐ使えるチェックリスト

まとめ

参考リンク

Tip 2: orchestrator の実行が返ってきた節目で `/compact` を使う

`/compact` に入れる要約の型

逆に `/compact` しない方がよい場面

Tip 3: 調査・構成・執筆・仕上げを `/new` で分ける

Tip 4: 横道にそれる調査は `/delegate` か別セッションに逃がす

Tip 5: `/usage` は診断、節約は `/compact` と `/new` の判断で起こる