命令の正本を一つにする（One Authoritative Source for Instructions）
優先順位が定義されていない以上、競合を作らない。狙いは「どれが勝つか」を正しく設計することではない — それはできない。できるのは、勝ち負けが起きない形に置くことだけである。
問題
同じ内容を複数の命令ファイルに書いていて、いつの間にか食い違ってきた。片方を直したとき、もう片方を直し忘れたのである。そこで「どちらが勝つのか」を調べに行く。ところが公式ドキュメントが、面ごとに違うことを言っている — ある面は完全な優先順位を定め、別の面も順序を定めるがその並びが食い違い、また別の面は「一般的な優先順位は定めていない」と明記している（公式、具体例節）。つまり、読者が正解を調べに行っても、正解が無い。競合は残り、どちらが効いているのかは誰にも言えない。
コンテキスト
適用する条件:
- 命令ファイルが複数ある — 個人の層・リポジトリの層・組織の層が併存する。あるいは同じリポジトリに、別々の名前の命令ファイルが同居している
- 複数の面で同じリポジトリを使う — エディタで書き、CLI で回し、ブラウザ上でも同じ命令が読まれる
- 命令を階層化した後 — 層を作った時点で、正本が割れる余地ができている
適用しないケース:
- 命令が1ファイルしかないとき。 競合が起きえないので、本パターンは何もしない
- 意図的に面ごとに違う命令を効かせたいとき。 ただし、それが本当に意図なのかを確かめること — 「面ごとに違っていてよい」と「面ごとに違ってしまった」は、出来上がりが区別できない
隣接パターンとの境界:
- 命令の階層化と適用範囲の限定 — ⚠ 同パターンは競合を作る方向に働く。 層を増やすほど正本は割れやすくなる。本パターンは同パターンの副作用を扱う。 同パターンは代償として「どれが効いているか分からなくなる」を自ら挙げており、本パターンはその状態を作らないための型である。2つは併用するが、引っ張る向きが逆である
- ルールを拘束力で階層化する — 同パターンは1つのファイルの中で重みを付ける。本パターンはファイル間を扱う。衝突の解決を拘束力で書けるのは、同一ファイル内に限る — ファイルをまたぐと、そもそもどちらが読まれるかが定義されていない
- 常駐物の棚卸し — 正本を一つにすることは、複製を減らすことでもある。数えて捨てるのが同パターン、複製を作らないのが本パターン
解決
面ごとの答えを並べると、次のようになる。
| 面 | 優先順位の扱い | 結果 |
|---|---|---|
| 面 A | 一般的な順序は定めていないと明記 | 競合したとき何が起きるかを予測できない |
| 面 B | 完全な順序を定める | ただし面 C と並びが食い違う |
| 面 C | 順序を定める | ただし面 B と並びが食い違う |
なぜ効くのか。本パターンの根拠は、他の型と質が違う。「一つにまとめると良い」という一般論ではない。 根拠は、競合の解決規則が存在しないという、確かめられる事実のほうにある。
普通、優先順位が定義されていれば、競合は設計できる。重要なものを上の層に置き、上書きされてよいものを下に置けばよい。競合は事故ではなく道具になる。ところが、「一般的な優先順位は定めていない」と明記している面がある（公式、具体例節）。定義されていない以上、競合したときに何が起きるかは、こちらから予測できない。予測できないものは設計できない。
「予測できない」の実体は、もう一段はっきりしている。競合しても、片方が捨てられるわけではない。 3つの面が揃って、命令は全部渡すと書いている（公式、具体例節）— 捨てる面は一つも無い。つまり矛盾した2つの指示は、矛盾したまま同時にモデルへ届く。競合を解いているのは、文書化された規則ではなくモデルである。 その出力は、どの面の docs にも書かれていない。
したがって残る手は一つしかない。競合を発生させないことである。 内容は一箇所に置き、他所からは参照する。複製しなければ、食い違いようがない。
これは消極的な結論に見えて、実は最も強い形の設計である。 解決規則に依存しない設計は、解決規則が変わっても壊れない。面ごとに規則が違い、しかもその規則が改訂されうる領域では、規則に賭けないことが唯一の安定である。 正しい規則を選ぶ競争から降りたぶんだけ、負けようがなくなる。
そして — 公式 自身が同じ結論に達している。 完全な順序を定めている面が、その順序を定めたのと同じページで、「できる限り、競合する命令の組を与えるな」と書いている（公式、具体例節）。順序を定義した当人が、順序に頼るなと言っている。 自分で書いた規則を、自分で信頼しきっていない。これは強い傍証である — 規則があることと、規則に賭けてよいことは、別である。
トレードオフ
利点
- どの面で使っても、同じ命令が効く。 正本が一つなら、面ごとの解決規則が何であっても結果は変わらない。規則が面ごとに違うこと自体が、影響しなくなる。 ある面で確かめた挙動が別の面でも成り立つ根拠を、docs の突き合わせに求めずに済む。
- 食い違いのメンテナンスが消える。 複製が無ければ、同期する作業も、同期が漏れたことに後から気づく作業も要らない。複製の数だけあった「直し忘れる場所」が、ゼロになる。
代償
- 参照は複製より不便である。 一箇所にまとめると、面ごとの都合に合わせられない。 複製すれば各所を最適な形に整えられるが、それはまさに本パターンが禁じていることである。利便性を、安定と引き換えに差し出している。
- 面ごとに違う命令を効かせたい、正当な場合がある。 対話的に使う面では冗長な出力を抑えたい、といった要求は本物でありうる。本パターンはそれを難しくする。 正本を一つにするとは、「面ごとに違えたい」を例外として毎回正当化させることでもある。
GitHub Copilot での具体例
Copilot は単一の製品ではない。本パターンにとって、この事実は前置きではなく主題そのものである。同じ問い — 命令ファイルが競合したらどうなるか — に、3つの面が違う答えを書いている。 以下は推測ではなく、3本の 公式 の逐語比較である。
Copilot CLI — 「一般的な優先順位は定めていない」と明記する
出典: Copilot CLI — カスタム命令の追加（取得日: 2026-07-16）公式:
When multiple applicable user-level and repository instruction files exist, Copilot CLI combines their instructions. It removes duplicate copies of identical user-level
copilot-instructions.md, repository-wide, and agent instructions, but does not define a general precedence order between these files. Avoid conflicting instructions.〔訳〕複数の適用可能なユーザーレベルおよびリポジトリの命令ファイルが存在する場合、Copilot CLI はそれらの命令を結合する。同一のユーザーレベル
copilot-instructions.md、リポジトリ全体、およびエージェントの命令の重複コピーは取り除くが、これらのファイル間の一般的な優先順位は定めない。競合する命令は避けよ。
複数の命令ファイルがあるとき、この面はそれらを結合する（combines）。同一内容の重複は取り除くが、これらのファイル間の一般的な優先順位は定めない（does not define a general precedence order between these files）。そして最後に一文だけ、助言が付く — Avoid conflicting instructions.
「定めていない」は 公式 である — 未文書化 でも 不在確認 でもない
未文書化 は「挙動を観測した」＋「公式に記載が無い」の二重の主張であり、本カタログは競合時の挙動を観測していないので貼れない。不在確認 は「一次資料に当たり、記述が無いことを確認した」という主張だが、ここで起きているのはその逆である — 記述はある。 その記述の内容が「定めていない」なのである。
つまりこれは公式が明示的に述べた設計上の事実であり、公式 で足りる。 「公式に書かれていない」のではなく「公式が『定めていない』と書いている」。この差は大きい — 前者なら探し方が悪かった可能性が残るが、後者にはそれが無い。
同じ面には、いま何が効いているのかを人間が直接見る口もある 公式:
Use the
/instructionscommand to view the instruction files discovered for the current session and enable or disable individual files.〔訳〕
/instructionsコマンドを使うと、現在のセッションで発見された命令ファイルを表示し、個々のファイルを有効・無効にできる。
いまのセッションで発見された命令ファイルを一覧し、個別に有効・無効を切り替えられる。正本が割れているかどうかを、記憶や推測ではなく一覧で確かめられる面である。
github.com — 完全な順序を定める
出典: GitHub — 応答のカスタマイズ（取得日: 2026-07-16）公式:
Multiple types of custom instructions can apply to a request sent to Copilot. Personal instructions take the highest priority. Repository instructions come next, and then organization instructions are prioritized last. However, all sets of relevant instructions are provided to Copilot.
〔訳〕Copilot に送られるリクエストには複数種類のカスタム命令が適用されうる。個人の命令が最優先であり、次にリポジトリの命令、最後に組織の命令の優先順位となる。ただし、関連するすべての命令一式は Copilot に提供される。
同ページはさらに、**完全な順序（the complete order of precedence）**を列挙する 公式:
The following list shows the complete order of precedence, with instructions higher in this list taking precedence over those lower in the list:
- Personal instructions
- Repository custom instructions:
- Path-specific instructions in any applicable
.github/instructions/**/*.instructions.mdfile- Repository-wide instructions in the
.github/copilot-instructions.mdfile- Agent instructions (for example, in an
AGENTS.mdfile)- Organization custom instructions
〔訳〕以下が完全な優先順位のリストであり、このリストで上位にある命令が下位にある命令より優先される。Personal instructions、Repository custom instructions(該当する
.github/instructions/**/*.instructions.mdファイルにおける Path-specific instructions を含む)、.github/copilot-instructions.mdファイルにおける Repository-wide instructions、Agent instructions(例:AGENTS.mdファイル)、Organization custom instructions、の順である。
原文の規則は「上にあるものが、下にあるものに優先する」である。先頭が Personal、末尾が Organization。その間に、Repository のカスタム命令（path-specific）、repo-wide の .github/copilot-instructions.md、そして agent 命令 — 原文が例として挙げているのが AGENTS.md である — が、この順で並ぶ。AGENTS.md は repo-wide より下に位置する。 CLI が「定めていない」と書いたものを、この面は一覧で定めきっている。
そして、その順序を示した上で、こう書いている 公式:
Whenever possible, try to avoid providing conflicting sets of instructions.
〔訳〕可能な限り、競合する命令の組を与えないようにせよ。
完全な順序を定めている面が、その順序に頼るなと言っている。 これが「解決」で述べた傍証である。順序を書いた当人が、競合を作らないほうを勧めている。
VS Code — 順序を定めるが、github.com と食い違う
出典: VS Code — カスタム命令（取得日: 2026-07-16）公式:
When multiple types of custom instructions exist, they are all provided to the AI. Higher-priority instructions take precedence when conflicts occur:
- Personal instructions (user-level, highest priority)
- Repository instructions (
.github/copilot-instructions.mdorAGENTS.md)- Organization instructions (lowest priority)
〔訳〕複数種類のカスタム命令が存在する場合、それらはすべて AI に提供される。競合が生じた場合は、優先度の高い命令が優先される。順に、Personal instructions(ユーザーレベル、最優先)、Repository instructions(
.github/copilot-instructions.mdまたはAGENTS.md)、Organization instructions(最下位)である。
こちらも Personal が最上位、Organization が最下位である。両端は github.com と一致する。食い違うのは真ん中である — この面は .github/copilot-instructions.md または（or） AGENTS.md と書き、二つを同じ段に並べている。github.com は同じ二つを別々の段に置き、AGENTS.md を repo-wide の下に落としていた。
突き合わせ — 同じ問いに、3つの答え
| 面 | 一般的な優先順位を定めているか | AGENTS.md の位置 | 出典 |
|---|---|---|---|
| Copilot CLI | 定めていないと明記 | — | 上記 add-custom-instructions |
| github.com | 完全な順序を定める | repo-wide の .github/copilot-instructions.md の下 | 上記 response-customization |
| VS Code | 順序を定める（3段） | .github/copilot-instructions.md と同一段 | 上記 custom-instructions |
論点は2つある。混ぜずに読む必要がある。
(1) CLI と、他の2面。 一方は「定めていない」と明記し、他方は「定めている」。同じ製品名を掲げた面のあいだで、設計そのものが違う。 これは詳細の差ではない — 「優先順位という概念を持つかどうか」の差である。
(2) github.com と VS Code。 どちらも順序を定めているのに、AGENTS.md の扱いが違う。 一方は repo-wide より下の段に置き、他方は repo-wide と同じ段に並べる。この2面は、両方が答えを持っていて、その答えが一致していない。
本カタログは、どちらが正しいかを知らない
確認したのは、上の3本の原文が、この取得日のこの URL で、それぞれこう書いていたというところまでである。挙動は観測していない。 したがって「実際には AGENTS.md はこう扱われる」を本カタログは主張しないし、「どちらの docs が誤りである」とも言わない。
読者に渡しているのは判定ではなく、判定の材料である。面ごとに違うことが書かれているという事実を、逐語と URL と取得日つきで置く。重みは読者が決める。
3面が一致していること — 命令は捨てられない
食い違いばかりが目立つが、3面が揃って書いていることが一つある。競合しても、どれも捨てられない。
- VS Code: 「they are all provided to the AI」〔訳: それらはすべて AI に提供される〕
- github.com: 「However, all sets of relevant instructions are provided to Copilot.」〔訳: ただし、関連するすべての命令一式は Copilot に提供される〕
- Copilot CLI: 「Copilot CLI combines their instructions」〔訳: Copilot CLI はそれらの命令を結合する〕— 取り除くのは同一内容の重複だけである
いずれも上記の各面の原文である（3本とも全文を上に引いてある）。矛盾した2つの命令があるとき、どの面も片方を捨てない。両方がモデルに届く。 これが「解決」で述べた「予測できない」の実体である。順序とは、渡す前に片方を落とす仕組みではない — 全部渡した上で、どちらを重く見るかの示唆にすぎない。
そして2つの面は、この状況への助言まで明記している — CLI の「Avoid conflicting instructions.」〔訳: 競合する命令は避けよ〕と、github.com の「Whenever possible, try to avoid providing conflicting sets of instructions.」〔訳: 可能な限り、競合する命令の組を与えないようにせよ〕（いずれも上記の原文）。順序を定めている側の面が、順序に頼るなと書いている。
別名
| 呼称 | 出典 |
|---|---|
| 単一の source of truth / SSOT | 通説 — コミュニティで流布しているが、この用法に一次出典を辿れない。かつ、既存の確立した用語と衝突する（下記） |
| 命令の正本を一つにする / One Authoritative Source for Instructions | 記述 — 本カタログの記述的呼称であり、一次資料に出典は無い |
SSOT は、借り物ではなく先住者のいる名前である。 データ設計・構成管理の領域では、データの正本を一箇所に持つことを指す語として確立している。本パターンが言うのは命令の正本を一つにすることであり、構造は近いが、対象が違う — あちらはデータ、こちらは命令である。この近さが実害を生む。SSOT と呼べば読者はまず既存の意味を思い浮かべ、そこから読み替える手間が毎回かかる。読み替えに失敗した読者は、本パターンを自分に関係のない話として通り過ぎる。近い名前ほど、誤読は静かに起きる。
そのため本カタログは、旧称「単一の source of truth」を、この衝突を理由に改めた（本カタログの設計上の判断であり、外部の呼称変更ではない）。それでも SSOT は別名として残す — 読者がその名で探しに来るからである。名前を捨てるより、衝突を明記した上で併記するほうが、読者は辿り着ける。
関連
- 命令の階層化と適用範囲の限定 — 階層を作ると正本は割れやすくなる。本パターンは同パターンの副作用を扱う。 同パターンは代償として「どれが効いているか分からなくなる」を自ら挙げており、本パターンはその状態を作らないための型である。併用するが、引っ張る向きは逆である — 層を足すたびに、正本を割らずに足せているかを確かめることになる
- ルールを拘束力で階層化する — 同パターンは1つのファイルの中で重みを付ける。本パターンはファイル間を扱う。拘束力で衝突を解けるのは、同一ファイル内に限る — ファイルをまたぐと、そもそもどちらが読まれるかが定義されていない。同じ「優先順位」という言葉が、この境界をまたいだ瞬間に意味を失う
- 常駐物の棚卸し — 正本を一つにすることは、複製を減らすことでもある。数えて捨てるのが同パターン、複製をそもそも作らないのが本パターン。正本を一つに保っても、その正本自体は肥大しうる — 複製が無いことと軽いことは別問題であり、後者を扱うなら次に読むとよい
- 機械ゲートと意味ゲートの分離 — 2つの命令が競合しているかどうかは、文字列では判定できない。機械ゲートに任せられないから、設計で避ける。 検出できないものは、起こさないようにするしかない
- まず次に読むなら 失敗の制度記憶化 — 正本を決めたら、次は事故の記録を正本に載せる番である