copilot-instructions.mdとは？書き方とサンプル・配置場所、AGENTS.mdとの違い【2026年10月】

copilot-instructions.mdは、GitHub Copilotにリポジトリ共通の指示（使う言語とライブラリ、ビルドとテストのコマンド、コーディング規約など）を毎回自動で渡すためのMarkdownファイルです。置き場所はリポジトリの.github/copilot-instructions.mdで、特定のファイルにだけ効かせたい指示は.github/instructions/配下の*.instructions.mdに分けます。この記事では、2026年10月時点のGitHub DocsとVS Codeの公式ドキュメントをもとに、配置場所、コピーして使えるサンプル、書き方のベストプラクティス、AGENTS.mdとの違い、指示が効かないときの確認点を整理します。

まとめ：copilot-instructions.mdの要点

• 配置場所：リポジトリのルートに.githubフォルダを作り、その中にcopilot-instructions.mdを置きます。ファイル名は固定で、フロントマター（先頭の---ブロック）は不要です。
• 効く機能：Copilot Chat、Copilot cloud agent（旧称coding agent）、Copilot code review、Copilot CLIが読みます。エディタで入力中に出るインライン補完（ゴーストテキスト）には効きません。
• 書き方：短い命令文を見出しと箇条書きで並べます。中身はプロジェクト概要、技術スタックと版、ビルド・テスト・リントのコマンド、リンターでは強制できない規約の4つを優先します。
• パス別の指示：.github/instructions/NAME.instructions.mdを作り、先頭にapplyTo: "**/*.ts"のようなglobを書きます。コードレビューかcloud agentの片方から外すときはexcludeAgentを使います。
• AGENTS.mdとの違い：AGENTS.mdはCopilot専用ではなく、CodexやCursorなど複数のエージェントが読む共通形式です。AGENTS.md対応のCopilot機能では両方を読めるため、複数のツールを使うチームは共通の指示をAGENTS.mdに、Copilotだけの指示をcopilot-instructions.mdに書き分けます。
• 優先順位：環境によって異なります。GitHub.comでは個人、リポジトリ（パス別、全体、エージェント向け）、組織の順です。VS CodeやCopilot CLIでは共通の優先順位に頼らず、指示の矛盾を解消します。

copilot-instructions.mdの役割と読み込まれる範囲

Copilotは入力したプロンプト、会話履歴、ワークスペースから収集した情報などを手がかりに回答します。copilot-instructions.mdに「依存管理はMavenではなくBazel」「JavaScriptはダブルクォートとタブ」と書いておくと、その内容が毎回のリクエストに自動で添えられ、同じ説明をプロンプトで繰り返さずに済みます。GitHub Docsの「Adding repository custom instructions」は、リポジトリの指示を次の3種類に分けています。

• リポジトリ全体の指示：.github/copilot-instructions.md。そのリポジトリでのすべてのリクエストに適用されます。
• パス別の指示：.github/instructions/以下のNAME.instructions.md。applyToに一致するファイルを扱うときだけ適用され、全体の指示とも併用されます。
• エージェント向けの指示：リポジトリ内の任意の場所に置けるAGENTS.md。作業中のファイルから見てディレクトリツリー上で最も近いものが優先されます。ルートのCLAUDE.mdやGEMINI.mdも代わりに使えます。

機能と環境ごとに読まれるファイルの違い

同じcopilot-instructions.mdでも、読むかどうかは機能と環境で変わります。GitHub Docsの対応表「Support for different types of custom instructions」を2026年10月13日に確認した内容を、主要な組み合わせに絞って並べます。

表から読み取れる実務上の結論は2つです。1つ目は、GitHub.comのChatでは*.instructions.mdが読まれないことです。GitHub.com上でパス別の指示が効くのはcloud agentとcode reviewだけなので、Chatでも守らせたい規約はcopilot-instructions.md本体に書きます。2つ目は、Eclipseのcode reviewはカスタム指示自体に非対応という点です。VS CodeのChatについては、VS Code側のドキュメントがCLAUDE.mdも読み込み対象に挙げており、GitHub Docsの表より広く読みます（次の節）。

インライン補完に効かない理由と影響

