コンテンツにスキップ

インライン補完とCopilot Chatの実践活用

2.1 インライン補完の仕組みと効果的な活用方法

Section titled “2.1 インライン補完の仕組みと効果的な活用方法”

インライン補完は、エディタ上でコードを入力している最中に次に書かれるべきコードを予測し、グレーテキスト(ゴーストテキスト)として候補を表示する機能である。
Copilotは以下のコンテキストを分析して提案を合成する。

  • カーソル前後のコード(直前・直後の行)
  • エディタで開いている他のファイル
  • リポジトリのファイルパスや構造
  • プロジェクトで使用しているフレームワークや依存関係
flowchart LR
    A["`コード入力
    カーソル位置`"] --> B["`コンテキスト収集
    前後のコード・開いているファイル`"]
    B --> C["`LLMへ送信
    確率的推論`"]
    C --> D["`候補表示
    ゴーストテキスト`"]
    D --> E{"`ユーザー判断`"}
    E -->|Tab で採用| F["`コードに挿入`"]
    E -->|Esc で却下| G["`次の候補 or 入力継続`"]
操作VS CodeJetBrains
候補全体を採用TabTab
1単語ずつ部分採用Ctrl + →Ctrl + →
候補を却下EscEsc
次の候補を表示Alt + ]Alt + ]
前の候補を表示Alt + [Alt + [

インライン補完の品質は、Copilotに与えるコンテキストの質に大きく依存する。
以下の実践を心がけると補完精度が向上する。

ファイルの冒頭にインポート文や型定義を記述する: Copilotはファイル上部の情報を重視するため、使用するライブラリやフレームワークを明示的にインポートしておくと、それに沿った提案が得られやすい。

関連ファイルをエディタで開いておく: Copilotは開いているタブの内容もコンテキストとして利用する。
関連するインターフェース定義やモデル定義のファイルを開いておくと、型に合った提案が得られる。

意味のある変数名・関数名を使う: tempdata のような汎用的な名前よりも、userEmailAddresscalculateMonthlyRevenue のように意図が明確な名前を使うと、Copilotの提案精度が上がる。

小さなファイルに分割する: 1つのファイルに多くのロジックを詰め込むと、Copilotが参照するコンテキストが曖昧になる。
責務ごとにファイルを分割すると提案の質が向上する。

Next Edit Suggestions(次の編集提案)

Section titled “Next Edit Suggestions(次の編集提案)”

VS Code、Xcode、Eclipseでは、現在のカーソル位置での補完だけでなく、次にユーザーが編集するであろう場所を予測して補完を提示するNext Edit Suggestions機能が利用できる。
ガター領域に矢印アイコンが表示され、クリックすると提案内容にジャンプできる。

この機能は、たとえば関数のシグネチャを変更した後に、その関数の呼び出し箇所も同時に修正するような場面で特に有効である。

コメント駆動開発(Comment-Driven Development)は、先にコメントで意図や仕様を記述し、それをCopilotがコードに変換するアプローチである。
インライン補完の特性を最大限に活用する開発手法として広く実践されている。

flowchart TD
    A["`ステップ1
    関数の目的をコメントで記述`"] --> B["`ステップ2
    引数・戻り値の仕様をコメントで記述`"]
    B --> C["`ステップ3
    Copilotが関数全体を提案`"]
    C --> D["`ステップ4
    提案内容をレビュー・修正`"]
    D --> E["`ステップ5
    テストコードのコメントを記述`"]
    E --> F["`ステップ6
    Copilotがテストを提案`"]

良い例: 具体的で、入出力が明確

# ユーザーのメールアドレスをバリデーションする関数
# - 引数: email (str) - 検証対象のメールアドレス
# - 戻り値: bool - 有効なメールアドレスの場合True
# - RFC 5322に準拠した形式チェックを行う
# - ドメイン部分にMXレコードが存在するかは検証しない

避けるべき例: 曖昧で、Copilotが意図を推測しづらい

# メールをチェック

GitHub公式の調査によると、コメント駆動開発の効果は言語によって異なる。
JavaScriptやPythonはパブリックリポジトリに大量のサンプルが存在するため高精度な補完が得られる一方、RustやHaskellなどは複雑な型システムの影響もあり、生成されたコードをより注意深く検証する必要がある。

2.3 Copilot Chatによる対話的コーディング

Section titled “2.3 Copilot Chatによる対話的コーディング”

Copilot Chatは、エディタ内で自然言語による対話を通じてコーディング支援を受けられるチャットインターフェースである。
インライン補完が「次の行を予測する」のに対し、Chatは「明確な質問や指示に基づいて回答・生成する」という違いがある。

コードの説明: 既存のコードを選択し、「このコードは何をしているのか」と質問できる。
レガシーコードの理解やオンボーディングに有効である。

テスト生成: 対象の関数やクラスを選択し、「この関数のユニットテストを書いて」と指示すると、テストフレームワークに応じたテストコードを生成する。

リファクタリング: 「この関数をより読みやすくリファクタリングして」「この処理をStrategy パターンで書き直して」のように設計レベルの指示も可能である。

デバッグ支援: コンパイルエラーやランタイムエラーのメッセージを貼り付けて原因の特定と修正案を得る。

ドキュメント生成: 関数やクラスに対するJSDoc、docstring、XMLコメントなどのドキュメントを自動生成する。

チャットの参照機能(@メンション)

Section titled “チャットの参照機能(@メンション)”

Copilot Chatでは @# を使って特定のコンテキストを明示的に参照できる。

参照方法説明
#file特定のファイルを参照#file:src/auth/login.ts
#selectionエディタで選択中のコード#selection を最適化して
#editorアクティブなエディタの内容#editor の問題点を指摘して
@workspaceワークスペース全体@workspace でAPI認証の処理はどこにある?
@terminalターミナルの出力@terminal のエラーを解決して

Copilot Chatはサイドパネルだけでなく、エディタ内の任意の位置でインラインチャットとしても利用できる(VS Code: Ctrl+I / Cmd+I)。
コードの一部を選択してインラインで質問・修正指示を出すと、差分プレビュー付きで変更が提案される。
コンテキストの切り替えが少なく、フローを維持しやすい。

2.4 カスタム指示とプロンプトファイルの設計

Section titled “2.4 カスタム指示とプロンプトファイルの設計”

Copilotの応答品質を組織やプロジェクトの要件に合わせて向上させるには、**カスタム指示(Custom Instructions)プロンプトファイル(Prompt Files)**の活用が不可欠である。

カスタム指示の種類と優先順位

Section titled “カスタム指示の種類と優先順位”

カスタム指示は複数の階層で定義でき、複数が同時に存在する場合は優先順位に従って適用される。

flowchart TB
    A["`個人指示(Personal Instructions)
    最高優先度
    ユーザーレベルで定義`"] --> D["`Copilotへ送信される
    プロンプトに統合`"]
    B["`リポジトリ指示
    .github/copilot-instructions.md
    または AGENTS.md`"] --> D
    C["`パス固有指示
    .github/instructions/*.instructions.md
    applyToフィールドで対象ファイルを限定`"] --> D
    E["`Organization指示
    組織レベルで定義
    GitHub.com上のChatのみ`"] --> D

リポジトリ全体のカスタム指示

Section titled “リポジトリ全体のカスタム指示”

リポジトリのルートに .github/copilot-instructions.md を作成し、自然言語で指示を記述する。
このファイルの内容はCopilot Chatへのすべてのリクエストに自動的に付加される。

記述例:

# Copilot Instructions
- このプロジェクトはTypeScript + Next.js 15 + Tailwind CSSで構築されている
- パッケージマネージャーはpnpmを使用する(npmやyarnではない)
- テストフレームワークはVitestを使用する
- コンポーネントはServer Componentsをデフォルトとし、必要な場合のみ "use client" を宣言する
- エラーハンドリングにはResult型パターンを使用し、例外のスローは避ける
- 変数名・関数名はcamelCase、型名・インターフェース名はPascalCaseとする

.github/instructions/ ディレクトリ内に *.instructions.md ファイルを作成し、applyTo フロントマターで適用対象を指定する。
言語やディレクトリごとに異なるルールを適用できる。

---
applyTo: "src/api/**/*.ts"
---
- APIエンドポイントはOpenAPI仕様に準拠したレスポンス形式を使用する
- すべてのAPIレスポンスに `requestId` フィールドを含める
- 入力バリデーションにはZodスキーマを使用する

プロンプトファイル(再利用可能なプロンプト)

Section titled “プロンプトファイル(再利用可能なプロンプト)”

.github/prompts/ ディレクトリに *.prompt.md ファイルを作成すると、チャット内で /ファイル名 のスラッシュコマンドとして呼び出せる再利用可能なプロンプトが定義できる。

---
agent: "agent"
description: "PRレビュー用のチェックリストを生成する"
---
以下のコード変更に対して、セキュリティ・パフォーマンス・可読性の
3観点でレビューコメントを生成してください。
対象: ${input:diff:レビュー対象の差分を貼り付けてください}

チャットで /pr-review と入力すると、このプロンプトが呼び出される。
チーム全員が同じプロンプトを使えるため、レビュー基準の統一に有効である。

Copilot自身に copilot-instructions.md を生成させることもできる。
以下の方法がある。

  • VS Code: /init コマンドまたは /create-instructions コマンドを使用
  • Visual Studio: /generateInstructions コマンドを使用
  • コーディングエージェント経由: GitHub.comのエージェントタブから、リポジトリを選択してプロンプトで生成を依頼

Copilotがプロジェクトの構造やコーディングパターンを分析し、カスタム指示を自動生成するため、ゼロから記述するよりも効率的にスタートできる。