こんにちは、@chips0711 です。
少し前に、GitHub から「GitHub Copilot CLI for Beginners」というGitHub Copilot CLI を学べるコースが公開されました。
2,000 超のスター（2026 年 4 月時点）が付いている人気コース
正直なところ、GitHub Copilot CLIを触り始める前は､「CLI でチャットするだけでしょ？」くらいに思ってました。
使い慣れている VS Code の GitHub Copilot Chat があれば十分じゃないかと。
ただ、実際にこのコースを通してやってみると、CLI ならではの使い方がかなりあって、印象がだいぶ変わりました。なので、今回この良い教材を広く紹介させてください。
本記事では、コースの内容をざっくり紹介しつつ、やってみて感じたことや Tips などを書いていきたいと思います。
そもそも GitHub Copilot CLI って何？
GitHub Copilot と聞くと、VS Code でコードの補完をしてくれるあの機能を思い浮かべる方が多いと思います。GitHub Copilot CLI はその「ターミナル版」です。
ターミナルで copilot と打つだけで、AI とやりとりしながらコードレビュー、デバッグ、テスト生成、リファクタリングなどができます。ブラウザもエディタも開く必要がありません。
では CLI 版ならではの強みとは何か。それがこのコースを通じてわかってきたので、まずは全体像から紹介します。
コースの全体像
コースは以下にあるように、全 8 チャプターです。
真面目に取り組むと、だいたい 5〜6 時間くらいはかかる構成になっています。
コースのラーニングパス（出典: リポジトリ）
所要時間目安としては以下の通りです。
一つ一つ丁寧にやるとこれくらいかかると思います。
（あくまで筆者が実際に実施した際のだいたいの所要時間なのでご参考程度に）
| チャプター | 内容 | 所要時間目安 |
|---|---|---|
| 00 | インストールと動作確認 | 10 分 |
| 01 | 3 つのインタラクションモード体験 | 30 分 |
| 02 | コンテキストの渡し方と会話管理 | 30 分 |
| 03 | コードレビュー・デバッグ・テスト生成 | 45 分 |
| 04 | カスタムエージェントの作成 | 45 分 |
| 05 | スキルによる作業自動化 | 45 分 |
| 06 | MCP サーバー連携 | 45 分 |
| 07 | 全部組み合わせて実践 | 60 分 |
全体の内容としては、書籍管理 CLI アプリを一貫して題材にしているのが特徴です。
毎回違うサンプルが出てくるタイプの教材と違って、同じアプリをどんどん改善していく流れなので、「さっきの章でやったことがここで活きるのか」という感覚があると思います。
題材の書籍管理アプリ（books.py）— Book データクラスと BookCollection クラスのシンプルな構成
まずやったこと
実際に試す環境は Codespaces よりローカルがおすすめ
コースでは GitHub Codespaces での利用が推奨されています。セットアップ不要ですぐに始められるのは大きなメリットです。
ただ、個人的にはローカル環境で試すのもおすすめです。実務で GitHub Copilot CLI を使うのはローカルのターミナルが多いので、セットアップから体験しておくと、コースが終わった後にそのまま自分の開発に持ち込めます。
セットアップ自体は簡単で、インストールスクリプトを実行するだけです。
# macOS / Linux の場合
curl -fsSL https://gh.io/copilot-install | bash
インストールできたか確認するには、バージョンを表示してみましょう。
$ copilot --version
GitHub Copilot CLI 1.0.18.
試しに一言聞いてみます。-p はプロンプトモード（非対話で 1 回だけ質問するモード）です。
$ copilot -p "Hello! 日本語で短く自己紹介して"
こんにちは！GitHub Copilot CLI です。ターミナルからコードの質問、
レビュー、生成などをお手伝いします。よろしくお願いします！
これで動作確認は完了です。10 分もかかりません。
README の日本語化から始める
このコースは基本的に英語で書かれています。英語のまま読むのがしんどい場合、最初に GitHub Copilot CLI で各チャプターの README を日本語化してしまえば、その後捗ります。
このコース自体が GitHub Copilot CLI の教材なので、README の日本語化がそのまま練習になります。
たとえばチャプター 1 の README を日本語化するなら、copilot を起動して以下のように入力します。
copilot
# Interactive セッションが起動したら以下を入力
> @01-setup-and-first-steps/README.md このREADMEを日本語に翻訳して。技術用語（GitHub Copilot, CLI, MCP など）はそのまま残して、説明文だけ自然な日本語にして
もちろん、他のチャプターの README もまとめて日本語化する指示を出してもいいです。
ポイントは、プロンプトで「技術用語は残して」と明示することです。これがないと "Interactive Mode" が「対話型モード」に訳されて、コース内のコマンド例と一致しなくなったりします。
@ でファイルを渡して翻訳を依頼する、というのは Ch02 で学ぶ「コンテキストの渡し方」そのものです。
コース内には案内はないんですが、この README.md の日本語化はコース前のウォーミングアップや、コースを円滑に進めるための下準備としてちょうどいいのではないかなと思います。
実際にチャプターを進めてみる
各チャプターごとに印象に残ったことなど、ピックアップして紹介します。
Ch01 — 3 つのインタラクションモード
コースでは Interactive / Plan / Programmatic の 3 つのモードが紹介されています。
Interactive モードは対話形式で質問する、いちばん直感的なモードです。
Plan モードは実装計画を先に立てさせるモードで、いきなりコードを書かせません。Programmatic モードはスクリプトから GitHub Copilot CLI を呼べるので、CI/CD に組み込めます。
これに加えて、現在は Autopilot モード も使えるようになっています。タスクが完了するまでエージェントが自律的に作業を続けてくれるモードで、「テストを書いて、通るまで直して」みたいなタスクを丸ごと任せられます。Shift+Tab で Interactive → Plan → Autopilot とモードを切り替えられます。
個人的に「おっ」と思ったのは Plan モードです。「このバグを直して」とお願いする前に「まず原因を分析して計画を立てて」と指示できます。いきなりコードを変えられるより安心感があります。
実際に Prompt モードで動かすとこんな感じです。-p フラグを付けると非対話で 1 回だけ質問できます。@file でファイルを参照する場合は --allow-all（権限確認をスキップ）も必要です。
$ cd samples/book-app-project
$ copilot --allow-all -p "@books.py このクラス構造を1行で説明して"
● Read books.py
└ 72 lines read
`Book` データクラス（title/author/year/read）と、それを JSON で
永続化しながら CRUD 操作を提供する `BookCollection` クラスの
2クラス構成です。
@books.py でファイルをコンテキストとして渡しているのがポイントです。これは Ch02 で詳しく学びます。
GitHub Copilot CLI がコードを読んで説明してくれる様子（出典: Ch01）
Ch02 — コンテキストの渡し方
ここがけっこう大事な章でした。
@ 記法を使って、ファイルやディレクトリをコンテキストとして渡せます。Interactive セッション内で以下のように使います。
copilot
# ファイル単体を渡す
> @books.py このクラスの責務を説明して
# ディレクトリごと渡す
> @samples/book-app-project/ このプロジェクトのアーキテクチャを分析して
何を渡すかで回答の質が変わる（出典: Ch02）
VS Code だと開いているファイルが自動でコンテキストに入りますが、CLI だと自分で明示的に指定します。一見面倒ですが、逆に「何を見せているか」を自分でコントロールできるので、意図しない情報を渡さずに済みます。プロジェクトが大きくなるほどこの違いが効いてきます。
複数ファイルをコンテキストに渡して横断的に分析させている様子（出典: Ch02）
Ch03 — 開発ワークフロー
コードレビュー、リファクタリング、デバッグ、テスト生成、Git 連携の 5 つのワークフローを体験できます。ここがいちばんボリュームのある章です。
特にコードレビューが実用的でした。
サンプルアプリにはわざとバグが仕込まれていて（samples/book-app-buggy/）、GitHub Copilot CLI がそれを見つける過程を体験できます。型の不一致やエッジケースの考慮漏れをけっこう正確に指摘してくれました。
実際にレビューを依頼するとこんな出力が返ってきます。
$ copilot --allow-all -p "@book_app.py このファイルをレビューして。バグとセキュリティリスクを指摘して"
● Read book_app.py
└ 58 lines read
## レビュー結果
1. **入力バリデーションなし**: year の入力が数値かどうかチェックしていません。
ValueError が発生する可能性があります。
2. **ファイルパスのハードコード**: DATA_FILE が固定値のため、
テスト時にプロダクションデータを上書きするリスクがあります。
3. ...
テスト生成も試しました。
copilot --allow-all -p "@books.py BookCollection クラスに対する pytest テストを生成して"
境界値テストまで自動で含まれている（出典: Ch03）
出てきたテストがそのまま動くレベルだったのは驚きました。もちろん手直しは要りますが、ゼロから書くよりずっと速いと感じました。
Ch04 — カスタムエージェント
ここから応用編です。
エージェントは、特定の役割を持った AI アシスタントを定義する機能です。
たとえば、以下のように「Python コードレビュー専門」のエージェントを作っておくと、毎回レビュー観点を指示しなくても PEP 8 準拠、型ヒント、エラーハンドリングなどを自動でチェックしてくれます。
---
name: python-reviewer
description: Python code quality specialist
---
# Python Reviewer
You are a senior Python developer reviewing code for:
- PEP 8 compliance
- Type hints
- Error handling patterns
- Test coverage gaps
チームで使うなら、レビュー基準をエージェント定義に落とし込んでおくと属人化を減らせます。これはいいアイデアだと思いました。
カスタムエージェントでレビューしている様子（出典: Ch04）
Ch05 — スキル
エージェントが「人」だとすると、スキルは「手順書」に近いイメージです。
エージェント vs スキル vs MCP の違い（出典: Ch05）
特定のキーワードに反応して自動的にロードされる命令セットです。
以下のように、「コミットメッセージを書いて」と言うと Conventional Commits 形式で生成してくれるスキルを定義できたりします。
---
name: commit-message
description: Generate conventional commit messages
---
エージェントは対話的なやりとり向き、スキルは決まった手順の自動化向きです。
この使い分けがコースの中で丁寧に説明されていて、実際に動かしてみると、感覚的にも自分の中で違いの整理がつきました。
なお v1.0.17 からは CLI にビルトインスキルも追加されていて、自分で定義しなくても使えるスキルが増えてきています。
Ch06 — MCP サーバー連携
MCP（Model Context Protocol）は、GitHub Copilot を外部のデータソースやツールに接続する仕組みです。
MCP の概念 — ブラウザ拡張機能に例えた図（出典: Ch06）
GitHub のリポジトリ情報、ファイルシステム、データベースなどを GitHub Copilot CLI から直接参照できるようになります。「このリポジトリの最新の Issue を見て」と言うだけで、GitHub API を叩いた結果をもとに回答してくれます。
MCP 経由で GitHub の情報を取得しながら作業する様子（出典: Ch06）
ここは CLI ならではの強みだと感じました。ターミナルでの作業中にブラウザで GitHub を開いて Issue を確認して、またターミナルに戻って…というコンテキストスイッチが要らなくなります。
Ch07 — 全部合わせて使う
最終章では、エージェント + スキル + MCP を組み合わせて、Issue の確認から実装、テスト、コミット、PR 作成までを一連の流れでやります。
ターミナルから一歩も出ずに PR まで持っていけるのは、正直かなり気持ちいい体験でした。/delegate で GitHub Copilot cloud agent に引き継げば、コードの微調整から PR 作成まで自動で進めてくれます。
覚えておくと便利なコマンド
コースでは各チャプターの機能にフォーカスしていますが、日常的に使っていて「これは便利だな」と感じたスラッシュコマンドをいくつか紹介します。
/fleet — 並列でサブエージェントを走らせる
個人的にいちばん気に入っているコマンドです。/fleet を有効にすると、GitHub Copilot CLI が複数のサブエージェントを並列で動かしてくれます。
たとえば「このプロジェクトのテストを書いて、同時にドキュメントも更新して」みたいな複数タスクを投げると、それぞれ別のサブエージェントが並行して処理を進めます。大きめのタスクを投げるとき、体感の待ち時間がだいぶ変わります。
copilot
> /fleet
# Fleet mode enabled と表示される
> @samples/book-app-project/ テストの追加とdocstringの整備を両方やって
/compact — コンテキストを圧縮する
長い会話をしていると、コンテキストウィンドウがいっぱいになってきます。/compact を打つと、これまでの会話を要約してコンテキストを軽くしてくれます。セッションを捨てずに作業を続けたいときに便利です。
/diff — 変更の確認
GitHub Copilot CLI にコードを変更してもらった後、何が変わったかを確認できます。git diff と似た出力で、「あ、ここも変えたんだ」というのがすぐわかります。
/review — コードレビューエージェント
変更内容に対してレビューエージェントを走らせます。自分で書いたコードを PR に出す前にセルフチェックする用途で使っています。
/research — 深掘りリサーチ
GitHub の検索や Web ソースを使って、調査を深掘りしてくれるコマンドです。「このライブラリの最新の breaking changes を調べて」みたいな使い方ができます。
/delegate — GitHub に送ってPRを作らせる
これもけっこう面白い機能です。ローカルで作業していたセッションを GitHub に送ると、GitHub Copilot cloud agent(旧名称：GitHub Copilot coding agent) が引き継いで PR を作ってくれます。「ここまで方針は決まったから、あとは PR にしておいて」みたいな委任ができます。
/undo と /rewind — やり直し
/undo は直前のターンを取り消してファイル変更もリバートしてくれます。「あ、違うそうじゃない」ってなったときにすぐ戻せます。
/rewind はさらに強力で、タイムラインピッカーが開いて会話の任意の地点まで巻き戻せます。「3 つ前の状態に戻したい」みたいなときに便利です。
その他よく使うもの
| コマンド | 用途 |
|---|---|
/model |
使用する AI モデルを切り替え（Claude Sonnet 4.5/4.6、GPT-5.4、Gemini 3.1 Pro など） |
/tasks |
バックグラウンドで動いているサブエージェントの状態確認 |
/context |
コンテキストウィンドウの使用状況を可視化 |
/share |
セッションを Markdown や HTML ファイルとして共有（/share html で対話型 HTML 出力も可） |
/mcp auth |
MCP サーバーの OAuth 認証を管理（アカウント切り替え対応） |
/session |
セッションの使用量（API コール数、コード変更行数）を確認 |
Shift+Tab |
モードの切り替え（Interactive → Plan → Autopilot） |
Ctrl+S |
入力を保持したままコマンド実行 |
/help で全コマンドの一覧が見られるので、一度眺めておくと発見があると思います。
スラッシュコマンドの全体像や料金プランごとのプレミアムリクエスト消費量など、もう少し詳しい情報は別途スクラップにまとめています。
CLI 版ならではだと感じたこと
コースを通じてわかった、VS Code の GitHub Copilot Chat との違いを整理します。
コンテキストを自分でコントロールできる
@ で何を見せるか明示するので、不要な情報を渡さずに済みます。VS Code だと開いているファイルが自動的にコンテキストに入りますが、CLI では自分で選べます。プロジェクトが大きくなるほどこの違いが効いてきますし、「何を見せたか」が明確なのでプロンプトの再現性も高くなります。
CI/CD に組み込める
Programmatic モード（-p フラグ）があるので、GitHub Actions のワークフローに GitHub Copilot CLI の処理を入れられます。たとえば PR ごとに自動レビューを走らせたり、コミットメッセージを自動生成させたりといった使い方が可能です。シェルスクリプトの中で copilot --allow-all -p "..." と呼ぶだけなので、既存のワークフローにも組み込みやすいと思います。
SSH 先でも使える
リモートサーバーにエディタをインストールしなくても、ターミナルさえあれば GitHub Copilot CLI が使えます。本番サーバーのログを見ながらその場で原因を分析してもらう、といった使い方もできます。
エージェント・スキル・MCP がファイルベース
VS Code でも使えますが、CLI だとこれらの定義ファイルをそのまま Git で管理できます。チームで .github/agents/ や .github/skills/ をリポジトリにコミットしておけば、メンバー全員が同じ設定で GitHub Copilot CLI を使えます。レビュー基準の属人化を防ぎたいチームには特に相性が良いと感じました。
コースの良かったところ
一貫した題材で理解が積み上がる
書籍管理アプリという身近な題材を 8 チャプターを通して使うので、章が進むごとに理解が積み上がる感覚がありました。Ch01 で基本操作を覚えた同じアプリに、Ch03 でテストを書き、Ch04 でレビュー用エージェントを作り、Ch07 で全部組み合わせて PR まで出す。「さっき学んだことが、ここで活きるのか」という体験が自然に生まれます。
コマンドがそのままコピペで動く
教材にありがちな「環境が違うと動かない」問題が少ないのも助かりました。コマンド例がそのまま動くので、写経しながら手を動かしているうちに自然と覚えられます。Codespaces を使えばセットアップすら不要で、ブラウザから数クリックで始められます。
無料で誰でも受講できる
GitHub アカウントと GitHub Copilot のサブスクリプション（無料プランを含む）があれば、コース自体は無料で受講できます。教材もすべて MIT ライセンスで公開されているので、社内勉強会やチームのオンボーディング素材としても使いやすいと思います。
各章に実践課題がある
各チャプターの最後に Assignment（課題）が用意されていて、読むだけで終わらない構成になっています。「ここまで学んだことを使って、自分で試してみよう」という流れがあるので、理解の定着度が全然違いました。
コースを終えた後に試してみたいこと
コースでは小さなサンプルアプリで基礎を固めますが、実務に持ち込むときに気になるのは「大きいプロジェクトでどう使うか」です。数百ファイルあるリポジトリだと、/compact で会話を要約したり、@ で渡すファイルを絞ったりする工夫が要りそうです。このあたりは自分のプロジェクトで試しながら感覚をつかんでいきたいと思っています。
また、プロンプトの書き方で結果がけっこう変わるので、「こう聞くとうまくいく／いかない」のパターンを自分なりに蓄積していくのが次のステップかなと思っています。
チームへの展開も考えています。コースの Ch04〜Ch05 で学んだエージェントとスキルの定義を、実際のプロジェクトのリポジトリに入れてみて、チームメンバーに使ってもらうところまでやりたいです。レビュー基準の統一やコミットメッセージのフォーマット自動化など、効果が見えやすいところから始めてみようと思います。
記事執筆時点の最新アップデート
コースの内容は安定していますが、GitHub Copilot CLI 本体は毎日のようにアップデートされています。コースの検証は v1.0.18 で行いましたが、記事公開時点では v1.0.20 まで出ています。特に注目の新機能をまとめて紹介します。
-
OpenTelemetry モニタリング（v1.0.20）:
copilot help monitoringで設定方法を確認できるように。サブエージェントのスパンやストリーミングの応答時間なども計測可能に -
/yoloの永続化（v1.0.20）:/yoloと--yoloの挙動が統一され、/restart後も状態が保持されるように -
MCP 設定の永続化（v1.0.19）:
/mcp enableと/mcp disableの設定がセッションをまたいで保持されるように - Critic エージェント（v1.0.18）: Plan モードで作った計画を別のモデルが自動レビューしてくれます。計画の穴を事前に潰せます
- ビルトインスキル（v1.0.17）: CLI に最初から組み込まれたスキルが追加されました。GitHub Copilot cloud agent の環境カスタマイズガイドなど
-
/share html（v1.0.15）: セッションを対話型 HTML としてエクスポートできます。調査結果の共有に便利です -
/mcp auth（v1.0.15）: MCP サーバーの OAuth 認証をコマンドで管理できます。アカウント切り替えにも対応 -
/rewindタイムラインピッカー（v1.0.13）: 直前だけでなく、会話の任意の地点まで巻き戻せるように進化しました - モノレポ対応（v1.0.11）: カスタム命令・エージェント・スキル・MCP の定義ファイルがワーキングディレクトリから Git ルートまで全階層で検出されます
- 複数セッション（v1.0.10）: 複数のセッションを並行して走らせる実験的サポートです
利用できるモデルも増えていて、/model で切り替えられます。
| ベンダー | モデル例 |
|---|---|
| Anthropic | Claude Sonnet 4.5/4.6、Claude Opus 4.5/4.6、Claude Haiku 4.5 |
| OpenAI | GPT-5.2、GPT-5.3-Codex、GPT-5.4、GPT-5.4-mini |
| Gemini 2.5 Pro、Gemini 3 Flash、Gemini 3.1 Pro |
おわりに
「GitHub Copilot CLI、名前は知ってるけど使ったことない」という方にはちょうどいいコースだと思います。ターミナル作業が多い方、SSH でリモート開発する方には特に刺さると思います。
個人的にいちばんの収穫は、エージェントとスキルの使い分けが整理できたことです。チームのレビュー基準をエージェント定義に落とし込んで、コミットメッセージのフォーマットはスキルで自動化して…というのを自分のプロジェクトでもやってみようと思っています。
また、コースを通して感じたのは、GitHub Copilot CLI は単なる「ターミナルで使えるチャット」ではないということです。@ でコンテキストを明示的にコントロールできること、エージェント・スキル・MCP をファイルベースで定義して Git 管理できること、CI/CD に組み込める Programmatic モードがあること。これらは VS Code の GitHub Copilot Chat とは異なる、CLI ならではの強みです。
特にチームで使う場合の可能性を感じました。レビュー基準やコミット規約をエージェントやスキルとしてリポジトリにコミットしておけば、チームメンバー全員が同じ AI アシスタントの恩恵を受けられます。属人化しがちなレビュー観点やコーディング規約を、コードと一緒にバージョン管理できるのは大きいと思います。
GitHub Copilot CLI は毎日のようにアップデートされていて、この記事を書いている間にも新しいバージョンが出ていました。進化のスピードが速いので、早めに触っておくと今後のキャッチアップもしやすくなるはずです。
ローカルで始めて、README の日本語化からやってみてください。コースの学びと実践が同時に体験できます!
再掲しておきます!ぜひ!
また、合わせてこういった記事も書きましたのでよろしくお願いします。
参考リンク
公式ドキュメント
- GitHub Copilot CLI ドキュメント
- GitHub Copilot CLI コマンドリファレンス
- GitHub Copilot で利用可能な AI モデル一覧
- GitHub Copilot 無料プラン
コース関連
関連記事
免責事項
本記事は筆者個人の見解であり、所属組織の公式見解ではありません。記事中のコマンドやコード例は、環境によって動作が異なる場合があります。また､記載されたサービスや機能はプレビュー段階のものを含み、仕様は予告なく変更される場合があります。
本記事は情報提供を目的としており、2026年4月8日時点の情報に基づいています。本記事について、内容の正確性・完全性は保証されず、誤りを含む可能性があります。公式ドキュメントで最新情報をご確認ください。記事内のコードサンプルおよび筆者のGitHubリポジトリは自己責任でご利用ください。本記事内容の利用によって生じたいかなる損害（サービスの中断、データ損失、営業損失等を含む）についても、著者は一切の責任を負いません。本記事に掲載されている各社製品・サービスは各社の利用規約に従ってご利用ください。
Discussion