語より先に指示対象を決める（Referent Before Label）

対象が定まっていなくても、もっともらしい語を置けば文章は続く。だから語を置く前に、それが何を指し、どんな役割なのかを埋めさせる。名前は最後に与える。⚠ この順序を求める記述は、確認した範囲ではどの一次資料にも無い — 両ベンダーが曖昧さについて述べているのは、いずれも人が書く文についてである。

問題

調査レポートに「圧縮時点」という見出しがあるとする。本文を読むと、その語は三つのあいだを行き来している — 会話履歴が設定量に達したこと、要約を始める閾値、実際に要約が始まる瞬間。開始条件と、値と、事象である。

文章は壊れていない。流暢で、技術的な説明らしく読める。しかし一つの語がこの三つを兼ねた時点で、その節が何について書かれているのかは決まらなくなっている。

厄介なのは、壊れ方が見えないことである。誤った数字なら検算で捕まる。誤ったコードなら実行で落ちる。誤った語は、読める文章のまま下流へ流れる。そして次の段が「圧縮時点を早める」と書き、その次の段が「圧縮時点を監視する」と書く。早めるのは閾値であり、監視するのは事象である — 二つの別々のものが、一つの語で結ばれたまま設計になる。

指摘しても直りにくい。曖昧だと告げられたエージェントは、まず説明を足す。次に見出しの表現を変える。開始条件と事象を取り違えているという指摘には、そこから容易には辿り着かない。足りないのは説明ではなく、語が何を指しているかの確定である。

根にあるのは、生成の性質である。空白を空白のまま保つことは、生成にとって自然な動作ではない。 対象も目的もまだ定まっていない箇所でも、それらしい語を一つ置けば、文はそこから先へ続けられる。続けられてしまうことが問題なのであって、続ける能力が低いことが問題なのではない。

コンテキスト

適用する条件:

• 設計・調査・原因の切り分け・対策案を書かせる — 一つの語が後続の段の前提になる形の仕事
• 名前を付けさせる — 状態名・条件名・事象名・値や記録の型名。命名は、指示対象の確定が済んでいることを前提にしている
• 人が与えた手順を、短いラベルへ要約させる — 「試験を行い、結果から原因箇所を切り分け、その後に対策を選ぶ」を「観測を一つに集める」と要約されると、順序そのものが消える。しかも要約はそれらしく読めるため、消えたことに気づかれない

適用しないケース:

• 原文をそのまま引くとき。 引用は指示対象の確定を要さない
• 単純な機械的な編集・既存の名前の再利用・定型の出力。 新しい語を導入しないなら、この規律は空回りする
• 確立した用語だけで書ける短文。 導入する語が無い場所に、語の規律は効かない

⚠ 適用範囲を広く取りすぎると、規律そのものが薄まる。 命令ファイルに書く分量は有限であり、常に効かせようとすると、本当に効かせたい場面で埋もれる。この緊張は命令の階層化と適用範囲の限定が扱う。

隣接パターンとの境界:

• 計画の先制検証 — どちらも本文の前に別のものを出させる。 同パターンが先に出させるのは何をするか（手順の計画）、本パターンが先に出させるのは何を指すか（語と対象の対応）である。計画が正しくても、そこに使われた語が二重の意味を持っていれば、計画は二通りに読める
• 出力の契約を明示する — 同パターンが契約するのは出力の形（分量・構造・述べ方）であり、本パターンが固定するのは語の指す先である。形が決まっていても、語が定まっていなければ中身は定まらない
• 失敗の制度記憶化 — 同パターンは過去の失敗を具体で書き残す。⚠ 本パターンが扱う失敗には、その型が効きにくい — 誤った語は毎回新しく生まれるため、書き残す対象が確定しない。ただしこれは本カタログの判断であり、一次資料の裏付けは無い（下記）
• 検証対象の明示 — 同パターンは何を検証させるかを契約にする。本パターンはその手前 — 検証させたい対象が、そもそも一つに定まっているかを問う
• 由来を分けて記録する — 同パターンは一つの記録の中で観測・主張・推論・判断を分けて書く。本パターンは一つの語が複数の役割を兼ねることを分ける。分ける対象が、記録の単位か語の単位かの違いである

解決

生成の順序を入れ替える。 語を置いてから説明を合わせるのではなく、指す対象と役割を埋めてから名前を与えさせる。

なぜ効くのか。三段で説明する。

