GitHub Copilot のエージェントモードのプロンプト構造を徹底解析

Posted at 2025-12-27

はじめに

GitHub Copilot は、単なるコード補完ツールではなく、高度なプロンプトエンジニアリング技術に基づいた AI コーダーです。ユーザーが入力したリクエストに対して、実際には複数層のプロンプトが組み合わされて AI に渡されます。

本記事では、GitHub Copilot が実際に受け取るプロンプト構造を詳しく分析し、その設計思想とプロンプトエンジニアリングのベストプラクティスを解説します。対象読者は、AI 活用に興味のある技術者、プロンプトエンジニアリングを学びたい開発者です。

検証環境と方法論

本記事の内容は、以下の環境・方法で検証しました。

検証日: 2025年12月27日
VSCode バージョン: 1.107
検証方法: Chat Debug view（VSCode 公式ドキュメントに記載のデバッグ機能）からログ内容を確認

Chat Debug view は、Copilot Chat の内部動作を確認できる公式のデバッグ機能です。この機能を通じて、実際に AI に渡されるプロンプトの構造を観察しました。

本記事の内容はログの解析に基づくため、解釈の誤りが含まれている可能性があります。また、プロンプト構造は今後のアップデートで変更される可能性があります。

なぜプロンプト構造を理解する必要があるのか

GitHub Copilot のプロンプト構造を理解することで、以下のメリットがあります：

効果的な指示の仕方を学べる: どのような情報が AI に渡されているかを知ることで、より効果的なリクエストが可能になります
プロンプトエンジニアリングのベストプラクティスを習得できる: Microsoft が設計した高度なプロンプト構造から、実践的な技術を学べます
AI コーダーの挙動を理解できる: なぜ特定の行動をとるのか、その背景を理解できます
独自の AI エージェント設計に応用できる: 学んだ設計思想を、自分のプロジェクトに活かせます

GitHub Copilot が受け取る3層のプロンプト構造

GitHub Copilot のプロンプトは、以下の3層構造になっています：

第1層：システムプロンプト
  ↓ （AI コーダーとしての基本設計）
第2層：ワークスペース情報
  ↓ （環境に応じた最適化）
第3層：ユーザリクエスト + コンテキスト
  ↓ （実際のタスク内容）
AI の応答

3つの層の役割と関係性

各層には明確な役割があります：

第1層（システムプロンプト）: 環境に依存しない、AI コーダーとしての普遍的な指示。ツール活用戦略、ワークフロー、コミュニケーションスタイルなどを定義
第2層（ワークスペース情報）: ユーザーの環境に応じた動的な情報。OS、ワークスペース構造、現在のファイルなどを提供
第3層（ユーザリクエスト）: 実際のユーザー入力に加え、日付情報、リマインダー指示、添付ファイルなどを追加

この階層構造により、汎用的な指示と環境固有の情報を分離し、効率的なプロンプト設計を実現しています。

第1層：システムプロンプト - AI コーダーの設計思想

システムプロンプトは、GitHub Copilot の「脳」とも言える重要な部分です。ここでは、AI がどのように振る舞うべきかを詳細に定義しています。

システムプロンプトの目的

システムプロンプトでは、まず AI の基本的な役割を明確にしています：

アイデンティティ: 名前は「GitHub Copilot」、使用モデル（例：Claude Sonnet 4.5）を明示
ポリシー遵守: Microsoft のコンテンツポリシー、著作権保護、有害コンテンツの拒否
基本姿勢: 簡潔で客観的な回答、ユーザー要求への厳密な対応

ツール活用の戦略

GitHub Copilot には多数のツールが用意されていますが、システムプロンプトではそれらの使い分けを詳細に指示しています：

コンテキスト収集系ツールの使い分け

read_file: ファイル内容を読み取る際は、複数回に分けず一度に大きな範囲（2000行）を読むよう指示
- これにより API 呼び出し回数を削減し、コンテキストの一貫性を保つ
semantic_search: ファイルや関数の場所が不明な場合に使用
- キーワードベースではなく、意味的な検索を実行
grep_search: 特定ファイル内の概要把握に使用
- read_file よりも効率的に該当箇所を発見できる
fetch_webpage: URL がコンテキストに含まれる場合は必ず使用
- さらに、関連リンクを再帰的に辿るよう指示されている

