GitHub Agentic Workflowsにおけるトークン効率の改善

GitHubのAgentic Workflowsは、リポジトリの小さな乱雑さを掃除する道路清掃チームのようなものです。これらのワークフローはリポジトリの衛生状態と品質を大幅に改善しますが、他のエージェンティックワークと同様に、コストは開発者にとって増大する懸念事項です。CIジョブは自動的にスケジュールされトリガーされるため、コストは目に見えないところで蓄積される可能性があります。

幸いなことに、自動化をより効率化することは、インタラクティブなデスクトップセッションを最適化するよりも簡単です。開発者セッション中の作業は予測が難しいですが、エージェンティックワークフローの作業はYAMLで完全に指定され、実行ごとに繰り返されます。

GitHubは自社のリポジトリでAgentic Workflowsを維持・使用しているため、ユーザーと同様にトークン効率を気にかけています。2026年4月、彼らは日常的に依存している多くのワークフローのトークン使用量を体系的に最適化し始めました。

まず、トークン使用状況を記録する必要がありました。各エージェントフレームワーク（Claude CLI、Copilot CLI、Codex CLI）は異なる形式でログを出力し、過去の実行データは不完全な場合がありました。しかし、エージェンティックワークフローのセキュリティアーキテクチャはAPIプロキシを使用して、エージェントが認証資格情報に直接アクセスするのを防ぎます。このプロキシにより、すべての実行におけるトークン使用量を単一の標準化された形式でキャプチャできるようになりました。現在、各ワークフローはtoken-usage.jsonlアーティファクトを出力し、各API呼び出しの入力トークン、出力トークン、キャッシュ読み取りトークン、キャッシュ書き込みトークン、モデル、プロバイダー、タイムスタンプが含まれます。

トークンデータを手に入れた後、彼らは2つの毎日の最適化ワークフローを構築しました：毎日のトークン使用監査人と毎日のトークン最適化器です。監査人は最近のワークフロー実行からトークン使用アーティファクトを読み取り、ワークフローごとに消費を集約し、異常をフラグ付けします。最適化器はフラグ付けされたワークフローのソースコードとログを調べ、具体的な非効率性を説明し、最適化を提案するIssueを作成します。

初期の結果によると、最も一般的な非効率性は未使用のMCPツール登録でした。LLM APIはステートレスであるため、エージェントランタイムは通常、各リクエストにMCPツール関数名とJSONスキーマを含めます。40個のツールを持つGitHub MCPサーバーの場合、1ターンあたり10～15KBのスキーマが追加される可能性があります。エージェントが2つのツールしか使用しない場合、残りの38個は純粋なオーバーヘッドとしてすべてのリクエストに追加されます。スモークテストワークフローでは、未使用のツールを削除することで、呼び出しごとのコンテキストサイズが8～12KB削減され、実行ごとに数千トークンを節約しました。

より大きな構造的機会は、プルリクエストの差分、ファイル内容、レビューコメントの取得などのデータ取得操作を、GitHub MCP呼び出しからGitHub CLI呼び出しに置き換えることでした。MCPツール呼び出しはデータ取得に加えて推論ステップでもあり、余分なトークンを消費します。一方、'gh pr diff'の呼び出しは、LLMを介さない決定論的なHTTPリクエストです。彼らは2つの移行戦略を採用しました：エージェント事前データダウンロードとエージェント内CLIプロキシ置換です。これらのテクニックにより、ほとんどのGitHubデータ取得がLLM推論ループの外に移動されました。

効率化の測定は簡単ではありません。3つの交絡要因があります：すべてのトークンが同じように作られているわけではない（モデルによってコストが異なる）、ワークロードが変動する（リポジトリはライブである）、出力品質が変化する可能性がある。モデルの違いを標準化するために、彼らは実効トークン（ET）メトリックを使用しました：ET = m × (1.0 × I + 0.1 × C + 4.0 × O)。ここでmはモデルコスト乗数、Iは入力トークン、Cはキャッシュ読み取りトークン、Oは出力トークンです。出力トークンは4倍の重みを持ち、キャッシュ読み取りトークンは0.1倍の重みを持ちます。この式は異なるモデル階層間での消費を標準化します。

初期結果は大幅なコスト削減を示しました。gh-awとgh-aw-firewallリポジトリの12の本番ワークフローに展開した後、Auto-Triage Issuesワークフローは109回の修正後実行で62%の削減を示し、Daily Compiler Qualityは19%改善、Daily Community Attributionは37%改善しました。gh-aw-firewallリポジトリでは、Security GuardとSmoke Claudeがそれぞれ43%と59%改善しました。実行頻度も重要で、Auto-Triage Issuesは平均して1日6.8回実行され、その最適化により累計で約7.8M ETが節約されました。

これらの結果に基づき、彼らは3つのパターンを強調しました：多くのエージェントターンは決定論的なデータ収集であること、未使用のツールはコストがかかること、単一の誤設定ルールが暴走ループを引き起こす可能性があること。例えば、Daily Syntax Error Qualityワークフローは1行の設定ミスにより、エージェントが64ターンのフォールバックループに陥りました。

次のステップには、モノリシックエージェントをより小さく安価なモデルを使用するサブエージェントチームにリファクタリングすること、ワークフローレベルの最適化からシステムレベルの最適化に移行すること、ワークフローポートフォリオの重複を分析することが含まれます。彼らは、最初のステップはAPIプロキシを追加し、ログ記録を有効にし、データに最適化の方向性を指示させることだと強調しています。