機械ゲートと意味ゲートの分離（Separating Mechanical Gates from Semantic Gates）

検証を、決定的に判定できるもの（機械ゲート）と、意味の判断が要るもの（意味ゲート）に分けて置く。機械に判定できることを、モデルの自己申告やレビューの目視に任せない。そして「命令に書く」は、どちらのゲートでもない。

問題

モデルが「直した」と言うが、直っていない。原因はたいてい嘘ではなく、確かめていないことである。そこで人間は命令ファイルに「テストを通してから完了と言え」と書き足す。ところが命令はコンテキストであって強制される設定ではなく（公式、出典は具体例節）、遵守は非決定的である（公式、限定と出典は具体例節）。確実に止めたいことが、確実でない手段に載っている。 逆も起きる — lint が一瞬で判定できる形式の崩れを、モデルやレビューの目視に任せ、見落とす。

コンテキスト

適用する条件:

「守られているはず」の制約がある — 命令・規約・口頭の合意など、言葉だけで運用されている
CI・テスト・lint・スキャナのような機械の検査を持っている、または書ける
モデルの自己申告を信じるしかない状態になっている — 「確認しました」を確認する手段が無い

適用しないケース:

機械で判定できないものを、無理に機械化しようとするとき。 「読みやすいか」「設計が妥当か」は機械ゲートに載らない。載せようとすると、判定できる代理指標（行数、カバレッジ率）で品質を測ることになり、指標だけが緑になる

隣接パターンとの境界:

失敗の制度記憶化 — 機械で止められる失敗はゲートにする。命令に書くのは、機械で判定できない失敗だけである。同パターンが記憶に残す側から書いているこの境界を、本パターンはゲートに載せる側から書く
ルールを拘束力で階層化する — 同パターンの限界が本パターンの入口である。拘束力は言葉であり、言葉は非決定的にしか効かない
検証対象の明示 — 本パターンは「どの種類のゲートに載せるか」、同パターンは「何を検証させるか」
無人経路にこそ強いゲート — 同パターンは「どの経路に」ゲートを厚くするか、本パターンは「どの種類の」ゲートに載せるか

解決

検証には2つの種類があり、性質が違う:

	機械ゲート	意味ゲート
判定	決定的 — 同じ入力なら同じ答え	非決定的
判定できるもの	形式・存在・一致・既知パターン	妥当性・意図・設計・読みやすさ
例	テスト、lint、型検査、スキャナ	レビュー、批評
失敗の仕方	判定できることしか判定しない	判定を見落とす

なぜ分離が効くのか。ゲートの価値は決定性にある。 機械ゲートは、通らなければ通らない。誰が何度流しても同じ所で止まる。意味ゲートは、機械に判定できない妥当性を見られる代わりに、見落とすことがある。この差は程度ではなく種類である — 機械ゲートの「通った」は事実の主張であり、意味ゲートの「問題なし」は一つの意見である。

失敗の仕方も対になっている。機械ゲートは判定できることしか判定しない — テストが緑でも設計は壊れうる。意味ゲートは判定を見落とす — 目視は形式の崩れを拾いきれない。この2つは互いを補えるが、互いを代替できない。 混ぜると両方の弱点だけが残る: 意味ゲートに形式の判定を任せれば見落とし、機械ゲートに妥当性の判定を任せれば、無意味な指標が緑になる。

そして最も多い事故は、第3の場所に載せることである。「気をつけろ」「必ず確認しろ」と命令ファイルに書くのは、どちらのゲートでもない。命令はコンテキストであって強制ではなく（公式、出典は具体例節）、遵守は非決定的である（公式、限定と出典は具体例節）。書いた本人はゲートを置いたつもりでいるが、何も置かれていない。 命令に書く価値があるのは、機械で判定できない、この環境固有の失敗の記憶だけである（「失敗の制度記憶化」）— そしてそれも保証ではない。

トレードオフ

利点

決定的に止めたいものが、実際に止まる。 命令と違い、機械ゲートの「通らない」は読み飛ばされることも、うっかり守り忘れられることもない。
意味ゲートが、意味の判定に集中できる。 形式・既知パターンは機械が先に落としているので、レビューの注意力が設計と意図に使われる。

代償

機械ゲートには初期費用がある。 テスト・lint・スキャナは書けば資産になるが、書くまではタダではない。一度きりの制約をゲート化すると、費用だけ払って回収できない。
緑が品質の証明として読まれやすい。 機械ゲートは判定できることしか判定しないのに、「全部緑」は全部確かめたかのように見える。緑を合格の証明と読んで意味ゲートを省略する運用は、本パターンの分離を逆側から壊す。