ファイル編集ツールの戦略

ファイル編集は最もコストの高い操作であるため、特に詳細な指示があります：

コンテキストの重要性: 編集前に必ず関連箇所を読み、変更箇所を一意に特定できるよう前後3行のコンテキストを含める
段階的な変更: 小さく、テスト可能な増分変更を推奨
エラーループの回避: 同じファイルで3回以上失敗した場合は、別のアプローチを検討

8ステップのワークフロー設計

システムプロンプトの中核となるのが、構造化されたワークフローです。これは AI コーダーとしての思考プロセスを8つのステップに分解しています：

ステップ1: 問題の深い理解

期待される動作は何か
エッジケースは何か
潜在的な落とし穴は何か
コードベース全体における位置付けは何か

この段階では、すぐにコードを書くのではなく、問題の本質を見極めることが強調されています。

ステップ2: コードベースの調査

関連ファイルとディレクトリの探索
キー関数、クラス、変数の検索
根本原因の特定
理解の継続的な検証と更新

コンテキスト収集が不十分な場合でも、適切なツールを使って必要な情報を見つけ出すよう指示されています。

ステップ3: 詳細な計画の策定

具体的で検証可能な手順の明示
Todo リストの作成（manage_todo_list ツールを使用）
各ステップ完了後の進捗更新
重要: ステップ完了後、ユーザーに尋ねることなく次のステップに進む

このステップで特徴的なのは、AI が自律的に作業を進めることが期待されている点です。

ステップ4: コード変更の実装

編集前に必ず関連ファイルを読む（2000行単位）
小さく、テスト可能な増分変更
環境変数が必要な場合は .env ファイルを自動作成
パッチ適用に失敗した場合は再試行

ステップ5: デバッグ

get_errors ツールで問題を確認
根本原因の特定（症状ではなく原因を解決）
仮説検証のための一時的なコード追加を許可
print 文、ログ、テストコードの活用

興味深いのは、デバッグのために一時的にコードを追加することが明示的に許可されている点です。

ステップ6: 頻繁なテスト

各変更後にテストを実行
表面的なテストだけでなく、隠れたテストも通過することを確認
テスト失敗時は根本原因を突き止める

GitHub Copilot がテスト環境で繰り返しテストを実行する背景がここで理解できます。

ステップ7: 修正完了まで反復

すべてのテストが通過するまで継続
3回以上同じファイルでループした場合は方針転換

ステップ8: 包括的な検証と反省

元の意図に立ち返る
追加テストを作成して正確性を確認
重要: Todo リストを必ず更新し、完了・スキップ・ブロック項目を明確にする

このワークフローの設計から、GitHub Copilot が単純な応答ではなく、体系的な問題解決プロセスを実行していることがわかります。

コミュニケーションガイドライン

技術的な正確性だけでなく、コミュニケーションスタイルにも詳細な指示があります：

トーン: 温かく親しみやすい、プロフェッショナルな口調
簡潔性: 短く要点を押さえた応答
批判的思考: ユーザーからの訂正に対しても、すぐに従うのではなく深く考えて対応
ユーモア: 適切な場面では軽いウィットを交える

単なる機械的な応答ではなく、人間味のあるコミュニケーションを目指している点が注目されます。

出力フォーマット指定

ユーザーへの表示を最適化するため、出力フォーマットも詳細に指定されています：

Markdown 形式: 読みやすい構造化された応答
シンボル強調: クラス名、メソッド名、変数名はバッククォートで囲む（例：MyClass、handleClick()）
ファイルリンク: ワークスペース相対パスとMDリンク形式を使用（例：src/handler.ts）
数式表示: KaTeX を使用した数式の表示

これらの指示により、GitHub Copilot の応答が常に見やすく、クリック可能なリンク付きで表示されることが保証されています。

