アーキテクチャ・設計

CLAUDE.md / .cursorrules / .github/copilot-instructions の書き分け術

CLAUDE.md、.cursorrules、.github/copilot-instructionsは何を書き分けるべきか。各ファイルの役割・スコープ・運用ルールを2026年の実践知見で整理します。

この記事の目次

この記事でわかること:

  • 3つの設定ファイルそれぞれの守備範囲
  • 重複させるべき内容・分けるべき内容
  • 2026年の実運用テンプレート

結論: 3ファイルは「役割が違う」

多くのチームがCLAUDE.md.cursorrules.github/copilot-instructions.mdをすべて作りはじめて混乱しています。結論を先に言うと、3ファイルは対象とするAIも、書くべき粒度も異なります。一つの内容をコピペで済ますと、どのAIにも刺さらない曖昧な指示になってしまいます。

各ファイルの役割

CLAUDE.md(Claude Code向け)

Claude Codeが起動時に読み込む長期記憶です。プロジェクト全体の文脈・ドメイン用語・禁止事項を中心に書きます。3000〜8000字の中量級が目安。Claudeは長文の指示を正確に解釈するため、背景説明を厚めに書けます。

.cursorrules(Cursor向け)

Cursorのインライン補完・チャットに作用します。コーディング規約・命名規則・型ルールのような短く明示的な指示が向いています。500〜1500字の軽量版が推奨されます。長すぎるとレイテンシが悪化します。

.github/copilot-instructions.md(GitHub Copilot向け)

Copilotの補完とChat両方に作用します。言語別ルール・ライブラリ選定・テスト方針など、IDE実装に直接効くルールを書きます。

書き分けの実例

CLAUDE.md に書くこと

  • プロダクトのドメイン用語集(「テナント」「ワークスペース」の違いなど)
  • アーキテクチャ概要(モノレポ構造、レイヤー責務)
  • 禁止事項(「本番DBへの直接接続禁止」など)
  • 過去の意思決定(ADRへの参照)
  • テスト戦略の方針

.cursorrules に書くこと

  • 「TypeScriptでanyを使わない」
  • 「Reactコンポーネントは関数型のみ」
  • 「import順序: 標準→外部→内部」
  • 「コメントは日本語で書く」

copilot-instructions.md に書くこと

  • 「テストはJestではなくVitestを使う」
  • 「APIクライアントはsrc/api/client.tsのラッパー経由」
  • 「エラーハンドリングはResult型を返す」

重複させてよい内容

禁止事項と命名規則は3ファイルすべてに重複させて構いません。AIごとに参照タイミングが違うので、同じルールを冗長に書く方が事故が減ります。実際、筆者のチームでは「シークレットをコードに書かない」「本番環境変数を編集しない」の2つは3ファイルすべてに記載しています。

運用ルール

  1. 3ファイルともGitで管理し、PR時にレビュー対象とする
  2. 変更時は四半期に1回、全体整合性をレビュー
  3. 各ファイル末尾に最終更新日とオーナーを記載
  4. 新メンバー参加時にこの3ファイルを必読リストに入れる

陥りがちな失敗

もっとも多い失敗は「3ファイルすべてに同じ長文を貼り付ける」ことです。これをやるとCursorのレイテンシが悪化し、Copilotの補完精度も下がります。役割に応じて粒度を変えてください。

次に多いのが「更新が止まる」失敗です。半年メンテされなかった.cursorrulesは嘘の塊になっており、AIを誤誘導します。最終更新日が3ヶ月以上前ならアラートを出すCI設定がおすすめです。

まとめ

CLAUDE.md・.cursorrules・copilot-instructionsは「同じものを3つ書く」のではなく、AIごとに最適な粒度で書き分けるのが正解です。2026年の開発生産性は、これら設定ファイルの質に大きく依存します。コピペではなく、設計の一部として扱いましょう。

関連タグ