VS Codeのドキュメント「Use custom instructions in VS Code」は、カスタム指示はエディタで入力中に表示されるインライン候補には考慮されないと注記しています。「関数名はスネークケース」と書いても、Tabで確定するゴーストテキストには反映されません。命名や書式を確実に揃えたいなら、ESLintやPrettier、Ruffなどのリンター・フォーマッターに設定し、指示ファイルにはリンターで表現できないルール（設計方針、使ってはいけないライブラリ、テストの置き場所）を書く分担が確実です。

copilot-instructions.mdの配置場所

指示を置く場所は、誰に効かせたいかで3つに分かれます。チームで共有する規約はリポジトリ、自分の好みは個人、全社のルールは組織です。

リポジトリ単位：.github/copilot-instructions.md

リポジトリのルートにある.githubフォルダ（無ければ作成）の直下に、copilot-instructions.mdというファイル名で置きます。.github/workflowsと同じ階層です。ルート直下にcopilot-instructions.mdを置いても読まれません。Gitにコミットすれば、リポジトリをクローンした全員とcloud agentに同じ指示が届きます。

my-repo/
├── .github/
│   ├── copilot-instructions.md        # リポジトリ全体の指示
│   ├── instructions/
│   │   ├── frontend.instructions.md   # applyTo: "src/web/**"
│   │   └── tests.instructions.md      # applyTo: "**/*.test.ts"
│   └── workflows/
├── AGENTS.md                          # 複数のエージェントで共有する指示
└── src/

モノレポでパッケージごとに指示を変えたいときは、copilot-instructions.mdを各フォルダに複製するのではなく、applyToでパッケージのパスを指定した*.instructions.mdを作るか、各パッケージにAGENTS.mdを置きます。Copilot CLIは、リポジトリのルートから作業中のディレクトリまでの各階層にある.github/copilot-instructions.mdも探しますが、VS CodeやGitHub.comはルートの1ファイルを前提にしています。

個人単位（global）：ユーザーフォルダとVS Codeのプロファイル

すべてのプロジェクトで使いたい自分用の指示（「回答は日本語で」など）は、リポジトリではなく個人の場所に置きます。置き場所はツールで異なります。

Copilot CLIでは環境変数COPILOT_HOMEを設定すると、~/.copilotの代わりにそのディレクトリを使います（Adding custom instructions for GitHub Copilot CLI）。VS Codeのプロファイルに置いた指示はSettings Syncで他の端末へ同期できますが、~/.copilot/instructionsのようなフォルダに置いた指示は同期されません。個人の指示に「このプロジェクトではpnpmを使う」のような特定リポジトリの事情を書くと、無関係なリポジトリでも毎回送られて邪魔になります。個人の指示は言語や回答スタイルなど、どのプロジェクトでも変わらないものに絞ります。

組織単位：Organizationのカスタム指示

Copilot BusinessかCopilot Enterpriseを契約している組織では、Organizationのオーナーが「Settings」→「Copilot」→「Custom instructions」から組織全体の指示を登録できます（Adding organization custom instructions）。GitHub.comのChatでは、個人、リポジトリ、組織の順で優先度が高いとされていますが、優先度が低い指示も捨てられず、すべてがCopilotに渡されます。VS Codeで組織の指示を読ませるには、設定github.copilot.chat.organizationInstructions.enabledをtrueにします。

copilot-instructions.mdを作成する手順

手で書く方法と、Copilotに生成させる方法があります。既存のリポジトリでは、自動生成を下書きに使い、人がコマンドやパスを確認して仕上げる方法もあります。

copilot-instructions.mdの手動作成手順

1. リポジトリのルートに.githubフォルダが無ければ作成します。
2. .github/copilot-instructions.mdを作り、Markdownで指示を書きます。指示と指示の間の空白や改行は無視されるので、1段落でも、1行1指示でも、空行区切りでも構いません。
3. コミットしてプッシュします。Copilot CLIは実行中のセッションには変更を反映しないため、いったん終了してcopilot --continueで再開するか、/newで新しいセッションを始めます。

VS Codeの/initとcloud agentによる指示ファイルの自動生成

VS CodeのChatでLocalエージェントを選び、/initと入力すると、ワークスペースを解析してプロジェクト全体の指示ファイルを生成します。特定の規約だけを足したいときは/create-instructionsを使います。コマンドパレットの「Chat: Open Customizations」で開くAgent Customizationsエディタからも作成できます。

