何が起きたか
GitHubは、開発支援AI「GitHub Copilot」のCLI（コマンドラインインターフェース）向けに、プロンプトを自動送信する2つのスラッシュコマンド「/every」と「/after」を公開した。これは対話型のCopilot CLIセッション内で、一定間隔ごとの繰り返し実行（/every）と、指定時間経過後の1回限りの実行（/after）を可能にする試験機能。現時点では「/experimental on」スラッシュコマンドまたは「--experimental」コマンドラインオプションを使用した場合にのみ利用できる。
詳細
「/every」は「/every INTERVAL PROMPT」の形式で使用し、指定した間隔（例: 1h、30m）ごとにプロンプトを繰り返し送信する。エイリアスとして「/loop」も利用可能。「/after」は「/after DELAY PROMPT」の形式で、遅延（例: 30m、10m）経過後にプロンプトを1回だけ実行する。間隔・遅延の単位はs（秒）、m（分）、h（時間）、d（日）で、サフィックスなしの数値は分として解釈される。最小間隔は10秒、最大は1日（24時間）。スケジュールされたプロンプトは「[Scheduled prompt #4]」のように識別され、「stop prompt 4」でキャンセル可能。アクティブなスケジュールは引数なしの「/every」「/after」で一覧表示でき、方向キーとdキーで削除する。スケジュールは作成されたセッションにスコープされ、セッション実行中のみトリガーされる。セッションを閉じて再度開くと（--continue/--resume）、スケジュールは再起動され、再度開いた時点から間隔が測定される。セッションが開いていない場合にスケジュール実行するには、外部スケジューラ（macOS/Linuxのcron、Windowsのタスクスケジューラ）から「copilot -p "YOUR PROMPT"」を実行する方法が案内されている。
Key Facts
| GitHubはCopilot CLI向けに、プロンプトを自動送信するスラッシュコマンド「/every」と「/after」を公開した（試験機能）。 | [1] |
| 「/every」は一定間隔でプロンプトを繰り返し送信し、「/after」は指定遅延後に1回だけ送信する。 | [1] |
| これらのコマンドは「/experimental on」または「--experimental」オプションでのみ利用可能。 | [1] |
| 間隔・遅延の最小値は10秒、最大値は1日（24時間）。 | [1] |
| スケジュールは作成されたセッションの実行中のみトリガーされ、セッションを閉じると停止する。 | [1] |
本紙の見方
今回の発表は、GitHub Copilot CLIに「時間」という新たな次元を導入する点で注目される。従来のCopilot CLIは、ユーザーがプロンプトを入力して初めて応答を返す「対話型」のツールだった。これに対し「/every」「/after」は、ユーザーが明示的に指示しなくても、設定した時刻や間隔で自動的にプロンプトを実行し、結果をセッション内に返す。これは、AIアシスタントを「呼び出し型」から「常駐型」へと進化させる試みと位置づけられる。 機能の構成をバリューチェーンで見ると、入力（プロンプト）→処理（Copilot CLI）→出力（結果）という単純な流れに、「スケジューリング」という制御層が加わった構造だ。特に、外部スケジューラ（cronやタスクスケジューラ）と組み合わせて「copilot -p」を実行する方法は、CLIを非対話モードで実行できることを示しており、これにより夜間のテスト実行や定期的な依存関係チェックなど、人間の介入なしにAIが自律的にタスクを処理する「自動化パイプライン」の一部としてCopilotを組み込むことが可能になる。 この機能の主役は、あくまで「スケジュール実行」という仕組みであり、特定のプロンプト内容ではない。GitHubは、テストスイートの実行、プルリクエストのコメント確認、READMEの変更確認、スキルの定期実行など、具体的なユースケースを例示しているが、これらはあくまで応用例に過ぎない。本質は、AIエージェントを「時間駆動」で動かすための基盤を提供した点にある。 業界構造への含意として、この動きは、AIコーディングツールの競争軸が「コード生成の品質」から「ワークフローへの統合度」へとシフトしつつあることを示唆する。GitHubは、Copilotを単なるコード補完ツールではなく、開発プロセスの自動化を担う「エージェント」として位置づけようとしている。競合他社（例えば、AnthropicのClaude Codeや、OpenAIのCodexなど）も同様の自律実行機能を強化しており、この分野での差別化が今後の焦点になる。 一方で、未確定の論点も多い。まず、この機能は「試験段階」であり、正式版での仕様変更や、安定性・セキュリティ上の問題が明らかになる可能性がある。特に、スケジュール実行中にエラーが発生した場合の挙動や、長時間実行時のリソース消費、プロンプトの内容によっては意図しない副作用（例えば、誤ったコード変更を自動で行うリスク）が生じる可能性について、GitHubは詳細を明らかにしていない。また、外部スケジューラとの連携は、ユーザー自身がcronやタスクスケジューラを設定する必要があり、その際の認証情報の管理や、複数セッションでのスケジュール競合などの運用面での課題も残る。次に確認すべきは、正式版への移行時期、エンタープライズ向けの管理機能（スケジュールのポリシー制御など）、そしてこの機能が実際にどの程度の開発生産性向上に寄与するかの定量的な評価だろう。
なぜ重要か
この機能は、AIコーディング支援が「ユーザーの指示待ち」から「自律的な定期実行」へと進化する一歩を示す。開発者は、定型的なタスクをAIに任せ、より創造的な作業に集中できるようになる可能性がある。また、外部スケジューラとの連携により、CI/CDパイプラインや運用監視など、開発プロセス全体へのAI組み込みが現実味を帯びてくる。