公式チュートリアル「GitHub Copilot CLI for Beginners」ハンズオンリポジトリを進めていきます！
このチュートリアルは (2026 年 3 月現在) 7 章までありますが、
今回は、第 3 章（開発ワークフローへの組み込み方）をざっくり和訳しながら進めていこうと思います。
前回/前々回の記事
第 0 章 環境構築編
第 1 章 操作モードの説明
第 2 章 基本用語やコンテキストについてなどの説明
🗺️ ハンズオンの全体像
2026/03/18 現在、第 0 章から第 7 章まであります。
今回はこの第 3 章を進めていきましょう。
| 章 | タイトル | 学べる内容 |
|---|---|---|
| 0 | 🚀 クイックスタート | インストールと動作確認 |
| 1 | 👋 最初の一歩 | ライブデモ + 3 つの操作モード |
| 2 | 🔍 コンテキストと会話 | 複数ファイルのプロジェクト分析 |
| 3 | [ 今ここ！→ ] ⚡ 開発ワークフロー | コードレビュー、デバッグ、テスト生成 |
| 4 | 🤖 特化型 (Specialized) AI アシスタントの作成 | ワークフロー用のカスタム AI エージェント |
| 5 | 🛠️ 繰り返し作業の自動化 | 自動で読み込まれるスキルの作成 |
| 6 | 🔌 GitHub・データベース・API との接続 | MCP サーバとの連携 |
| 7 | 🎯 すべてを組み合わせる | すべてを組み合わせた実践的ワークフロー |
🎯 ゴール（Learning Objectives）
今まで (第 0 - 2 章) は「使い方」の説明だったのに対し、
今回の章は「日常の開発ワークフローにどう組み込むか」にフォーカスしています。
- GitHub Copilot CLI を使って包括的なコードレビューを実行する
- レガシーコードを安全にリファクタリングする
- AI の支援を受けながらデバッグする
- テストコードを自動生成する
- GitHub Copilot CLI を Git のワークフローに統合する
🗺️ 全体像
コアとなる 5 つのワークフロー
開発の主要タスクを 5 つに分解し、それぞれで Copilot を使います：
| ＃ | 項目 | 説明 |
|---|---|---|
| 1 | コードレビュー | 人間レビューの補助ではなく「前処理としての AI レビュー」 |
| 2 | リファクタリング | テストを先に生成して安全に変更 |
| 3 | デバッグ | セキュリティ脆弱性の発見も可能 |
| 4 | テスト | pytest などで自動テスト生成 など |
| 5 | Git Integration | commit message 自動生成, PR description 作成 など |
これらを上から順に詳しく見ていきましょう
1. コードレビュー
1-1. 基本的なレビュー
この例では @ 記法を使ってファイルを指定し、Copilot CLI にその内容へ直接アクセスさせてレビューを行います。
copilot
> @samples/book-app-project/book_app.py のコード品質をレビューして
出力例）
1-2. 入力バリデーションのレビュー
特定の観点（ここでは入力バリデーション）に絞ってレビューしたい場合は、
プロンプト内でチェックしてほしい項目を明示します。
@samples/book-app-project/utils.py を入力バリデーションの観点でレビューして。確認項目：バリデーション不足、エラーハンドリングの抜け、エッジケース
1-3. 複数ファイルにまたがるプロジェクトレビュー
@ を使ってディレクトリ全体を指定すると、Copilot CLI がプロジェクト内のすべてのファイルを一度にスキャンしてレビューできます。
copilot
> @samples/book-app-project/ このプロジェクト全体をレビューして。
\ 発見した問題を重要度別に分類した Markdown のチェックリストとして出力して
1-4. インタラクティブなコードレビュー
複数ターンの会話を使うことで、より深く掘り下げたレビューができます。
最初は広くレビューし、その後はセッションをリセットせずに追加の質問をしていきます。
copilot
> @samples/book-app-project/book_app.py このファイルを以下の観点でレビューして：
> - 入力バリデーション
> - エラーハンドリング
> - コードスタイルとベストプラクティス
# [結果] Copilot CLI が詳細なレビューを提供
> ユーザー入力の処理について、見落としているエッジケースはある？
# [結果] Copilot CLI が空文字や特殊文字などの問題点を提示
> 見つかったすべての問題を、重要度順に整理したチェックリストにして
# [結果] Copilot CLI が優先度付きの対応項目を生成
1-5. レビューチェックリストのテンプレート
Copilot CLI に対して、出力形式を明示的に指定することもできます。
ここでは、Issue にそのまま貼り付けられる「重要度別の Markdown チェックリスト」を生成させています。
copilot
> @samples/book-app-project/ をレビューして、
> 以下の分類で問題点の Markdown チェックリストを作成して：
> - Critical（データ消失リスク、クラッシュ）
> - High（バグ、誤った挙動）
> - Medium（パフォーマンス、保守性）
> - Low（スタイル、軽微な改善）
↓
1-6. Git の変更内容を理解する（/review を使う前に重要）
/review コマンドを使う前に、Git における 2 種類の変更を理解しておく必要があります。
| 変更の種類 | 意味 | 確認方法 |
|---|---|---|
| ステージ済み変更（Staged changes） |
git add で次のコミット対象としてマークしたファイル |
git diff --staged |
| 未ステージ変更（Unstaged changes） | 変更はしているが、まだ git add していないファイル |
git diff |
git クイックリファレンス
# クイックリファレンス
git status # ステージ済み・未ステージ両方を表示
git add file.py # ファイルをステージする
git diff # 未ステージの変更を表示
git diff --staged # ステージ済みの変更を表示
1-7. /review コマンドの使い方
/review コマンドは、組み込みの コードレビュー エージェント を呼び出します。
このエージェントは、ステージ済み・未ステージの変更を対象に、ノイズの少ない実用的なフィードバックを出すよう最適化されています。
通常のプロンプトを書く代わりに、スラッシュコマンドで専用エージェントを起動します。
copilot
> /review
# ステージ済み・未ステージの変更を対象にコードレビューを実行
# 実用的で焦点の絞られたフィードバックを提供
> /review 認証処理におけるセキュリティ問題をチェックして
# 特定の観点に絞ったレビューも可能
💡 Tip:
コードレビューエージェントは「変更がある状態」で最も効果を発揮します。
git add でファイルをステージしてから実行すると、より的確なレビューが得られます。
2. リファクタリング
コードの再構成、関心の分離、エラーハンドリングの改善
2-1. シンプルなリファクタリング
まずはシンプルな改善から始めます。
以下は book app を対象にした例です。各プロンプトでは、@ でファイルを指定しつつ、具体的なリファクタリング内容を指示しています。これにより Copilot CLI は何を変更すべきか正確に理解できます。
copilot
# 例１
> @samples/book-app-project/book_app.py コマンド処理が
> if/elif チェーンになっています。
> 辞書ディスパッチパターンにリファクタリングしてください
# 例２
> @samples/book-app-project/utils.py すべての関数に型ヒントを追加してください
# 例３
> @samples/book-app-project/book_app.py 書籍表示ロジックを
> utils.py に切り出して、関心の分離を改善してください
💡 リファクタリング初心者の方へ：
まずは型ヒントの追加や変数名の改善など、シンプルな変更から始めましょう。複雑な変換はその後に取り組むのがおすすめです。
2-2. 関心の分離（Separation of Concerns）
訳註：「 関心の分離（Separation of Concerns） 」
ソフトウェアを機能や役割（関心事）ごとに分割し、独立性を高める設計原則。
巨大なコードを小さな単位に分け、コードの可読性・保守性・再利用性を向上させる
1つのプロンプト内で複数のファイルを @ で指定することで、Copilot CLI はそれらのファイル間でコードを移動させるリファクタリングも行えます。
copilot
> @samples/book-app-project/utils.py @samples/book-app-project/book_app.py
> utils.py にロジックと print 文が混在しています。
> 表示処理とデータ処理を分離するようにリファクタリングしてください
2-3. エラーハンドリングの改善
関連する複数のファイルを指定し、横断的な課題（ここではエラーハンドリング）を説明することで、Copilot CLI は一貫性のある修正案を提示できます。
copilot
> @samples/book-app-project/utils.py @samples/book-app-project/books.py
> これらのファイルではエラーハンドリングが統一されていません。
> カスタム例外を使った統一的なアプローチを提案してください
2-4. ドキュメントの追加
docstring に含めてほしい内容を箇条書きで具体的に指定することで、より精度の高いドキュメントを生成できます。
copilot
> @samples/book-app-project/books.py
> すべてのメソッドに包括的な docstring を追加してください：
> - 引数の型と説明を含める
> - 戻り値を明記する
> - 発生しうる例外を記述する
> - 使用例を追加する
2-5. テストを活用した安全なリファクタリング
複数ターンの会話でリクエストを連鎖させます。
まずテストを生成し、その後にリファクタリングを行うことで、安全に変更できます。
copilot
> @samples/book-app-project/books.py リファクタリングの前に、
> 現在の挙動に対するテストを生成してください
# まずテストを取得
> 次に、ファイル操作にコンテキストマネージャを使うように
> BookCollection クラスをリファクタリングしてください
# テストがあるので安心してリファクタリングできる（挙動の維持を検証可能）
3. デバッグ
バグの特定、セキュリティ監査、複数ファイルにまたがる問題の追跡
3-1. シンプルなデバッグ
まずは「何が起きているか」を説明するところから始めます。
以下は、バグ入りの book app を使った代表的なデバッグパターンです。
各プロンプトでは @ でファイルを指定しつつ、明確な「症状」を伝えることで、Copilot CLI が原因の特定と診断を行います。
copilot
# パターン：「XのはずなのにYになる」
> @samples/book-app-buggy/books_buggy.py "The Hobbit" を検索しても
> データに存在するのに結果が返らない。原因をデバッグして
# パターン：「想定外の挙動」
> @samples/book-app-buggy/book_app_buggy.py 存在しない本を削除すると、
> 削除されたと表示されてしまう。原因を見つけて
# パターン：「結果がおかしい」
> @samples/book-app-buggy/books_buggy.py 1冊を既読にすると、
> すべての本が既読になる。このバグは何？
💡 デバッグのコツ：
- 「症状（実際に起きていること）」(what you see)
- 「期待値（本来どうなるべきか）」(what should happen)
を明確に書きましょう。
あとは Copilot CLI が原因を推測してくれます。
3-2. 「バグ探偵」 - AI が "関連するバグ" も見つける
ここでコンテキストを活用したデバッグの真価が発揮されます。
ファイル全体を @ で渡し、「ユーザーから報告された症状」だけを伝えてみてください。
Copilot CLI は原因を追跡し、さらに周辺のバグも見つけてくれる可能性があります。
copilot
> @samples/book-app-buggy/books_buggy.py
>
> ユーザー報告：「著者名で検索すると部分一致が効かない」
> なぜこの問題が起きるのかデバッグして
↑ 前のセクションですでにプロジェクト全体を舐めており、そのコンテキストを保持しているため、一瞬で結果を返してくれました
3-2-1. なぜ重要か (Why this matters)
Copilot CLI はファイル全体を読み、バグ報告の文脈を理解した上で、具体的な修正案と明確な説明を提示します。
💡 Bonus:
ファイル全体を解析するため、依頼していない他の問題も見つかることがあります。
例えば著者検索の修正中に、find_book_by_title の大文字小文字問題にも気づくかもしれません。
3-3. 実務におけるセキュリティ補足
自分のコードのデバッグも重要ですが、本番環境ではセキュリティ脆弱性の理解も極めて重要です。
次の例では、見慣れないコードに対してセキュリティ監査を依頼しています。
copilot
> @samples/buggy-code/python/user_service.py
> このPythonのユーザーサービスに存在するセキュリティ脆弱性をすべて見つけて
このファイルには、本番アプリケーションでよく見られるセキュリティパターンが含まれています。
よく出てくるセキュリティ用語：
-
SQLインジェクション (SQL Injection:)：
ユーザー入力をそのままSQLに埋め込むことで、攻撃者が不正なクエリを実行できてしまう脆弱性
-
パラメータ化クエリ (Parameterized queries)：
プレースホルダ（?）を使ってユーザーデータとSQLを分離する安全な手法
-
レースコンディション (Race condition)：
複数の処理が同時に実行され、互いに干渉して不整合が起きる状態
-
XSS（クロス サイト スクリプティング） (Cross-Site Scripting)：
Webページに悪意のあるスクリプトを埋め込まれる攻撃
3-4. エラーの理解
スタックトレースをそのままプロンプトに貼り付け、さらに @ で対象ファイルを指定することで、Copilot CLI はエラーとソースコードを対応付けて原因を説明できます。
copilot
> 次のエラーが出ています：
> AttributeError: 'NoneType' object has no attribute 'title'
> at show_books (book_app.py:19)
>
> @samples/book-app-project/book_app.py
> なぜこのエラーが発生するのか、どう修正すべきか説明してください
3-5. テストケースを使ったデバッグ
具体的な入力と実際の出力を説明することで、Copilot CLI に再現可能なケースを与え、より正確に原因を推測させることができます。
copilot
> @samples/book-app-buggy/books_buggy.py remove_book 関数にバグがあります。
> "Dune" を削除しようとすると "Dune Messiah" も一緒に削除されてしまいます。
> 原因を説明し、修正方法を提示してください
3-6. コードを横断した問題追跡
複数のファイルを指定し、データの流れを追跡させることで、問題がどこで発生しているかを特定できます。
copilot
> ユーザーから「本の一覧番号が1ではなく0から始まる」と報告があります。
> @samples/book-app-buggy/book_app_buggy.py @samples/book-app-buggy/books_buggy.py
> リスト表示の処理フローを追跡して、どこで問題が発生しているか特定してください
3-7. データ関連の問題を理解する
コードと、そのコードが読み込むデータファイルの両方を指定することで、Copilot CLI は全体像を理解し、より適切なエラーハンドリングの改善案を提示できます。
copilot
> @samples/book-app-project/data.json @samples/book-app-project/books.py
> JSONファイルが壊れることがあり、そのときアプリがクラッシュします。
> これを安全に処理するにはどうすればよいですか？
4. テスト生成
包括的なテストとエッジケースを自動生成
4-1. 「テスト爆発(Test Explosion)」 - 2つのテスト vs 15以上のテスト
通常、人間が手動でテストを書く場合、作られるのはせいぜい 2 〜 3 個程度です：
- 正常系のテスト
- 異常系のテスト
- エッジケースのテスト
では、Copilot CLI に「包括的なテスト生成」を依頼するとどうなるでしょうか？
以下のプロンプトでは、@ でファイルを指定しつつ、箇条書きでテスト対象を明示することで、網羅的なテスト生成を促しています。
copilot
> @samples/book-app-project/books.py
> 包括的な pytest テストを生成してください。
> 以下を含めてください：
> - 書籍の追加
> - 書籍の削除
> - タイトルによる検索
> - 著者による検索
> - 既読フラグの設定
> - 空データに対するエッジケース
4-1-1. 出力例
生成される内容：以下のような、15件以上の包括的なテスト
class TestBookCollection:
# 正常系
def test_add_book_creates_new_book(self):
...
def test_list_books_returns_all_books(self):
...
# 検索機能
def test_find_book_by_title_case_insensitive(self):
...
def test_find_book_by_title_returns_none_when_not_found(self):
...
def test_find_by_author_partial_match(self):
...
def test_find_by_author_case_insensitive(self):
...
# エッジケース
def test_add_book_with_empty_title(self):
...
def test_remove_nonexistent_book(self):
...
def test_mark_as_read_nonexistent_book(self):
...
# データ永続化
def test_save_books_persists_to_json(self):
...
def test_load_books_handles_missing_file(self):
...
def test_load_books_handles_corrupted_json(self):
...
# 特殊文字
def test_add_book_with_unicode_characters(self):
...
def test_find_by_author_with_special_characters(self):
...
30秒で、人間なら1時間かけて考えるレベルのエッジケースまで含んだテストが手に入ります。
4-2. ユニットテスト
特定の関数に絞り、テストしたい入力パターンを明示することで、Copilot CLI はより的確で網羅的なユニットテストを生成できます。
copilot
> @samples/book-app-project/utils.py
> get_book_details 関数に対する包括的な pytest テストを
> 生成してください。
> 以下をカバーしてください：
> - 正常な入力
> - 空文字列
> - 不正な年のフォーマット
> - 非常に長いタイトル
> - 著者名に含まれる特殊文字
テストコードが生成されます：
(↑ 特に何も指示してないのに、たとえば日本語 (Unicode) の入力も大丈夫かのテストも入れてくれてる)
4-3. テストの実行方法
ツールチェーンに関する操作は、自然言語で質問するだけでOKです。
Copilot CLI が適切なコマンドを生成してくれます。
copilot
> テストを実行するにはどうすればいい？pytest のコマンドを教えて
Copilot CLI の回答例
cd samples/book-app-project && python -m pytest tests/
# 詳細表示の場合：
python -m pytest tests/ -v
# print文を表示する場合：
python -m pytest tests/ -s
4-4. 特定のシナリオに対するテスト
より高度で難しいケースを列挙することで、Copilot CLI は単なる正常系を超えたテストを生成します。
copilot
> @samples/book-app-project/books.py
> 以下のシナリオに対するテストを生成してください：
> - 同じタイトル・著者の重複書籍の追加
> - タイトルの部分一致による削除
> - コレクションが空の状態での検索
> - 保存時のファイル権限エラー
> - 書籍コレクションへの同時アクセス
4-5. 既存ファイルへのテスト追加
既存のテストに対して「追加のテスト」を依頼することで、既存ケースを補完する新たなテストを生成できます。
copilot
> @samples/book-app-project/books.py
> find_by_author 関数に対して、以下のエッジケースを含む追加テストを生成してください：
> - ハイフンを含む著者名（例："Jean-Paul Sartre"）
> - 複数の名前を持つ著者
> - 空文字の著者名
> - アクセント付き文字を含む著者名
5. Git 連携 (Git Integration)
コミットメッセージ、Pull request の descriptions 生成、/pr、/delegate、/diff の活用
💡 前提知識
このワークフローは、基本的な Git の知識（ステージング、コミット、ブランチ操作）を前提としています。
5-1. コミットメッセージの生成
この例では、-p（インラインプロンプト）オプションとシェルのコマンド置換を組み合わせて、
git diff の出力をそのまま Copilot CLI に渡し、一発でコミットメッセージを生成しています。
$(...) の構文は、括弧内のコマンドを実行し、その出力を外側のコマンドに埋め込む仕組みです。
例) $(git diff --staged)
# 変更内容を確認
git diff --staged
# Conventional Commit 形式でコミットメッセージを生成
# （例："feat(books): add search" や "fix(data): handle empty input" のような構造化された形式）
copilot -p "Generate a conventional commit message for: $(git diff --staged)"
# 出力例：
# "feat(books): 著者名の部分一致検索を追加
#
# - find_by_author を部分一致対応に更新
# - 大文字小文字を区別しない比較を追加
# - 著者検索時のユーザー体験を改善"
5-2. 変更内容の説明
git show の出力を -p オプションで Copilot CLI に渡すことで、直前のコミット内容を自然言語で要約できます。
# このコミットは何を変更したのか？
copilot -p "このコミットの内容を説明してください: $(git show HEAD --stat)"
訳註）
git show HEAD --stat は、最新コミット (HEAD) の情報を表示するコマンドです。
-
git show: コミットの詳細を表示 -
HEAD: 現在チェックアウトしているブランチの最新コミットを指す -
--stat: 差分の全文ではなく、更新ファイル名と 追加/削除行数の要約だけ表示
5-3. PR（プルリクエスト）の説明文生成
git log の出力と構造化されたプロンプトを組み合わせることで、PRの説明文を自動生成できます。
# ブランチの変更内容からPR説明を生成
copilot -p "これらの変更に対するプルリクエストの説明を生成してください:
$(git log main..HEAD --oneline)
以下を含めてください：
- 変更内容の概要
- なぜこの変更を行ったか
- 実施したテスト
- 破壊的変更の有無（yes/no）"
訳註）
git log main..HEAD --oneline は、現在のブランチにあって main には無いコミットを一覧表示します。
-
main..HEAD: main から分岐した後のコミットだけを抽出する範囲指定 -
--oneline: 各コミットを 1 行（短縮ハッシュ + メッセージ）で表示
PR を出す前に「自分のブランチで何をコミットしたか」を確認するのに便利です
5-4. インタラクティブモードでの /pr コマンドの利用
Copilot CLI のインタラクティブモードでブランチ上の作業をしている場合、/pr コマンドでプルリクエストを操作できます。
- PR の確認
- 新規 PR の作成
- 既存 PR の修正
- 状況に応じた自動判断
copilot
> /pr [view|create|fix|auto]
5-5. push 前のレビュー
git diff main..HEAD を -p プロンプトで渡すことで、push 前に最終チェックができます。
# push前の最終確認
copilot -p "pushする前に、この変更に問題がないかレビューしてください:
$(git diff main..HEAD)"
5-6. /delegate によるバックグラウンド処理
/delegate コマンドを使うと、処理を GitHub Copilot のクラウドエージェントに委任できます。
また、& を使ったショートカットも利用可能です。
copilot
> /delegate ログインフォームに入力バリデーションを追加して
# またはショートカット：
> & READMEのヘッダーのタイポを修正して
# Copilot CLI の動作：
# 1. 新しいブランチを作成して変更をコミット
# 2. Draftのプルリクエストを作成
# 3. GitHub上でバックグラウンド処理を実行
# 4. 完了後にレビューを依頼
これは、定義が明確なタスクを他に任せて、自分は別の作業に集中したいときに非常に有効です。
5-7. /diff を使ったセッション内変更の確認
/diff コマンドを使うと、現在のセッション中に行われたすべての変更を確認できます。
このスラッシュコマンドにより、Copilot CLI が変更した内容をコミット前に視覚的な差分としてチェックできます。
copilot
# いくつか変更を加えた後…
> /diff
# このセッションで変更されたすべてのファイルの差分を表示
# コミット前の確認に最適
6. クイックヒント：計画やコーディングの前にリサーチ /research する
ライブラリの調査、ベストプラクティスの理解、未知のトピックの探索をしたい場合は、コードを書く前に /research を使って深い調査を行いましょう。
copilot
> /research CLIアプリでユーザー入力を検証するための最適なPythonライブラリは？
Copilot は GitHub リポジトリやWeb上の情報を検索し、参考情報付きの要約を返します。
新しい機能を実装する前に、適切な技術選定を行うのに非常に有効です。
↓ リサーチした結果 (アウトプット) を格納するところも作ってくれました
めっちゃ長い詳細レポートをマークダウンとして出力してくれました
結果は /share で共有することもできます。
💡 Tip:
/research は /plan の前に使うと効果的です。
まず調査し、その後に実装計画を立てる、という流れが推奨されます。
7. まとめ：バグ修正ワークフロー
報告されたバグを修正するための一連の流れは次の通りです。
# 1. バグの内容を理解する
copilot
> ユーザー報告：「著者名で検索しても部分一致が機能しない」
> @samples/book-app-project/books.py 分析して原因を特定して
# 2. 問題をデバッグ（同じセッション内で続ける）
> 分析結果をもとに、find_by_author関数を表示して問題を説明して
> find_by_author関数を修正して、部分一致に対応させて
# 3. 修正に対するテストを生成
> @samples/book-app-project/books.py pytestのテストを生成して：
> - 著者名の完全一致
> - 著者名の部分一致
> - 大文字小文字を区別しない検索
> - 該当する著者が見つからない場合
# 4. コミットメッセージを生成
copilot -p "Generate commit message for: $(git diff --staged)"
# 出力例: "fix(books): support partial author name search"
7-1. バグ修正ワークフローまとめ
| step | 内容 | Copilotコマンド |
|---|---|---|
| 1 | バグを理解する | > [バグ内容] @対象ファイル.py 分析して原因を特定 |
| 2 | 詳細分析を取得 | > 関数を表示して問題を説明して |
| 3 | 修正を実装 | > [具体的な問題] を修正して |
| 4 | テストを生成 | > [特定のシナリオ] のテストを生成 |
| 5 | コミット | copilot -p "Generate commit message for: $(git diff --staged)" |
8. まとめ（Summary）
重要なポイント
- コードレビュー は、具体的なプロンプトを使うことで網羅的になる
- リファクタリング は、先にテストを生成することで安全性が高まる
- デバッグ は、エラーとコードの両方を提示することで精度が上がる
- テスト生成 では、エッジケースや異常系を含めるべき
- Git 連携 により、コミットメッセージや PR 説明の作成を自動化できる
📋 クイックリファレンス:
コマンド一覧やショートカットは
GitHub Copilot CLI の公式リファレンスを参照してください。
9. ✅ Checkpoint: 基本スキルの習得完了
おめでとうございます！
第 3 章まで頑張りましたね！
これで GitHub Copilot CLI を実務で活用するための基本スキルが身につきました。
| スキル | 章 | できるようになったこと |
|---|---|---|
| 基本コマンド | 第1章 | インタラクティブモード、プランモード、-p（プログラム実行モード）、スラッシュコマンドの利用 |
| コンテキスト | 第2章 |
@ によるファイル参照、セッション管理、コンテキストウィンドウの理解 |
| ワークフロー | 第3章 | コードレビュー、リファクタリング、デバッグ、テスト生成、Git連携 |
第4章〜第6章では、さらに強力な機能が紹介されており、
学ぶことでより高度な活用が可能になります。
10. 次は？
残りの章では、Copilot CLI の機能をさらに拡張する内容を扱います。
| 章 | 内容 | 使いたくなる場面 |
|---|---|---|
| 第4章: Agents | 専門的なAI人格を作る | フロントエンドやセキュリティなど専門家が欲しいとき |
| 第5章: Skills | タスク用の命令を自動読み込み | 同じプロンプトを何度も使うとき |
| 第6章: MCP | 外部サービスと連携 | GitHubやDBなどのリアルタイムデータが必要なとき |
とくに、つぎの
『第4章：Agents とカスタム命令』
では、次の内容を学びます：
- 組み込みエージェント（/plan, /review）の活用
-
.agent.mdファイルを使った専門エージェントの作成（フロントエンド専門家、セキュリティ監査など） - マルチエージェントの協調パターン
- プロジェクト標準を定義するカスタム命令ファイル
残りの章もがんばりましょう！