AI Tools
チュートリアル14 分2026年4月13日執筆:AIGCDev

GitHub Copilot CLI チュートリアル:2026年版 インストール、認証、安全な使い方

まず結論

今日から GitHub Copilot CLI を使い始めたいなら、最短かつ比較的安全な手順はこれです。

  1. npm install -g @github/copilot または brew install copilot-cli で Copilot CLI をインストールする。
  2. 実際に作業したいリポジトリ内で copilot を起動し、初回は /login を実行する。フォルダ信頼では、まず「このセッションのみ」を選んでから恒久的に記憶するか判断する。
  3. まずは対話モードで探索し、複数ファイルに触る前に plan mode へ切り替え、programmatic mode は狭いワンショット作業だけに使う。

最近見たチュートリアルに trusted folder、plan mode、権限設定の話が出てこなかったなら、その手順は今の GitHub の beginner guide や quickstart と比べると不十分です。今いちばん事故が起きやすいのは install コマンドではなく、初回起動時に Copilot に何を読ませ、何を触らせるかの境界です。

このチュートリアルが向いている人

このガイドは、すでにターミナル中心で作業していて、Copilot にリポジトリ調査、小さなコード変更、Git 操作、スコープの明確な自動化を任せたい一方で、マシン全体を無条件で任せたくはない開発者向けです。

次のような使い方をしたいなら、このセットアップは相性がいいです。

  • ブラウザ、IDE、シェルを行き来せず、できるだけターミナル内で完結したい
  • Copilot にリポジトリを読ませ、変更を説明させ、文脈つきでコード案を出させたい
  • Copilot がファイル編集やコマンド実行を求めたとき、承認範囲を狭く保ちたい
  • すでに終了した GitHub CLI Copilot 拡張ではなく、新しい Copilot CLI を学びたい

古いガイドを見た人は、まずこの3点だけ更新する

今の GitHub Docs では、セットアップの前提が次のように整理されています。

  • 主な入口は standalone の copilot コマンドで、About GitHub Copilot CLI では対話インターフェースと -p の programmatic interface が分けて説明されています。
  • 初回起動にはフォルダ信頼の確認があります。quickstart と usage guide には、そのセッション中 Copilot がそのフォルダ以下のファイルを読み、変更し、実行できると書かれています。
  • plan mode と /delegate は正式な使い方として文書化されています。plan mode は About GitHub Copilot CLI、/delegate は delegate guide を見れば確認できます。

install と login だけで終わる古い記事だと、いちばん重要な permission boundary が抜け落ちます。

インストール前に確認すること

要件 確認すること なぜ重要か
Copilot の利用権 有効な GitHub Copilot プランまたは seat があるか 権限がなければ CLI は認証できない
Node.js 22+ npm インストール経路を使う場合のみ必須 古い Node では公式の npm 手順が失敗する
Windows の PowerShell 6+ Windows 経路で必要 GitHub は PowerShell または WSL を案内している
組織ポリシー org / enterprise が Copilot CLI を無効化していないか seat があってもポリシーで止められることがある

2026-04-13 時点で、GitHub の Copilot plans ページ には、個人向けとして Free、月額 10 ドルの Pro、月額 39 ドルの Pro+ が掲載されています。実務上の判断はもっとシンプルで、CLI を試すだけなら高額プランは必須ではありません。ただし有効な Copilot 権益は必要で、さらに GitHub の インストールガイド にある通り、org / enterprise のポリシーで機能自体が止められることはあります。

最速で、しかも比較的安全なセットアップ

Step 1: インストール方法を 1 つ選ぶ

GitHub の インストールガイド では、npm、Homebrew、WinGet、直接インストールスクリプトの 4 経路が案内されています。

ほとんどの開発者にとって、最も扱いやすいのは次の 2 つです。

npm install -g @github/copilot

または macOS / Linux では:

brew install copilot-cli

もし ~/.npmrc に ignore-scripts=true があるなら、同じガイドに載っている npm の変形手順はこちらです。

npm_config_ignore_scripts=false npm install -g @github/copilot

私のおすすめは次の通りです。

  • すでに brew upgrade でターミナルツールを管理しているなら brew install copilot-cli
  • Node.js 22+ が入っていて、macOS / Linux / Windows で同じ手順にしたいなら npm install -g @github/copilot
  • パッケージマネージャーが使えない事情がない限り、最初から install script は選ばない

Step 2: 起動し、認証し、フォルダ信頼は慎重に選ぶ

インストール後、対話インターフェースは次のコマンドで起動します。

copilot

初回は次を実行します。

/login

GitHub の 認証ガイド によると、対話利用では OAuth device flow が既定かつ推奨です。非対話環境では COPILOT_GITHUB_TOKEN、GH_TOKEN、GITHUB_TOKEN による環境変数認証も案内されており、fine-grained PAT には Copilot Requests 権限が必要と明記されています。

この token 経路は CI、コンテナ、その他の headless 環境には便利です。ふつうのローカル開発なら、最初は /login の方がわかりやすいです。

