はじめに：新しいチャットを作成する必要があるのか？

GitHub Copilotを日常的に使っていると、こんな疑問が浮かぶはずです。

「なんで毎回新しいチャット作る必要があるんだ？同じチャットで続ければいいじゃん」

実は、この感覚は正しいです。しかし、技術的な制限とその回避方法を理解することで、新しいチャット作成の本当の役割と、むしろそれを避ける方法が見えてきます。

本記事では、GitHub Copilotのチャット管理、コンテキストウィンドウの制限、そして.github/copilot-instructions.mdという知られざる強力な機能を組み合わせることで、新しいチャットなしで継続的な開発を実現する方法を解説します。

第1章：GitHub Copilot Chatの現在地

1.1 チャット履歴と自動要約の問題

GitHub Copilot Chatを使い続けると、システムは自動的に会話履歴を要約し始めます。これは一見、メモリ効率を高めるための機能に見えます。

しかし、実際の動作は以下のような問題を引き起こしています：

要約による弊害の実例：

  • 詳細なコンテキストが失われる
  • 以前のやり取りの重要な詳細が削除される
  • ユーザーが「要約を無視してほしい」と指示しても機能しない
  • 長い問題解決の過程で、AIが前のステップのコンテキストを喪失し、無限ループに陥る

2025年10月時点で、このコンテキスト喪失問題は依然としてGitHub Issuesで活発に報告されており、Microsoft/Copilotチームも改善に取り組んでいます。

1.2 コンテキストウィンドウの制限

各言語モデルには有限のトークン予算があります。GitHub Copilotが統合する主要モデルのコンテキストウィンドウ（2025年10月29日時点）：

モデルコンテキストウィンドウリリース状況
Claude Sonnet 4.5（最新）200,000トークン（ベータ版で1,000,000トークン）GA（2025年9月29日リリース）
Claude Sonnet 4200,000トークンGA
Claude Opus 4.1200,000トークンGA
Claude Haiku 4.5200,000トークンGA（2025年10月21日リリース）
GPT-5（最新）128,000トークンGA（2025年8月7日リリース）
GPT-5 mini128,000トークンGA
GPT-4.1128,000トークンGA
Gemini 2.5 Pro（最新）1,000,000トークン（ただし圧縮される）GA（2025年6月17日リリース）

2025年10月23日に廃止されたモデル：

  • Claude Sonnet 3.7 → Claude Sonnet 4に移行
  • Claude Opus 4 → Claude Opus 4.1に移行
  • GPT o3, o4-mini → GPT-5シリーズに移行
  • Gemini 2.0 Flash → Gemini 2.5 Proに移行

見た目の大きさに騙されてはいけません。大容量ファイルの添付や長時間の会話を続けると、これらのトークン予算に接近し、AIのパフォーマンスが著しく低下します。

1.3 パフォーマンスの悪化サイクル

チャットが長くなると、以下のサイクルに陥ります：

  1. チャット履歴の蓄積
  2. コンテキスト管理に集中するあまり、実際の問題解決の精度が低下
  3. AIの応答速度が遅くなる
  4. ユーザーストレス増加

第2章：従来の「新しいチャット」ソリューション

2.1 新しいチャットを作成するメリット

公式ドキュメントが推奨する「新しいチャット」戦略には、明確なメリットがあります：

1. コンテキストのクリア化

新しいチャットを作成すると、会話履歴とコンテキストが完全にクリアされます。これにより、無関係な前のコンテキストが干渉せず、AIが現在のタスクに完全に焦点を当てられます。

2. 異なるトピック間での干渉防止

公式ドキュメント曰く：

「異なるトピックのために新しいチャットセッションを開始する。これは、関連のない会話から前のコンテキストが引き継がれるのを避けるのに役立ちます。これにより、より適切な回答が得られます。」

3. パフォーマンスの回復

新しいチャットの開始により、コンテキストが軽くなるため、AIの応答速度が向上します。

2.2 新しいチャットを作成するデメリット

しかし、代償も大きいです：

1. 前のコンテキストの喪失

新しいチャットを作成すると、前の会話履歴や決定が完全に失われます。その結果：

  • 既に説明した背景情報を再度入力する必要がある
  • 長い開発プロセスで得た学習が失われる
  • 同じ説明を何度も繰り返すストレス

2. ワークフロー効率の低下

  • 複数のチャットを開く必要がある
  • チャット間の切り替えが発生
  • チャットの構成と管理に手間がかかる
  • 過去のやり取りの参照が困難

3. テーマの関連性がある場合の不利