第一に、埋められない欄が残る。「この語は何を指すか」を具体で書けと言われて書けないなら、それは対象がまだ定まっていないということである。語を先に置く順序では、この事実は表に出ない — もっともらしい語を置いた時点で、空白は埋まったように見えてしまうからだ。順序を変えることは、空白を空白のまま可視化することである。

第二に、役割を一つに絞る問いが、二重性を露わにする。「これは条件か、状態か、事象か、値か、記録か、目的か、手段か」と問われたとき、二つ以上に当てはまるなら、扱っている対象は二つある。一語で済ませたいという圧力より先に、その事実が見える。 露わになれば行を分けられる。分ければ、下流の段は二つを別々に扱える。

⚠ この分類そのものを規範として示すことは、本カタログはしない。 どの役割の集合が正しいかを判定できる一次資料を持っていないためである（後述）。効いているのは分類の内容ではなく、「一つに絞れるか」と問う形のほうである。

第三に、名前が最後に来ることが、書式上の強制になる。もし名前の欄を先頭に置けば、そこへ語を書き、後から辻褄の合う説明を足すことができてしまう。それは止めたい生成順を、表の中で再現するだけである。名前の欄を最後に置くことは、順序を助言ではなく形にすることである。 完成したら名前の列を隠してみて、対象の記述だけで意味が通るかを確かめる — 通らないなら、意味を担っていたのは名前のほうであり、対象はまだ書けていない。

そして、定義を書けない語は導入しない。指す対象を具体で書けないなら、その語を作らず、対象の記述をそのまま本文で使う。長くなるが、二通りに読める一語よりは短く済む。

この規律が、なぜ「誤った語の一覧」では代替できないのか

一度ずれた語を記録し、次から使わせない、という手はある。実際それは失敗の制度記憶化の型そのものである。

しかし止めたいのは「以前に間違えた語をもう一度使うこと」ではない。 止めたいのは、対象が曖昧なまま語を先に置き、その語で思考を進めることである。前者は列挙できるが、後者は列挙できない — 次に生まれる語は、まだ存在しないからである。だから照合先は、外部に持ち越した禁止語の一覧ではなく、その文書自身が宣言した対応になる。

⚠ これは本カタログの判断であって、公式 ではない。 それどころか、確認した範囲の一次資料は逆を向いている — 避けたいものを具体で列挙して示せ、という推奨が両ベンダーにあり、避けるべき語・廃止された語の一覧を設計に組み込んだ公式のツールキットも存在する（出典は具体例節）。本カタログはこの相違を隠さない。 列挙が無駄だと述べているのではなく、列挙だけでは新しく生まれる語に届かないと述べている。

一次資料に無いことを、先に書いておく

本パターンの中核 — エージェントの生成物の語彙に規律を課すこと、および名前を最後に与えること — に対応する記述は、確認した範囲の一次資料に無い。

両ベンダーはいずれも「曖昧な語を避けよ」と述べている。しかしその射程は人が書く文である — 利用者がチャットに書く指示語、人が書くツールの定義文、人が書く手順書の記述文。モデルが生成した語彙を、生成の途中で止めて確定させよ、という記述は無い（不在確認。検索語と範囲は具体例節）。

したがってこのページは、根拠を「一次資料がそう言っている」に置いていない。 置いているのは、両ベンダーが人の文について同じ処方を出しているという事実と、その処方が向けられている先が生成物側では空いているという事実の二つである。空いている場所に何を置くかは、本カタログの提案であって、公式の推奨ではない。

トレードオフ

利点

• 空白が空白のまま見える。 埋められない欄は、対象が定まっていないことの表示になる。語を先に置く順序では、この情報は失われる
• 二重性が早期に出る。 一つの語が二つの役割を持つことが、下流の段で矛盾として現れる前に、表の上で行の分裂として現れる
• やり直しが安く済む。 語が定まる前の段でやり直すほうが、その語を前提に組み上がった設計をほどくより短い

代償

• 遠回りである。 本文へ入るまでに一段増える。確立した用語だけで書ける短い仕事では、増えた一段がそのまま損になる
• 命令が長くなる。 この規律を常駐の命令に書けば、そのぶん他の規則が埋もれる方向に働く。実際に一次資料は命令ファイルを短く保てと述べている（具体例節）。適用範囲を絞ることと対で運用する必要がある
• 形式が守られたことと、対象が定まったことは別である。 表の欄はすべて埋まっているのに、指示対象の記述自体が曖昧、ということは起こりうる。埋まっているかは形で見えるが、定まっているかは読まないと分からない — これは機械ゲートと意味ゲートの分離が言う、機械が形を、人が正しさを見るという分担そのものである

