GitHub Copilot CLIとSDKは、session単位のAI credit上限を設定できるようになった。無人Agentの費用暴走を抑えられるが、進行中responseが完了するまで止まらないsoft capであり、設定値を厳密な請求上限として扱ってはいけない。
何が変わったか
Copilot CLIとCopilot SDKで、1 sessionが消費できるAI creditsの上限を指定できる。計測にはmodel callだけでなく、subagentやcompactionなどの背景処理も含まれる。interactive sessionでは/limits、noninteractive runでは--max-ai-creditsを利用する。
到達時、interactiveでは上限変更後に同じtaskを続けられる。noninteractiveではrunが終了する。利用量はresponse完了後に確定するため、上限はhard stopではなくsoft capで、設定値を少し超える場合がある。
変更前後の差
| 項目 | 上限なし | session limitあり |
|---|---|---|
| 無人実行 | task完了・手動停止まで継続 | 指定credit付近で終了 |
| 集計範囲 | 全体請求で事後確認 | session内のmodel・subagent・compaction |
| interactive | 手動監視 | /limitsで確認・変更・解除 |
| script | 外部timeout中心 | --max-ai-creditsを指定 |
| 超過 | 制御なし | 進行中response分は超える可能性 |
| 再開 | 独自状態管理 | interactiveは同taskを継続可能 |
誰に影響するか
repository全体の修正、長時間調査、複数subagent、定期的なdependency更新をCopilot CLIやSDKへ任せる利用者に影響する。開発者が画面を見ている短いsessionでも有効だが、最大の効果は夜間jobやCIのように人が停止できない処理にある。
期限
強制移行期限はない。Public Previewで、Copilot CLI 1.0.66以降、Copilot SDK 1.0.5以降が対象である。既存自動化へ追加する前にversionを固定し、Previewの変更を追跡する。
必要な対応
上限は業務価値とtask規模から決める。小さなlint修正とrepository移行で同じ値を使わない。組織全体のspending limitとは別に、1 runの異常を止めるguardrailとして設定する。終了時に何が完了し、何が未完かをmachine-readableに出力し、再試行が同じ作業を最初から重複実行しないようcheckpointを持つ。
実装・移行手順
- 過去jobのAI credit分布と完了率を収集する。
- task種別ごとにP90程度の消費量と異常値を把握する。
- noninteractive commandへ
--max-ai-creditsを追加する。 - 上限到達時のexit code、標準出力、変更ファイルを記録する。
- 部分変更をcommitするか破棄するかをtaskごとに決める。
- 再実行はcheckpointから継続し、同じsubtaskを重複させない。
- 組織budget、rate limit、session limitを別の監視指標にする。
失敗しやすい点
設定値を絶対に超えないhard capだと考える、全体budgetの代わりに使う、上限到達を成功終了として扱う、部分的に変更されたworktreeを次のjobへ渡す、retryのたびに新sessionを作って総額を増やすことが問題になる。
リスク
soft cap超過、途中終了したコードの混入、再試行による総費用増加、低すぎる上限による成功率低下がある。Agentがwrap upするために追加responseを使う場合もあり、請求予測は設定値だけでなく実測分布から行う必要がある。
評価方法
- task種別のAI credit中央値・P90・最大値
- 上限到達率
- 上限到達後の実超過量
- 完了率と人手引き継ぎ率
- 再試行による重複credit
- 部分成果物の再利用率
- 1成功task当たりの総credit
- 組織budgetとの差異
ロールバック
--max-ai-creditsまたはSDK設定を外して従来実行へ戻す。ただし無人jobでは外部timeoutと全体budgetを残す。低すぎる上限が原因なら一律解除せず、task分類ごとの値を調整する。中断されたworktreeは検証せずに本番へ反映せず、差分を破棄するか人手レビューへ回す。
編集部分析
session limitは費用上限というより、Agentが仕事量を無限に拡張することを防ぐ制御である。soft capである以上、正確な請求額を保証する機能ではない。予算、timeout、最大subagent数、変更ファイル数を組み合わせて、異常なrunを早く終わらせる一つの信号として使うべきだ。
実務チェックリスト
- [ ] CLI・SDKの対応versionを確認した
- [ ] task種別ごとに上限を分けた
- [ ] soft cap超過を予算へ織り込んだ
- [ ] 上限到達を成功扱いしていない
- [ ] 部分成果物の扱いを決めた
- [ ] retry時の重複実行を防いだ
- [ ] 組織全体budgetを別に設定した