ターミナル派待望の GitHub Copilot CLI 使い方まとめ
こんにちは、URBAN HACKS サーバーサイドエンジニアの池田です。
2025/9/25に GitHub Copilot CLI が public preview 版で登場しました!
業務で GitHub Copilot をメインに使っている私にとっては待望の CLI です!
なお、GitHub Copilot CLI は以下の有料プランで利用可能です。
- GitHub Copilot Pro
- GitHub Copilot Pro+
- GitHub Copilot Business
- GitHub Copilot Enterprise
プロンプトの送信ごとにプレミアムリクエストを1消費します。
ちなみに名前が紛らわしいのですが、GitHub CLI の拡張として存在していた copilot の方は廃止されるそうです。
執筆時点の環境
- OS: macOS
- GitHub Copilot CLI のバージョン: 0.0.333
インストール & 起動方法
以下のコマンドでインストールします。
※ 利用可能な環境などは公式のREADMEを参照してください
npm install -g @github/copilot
起動は以下です。このコマンドでインタラクティブモードが始まります。
copilot
なんと初回の起動時にぴゅーんと Copilot が出てくるかわいいアニメーションが走ります😍
2回目以降は省略されてしまいますが、--banner
フラグをつけて起動すれば何度も表示されます!
GitHub の認証情報がない場合は以下のメッセージが出ますので、/login
コマンドでログインしてください。
Please use /login to sign in to use Copilot
起動ディレクトリの注意点
任意のディレクトリで起動できますが、公式ドキュメントには、信頼できないファイルを含んでいる、変更されては困るファイルや機密情報を含むなど、起動が非推奨なディレクトリの注意書きがあります。
特に公式で言及されている通り、ホームディレクトリでの起動はしない方が良いでしょう。
Typically, you should not launch Copilot CLI from your home directory.
それもあってか、起動ディレクトリを配下まで含め信頼できるかの確認が入ります。
Yes, and remember this folder for future sessions
を選ぶとそのパスが信頼するディレクトリとして認識され、次回以降はそのディレクトリと配下での起動時に確認がスキップされます。
CLI 全体の主な設定内容
copilot
コマンドと一緒に指定して出来ること、インタラクティブモードで出来ることがそれぞれあります。
コマンドと一緒に指定する方はcopilot help
で、インタラクティブモードの方は/help
コマンドでそれぞれ確認できます。
設定ファイル
以下のコマンドで環境設定のヘルプが表示できます。
copilot help environment
内容は以下です。
Environment Variables:
`COLORFGBG`: fallback to detect dark / light backgrounds; uses form of "fg;bg" where each field is a number from 0-15 corresponding to ANSI colors.
`COPILOT_ALLOW_ALL`: allow all tools to run automatically without confirmation when set to "true".
`COPILOT_MODEL`: optionally set the agent model. Allowed values are "gpt-5" or "claude-sonnet-4" or "claude-sonnet-4.5" (default). Can be overridden by the --model command line option or the /model command.
`GH_TOKEN`, `GITHUB_TOKEN` (in order of precedence): an authentication token that takes precedence over previously stored credentials.
`XDG_CONFIG_HOME`: override the directory where configuration files are stored; defaults to `$HOME/.copilot`.
`XDG_STATE_HOME`: override the directory where state files are stored; defaults to `$HOME/.copilot`.
XDG_CONFIG_HOME
の説明によると$HOME/.copilot
が設定ファイルのパスのようです。
$HOME/.copilot/config.json
を見ると、以下のようなものが書かれています。
{
"banner": "never",
"theme": "auto",
"trusted_folders": []
}
この設定内容のヘルプは以下のコマンドで表示できます。
copilot help config
内容は以下です。
Configuration Settings:
`banner`: frequency of showing animated banner; defaults to "once".
- "always" displays it every time
- "never" disables it
- "once" displays it the first time
`beep`: whether to beep when user attention is required; defaults to `true`.
`model`: AI model to use for Copilot CLI; defaults to "claude-sonnet-4.5".
- "claude-sonnet-4" uses Claude Sonnet 4 model
- "gpt-5" uses GPT-5 model
- "claude-sonnet-4.5" uses Claude Sonnet 4.5 model
- Can be changed with the /model command (overrides environment variable)
- Overridden by --model command line option
`render_markdown`: whether to render markdown in the terminal; defaults to `true`.
`screen_reader`: whether to enable screen reader optimizations; defaults to `false`.
`theme`: theme to color and stylize output; defaults to "auto".
- "auto" detects terminal background and decides based on luminosity
- "dark" uses contrasting ANSI colors for dark backgrounds
- "light" uses contrasting ANSI colors for light backgrounds
`trusted_folders`: list of folders where permission to read or execute files has been granted.
banner
をalways
に設定すると、--banner
フラグがなくてもかわいい起動アニメーションが毎回表示されます✌️
また、trusted_folders
で信頼するディレクトリに追加したディレクトリ一覧が確認・編集できます。
その他にも以下が設定可能です。
-
beep
: ユーザー入力・操作が必要な場合に音を鳴らすか -
model
: 利用するモデル -
render_markdown
: ターミナル内でマークダウンを表示するか -
screen_reader
: スクリーンリーダー向けの最適化をするか -
theme
: GitHub Copilot CLI のカラーテーマ
利用モデル
公式ドキュメントによると、デフォルトは Claude Sonnet 4 です。
変更したい場合はcopilot --model gpt-5
のように--model
フラグで指定するか、インタラクティブモードの/model
コマンドで指定できます。
利用可能なモデルの値は以下です。
- claude-sonnet-4
- claude-sonnet-4.5
- gpt-5
また、環境変数のCOPILOT_MODEL
で指定することもでき、例えばgpt-5
を指定すれば GPT-5 に変更できます。
COPILOT_MODEL
よりも--model
の指定が優先されるので、デフォルトで使いたいモデルをCOPILOT_MODEL
に指定し、特定のモデルで動かしたい場合に--model
で上書きする運用が良さそうです。
利用中のモデルは以下のようにチャット欄の右上あたりに表示されています。
MCP Server
デフォルトで GitHub MCP Server が設定されています。GitHub との連携が楽でこれはありがたいですね!
他の MCP Server を追加・管理する際は、インタラクティブモードの以下のコマンドで実行できます。
/mcp [show|add|edit|delete|disable|enable] [server-name]
例えば context7 を追加する際は
/mcp add context7
と入力します。すると以下のような画面が表示されますので、Server Type を適宜選んで必要な情報を入力し、最後に Ctrl+S で保存すればOKです。
追加した MCP Server の設定はXDG_CONFIG_HOME
で指定の場所に保存されます。デフォルトでは$HOME/.copilot/mcp-config.json
です。
今回の例では以下のようなものが追加されています。
{
"mcpServers": {
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp",
"headers": {},
"tools": [
"*"
]
}
}
}
参照するカスタムインストラクションファイル
インタラクティブモードの/help
コマンドの中に以下の記載があります。
Respects instructions sourced from various locations:
`.github/instructions/**/*.instructions.md`
`.github/copilot-instructions.md`
`**/AGENTS.md`
`CLAUDE.md`
`GEMINI.md`
`$HOME/.copilot/copilot-instructions.md`
特にこれまで GitHub Copilot を利用しカスタムインストラクションを育ててきた場合、CLI もそのまま同じものを見てくれるのですぐに使い始められますね!
複数のファイルを見てくれるようですが、内部的に優先順位はありそうです。
全ファイルを用意してそれぞれで別の口調を指示する実験をした所、以下のGitHub Copilot用のファイルが優先されていそうな挙動でした。
(Copilot用ファイルの指示が全部混ざった応答をしたので、この中での優先順位はないのかもしれません)
- .github/instructions/**/*.instructions.md
- .github/copilot-instructions.md
- $HOME/.copilot/copilot-instructions.md
ただ、各ファイルで矛盾したことを書くと生成精度の低下を招くと思いますので、複数読んでくれるとはいえ配置するファイルの種類はある程度絞った方が良さそうに思います。
コード生成時のTips
ここからは主にプロンプトを渡してコード生成する際のTipsです。
コンテキストとして渡すファイル
@
以降にファイルパスを指定することで渡せます。複数指定も可能です。
また、画像も渡せます。
セッション管理
copilot
でインタラクティブモードを開始すると新しいセッションが作られます。
セッションが変わると、会話の履歴や後述するツールの許可設定がリセットされ、Copilot は会話した内容を忘れます。
実行したコマンド自体の履歴はセッションを跨いで残るため、↑キーで遡って同じコマンドを簡単に実行可能です。
(実行コマンドの履歴は$HOME/.copilot/command-history-state.json
に記録されています)
直前のセッションを再開したい場合はcopilot --continue
で再開できます。
また、それ以前のセッションを再開したい場合はcopilot --resume
で再開できます。
実行すると以下のようにセッションの選択肢が表示されますので、希望のものを選択すればOKです。
Select a session to resume:
# Modified Created Msg Summary
1. just now just now 1 This is new session.
2. 1m ago 1m ago 1 こんにちは。
利用可能なツール
インタラクティブモードでは、Copilot がツールを使いたい場合に以下の3択を聞かれます。
-
- Yes
-
- Yes, and approve {{tool}} for the rest of the running session
-
- No, and tell Copilot what to do differently (Esc)
1.が一度のみ許可(同じツールを再度使う場合は再び許可を求められる)、2.が同一セッション内で同じツールの利用を自動的に許可、3.が拒否です。
--allow-tool
フラグ
ツールの自動許可のスコープがセッション内のため、別のセッションになるとリセットされてしまいます。
これだとやや不便なので、安全に使えるツールは起動時の--allow-tool
フラグで渡しておくと便利です。
copilot help
の表示内で関連する部分を抜粋したものが以下です。
--allow-tool [tools...] Allow specific tools
## Allow touch commands
$ copilot --allow-tool 'shell(touch)'
## Allow all file editing
$ copilot --allow-tool 'write'
shell({{command}})
の形式で許可するコマンドを指定するのが基本の形です。ここで指定したコマンドはサブコマンド含めて全て許可します。
その上で、git
とgh
は特定の第一サブコマンド単位(shell(git fetch)
, shell(git commit)
等)で許可できます。
また、write
は Copilot にファイル編集を許可するためのものなので、--allow-tool 'write'
は常に指定して起動した方が楽だと思います。
複数のツールを指定したい場合は--allow-tool
を複数渡せばOKです。
その他、ツールの記述方法の詳細は公式ドキュメントをご覧ください。
--deny-tool
フラグ
許可とは反対に必ず拒否したいツールもあります。そういったものは--deny-tool
フラグで指定できます。
copilot help
の表示内で関連する部分を抜粋したものが以下です。
--deny-tool [tools...] Deny specific tools, takes precedence over --allow-tool or --allow-all-tools
## Deny git push commands
$ copilot --deny-tool 'shell(git push)'
## Allow all but one specific tool from MCP server with name "MyMCP"
$ copilot --deny-tool 'MyMCP(denied_tool)' --allow-tool 'MyMCP'
--deny-tool
のコマンドの指定方法は--allow-tool
と同様です。
なお、--allow-tool
よりも--deny-tool
の指定が優先されます。
プロンプトの渡し方
インタラクティブモードで入力する以外に、copilot
コマンドと一緒に-p
または--prompt
で渡すこともできます。
copilot help
の表示内にも以下の例が記述されています。
## Execute a prompt directly
$ copilot -p "Fix the bug in main.js" --allow-all-tools
コンテキストとして渡したいファイルは、インタラクティブモード同様に@
以降でのパス指定で渡せます。
1点注意として、インタラクティブモードと異なり、後から利用ツールの許可を出すことができません。
copilot help
内の--allow-all-tools
(全ツールの利用を許可)で以下の説明がされているのは、おそらく全ツール許可すればどのタスクでも完遂できるという意図なのかなと思われます。
required for non-interactive mode (env: COPILOT_ALLOW_ALL)
ただ、ツール全許可はちょっとリスクが高いです。
一応--allow-all-tools
を指定せずとも、タスクの遂行に必要となるツールを--allow-tool
で渡せば問題ありません。
使い所としては、これまで簡単な Shell Script を書いて実現していたような領域に対し、ワンライナーで Copilot を使った処理を差し込める、という発想だと良いかもしれません。
MCP Server と連携させるとより活用範囲が広がると思います。
例えば Playwright MCP や Chrome DevTools MCP と連携させれば、ちょっとしたブラウザ操作をワンライナーで Copilot に依頼できます。
この際に特定の MCP Server や一部のツールのみを許可することで、Copilot が比較的安全にタスクをこなせるかと思います。
一方で、コード修正を依頼する場合は素直にインタラクティブモードを利用した方が良さそうです。
実際に使ってみた
単一の GitHub リポジトリを対象にタスクを依頼しても十分こなせそうでちょっと面白みに欠けるので、複数のリポジトリを対象に動かしてみました。
先にシステムAにIDを登録し、そこで発番されたIDを元にシステムBにIDを登録する流れを模倣するローカル用のデータセットアップスクリプトを作ってもらいます。
ディレクトリ構成とプロンプトは以下です。(プロンプトはブログ用に簡素化していますが、概ね近い雰囲気です)
モデルは Claude Sonnet 4.5 にしました。
## ディレクトリ構成
└── root/ ## このディレクトリでインタラクティブモードを起動
├── system-A/ ## GitHubリポジトリ1
└── system-B/ ## GitHubリポジトリ2
## 目的
2つのシステム(system-A / system-B)間で行われるID発番と登録処理の流れを再現し、ローカルでアカウントデータを生成できるスクリプトを作成する。
## 処理フロー
1. 実行時引数として base ID を受け取る。(例: --base-id=base_1234567890)
1. 受け取った base ID に対応する system-A ID を生成し、base ID と system-A ID のペアを DynamoDB に登録。
1. この処理は system-A の POST /user の内部ロジックを模倣。
1. UUID 形式の system-B ID を生成し、 system-A ID / system-B ID のペアを PostgreSQL に登録。
1. この処理は system-B の POST /user の内部ロジックを模倣。
## 要件・仕様詳細
- 言語: shell script
- インフラ想定:
- DynamoDB: ローカル (amazon/dynamodb-local) or AWS 開発環境。接続設定は環境変数優先。
- PostgreSQL: ローカル (Docker) or AWS 開発環境。接続設定も環境変数優先。
- エラー時挙動:
- 既に同じ base ID / system-A ID ペアが DynamoDB に存在する場合、該当データの各種IDをログに出力しスキップ。
- PostgreSQL 登録失敗時はロールバックし、該当データの各種IDをログに出力。
- ログ: INFO レベルで各ステップの開始・完了・ID値を出力。
- テストコードは不要。
## 期待アウトプット
- スクリプト本体。
インタラクティブモードでプロンプトを渡してから、約10分ほどで最初のスクリプトが生成されました。
中を見るとそれぞれのリポジトリのコードを読まなければ作れないようなスクリプトになっていたので、うまく複数のリポジトリを読めていそうでした!
一発で完璧なスクリプトとまではいきませんでしたが、インタラクティブモードであれば追加で依頼をすれば良いので、他のコーディングエージェント同様の感覚で使っていけそうです。(生成精度はプロンプト自体の改善で変わる部分もあるでしょうし)
ちなみに VS Code の GitHub Copilot の Agent モードに同じディレクトリ、モデルで同じプロンプトを渡したところ、似たようなスクリプトが生成されました。
そのため、これまで Agent モードを使っていた方であれば、似たような雰囲気で CLI の方も使い始められるのではないかと思います。
まとめ
ターミナルから GitHub Copilot が呼べるようになったことで、これまで以上に活用の幅が広がりそうだなと感じました!
既に存在している他のターミナル型AIコーディングエージェント(Claude Code など)と比べると足りない機能もありますが、まだ登場したばかりですのでこれからの成長に期待です🚀
(記事を書いている最中にもちょこちょこ更新が入り、かゆい部分(利用中モデルが表示されない等)が改善されたりしていました)
Discussion