自作の定期実行は、条件が合うタスクから公式へ移す

毎朝の変更点確認や Issue の仕分けを自作拡張で実行しているなら、VS Code Copilot の Automations が置き換え候補になります。毎時・毎日・毎週で足りるタスクを選び、手動で結果を確かめてから移す、というのが本記事の提案です。

ただし、同じリリースで追加された Voice Mode は、チーム全員へ配れる機能とは限りません。GitHub Copilot Business / Enterprise は対象外です。定期実行の評価と音声機能の全社展開は、別の判断として扱う必要があります。

出典は 2026 年 9 月 9 日公開の VS Code 1.137 リリースノート です。以下は 2026 年 9 月 19 日時点の記載をもとに、確認できる仕様と、チームで決める運用を分けて説明します。

Automations で選べる実行間隔と有効化

Automations は、エージェントへの定型的な依頼をスケジュールで開始する preview 機能です。公式が案内している実行間隔は hourly / daily / weekly、つまり毎時・毎日・毎週。必要なときにオンデマンドで実行することもできます。

用意されているテンプレートには、変更点の確認、Issue のトリアージ、バグ探しがあります。トリアージは、Issue の内容を読み、優先度や担当の候補を整理する作業です。独自のプロンプトも指定できるため、チームの確認項目に合わせた依頼を作れます。

有効化する設定は次のとおりです。

{
  "chat.automations.enabled": true
}

設定後は Agents ウィンドウを開き、サイドバーの Automations を選びます。公式は段階的に提供すると案内しているため、項目が表示されない場合はバージョンと提供状況も確かめてください。公式リリースノート に、設定キーと入口が記載されています。

自作 cron 拡張から乗り換える判断

必要な自由度をタスクごとに書き出す

自作の定期実行には、チーム固有の曜日や時刻、実行条件をコードで表せる利点があります。公式機能へ移す前に、既存の設定をそのままコピーしようとせず、実際に必要な条件を言葉にしてください。

たとえば「毎日、変更点を一覧にする」なら daily が候補です。「営業日だけ実行し、祝日は除く」なら、曜日だけでなく休日の判定も必要になります。リリースノートには任意の cron 式、分単位の間隔、営業日指定の説明がありません。営業日・祝日を判定する要件まで置き換えられるとは判断できません。

既存タスクの要件移行の考え方
毎時・毎日・毎週の確認で足りるAutomations で結果を評価する候補にする
分単位や独自のカレンダー判定が必要同等の設定ができると確認するまで既存の仕組みを残す
担当者の PC を閉じた後も期限どおりに完了させたい停止中の扱いを確認するまで切り替えを保留する
単に開始ボタンを押す手間を減らしたいオンデマンドで依頼内容を固め、適切な間隔を決める

公式機能であることを、無制限利用の保証にしない

Automations では、製品が用意した入口から定期実行を設定できます。自作の外部自動化が公式の想定する使い方かを個別に調べる負担は、移行を検討する理由になります。

ただし、本記事では自作拡張を一律に規約違反と判定したり、公式機能ならアクセス制限を受けないと保証したりはしません。自由度を自分たちで維持する価値と、公式に案内された機能へ寄せる安心感を比べてください。公式機能に寄せても、利用条件の確認と組織のポリシー設定は引き続き必要です。

移行が決まったタスクは、自作側のスケジュールを停止してから公式側で定期化します。両方から同じ Issue に結果を書き込むような二重実行を避けるためです。

定期実行を任せる前に確かめること

まずオンデマンドで実行し、結果を読む

最初は人が結果を確認できる時間帯に実行してください。確認するのは、参照した範囲、出力の根拠、依頼していない変更がないかです。実行履歴や会話に何が記録されるかも、評価対象に含めます。

次は、移行候補を評価するためのプロンプト例です。製品が権限を制限する設定ではなく、作業範囲を伝える指示として使います。

指定した期間の変更点を読み、レビュー担当者向けに要約してください。
各項目に根拠となるコミットまたはファイルを添えてください。
コードの変更、Issue への投稿、PR の作成は行わず、提案だけを返してください。
参照できなかった対象は、推測で補わず一覧にしてください。

既存の手作業と同じ対象を渡して結果を比べれば、確認漏れや余分な出力を見つけやすくなります。結果を採用できると判断してから、チームのレビュー時刻に合わせてスケジュールを設定する順序がおすすめです。

停止中の扱いは公式に記載がない｜移行テストで確かめる

確認したリリースノートには、マシンの電源が切れている間や、エディタを終了した間のスケジュールの扱いは記載されていません。予定がスキップされるのか、再開時に実行されるのかも、この記事では断定しません。

移行テストでは、エディタ終了・端末のスリープ・再起動を分け、予定時刻の前後で実行記録を確認してください。手元で観察した結果は、利用したバージョンと環境を添えて残します。期限を保証する必要がある処理は、観察結果だけで判断せず、公式仕様も確認してから移行します。

費用と preview の扱い

Automations 固有のプレミアムリクエスト消費や費用は、同リリースノートでは確認できません。無料とも、通常のチャットと同じ消費量とも書かず、導入前に GitHub Copilot の課金ドキュメントと利用状況を確認してください。

preview は、チームの業務を任せられると保証する表示ではありません。まずは要約や提案の作成に範囲を絞り、失敗しても担当者が再実行できる用途で評価するのが妥当です。書き込みを伴う処理を追加する際には、使うエージェントやツールの権限も見直します。

