Claude Codeトークンコスト最適化 実践編 — Copilot CLI委譲と/commitsスキルの多段フォールバック戦略

概要

前回の記事では、Claude Codeのトークンコストについて、/clearによるコンテキスト切断やagent teamsによるコンテキスト分離がどう効くかという理論的な話をした。今回はその続きで、実際にトークン節約をどう実装するかという実践編。

GitHub Copilot CLIの無料モデル（GPT-4.1）にcommit/push作業を委譲するシェル関数を作り、最終的には/commitsスキル内部に多段フォールバックを組み込むところまで到達した会話の記録。

me:

Here’s another idea:

By this info, github copilot is free for low cost model. but for just for /commits pull push like simple task, we can use it almost as free.

/Users/takazudo/repos/w/zpaper/doc/src/content/docs/articles/20260414-1633-github-copilot-cli-as-claude-code-subagent.md

Let’s say we’ll define that alias on ~/.zshrc as

• gcommits: let copilot do commits (by handling gitignore-awared files like /commits)
• gpush: let copilot do push
• gsync: let copilot do gcommits, git pull, git push

with -p prompt, can we reduce the token on

me: implement something big, /commits push

this pattern? It’s like…

me: implement something big, then just run gsync

I think with this, LLM does not separate this as subsequential tasks. maybe?

Claude Code:

Your idea works because offloading work to an external process (Copilot CLI) avoids adding tool call results to Claude Code’s context. It’s not about the LLM understanding task boundaries differently — it’s about the work happening outside Claude Code’s conversation loop entirely.

With /commits push, Claude Code runs 5+ tool calls (git status, diff, log, add, commit, push), each re-sending the full context. With gsync, it’s one Bash command — Copilot does the git analysis in its own process.

Token comparison:

This is the same principle as agent teams, but lighter weight: you’re using a cheap external tool instead of Claude Code’s expensive multi-step workflow.

gcom と gpush のシェル関数を ~/.zshrc に作り、copilot CLI を --model gpt-4.1 --no-ask-user --allow-all-tools で呼び出す構成にした。Copilotが失敗した場合は基本的なgit操作にフォールバックするようにもした。併せて4つのスキルから /commits の参照を gcom/gpush に置き換えた。

me:

I got error on gpush. need to add more permission on copilot. is it possible by args?

✗ Edit .gitignore
  └ Permission to run this tool was denied due the following rules: `write`

Claude Code:

The issue is --deny-tool='write' blocks Copilot from editing .gitignore, which is part of the commit workflow. Removed that restriction from both gcom and gpush.

commit作業の中で .gitignore の編集が必要になるケースがあり、--deny-tool='write' がそれをブロックしていた。/gco や /gco-review のような読み取り専用のスキルでは --deny-tool='write' が適切だが、commit/push を行うスキルでは書き込み権限が必要になる。用途に応じた権限設定が必要ということ。

me:

Good. as the summary. If I ask you /commits push in the workflow, even if it is a tiny tasks, it becomes like chained action collection, so the whole token raises on by one.

But here’s another question. We’ve just now delegated this to copilot. so it’s like this: “Ah, I don’t know the detail around here, but do the commits, pull, push by your decision please”.

I can understand this reduces the cost, but as the result. I think the Claude Code will read the stdout of copilot at least. But even if such cases, what Claude Code does is only “read the result by stdout from copilot”. so is this still effective?

I also thought this case. How about using do commits + pull + push work using Haiku subagent? it’s also the same thing, so this is effective too?

In our current strategy, we replaced /commits and push related actions to gcom and gpush. So if this haiku subagent way is effective. How about this?

• we use /commits still
• but inside, first call gcom
• if failed, raise Haiku subagent and let them do commits work

Claude Code:

Yes, both approaches work for the same reason — context isolation. The savings come from fewer round-trips, not from reading less data.

Your proposed layered fallback is smart:

/commits (modified):
  1. Try gcom (Copilot, FREE)
  2. If failed → spawn Haiku subagent (cheap)
  3. Never do the expensive multi-step workflow in Opus context

This keeps /commits as the single interface while the implementation is cost-optimized underneath. No need to rename anything — skills still say /commits.

me:

all right do that.

ということで、/commits スキルの内部に多段フォールバックを実装した。

1. まず gcom/gpush（Copilot CLI、無料）を試す
2. 失敗したらHaikuサブエージェントを起動して委譲する（安い）
3. 直接的なマルチステップワークフローは最後の手段

先に4つのスキルで /commits への参照を gcom/gpush に書き換えていたが、これを元に戻した。/commits の中身が最適化されたので、スキル側は何も変える必要がなくなった。

この会話で起きたこと

アプローチが段階的に進化した流れをまとめると以下のようになる。

1. Copilot CLIに委譲するシェル関数を作って、スキルから /commits の参照を置き換え
2. --deny-tool='write' がcommitワークフローをブロックする問題を修正
3. stdoutを読む分のコストがあっても、ラウンドトリップが1回で済む分十分に安いという確認
4. Haikuサブエージェントでも同じコンテキスト分離効果が得られるという発見
5. 「あちこちの参照を書き換える」のではなく、/commits 内部を最適化するという設計判断
6. 多段フォールバック: Copilot CLI（無料） → Haiku（安い） → 直接実行（最後の手段）

最終的に、各スキルは今まで通り /commits を呼ぶだけ。最適化はインターフェースの裏側で行われている。

余談

前回の記事で「あなたがコンテキストマネージャー」という結論に至ったが、今回は「じゃあ自動化しよう」という流れになった。/clear は手動のコンテキスト管理で、Copilot CLI委譲やHaikuサブエージェントは自動的なコンテキスト分離。前回が理論編で、今回が実践編という位置づけになる。