GitHub Copilot での具体例

このパターンに対応する専用の機能は、どの面（VS Code / github.com / Copilot CLI / cloud agent）にも無い。 道具が与えるのは、規律を書いて常駐させる場所（命令ファイル）と、手順を切り出して置く場所までであり、その規律の内容は運用の側にある。以下では、両ベンダーの一次資料が曖昧さについて何を述べているか、そしてそれがどこへ向けられているかを突き合わせる。

両ベンダーが述べているのは「人が書く文」についてである

GitHub 側は、利用者がチャットに書く指示語を対象にしている（出典: Prompt engineering for GitHub Copilot Chat、取得日: 2026-07-29。面: VS Code / github.com）公式:

Avoid ambiguous terms. For example, don’t ask "what does this do" if "this" could be the current file, the last Copilot response, or a specific code block.

〔訳〕曖昧な語を避けること。例えば「これは何をするのか」と尋ねてはならない。その「これ」は、現在のファイルかもしれず、直前の Copilot の応答かもしれず、特定のコードブロックかもしれないからである。

指示語が三つの候補のあいだで定まらないという指摘の構造は、冒頭の「圧縮時点」と同じである。ただし主語が違う — ここで曖昧な語を置いているのは人であり、直すのも人である。原文が続けて勧めるのは、既存の関数名を挙げて具体的に尋ねることであって、名前を後回しにすることではない。

Anthropic 側は、人がツールの定義文を書くときを対象にしている（出典: Writing tools for agents、取得日: 2026-07-29）公式:

Consider the context that you might implicitly bring—specialized query formats, definitions of niche terminology, relationships between underlying resources—and make it explicit. Avoid ambiguity by clearly describing (and enforcing with strict data models) expected inputs and outputs.

〔訳〕自分が暗黙に持ち込んでいる文脈 — 専用のクエリ形式、ニッチな用語の定義、背後にあるリソース同士の関係 — を洗い出し、それを明示すること。期待する入力と出力を明確に記述し（かつ厳格なデータモデルで強制し）、曖昧さを避けること。

「ニッチな用語の定義」を明示せよという一句は本パターンに近い。しかし原文はこの直後、入力パラメータの命名の話へ進む — 曖昧な名前ではなく、指す対象が分かる名前を付けよ、という向きである。名前を精緻にせよであって、名前を後回しにせよではない。

同じベンダーの、再利用可能な手順を書くときの規約も、対象は人が書く記述文である（出典: Agent Skills best practices、取得日: 2026-07-29）公式:

Choose one term and use it throughout the Skill:

〔訳〕一つの語を選び、そのスキル全体でそれを使い通すこと。

⚠ 求められているのは一貫性であって、定義の明示ではない。 そして照合の対象は、人が書いた記述文である。「宣言した定義にモデルの出力を照合させる」機構ではない。 近い語が並んでいるからといって、同じことを言っていることにはならない。

用語の確定を、設計より前の工程に置いた実例

GitHub が自社のブログで公開した仕様駆動のツールキットには、曖昧性を走査する観点の一つとして用語が置かれている（出典: github/spec-kit の明確化テンプレート、取得日: 2026-07-29。面: VS Code / Copilot CLI）公式:

Terminology consistency: same canonical term used across all updated sections.

〔訳〕用語の一貫性 — 更新したすべての節で、同一の正準語が使われていること。

同じファイルは、この明確化の工程を、設計の起動より前に完了させることを求めている（逐語は引かない — 当該文には配布時に置換されるプレースホルダが含まれており、利用者の手元のファイルとは表記が異なるためである）。用語の確定を独立した前工程に置く実例が、公式の側にあるという点で、これは本パターンに最も近い一次資料である。

⚠ ただし三つの点で射程が違う。 第一に、これは製品のドキュメントではなく、公開されたツールキットのテンプレートである。第二に、独立した成果物になるのは仕様の全体であり、用語はその中の一観点として仕様へ書き戻される。 第三に、この工程が行うのは正準語への寄せ — 同義語の乱立を一つの語に統一することであり、名前を後回しにすることではない。 向きはむしろ逆で、名前を先に決めて固定する操作である。

さらに同じファイルは、回避すべき語・廃止された語の列挙を走査の観点に含んでいる。「解決」で述べた「誤った語の一覧では代替できない」は、この公式の設計とは逆を向く本カタログの判断である。 隠さずに併記する。

確認できなかったこと