実は、同じテーマでも、単に同じチャットで続行する方が効率的な場合があります：

  • 機能の段階的な開発
  • バグの調査と修正の連続的なプロセス
  • リファクタリングのステップバイステップの実装

第3章：革新的ソリューション：.github/copilot-instructions.md

3.1 copilot-instructions.md とは何か

.github/copilot-instructions.mdは、リポジトリ単位でGitHub Copilotに永続的に指示を与える仕組みです。

重要なのは、この指示ファイルは：

  • リポジトリの.githubディレクトリに配置する
  • 毎回のチャットリクエストで自動的に読み込まれる
  • 特別な設定は不要
  • チーム全体で共有される

3.2 会話履歴の要約との組み合わせ

.github/copilot-instructions.mdのゲニアスな点は、会話履歴の要約と役割分担することです：

[長期間のチャット継続]
        ↓
[会話履歴は要約されて削除]
        ↓
[.github/copilot-instructions.md は毎リクエスト読み込まれる]
        ↓
[コアな指示は永続的に保持される]

つまり、細部の会話履歴は圧縮されても、プロジェクトの本質的な要件は失われないのです。

3.3 実装例：必須指示の構成

実際のプロジェクトでは、.github/copilot-instructions.mdに以下のようなプロジェクト永続的な指示を記述します：

<strong># プロジェクト概要</strong>

このアプリケーションは、ユーザーのタスク管理とチーム連携を効率化するWebアプリケーションです。

<strong>## 技術スタック</strong>

- <strong>**言語**</strong>: TypeScript（フロントエンド・バックエンド両方）
- <strong>**フレームワーク**</strong>: Next.js 14（フロントエンド）、Node.js + Express（バックエンド）
- <strong>**データベース**</strong>: PostgreSQL 16
- <strong>**ORM**</strong>: Prisma 5
- <strong>**認証**</strong>: NextAuth.js
- <strong>**パッケージマネージャー**</strong>: pnpm
- <strong>**テスト**</strong>: Jest + React Testing Library

<strong>## コーディング規約</strong>

<strong>### TypeScript</strong>

- <strong>**常に型ヒントを使用する**</strong>（`any`の使用は禁止）
- `strict`モードを有効にしたコンパイル設定
- インターフェース名は`I`プレフィックスを使用しない（`User`ではなく`UserType`）
- 型定義は`types/`ディレクトリに集約

<strong>### React コンポーネント</strong>

- <strong>**PascalCase**</strong> でコンポーネント名を命名
- ファイル名もPascalCase（例：`TaskCard.tsx`）
- 関数型コンポーネントのみ使用（クラスコンポーネント禁止）
- props の分割代入を推奨

<strong>### API エンドポイント</strong>

- RESTful設計を厳守
- すべてのエラーハンドリングは try/catch で実装
- ステータスコードの適切な使用
- エラーレスポンスは統一フォーマット

<strong>## プロジェクト構成</strong>


project-root/
├── src/
│ ├── app/ # Next.js App Router
│ ├── components/ # 再利用可能なReactコンポーネント
│ ├── lib/ # ユーティリティ関数
│ ├── types/ # TypeScript型定義
│ ├── hooks/ # カスタムReactフック
│ └── pages/ # ページファイル（古いRouter）
├── api/ # バックエンドAPI
├── tests/ # テストファイル
├── prisma/ # Prismaスキーマ
├── .github/
│ ├── copilot-instructions.md # このファイル
│ └── workflows/ # GitHub Actions
└── package.json
## 重要なデータベーススキーマ

```prisma
model User {
  id        String   @id @default(cuid())
  email     String   @unique
  name      String
  tasks     Task[]
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model Task {
  id          String   @id @default(cuid())
  title       String
  description String?
  status      String   @default("todo")
  userId      String
  user        User     @relation(fields: [userId], references: [id])
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
}
``` {data-source-line="228"}

## 実行コマンド

### セットアップ

```bash
pnpm install
pnpm prisma migrate dev
pnpm run dev
``` {data-source-line="238"}

### テスト実行

```bash
pnpm test
``` {data-source-line="244"}

### ビルド

```bash
pnpm build
pnpm start
``` {data-source-line="251"}

## 禁止パターン

- ❌ グローバル状態の使用（Redux不使用、Context API推奨）
- ❌ ダイレクトなDOM操作（React hooks経由のみ）
- ❌ ブラウザの localStorage への認証情報保存（HttpOnly cookies推奨）
- ❌ 型定義なしのデータ処理
- ❌ CSS-in-JS（Tailwind CSS使用）

