GitHub Copilot CLIの使い方：導入からテスト修正・PR作成まで

GitHub Copilot CLIをインストールしてログインする

GitHubの安定版npmパッケージ、@github/copilotを使います。必要なのはNode.js 22以降です。Windowsでは、GitHubはさらにPowerShell v6以上を要件としています。組織からCopilotを付与されている場合は、管理者によるCopilot CLIポリシーの有効化が必要です。インストールの要件。

ターミナルで次のコマンドを実行します。

npm install -g @github/copilot

~/.npmrcにignore-scripts=trueを設定している場合、GitHubは代わりにnpm_config_ignore_scripts=false npm install -g @github/copilotを案内しています。ほかにも、Windowsではwinget install GitHub.Copilot、macOSまたはLinuxではbrew install --cask copilot-cliとcurl -fsSL https://gh.io/copilot-install | bashが公式に案内されています。Node.jsが必要なのは、npm経由でインストールする場合です。GitHubのインストールコマンド。

作業するリポジトリに移動して、copilotを起動します。そのフォルダーを今回のセッションだけ信頼するか、今後のセッションでも信頼するかを選びます。まだログインしていない場合は、案内に従ってCopilot内で/loginを入力します。初回起動の手順。

GitHub.com、またはデータレジデンシーを利用するGitHub Enterprise Cloudのホスト名を選択します。ローカルのデスクトップ環境ではブラウザー経由の認証を選びます。リモート環境やヘッドレス環境では、通常、デバイスコードによる認証が先に提示されます。ブラウザーで認証を完了し、SAML SSOを使う組織については必要な承認を行い、GitHub Copilot CLIアプリケーションを承認します。ログインが完了したらターミナルに戻ります。シェルからcopilot loginを実行して認証を始めることもできます。認証の手順。

意図しないアカウントでCLIが動く場合は、COPILOT_GITHUB_TOKEN、GH_TOKEN、GITHUB_TOKENの環境変数を確認してください。明示的にエクスポートしたトークンは、保存済みのログイン情報より優先されます。自動化には、個人アカウントのCopilot Requests権限を持つきめ細かなアクセストークンを利用できます。クラシック形式の個人用アクセストークンはサポートされていません。認証とトークンの優先順位。

最初の使い方：コードの把握、テスト修正、PR作成

まず質問し、次に結果を確認できる変更を依頼してから、プルリクエストに進みます。CLIは、同じ作業台でプロジェクトを調べ、ツールを操作する開発者のように考えるとわかりやすいでしょう。どの操作を許可するかは、自分で判断します。

以下の表では、シェルで実行するコマンドと、対話形式のcopilotセッション内で入力する内容を区別しています。ここに挙げたコマンドとプロンプトは、いずれもGitHubのドキュメントに記載されています。モデルとのやり取りには、その都度AIクレジットを消費します。GitHubは、これらの作業に対する固定のクレジット料金を公表していません。CLIの課金の仕組み。

変更する前にリポジトリを理解する

初めて触るプロジェクトなら、表にある説明用のコマンドから始められます。GitHubの例ではClaude Haiku 4.5を指定しています。-pは単一のプロンプトを送信して処理後に終了し、-sは余分な出力を抑え、--modelはモデルを選択します。プランやポリシーによってそのモデルを使えない場合は、対話セッションを起動し、/modelで利用できるモデルを選んでください。FreeとStudentのアカウントではAutoによる選択を使います。プログラムから実行する例、モデルの利用条件。

説明を手がかりにエントリーポイントやテストの構成を見つけ、実際のファイルを自分で確認します。こうすれば、ディレクトリを漫然とたどる代わりに、疑問点を掘り下げられる具体的な見取り図が得られます。

テスト修正は完了条件を明確にする

テストが壊れている場合は、リポジトリで実際に使うテストコマンドを実行し、その失敗出力をCopilotに渡してから、表の対話用プロンプトを使います。GitHubはテスト駆動開発の手順で、失敗するテストを作成・レビューした後にこの文言を使っています。既存の失敗を直す場合も、同じように必要な情報を補います。どのテストが失敗しているのか、どの振る舞いを維持すべきなのかを伝えてください。変更を採用する前に差分を確認し、該当するテストを再実行します。GitHubのテスト手順。

