GitHub Copilot CLIをスクリプトや自動処理へ組み込むと、作業を止めずに進められる一方で、「どこまでAIクレジットを消費するのか分からない」という不安が出てきます。特に、複数のモデル呼び出し、サブエージェント、長いセッション、バックグラウンド処理が重なると、人が見ていない間に想定以上の利用量になる可能性があります。
GitHubは2026年7月1日、Copilot CLIとCopilot SDKで、セッション単位のAIクレジット上限を設定できる機能を公開しました。対話型セッションでは/limits、非対話型実行では--max-ai-creditsを使い、1回の作業や自動処理が消費できるAIクレジットに上限を設けられます。
この機能は、月間予算や組織全体の支出制限とは役割が異なります。1回の実行をどこで止めるかを決めるための安全装置です。この記事では、機能の仕組み、設定方法、実務での使い分け、注意点を整理します。
先に結論：自動処理では上限設定を標準にしたい
Copilot CLIを手元で対話的に使うだけなら、利用者が途中経過を見ながら止められます。しかし、CI、定期バッチ、夜間処理、Issue起点の自動修正などでは、人が常に監視しているとは限りません。
このような運用では、--max-ai-creditsを明示的に設定し、1回の実行で使える量を制限するのが現実的です。
ただし、セッション上限は「絶対にその値を超えない」厳密なハードキャップではありません。GitHubの説明では、利用量は応答が返った後に確定するため、処理中の応答が完了する分だけ、設定値をわずかに超える可能性があります。
したがって、上限値を予算ぎりぎりに設定するのではなく、多少の超過を見込んだ余裕を持たせる必要があります。
Copilot CLIのAIクレジット上限とは
今回追加された機能は、Copilot CLIまたはCopilot SDKの1セッションで消費できるAIクレジット量を制御するものです。
GitHubの公式発表によると、利用量には次のような処理が含まれます。
- モデルへの呼び出し
- サブエージェントによる処理
- コンパクションなどのバックグラウンド作業
単純な質問回数だけではなく、エージェントが内部で行う複数の処理も対象になる点が重要です。画面上では1回の依頼に見えても、内部では複数回のモデル利用が発生する可能性があります。
上限に達すると、対話型セッションと非対話型実行で動きが異なります。
対話型セッションの場合
対話中に上限へ達した場合は、Copilotが処理を止め、上限を引き上げるか調整するよう促します。上限を変更すれば、タスクを最初からやり直さず、停止したところから続けられます。
非対話型実行の場合
スクリプトや自動処理では、指定した上限に達すると実行が終了します。人間への確認待ちで無期限に止まるのではなく、1回の処理をそこで区切れるため、自動化と相性がよい仕組みです。
利用条件と対応バージョン
2026年8月1日時点のGitHub公式情報では、この機能はパブリックプレビューです。対象はCopilot for Individuals、Business、Enterpriseです。
対応バージョンは次のとおりです。
- Copilot CLI 1.0.66以降
- Copilot SDK 1.0.5以降
パブリックプレビューのため、仕様やコマンド、利用条件が変更される可能性があります。業務へ組み込む場合は、固定した手順を長期間そのまま使うのではなく、更新情報を定期的に確認した方が安全です。
Copilot CLIを更新する場合、GitHubは次のコマンドを案内しています。
copilot update更新前には、現在のバージョン、組織ポリシー、既存の自動処理への影響も確認してください。
対話型セッションでは/limitsを使う
Copilot CLIをターミナルから対話的に使っている場合は、セッション内で/limitsを実行します。
公式説明では、このコマンドから上限の表示、設定、解除ができます。具体的な画面表示や入力形式は、バージョン更新で変わる可能性があるため、実際のCLI表示に従って操作してください。
対話型の上限は、次のような使い方に向いています。
- 初めて扱うリポジトリの調査
- 大規模なリファクタリングの事前検討
- 複数ファイルをまたぐ不具合修正
- モデルやプロンプトによる消費量の違いを確認する試行
たとえば、最初は低めの上限で調査と計画だけを依頼し、内容を確認した後に上限を追加する方法があります。最初から大きな上限を与えるより、処理が広がりすぎるのを防ぎやすくなります。
非対話型実行では--max-ai-creditsを指定する
人が操作しない実行では、--max-ai-creditsオプションを使います。GitHubの公式発表では、このオプションによって1回の実行に上限を設けられると説明されています。
概念的には、次のように実行コマンドへ上限値を追加します。
copilot [実行内容] --max-ai-credits [上限値]実際のサブコマンドや引数は、行いたい処理と利用中のCLIバージョンに合わせて確認してください。存在しない構文を固定でコピーするのではなく、copilot --helpや公式ドキュメントで現在の形式を確認することが大切です。
非対話型の上限設定は、次のような場面で役立ちます。
- GitHub ActionsからCopilot CLIを呼び出す
- 定期的なコード調査を行う
- 複数リポジトリを順番に処理する
- Issueやアラートを起点に自動分析する
- 社内ツールからCopilot SDKを実行する
自動処理では、失敗時の再実行が重なると利用量が増えることがあります。上限設定だけでなく、リトライ回数、タイムアウト、対象ファイル数、同時実行数も合わせて管理する必要があります。
セッション上限と月間予算は別物
セッション上限を設定したからといって、月間費用や組織全体の利用量を完全に管理できるわけではありません。
GitHubは、セッション上限について、全体の予算や支出制限を補完するものであり、置き換えるものではないと説明しています。
違いを整理すると、次のようになります。
| 管理対象 | 主な目的 | 確認したい点 |
|---|---|---|
| セッション上限 | 1回の作業や自動処理の暴走を抑える | タスクの規模、停止時の扱い、多少の超過 |
| 月間予算・支出制限 | アカウントや組織全体の費用を管理する | 利用者数、チーム別配分、請求期間 |
| 同時実行数 | 複数ジョブによる利用量増加を抑える | CIの並列数、リトライ、キュー制御 |
| 権限・ポリシー | 利用できる機能や対象者を制限する | 組織設定、モデル利用、外部接続 |
1セッションの上限が小さくても、同じ処理が100回実行されれば全体の消費量は増えます。逆に、月間予算だけ設定していても、1つの誤ったジョブが大きな割合を使う可能性があります。
実務では、この2つを組み合わせて管理する必要があります。
上限値はどう決めるか
公式情報には、すべての利用者に共通する推奨値は示されていません。タスク内容やモデル、リポジトリ規模によって必要量が変わるためです。
最初から感覚で決めるより、次の手順で基準を作る方が現実的です。
1. 小さなタスクで利用量を確認する
単一ファイルの説明、テスト候補の提案、小さな修正など、範囲が分かりやすい処理から始めます。どの程度の上限で完了するかを記録します。
2. タスクを分類する
「調査だけ」「小規模修正」「複数ファイル修正」「大規模変更」のように分け、それぞれの標準上限を決めます。
3. 完了率と停止率を見る
上限が低すぎると、多くの処理が途中で終了し、人間の手戻りが増えます。高すぎると、安全装置としての意味が弱くなります。一定期間の実行結果から調整します。
4. 超過分の余裕を持たせる
セッション上限はソフトキャップです。設定値をわずかに超える可能性を考慮し、厳密な予算値より低い位置に設定します。
5. 本番と検証環境で分ける
検証環境では利用傾向を調べるために多少広い上限を認め、本番の自動処理では狭くするなど、用途ごとに変えます。
SE実務での運用例
コード調査だけを自動化する
障害調査や影響範囲の確認では、最初のジョブを読み取りと報告作成だけに限定します。上限へ達した場合は、結果を途中経過として保存し、人間が次の作業を判断します。
この方法なら、エージェントが勝手に修正範囲を広げるのを防ぎながら、調査時間を短縮できます。
軽微なIssueを処理する
誤字、設定値の修正、単純なテスト追加など、定型的なIssueに小さな上限を設定します。処理が複雑になった時点で終了させ、人間のレビューへ切り替えます。
「簡単なIssueとして始まったが、依存関係や設計変更が必要だった」というケースを早めに止められます。
夜間バッチで複数リポジトリを確認する
複数リポジトリに対し、依存関係やテスト失敗を調査する場合は、リポジトリごとに上限を設定します。全体で1つの大きな上限を共有すると、最初のリポジトリだけで消費してしまう可能性があります。
ジョブを分離し、各実行の結果と消費量を記録すると、翌朝に失敗原因を確認しやすくなります。
フリーランスSEが注意したいポイント
フリーランスSEは、顧客ごとに契約条件、費用負担、利用可能なAIサービスが異なります。個人契約のCopilotを顧客業務へ使ってよいか、利用料をどの案件の経費として扱うかも確認が必要です。
案件別に利用量を把握したい場合、次のような運用が考えられます。
- 案件ごとに実行スクリプトを分ける
- 案件別の標準上限を設定する
- 実行ログへ案件名とタスクIDを残す
- 自動リトライ回数を制限する
- 月末に案件別の実行回数を確認する
ただし、セッション上限だけで正確な原価計算ができるとは限りません。請求や顧客への説明に使う場合は、GitHub側で確認できる利用状況や契約内容も合わせて確認してください。
導入時に起こりやすい失敗
上限を設定しただけで安心する
同時実行数やリトライを制限していなければ、複数の小さなセッションが大量に発生します。1回あたりの上限だけでなく、実行回数も管理する必要があります。
ソフトキャップを厳密な停止値と考える
処理中の応答は完了するため、実際の利用量は設定値を少し超える可能性があります。費用上限ぎりぎりの値を設定しない方が安全です。
すべてのタスクへ同じ値を使う
コード説明と大規模リファクタリングでは必要量が異なります。一律の設定では、簡単な作業に多すぎたり、複雑な作業が毎回途中で止まったりします。
停止後の処理を決めていない
上限へ達したとき、失敗として再実行するのか、人間へ通知するのか、途中結果を保存するのかを決めておかないと、無限リトライにつながる可能性があります。
プレビュー機能を固定仕様として扱う
パブリックプレビューでは仕様変更の可能性があります。自動処理ではバージョンを管理し、更新時にテストする仕組みが必要です。
チーム導入前のチェック項目
- Copilot CLIとSDKの対応バージョンを確認したか
- タスク別の標準上限を決めたか
- 月間予算や組織全体の支出制限も設定したか
- 同時実行数とリトライ回数を制限したか
- 上限到達時の通知先を決めたか
- 途中結果やログを保存できるか
- パブリックプレビューの変更を追跡する担当を決めたか
- 顧客データや機密情報の扱いを確認したか
コスト管理は、単に数字を決める作業ではありません。自動処理が途中で止まったときの業務影響や、人間が引き継ぐ手順まで含めて設計する必要があります。
この機能が向いている人・向いていない人
セッション上限は、Copilot CLIを自動化へ組み込む人、複数のエージェント処理を走らせる人、チームで利用量を管理したい人に向いています。処理の規模が不明なタスクを、まず小さく試したい場合にも役立ちます。
一方で、普段は短い対話を数回行うだけで、利用量を常に自分で確認できる人には、設定の効果を感じにくいかもしれません。また、セッション上限だけで月間費用を完全管理したい人には不十分です。
これから試すときの進め方
最初はCopilot CLIを対応バージョンへ更新し、対話型セッションで/limitsを確認します。小さなコード調査に低めの上限を設定し、どのタイミングで停止するか、途中から再開できるかを試します。
次に、非対話型の検証用スクリプトへ--max-ai-creditsを追加します。上限到達時の終了コード、ログ、途中成果物の状態を確認し、自動リトライが発生しないようにします。
十分に挙動を確認した後で、CIや定期処理へ段階的に導入するのが安全です。
まとめ
GitHub Copilot CLIとSDKのAIクレジットセッション上限は、1回のエージェント実行が使える量を制御する機能です。対話型では/limits、非対話型では--max-ai-creditsを利用します。
この機能は、自動化の暴走や想定外の長時間処理を抑える助けになります。ただし、ソフトキャップであること、月間予算の代わりにはならないこと、同時実行やリトライも管理する必要があることには注意が必要です。
自動化へ組み込む場合は、タスク別に上限を分け、停止後の処理を設計し、全体予算と組み合わせて使うのが現実的です。まずは小さなタスクで利用傾向を確認し、実行結果を見ながら調整してください。
コメント