検証対象の明示（Making the Verification Target Explicit）

「確認して」だけでは、何を確認するかをモデルが後から決めてしまう。検証の基準を、答えより先に契約として渡す。

問題

モデルが「直った」と言うが、直っていない。ただし原因は一様ではない。機械ゲートと意味ゲートの分離が扱うのは、決定的に判定できることが命令という非決定的な手段に載っている失敗である。本パターンが扱うのは、そのさらに手前にある失敗である — そもそも何を基準に「直った」と言えばよいのかを、こちらが渡していない。

「ちゃんと動くか確認して」と言えば、モデルは何かを確認する。何を確認したかは、こちらが決めていない。検証という行為は行われるのに、的が無い。

コンテキスト

適用する条件:

検証させたい基準が具体的にある
「動く」の定義が自明でない
同じ検証を繰り返す

適用しないケース:

基準が機械で表現できるとき。テストで書けるならテストで書く（→ 機械ゲートと意味ゲートの分離）。本パターンが扱うのは、機械に落とせない基準を言葉の契約として渡す場面である
探索段階で、何が正しいかまだ分からないとき。基準を固定できないうちに固定すると、探索を狭める

隣接パターンとの境界:

機械ゲートと意味ゲートの分離 — 同パターンは「どの種類のゲートに載せるか」、本パターンは「何を基準に確かめさせるか」。機械ゲートに載せられるなら、そちらが優先する
命令の階層化と適用範囲の限定 — 同じ機構（applyTo）を別の目的に使う。同パターンは「どの命令を適用するか」、本パターンは「その作業で何を満たすべきか」を範囲つきで渡す
計画の先制検証 — 同パターンはやる前に計画を検証する、本パターンはやった後に何を検証させるかを扱う
失敗の制度記憶化 — 過去の失敗は、検証項目として書くと最も効く。同パターンの三つ組の「条件」が、そのまま検証の的になる

解決

なぜ効くのか。検証は照合である。照合には照合先が要る。照合先を渡さないと、モデルは自分で作る — そして自分で作った基準に対しては、ほぼ必ず合格する。「動くか確認して」への答えが常に「動きます」になるのは、嘘だからではない。基準が答えと一緒に作られているからである。

だから本パターンの主張は「厳しく検証させろ」ではない。基準を、答えより先に固定しろである。順序がすべてを決める — 後から作った基準は、答えに合わせて曲がる。先に固定した基準だけが、答えを縛る側に回る。

ただし、渡すものを増やせばよいわけではない。検証の基準を渡すことと、その基準をどう確かめるかという手続きを書き込むことは別である。後者はコンテキストを消費し、消費した分だけ他の情報を押しのける代償を伴う（下記トレードオフ）。

トレードオフ

利点

検証の結果が、こちらの関心と対応する。 照合先を渡しているので、照合対象がこちらの意図とずれない。
満たさない項目が名指しで返る。 「動きません」ではなく「この項目を満たしていません」が返るため、直す対象が決まる。

代償

基準を書くのはこちらの仕事である。 書けないなら渡せない。そして「何が正しいか」を自分でも言葉にできないことは多い — その場合、本パターンは適用できない。
手続きの指示は、コンテキストを占める。 ここで注意深く扱うべき研究がある。30B のオープンウェイトモデルを consumer hardware 上で動かした条件で、TDD の手続き指示のみを与えるとレグレッションが 9.94% 増加したという報告がある（研究、arXiv:2603.17973）。論文はこれを、手続き指示が repo のコンテキストを押し出したためと説明している。この数値は当該条件に限定されており、AI エージェント一般の法則としては読まない。
この研究は本パターンへの反証ではない。論文が示しているのは、「どう進めるか」という手続きだけを渡し、「何を満たすべきか」という検証対象を渡さなかった場合に起きたことである。むしろ本パターンが立てる区別 — 検証の基準を渡すことと、その基準を確かめる手続きで埋め尽くすことは別である、という境界を裏付けている。「明示すればするほど良い」ではない。 手続きを長々と書くと、消費した分だけ本題が押し出されうる。明示にも家賃がかかる（→ 常駐物の棚卸し）。

GitHub Copilot での具体例

Copilot は単一の製品ではない。ここでは VS Code と Copilot CLI の2つの面を扱う。両者は同じプロパティ名で、同じ意味論を持つ。

VS Code — `applyTo` を検証契約として使う

出典: VS Code — カスタム命令（取得日: 2026-07-16）。命令ファイルの applyTo プロパティの定義は次のとおりである公式:

Glob pattern that defines which files the instructions apply to automatically, relative to the workspace root. Use ** to apply to all files. If not specified, the instructions are not applied automatically, but you can still add them manually to a chat request.
〔訳〕ワークスペースのルートを基準に、その命令がどのファイルに自動的に適用されるかを定義する glob パターンである。すべてのファイルに適用するには ** を使う。指定しない場合、命令は自動的には適用されないが、チャットのリクエストに手動で追加することはできる。

applyTo が宣言しているのは「どのファイルに効くか」という範囲であり、それ自体は命令の階層化と適用範囲の限定の主題である。ただし、その範囲の中身が「この作業で何を満たすべきか」という検証の基準であるとき、同じ機構は検証契約を配る道具になる。 機構は一つでも、渡す中身次第で別のパターンとして働く。

範囲の決まり方は glob だけではない公式:

The agent determines which instructions files to apply based on the file patterns specified in the applyTo property in the instructions file header or semantic matching of the instruction description to the current task.
〔訳〕エージェントは、命令ファイルのヘッダーにある applyTo プロパティで指定されたファイルパターン、または命令の説明文と現在のタスクとの意味的な一致に基づいて、どの命令ファイルを適用するかを決める。

範囲の入口は文字列一致（applyTo）だけでなく、説明文と作業内容の意味的な一致もある。検証契約を書くときも、glob で当てるか、説明文で当てるかの二通りが選べる。

Copilot CLI — 同じ意味論が、別の面にもある

出典: Copilot CLI — カスタム命令の追加（取得日: 2026-07-16）公式:

Path-specific instructions are included only when their applyTo value matches a file that Copilot CLI is working with. An instruction file that you disable using /instructions is not included.
〔訳〕パス指定の命令は、その applyTo の値が Copilot CLI が扱っているファイルに一致したときにのみ含まれる。/instructions を使って無効化した命令ファイルは含まれない。

applyTo がいま扱っているファイルに一致したときだけ契約が含まれる。VS Code と同じ意味論が別の面でも成立しており、本パターンが一つの製品の機能に閉じていないことがここで確認できる。

別名

呼称	出典
検証対象の明示	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い
コンテキスト契約	記述 — ⚠ 出典なし。リサーチ文書に現れる呼称であり、一次出典を辿れない

「コンテキスト契約」は、既存の確立した呼称であるかのように書かない。 この語を使う文書は他にもあるが、本カタログが確認できた範囲では、ベンダー・学術のどちらにも一次資料が無い。載せる理由は流通しているからであり、出典があるからではない。両方とも本カタログの記述的呼称として扱う。

検証対象の明示（Making the Verification Target Explicit） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

VS Code — applyTo を検証契約として使う ​

Copilot CLI — 同じ意味論が、別の面にもある ​

別名 ​

関連 ​