ログイン後、Copilot は現在のフォルダを信頼するかどうかを尋ねます。GitHub の getting started guide、usage guide、configuration guide は、ここでの範囲をはっきり説明しています。セッション中、Copilot はそのディレクトリと配下のファイルを読み、変更し、実行できます。

通常は次の 3 つの選択肢が表示されます。

  • Yes, proceed:このセッションのみ信頼
  • Yes, and remember this folder for future sessions:今後もこのフォルダを記憶
  • No, exit:終了

初心者向けの安全寄りのデフォルトはシンプルです。

  • 新しいリポジトリや不慣れな checkout では、まず「このセッションのみ」を選ぶ
  • 自分が管理していて繰り返し使うディレクトリだけ「記憶する」を選ぶ
  • home ディレクトリや、コード・秘密情報・認証情報・顧客ファイルなどが混ざった広いディレクトリから Copilot を起動しない

後から現在のリポジトリ外のファイルも必要になった場合は、GitHub が案内している /add-dir や /cwd の方が、広い親ディレクトリから起動し直すより安全です。

Step 3: 最初は対話モード、いきなり自動化しない

GitHub Copilot CLI には現在、大きく 2 つの使い方があります。

  • 対話モード:ターミナル内で継続的にやり取りする
  • programmatic mode:1 回の prompt を実行して終了する

初回セッションでは、対話モードの方が通常は良い選択です。権限を渡す前に、Copilot が何をしようとしているかを確認できるからです。

最初の prompt としては、たとえば次が強いです。

Give me an overview of this project. Show the main entry points, likely build command, test command, and one risky area to avoid touching first.

この prompt が良いのは、編集より先にリポジトリ読解を強制できるからです。

Step 4: コード変更の前に plan mode へ切り替える

2026 年時点の変化の中で特に重要なのは、plan mode が正式に文書化されたことです。

GitHub の CLI overview と usage guide の両方で、対話インターフェース内では Shift+Tab で plan mode に切り替えられ、通常モードから /plan も使えると説明されています。

例:

/plan Add a new REST endpoint for category listing without changing the current response format.

実リポジトリで plan mode をデフォルト習慣にすべき理由は次の通りです。

  • コードを書く前に確認質問が入る
  • 編集前にスコープが見える
  • 小さな変更が静かにリポジトリ全体の書き換えへ膨らむ確率を下げられる

このチュートリアルから 1 つだけ習慣を持ち帰るなら、複数ファイルに触る作業ではまず plan mode を使うことです。

Step 5: programmatic mode は狭いタスク専用にする

GitHub の programmatic guide では、-p / --prompt を使うプログラム的な実行方法が説明されています。同じ文書で最小権限も勧められているので、このモードは「1 回の結果を得てすぐ終わる」狭い作業に向いています。

例:

copilot -p "Summarize the last 5 commits in this repository" --allow-tool='shell(git log:*)'

向いているのは次のような用途です。

  • commit 要約
  • クイックなリポジトリ確認
  • ワンショットのドキュメント書き換え
  • 範囲のはっきりした Git クエリ

向いていないのは次のような用途です。

  • オープンエンドな機能実装
  • リスクの高いリファクタリング
  • まだ承認境界を決めていないタスク

GitHub は CLI overview と tool permissions guide の両方で、広すぎる自動承認は Copilot にあなたと同じレベルのファイル・シェル権限を与えると明確に警告しています。これは定型文ではなく、本物のセキュリティ境界として扱うべきです。

最初の1回はこの順番で十分

最初に実リポジトリで使うときは、順番を保守的にしておく方が安全です。

段階 Copilot CLI にやらせること 次に進む前に自分で確認すること
Explore リポジトリ構造、スクリプト、最近の変更を説明させる ファイルマップやコマンドが本当に正しいか
Plan 構造化された実装計画を出させる 編集前にスコープが受け入れ可能か
Execute 承認済みの狭い変更を実行させる diff が計画から逸脱していないか
Verify テストを実行するか、失敗を要約させる チェックが本当に通ったか
Delegate スコープの明確な作業をバックグラウンドへ渡す 出てきた branch / PR を残す価値があるか

順番を逆にしないこと。先に読ませて、あとで書かせる。それだけで後始末はかなり減ります。

そのまま使える 3 つの prompt

1. リポジトリ把握用の prompt

Read this repository and give me:
1. the main entry points
2. the build and test commands
3. the folder I should read first
4. one risky area where changes could have side effects
Do not write code.

2. 安全な planning prompt

/plan Add a new CLI flag to this tool.
Constraints:
- preserve existing output format
- do not add dependencies
- list tests before implementation

3. ワンショットの terminal summary

copilot -p "Show me what changed in package.json and explain whether it affects build or runtime behavior" --allow-tool='shell(git diff:*)'

この 3 つが使いやすいのは、Copilot に先に確認させ、次に計画させ、最後に自動化させる流れを自然に作れるからです。

よくあるミスと避け方

ミス 1: 間違ったディレクトリで copilot を起動する

よくある失敗は、prompt を打つ前に始まっています。広い親ディレクトリ、home ディレクトリ、無関係なファイルが混ざった workspace からそのまま copilot を起動してしまうことです。

