失敗の制度記憶化（Failure as Institutional Memory）

過去の事故を、抽象的な戒めではなく具体で残す。書く価値があるのはモデルが知りようのないこと — ここで実際に何が起きたか — だけであり、モデルが既にやることを書き足しても雑音が増えるだけである。

問題

エージェントはセッションを跨いで学習しない。先週踏んだ地雷を今週も踏む。人間の側には「前にも言った」という記憶があるが、モデルにとっては毎回が初回である。そこで命令ファイルに「注意深く確認すること」と書き足す。ところがこの種の記述は効かない — 公式が名指しで「雑音」と呼んでいる書き方だからである（具体例節）。結果、事故は繰り返され、命令ファイルだけが太り、太った分だけ他の命令が読み飛ばされる。

コンテキスト

適用する条件:

同じ失敗が二度起きた、または一度でも代償が大きかった
失敗に再現条件がある — この状況で、この操作をすると、こうなる、と書ける
モデルが知りようのない事実である — この環境固有の癖、過去にここで起きたことの実際の帰結

適用しないケース:

モデルの既定挙動を言い直すだけのとき。「テストが通るまで完了と主張するな」の類は、現行モデルが既定でやることであり、書いても限界効用は小さい（これは測定ではなく判断である — ある個人環境の監査の判定であり、公式の「add noise ... already optimized」と独立に一致している。いずれも具体例節）
一度きりで再現条件を特定できない失敗。条件の書けない記憶は、次に照合できない
コードやテストに居場所があるとき。パーサが踏む入力の癖は、命令ファイルではなくパーサのテストに書く。機械で止められる失敗を人間の言葉で書き残すのは、置き場所の誤りである

隣接パターンとの境界:

常駐物の棚卸し — 記憶を増やすのが本パターン、減らすのが同パターン。この2つは正面から緊張する。緊張を解くのが「モデルが知りえないことだけを書く」という本パターンの条件である
命令の階層化と適用範囲の限定 — その記憶をどこに効かせるかが同パターン、何を書くかが本パターン
ルールを拘束力で階層化する — 記憶にどの拘束力を与えるかが同パターン
機械ゲートと意味ゲートの分離 — 機械で止められる失敗はゲートにする。命令に書くのは、機械で判定できない失敗だけである
読み捨ての隔離 — 何をコンテキストから追い出すかが同パターン、何をコンテキストに残す価値があるかが本パターン。同じ問い（何が居座る価値を持つか）の両端である

解決

なぜ効くのか。モデルは一般論を既に持っている。 「検算せよ」「見落とすな」「気をつけろ」は、訓練の時点で無数に読んでいる。それを命令ファイルに書き足しても、モデルの手持ちに何も足さない。足さないものに毎ターンの家賃だけが発生する。

モデルが持っていないのはここで実際に何が起きたかである。この環境の、この手順の、この条件で、何が壊れ、いくら損したか。これは訓練データのどこにも無く、原理的に外から与えるしかない。だから制度記憶の価値は次の差で決まる:

書く価値＝事故の中身 − モデルが既に持っている一般論

「注意深く確認すること」は差がゼロである。事故から一般論だけを抽出して書いているからだ。事故を抽象化した瞬間、書く価値は消える。 制度記憶化とは、抽象化に抗って具体を残す作業である。ここが直感に反する — 我々は普通、教訓を一般化して覚えようとする。

具体で書くと短くなることにも注意したい。抽象的な戒めは適用範囲が無限なので、いくらでも書ける。具体的な前例は一つの条件しか指さないので、一行で終わる。長さと効き目は、ここでは逆に相関する。

残す形は三つ組にする — 症状（何が起きたか）、条件（どうすると再現するか）、帰結（実際にどうなったか）。条件が書けない記憶は、次に照合できないので残さない。帰結が書けない記憶は、重みが分からないので優先順位を付けられない。

三つ組にはもう一つ効用がある。条件が消えたときに削れる。 抽象的な戒めは、いつ不要になったのか誰にも判断できないので永久に残る。具体的な前例は、その手順が無くなれば一緒に捨てられる。制度記憶を具体で書くことは、後から棚卸しできる形で書くことでもある（「常駐物の棚卸し」）。

トレードオフ

利点

抽象的な戒めより短い。 ある個人リポジトリでは、検証チェックリストの各項目に過去の事故が実額つきで紐づけてあり、そのバイト数は「注意深く検算せよ」という抽象的な指示の数分の一だった（実測、具体例節）。短さは実測できるが、「よく効く」は実測していない — 効き目の根拠は公式の側にある（specificity matters / add noise、具体例節）。
後から棚卸しできる。 再現条件が明示されているため、その条件が消滅したときに削除を判断できる。抽象的な戒めは削除の判断ができず、永久に家賃を払い続ける。

代償

常駐物が増える。 記憶は書いた瞬間から毎ターンの家賃を発生させる。公式は「命令ファイルが長すぎると一部の命令が見落とされうる」と明記しており（具体例節）、記憶を足すことは他の命令を薄めることでもある。本パターンは「常駐物の棚卸し」と正面から緊張し、その緊張は消えない。
記憶は保証ではない。 公式は命令の遵守が非決定的であることを明記している（具体例節）。書いたから二度と起きない、とは言えない。決定的に止めたい失敗は、命令ではなく機械のゲートにする（「機械ゲートと意味ゲートの分離」）。

GitHub Copilot での具体例

github.com — code review のカスタム命令

この節の公式引用が語る範囲

以下の原文はすべて Copilot code review のカスタム命令についての記述である。命令ファイル一般の目安として引かない。 数値も助言も、原文が名指ししている対象の外へ広げないこと。

出典: Using custom instructions to unlock the power of Copilot code review（取得日: 2026-07-16、全文確認）。