第2層：ワークスペース情報 - 環境に応じた最適化

第2層では、ユーザーの作業環境に固有の情報を提供します。これにより、汎用的なシステムプロンプトが、具体的な環境に適応します。

提供される環境情報

ワークスペース情報プロンプトには、以下の情報が含まれます：

OS 情報

The user's current OS is: Windows

この情報により、適切なターミナルコマンドを生成できます：

Windows: PowerShell コマンド
macOS/Linux: bash コマンド

また、パスの区切り文字（\ vs /）も正しく使い分けられます。

ワークスペース構造

I am working in a workspace with the following folders:
- c:\CodeStudy\Prompts

I am working in a workspace that has the following structure:
README.md
ai_coder/
  github_copilot/
    agent/
      basic.general.md
...

ワークスペースのツリー構造が提供されることで：

どのファイルを読むべきか判断できる
ファイルへの絶対パスを正確に構築できる
プロジェクトの全体構造を理解できる

注意点として、ワークスペースが大規模な場合、ツリー情報は省略されることがあります。その場合は、ツールを使って追加のコンテキストを収集するよう指示されています。

環境情報がもたらす価値

第2層の情報提供により、以下のメリットがあります：

コンテキストに応じた精度向上: OS やプロジェクト構造を理解することで、より適切な提案が可能
ツール呼び出しの正確性: 絶対パスを正しく構築でき、ファイル操作エラーを削減
プロジェクト理解の加速: 最初からプロジェクト構造を把握できるため、調査時間を短縮
一貫性のある動作: 環境情報を XML タグで構造化することで、AI が確実に認識できる

第3層：ユーザリクエスト - コンテキストの補強

第3層では、ユーザーが入力したリクエストに対して、追加情報とリマインダー指示が付与されます。

ユーザ入力に追加される情報

ユーザーのリクエストは、以下のような構造で補強されます：

コンテキスト情報

<context>
The current date is December 27, 2025.
</context>

現在の日付を提供することで、時間に依存するタスク（ログ分析、締め切り計算など）に対応できます。

エディタコンテキスト

<editorContext>
The user's current file is at: c:\CodeStudy\Prompts\readings\GithubCopilotのプロンプト.md
</editorContext>

ユーザーが現在開いているファイルの情報を提供することで：

「このファイル」という曖昧な指示を理解できる
関連ファイルを推測しやすくなる
作業コンテキストを維持できる

添付ファイルとコンテキスト

ユーザーが添付したファイル内容、選択範囲、スクリーンショットなどは <attachments> タグ内に含まれます。

リマインダー指示の意図

第3層で特に重要なのが、リマインダー指示です：

<reminderInstructions>
You are an agent - you must keep going until the user's query is completely resolved, 
before ending your turn and yielding back to the user. ONLY terminate your turn when 
you are sure that the problem is solved, or you absolutely cannot continue.

You take action when possible - the user is expecting YOU to take action and go to 
work for them. Don't ask unnecessary questions about the details if you can simply 
DO something useful instead.
</reminderInstructions>

この指示には、重要な設計思想が込められています：

自律性の強調

「完全に解決するまで続ける」という指示により、GitHub Copilot は：

不確実性に直面しても、自ら調査を続ける
ユーザーに頻繁に確認を求めず、推論に基づいて行動する
問題解決志向で、受動的にならない

行動優先の原則

「行動可能な場合は行動する」という指示により：

詳細を聞くよりも、まず有用なことを実行する
不必要な質問を避け、効率的に作業を進める
ユーザーの時間を節約する

これらの指示は、毎回のリクエストで繰り返されることで、AI が常に自律的な行動を取るよう強化されています。

重要な設計思想とベストプラクティス

GitHub Copilot のプロンプト構造から、以下の重要な設計思想とベストプラクティスが学べます。

1. 階層的なプロンプト設計

設計思想: 汎用的な指示と環境固有の情報を分離する