既存のプルリクエストに付随する自動チェック（CI）でテストが失敗している場合、GitHubは**/pr fix ci focus on test failures**を案内しています。このコマンドはログを調べ、修正を加え、変更をプッシュすることもあります。ローカルのテスト修正とは別のワークフローとして扱ってください。現在のブランチに既存のPRが必要です。CIの失敗を修正する手順。

差分を確認してからプルリクエストを作成する

小さな修正をリリースする創業者なら、変更を確認してコミットした後、作業ブランチから/pr createを使えます。GitHubでホストされているGitリポジトリ内で実行する必要があります。Copilotはローカルのコミットをプッシュし、リポジトリのPRテンプレートに沿ったタイトルと説明でPRを作成します。そのブランチにすでにPRがある場合は、既存のPRを更新します。プルリクエストの作成。

チームが普段使うGitHubの流れに沿って、レビューできる形で変更を引き渡せます。ただし、ブランチに含まれる内容への責任は自分にあります。

コマンド実行前の承認はどう扱う？

フォルダーを信頼するかどうかと、ツールの操作を許可するかどうかは、別々に判断します。 承認が必要な操作では、今回だけ許可する、実行中のセッションでそのツールを許可する、拒否してフィードバックを伝える、といった選択ができます。セッション単位の承認は、ツールとそのオプションに適用されます。承認時の案内。

読み取り専用の操作は自動で実行できます。破壊的になりうる操作、書き込み、URLへのアクセスには、すでに許可している場合を除いて承認が必要です。一部の確認では、リポジトリやディレクトリに対する許可を保存できます。恒久的に許可したURLドメインは、セッションをまたいで有効になります。保存される権限。

GitHubは、起動時に権限を設定する例として次を挙げています。

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

この設定はGitコマンドを許可しつつ、プッシュを拒否します。拒否ルールは、許可ルールや保存済みの承認より優先されます。/reset-allowed-toolsはセッション内の承認と現在の場所に保存されたツールの承認を消去し、起動時に設定した権限に戻します。許可と拒否のルール。

--allow-all-toolsは、利用可能なツールをすべて許可します。--allow-allまたは--yoloは、さらにすべてのパスとURLも許可します。GitHubは、広範な許可を使う場合には隔離された環境を推奨しています。最初の作業では、通常の承認フローを使いましょう。広範な権限を与えるオプション。

Copilot CLIの料金は？どのプランに含まれる？

CLIはすべてのCopilotプランに含まれています。 対象はFree、Student、Pro、Pro+、Max、Business、Enterpriseです。既存のCopilotライセンスに、CLI専用の契約を追加する必要はありません。GitHubのプランページに記載されている現在の月額料金と利用枠は、次のとおりです。Copilotのプラン。

flexは変動する割り当てなので、現在の合計が今後も保証されるわけではありません。AIクレジットの単価は$0.01 USDです。 消費量は、選択したモデルの料金と、入力・出力・キャッシュ済みトークンによって決まります。チャットとCLIは同じ利用枠を使います。有料プランのコード補完と次の編集候補の提案は、引き続き無制限で、AIクレジットを消費しません。個人向けの課金。

すでにProを契約している場合、月額料金は$10のままです。ただし、ターミナルでモデルを使うと、現在の1,500クレジットの枠をほかの作業と分け合います。費用を考えるうえでの要点は、すでに利用できるCLIを試し、共有枠で仕事をまかなえるかを判断することです。個人の有料プランでは、追加使用の予算を設定する、上位プランに変更する、月次リセットを待つ、といった選択肢があります。公開されている料金表では、Freeでの追加クレジット購入は提供されていません。個人向けの利用枠、Freeの購入制限。