## CI/CDパイプライン

- すべてのプルリクエストで自動テスト実行
- ESLint と Prettier による自動フォーマット
- TypeScript型チェック必須

これでもまだ1,500〜2,000トークン程度に収まります。

3.4 段階的指示ファイルの構築

最初はシンプルに始めて、段階的に拡充するのが実践的です：

フェーズ1（最小構成、5分）

# プロジェクト概要
ユーザー向けのタスク管理アプリケーション

## 技術スタック
- TypeScript + Next.js 14
- PostgreSQL + Prisma

## コーディング規約
- PascalCase: コンポーネント名
- camelCase: 変数・関数名
- 常に型ヒント使用

フェーズ2（実装規約追加、30分）

# [フェーズ1の内容] 

## プロジェクト構成
[ディレクトリ構造説明]

## API設計ルール
[REST設計]

フェーズ3（運用安定化後、完全版）

データベーススキーマ、CI/CDパイプライン、よくあるエラーの対応方法など、すべてを網羅。

3.5 複数指示ファイルの運用（高度な使用法）

より大規模なプロジェクトでは、.github/instructions/ディレクトリに複数の指示ファイルを配置できます：

.github/
├── copilot-instructions.md        # 全体ルール（必須）
└── instructions/
    ├── frontend.instructions.md   # フロントエンド専用（*.tsx, *.ts に適用）
    ├── backend.instructions.md    # バックエンド専用（api/ に適用）
    └── database.instructions.md   # データベース操作（prisma/ に適用）

各ファイルのヘッダーで適用対象を指定：

---
applyTo: "src/**/*.tsx,src/**/*.ts"
---

<strong># フロントエンド向け指示</strong>

（フロントエンド固有の指示）

この方式により、Copilotは現在編集中のファイルに応じて適切な指示を自動選択します。

第4章：長期会話の実現メカニズム

4.1 動作フロー

.github/copilot-instructions.mdと会話履歴要約の動作メカニズムは以下の通りです：

┌─ ユーザーが新しいメッセージを送信
│
├─ Copilotが即座に .github/copilot-instructions.md を読み込み
│
├─ 会話履歴の要約を生成
│  （詳細は削除、重要な決定のみ残す）
│
├─ [指示ファイル] + [要約済み履歴] + [新規メッセージ] を統合
│
├─ 統合プロンプトをAIモデルに送信
│
└─ コンテキストを保ったまま回答生成
  （指示ファイルがコアコンテキストとして機能）

4.2 トークン効率の最適化

この仕組みにより、以下の効率化が実現します：

項目従来の方法指示ファイル活用時
新規チャット作成頻度1時間ごと不要（数日間継続可能）
コンテキスト引き継ぎ完全喪失指示で保持
トークン使用効率低い（説明の繰り返し）高い（指示で共有）
チャット管理のストレス高い低い

第5章：実装ガイド

5.1 始める前にやること

GitHub Copilotで指示ファイルを活用する前に、以下を確認してください：

チェックリスト

  • ☑ VS Code 1.90以上がインストール済み
  • ☑ GitHub Copilot拡張機能がインストール済み
  • ☑ Copilot Chat がVS Codeで動作確認済み
  • ☑ リポジトリがGit管理されている

5.2 ステップバイステップ実装

ステップ1：.githubディレクトリの作成

プロジェクトの最上位に.githubディレクトリが存在するか確認します。なければ作成：

mkdir -p .github

ステップ2：指示ファイルの作成

.github/copilot-instructions.mdを作成：

touch .github/copilot-instructions.md

ステップ3：初期内容の記述

前述の「実装例」をベースに、プロジェクト固有の内容を記述します。

最重要ポイント：

  • 最初は簡潔に（2ページ以下、2,000トークン以下）
  • 実装規約に絞る（思想や歴史は不要）
  • 実際のコードを参照しながら作成

ステップ4：Git追加とコミット

git add .github/copilot-instructions.md
git commit -m "Add GitHub Copilot custom instructions"
git push

ステップ5：動作確認

VS CodeのCopilot Chatで質問を送信し、Referencesセクションに.github/copilot-instructions.mdが表示されるか確認します。

表示されれば、指示ファイルが正常に読み込まれています。

5.3 トラブルシューティング

Q: 指示ファイルが読み込まれていない

A: 以下を確認してください：

  1. ファイル名が正確に.github/copilot-instructions.mdか
  2. VS Code を再起動したか
  3. Copilot Chat ウィンドウを開きなおしたか

Q: 効果が実感できない

