はじめに
GitHubが2026年5月7日、同社が自社リポジトリで運用しているエージェントワークフローのトークン使用量を大幅削減した取り組みをブログで公開しました。本稿では、計測基盤の構築から未使用ツールの削除・CLI置換・効果測定の考え方まで、実践的な手法を解説します。
参考記事
- タイトル: Improving token efficiency in GitHub Agentic Workflows
- 著者: Landon Cox & Mara Kiefer
- 発行元: GitHub Blog
- 発行日: 2026年5月7日
- URL: https://github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows/
関連記事
要点
- エージェントワークフローはCIジョブとして自動起動されるため、コストが見えにくいところで蓄積されやすい
- GitHubはAPIプロキシを活用してフレームワーク横断でトークン使用量を一元計測し、デイリーの監査・最適化ワークフローを自動化した
- 未使用MCPツールのスキーマはAPIリクエストごとに送信されるオーバーヘッドであり、削除だけで1実行あたり数千トークンの削減が可能である
- データ取得をGitHub MCPからGitHub CLIに置き換えることで、LLMのリーズニングループから不要な推論ステップを除外できる
- モデルのコスト差を正規化した「Effective Tokens（ET）」指標を用いることで、異なるモデル間での最適化効果を正確に比較できる
詳細解説
エージェントワークフローとトークンコストの問題
GitHub Agentic Workflowsは、プルリクエストのレビューやIssueの自動分類、セキュリティチェックといったリポジトリ保守タスクを自動化するエージェント群です。2026年3月にGitHubが発表したこの仕組みは、コード品質と保守効率を大きく高める一方で、CIジョブとして自動スケジューリング・自動トリガーされるためコストが開発者の目に触れにくいという特性があります。
GitHubによれば、インタラクティブなデスクトップセッションとは異なり、エージェントワークフローの処理内容はYAMLで完全に仕様化されており、繰り返し実行されます。この予測可能性こそが、系統的な最適化を可能にする強みです。
トークン使用量の計測基盤
最適化の第一歩として、GitHubはどのようにトークンが消費されているかを把握する必要がありました。Claude CLI・Copilot CLI・Codex CLIなど各エージェントフレームワークがそれぞれ異なる形式でログを出力するという課題に対し、GitHubはエージェントが認証情報に直接アクセスできないよう設けているAPIプロキシを活用しました。このプロキシのセキュリティ設計については以前の記事でも詳しく取り上げていますが、今回はこのプロキシがフレームワーク横断での計測基盤としても機能しています。
各ワークフローは現在、以下の構造を持つ token-usage.jsonl というアーティファクトを出力します。
{
"input_tokens": 12400,
"output_tokens": 820,
"cache_read_tokens": 9800,
"cache_write_tokens": 1200,
"model": "claude-sonnet",
"provider": "anthropic",
"timestamp": "2026-04-15T09:23:11Z"
}1レコードがAPIコール1回に対応し、これをワークフローの他のログと組み合わせることで、トークンがどのフェーズでどれだけ消費されているかを時系列で把握できます。
デイリー監査・最適化ワークフローの構築
計測基盤を整えた後、GitHubは2つのデイリーワークフローを構築しました。
Daily Token Usage Auditor は、最近のワークフロー実行から token-usage.jsonl を集約し、使用量が急増したワークフローや異常なLLMターン数（通常4ターンのところ18ターンになるなど）を検出してレポートを投稿します。
Daily Token Optimizer は、Auditorがフラグしたワークフローのソースコードと実行ログを分析し、具体的な非効率点と改善策をGitHub Issueとして起票します。
これら2つのワークフロー自体もエージェントワークフローとして動作し、そのトークン使用量もデイリーレポートに含まれます。Optimizerは人間が見落とすような非効率を複数発見しており、小さな好循環が生まれています。
最適化手法① 未使用MCPツールの削除
Auditor/Optimizerが発見した最も一般的な非効率は、未使用のMCPツール登録でした。
LLM APIはステートレスであるため、エージェントランタイムは各APIリクエストにMCPツールの関数名とJSONスキーマを含めて送信します。GitHubによれば、40ツールを持つGitHub MCPサーバーでは1ターンあたり 8〜15 KB のスキーマが付加されます。エージェントが実際に使うのが2ツールだけであれば、残り38ツールのスキーマは純粋なオーバーヘッドです。
ワークフロー作者は最初からフルセットのツールを設定しがちですが、時間が経つにつれてほとんどのワークフローは狭い安定したツールセットに依存するようになります。Optimizerはツールマニフェストと実際のツールコール履歴を照合してこのパターンを検出し、未使用ツールの削除を推薦します。
実際に未使用ツールを削除すると、コンテキストサイズが1コールあたり 8〜12 KB 削減され、1回の実行あたり数千トークンの節約になりました（動作変更なし）。
なお、Glossary Maintainerというワークフローでは search_repositories というツールが1回の実行中に 342回 も呼び出され、全ツールコールの58%を占めていましたが、ローカルファイル変更のスキャンのみを行うそのワークフローには本来不要なツールでした。削除が推薦されています。
最適化手法② GitHub MCPをGitHub CLIに置き換える
より大きな構造的改善として、GitHubはデータ取得（PRのdiff・ファイル内容・レビューコメントなど）にGitHub MCPを使っていた箇所をGitHub CLIコマンドに置き換えました。
MCPツールコールは単なるデータ取得ではなく「LLMの推論ステップ」でもあります。エージェントはツールコールを決定し、引数を生成し、その結果をコンテキストとして受け取るため、これはLLM API呼び出し1回を消費します。一方、gh pr diff などのCLIコマンドは、LLMを介さない確定的なHTTPリクエストです。
GitHubは2つの戦略を用いています。
① エージェント実行前のデータ事前ダウンロード（Pre-agentic data downloads）
エージェントが常に必要とするデータ（PRのdiffや変更ファイルリストなど）は、ワークフローのセットアップステップでghコマンドを実行し、結果をワークスペースファイルに書き込んでおきます。エージェントはそのファイルを参照するだけです。
# ワークフローYAMLの構成例（参考記事の手法をもとにした参考サンプルです）
steps:
- name: Pre-download PR diff
run: |
# エージェントが必ず必要とするPRのdiffを事前に取得してファイルに保存する
gh pr diff ${{ github.event.pull_request.number }} > /workspace/pr.diff
# 変更ファイル一覧も同様に取得しておく
gh pr view ${{ github.event.pull_request.number }} --json files > /workspace/pr-files.json
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Run agent
# エージェントは /workspace/pr.diff と /workspace/pr-files.json を読むだけ
# MCP経由のデータ取得ステップが不要になる
run: gh aw run .github/workflows/triage-agent.ymlこのアプローチにより、LLMのリーズニングループからデータ取得を分離できます。
② エージェント内CLIプロキシ置換（In-agent CLI proxy substitution）
実行時にエージェントが何を取得するかを動的に決定する場合、事前ダウンロードは使えません。この場合は、CLIのトラフィックをGitHub APIサーバーへルーティングする軽量な透過型HTTPプロキシを利用します。エージェントは gh pr view –json を実行し、通常のターミナル操作と同様に構造化データを受け取ります。認証トークンをエージェントに渡さないセキュリティ要件を維持しながらトークン使用量を削減できます。
効果測定の指標：Effective Tokens（ET）
最適化の効果を正確に測るには、単純なトークンカウントでは不十分です。同じワークフローをClaude HaikuとClaude Sonnetで実行した場合、トークン数は同程度でもコストは大きく異なります。GitHubはモデル間のコスト差を正規化した Effective Tokens（ET） という指標を導入しています。
ET = m × (1.0 × I + 0.1 × C + 4.0 × O)
各変数の意味は以下のとおりです。
- m：モデルコスト乗数（Haiku = 0.25×、Sonnet = 1.0×、Opus = 5.0×）
- I：新規処理の入力トークン数（weight 1.0×）
- C：キャッシュ読み込みトークン数（キャッシュ提供のため低コスト、weight 0.1×）
- O：出力トークン数（最も高額なため weight 4.0×）
この指標により、モデルの切り替えによるコスト変化も正規化されます。「ET10%削減＝コスト10%削減」として解釈でき、異なるモデルやワークフロー間での効果比較が可能になります。
なお、効果測定には別の難しさもあります。GitHubによれば、ワークフローはライブリポジトリで動作するため、5行修正のPRを処理する実行と200行PRを処理する実行が混在します。単純なトークン数の変化をそのまま効率の改善と見なすことはできず、LLM APIコール数（ターン数）とトークン数の両方を並行して追跡することが重要とされています。
監査・最適化ワークフローの導入方法
GitHubは上述の監査・最適化ワークフローを誰でも利用できるようにしています。gh-aw CLIを使って以下の手順で追加できます。
前提条件： GitHub CLIがインストール済みであること。バージョン確認は以下のコマンドで行えます。
gh –version
ステップ1： gh-aw CLIをGitHub拡張機能としてインストールします。
gh extensions install github/gh-aw
ステップ2： トークン監査ワークフローとトークン最適化ワークフローをリポジトリに追加します。
gh aw add githubnext/agentic-ops/copilot-token-audit githubnext/agentic-ops/copilot-token-optimizer
これらを既存のCIと並行して実行すると、トークン使用量の即時可視化と継続的な最適化が可能になります。
初期結果
GitHubによれば、12本の本番ワークフロー（gh-awリポジトリおよびgh-aw-firewallリポジトリ）にAuditor/Optimizerを展開した結果、9本が最適化の推薦を受けて変更を実施しました。
| ワークフロー | ET削減率 | 主な要因 |
| Smoke Claude | −59%（最大−79%） | MCPツール削減＋Haiku切り替え |
| Auto-Triage Issues | −62% | 不要なデータ取得を事前CLIステップに移行 |
| Security Guard | −43% | セキュリティ非関連PRではLLMをスキップ |
| Daily Community Attribution | −37% | ツール最適化 |
| Daily Compiler Quality | −19% | ツール最適化 |
| Contribution Check | +5% | 最適化後に大規模PRが集中（ワークロード変化） |
Contribution Checkの5%増加は最適化失敗ではなく、最適化後の期間に開発活動が活発化し大規模PRの比率が39%から65%に増加したためとGitHubは分析しています。
また、Auto-Triage Issuesは1日平均6.8回という高頻度で実行されることから、62%の削減が累積して観測期間中の節約量は約780万ETに達したとGitHubは報告しています。ワークフロー最適化の優先順位は「1回あたりのトークン量」だけでなく「実行頻度」も重要な要素です。
まとめ
GitHubが自社ワークフローで実証した「計測→監査→最適化」のサイクルは、エージェントCI/CDを運用する開発者が直接応用できる実践的な知見です。未使用MCPツールの削除とCLI置換という2つの手法が特に効果的で、コスト意識を持ってエージェントワークフローを設計する重要性が改めて示されました。コスト管理の観点では、GitHub Copilotの従量課金制移行もあわせてご確認いただければと思います。