定期実行をどこに置くか｜Cursor Projects との比較

VS Code の Automations は Agents ウィンドウで設定・確認する機能です。一方、Cursor Projects の公式発表 は、クラウドの専用マシンで実行し、ノート PC を閉じても処理を継続すると説明しています。手元の環境が必要なテストには、ローカルエージェントを使う設計です。

日々の確認を VS Code の画面に集めたいチームなら、Automations が候補になります。端末を閉じた後の継続が選定条件なら、クラウド実行を明記している Projects を比較対象にできます。ただし、Automations の実行環境がローカルに限られるかどうかは、設定画面の場所からは判断できません。

比較するときは、開始する画面と、処理を実行する環境を分けてください。Projects の計画・委譲の仕組みは Cursor Projects のコーディネーター解説 で扱っています。エディタ全体の選定から見直すなら、Claude Code・Cursor・GitHub Copilot の比較 も判断材料になります。

Voice Mode は Business / Enterprise の全社展開に含められない

音声入力に加えて、セッションについて会話する

Voice Mode は experimental 機能です。エージェントの作業中に音声で会話し、応答に割り込めます。実行中のセッション、選択中のモデル、添付ファイルについて質問し、新しいセッションの開始を依頼することも可能です。

発話を文字にするだけの音声入力と比べ、作業の文脈を踏まえた対話まで扱う点が特徴です。有効化後はチャット入力欄の Voice Mode ボタンを選びます。

{
  "agents.voice.enabled": true,
  "agents.voice.showTranscript": true
}

agents.voice.showTranscript は会話の文字起こしを表示する設定です。読み上げる声は agents.voice.voice で選択できます。機能と設定の説明は 公式リリースノート にあります。

全社契約の席を配っても利用条件は満たせない

公式の提供条件には、次の記載があります。

requires an eligible individual GitHub Copilot plan

続いて、GitHub Copilot Business / Enterprise では利用できないと明記されています。対象の個人向けプランが必要という意味で、すべての個人プランが対象だとまでは読めません。提供条件は 公式リリースノート に記載されています。また、段階的な提供のため、対象アカウントでもすぐには使えない場合があります。

国内の組織で Business の席を全員に配っているなら、その契約を根拠に Voice Mode の利用を約束することはできません。管理者が preview 機能を許可することと、プランが対象に含まれることは別の条件です。公式は組織のポリシーで preview 機能を無効化できるとも説明しています。

Business / Enterprise の利用者が個人プランを併用した場合の可否は、同リリースノートには記載がありません。個人契約の追加を解決策として案内せず、GitHub のプラン資料やサポートで確認し、業務データを扱う社内規程とも照合してください。対象外とした製品側の理由も、公表された記載からは判断できません。

FIXITFIXIT

会社で契約しているのに、音声だけ使えないの？

IrodoriIrodori

はい。契約の対象範囲が違います。全員で使う手順は、同じ提供条件で揃えておくと後が楽です。

全社の作業手順は、当面テキストで指示・確認できる形にしておくと、Voice Mode の提供範囲に左右されません。音声入力だけが目的なら、リリースノートが Voice Mode と別に挙げているディクテーション (Chat: Dictate) の提供条件と、社内での利用可否を確認するのがよいでしょう。

Agents ウィンドウで Issue / PR の詳細を開く

同じリリースには、GitHub の Issue / PR の詳細を Agents ウィンドウで開く experimental 機能も含まれます。既定の VS Code プロファイルに GitHub Pull Requests 拡張をインストールし、次の設定を有効にします。

{
  "extensions.experimental.enableAgentsWindowCapability": true
}

チャット中の github.com の Issue / PR リンクを選ぶと詳細を開けます。対象リポジトリのワークスペースを開いていなくても利用できる点も、公式リリースノート に記載されています。

トリアージ結果を読む担当者にとっては、根拠となる Issue を同じ画面で確認するための補助になります。この設定を、自動投稿や PR 承認を許可する設定と取り違えないようにしてください。

定期実行の頻度は、担当者が確認できる間隔で決める

チームで先に決めたいのは、誰がどの成果物をいつ読むかです。担当者が毎朝しか確認しない作業を毎時実行しても、未確認の結果が積み重なるおそれがあります。

運用台帳には、タスクの目的、対象リポジトリ、実行間隔、確認担当者、停止・再実行の手順を残してください。レビュー経路も、要約を会話で読むだけなのか、変更案を PR として確認するのかをタスクごとに決めます。

失敗の検知と費用の確認は、製品が自動で通知すると仮定せずに設計します。評価時に利用できる記録や通知を確かめ、通知が足りなければ担当者の点検を手順に含めてください。費用の確認先と、想定を超えたときに停止を判断する人も決めておきます。

チームに共通の設定を配り、利用範囲を揃える考え方は Cursor のチーム導入手順 でも扱っています。製品が違っても、個人の設定だけでチーム全体の運用を決めない点は共通です。

移行候補を選び、手動の確認から始める

まず既存の定期タスクから、日次の要約など、成果物を人が確認して採用する用途を選んでください。必要な実行条件を満たすことを確かめてから移せば、自作の仕組みを一度に撤去する必要はありません。

導入の判断記録には、採用した機能だけでなく、未確認のため保留した条件も残します。製品の提供条件が更新されたときに、どの判断を見直せばよいかが明確になります。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、AI 開発ツール導入支援 を提供しています。既存の自動化をどこまで置き換えるか、チームの確認手順をどう揃えるかは、お問い合わせ からご相談ください。