A: 指示ファイルの内容が抽象的すぎる可能性があります。以下を試してください：

  1. プロジェクト固有のコーディング規約に絞る
  2. 実際のコード例を追加
  3. 9,000トークンを超えないか確認（.github/copilot-instructions.mdが肥大化すると効果が低下）

Q: 長時間チャットを続けると応答が遅くなる

A: これは仕様です。以下の対応があります：

  1. 設定での要約無効化（2025年10月対応）

.vscode/settings.jsonに追加：

{
  "github.copilot.chat.summarizeAgentConversationHistory.enabled": false
}
  1. 新しいチャットの分離活用

同じテーマでも、実装フェーズが大きく異なる場合は新しいチャットを使う（例：設計 → 実装 → テスト）

第6章：ベストプラクティス

6.1 何を書くべきか

.github/copilot-instructions.mdに記述すべき内容：

✅ プロジェクト概要

  • アプリケーションが何を実現するのか
  • 誰が使うのか
  • 主要な機能

✅ 技術スタック

  • 使用言語・フレームワーク・ライブラリ
  • バージョン情報

✅ 絶対に守るべきコーディング規約

  • 命名規則（PascalCase/camelCase など）
  • 型チェック必須の指示
  • エラーハンドリング方式

✅ ファイル構成

  • ディレクトリ構造図
  • 各ディレクトリの役割

✅ 重要な実装ルール

  • 禁止パターン
  • 推奨パターン
  • 外部リソースへのリンク

6.2 何を書くべきでないか

❌ チャット内で決めた一時的な仕様

  • 「今のこのプロジェクトだけで有効な指示」は履歴に記録

❌ 長大なコード例

  • トークン浪費
  • READMEなどのドキュメントへのリンク推奨

❌ プロジェクト外の一般知識

  • 「JavaScriptの基本」など
  • Copilotは既に知っている

❌ 定期的に変わる情報

  • チーム構成
  • 進行中のタスク

6.3 Copilot Agentと組み合わせる

GitHub Copilot Coding Agentは、.github/copilot-instructions.mdを読み込んでPull Requestの自動作成まで行います。

指示ファイルの質が直接、Agent の提案品質に影響します。

Agent 向けの指示強化ポイント

# 追加: Agent 向けガイドライン

## Pull Request作成時の要件

- コミットメッセージは英語で記述（例：`feat: add task filtering`）
- 1つのPRは1つの機能に限定
- テストケースも合わせて作成
- ドキュメント更新も実施

## テスト要件

- 全テストが通ること
- 新規コードに対してテスト追加
- カバレッジ 80% 以上

第7章：実装例：実際のプロジェクト

7.1 Case Study: React + Node.js プロジェクト

実際のプロジェクトで使用されている指示ファイルの例を紹介します。

GitHubリポジトリの参考例

2025年10月時点で、以下のプロジェクトが優れた指示ファイルを公開しています：

  1. Microsoft公式サンプル（Copilot Team提供）
  2. Vercel projects（Next.js最新ベストプラクティス）
  3. Zenn記事で紹介されているプロジェクト

これらを参考にしながら、自プロジェクトの指示ファイルを構築すると効率的です。

第8章：新しいチャット「不要論」を超えて

8.1 新しいチャットが有用な場合

誤解のないよう、新しいチャット作成が有用な場面を整理します：

新しいチャットを推奨する場面

  1. 全く異なるテーマへの切り替え
    • 機能開発 → インフラ構築
    • コード実装 → ドキュメント作成
  2. プロジェクト間の移動
    • プロジェクトA → プロジェクトB
    • 異なるリポジトリへの切り替え
  3. チャット内の参照を避けたい場合
    • 前のやり取りがノイズになる
    • 新しいコンテキストで心機一転したい

同一チャット継続を推奨する場面

  1. 機能の段階的な開発（設計 → 実装 → テスト）
  2. バグ調査と修正の連続プロセス
  3. リファクタリング
  4. コードレビュー対応

8.2 混在戦略

実践的には、以下の混在戦略が最適です：

┌─ 新しい機能開発を開始
│  └─ 新しいチャット作成
│
├─ 実装フェーズ（設計 → コーディング → テスト）
│  └─ 同一チャットで継続
│     （.github/copilot-instructions.md がコンテキスト保持）
│
├─ 機能完成
│  └─ チャット終了
│
└─ 別の機能へ
   └─ 新しいチャット作成

第9章：今後の展望と最新モデル動向

9.1 2025年10月の最新モデル状況

GitHub Copilotは急速に進化しており、2025年10月23日に大規模なモデル更新が行われました：