GitHub.com側では、github.com/copilot/agentsで対象リポジトリを選び、GitHub Docsに載っている生成用プロンプトを貼るとcloud agentがcopilot-instructions.mdをドラフトのプルリクエストとして作ります。このプロンプトは「指示は2ページ以内」「特定のタスクに依存させない」を条件にし、ビルド・テスト・リントの各手順を実際に実行して動く順番を書くよう求めています。生成物のコマンドやパスは推測を含むことがあるため、マージ前に1つずつ実行して確かめます。

copilot-instructions.mdのサンプル

そのままコピーして書き換えられるサンプルを3つ載せます。どれも「プロジェクトで実際に使うコマンドとライブラリ名に置き換える」ことが前提です。架空のコマンドを残すと、Copilotはそれを実行しようとして失敗します。

Webアプリ（TypeScript・React）の基本サンプル

GitHub Docsの例と同じく、概要、技術スタック、規約を見出しで分けた形です。版番号は例なので、自分のプロジェクトのpackage.jsonに合わせて書き換えます。版まで書いておくと、古いAPIでコードを書かれる事故が減ります。

# プロジェクト概要
社内向けの勤怠管理Webアプリ。フロントエンドはReact、バックエンドはNode.jsのREST API。

## 技術スタック
- TypeScript 5.9（strict有効）、React 19、Vite 7
- 状態管理はTanStack Query。Reduxは使わない
- バックエンドはExpress 5、DBアクセスはPrismaのみ（生SQLを書かない）

## ビルドとテスト
- 依存関係のインストール: pnpm install（npmとyarnは使わない）
- 型チェック: pnpm typecheck
- テスト: pnpm test --run（package.jsonのtestスクリプトがvitestの場合）。挙動を変えたら必ずテストを追加する
- コードを変更したら、提案の前に pnpm lint と pnpm typecheck が通る形にする

## コーディング規約
- コンポーネントは関数コンポーネントとアロー関数で書く
- API呼び出しは src/api/ のラッパー経由にする。fetchを直接呼ばない
- 日付処理は date-fns を使う（Moment.js はメンテナンスモードのため、新規採用しない）

## 回答
- 説明は日本語で書く。コード中のコメントも日本語にする

ビルドとテストの手順を中心にしたサンプル（cloud agent向け）

Copilot cloud agentやCopilot CLIに作業させるリポジトリでは、コマンドの順番と既知の落とし穴を書いた方が効果が大きくなります。GitHub Docsの生成用プロンプトが求めている項目（ビルド・テスト・リントの手順、CIで走るチェック、主要ファイルの場所）に合わせた形です。

# このリポジトリでの作業手順

## 環境
- Python 3.12、パッケージ管理は uv
- 最初に uv sync を実行する。これを飛ばすと import エラーになる

## 検証（変更後に必ずこの順で実行する）
1. uv run ruff check .
2. uv run mypy src
3. uv run pytest -q
- 統合テスト（tests/integration）はDockerが必要。ローカルで動かせないときは、対象テストに integration マーカーが付いていることを確認し、uv run pytest -q -m "not integration" で除外してよい

## 構成
- APIのルーティングは src/app/routes/、DBアクセスは src/app/repositories/ に置く
- 設定値は src/app/settings.py に集約されている。環境変数を直接読まない
- CIは .github/workflows/ci.yml。ruff・mypy・pytestの3つが通らないとマージできない

## 注意
- この指示に書いてある内容を信頼し、情報が足りないか誤っているときだけ検索する

最後の1行は、GitHub Docsの生成用プロンプトにある「指示を信頼し、不完全か誤っているときだけ検索する」という方針を写したものです。cloud agentがリポジトリを探索するコマンドの回数を減らす狙いがあります。

コードレビューを日本語で行わせるサンプル

Copilot code reviewもこのファイルを読みます。GitHub Docsのコードレビュー向けの例は「When performing a code review, respond in Spanish.」のように、レビューに限定する前置きを付けています。同じ形で日本語にすると次のようになります。

## コードレビュー
- コードレビューを行うときは、日本語で回答する
- コードレビューを行うときは、docs/security-checklist.md のチェック項目を適用する
- ハードコードされたシークレット、APIキー、認証情報がないか確認する
- ネストした三項演算子は避け、読みやすさを優先するよう指摘する

レビューの観点が多いときは、.github/instructions/review.instructions.mdに分けてexcludeAgent: "cloud-agent"を付けると、cloud agentの作業時にはレビュー用の指示が混ざりません。Copilotのコードレビューそのものの依頼方法と自動化は「GitHub Copilotのコードレビュー｜依頼方法・自動化・日本語化と料金」で扱っています。