BusinessとEnterpriseでは、請求主体の単位でクレジットをプールします。追加の有料使用は既定で有効ですが、管理者が無効にできます。別の利用枠が残っていても、ユーザー予算やEnterpriseの支出上限に達すると利用が止まる場合があります。GitHubは、課金と使用量を正確に表示するためにCLI 1.0.48以降を推奨しています。組織向けの課金。

作業後に/usageで、セッションのクレジット消費量とモデルのトークン使用量を確認します。対話セッションでは/limits set max-ai-credits NUMBERで上限を設定でき、NUMBERを希望する利用枠に置き換えます。最小値は30クレジットです。この機能はパブリックプレビューで、上限はソフトリミットです。進行中の応答は最後まで処理されるため、設定値をわずかに超えることがあります。使用量の表示、セッションの上限。

Copilot CLIではどのモデルを使える？

Copilot内では**/model**で選択肢を確認し、シェルから起動する場合は--modelを使います。GitHubの現在のクライアント別対応表では、以下のモデルがCLI対応とされています。ただし、プランや管理者のポリシーによって利用範囲が狭まることがあります。対応モデル。

GitHubが別に掲載しているCLIのAuto対応表には、GPT-6.1 Solも含まれています。FreeとStudentではAutoのみを利用できます。提供状況は変わるため、自分のアカウントで現在選べるモデルはモデル選択画面で確認してください。Autoとプラン別の利用条件。

プロジェクトの指示ファイルとMCPツールを設定する

繰り返し変更を依頼する前に、リポジトリの作業ルールを書いておきます。 カスタム指示は、Copilotがコンテキストに含めるMarkdownファイルです。プロジェクト全体のビルドコマンド、テストコマンド、規約は.github/copilot-instructions.mdに記載します。特定のパスだけに適用するルールは、.github/instructions/**/*.instructions.mdとapplyToパターンで指定します。カスタム指示。

CLIはAGENTS.md、CLAUDE.md、.claude/CLAUDE.md、GEMINI.mdも検出します。ユーザー全体の設定は、~/.copilot/copilot-instructions.mdや~/.copilot/instructions/**/*.instructions.mdに置けます。適用対象となる指示は組み合わせて使われますが、GitHubはそれらの間の一般的な優先順位を定めていません。内容に矛盾がないようにし、/instructionsで検出されたファイルを確認したり、無効にしたりしてください。指示の検出と組み合わせ。

MCP（Model Context Protocol）は、エージェントを外部のツールやデータにつなぐ仕組みです。 作業台にサービスとの接続を追加するものと考えるとわかりやすいでしょう。GitHub MCPサーバーはすでに組み込まれています。別のサーバーを追加するには、/mcp addを使い、Tabで項目間を移動し、Ctrl+Sで保存します。ローカルまたはstdioのサーバーはプロセスを起動し、HTTPサーバーはリモートのエンドポイントに接続します。従来のSSEもサポートされています。MCPサーバーの追加。

GitHubが示すターミナルでの例は、copilot mcp add --transport http sentry https://mcp.sentry.dev/mcpです。ユーザー設定は~/.copilot/mcp-config.jsonに保存され、プロジェクト設定には.mcp.jsonまたは.github/mcp.jsonを使えます。MCP専用ガイドには、設定済みの組織レジストリと許可リストのポリシーがCLIにも適用されると記載されています。ターミナルでの設定例、設定とポリシー。

CLI、IDE、別のエージェントはどう使い分ける？

ターミナルで行う作業があり、Copilotのライセンスも持っているなら、まずCopilot CLIから試すのがおすすめです。 編集対象のファイルを開き、変更を画面で確認しながらエディター内で作業を続けたい場合は、IDE拡張機能を選びます。エディター選びには、CursorとGitHub Copilotの比較も参考になります。

基本的な作業に慣れたら、次のような使い方も考えられます。