最新の利用可能モデル（2025年10月29日時点）

Anthropic Claude シリーズ

  • Claude Sonnet 4.5（2025年9月29日リリース）
    • 世界最高のコーディング性能
    • 200,000トークン（ベータ版で1,000,000トークン）
    • 複雑なエージェント構築に最適
  • Claude Haiku 4.5（2025年10月21日リリース）
    • 前世代のSonnet 4と同等性能を3分の1の価格で提供
    • 高コスパで日常使いに最適
  • Claude Opus 4.1
    • ハイブリッド推論とエージェント動作に特化

OpenAI GPT シリーズ

  • GPT-5（2025年8月7日リリース）
    • 高速応答と効率的な処理
    • 128,000トークン
    • GPT-4oとo3シリーズを統合した最新フラッグシップモデル
  • GPT-5 mini
    • 軽量かつ高速
    • o1-mini、o3-mini、o4-miniの後継
  • GPT-5-Codex（パブリックプレビュー）
    • コーディング特化型

Google Gemini シリーズ

  • Gemini 2.5 Pro（2025年6月17日リリース）
    • 1,000,000トークン（圧縮あり）
    • 大規模文書分析・リサーチに最適
    • マルチモーダル処理に強み

9.2 廃止されたモデル（2025年10月23日）

以下のモデルは廃止され、代替モデルへの移行が完了しています：

廃止モデル代替モデル
Claude Sonnet 3.7Claude Sonnet 4
Claude Opus 4Claude Opus 4.1
GPT o3, o3-mini, o4-miniGPT-5, GPT-5 mini
Gemini 2.0 FlashGemini 2.5 Pro

9.3 モデル選択の戦略

コーディング重視：

  • 第1選択：Claude Sonnet 4.5（世界最高のコーディング性能）
  • コスパ重視：Claude Haiku 4.5（3分の1の価格）

長時間タスク・大規模コンテキスト：

  • Gemini 2.5 Pro（1,000,000トークン）
  • Claude Sonnet 4.5（ベータ版で1,000,000トークン）

汎用・高速応答：

  • GPT-5（バランス型）
  • GPT-5 mini（軽量高速）

9.4 GitHub Copilot の進化予定

短期（今後3ヶ月）

  • ✅ 要約機能の細かい制御オプション追加（既に実装済み）
  • ✅ コンテキストオプティマイザーのGA化

中期（今後6-12ヶ月）

  • 🔄 より大きなコンテキストウィンドウ対応（Gemini 2.5 Pro、Claude 4.5で実現）
  • 🔄 複数リポジトリ間の指示管理
  • 🔄 Computer-Using Agents（CUA）の強化

長期ビジョン

  • 🚀 AIが自動的に指示ファイルを最適化
  • 🚀 チーム全体での指示ライブラリの共有化
  • 🚀 Claude Agent SDKとの統合による高度なエージェント機能

9.5 ユーザーがすべき準備

  1. 今すぐ実施：.github/copilot-instructions.mdを作成・運用開始
  2. モデル選択の最適化：タスクに応じて最新モデルを活用
  3. 定期的な見直し：3ヶ月ごとに指示ファイルの内容を更新
  4. チーム展開：組織内での標準化

まとめ：新しいチャット「不要論」の結論

ユーザーの直感は正しかった。新しいチャットを毎回作成する必要はないのです。

その代わりに必要なのは：

  1. .github/copilot-instructions.md の活用
    • プロジェクトの本質的な指示を永続化
    • 毎リクエスト自動読み込みされるため、要約の影響を受けない
  2. 適切なファイルサイズ管理
    • 2,000トークン程度に収める
    • コアなルール・規約に絞る
  3. 戦略的なチャット管理
    • 同じテーマ内での継続は避ける必要がない
    • テーマ完全切り替え時のみ新チャット作成
  4. 最新モデルの活用
    • Claude Sonnet 4.5：コーディング性能最高
    • Gemini 2.5 Pro：大規模コンテキスト（1M トークン）
    • GPT-5：汎用バランス型

この戦略により、以下が実現します：

✅ チャット管理のストレス軽減
✅ コンテキスト引き継ぎの効率化
✅ トークン利用効率の向上
✅ チーム全体での開発品質向上
✅ 最新AIモデルの恩恵を最大化

今すぐ、プロジェクトに.github/copilot-instructions.mdを追加してみてください。

その瞬間から、GitHub Copilotは単なるコード補完ツールから、プロジェクトの文脈を理解した開発パートナーへと進化します。

参考資料

公式ドキュメント

最新モデル情報