copilot-instructions.mdの書き方のベストプラクティス

GitHub DocsとVS Codeのドキュメントが挙げる書き方の原則は、短く、自己完結し、理由を添えることです。具体的には次の5点を守ります。

• 1指示1文の命令形で書く：「〜した方が良いかもしれません」ではなく「〜する」「〜しない」と書きます。長い説明文より、見出しと箇条書きの短い指示の方が拾われやすいとGitHub Docsのコードレビュー向けチュートリアルは説明しています。
• ルールの理由を書く：「Moment.jsはメンテナンスモードで、新規プロジェクトには代替ライブラリが推奨されているためdate-fnsを使う」のように理由があると、指示に書いていない境界のケースでも判断が揃います（VS Codeのドキュメントの例を、Moment.js公式の保守方針に合わせて調整）。
• リンターが強制できることは書かない：セミコロンやインデントは設定ファイルで機械的に揃える方が確実です。指示ファイルの容量は、設計方針や禁止ライブラリのように機械で検出しにくいルールに使います。
• 長さは短く保つ：指示はリクエストのたびに送られます。コードレビュー向けのチュートリアルは、1ファイルあたり約1,000行を上限の目安とし、それを超えると回答の質が落ちうるとしています。cloud agent向けの生成プロンプトは「2ページ以内」を条件にしています。なお、Copilot code reviewにはかつて4,000文字を超えた部分を読まない制限がありましたが、2026年6月12日に撤廃されました（GitHub Changelog）。「4,000文字以内に収める」と書いた古い解説は、現在のレビューには当てはまりません。
• 良い例と悪い例をコードで示す：命名規則ならconst d = new Date()（避ける）とconst currentDate = new Date()（推奨）を並べると、抽象的な規則より正確に伝わります。

書いても効きにくい指示の例

GitHub Docsは、大きく多様なリポジトリでは次の種類の指示が意図どおりに働かない可能性があると明記しています。

• 外部のリソースを参照させる指示（例：「別リポジトリのstyleguide.mdに従ってコードを書く」）
• 回答の口調を指定する指示（例：「親しい同僚のようにくだけた言葉で答える」）
• 回答の分量を一律に縛る指示（例：「すべての質問に1,000文字未満で答える」）

別リポジトリのスタイルガイドを守らせたいなら、参照を指示するより要点を指示ファイル本体に書き写す方が確実です。同じリポジトリ内のファイルなら、Copilot CLIではcopilot-instructions.md・AGENTS.md・CLAUDE.mdの中に@と相対パスを書くと、そのファイルの内容が読み込まれます。VS Codeでは指示ファイル内のMarkdownリンクが参照として扱われます。

.instructions.mdでパス別に指示を分ける方法

フロントエンドとバックエンドで規約が違う、テストコードだけに別のルールがある、といった場合はcopilot-instructions.mdに全部を書かず、.github/instructions/配下に分けます。ファイル名は.instructions.mdで終わる必要があり、サブフォルダで整理しても構いません。

applyToのglob書式

ファイルの先頭にYAMLフロントマターを置き、applyToに対象ファイルのglobを書きます。複数のパターンはカンマで区切ります。

---
applyTo: "**/*.ts,**/*.tsx"
---
# TypeScriptの規約
- any型を使わない。型が決められないときは unknown にして絞り込む
- 例外は src/errors/ の独自エラークラスで投げる

globが対象パスに一致しないと、パス一致による自動適用は行われません。GitHub Docsに載っている例のうち、間違えやすいものを抜き出します。

