何が起きたか
GitHub Docsは、Copilot CLIのAutopilotモードについて、入力を待たずに各ステップを自律的に進める仕組みとして案内した。既定では5つの自動継続メッセージの後に一時停止し、--max-autopilot-continuesで上限を調整できる。Autopilotは、タスク完了、進行不能な問題、Ctrl+キーでの停止、継続上限到達のいずれかで止まる。
詳細
GitHubの説明では、Autopilotモードは対話型モードと異なり、最初の指示の後は入力待ちなしで進む。対話中はShift+Tabでモードを切り替えられ、/settings stayInAutopilot false を設定すると、タスク完了後に標準の対話型モードへ戻る動作にできる。 権限面では、Autopilotに入ると「Enable all permissions」「Continue with limited permissions」「Cancel」の3択が示される。GitHubは、--allow-allまたはそのエイリアス--yoloで、CLIエージェントにすべてのツール、パス、URLの使用を許可できるとしている。
Key Facts
| Copilot CLIのAutopilotモードは、最初の指示後に入力待ちを挟まず自律的に実行する（source_index: 0） | [2] |
| 既定の自動継続上限は5回で、--max-autopilot-continuesで変更できる（source_index: 0） | [2] |
| Autopilotは、タスク完了・進行不能な問題・Ctrl+キーによる停止・継続上限到達のいずれかで停止する（source_index: 0） | [2] |
| GitHubは、Autopilotが明確に定義されたタスクに向く一方、曖昧な指示には不向きだとしている（source_index: 0） | [2] |
| --allow-allまたは--yoloで、CLIエージェントにツール、パス、URLの使用を許可できる（source_index: 0） | [2] |
本紙の見方
Autopilotモードの新しさは、Copilot CLIを「対話の相手」から、権限と上限を与えたうえで手順を継続実行する実行系として扱う点にある。もっとも、GitHubの説明を読む限り、これは完全な無人化ではなく、継続回数の既定上限が5回に設定され、権限の付与も明示的に求める設計である。つまり、対話型CLIの延長線上にある自動化であって、判断を放棄したブラックボックス化ではない。 本紙の関連記事であるGitHub Copilot CLIに定期・遅延実行の試験機能追加（2026-09-04）は、プロンプトの自動送信という入力側の自動化を扱っていた。今回のAutopilotは、その先の応答生成と後続手順の継続までをCLI側に寄せる説明であり、同じ「自動化」でも対象が一段深い。連続実行の上限、権限、サンドボックスという制約を前面に置いている点からは、GitHubが無制限な自走ではなく、制御可能な自律実行を目指していることが分かる。 業界構造で見ると、焦点はコード生成の質そのものよりも、どこまでの操作をCLIに許すかという実行権限の設計にある。--allow-allやローカル/クラウドのサンドボックス説明があることから、対象はファイル変更、削除、URL利用を含む実務フローであり、開発者はモデルの賢さだけでなく、誤操作時の影響範囲を管理する必要がある。バッチ操作やCIワークフローへの適性も示されているため、今後の確認点は、実運用での停止頻度、権限設定ごとの差、--max-autopilot-continuesを含む既定値が現場でどう使われるかである。
なぜ重要か
GitHubの説明に基づけば、Autopilotモードはテスト作成、リファクタリング、CIエラー修正のような明確な作業を、人の逐次確認なしに進める用途を想定している。これにより、開発者は「どの作業を任せるか」だけでなく、「どの権限まで渡すか」を設計課題として扱う必要がある。
日本への影響
日本の開発現場でも、Copilot CLIにファイル変更やURL利用まで許す前提で運用するなら、権限管理とサンドボックス設計が導入条件になるとみられる。特にCI修正やスクリプト作成のような反復作業では、--allow-allや--max-autopilot-continuesの扱いが運用ルールの論点になりやすい。