追記: 2026年6月8日の最新情報
2026年6月8日時点で、GitHub DocsにCopilot CLIのスケジュール機能の個別ドキュメントが用意されています。/everyと/afterは現在もexperimental機能で、/experimental onまたは--experimentalが必要です。さらに、スケジュールは作成したinteractive Copilot CLI sessionが動いている間だけ発火します。
そのため、夜間ジョブや毎週の依存更新のようにセッション外でも確実に動かしたい処理は、Docsの案内どおりcronやWindows Task Schedulerからcopilot -p "YOUR PROMPT"を呼ぶ設計と分けて考えるのが安全です。/everyと/afterは、CLI内での一時的なリマインドや確認に向く機能として扱うと読み違えにくくなります。
このテーマをもう少し広げて見るなら、GitHub Copilot sandboxesがpublic preview：ローカル/クラウド実行、権限、課金の確認ポイント と GitHub CopilotのEnterprise-managed pluginsがVS Codeでpublic preview：MCP、hooks、skillsを企業で標準化する確認ポイント も合わせて確認してください。Copilot CLIから実行環境を切り分けるlocal/cloud sandboxの条件を続けて確認できるため。
GitHub Copilot CLIは、Microsoft Build 2026に合わせて目立つ更新が出た開発者向けCopilot機能です。ターミナルの中でエージェント作業を続ける人にとっては便利な話ですが、今回の発表は「すべてが今すぐ本番運用で使える」という意味ではありません。
特に注意したいのは、Rubber Duckと音声入力は一般提供として案内されている一方で、prompt schedulingと新しいterminal UIは/experimentalで試す段階に分かれていることです。2026年6月3日のGitHub ChangelogのEditor noteでは、prompt schedulingがexperimentalである点が訂正されています。
この記事では、GitHub公式のChangelogとDocs、Microsoft公式ブログをもとに、開発者と管理者がCopilot CLIを試す前に見るべき条件を整理します。Microsoft Watch JapanはMicrosoftおよび関係会社とは非提携の独立ブログであり、この記事は製品・サービスの確認ガイドであって投資助言ではありません。
3行まとめ
計画、設計、実装、テストへの批評を返す補助として扱えます。
英語またはスペイン語のプロンプト入力を楽にする機能です。
/every、/after、新しいterminal UIは/experimentalで試す段階です。
Copilotプラン、組織ポリシー、Node.js 22以上、インストール経路を確認します。
機能名だけで判断せず、一般提供かexperimentalかを先に分けて読むのが安全です。
- GitHub Copilot CLIはBuild 2026で、Rubber Duck、音声入力、prompt scheduling、新terminal UIを中心に刷新された。
- Rubber Duckと音声入力は一般提供、
/everyと/afterによるprompt schedulingと新terminal UIは/experimentalで試す機能として分けて読む必要がある。 - 導入前には、Copilotプラン、組織側のCopilot CLIポリシー、Node.js 22以上、インストール経路、音声入力の対応言語、セッション内スケジュールの制約を確認したい。
最初に見るべきなのは、機能名よりも「どの状態で提供されているか」です。GitHub Changelogは2026年6月2日にCopilot CLIの大きな刷新を発表し、Rubber Duckと音声入力を一般提供、prompt schedulingと新terminal UIを/experimentalで試せる機能として説明しています。
この違いを曖昧にすると、試験導入の範囲を誤ります。Rubber Duckは、計画や実装への批評を返す補助として扱えます。音声入力は、英語またはスペイン語のプロンプト入力を楽にする機能です。一方、/everyや/afterでプロンプトを後から実行する仕組みは、現時点では通常のCI、cron、タスクスケジューラの代替として見ない方が安全です。
すでにBuild 2026全体の動きを追っている読者は、まず<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月のMicrosoft重要トピックまとめ</a>と合わせて読むと、GitHub Copilot app、Windows側のAI基盤、Azure側のエージェント発表との位置づけが見えやすくなります。
Build 2026でCopilot CLIは何が変わったか
- 1認証と信頼確認
/loginで認証し、対象ディレクトリを信頼してよいか確認します。
- 2質問と計画
プロジェクトの概要を聞き、作業の進め方を相談します。
- 3実行と確認
テスト、差分、GitHub workflowに関係する作業をターミナル内で扱います。
- 4批評と入力補助
Rubber Duckや音声入力により、レビュー視点と入力しやすさが加わります。
IDEやGitHub Web上のCopilot機能と同一視せず、ターミナルで作業を続けるための機能として見ると整理しやすくなります。
今回のCopilot CLI更新は、ターミナルを単なるコマンド実行場所ではなく、エージェント作業の入口にする動きです。Microsoft Build 2026ではGitHub Copilot appやCopilot SDKなど、開発作業をエージェント化する発表が複数並びました。その中でCopilot CLIは、開発者がローカルのプロジェクトにいるまま、質問、計画、実行、確認を進めるための道具として扱われています。
発表の中心はCLI内の作業継続
GitHub Docsは、Copilot CLIをterminal-nativeなAI coding assistantとして説明しています。インタラクティブなCLI sessionを起動し、/loginで認証し、対象ディレクトリを信頼してよいか確認したうえで、プロジェクトの概要を聞いたり、作業を依頼したりする流れです。
ここで重要なのは、Copilot CLIがIDEやGitHub Web上のCopilot機能と完全に同じ体験ではないことです。IDEの補完やチャットは編集中のコードに近く、GitHub Copilot appは複数のagent sessionsをデスクトップ上で扱う体験に寄っています。Copilot CLIは、ターミナルでテスト、Git操作、依存関係確認、GitHub workflowの把握をしている開発者が、その場でAI agentに相談するための面です。
Build 2026のGitHub Copilot appについては、すでに<a href="https://msft-watch.blog.mo-gmo.com/msft-18-github-copilot-app-preview-build-2026/" rel="noopener">GitHub Copilot app preview拡大の記事</a>で、キャンバス、サンドボックス、複数sessionの確認ポイントを整理しています。本稿ではそこへ踏み込みすぎず、CLIの中で変わる点に絞ります。
新terminal UIはexperimental扱い
GitHub Changelogでは、新しいterminal interfaceも紹介されています。Issue、Pull request、Gistをタブで見られること、色モードやアクセシビリティ面の改善、狭いターミナルでも情報が読めるようにする表示改善が挙げられています。
ただし、この新terminal UIは/experimental modeで試す機能です。通常運用へ入れる前に、チームで使っているterminal、スクリーンリーダー、キーバインド、狭い画面での表示、社内標準の色設定とぶつからないかを確認する必要があります。
見た目の刷新に見えても、実際には開発者の作業導線に関わります。IssueやPull requestをCLI内で見られるようになると、ブラウザとターミナルの往復は減ります。一方で、レビュー、承認、監査ログ、コメント履歴の確認をどこで正式に行うかは、従来のGitHub運用と切り分けておくべきです。
ChangelogとDocsを両方見る理由
発表記事は、何が新しく出たかを理解するには便利です。けれども、導入判断に必要な制約はDocs側に分かれて書かれます。今回のように、発表直後にEditor noteで扱いが修正されることもあります。
根拠として見る一次情報
そのため、本稿ではGitHub Changelogを発表の起点として使い、GitHub Docsで利用条件、インストール、音声入力、スケジュール実行、Rubber Duckの実際の制約を確認しています。記事公開後も、experimental機能の扱いは変わる可能性があるため、読者自身も導入前にDocsを再確認してください。
使う前に確認するプラン、ポリシー、インストール条件
個人利用と組織利用では確認先が変わるため、ユーザー任せの試用にする前に利用範囲を決めておく必要があります。
Copilot CLIを試す前に、まず利用条件を片付ける必要があります。新機能の評価に入る前に、個人利用なのか、組織からCopilotを付与されているのかで確認先が変わります。
利用できるプランと組織ポリシー
GitHub Docsは、GitHub Copilot CLIがすべてのCopilotプランで利用可能だと説明しています。ただし、組織からCopilotを受け取っている場合は、組織設定でCopilot CLI policyが有効になっている必要があります。
個人開発者は、自分のCopilotプランとGitHubアカウントでCLIを使えるかを確認します。企業やチームの場合は、管理者が「どの組織、どのチーム、どのリポジトリでCopilot CLIを使ってよいか」を先に決める必要があります。特に機密情報を含むリポジトリ、顧客データを扱うリポジトリ、規制対象のプロジェクトでは、ユーザー任せの試用にしない方がよいでしょう。
インストール経路とNode.js 22以上
インストール経路は複数あります。GitHub Docsは、npm、WinGet、Homebrewを案内しています。npmで入れる場合はNode.js 22以上が前提です。WindowsではWinGet、macOSとLinuxではHomebrewという経路も示されています。
確認項目
導入前チェックは、次の順に進めると迷いにくくなります。
| 確認項目 | 個人開発者 | 組織利用の管理者 |
|---|---|---|
| Copilotプラン | 自分のアカウントで使えるか確認する | 対象ユーザーにライセンスがあるか確認する |
| Copilot CLI policy | 自分の環境では該当しない場合が多い | 組織設定で有効か確認する |
| Node.js | npm利用なら22以上か確認する | 標準配布するruntimeを決める |
| インストール経路 | npm、WinGet、Homebrewから選ぶ | OS別の標準手順を決める |
| 対象ディレクトリ | 自分が信頼できるprojectだけで起動する | 利用可能なrepoと禁止repoを明確にする |
この段階で重要なのは、Copilot CLIを「便利そうだから各自で入れる」扱いにしないことです。開発者のローカル環境で動くCLIであっても、扱うコード、プロンプト、出力、ファイル変更の承認はチームの開発プロセスに影響します。
初回起動時のログインと信頼ディレクトリ
GitHub Docsのquickstartでは、プロジェクトディレクトリに移動し、copilotでinteractive CLI sessionを起動し、/loginでGitHubアカウントに認証する流れが示されています。初回には、現在のディレクトリ内のファイルをAI toolで使うのに適しているか、信頼してよいかを確認します。
Docsは、Copilotが明示的な承認なしにファイル変更を行わないとも説明しています。これは安心材料ですが、同時に「何を承認したか」を人間が理解できている必要がある、という意味でもあります。テストを走らせる、差分を作る、依存関係を触る、外部コマンドを使う可能性がある作業では、承認画面だけでなく、チーム側のルールも必要です。
Rubber Duckは何をして、何をしないのか
- 1見る
メインのCLI agentが作った計画、設計、実装、テストを確認します。
- 2指摘する
設計上の問題、バグ、ロジックエラー、セキュリティ上の弱点、性能上の懸念、テスト不足を探します。
- 3変えない
ファイル編集や環境を変更するコマンド実行は行わず、read-onlyの批評役として動きます。
- 4戻す
指摘を採用するかどうかは、メインのCLI agentとユーザーの承認に戻ります。
人間レビューの代替ではなく、非自明な変更やテスト方針が曖昧な場面で見落としを減らす補助として扱うのが現実的です。
今回の更新で一番誤解されやすいのがRubber Duckです。名前の印象は柔らかいですが、実態はCopilot CLIの中で動く批評役です。メインのCLI agentが作った計画、設計、実装、テストを見て、盲点や実質的な問題を指摘します。
批評役であって実行役ではない
GitHub Docsは、Rubber Duckをbuilt-in criticとして説明しています。メインのCLI agentから現在の作業内容を渡され、設計上の問題、バグ、ロジックエラー、セキュリティ上の弱点、性能上の懸念、テスト不足などを見つけ、具体的な修正案を返します。
大事なのは、Rubber Duckがファイルを編集するagentではないことです。Docsでは、Rubber Duckはread-onlyでコードベースを探索し、環境を変更するコマンドを実行しないとされています。最終的にフィードバックをどう扱うかは、メインのCLI agentとユーザーの承認に戻ります。
この性質は、人間レビューの代替というより、実装前後の見落としを減らす補助と考えるとわかりやすいです。特に複数ファイルにまたがる変更、設計判断を伴う変更、テスト方針が曖昧な変更では、別視点の批評が効きます。
自動で呼ばれる場面と手動で呼ぶ場面
Rubber Duckは、Copilot CLI側が有効だと判断した場面で自動的に使われることがあります。Docsでは、非自明な変更の計画後、複雑な実装の途中、テスト作成後、失敗が続く場面などが例示されています。
手動で使うこともできます。たとえば、作業計画を出させた後に「この計画を批評して」と頼む、または/rubber-duckを使って不足しているエッジケースを見てもらう、といった使い方です。
この機能をpilotに入れるなら、チーム内では「Rubber Duckの指摘をどう扱うか」を決めておくとよいでしょう。blocking issueとして返されたものは必ず確認する、non-blockingはPRコメントで扱う、suggestionは必要に応じて採用する、というように粒度を決めておくと、AIの批評が雑音になりにくくなります。
モデル利用と待ち時間も評価に入れる
Docsによると、Rubber Duckはメインのsessionを動かしているモデルとは別のAI modelを使う設計です。別モデルで批評することで、同じ盲点を共有しにくくする狙いがあります。ただし、Rubber DuckはメインagentがClaudeまたはGPTのlarge language modelを使っている場合に限られるとも説明されています。
評価基準
また、Rubber Duckの利用は追加の推論パスを伴います。つまり、待ち時間やモデル利用が増える可能性があります。小さなtypo修正や単純なファイル名変更にまで毎回期待する機能ではありません。効果が出るのは、失敗したときの手戻りが大きい作業です。
音声入力はどこまで実用に入れられるか
現在示されている対応言語は英語とスペイン語です。
文字起こしはローカルマシン上で行われ、録音した音声はネットワークに送信されないと説明されています。
文字起こし後のテキストは送信前に編集できますが、送信すればCopilot CLIへの入力になります。
短い入力は押しながら話し、長い入力は録音モードを切り替えて使います。
音声がローカル処理でも、文字起こし後のプロンプトに機密情報を含めるかは別の判断として扱います。
音声入力は一般提供として案内されている機能です。ただし、日本語読者にとっては、ここでも扱いを分ける必要があります。音声入力そのものは便利ですが、GitHub Docsが現在示している対応言語は英語とスペイン語です。
音声はローカルで文字起こしされる
GitHub Docsは、Copilot CLIのvoice inputについて、音声の文字起こしがローカルマシン上で完結し、録音した音声はネットワークに送信されないと説明しています。文字起こしされたテキストは、プロンプト入力欄のカーソル位置に挿入され、送信前に編集できます。
この説明で分けたいのは、音声データとプロンプト文です。録音音声はローカル処理でも、文字起こし後に送信するプロンプトはCopilot CLIに渡す入力です。機密情報を口頭で読み上げてプロンプト化する運用は、音声がローカル処理かどうかとは別に慎重に扱う必要があります。
操作方法と対応言語
操作は二つあります。短いプロンプトではspace barを押し続けて話し、離すと文字起こしが入力欄に入ります。長いプロンプトではCtrl+Xに続けてVを押し、録音を開始し、任意のキーで停止して文字起こしを挿入します。
初回利用時には、/voice slash commandからvoice runtimeとvoice modelをダウンロードします。英語が既定のspeech recognitionで、スペイン語で使う場合はvoice models pickerからSpanish speech-to-text modelを選ぶ流れです。
対応言語の注意点
現時点で、日本語の口述入力を前提に記事化するのは危険です。日本語チームで試すなら、英語の短い指示を音声で入れる、アクセシビリティ上の入力補助として評価する、定型的な英語プロンプトを声で入れる、といった限定的な使い方から見るのが現実的です。
日本語チームでの運用注意点
日本語の会話をそのままCopilot CLIへ話しかける使い方は、少なくとも公式Docs上の対応言語からは確認できません。日本語での精度を前提にした研修、社内手順、チーム標準を作る前に、GitHub Docsの対応言語とモデル選択画面を再確認してください。
また、声に出すプロンプトは周囲に聞こえます。オフィスや共有スペースでは、リポジトリ名、顧客名、障害内容、未公開機能名を不用意に読み上げない運用も必要です。音声入力は「手が空く」機能ですが、情報の扱いまで軽くなるわけではありません。
/everyと/afterを自動実行としてどう扱うか
- 2026年6月3日の修正
Editor noteにより、prompt schedulingは/experimentalの一部であり一般提供ではないことが明確になりました。
- /experimentalを有効化
試す場合は、通常作業とは分けてexperimental機能として有効にします。
- /every
指定した間隔でプロンプトを繰り返し送るslash commandです。
- /after
指定した時間が経った後に、一度だけプロンプトを送ります。
- 運用との線引き
開いているCLIセッション内の補助として見て、CIやcronの代替にはしません。
自動化に見えても、常駐ジョブや本番運用のスケジューラとは別物として評価するのが安全です。
prompt schedulingは便利に見えますが、ここは最も線引きが必要な部分です。GitHub Changelogは2026年6月3日のEditor noteで、prompt schedulingが/experimentalの一部であり、一般提供ではないことを明確にしています。GitHub Docsのschedule promptsページでも、/everyと/afterはexperimentalで、/experimental onまたは--experimentalが必要だと説明されています。
繰り返し実行と一回限りの遅延実行
/everyは、指定した間隔でプロンプトを繰り返し送るslash commandです。たとえば、一定時間ごとにテスト結果を確認して要約する、open pull requestsへの新しいコメントを確認する、といった使い方が考えられます。
/afterは、指定した時間が経った後に一度だけプロンプトを送ります。作業から少し時間を置いてREADMEの変更を確認する、数分後に特定画面の表示を確認する、といった用途です。
ただし、これらは便利なメモリ機能ではなく、AI agentへプロンプトを後から送る仕組みです。何を実行させるか、どの権限で動くか、結果を誰が確認するかを曖昧にすると、思わぬ作業やコマンド実行につながる可能性があります。
experimentalで、対話セッション内に閉じる
Docsは、/everyと/afterのスケジュールが作成されたinteractive Copilot CLI sessionに紐づき、そのsessionが動いている間だけ発火すると説明しています。sessionを閉じた後も常駐して裏で動く仕組みではありません。
条件と上限
また、間隔指定には秒、分、時間、日が使え、最小間隔は10秒、最大は1日です。/everyまたは/afterを引数なしで入力するとactive schedulesを見られ、選択して削除することもできます。
導入判断では、この制約をむしろ利点として見てもよいでしょう。開いているsessionに閉じるなら、完全な無人運用に比べて監視しやすいからです。一方で、夜間バッチや定期レポートのようにsessionを開いていない状態で走らせたい用途には向きません。
外部スケジューラと分ける
Docsは、interactive sessionが開いていない状態でスケジュール実行したい場合、copilot -p "YOUR PROMPT"を外部スケジューラから呼ぶ方法へ分けています。macOSやLinuxならcron、WindowsならTask Schedulerのような外部スケジューラです。
ここは企業導入で特に重要です。外部スケジューラからAIを動かすなら、標準のジョブ管理、ログ、権限、失敗時通知、コスト監視、対象リポジトリの制限が必要になります。/everyと/afterの試用が便利だったからといって、そのまま本番の無人実行へ拡張するのは早計です。
| 比較項目 | /every | /after | 外部スケジューラ |
|---|---|---|---|
| 主な用途 | session中の定期確認 | session中の一回だけの遅延実行 | session外の定期・無人実行 |
| 状態 | experimental | experimental | Copilot CLIのprogrammatic利用とOS側設定 |
| 実行条件 | interactive sessionが開いている | interactive sessionが開いている | cronやTask Schedulerなどを別途設定 |
| 向く作業 | テスト結果やPRコメントの一時確認 | 少し後の確認や要約 | 夜間レポート、定期保守、週次確認 |
| 注意点 | 監視なしの反復実行にしない | 忘れた頃の実行内容を確認する | ログ、権限、失敗時通知を設計する |
Copilot CLI、Copilot app、code reviewをどう使い分けるか
導入判断では、機能名ではなく作業場所、責任範囲、チームの慣れを分けて見る必要があります。
Build 2026前後は、GitHub Copilotの発表が一気に増えています。Copilot CLI、Copilot app、Copilot code reviewをまとめて「Copilotが増えた」とだけ見ると、導入判断がぼやけます。
CLIはターミナル内の作業継続に強い
Copilot CLIは、開発者がターミナルの中で作業を続けたいときに向きます。既存プロジェクトの概要を聞く、テストの失敗を整理する、差分を確認する、GitHub workflowに関係する作業を進める、といった用途です。
CLIの強みは、作業場所が変わらないことです。逆に言えば、CLIに慣れていないユーザーや、GUI中心で作業するチームには、最初の学習コストがあります。導入前には、誰がCLIで作業しているのか、どのrepositoryで使うのかを把握した方がよいでしょう。
Copilot appは複数sessionを扱う面
GitHub Copilot appは、native desktop experienceとしてpreviewが拡大した機能です。複数のagent sessions、worktrees、canvas、sandboxなど、CLIとは違う画面と管理の考え方があります。
すでにCopilot appを試している読者は、CLIを「appの代替」と見るより、ターミナル内で完結させたい作業の入口と見る方が自然です。appで複数sessionを俯瞰し、CLIで手元のprojectを深掘りする、といった併用もあり得ます。
code reviewはPRと課金の確認軸が別
GitHub Copilot code reviewは、PRレビューと費用確認の軸が強い機能です。2026年6月1日からのAI CreditsやGitHub Actions minutesの扱いは、Copilot CLIのRubber Duckとは別物として見てください。
Rubber Duckは、CLI session内でメインagentの計画や実装へ批評を返す補助です。Copilot code reviewは、PR上のレビュー、runner、Actions minutes、AI Creditsなどの確認が関わります。費用とPR運用を知りたい読者は、<a href="https://msft-watch.blog.mo-gmo.com/msft-14-github-copilot-code-review-actions-minutes/" rel="noopener">GitHub Copilot code reviewの課金変更記事</a>を先に読むと、CLI側の話と混同しにくくなります。
| 機能 | 主な場所 | 向く作業 | 先に見る制限 |
|---|---|---|---|
| GitHub Copilot CLI | Terminal | 手元のproject調査、実装、テスト確認、agent作業 | Copilot CLI policy、信頼ディレクトリ、CLI操作 |
| GitHub Copilot app | Desktop app | 複数agent sessions、canvas、sandbox | preview対象、Business/Enterprise設定、sandbox条件 |
| Copilot code review | Pull request | PRレビュー、品質確認、レビュー自動化 | AI Credits、Actions minutes、runner、budget |
開発者と管理者のpilotチェックリスト
インストール、/login、信頼できるproject directory、概要要約、既存テストの説明を確認します。
blocking issue、non-blocking、suggestionの扱いをチームで決めます。
新terminal UIやprompt schedulingは、検証用projectや低リスクの作業から始めます。
Copilot CLI policy、対象チーム、対象repository、監査しやすいルールを決めます。
pilotの目的は、便利さだけでなく、使ってよい範囲とレビューすべき指摘の扱いを先にそろえることです。
Copilot CLIを導入するなら、最初から全員に開放するより、小さなpilotで条件を確認する方が現実的です。特にexperimental機能は、通常利用とは分けて評価したいところです。
開発者が初日に試すこと
開発者側の初日は、インストールと基本操作を確認するだけで十分です。まず自分の環境でCopilot CLIを起動し、/loginで認証し、信頼できるproject directoryだけで使います。次に、プロジェクト概要の要約、既存テストの説明、Rubber Duckの手動呼び出し、音声入力の可否を確認します。
この時点で/experimentalを有効にするかは、チームで分けた方がよいでしょう。新terminal UIやprompt schedulingを試したい人は、通常作業のrepositoryではなく、検証用のprojectや低リスクの作業から始めるのが安全です。
管理者が先に決めること
管理者は、Copilot CLI policyを有効にするか、対象チームをどこまでにするか、使ってよいrepositoryと避けるrepositoryをどう分けるかを決めます。音声入力については、対応言語、録音時の周囲環境、機密情報を声に出さないルールを確認します。
prompt schedulingについては、experimentalであることを前提に、どの作業を許可するかを明示してください。テスト実行の確認、PRコメントの要約、開発メモの作成程度ならpilotに向きます。外部システムへ書き込む、顧客データを処理する、承認なしに変更を作る可能性がある用途は、別途設計が必要です。
pilotから本番導入へ進める条件
pilotの評価は、単に「便利だったか」では足りません。少なくとも次の観点を見たいところです。
- 開発者がCopilot CLIの提案を理解し、承認前に差分を確認できているか。
- Rubber Duckの批評が、実際に設計ミス、テスト不足、セキュリティ観点の抜けを減らしたか。
- 音声入力は、英語またはスペイン語のプロンプト入力として無理なく使えているか。
- experimental機能を通常作業に混ぜず、試用範囲を管理できているか。
- Copilot CLIの利用ログ、費用、組織ポリシー、対象repositoryを管理者が追えるか。
下振れリスク
本番導入へ進める条件は、チームによって違います。ただし、experimental機能を通常運用へ入れる、音声入力の対応言語を誤解する、スケジュール実行を監視なしで使う、Rubber Duckの批評を人間レビューの代替にする、という四つは避けたい下振れリスクです。
次に読むなら
Microsoft Watch Japanでは、Build 2026後のGitHub Copilot、Windows、Azure、Microsoft 365 Copilotの更新を<a href="https://msft-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>でも追います。仕様変更やexperimental機能の扱いを毎回見落としたくない場合は、読了後の補助導線として使ってください。
次に読むなら
参照した主な情報源
- GitHub Changelog, "Copilot CLI: Improved UI, rubber duck, prompt scheduling, and voice input"
Copilot CLI: Improved UI, rubber duck, prompt scheduling, and voice input
- GitHub Docs, "Getting started with GitHub Copilot CLI"
https://docs.github.com/en/copilot/how-tos/copilot-cli/cli-getting-started
- GitHub Docs, "Installing GitHub Copilot CLI"
https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli
- GitHub Docs, "Use voice input with Copilot CLI"
https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/voice-input
- GitHub Docs, "Scheduling prompts in GitHub Copilot CLI"
https://docs.github.com/en/copilot/how-tos/copilot-cli/automate-copilot-cli/schedule-prompts
- GitHub Docs, "About the rubber duck agent"
https://docs.github.com/en/copilot/concepts/agents/copilot-cli/rubber-duck
- Microsoft Official Blog, "Microsoft Build 2026: Be yourself at work"
https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/
確認日: 2026年6月4日 JST。GitHub Copilot CLIのexperimental機能、対応言語、組織ポリシー、インストール要件は変わる可能性があるため、導入前にはGitHub Docsの最新版を確認してください。