2026-07-29 に、素材を取得したのとは別のサブエージェント2体が、GitHub / Microsoft 側30件・Anthropic 側31件の一次資料を生本文で取得して確認した（GitHub 側: docs.github.com の Copilot 関連12件、code.visualstudio.com 6件、github.blog 2件、公開ツールキットの生ファイル6件。Anthropic 側: プロンプト設計の統合ページ、Agent Skills のベストプラクティスと概要、ツール利用、Claude Code のベストプラクティス・メモリ・スキル・サブエージェント・一般的なワークフロー、エンジニアリングブログ5件ほか）。

探したもの	検索語	結果
エージェントが生成した語彙に規律を課す記述	terminolog / glossar / vocabular / nomenclature / synonym / ambigu / precise	0件（vocabular / nomenclature / synonym は Anthropic 側の全資料で0件）
名前を最後に与える順序制御	before writing / plan before / outline / structured output before	0件
役割の閉じた分類（条件・状態・事象・値・記録・目的・手段）	上記に同じ	0件
誤用語の一覧が機能しないこと	forbidden / banned / blocklist / denylist / prohibited / word list	0件。⚠ 逆向きの推奨は実在する（上記のツールキット、および避けたいパターンを具体例で示せという VS Code 側の推奨）
用語の対応表を本文と別の成果物として先に保存させること／生成順の証明	plan to a file / before coding / proof of order / generation order	0件。仕様の全体を先に別ファイルにする記述は両側にあるが、それは計画の先制検証の射程である

不在確認 である。「無い」であって「否定されている」ではない（最後の行だけは事情が違い、逆向きの記述が実在する）。

規律を書く場所と、その代償

この規律を常駐の命令に書けば、命令ファイルはそのぶん長くなる。一次資料は、その方向に対してはっきりと逆の圧力をかけている（出典: Claude Code のベストプラクティス、取得日: 2026-07-29）公式:

Keep it concise. For each line, ask: "Would removing this cause Claude to make mistakes?" If not, cut it. Bloated CLAUDE.md files cause Claude to ignore your actual instructions!

〔訳〕簡潔に保つこと。各行について「これを削ったら Claude は間違えるようになるか」と問い、ならないなら削ること。肥大した CLAUDE.md は、Claude に本来の指示を無視させる原因になる。

したがって「常に適用せよ」とは書かないほうがよい。 適用しない範囲を先に決めることが、この規律を生かす条件になる。範囲の切り方は命令の階層化と適用範囲の限定が扱う。

別名

呼称	出典
語より先に指示対象を決める / Referent Before Label	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

素材となった実践には作者が付けた手法名があるが、手法名をパターン名に使わない。 手法の名はその実装の名であり、型の名ではない。同じ理由で改訂を測って採るも素材の手法名を採らなかった。

⚠ 近い呼称として「用語の一貫性」を挙げることはできるが、等号で結ばない。 一貫性が求めているのは同じものを同じ語で呼ぶことであり、本パターンが求めているのはその語が何を指すかを先に決めることである。一貫していても、一貫して曖昧であることはありうる。

関連

• 計画の先制検証 — どちらも本文の前に別のものを出させる型である。 同パターンは何をするかを、本パターンは何を指すかを先に確定させる。計画の語が二重の意味を持てば、計画そのものが二通りに読める
• 出力の契約を明示する — 形を決める側と、語を決める側。形が決まっていても、語が定まっていなければ中身は定まらない
• 失敗の制度記憶化 — 本パターンが扱う失敗には、その型が効きにくい。 誤った語は毎回新しく生まれるため、書き残す対象が確定しないからである。⚠ ただしこれは本カタログの判断であり、一次資料は逆向きの推奨を持つ（具体例節）
• 検証対象の明示 — 本パターンはその手前にある。何を検証させるかを契約にする前に、その「何」が一つに定まっている必要がある
• 由来を分けて記録する — 分ける対象が、記録の単位か語の単位かの違いである。どちらも「一つにまとめられたものを、まとめる前に戻す」型である
• 機械ゲートと意味ゲートの分離 — 欄が埋まっているかは機械が見られるが、指示対象が定まっているかは読まないと分からない。本パターンの形式は機械ゲートに載るが、中身は載らない
• 命令の階層化と適用範囲の限定 — この規律をどこに書き、どこに効かせるか。常に効かせようとすると、規律そのものが埋もれる
• まず次に読むなら 計画の先制検証 — 語が定まったら、次はその語で書かれた計画を人が読む番である