公式は「書いてはいけない命令」を節として立てており、その最後の類型が本パターンの核心に当たる公式:

Vague quality improvements:
Be more accurate
Don't miss any issues
Be consistent in your feedback
These types of instructions add noise without improving Copilot's effectiveness, as it's already optimized to provide accurate, consistent reviews.
〔訳〕曖昧な品質改善の例として Be more accurate（もっと正確であれ）、Don't miss any issues（問題を見逃すな）、Be consistent in your feedback（フィードバックに一貫性を持たせよ）を挙げ、この種の指示は Copilot の効果を高めることなく雑音を足すだけである、なぜなら Copilot は既に正確で一貫したレビューを提供するよう最適化されているからだ、と述べている。

「正確であれ」「見落とすな」「一貫していろ」は、効果を上げずに雑音を足す（add noise without improving） と明言されている。理由も書かれている — already optimized、すなわちモデルが既にやっていることだからである。「解決」で述べた「差がゼロなら書く価値もゼロ」が、公式の言葉で確認できる数少ない箇所である。

同ページは逆側も書いている公式:

Non-deterministic behavior: Copilot may not follow every instruction perfectly every time.
Context limits: Very long instruction files may result in some instructions being overlooked.
Specificity matters: Clear, specific instructions work better than vague directives.
〔訳〕非決定的な挙動: Copilot は毎回すべての指示に完全に従うとは限らない。文脈の制限: 非常に長い指示ファイルでは一部の指示が見落とされることがある。具体性が重要: 明確で具体的な指示は曖昧な指示より効果的である。

三つとも本パターンのトレードオフに直結する。具体が効く（specificity matters）が、書けば書くほど見落とされ（context limits）、しかも守られる保証はない（non-deterministic）。

粒度と上限も示されている公式:

Begin with 10–20 specific instructions that address your most common review needs, then test whether these are influencing Copilot code review in the way you intended.
〔訳〕最も多いレビューニーズに対応する10〜20個の具体的な指示から始め、それらが意図したとおりに Copilot code review に影響しているかをテストせよ。

Best practice: Limit any single instruction file to a maximum of about 1,000 lines. Beyond this, the quality of responses may deteriorate.
〔訳〕ベストプラクティス: 単一の指示ファイルは最大約1,000行までに制限すること。これを超えると、応答の品質が劣化する場合がある。

同ページの Troubleshooting は、命令が無視されるときの原因の筆頭に「Instruction file is too long (over 1,000 lines)」〔訳: 指示ファイルが長すぎる(1,000行超)〕を挙げている。記憶を足し続けた先に何が起きるかを、公式が原因として名指ししているに等しい。

実運用での観測

ある個人リポジトリ（2026-07-07 時点の監査、Claude Code 環境、n=1）で、本パターンが独立に実装されているのが観測された。一般法則としては書かない。 以下、観測できたことと、そこから引かれた判断を分けて示す。

観測できたこと実測

検証チェックリストの各項目に、過去の事故が実額つきで紐づけてある（事故の金額・対象は資産情報のため本カタログには持ち込まない）
その記述のバイト数は、「注意深く検算せよ」という抽象的な指示の数分の一である
修正コミットは 2行の修正に44行の回帰テストを同梱していた。同リポジトリの修正コミット率は 3.3%、revert は 0 件

観測ではないこと（監査者の判断であり、実測ではない）

同監査はこの設計を「遥かに高い再発防止効果を持つ」と結論している。しかし反実仮想は回っていない — 抽象的な戒めで運用した場合の再発率を、誰も数えていない。効き目の根拠は実測ではなく、公式（specificity matters / add noise）の側にある
同監査はルールの model-babysitting 傾向も指摘し、「テストが通るまで完了と主張するな」の類は現行モデルの既定挙動であるため限界効用は小さいと判定した。これも測定ではなく判断である。ただし公式の「add noise ... already optimized」と、独立した個人環境の監査が同じ結論に達していることには意味がある — 根拠の重みは、一致それ自体から来る

この分け方が規約そのものである

バイト数と修正コミット率は、反実仮想を回さずに見える。「再発防止効果が高い」は、抽象版を運用して数えない限り見えない。前者は実測、後者は判断である。両方を同じラベルの下に置くと、読者は重みを判断できなくなり、実測は「観測」ではなく「筆者がそう思う」の別名に堕ちる。実測が覆えるのは、反実仮想を回さずに見えることだけである。

他ツールでの対応物

置き場所は道具によって変わるが、構造は変わらない。Copilot なら .github/copilot-instructions.md や *.instructions.md（上記出典）、Claude Code なら CLAUDE.md である。

いずれも機構の名前であって、本パターン（何を書くか）の名前ではない。 機構は「置ける場所」を与えるだけで、何を置くべきかは決めてくれない。

別名

呼称	出典
Custom instructions / 命令ファイル	一次 — ただしこれは機構の呼称であり、本パターンの呼称ではない（出典は具体例節）
失敗の制度記憶化 / Failure as Institutional Memory	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

公式が名前を与えているのは入れ物（custom instructions、CLAUDE.md）までである。「その入れ物に、過去の事故を具体で書く」という実践には、確認できた範囲で確立した呼称が無い。入れ物の名前を実践の名前として使うと、「命令ファイルを持っている＝この実践をしている」という誤解になる。実際には、同じ入れ物に抽象的な戒めを詰めることもでき、公式はそれを雑音と呼んでいる。入れ物と中身は別の問題であるため、中身の側に名前を与えた。

失敗の制度記憶化（Failure as Institutional Memory） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

github.com — code review のカスタム命令 ​

実運用での観測 ​

他ツールでの対応物 ​

別名 ​

関連 ​