GitHub Copilot での具体例

Copilot は単一の製品ではない。ここでは cloud agent と github.com（Copilot code review）の面を扱い、比較として Claude Code を置く。

cloud agent — 同じ経路に、2種類のゲートが並べて置かれている

出典: Copilot cloud agent のリスクと緩和策（取得日: 2026-07-16）。cloud agent が生成したコードには、既定で機械の検査が走る公式:

CodeQL is used to identify code security issues.
Newly introduced dependencies are checked against the GitHub Advisory Database for malware advisories, and for any CVSS-rated High or Critical vulnerabilities.
Secret scanning is used to detect sensitive information such as API keys, tokens, and other secrets.
〔訳〕CodeQL を使ってコードのセキュリティ上の問題を特定する。新たに導入された依存関係は、マルウェアの勧告や CVSS で High・Critical と評価された脆弱性がないか GitHub Advisory Database と照合される。secret scanning を使って API キーやトークンなどの機密情報を検出する。

3つとも機械ゲートである — 既知パターンとの照合（CodeQL）、データベースとの突き合わせ（Advisory Database）、形式の検出（secret scanning）。いずれも「決定的に判定できるか？」に「はい」で答えられる種類の検査である。

同じページが、続けて別の種類のゲートを書いている公式:

By default, Copilot cloud agent checks code it generates for security issues and gets a second opinion on its code with Copilot code review.
〔訳〕既定では、Copilot cloud agent は生成したコードにセキュリティ上の問題がないか確認し、Copilot code review によってそのコードについて第二の意見(second opinion)を得る。

Copilot code review は「second opinion」— 第二の意見と呼ばれている。機械ゲートの結果は意見とは呼ばれない。通ったか、通らなかったかである。同じ製品が、同じ経路に、2種類のゲートを並べて置き、片方を検査として、もう片方を意見として書き分けている。 本パターンの分離が、製品の既定に埋め込まれている実例である。

github.com — code review カスタム命令（命令の遵守は非決定的）

この引用が語る範囲

以下の原文は Copilot code review のカスタム命令についての記述である。命令ファイル一般へ広げない。

出典: Using custom instructions to unlock the power of Copilot code review（取得日: 2026-07-16）公式:

Non-deterministic behavior: Copilot may not follow every instruction perfectly every time.
〔訳〕非決定的な挙動: Copilot は毎回すべての指示に完全に従うとは限らない。

すべての命令が毎回完全に守られるわけではない。「テストを通してから完了と言え」と命令に書くことと、テストを CI のゲートに置くことの差がここにある。前者は守られないことがあり、後者は通らなければ通らない。

他ツールでの対応物 — Claude Code

命令が強制でないのは Copilot の癖ではない。Claude Code は自分の命令ファイル（CLAUDE.md）についてこう書いている（出典: code.claude.com/docs/en/memory、取得日: 2026-07-16）公式:

Because they're context rather than enforced configuration, how you write instructions affects how reliably Claude follows them. Specific, concise, well-structured instructions work best.
〔訳〕強制される設定ではなくコンテキストであるからこそ、命令の書き方が Claude がどれだけ確実に従うかを左右する。具体的で簡潔かつ構造化された命令が最もよく効く。

命令はコンテキストであって、強制される設定ではない（context rather than enforced configuration）。だから書き方が遵守の度合いを左右する — 強制なら書き方は関係ないはずである。二つのベンダーが、それぞれ自分の製品について同じ性質を書いている。命令で止まらないものは、命令の外 — 機械ゲート — で止めるしかないという本パターンの前提は、この2つの公式に立っている。

別名

呼称	出典
機械ゲートと意味ゲートの分離 / Separating Mechanical Gates from Semantic Gates	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

個々のゲートには確立した名前がある — CodeQL、secret scanning、Copilot code review（いずれも出典は具体例節）。名前が無いのは、検証をどちらの種類のゲートに載せるかを判断するという分離の作法のほうである。道具は両方の種類のゲートを提供するが、どちらに何を載せるべきかは言わない。判断の側に名前を与えた。

機械ゲートと意味ゲートの分離（Separating Mechanical Gates from Semantic Gates） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

cloud agent — 同じ経路に、2種類のゲートが並べて置かれている ​

github.com — code review カスタム命令（命令の遵守は非決定的） ​

他ツールでの対応物 — Claude Code ​

別名 ​

関連 ​