記録した判断を後から監査させる（Auditing Past Decisions）

判断の記録は、書いた時点の前提に依存している。前提が崩れても、記録の側からは何も言ってこない。 人間はその見直しを自発的には行わない — 読み直しは退屈で、分量が多く、そして自分の過去の判断は擁護したくなるからである。

問題

まともに運用されている場所には、判断の記録がある。設計文書、決定の記録、issue の議論、命令ファイルに書いた規約。どれも書かれた時点では正しい。問題は、正しさが前提にぶら下がっていることである。

「この API は月間1万リクエストなので同期処理でよい」と書く。半年後、リクエストは30万になっている。記録は何も言わない。記録は自分が古くなったことを知らない。 気づくのは、たいてい壊れたときである。

見直せばよい、というのは正しいが実行されない。理由は3つあり、どれも意志の問題ではない。

1. 分量が多い。 半年分の決定と、半年分の新しい入力を突き合わせる作業は、人間には単純に長すぎる
2. 退屈である。 突き合わせの大半は「変化なし」で終わる。当たりの薄い作業を人は続けられない
3. 自分の判断は擁護したくなる。 書いた本人が読み直すと、崩れた前提より「まだ有効な理由」のほうが目に入る

エージェントは、この3つのどれにも当たらない。分量を厭わず、退屈を感じず、そして過去の判断が自分のものであるという感覚を持たない。

コンテキスト

適用する条件:

• 判断が記録として残っている — 記録が無ければ監査する対象が無い。まず「由来を分けて記録する」が要る
• 判断が依存している前提が、記録に書いてある — 「なぜそう決めたか」が無い記録は、崩れたかどうかを判定できない。結論だけの記録は監査できない
• その後の変化が、同じ場所から読める — 作業ログ・コミット・issue など、突き合わせる相手が手の届く範囲にあること
• 判断の寿命が長い — 一週間で作り直すものに監査は要らない

適用しないケース:

• 記録が結論だけのとき。 「同期処理を採用」しか書いていなければ、何が崩れたかは判定不能である。監査を入れる前に、記録の書き方を直すほうが先である
• 機械で検出できる陳腐化。 依存ライブラリの古さ・リンク切れ・スキーマ違反は、監査ではなくゲートで検出する（「機械ゲートと意味ゲートの分離」）
• 判断が可逆で安いとき。 すぐ戻せる決定は、監査の費用のほうが高くつく

隣接パターンとの境界:

• 失敗の制度記憶化 — 記録に書くのが同パターン、書いたものを後から読み直させるのが本パターンで、時間軸が逆を向いている。なお同パターンは「モデルが変われば記憶は陳腐化する」を 公式 で扱うが、あれは命令の陳腐化であり、本パターンは判断記録の陳腐化である
• 計画の先制検証 — これから行うことを事前に検証するのが同パターン。本パターンはすでに下した判断を事後に検証する
• 由来を分けて記録する — 本パターンの前提条件である。由来が混ざった記録を監査させると、「未検証の推論」と「崩れた前提」の区別がつかない
• 成果物の差分レビューと段階的採用 — エージェントの出力を人間がどう受け取るか。本パターンの出力もまた、そのまま採用してはならない指摘の一覧である

解決

やることは3つで、どれも外せない。

1. 読ませる対象を、判断側と変化側の両方から指定する。 判断記録だけを読ませても、崩れたかどうかは判定できない。崩れは、記録とその後に起きたことの差にしか現れない。片方だけを渡すと、エージェントは記録の内部矛盾しか見つけられない。

2. 列挙させ、書き換えさせない。 これが本パターンの要である。監査と修正を同じ依頼に混ぜると、指摘がそのまま適用され、何が指摘されたのかが差分に埋もれる。 出力は「どの記録の、どの前提が、何によって崩れたか」の一覧と、原文へのリンクに限る。採否は人間が決める。

3. 契機を運用に埋める。 「思い出したとき」は契機ではない。週次・月次・リリース前など、外から来る時刻に紐づける。 監査の価値は当たりの薄い回にこそあり、当たりそうなときだけ回すなら、それはもう監査ではなく調査である。

なぜエージェントに向くのか。この作業は読む量が多く、判定が浅いからである。半年分の記録と半年分のログを突き合わせる作業は、一件ごとの判断は易しいが件数が多い。人間が苦手で、エージェントが得意な形をしている。そして最後の一点 — エージェントは、過去の判断を自分のものとして擁護しない。

トレードオフ

利点

• 前提の崩れを、壊れる前に見つけうる。 記録は自分の陳腐化を通知しないので、外から取りに行くしかない
• 人間のバイアスから独立している。 書いた本人が読み直すのとは、目に入るものが違う
• 判断の質そのものへ効く。 検出されるのは誤りではなく、前提が変わったことである。誤りの検出は機械ゲートの仕事であり、本パターンはその外側を扱う
• 記録の書き方が改善される。 監査を回すと「前提が書かれていない記録は監査できない」ことがすぐ分かる。監査は記録の品質検査にもなる

代償

