トークン消費量も実装の手戻りも最小限にする GitHub Copilot を利用した開発フロー
2026 年 6 月 1 日より、GitHub Copilot の課金方式が大きく変わります。
これまでの「プレミアムリクエスト」数による管理から、トークン消費量ベースの「GitHub AI Credits」制へ移行します。
注意すべきは Output トークン(Copilot が生成する文書)の単価が Input の 5 倍という点です。大量のコードを生成させるほど、コストが膨らむ構造になっています。
本記事では、トークン消費を抑えながら手戻りを減らして開発を進めるフローを紹介します。
なぜ「Agent に丸投げ」はコスパが悪いのか
GitHub Copilot の Agent モードは非常に便利です。指示を出せば自律的にコードを書き、ファイルを編集し、エラーがあれば自分で修正を試みます。
しかし、意図と違う実装をされてしまったときに問題が生じます。
- 手戻りで再実装 → Output トークンが 2 倍消費
- 修正指示のやり取り → Input・Output ともに消費
- コンテキストが膨らむほど次のリクエストのコストも高くなる
私自身、Agent モードだけに頼っていた結果、月半ばでプレミアムリクエストが上限に達してしまいました。
また、GitHub 自身も公式ブログで「プランモードを使用してタスクの効率を高める。プランモードはタスクの成功率も向上します」と明言しています。
プランモード（VS Code、GitHub Copilot CLI）を使用してタスクの効率を高める。プランモードはタスクの成功率も向上します。
つまり、いきなり Agent に実装させるのではなく、まず計画を合意してから動かすことが、品質とコスト両面で推奨されます。
効率的な開発フロー
全体像
① /init で .github/copilot-instructions.md を自動生成する
② Plan モードでタスクを設計・合意する
③ Agent モードで実装する（手戻りは /undo で即リカバリー）
④ /review で品質確認する
⑤ /context でトークン使用量を確認する
⑥ /compact・/clear でコンテキストを管理する
※ 作業中のちょっとした調べものは /ask でコンテキストを消費せずに行う
① /init で .github/copilot-instructions.md を自動生成する
プロジェクトルートに .github/copilot-instructions.md を置くと、Copilot が常にその内容を参照します。手動で書いてもよいですが、まず /init を実行するのがおすすめです。
/init
Copilot がリポジトリのディレクトリ構造・使用言語・フレームワークを自動解析し、.github/copilot-instructions.md を生成・更新してくれます。既存ファイルがある場合は差分で追記してくれるので、プロジェクト構成が変わったときの更新にも使えます。下記は例です。
## プロジェクト概要
このリポジトリは社内向けの勤怠管理システムです。AWS CDK で構築されたサーバーレスバックエンドで、DynamoDB をデータストアとして使用しています。
## 技術スタック
- **Backend**: TypeScript + AWS Lambda + API Gateway
- **Infrastructure**: AWS CDK (TypeScript)
- **DB**: DynamoDB (NoSQL)
- **メール送信**: AWS SES
- **スケジュール実行**: EventBridge
- **Node.js**: バージョン 22
## コーディング規約
- 変数名・関数名は **camelCase** を使用してください
- コンポーネント・クラスは **PascalCase** で命名してください
- インデントは **スペース 2 つ**です
- **セミコロンは省略しない**でください
- マジックナンバーは定数として定義してください
- コメントは**日本語**で書いてください
## アーキテクチャパターン
### レイヤード構造
バックエンドはレイヤードアーキテクチャを採用しています：
- **handler/**: AWS Lambda イベント（API Gateway）を受け取り、サービス層を呼び出し、HTTP レスポンスを返却
- **service/**: ビジネスロジック実装（データ変換、バリデーション、複合処理）
- **database/**: DynamoDB とのデータアクセス（クエリ、更新）
- **router/**: API ルート定義（HTTP メソッド、パス、対応するハンドラーのマッピング）
② Plan モードでタスクを設計・合意する
VSCode で Copilot Chat または Copilot CLI のモードを Plan に切り替えます。
Plan モードでは Copilot はコードを書かず、作業計画の提案と相談だけを行います。
# Plan モードでの進め方
1. タスクを日本語で伝える
「ユーザー一覧ページにページネーションを追加したい」
2. Copilot が作業計画を提示する
「以下のファイルを変更します：
- src/components/UserList.tsx
- src/hooks/usePagination.ts（新規作成）
- src/app/users/page.tsx」
3. 合意できたら Agent モードに切り替える
この段階でズレを発見できれば、Output トークンを無駄に消費せずに方向修正できます。
/new でコンテキストをリセットしてから始めるのもおすすめです。不要な会話履歴がコンテキストに残らず、トークン消費を抑えられます。
③ Agent モードで実装する
計画に合意できたら、Agent モードに切り替えて実装を依頼します。
このとき、タスクを小さく分割して渡すことが重要です。
# 良い例（小さく分割）
「usePagination.ts を作成してください。
仕様は Plan で確認した通りです」
# 悪い例（大きすぎる）
「ユーザー管理機能を全部作ってください」
大きなタスクを一度に渡すと、Agent が複数ファイルを同時に処理するため、コンテキストウィンドウの使用量が増加する傾向があります。/context コマンドで確認できるように、ファイル数が増えるほど System/Tools の消費量が増えます。
タスクは小さく渡すことでトークン消費を分散できます。
意図と違う実装をされた場合は、/undo で直前のファイル変更を元に戻せます。修正指示を重ねてトークンを消費するよりも、/undo でリセットして指示を出し直す方が効率的です。
/undo
また、モデルの使い分けも有効です。私は以下のように使い分けています。
| 用途 | モデル |
|---|---|
| 複雑なアーキテクチャ設計・難しいバグ修正 | Claude Sonnet 4.6 / Claude Opus 4.6 |
| 単純な実装 | Claude Haiku 4.5 |
| コード補完（無制限・クレジット不要） | 自動選択 |
④ /review で品質確認する
実装が終わったら、すぐにマージせず Copilot に /review で確認させます。
レビューには少々時間がかかります。ある程度まとめてからレビューさせると効率的です。
また、/review [prompt] のようにプロンプトを添えると、レビューの観点を指定できます。
/review セキュリティの問題がないか重点的にチェックして
/review パフォーマンスに影響がある変更がないか確認して
/review エラーハンドリングが適切か見て
⑤ /context でトークン使用量を確認する
/context を実行すると、現在のコンテキストウィンドウの使用状況をビジュアルで確認できます。
Context Usage
claude-haiku-4.5 · 20k/168k tokens (12%)
○ System/Tools: 19.5k (12%)
● Messages: 0 (0%)
· Free Space: 109.7k (65%)
⊙ Buffer: 38.8k (23%)
このように使用中のモデル・総トークン数・内訳が一目でわかります。コンテキストが膨らんでいる状態で実装を依頼すると、その分だけ Input トークンのコストが上がります。実装を依頼する前に /context で状況を把握し、膨らんでいれば /compact で圧縮してから進めることをお勧めします。
⑥ /compact と /clear でコンテキストを管理する
長いセッションを続けると、コンテキストがどんどん膨らみます。コンテキストが大きいほど次のリクエストの Input トークンも増えるため、定期的に整理が必要です。
| コマンド | 用途 |
|---|---|
/compact |
会話を要約してコンテキストを圧縮する |
/clear |
コンテキストを完全にリセットする |
/new |
新しいセッションを開始する |
目安として、1 つのタスクが終わったら /clear または /new でリセットするのがおすすめです。次のタスクに前のタスクの情報は不要なことがほとんどです。
おまけ /ask でコンテキストを汚さずに調べ物をする
作業中に「この関数の引数ってなんだっけ？」とちょっとした確認をしたいことはよくあります。しかし通常のチャットで質問すると会話履歴に残り、コンテキストを消費してしまいます。
そんなときは /ask（experimental） が便利です。質問と回答が会話履歴に追加されないため、コンテキストを消費せずに調べ物をすることができます。
# experimental モードを有効化（初回のみ。試験中のスラッシュコマンドのため有効化が必要です）
/experimental on
# 会話履歴に残さずに質問
/ask Array.prototype.reduce の引数を教えて
まとめ
6 月 1 日からの従量課金制により、手戻りを減らす工夫がそのままコスト削減にもつながるようになります。
/initでプロジェクトの土台を自動生成する- Agent に丸投げせず、Plan モードで合意してから実装
- タスクは小さく分割して渡し、手戻りは
/undoで即リセット /contextでトークン使用量を把握してから実装依頼する- コンテキストを定期的にリセットする
- 調べ物は
/askでコンテキストを消費せずに行う。本来の会話を汚さないで質問できる - 用途に応じてモデルを使い分ける
参考リンク
