CLAUDE.mdとcopilot-instructions.mdを比較

Claude CodeとGitHub Copilot、両方を使っている方も増えてきました。それぞれにプロジェクト固有のルールをAIへ伝える設定ファイル(CLAUDE.md／copilot-instructions.md)がありますが、書き方や運用ルールの勘所は微妙に異なります。

本記事では、両者の役割の違いから実際に同じルールを書き比べた実例、併用時の注意点までを整理し、自分のプロジェクトでどう書き分ければよいか判断できる状態を目指す。

CLAUDE.mdとcopilot-instructions.mdは何が違うのか
1. CLAUDE.md（Claude Code）の役割
2. copilot-instructions.md（GitHub Copilot）の役割
書式・運用ルールを比較する
同じルールを両方の形式で書いてみる
1. CLAUDE.mdで書く場合
2. copilot-instructions.mdで書く場合
併用時の注意点
結局どちらを使うべきか
まとめ
FAQ

CLAUDE.mdとcopilot-instructions.mdは何が違うのか

CLAUDE.md（Claude Code）の役割

CLAUDE.mdは、Claude Codeがセッションを開始するたびに自動で読み込むMarkdown形式のファイルです。コードを読めば分かることではなく、「コードを読んだだけでは推測できないこと」(コーディング規約、禁止事項、独自のワークフローなど)を書くのが基本方針です。

配置場所によってスコープが分かれており、下の階層にあるものほど優先度が高くなります。

管理ポリシー用(組織全体に強制するルール)
ユーザー設定用(~/.claude/CLAUDE.mdなど、個人の好み)
プロジェクト用(リポジトリ直下のCLAUDE.md、チームで共有)
ローカル用(CLAUDE.local.md、個人の作業メモ)

copilot-instructions.md（GitHub Copilot）の役割

GitHub Copilotの場合は、リポジトリの.github/copilot-instructions.mdに自然言語でルールを書きます。特別なスキーマやfront matterは不要で、見出しや箇条書きを使って読みやすく書けば十分です。

公式には、プロジェクト概要・技術スタック・コーディング規約・ディレクトリ構成・テストの書き方などを含めることが推奨されています。

GitHub CopilotでClaudeモデルを活用する方法はこちら

書式・運用ルールを比較する

フォーマットとスキーマの有無

どちらもMarkdownで書く点は共通していますが、CLAUDE.mdは「箇条書きで簡潔に」という文化が強く、copilot-instructions.mdは「文章として自然に説明する」書き方でも問題ないとされています。

推奨される文字数・行数の目安

CLAUDE.mdは公式ドキュメントで200行以内が目安とされ、コミュニティでは60行前後まで削り込むのが最適という意見も多く見られます。各行について「これを消したらClaudeが間違えるか」を自問し、答えがNoなら削るのがコツです。

copilot-instructions.mdについては、2ページ程度に収めるのが望ましいという意見が一般的です(公式に厳密な行数規定があるわけではないため、目安として捉えてください＝要検証)。どちらのファイルも「長ければ長いほど良い」わけではなく、むしろ長文はAIの遵守率を下げる方向に働きます。

読み込まれるタイミングと階層構造

CLAUDE.mdは作業ディレクトリより上の階層にあるファイルをすべてセッション開始時に読み込み、サブディレクトリのCLAUDE.mdはClaudeがそのディレクトリのファイルを扱うタイミングでオンデマンドに読み込まれます。一方copilot-instructions.mdは、リポジトリ単位で1つ設置するのが基本の使い方です(IDEごとの個人設定を別途重ねることもできます)。

同じルールを両方の形式で書いてみる

「TypeScriptプロジェクトで、APIレスポンスの型は必ずzodでバリデーションする」というルールを例に、両方の形式で書き比べてみる。

CLAUDE.mdで書く場合

# プロジェクトルール

## API
- 外部APIのレスポンスは必ずzodでパースしてから使う（生のfetch結果を直接使わない）
- 型定義は `src/schemas/` 配下に置く
- パースに失敗したら例外を投げず、Result型で返す

短い箇条書きで、理由よりも「何をするか／しないか」を優先して書いているのがポイント。

copilot-instructions.mdで書く場合

# プロジェクト概要
TypeScriptで書かれたAPIクライアントアプリです。

## コーディング規約
外部APIのレスポンスを扱うときは、必ずzodでバリデーションしてから使用してください。
生のfetch結果をそのまま画面やロジックに渡すことは避けてください。
型定義は `src/schemas/` ディレクトリにまとめています。
パースに失敗した場合は例外をthrowするのではなく、Result型（`{ ok: true, data } | { ok: false, error }`）で返す設計にしています。

copilot-instructions.mdでは背景や理由も含めて文章で説明する書き方が馴染みやすく、Copilotのコードレビュー機能などでも参照されやすくなる。

併用時の注意点

同じリポジトリでClaude CodeとGitHub Copilotを両方使う場合、ルールを二重管理することになる。内容が食い違うと、どちらのAIを使うかでコードの書き方がぶれてしまうので注意が必要。

共通のルールは1箇所(例: docs/coding-rules.md)にまとめ、CLAUDE.mdとcopilot-instructions.mdはそこを参照する一文だけを書く
ツール固有の指示(Claude Codeのみのコマンド運用、Copilotのみのレビュー設定など)はそれぞれのファイルに残す
定期的に両方のファイルを見直し、片方だけ更新されていないか確認する

結局どちらを使うべきか

ツールの使い方そのものが違うため、「どちらか一方を選ぶ」というより「両方書く前提で、役割を分ける」のが現実的。

Claude Codeでエージェントに実装や修正を任せることが多いチーム → CLAUDE.mdを優先して整備する
GitHub Copilotのコード補完・レビュー機能を中心に使うチーム → copilot-instructions.mdを優先して整備する
両方を併用するチーム → 内容を薄く保ち、共通ルールは外部ファイルに寄せる

まとめ

CLAUDE.mdとcopilot-instructions.mdは、どちらも「AIにプロジェクト固有のルールを伝える」という目的は同じだが、CLAUDE.mdは箇条書き中心で簡潔に、copilot-instructions.mdは文章での説明も交えて書くのが馴染みやすい形式。どちらも長く書きすぎないことが共通のポイントなので、まずは今のプロジェクトのCLAUDE.mdやcopilot-instructions.mdを見直すところから始めてみてほしい。