• レビューを準備するメンテナーなら、作業ブランチのコードレビューを依頼し、指摘を調べてから、人間のレビュアーに差分を渡せます。検証に耐える指摘であれば、的を絞ったレビューチェックリストとして役立ちます。GitHubはローカルでのレビュー手順を公開しています。レビューのガイド。
• PRのフィードバックに対応する開発者なら、/pr fix feedbackで修正案を確認し、その結果のプッシュを承認できます。求められた変更と議論を一緒に扱える利点があります。このコマンドは、対応済みのレビュースレッドに返信し、解決済みにすることもできるため、承認前に対象範囲を確認してください。フィードバックへの対応手順。

別のサブスクリプションの利用枠、異なるプロバイダー構成、あるいはエージェント自体への制御が必要なら、ほかのターミナルエージェントを検討します。購入の判断には、Claude Codeの代替とターミナル利用コストの比較を参照してください。その前に、Copilot自身のモデル選択肢で要件を満たせるかも確認しましょう。GitHubは、互換性のあるローカルモデルを含め、独自のプロバイダーを持ち込む方法も案内しています。こちらは別途プロバイダーの設定が必要で、ツール呼び出しとストリーミングへの対応が要件です。Copilotの利用枠を使う場合とは、設定方法が異なります。独自モデルの利用。

小さなチームなら、どんなサービスを作れる？

最も有望な出発点は、リポジトリへのオンボーディング用パックです。 開発者は「how to understand a new codebase」や「ai tool to understand codebase」といった言葉で検索します。チームは、アーキテクチャの説明、検証済みのビルド手順、範囲を絞ったオンボーディングタスクを継続的に整備し、エンジニアリングの責任者に販売することが考えられます。最小限の実用版では、顧客のリポジトリを対象に、コードの把握、テスト、PR作成までの流れを示します。課題は、汎用的なプロンプトは簡単にコピーできることです。購入者が対価を払う対象は、更新を続けるプロジェクト固有の知識でしょう。

レビュー準備のワークフローも候補です。 「ai code review tools」や「ai powered code review platform」という検索は、この作業への関心を示しています。プロジェクトの指示と連携先の課題情報を組み合わせ、変更内容、テストの証拠、未解決の疑問をまとめたレビュー資料を作るサービスが考えられます。購入者は、引き継ぎの方法を統一したいチームリードです。ただし、生成された指摘の検証は欠かせません。GitHubの既存レビュー機能と並べて使う価値も示す必要があります。ここで挙げているのは製品の可能性であり、実証済みの成果ではありません。

導入前に押さえておきたい制約

CLIは、もっともらしく見えても誤った変更を生成することがあります。 GitHubの責任ある使用のガイドは、生成物が不正確または不完全になりうると説明し、CLIが生成したコードとコマンドの検証を求めています。該当するテストを通すことと、差分を確認することも作業の一部です。責任ある使用。

フォルダーを信頼しても、隔離が保証されるわけではありません。 GitHubはディレクトリ権限の範囲判定をヒューリスティックなものと説明しており、信頼したディレクトリの外にあるすべてのファイルの保護を保証していません。作業対象のリポジトリ内で起動してください。制限を強めたい場合は、/sandbox enableでツールのローカルサンドボックスを有効にできます。GitHubのローカルサンドボックスとクラウドサンドボックスは、パブリックプレビューです。ディレクトリの信頼とサンドボックス。

利用条件と支出上限も引き続き適用されます。 ドキュメントに載っているモデルでも、プランで提供されていなかったり、ポリシーで無効になっていたりする場合があります。CLIはほかのCopilot作業とクレジットを共有し、プレビュー中のセッション上限をわずかに超えることもあります。組織の予算に達すると、安いモデルへ自動的に切り替わることなく利用が止まる場合があります。モデルの利用条件、セッションの上限、予算到達時の挙動。

次の作業では、レビューできるブランチ上で、実際に失敗しているテストを選びましょう。関連コードの説明を受け、修正に必要なツールのリクエストを承認し、テストを再実行して/usageを確認してから、PRを作成します。そうすれば、作業の流れに合うか、どれだけクレジットを使うかを具体的に判断できます。

チームのチェック手順や連携ツールに合わせたリポジトリのワークフローを構築したい場合は、AIによる自動化の開発をご相談ください。