「リポジトリ内のすべての.tsx」を指定するつもりで*.tsxと書くと、ルート直下のファイルにしか当たりません。サブフォルダを含めるなら**/*.tsxです。

excludeAgentによるコードレビューとcloud agentの適用先の分離

フロントマターにexcludeAgentを書くと、そのファイルをCopilot code reviewかCopilot cloud agentの片方から外せます。値は"code-review"か"cloud-agent"のどちらかです。省略すると両方が読みます。

---
applyTo: "**"
excludeAgent: "code-review"
---
# cloud agentだけが読む作業手順
- 変更後は pnpm test を実行し、失敗したテストを修正してからプルリクエストを作る

注意点として、cloud agent側の値は以前のドキュメントでは"coding-agent"でした。GitHub Docsは2026年4月7日のコミットで製品名をcoding agentからcloud agentへ改めた際に、この値の表記も"cloud-agent"へ書き換えています（github/docs a31ee09）。古い記事の"coding-agent"をそのまま写している場合は、現行の表記に合わせます。VS Codeのドキュメントが挙げる.instructions.mdのフロントマター項目はname・description・applyToの3つで、excludeAgentは含まれていません。VS CodeのChatから外す目的では使えないと考えてください。

VS Codeのdescriptionによる読み込み

VS CodeではapplyToに加えて、description（このファイルがどの作業に関係するかの説明）を書くと、エージェントが作業内容と照らして必要なときに指示ファイルを読み込みます。applyToもdescriptionも無いファイルは自動では使われず、チャットに手動で添付したときだけ効きます。

---
name: 'Python testing'
description: 'Pythonの単体テストを作成・更新するときに使う'
applyTo: '**/*.py'
---
- テストは pytest で書き、tests/ 配下に src と同じ構成で置く

AGENTS.md・CLAUDE.md・.prompt.mdとの違い

名前の似たファイルが増えていますが、役割は「常に読まれる指示」「呼び出したときだけ使うプロンプト」「エージェントの役割定義」の3系統に分かれます。

AGENTS.mdとcopilot-instructions.mdの使い分け

AGENTS.mdは特定のツール専用ではない共通形式で、仕様はagents.mdで公開されています。エージェントの人格や役割を定義するファイルではなく、中身はcopilot-instructions.mdと同じく「このリポジトリで守ること」を書いたMarkdownです。両形式に対応した機能では両方が読み込まれます。GitHub.comの優先順位では、リポジトリ全体の指示がAGENTS.mdなどのエージェント向け指示より上位です。

判断は次のとおりです。チームがCopilotだけを使うならcopilot-instructions.mdだけで足ります。Copilotに加えてCodex、Cursor、Claude Codeなどを併用するなら、ビルド手順や規約の共通部分をAGENTS.mdに書き、Copilot固有の指示（コードレビュー向けの観点、GitHub.comのChat向けの補足）だけをcopilot-instructions.mdに残します。同じ内容を両方に書き写すと、片方だけ更新されて矛盾が生まれます。VS CodeのLocalエージェントでは設定chat.useAgentsMdFileでAGENTS.mdの読み込みをオン・オフでき、サブフォルダのAGENTS.mdを読むchat.useNestedAgentsMdFilesは既定で無効です。Claude Code側のファイルの扱いは「Claude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順」、Cursorのルールファイルは「.cursorrulesとは？非推奨の現状と.cursor/rules（.mdc）への移行・書き方【2026年9月】」にまとめています。

.prompt.mdとカスタムエージェント（.agent.md）の位置づけ

*.prompt.mdは、「このファイルのテストを書いて」のような定型作業のプロンプトを保存しておき、チャットで/に続けて名前を入力して呼び出すファイルです（VS Code: Prompt files）。呼び出したときだけ使われる点が、常に読まれるcopilot-instructions.mdとの違いです。

*.agent.mdはカスタムエージェント（たとえば「計画だけを立てて編集はしないエージェント」）の役割、使えるツール、モデルを定義するファイルです（VS Code: Custom agents）。エージェントの役割を定義するのはこちらで、AGENTS.mdとは名前が似ているだけの別物です。手順書ごとまとめて配布したい場合はAgent Skills（SKILL.md）も選択肢になり、「Agent Skillsとは？SKILL.md仕様と46製品で動かす移植性の実装手順」で仕様を解説しています。

copilot-instructions.mdが効かないときの確認ポイント

「書いたのに反映されない」原因の多くは、ファイルの場所か、使っている機能が対応しているかのどちらかです。次の順で確かめます。

