Copilot CLIの新しいターミナルインターフェースは、従来よりも「GitHub上のIssueやPull Requestを見ながら、その場でCopilotに作業を依頼しやすくなった」点が大きな変更です。2026年6月24日時点で確認できる公式情報では、GitHub Changelogに2026年6月23日付の「Release」として掲載され、タブ表示、ターミナル内での設定、アクセシビリティ改善が主なポイントとして案内されています。(The GitHub Blog)
特に迷いやすいのは、「どこで設定するのか」「IssueやPull Requestのタブが表示されないのはなぜか」「MCPやSkills、Pluginsは何を触ればよいのか」「権限許可をどこまで緩めてよいのか」という部分です。結論から言うと、まずは通常の作業リポジトリ内でCopilot CLIを起動し、/settings、/mcp、/skills、/pluginの4つを覚えるだけで基本操作はかなり整理できます。権限まわりは便利さより安全性を優先し、最初から--allow-allや/yoloを常用しないのが実務では無難です。
Copilot CLI: New terminal interface is generally available の使い方・設定で迷うポイント
Copilot CLIは、GitHub Copilotをターミナルから使うためのインターフェースです。エディター内の補完機能とは違い、コマンドライン上でコードベースを読み、ファイル変更やコマンド実行を含む作業をCopilotに依頼できます。
今回一般提供された新しいターミナルインターフェースでは、対話画面の上部にタブが表示されるようになりました。通常の会話を行うSessionタブに加え、GitHubリポジトリ内で起動している場合はIssues、Pull requests、個人のGistを扱うGistsタブをターミナル内で切り替えられます。(GitHub Docs)
これにより、ブラウザでIssueを探して番号をコピーし、ターミナルに戻ってプロンプトへ貼り付ける、といった往復が減ります。IssueやPull Requestを選び、参照としてプロンプトへ入れたうえで「このIssueの原因を調べて」「このPull Requestをレビューして」「この修正案を実装して」と依頼できるのが実用上のメリットです。
まず押さえたい新インターフェースの変更点
| 変更点 | できること | 迷いやすいポイント |
|---|---|---|
| タブ表示 | Session、Issues、Pull requests、Gistsを切り替えられる | IssuesとPull requestsはGitHubリポジトリ内で起動したときに表示される |
| GitHub項目の参照 | IssueやPRを選び、プロンプトに参照として入れられる | どのキーで操作するかを最初に覚える必要がある |
| ターミナル内設定 | MCP、Skills、Plugins、Settingsを画面内で操作できる | 従来のように設定ファイルを直接編集する場面と混同しやすい |
| アクセシビリティ改善 | テーマ、狭いターミナル対応、スクリーンリーダー対応が強化 | 表示が見づらい場合は/themeを試す |
| 更新方法 | copilot updateで更新できる | 古いCLIのままだと新UIが使えない可能性がある |
GitHub Changelogでは、タブ付きレイアウト、ツール設定の新しい体験、よりクリーンでアクセシブルな画面が新インターフェースの柱として説明されています。更新はターミナルでcopilot updateを実行する形で案内されています。(The GitHub Blog)
Copilot CLIを使う前に確認したい前提条件
Copilot CLIでつまずく人の多くは、操作方法よりも「利用条件」と「組織ポリシー」で止まります。個人利用と会社アカウント利用では確認すべき場所が変わるため、最初に切り分けておきましょう。
個人利用で確認すること
個人で使う場合は、まず有効なGitHub Copilotサブスクリプションがあるかを確認します。公式ドキュメントでは、Copilot CLIはすべてのCopilotプランで利用できると説明されています。(GitHub Docs)
インストール方法は複数あります。WindowsならWinGet、macOSやLinuxならHomebrew、全プラットフォーム共通ではnpmが選択肢になります。npmで入れる場合はNode.js 22以降が前提です。(GitHub Docs)
npm install -g @github/copilotWindowsでは、公式ドキュメント上でPowerShell v6以上が前提として示されています。Windows標準の古いWindows PowerShellだけを使っている環境では、PowerShellのバージョン確認から始めると安全です。(GitHub Docs)
組織・会社アカウントで確認すること
会社のGitHub OrganizationやEnterpriseでCopilotを使っている場合、ユーザー本人がCopilotライセンスを持っていても、管理者がCopilot CLIを無効化していると利用できません。公式ドキュメントでも、OrganizationやEnterpriseからCopilotを受け取っている場合は、組織側のCopilot CLIポリシーが有効である必要があると説明されています。(GitHub Docs)
導入前に管理者へ確認したい項目は次の通りです。
| 確認項目 | 確認する相手 | 理由 |
|---|---|---|
| Copilot CLIの利用可否 | GitHub管理者 | 組織ポリシーで無効化されていると使えない |
| 利用できるCopilotプラン | 管理者または請求担当 | AI Creditsや利用制限の把握が必要 |
| リポジトリへの権限 | リポジトリ管理者 | Issue、PR、コード参照に権限が影響する |
| 外部URLアクセスの扱い | セキュリティ担当 | URL取得やMCP利用時に社内ルールと衝突しやすい |
| 自動実行コマンドの許可範囲 | 開発責任者 | rm、git push、デプロイ系コマンドは事故につながりやすい |
特にBusinessやEnterprise環境では、「インストールできたが動かない」「ログインできたが機能が一部使えない」という状態が起こりがちです。この場合、CLI側だけでなくGitHub側の組織ポリシーも確認してください。
インストールとログインで迷いやすいポイント
Copilot CLIの導入は、大きく分けると「インストール」「認証」「作業ディレクトリで起動」の3段階です。
基本の流れ
| 手順 | 操作例 | 確認ポイント |
|---|---|---|
| インストール | winget install GitHub.Copilot、brew install copilot-cli、npm install -g @github/copilot | OSや社内端末の制約に合う方法を選ぶ |
| 初回起動 | copilot | ターミナル上で対話セッションを開始する |
| 認証 | /loginまたはcopilot login | ブラウザでGitHubアカウント認証を行う |
| 作業場所へ移動 | cd your-repository | IssueやPRタブを使うならGitHubリポジトリ内で起動する |
| 更新 | copilot update | 新UIが出ない場合は更新を確認する |
認証方法は、対話的に使うならOAuth device flowが基本です。Copilot CLI内で/loginを実行するか、ターミナルからcopilot loginを実行して、表示される手順に従います。CI/CDやコンテナなど非対話環境では、環境変数でトークンを渡す方法が案内されています。(GitHub Docs)
「ログインしたのに別アカウントで動く」場合
Copilot CLIは、認証情報を複数の場所から探します。公式ドキュメントでは、COPILOT_GITHUB_TOKEN、GH_TOKEN、GITHUB_TOKENなどの環境変数が、保存済みOAuthトークンより優先されることが説明されています。(GitHub Docs)
そのため、別ツール用にGH_TOKENを設定している環境では、意図しないアカウントや権限でCopilot CLIが動くことがあります。会社用と個人用のGitHubアカウントを切り替えている人は、次の順で確認すると原因を見つけやすくなります。
echo $COPILOT_GITHUB_TOKEN
echo $GH_TOKEN
echo $GITHUB_TOKENWindows PowerShellでは次のように確認します。
$env:COPILOT_GITHUB_TOKEN
$env:GH_TOKEN
$env:GITHUB_TOKEN意図しないトークンが設定されている場合は、シェルの設定ファイルやCIの環境変数を確認してください。
新しいタブ表示の使い方
新インターフェースの中心はタブです。GitHub Docsでは、Gitリポジトリ内の対話セッションでは、標準でSession、Issues、Pull requests、Gistsの4つのタブが表示されると説明されています。一方、GitHubリポジトリ以外のディレクトリではSessionとGistsのみになります。(GitHub Docs)
タブが表示されない・少ないときの確認
| 症状 | よくある原因 | 対処 |
|---|---|---|
| Issuesタブがない | GitHubリポジトリ外で起動している | cdで対象リポジトリへ移動してから起動する |
| Pull requestsタブがない | 同上、または権限不足 | リポジトリ権限とGitHubログイン状態を確認する |
| タブクリックが効かない | ターミナルのマウス操作が無効 | キーボード操作を使うか、マウスサポート設定を確認する |
| 画面が崩れる | ターミナル幅が狭い、フォント表示の問題 | 画面幅を広げる、/themeで見やすいテーマを選ぶ |
| 最新UIにならない | Copilot CLIが古い | copilot updateを実行する |
基本操作はシンプルです。Tabで次のタブへ、Shift + Tabで前のタブへ移動できます。Issue、Pull Request、Gistの一覧では上下キーで項目を選び、Enterで詳細表示、Escで戻る、oでGitHub.com上の該当項目を開けます。(GitHub Docs)
GitHub Changelogでは、選択したIssueやPull Requestに対してcを押すと、その参照をプロンプトへ挿入できると説明されています。これにより、選んだ項目をもとにCopilotへ調査、修正、コメント、レビューを依頼できます。(The GitHub Blog)
実務で使いやすいプロンプト例
Issueを選んで参照を入れたあと、次のように依頼すると具体的な作業につながりやすくなります。
このIssueの内容を読み、原因として考えられる箇所を3つに絞って説明してください。まだファイルは変更しないでください。このIssueを修正するための実装方針を提案してください。影響範囲、変更ファイル、テスト方針も含めてください。このPull Requestをレビューしてください。重大度の高い指摘、改善提案、確認すべきテストを分けてください。最初から「修正して」と依頼するより、まず調査や方針出しをさせるほうが安全です。特に既存システムや本番影響があるリポジトリでは、Copilotにコードを書かせる前に、変更対象とリスクを言語化させましょう。
設定場所はどこか：/settings、/mcp、/skills、/pluginを使い分ける
今回のアップデートで初心者にとって分かりやすくなったのが、設定操作です。GitHub Changelogでは、MCPサーバー、Skills、Plugins、Settingsをターミナルセッション内で設定できるようになり、手作業で設定ファイルを編集する必要が減ったと説明されています。(The GitHub Blog)
よく使うスラッシュコマンド
| コマンド | 主な用途 | 使う場面 |
|---|---|---|
/settings | 設定画面を開く | タブ表示、動作設定、全体設定を確認したい |
/mcp add | MCPサーバーを追加する | 外部ツールや社内ツールと連携したい |
/mcp search | GitHub MCP Registryから探す | 利用可能なMCPサーバーを一覧から選びたい |
/skills | Skillsのオン・オフを切り替える | 特定技術や作業向けの補助能力を使いたい |
/plugin | Pluginを参照・インストールする | マーケットプレイス、リポジトリ、ローカルパスから拡張したい |
/theme | 表示テーマを変更する | 色が見づらい、コントラストを上げたい |
/feedback | フィードバック送信 | 不具合や改善要望を伝えたい |
GitHub Changelogでは、/mcp addで対話フォームを使ってMCPサーバーを追加でき、/mcp searchでGitHub MCP Registryから探してインストールできると説明されています。Skillsは/skillsで個別にオン・オフでき、Pluginsは/pluginコマンドでマーケットプレイス、リポジトリ、ローカルパスから導入できます。(The GitHub Blog)
MCP、Skills、Pluginsの違い
名前が似ているため混乱しやすいですが、役割は分けて考えると理解しやすくなります。
| 種類 | ざっくり言うと | 例 |
|---|---|---|
| MCPサーバー | Copilot CLIに外部ツールやデータへアクセスする手段を追加する仕組み | GitHub、社内API、ドキュメント検索、チケット管理 |
| Skills | 特定作業の進め方、知識、スクリプト、リソースをまとめた補助セット | テスト作成、コードレビュー、特定フレームワーク対応 |
| Plugins | CLIの機能を拡張する追加部品 | マーケットプレイスやリポジトリから追加する拡張 |
最初から全部を入れる必要はありません。導入直後は、標準機能だけでIssue調査、PRレビュー、README更新、小さなリファクタリングを試し、必要が出てからMCPやSkillsを追加するのがおすすめです。
権限設定で失敗しやすいポイント
Copilot CLIは、ファイル変更やコマンド実行を扱えるため、権限設定が重要です。便利にしようとして許可範囲を広げすぎると、意図しないファイル変更や危険なコマンド実行につながります。
公式ドキュメントでは、Copilot CLIがアクセスできる場所や実行できる操作を制御する設定として、信頼済みディレクトリ、許可ツール、パス権限、URL権限が説明されています。(GitHub Docs)
信頼済みディレクトリは慎重に選ぶ
Copilot CLIを起動すると、そのディレクトリ配下のファイルを信頼するか確認されます。現在のセッションだけ信頼するか、今後のセッションでも信頼するかを選べます。公式ドキュメントでは、将来も安全な場所だと確信できる場合のみ、今後のセッションでも信頼する選択をすべきだと説明されています。(GitHub Docs)
実務では、次の基準で判断すると安全です。
| ディレクトリ | 信頼判断 | 理由 |
|---|---|---|
| 自分が管理する検証用リポジトリ | 信頼しやすい | 失敗しても戻しやすい |
| 本番サービスの主要リポジトリ | 慎重に判断 | 変更範囲を限定し、レビュー前提にする |
| 複数プロジェクトを含む親フォルダ | 避ける | 想定外のプロジェクトまで対象になる可能性がある |
| ダウンロードフォルダ | 避ける | 出所不明ファイルが混在しやすい |
| 秘密情報を含む設定ファイル群 | 原則避ける | APIキーや認証情報の露出リスクがある |
永続的に信頼したディレクトリは、config.json内のtrustedFoldersで管理されます。標準ではmacOS/Linuxが~/.copilot/config.json、Windowsが$HOME\.copilot\config.jsonです。(GitHub Docs)
ツール許可は「今回だけ」から始める
Copilot CLIがtouch、chmod、node、sedなどのツールを使う必要がある場合、初回は実行を許可するか確認されます。公式ドキュメントでは、許可の選択肢として「今回だけ許可」「現在のセッション中はそのツールを許可」「拒否して別の方法を指示」が説明されています。(GitHub Docs)
初心者やチーム導入初期では、原則として「今回だけ許可」を選ぶのが安全です。セッション中ずっと許可すると、たとえば一度rmを許可したあと、同じセッション内で別のrmコマンドが確認なしに実行される可能性があります。公式ドキュメントでも、rm ./this-file.txtをセッション中許可した場合、同じセッション中に別のrmコマンドを実行できる例が示されています。(GitHub Docs)
--allow-allや/yoloは常用しない
Copilot CLIには、すべてのツール、パス、URLを許可する--allow-allや別名の--yoloがあります。これは--allow-all-tools、--allow-all-paths、--allow-all-urlsをまとめて有効にするものです。(GitHub Docs)
検証用の使い捨てリポジトリで動作確認するなら便利な場面もありますが、通常業務のリポジトリでは常用しないほうがよい設定です。特に次のような環境では避けてください。
- 本番環境へデプロイできるコマンドが実行可能な端末
- 秘密情報や
.envファイルを含むリポジトリ - 顧客データや個人情報を扱うプロジェクト
git pushやリリース操作が端末から実行できる環境- 社内ネットワークや外部URLアクセスに制限がある環境
便利さを優先したい場合でも、--allow-allではなく、--deny-tool='shell(git push)'や--deny-tool='shell(rm)'のように危険な操作を明示的に拒否するほうが現実的です。公式ドキュメントでも、--deny-toolは--allow-all-toolsや--allow-toolより優先されると説明されています。(GitHub Docs)
IssueやPull RequestをCopilot CLIで扱う実践例
新しいターミナルインターフェースを使うと、IssueやPull Requestを起点にした作業が進めやすくなります。ここでは、実務で使いやすい流れを紹介します。
Issueから修正方針を作る
まず対象リポジトリへ移動します。
cd your-repository
copilotIssuesタブを開き、対象Issueを選びます。参照をプロンプトへ入れたら、いきなり修正させるのではなく、まず方針を出させます。
このIssueの内容を整理し、再現条件、原因候補、修正方針、確認すべきテストを分けて説明してください。まだファイルは変更しないでください。方針が妥当なら、次に小さな単位で実装を依頼します。
提案された方針のうち、最小限の修正で対応できる案を実装してください。変更前に対象ファイルと変更理由を一覧で示してください。このように段階を分けると、Copilot CLIが大きすぎる変更を一度に行うリスクを下げられます。
Pull Requestをレビューする
Pull requestsタブから対象PRを選び、次のように依頼します。
このPull Requestをレビューしてください。仕様不整合、テスト不足、可読性、後方互換性の観点で確認し、重大度をHigh/Middle/Lowで分類してください。レビュー結果をそのまま採用するのではなく、最終判断は人間が行います。Copilot CLIは見落としを減らす補助役として使い、マージ判断や仕様判断は担当者が確認する運用にしましょう。
Gistを作業メモとして活用する
Gistsタブは、個人のGistを参照する用途に使えます。たとえば、よく使う調査手順、社内で許可されたプロンプトテンプレート、検証メモをGistにまとめておくと、ターミナルから参照しやすくなります。
ただし、Gistに秘密情報、社内限定情報、顧客情報を置くのは避けてください。Gistの公開範囲や社内ルールを確認したうえで使うことが重要です。
表示が見づらいときは/themeを確認する
新インターフェースでは、テーマ対応やアクセシビリティ改善も含まれています。GitHub Changelogでは、/themeコマンドでdefault、dim、high-contrast、colorblindなどのカラーモードを選べること、スクリーンリーダー検出時のサポートが説明されています。(The GitHub Blog)
ターミナル環境によっては、背景色や文字色の組み合わせで読みにくくなることがあります。特にダークテーマ、リモートSSH、Windows Terminal、VS Code統合ターミナルを使い分けている場合は、同じ表示設定でも見え方が変わります。
見づらい場合は、まず次を試してください。
/themeおすすめは、長時間作業するならhigh-contrastを試すことです。Issue一覧やPR一覧をターミナル内で読み続ける場合、コントラストが低いと選択中の項目や警告表示を見落としやすくなります。
Copilot CLIと他のCopilot機能の使い分け
Copilot CLIは便利ですが、すべての作業を置き換えるものではありません。GitHub Copilot Chat、エディター補完、GitHub上のCopilot機能と役割を分けると使いやすくなります。
| 用途 | 向いている機能 | 理由 |
|---|---|---|
| コードを書きながら補完を受ける | エディター内Copilot補完 | 入力中のコードに自然に追従する |
| ファイルを見ながら質問する | Copilot Chat | 会話形式で理解を深めやすい |
| IssueやPRを起点に作業する | Copilot CLI | ターミナルからGitHub項目を参照して作業しやすい |
| 複数コマンドやファイル変更を伴う作業 | Copilot CLI | コマンド実行とファイル編集をまとめて扱える |
| 最終レビューやマージ判断 | 人間によるレビュー | 仕様、責任、影響範囲の判断が必要 |
Copilot CLIの強みは、ターミナル作業の流れを止めずに、調査、修正、レビュー補助まで進められることです。一方で、コマンド実行やファイル変更を伴うため、エディター補完よりも権限管理と確認作業が重要になります。
導入時に決めておくと失敗しにくい運用ルール
チームでCopilot CLIを使う場合は、インストール手順だけでなく、使い方のルールを先に決めておくと混乱を防げます。
最低限決めたいルール
| ルール | 推奨内容 | 理由 |
|---|---|---|
| 初期権限 | 原則「今回だけ許可」 | 予期しないコマンド実行を防ぐ |
| 信頼済みディレクトリ | プロジェクト単位で設定 | 親フォルダ全体を信頼しない |
| 禁止コマンド | git push、rm、デプロイ系を慎重に扱う | 事故の影響が大きい |
| レビュー | Copilotの変更は必ず人間が確認 | 生成内容の責任は利用者側に残る |
| 秘密情報 | プロンプトやGistへ入れない | 情報漏えいリスクを避ける |
| MCP追加 | チームで承認したものだけ使う | 外部連携の範囲を管理する |
特にMCPサーバーやPluginsは、便利な反面、外部サービスや社内データへアクセスする入口になります。個人判断で増やしすぎると、チーム内で再現できない作業や、監査しづらい開発環境が生まれます。まずは標準機能で使い方を固め、必要な拡張だけを追加する流れが安全です。
よくある疑問
Copilot CLIはGitHub CLIとは別物ですか？
別物です。GitHub CLIのghはGitHub操作をコマンドラインで行うためのツールです。一方、Copilot CLIはGitHub Copilotをターミナルから使い、コード調査、ファイル編集、コマンド実行を含むAI支援を受けるためのツールです。ただし、認証ではGitHub CLIのトークンをフォールバックとして利用できる場合があります。(GitHub Docs)
Copilot CLIはVS Code以外でも使えますか？
使えます。GitHubの製品ページでは、Copilot CLIはターミナルで独立して動作し、任意のエディターで表示できるファイルを変更できるため、公式Copilot拡張がないエディターでも有用だと説明されています。(GitHub)
IssueやPull Requestのタブが出ないのは不具合ですか？
必ずしも不具合ではありません。公式ドキュメントでは、IssuesとPull requestsタブはGitHubリポジトリ内でCopilot CLIを実行している場合に表示され、それ以外のディレクトリではSessionとGistsのみが表示されると説明されています。(GitHub Docs)
BYOKを使えばGitHubログインなしで使えますか？
自分のLLMプロバイダーのAPIキーを使うBYOK構成では、GitHub認証なしで使える場合があります。ただし、/delegate、GitHub MCP server、GitHub Code Searchなど、GitHubホスト型の機能には認証が必要です。(GitHub Docs)
すべて許可する/yoloは使ってよいですか？
検証用の隔離された環境以外では慎重に扱うべきです。/yoloはツール、パス、URLの許可をまとめて広げるため、作業効率は上がりますが安全性は下がります。BusinessやEnterpriseでは管理者にブロックされる場合もあります。(GitHub Docs)
Copilot CLIを安全に使い始めるためのおすすめ手順
初めて使う場合は、いきなり本番リポジトリで大きな修正を任せるのではなく、次の順で慣れるのがおすすめです。
| 段階 | やること | ゴール |
|---|---|---|
| 1 | Copilot CLIをインストールし、/loginで認証する | 起動と認証を確認する |
| 2 | 検証用リポジトリで起動する | タブ操作と権限確認に慣れる |
| 3 | IssueやPRを参照して要約させる | 参照機能の使い方を覚える |
| 4 | 小さなREADME修正やテスト追加を依頼する | ファイル変更の承認フローを理解する |
| 5 | /settings、/theme、/skillsを確認する | 自分の環境に合わせて調整する |
| 6 | 必要になってからMCPやPluginsを追加する | 拡張を最小限に保つ |
| 7 | チーム利用ルールを決める | 権限、レビュー、外部連携を管理する |
Copilot CLIの新しいターミナルインターフェースは、単に見た目が変わっただけではありません。IssueやPull Requestをターミナル内で扱い、そのままCopilotに調査や修正を依頼できるため、GitHubを中心に開発しているチームほど効果を感じやすい変更です。
一方で、ファイル変更やコマンド実行を扱う以上、設定と権限の理解は欠かせません。まずはcopilot updateで最新版にし、GitHubリポジトリ内で起動してタブ表示を確認します。そのうえで、/settings、/mcp、/skills、/pluginを必要に応じて使い、権限は最小限から始めてください。安全な検証環境で操作に慣れてから、実務リポジトリへ広げるのが最も失敗しにくい導入方法です。
コメント