2026 年 5 月、GitHub Blog が Improving token efficiency in GitHub Agentic Workflows を公開し、Pull Request ごとに走る agentic workflow が「気づかないうちに大きな API 請求を積み上げる」現象とその対策を社内事例で公開しました。GitHub 自身が 本番ワークフローを計測 → 非効率を特定 → 修正用エージェントを構築する 3 段階で改善した実例で、「同じ workflow を回しながら 30 〜 60% トークン削減」というインパクトある数字が出ています。
弊社では、受託の AI エージェント案件で 「PR ごとに自動レビュー」「Issue ごとに自動仕分け」といった agentic workflow を案件横断で運用しています。本記事では、トークン浪費の 検出 → 削減 → 契約への落とし込み までを、受託標準の運用設計として整理します。
なぜ「静かなトークン浪費」が起きるのか
agentic workflow のトークン浪費は、「動いているから OK」で見過ごされがちな構造を持ちます。
| 浪費パターン | 典型例 | 受託での影響 |
|---|---|---|
| 過剰コンテキスト | PR 全差分を毎回投入 | 大規模 PR で爆発 |
| 重複呼び出し | 同じ情報を多段で再質問 | 月次で 2 〜 3 倍化 |
| キャッシュ未活用 | 同一プロンプトを毎回送信 | プロンプトキャッシュ機会損失 |
| 出力肥大 | 「念のため」長文の根拠を要求 | トークン × 件数で線形増加 |
| 失敗リトライ | 失敗時に full prompt を再送 | 障害時にスパイク |
特に **「過剰コンテキスト」は、受託で最初に踏みやすい落とし穴です。「PR の差分を全部投げれば賢くなるはず」という直感が、「差分の 9 割は agent の判断に不要」**という現実とぶつかります。
これは GitHub Copilot 従量課金とトークン消費ガバナンス で扱った “課金体系の変化” の続編にあたる論点で、「課金が見えるようになった次は、エンジニアリングで削る段階」に入ったということです。
受託で組む「計測 → 削減 → 検証」3 ステップ
GitHub の事例を受託の現場に翻訳すると、以下の 3 ステップが標準フローになります。
[Step 1: 計測 (1〜2 週間)]
├ workflow ごとのトークン入出力を記録
├ ジョブ別 / モデル別 / リポジトリ別に集計
└ コスト × 件数のヒートマップ化
[Step 2: 削減 (2〜4 週間)]
├ 上位 5 つの「太い workflow」を特定
├ プロンプト圧縮 / コンテキスト削減 / キャッシュ導入
└ 修正用エージェント（fixer agent）を作って一括適用
[Step 3: 検証 (継続)]
├ 削減後のトークン消費を週次でレポート
├ 品質劣化が出ていないかを A/B で確認
└ 月次で顧客 PM と振り返り特に Step 2 の「修正用エージェント」は、GitHub 自身が **「効率化を効率化する」ためにエージェントを使ったというメタ的な打ち手で、受託でも横展開価値が高い手法です。これは Claude Code Auto Mode で受託を回す の Approval Gates と組み合わせると、「修正案は自動生成 → 人間が承認」**のフローで安全に量産できます。
削減効果が大きい 5 つのテクニック
実案件で効果検証済みの削減テクニックを、効果順に並べます。
1. コンテキスト最小化 — 「必要な差分だけ」投げる
PR 全差分ではなく、「変更ファイル × ±50 行」に限定するだけで 30 〜 50% 削減します。テストファイルや lock ファイルは事前に除外します。
2. プロンプトキャッシュ徹底活用
同一の system prompt / few-shot は キャッシュ化します。Anthropic / OpenAI / GitHub Models のいずれもキャッシュヒットで 大幅なコスト削減が効きます。
3. 段階的呼び出し（cascade）
最初に 小型モデル（Haiku / GPT-5.5 mini 相当）でトリアージ → 必要な PR だけ大型モデルに渡す 2 段構成にします。全 PR を大型モデルで処理する案件の 60 〜 80% は、この cascade で削減できます。
4. 出力フォーマット制約
「JSON で 5 項目以内」と最初に固定すると、長文の根拠説明がなくなります。受託の自動レビューでは 「根拠は別途要求された場合のみ」でも品質が変わらないケースが多いです。
5. 失敗時のスマートリトライ
失敗した場合に full prompt をそのまま再送せず、「失敗箇所だけを最小コンテキストで再試行」にします。障害時のスパイクが消えます。
案件横断で「トークン予算」を契約に書く
受託契約に **「トークン予算条項」を組み込み、「使い切ったら追加見積もり」「想定 80% で警告」を明文化することで、「気づいたら超過していた」**事故を防ぎます。
| 条項 | 内容 | 顧客との合意ポイント |
|---|---|---|
| 月次トークン予算 | モデル別の上限値 | 上限到達時の挙動（停止 / 縮退 / 追加課金） |
| アラート閾値 | 50% / 80% / 100% | 通知先・対応 SLA |
| 削減施策レビュー | 月次の削減提案レポート | 顧客の承認権限者 |
| モデル変更権限 | 受託側で軽量化判断可能か | 品質基準の合意 |
| 計測ダッシュボード | 顧客に共有する範囲 | アクセス権限・更新頻度 |
特に **「モデル変更権限」は受託で最初に揉める論点です。「品質基準を満たす範囲なら受託側でモデル選定可」**と契約に書くことで、cascade 設計の自由度が確保できます。
これは Computer Use 4.5x コスト時代の受託エンジニアリング で扱った “コスト × 品質のトレードオフを契約に組み込む” と同じ思想で、「受託側の手足を縛らない契約」を最初に作ることが鍵になります。
価格モデル — トークン効率化の受託パッケージ
弊社では agentic workflow のトークン効率化を、以下の 3 段階で提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| Token Audit | 60 万円 / 0 円 | 単発の効率化監査 | 計測 + 上位 5 workflow の削減提案レポート |
| Token Optimize | 180 万円 / 20 万円〜 | 中規模 SaaS / 業務システム | Audit + 修正用エージェント構築 + 月次運用 |
| Token Optimize Plus | 400 万円〜 / 60 万円〜 | 複数案件横断 / 大規模運用 | Optimize + 案件横断ダッシュボード + 月次レビュー |
特に Token Audit は 「まずどこで浪費しているのか可視化したい」という相談に刺さるレンジで、多くの場合 1 〜 2 ヶ月で投資回収できる ROI が出ます。
落とし穴 — 「削減して品質が落ちる」を防ぐ
最後に、トークン削減で踏みやすい落とし穴を整理します。
落とし穴 1: 削減と品質低下の境界を測らない
トークンを削った結果、自動レビューの見落とし率が上がっていたというケースがあります。A/B テストで品質指標（Precision / Recall）を必ず計測します。
落とし穴 2: cascade のトリアージモデルが弱い
小型モデルのトリアージ精度が低いと、重要な PR を見落とす事故が起きます。月次でトリアージ精度を監査し、必要に応じて閾値を調整します。
落とし穴 3: キャッシュ設計が雑
system prompt をちょっと変えるたびに キャッシュが全失効します。キャッシュ単位を意識した prompt 設計（不変部分を先頭に固める）を徹底します。
落とし穴 4: 削減効果を顧客に共有しない
削減した分の価値が顧客に伝わらないと、受託側の努力が見えません。月次レポートで「削減額」を金額換算して報告します。
まとめ — 「動いている」から「効率的に動いている」へ
agentic workflow は 「動かす」段階から「効率化する」段階に移行しました。GitHub 自身が 本番ワークフローで 30 〜 60% 削減を達成した実例は、受託の現場でも同等の削減余地があることを示唆しています。
弊社では Token Audit / Optimize / Optimize Plus の 3 段階で agentic workflow の効率化パッケージを提供しています。「Copilot や Claude Code の請求が読めない」「PR ごとの自動レビューが想定の 3 倍コストになっている」というご相談は お問い合わせフォーム からお気軽にどうぞ。
