Copilotを活用した開発フロー：調査・計画・実装の3ステップ

GitHub Copilotを「コード補完ツール」としてだけ使っていませんか？

Copilotの真価は、開発プロセス全体を効率化できることにあります。

この記事では、Copilotを活用した開発フローを「調査→計画→実装」の3ステップで解説します。

全体の流れ

flowchart LR
    A[調査] --> B[計画]
    B --> C[実装]
    C --> D{完了？}
    D -->|No| A
    D -->|Yes| E[リリース]

各ステップで使う機能が異なります。

ステップ目的主に使う機能
調査現状を把握するCopilot Chat, Agent mode
計画方針を決めるPlan agent
実装コードを書くAgent mode, Edit mode

順番に見ていきます。

ステップ1：調査

目的

「何がどうなっているか」を把握します。

  • 既存コードの構造
  • 依存関係
  • 影響範囲

いきなりコードを書き始めると、後で「思ってたのと違う」となりがちです。

使う機能

Copilot Chat で質問する

# 良い質問の例
「このリポジトリの認証の仕組みを説明して」
「UserService クラスの責務は何？」
「このエラーが発生する条件は？」

知らないコードベースでも、Chatに聞けば概要がつかめます。

Agent mode で調査タスクを実行

# 調査タスクの例
「このプロジェクトの依存関係を一覧にして」
「廃止予定のAPIを使っている箇所を洗い出して」
「テストカバレッジが低いファイルを特定して」

Agent modeはファイルを読み、ターミナルでコマンドを実行して調査してくれます。

調査のコツ

出力を残すことが重要です。

  • 調査結果をMarkdownにまとめさせる
  • Issueとして記録する
  • READMEに追記する

調査だけして終わると、次に同じ調査をすることになります。

ステップ2：計画

目的

「何をどの順番でやるか」を決めます。

  • 変更が必要なファイル
  • 実装の手順
  • 考慮すべきリスク

計画なしに実装を始めると、途中で方針がブレます。

使う機能

Plan agent で計画を立てる

Plan agentは実装をせず、計画だけを作成します。

# Plan agentへの入力例
「認証方式をJWTからセッションベースに変更したい。
現状の認証コードを調査し、変更計画を立てて。

制約：
- 既存のAPIは互換性を保つ
- ダウンタイムなしで移行する
- テストは必ず通す」

計画の出力例

Plan agentは以下のような計画を出力します。

## 変更対象ファイル
1. src/auth/jwt.ts → 削除
2. src/auth/session.ts → 新規作成
3. src/middleware/auth.ts → 修正
4. src/api/login.ts → 修正

## 実装手順
1. セッション管理の基盤を作成
2. 新旧両方の認証を並行稼働させる
3. 各APIを順次移行
4. JWT関連コードを削除

## リスク
- セッションストレージの選定が必要
- 既存トークンの無効化タイミング

計画のコツ

「受け入れ条件」を明確にすることが重要です。

## 受け入れ条件
- [ ] 全てのAPIテストが通る
- [ ] 既存ユーザーが再ログインなしで使える
- [ ] セッションの有効期限が設定できる

これがないと、「完了」の判断ができません。

ステップ3：実装

目的

計画に沿って、実際にコードを書きます。

使う機能

Agent mode で自律実行

計画があれば、Agent modeに任せられます。

# Agent modeへの指示例
「先ほどの計画に沿って、ステップ1を実装して。
ビルドとテストが通ることを確認して。」

Agent modeは以下を自律的に行います。

  1. ファイルを作成・編集
  2. npm run build を実行
  3. エラーがあれば修正
  4. npm test を実行
  5. 失敗したテストを修正

Edit mode で細かい調整

Agent modeの結果を微調整したい場合は、Edit modeを使います。

# Edit modeでの指示例
「この関数のエラーハンドリングをもう少し丁寧にして」
「変数名をもっとわかりやすくして」

Edit modeは変更箇所を提案として表示し、適用するかどうかを選べます。

実装のコツ

小さく区切って進めることが重要です。

# 悪い例（一度に全部）
「認証システム全体を作り直して」

# 良い例（ステップごと）
「まずセッション管理の基盤だけ作って」
→ 確認
「次にログインAPIを移行して」
→ 確認
「最後にログアウトAPIを移行して」
→ 確認

一度に大きな変更をすると、問題が起きたときに原因特定が難しくなります。

3ステップを回す

実際の開発サイクル

flowchart TB
    subgraph 調査["ステップ1: 調査"]
        A1[Chatで質問] --> A2[Agent modeで洗い出し]
        A2 --> A3[結果を記録]
    end

    subgraph 計画["ステップ2: 計画"]
        B1[Plan agentで計画作成] --> B2[受け入れ条件を設定]
        B2 --> B3[計画をレビュー]
    end

    subgraph 実装["ステップ3: 実装"]
        C1[Agent modeで実装] --> C2[テスト確認]
        C2 --> C3{問題あり？}
        C3 -->|Yes| C4[修正]
        C4 --> C2
        C3 -->|No| C5[次のステップへ]
    end

    調査 --> 計画 --> 実装
    実装 -->|追加の調査が必要| 調査

よくある失敗パターン

調査をスキップする

「たぶんこうだろう」で実装を始め、後で全部やり直し。

計画を立てない

実装しながら方針がブレて、一貫性のないコードになる。

一度に全部やろうとする

大きな変更を一気にやって、問題の切り分けができなくなる。

チームで使う場合

調査結果を共有する

# Issue として記録
## 調査: 認証システムの現状

### 構造
- JWT認証を使用
- トークンの有効期限は24時間
- リフレッシュトークンなし

### 問題点
- トークン無効化の仕組みがない
- ログアウトしても他端末で使える

### 関連ファイル
- src/auth/jwt.ts
- src/middleware/auth.ts

計画をレビューする

Plan agentの出力をPRやIssueに貼り、チームでレビューします。

# PR: 認証システム移行計画

## 概要
JWTからセッションベース認証への移行計画です。

## Plan agentの出力
（計画を貼り付け）

## レビューポイント
- [ ] 移行手順に漏れはないか
- [ ] リスクの洗い出しは十分か
- [ ] 受け入れ条件は適切か

まとめ

ステップやること使う機能
調査現状を把握するChat, Agent mode
計画方針を決めるPlan agent
実装コードを書くAgent mode, Edit mode

Copilotは「コードを書く」だけのツールではありません。

調査→計画→実装のサイクルを意識することで、手戻りが減り、品質の高いコードが書けます。

まずは小さなタスクで3ステップを試してみてください。