• ⚠ 監査もまた推論である。 エージェントは「もっともらしい崩れた前提」を作り出せる。推論の誤りを推論で確かめる循環からは出られない（「計算をコードに落とす」が同じ構造を扱う）。だから出力を採用としてではなく候補として受け取ることが、運用上の必須条件になる
• ⚠ 確認した範囲では、この実践に公式の裏付けが無い。 本ページは、本カタログで中核の主張に [公式] を持たない唯一のページである。両ベンダーの資料8件に当たり、対応する記述は見つからなかった（具体例節に検索語と範囲を記す）。「公式がやれと言っている」とは読まないこと。 書けるのは機構の説明までである
• 費用が周期的に発生する。 当たりの薄い回にも同じだけ読ませる。読ませる範囲が広いほど費用は上がる（「委譲の損益分岐」）
• 記録が悪いと何も出ない。 結論しか書いていない記録からは、崩れた前提は原理的に取り出せない。本パターンだけを導入しても効かない
• 見つけたものを直す義務が生まれる。 崩れた前提の一覧を作り、放置すると、次の監査ではそれが雑音として毎回出てくる。直さない前提で回すと、監査は速やかに無視されるようになる

GitHub Copilot での具体例

このパターンの中核に、公式の対応物は確認できていない。 ただし「書き換えさせない」を構造で担保する手段には対応物がある。運用として書く。

Copilot CLI — 計画モードで、書き換えを止めたまま読ませる

監査を「列挙だけ」に留めたいとき、依頼文で「変更するな」と書くのは弱い。命令の遵守は非決定的だからである。構造で止めるほうが強い。

Copilot CLI には計画モード（--plan / /plan）があり、プロジェクトファイルの編集を止めたまま調査させられる。公式は変更に利用者のレビューが要ることを述べる一方、これを完全な封じ込めではなく安全網として位置づけている（CLI command reference、取得日: 2026-07-26。1,469,507 バイトを取得し、--plan は2件、changes require your review before applying は2件）公式。

同じ位置づけの機構は Anthropic 側にもあり、plan の権限モードはファイルの読み取りと読み取り専用のコマンドによる調査を行い、ソースファイルを編集しない（Claude Code の権限、取得日: 2026-07-26。626,938 バイトを取得し、doesn't edit your source files は2件）公式。

この2つが裏づけるのは「書き換えずに読ませる手段が両ベンダーにある」ことまでであり、「過去の判断を監査させよ」という実践ではない。 射程を混ぜないこと。詳しくは「計画の先制検証」を参照。

面を問わない運用 — 何を読ませ、何を出させるか

依頼に含めるのは4つである。

• 判断側 — 設計文書・決定の記録・命令ファイル・過去の issue のうち、監査したい範囲
• 変化側 — その後のコミット・作業ログ・新しい出典
• 出させるもの — 崩れた前提／弱くなった根拠／撤回条件に近づいた決定／未検証のまま事実扱いされている主張の4種、それぞれ原文へのリンク付き
• 禁じること — 書き換え。事実と推論を分けて述べること（「由来を分けて記録する」）

cloud agent に回す選択もあるが、その場合も出力は draft PR として人間のレビューを経る（「無人経路にこそ強いゲート」）。監査の結果を自動で適用させないこと。

不在確認 — 両ベンダーとも記述が見つからない

2026-07-26 に、両ベンダーの資料8件（GitHub: 応答のカスタマイズ／リポジトリのカスタム命令／cloud agent のリスクと緩和策／VS Code のカスタム命令。Anthropic: Claude Opus 5 のプロンプト設計／Claude Code のメモリ／Agent Skills の概要／Claude Code の Skills）の本文全体を取得し、検索した。

review past / revisit / contradiction / inconsistenc / assumptions / design document / ADR は全資料で0件である。audit はヒットするが、GitHub 側は cloud agent のログを人間が監査する話、Anthropic 側はメモリを人間が編集する話と、信頼できない Skill を人間が監査する話にとどまる。エージェントに過去の判断記録を読み直させ、陳腐化を列挙させるという用途は、確認した範囲では両ベンダーとも記述していない。

「無い」であって「否定されている」ではない。

別名

呼称	出典
記録した判断を後から監査させる / Auditing Past Decisions	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い
Decision review / 決定の棚卸し	記述 — 人間が行う実務としては一般的な言い回しだが、エージェントに行わせる実践としての一次出典は確認できていない

audit という語自体は両ベンダーの資料に現れるが、いずれも人間がエージェントの作業を監査する向きであり、本パターンのエージェントに人間の過去の判断を監査させる向きとは逆である。同じ語を、逆向きの意味で借りないこと。

関連

• 由来を分けて記録する — 本パターンの前提。由来が混ざった記録は監査できない。同パターンが構造を作り、本パターンがそれを使う
• 失敗の制度記憶化 — 記録に書く側。本パターンは書いたものを読み直させる側で、時間軸が逆を向いている
• 計画の先制検証 — これから行うことの事前検証。本パターンは下した判断の事後検証であり、計画モードという同じ機構を逆向きに使う
• 計算をコードに落とす — 推論の誤りを推論で確かめられないという同じ壁を扱う。あちらは計算をコードへ逃がし、本パターンは逃がせないので人間の採否を残す
• 無人経路にこそ強いゲート — 監査を無人で回すなら、結果の適用経路にゲートが要る
• 手順の可搬性を設計する — 置き場所の判断が依存している互換の向きは、仕様の改訂で崩れうる。本パターンが後から効く典型の一つである