システムプロンプト: 変更頻度の低い、普遍的なルール
ワークスペース情報: セッションごとに変わる環境情報
ユーザリクエスト: リクエストごとに変わる具体的なタスク

応用: 自分のプロジェクトでも、プロンプトを階層化することで保守性と再利用性が向上します。

2. 構造化されたワークフロー

設計思想: 複雑なタスクを明確なステップに分解する

GitHub Copilot の8ステップワークフローは：

理解 → 調査 → 計画 → 実装 → デバッグ → テスト → 反復 → 検証

という自然な問題解決プロセスを体系化しています。

応用: AI エージェント設計では、曖昧な指示よりも具体的なステップを示す方が効果的です。

3. ツール使用の明確なガイドライン

設計思想: 各ツールの使用場面と注意点を明示する

read_file: 大きな範囲を一度に読む
semantic_search: ファイルの場所が不明な場合
grep_search: 特定ファイル内の概要把握

応用: ツールを提供するだけでなく、「いつ」「どのように」使うかを指示することで、適切な使用を促進できます。

4. 自律性と行動志向

設計思想: AI に判断と行動の権限を与える

「完全に解決するまで続ける」
「行動可能な場合は行動する」
「不必要な質問を避ける」

応用: 過度に制約するよりも、適切な判断基準を与えて自律性を持たせる方が、効率的な AI エージェントになります。

5. コンテキストの重要性

設計思想: 十分なコンテキストを収集してから行動する

編集前に2000行読む
変更箇所の前後3行を含める
不十分な場合はツールで追加収集

応用: AI の精度は、提供されるコンテキストの質と量に大きく依存します。

6. XML タグによる構造化

設計思想: 情報を明確に区分けして AI の理解を助ける

<environment_info>...</environment_info>
<workspace_info>...</workspace_info>
<editorContext>...</editorContext>
<reminderInstructions>...</reminderInstructions>

応用: 複雑な情報を扱う場合、XML や JSON などの構造化フォーマットを使うことで、AI の解析精度が向上します。

7. 段階的なエラー処理

設計思想: 失敗時の対応戦略を事前に定義する

パッチ適用失敗時は再試行
3回失敗したら方針転換
デバッグのための一時コード追加を許可

応用: エラーハンドリングの戦略を明示的に指示することで、AI がより柔軟に対応できます。

8. 出力フォーマットの標準化

設計思想: 一貫性のある、読みやすい出力を保証する

Markdown 形式
バッククォートでシンボル強調
クリック可能なファイルリンク

応用: ユーザー体験を向上させるため、出力フォーマットを明確に指定することが重要です。

プロンプトエンジニアリングへの応用

GitHub Copilot のプロンプト構造から学んだことを、実際のプロンプトエンジニアリングに応用できます。

自分のプロジェクトへの応用例

AI エージェント設計

# システムプロンプト（汎用ルール）
あなたは専門的なデータアナリストです。
以下のワークフローに従ってください：
1. データを理解する
2. 分析計画を立てる
3. 段階的に分析を実行
...

# 環境情報（動的情報）
<environment>
データソース: PostgreSQL
利用可能なツール: pandas, matplotlib, seaborn
</environment>

# ユーザリクエスト
<task>
売上データの傾向分析を実行してください
</task>

<reminder>
完全な分析レポートを生成するまで作業を続けてください
</reminder>

プロンプトテンプレートの構築

GitHub Copilot の構造を参考に、再利用可能なプロンプトテンプレートを作成できます：

基本テンプレート: 役割、ルール、禁止事項
環境テンプレート: プロジェクト固有の情報
タスクテンプレート: 具体的なリクエスト

効果的なリクエストの書き方

GitHub Copilot に対してリクエストを行う際、プロンプト構造を理解していれば、より効果的な指示ができます：

✅ 良い例

現在のファイルのエラーを修正してください。
関連するテストファイルも確認して、すべてのテストが通るようにしてください。

この指示は：

明確な目標がある
AI が自律的に作業できる
ワークフローに沿っている（理解 → 調査 → 修正 → テスト）

❌ 悪い例

エラーがあるかどうか教えてください