1. ファイル名と場所：.github/copilot-instructions.mdになっているか。.github/copilot_instructions.md（アンダースコア）や、ルート直下への配置は読まれません。
2. 参照に出ているか：Chatの回答上部にある「References（参照）」を開き、copilot-instructions.mdが一覧にあるかを見ます。GitHub.comでもVS Codeでも、使われた指示ファイルはここに表示されます。
3. 使っている機能が対応しているか：インライン補完には効きません。GitHub.comのChatは*.instructions.mdを読みません。前の節の対応表で、機能と環境の組み合わせを確認します。
4. VS Codeの設定：Localエージェントでは、github.copilot.chat.codeGeneration.useInstructionFilesが有効なときにcopilot-instructions.mdを読みます。*.instructions.mdはchat.includeApplyingInstructions、AGENTS.mdはchat.useAgentsMdFileが関係します。コマンドパレットの「Developer: Open Agent Debug Logs」で、どの指示ファイルが見つかったかとエラーを確認できます。
5. コードレビューの設定とブランチ：リポジトリの「Settings」→「Copilot」→「Code review」にある「Use custom instructions when reviewing pull requests」がオフになっていないか確認します。また、プルリクエストのレビューでは、ベースブランチではなく変更元（head）ブランチの指示ファイルが読まれます。指示ファイルを直したプルリクエストでは、マージ前からその修正がレビューに効きます。
6. Copilot CLIの再起動：CLIは実行中のセッションに変更を反映しません。セッションを再開し、/instructionsコマンドで読み込まれたファイルの一覧と有効・無効を確認します。

指示同士が矛盾している場合、VS CodeのドキュメントもCopilot CLIのドキュメントも、ファイルの順番や優先順位で解決できるとは考えないよう求めています。個人の指示で「axiosを使う」、リポジトリの指示で「社内のHTTPクライアントを使う」と書いてあれば、結果は不定です。矛盾は元のファイル側で消します。

VS CodeでのCopilotの導入とチャットの基本操作は「VS CodeでGitHub Copilotを使うには？導入手順・使い方・料金を解説【2026年9月版】」、CLIでの自律実行は「GitHub Copilot CLIのAutopilotとは｜使い方・止まる条件・料金と導入手順【2026年9月】」で扱っています。社内の開発チームにCopilotなどの生成AIツールを定着させる指示ファイルの整備から相談したい場合は、生成AI導入支援でも対応しています。

copilot-instructions.mdに関するよくある質問

copilot-instructions.mdはどこに置けばよいですか？

リポジトリのルートにある.githubフォルダの直下に.github/copilot-instructions.mdとして置きます。すべてのリポジトリで使う個人用の指示は、Copilot CLIとVS Codeのエージェントホストなら~/.copilot/copilot-instructions.mdに置きます。

copilot-instructions.mdのサンプルや公式テンプレートはありますか？

GitHub Docsの「Customization library」に、コードレビュー担当やテスト自動化など役割別のカスタム指示の例がまとまっています（Custom instructions – GitHub Docs）。この記事のサンプル3種も、そのまま書き換えて使えます。

.instructions.mdとcopilot-instructions.mdの違いは何ですか？

copilot-instructions.mdはリポジトリ全体に効く1ファイルで、*.instructions.mdは主にapplyToで対象を絞る分割ファイルです。VS Codeではdescriptionによる読み込みや手動添付も利用できます。両方が当たる場面では両方の指示が使われます。GitHub.comのChatは*.instructions.mdを読まない点に注意してください。

AGENTS.mdとcopilot-instructions.mdはどちらを使うべきですか？

Copilotだけを使うならcopilot-instructions.mdで十分です。CodexやCursorなど複数のAIエージェントを併用するなら、共通の手順と規約をAGENTS.mdに書き、Copilot固有の指示だけをcopilot-instructions.mdに残します。ただし、GitHub.comのChatなどAGENTS.md非対応の機能にも必要な指示は、copilot-instructions.md側に用意します。

copilot-instructions.mdは日本語で書いても効きますか？

Markdownの自然言語で書くファイルなので、日本語で書いても読み込まれます。回答やレビューを日本語にしたいなら「説明は日本語で書く」「コードレビューを行うときは日本語で回答する」と明記します。ただし、インライン補完には指示ファイルそのものが効かないため、補完の候補に含まれるコメントの言語までは制御できません。

関連記事

• VS CodeでGitHub Copilotを使うには？導入手順・使い方・料金を解説【2026年9月版】
• GitHub Copilotエージェントモードの使い方｜Ask・Edit・Agentの違いと有効化・料金【2026年版】
• GitHub Copilotのコードレビュー｜依頼方法・自動化・日本語化と料金
• .cursorrulesとは？非推奨の現状と.cursor/rules（.mdc）への移行・書き方【2026年9月】
• Agent Skillsとは？SKILL.md仕様と46製品で動かす移植性の実装手順