対策:まず本当に触りたいリポジトリへ移動してから copilot を起動します。あとで範囲を広げる必要が出たら、最初から巨大なディレクトリを信頼する代わりに /add-dir や /cwd を使います。

ミス 2: 早い段階で広すぎる権限を与える

まだそのリポジトリでの挙動を理解していないうちに広い shell 権限を与えるのが、避けられたはずのトラブルを作る最短ルートです。

対策:まずは最小限の有用なツール範囲だけ承認します。たとえば広い書き込み権限や shell 権限の前に、特定の git 読み取りコマンドだけを許可する方が安全です。

ミス 3: 複数ファイル作業で plan mode を飛ばす

リポジトリ編集前に計画をレビューできるだけで、Copilot はずっと信頼しやすくなります。

対策:タスクが複数ファイルにまたがるなら、まず /plan を使うことです。

ミス 4: 本当はポリシー制限なのに、インストール失敗だと思い込む

GitHub の インストールガイド には、Copilot 権限があっても org / enterprise のポリシーで Copilot CLI が無効化される場合があると書かれています。

対策:ログインや利用が止められたら、再インストールより先に entitlement と policy を確認してください。

ミス 5: Node.js のバージョン要件を見落とす

GitHub の インストールガイド では、npm 経路に Node.js 22 以上が必要です。

対策:古いマシンで npm install -g @github/copilot が失敗したら、まず Node を更新するか、Homebrew 経路へ切り替えます。

/delegate が本当に有効な場面

GitHub の現行ドキュメントでは、/delegate はローカル端末の裏で静かに動く worker ではなく、GitHub 上の Copilot cloud agent へのハンドオフとして説明されています。GitHub の delegate guide では、現在のセッションを GitHub に push し、未ステージ変更を新しい branch の checkpoint として commit するよう求められる場合があり、その後 cloud agent が background で続きを行う draft PR を開くと説明されています。

/delegate を使うのは、GitHub 上に見える branch と draft PR が成果物として欲しいときだけで十分です。同じローカル terminal の中で少し長く考えてほしいだけなら、別の手段を選んだ方が自然です。

向いているのは次のようなケースです。

  • ドキュメント更新
  • 独立した小さなクリーンアップ作業
  • 受け入れ条件がはっきりした issue ベースの作業

向いていないのは次のようなケースです。

  • 進行中のデバッグ
  • 探索的なリファクタリング
  • まだ問題自体を発見している途中の作業

初心者向けのルールは単純です。1 段落で明確に説明できて、しかも draft PR になっても困らない作業だけを /delegate します。

FAQ

GitHub Copilot を効果的に使うには、ターミナルを離れる必要がありますか?

ありません。それが Copilot CLI の価値です。リポジトリ読解、計画、Git 操作、スコープの明確なコード作業は、すべて shell の中で進められます。

初回起動でフォルダをそのまま恒久的に信頼してもいいですか?

たいていはやめた方が安全です。新しい repo、不慣れな checkout、混在した workspace では、まず「このセッションのみ」を選ぶのが無難です。何度も使う自分の管理下のディレクトリだけ、あとから恒久的に記憶させれば十分です。

初心者は対話モードと programmatic mode のどちらから始めるべきですか?

対話モードから始めるのがよいです。Copilot がファイルやコマンドに触る前に、修正・拒否・誘導の余地が多く残るからです。

自動承認を有効にしても Copilot CLI は安全ですか?

その環境で Copilot に広い権限を持たせたいと明確に決めている場合に限って、ある程度は成立します。GitHub 自身の文書でも、広い自動承認は実質的にあなたと同じ shell・ファイル権限を Copilot に与えると警告しています。

これだけ守れば十分

対象の repo に入って copilot を起動し、ログインし、フォルダ信頼はまずセッション限定にして、最初はリポジトリの概要を聞き、編集前に plan mode へ切り替え、理由があるときだけ権限を広げる。最初の運用なら、その順番で十分です。

検証メモ

2026-04-13 に検証。トピックの発火は公式の GitHub Blog beginner guide を確認。インストール方法、npm 経路の Node.js 22+ 要件、Windows の PowerShell 6+、組織ポリシー制限は Installing GitHub Copilot CLI を確認。OAuth /login、環境変数認証、token precedence、Copilot Requests PAT 権限は Authenticating GitHub Copilot CLI を確認。trusted folder prompt、対話利用、このセッションのみと将来セッションへの信頼差分は Getting started with GitHub Copilot CLI、Using GitHub Copilot CLI、Configure GitHub Copilot CLI を確認。plan mode と承認境界の警告は About GitHub Copilot CLI と Allowing and denying tool use を確認。programmatic な -p の使い方は Running GitHub Copilot CLI programmatically を確認。/delegate の checkpoint、branch、draft PR の挙動は Delegate tasks to GitHub Copilot CLI を確認。現在の個人向けプラン情報は GitHub Copilot plans を確認。

github-copilotcopilot-cliai-codingterminaldeveloper-workflowtutorial