由来を分けて記録する（Recording by Provenance）

エージェントは、観測した事実も、出典が述べている主張も、自分の推論も、同じ文体で書く。同じ入れ物に入れると、次に読む者は区別できない — そしてその次の読み手は、たいてい別のエージェントである。

問題

エージェントに調べさせて記録を作らせると、返ってくる文章はどれも同じ顔をしている。ログに実際に出ていた行も、公式ドキュメントが書いている一文も、モデルがそこから推した「おそらくこうであろう」も、区別のつかない断定として並ぶ。書き手が嘘をついているわけではない。文体に由来を刻む習慣が無いだけである。

問題が現れるのは書いた瞬間ではない。数週間後、その記録を読み直したときである。どれが確かめた事実で、どれが確かめていない推測だったかが、もう分からない。分からないので、全部が事実として扱われる。 検証されていない一文が、次の判断の前提になる。

しかもその読み直しを行うのは、多くの場合また別のエージェントである。エージェントは記録を疑わない。書いてあれば読み、読んだものを前提に次を書く。こうして、一度混ざった推論は、時間とともに事実へ昇格していく。 誰も嘘をつかないまま、記録全体の信頼度だけが静かに下がる。

「気をつけて書く」では止まらない。書き手に規律を求める対策は、書き手が疲れたとき・急いだとき・そして書き手がエージェントであるときに、まず破れる。

コンテキスト

適用する条件:

• 記録が後で読み返される — 一度きりの使い捨てなら由来は要らない。残る記録にだけ家賃を払う価値がある
• 記録を書く側と読む側が違う（時間的に離れている場合を含む）— 自分が今日書いたものを今日読むなら記憶が補う。三か月後の自分は他人である
• エージェントが記録を読んで次の判断をする — 人間なら「これは怪しい」と留保できるが、エージェントは書いてあるものを前提として扱う
• 主張の重みが由来によって違う — 実測と伝聞と推論を同じ重みで扱ってよい場面なら、分ける必要はない

適用しないケース:

• 由来が一種類しかない記録。 生ログ・計測値の羅列のように、全部が同じ由来なら欄を分ける意味がない
• 由来より鮮度が支配的なとき。 数分で捨てる作業メモに欄を作るのは、家賃だけ払うことになる
• 機械で判定できる真偽。 テストが通るかどうかは記録の欄ではなくテストが決める（「機械ゲートと意味ゲートの分離」）

隣接パターンとの境界:

• 失敗の制度記憶化 — 何を記録に残すかが同パターン、残すときにどう区別を保つかが本パターンである。同パターンのページは実際に本パターンを実装しており、観測できたことと監査者の判断を節ごと分けている（本ページの具体例節で引く）
• 出力の契約を明示する — 出力の形（長さ・粒度）の指定が同パターン。由来の分離は形ではなく内容の帰属であり、別の軸である
• 検証対象の明示 — 何を検証させるかが同パターン。本パターンはその手前で、何が既に検証済みで何がそうでないかを記録の上で見分けられるようにする
• 成果物の差分レビューと段階的採用 — 成果物をどう受け取るかが同パターン。本パターンは受け取った後、それを記録に落とすときの作法である

解決

なぜ効くのか。由来は、内容を読んでも復元できないからである。 「ビルドは3分12秒で終わった」という一文からは、それが計測値なのか、誰かの記憶なのか、モデルの見積もりなのかが読み取れない。復元できない情報は、書いた時点で欄に落としておくしかない。 後から足そうとしても、そのときにはもう分からない。

だから対策は、書き手への注意ではなく置き場所になる。見出しで分ける、欄を分ける、ラベルを付ける — 形は何でもよい。要件は一つだけで、内容を書くと自動的に由来も決まることである。書き手が「今これは推論だな」と自覚しなくても、推論の欄に書けば推論として残る。規律を人（やエージェント）の側に置かず、構造の側に置く。

欄の切り方は、粗すぎても細かすぎても働かない。実用的には、確かめ方の違いで切るのがよい。自分で観測したもの（もう一度測れば確かめられる）、出典が述べているもの（出典に当たれば確かめられる）、推論（確かめるには実験が要る）、判断（そもそも真偽ではなく選択である）。確かめ方が違うものを同じ欄に入れない — これだけで、後から「何を検証すればよいか」が決まる。

もう一つ、見落とされやすい欄がある。「調べたが見つからなかった」という由来である。これは推論でも事実でもない — 確認した範囲についての報告であり、確認範囲を書かない限り何も述べていないに等しい。本カタログはこれを [不在確認] として独立の欄に置き、確認した資料と検索語と範囲を必ず添える規約にしている。

トレードオフ

利点

• 後から検証すべき場所が決まる。 推論の欄だけを洗えばよい。混ざっていると、全部を疑うか全部を信じるかの二択になる
• 主張の重みが読み手に伝わる。 「実測が一件」と「公式が一件」は同じ強さではない。欄はその差を、読み手が読解に頼らずに受け取れる形にする
• 書いた本人以外が監査できる。 由来が書いてあれば、独立した第三者が同じ出典に当たり直せる。書いてなければ、著者に訊くしかない
• エージェントに渡す記録として頑健である。 エージェントは行間を読まないが、欄は読む

代償

• 書くのが重くなる。 一行書くたびに「これはどの欄か」を決める費用がかかる。使い捨ての記録には割に合わない
• 欄は真偽を保証しない。 ⚠ ここが最大の誤解である。「実測」の欄に書かれた数字が本当に測られたものである保証は、欄そのものからは出てこない。 由来の分離は検証を可能にするだけで、検証したことにはならない。本カタログでも、正しく欄立てされた記録の中に原文に存在しない引用が入り込んだことがある（具体例節）
• 欄が増えると運用が壊れる。 由来を細かく分けすぎると、どこに書くべきか毎回迷い、やがて全員が同じ欄に投げるようになる。確かめ方が同じものは同じ欄に置く
• 書き手が自分の欄を誤る。 とくに推論を実測の欄に置く誤りは、書いた本人には見えにくい。自己点検では代替できず、独立した主体による照合が要る（具体例節）

GitHub Copilot での具体例

このパターンは、確認した範囲ではどちらのベンダーの資料にも対応物が無い。 機能ではなく運用として書く。

面を問わない運用 — 命令ファイルに由来の規約を置く

置き場所は面によって変わるが、書くことは変わらない。github.com とリポジトリ全体に効かせるなら .github/copilot-instructions.md、適用範囲を絞るなら .github/instructions/NAME.instructions.md（Adding repository custom instructions for GitHub Copilot、取得日: 2026-07-26）である。VS Code も同じファイルを読む（Custom instructions、取得日: 2026-07-26）。

書く内容は、欄の定義と、どの欄に何を置くかである。「正確に書け」ではなく「確かめ方が違うものを同じ欄に置くな」と書く。前者は既定の挙動の言い直しにすぎず、公式が雑音と呼ぶ類の指示になる（「失敗の制度記憶化」が引く 公式 を参照）。

ただし遵守は保証されない。 github.com の公式は、AI の非決定性ゆえにカスタム命令が毎回まったく同じように守られるとは限らないと明記している（公式、docs.github.com）。決定的に守らせたい欄の規約は、命令ではなく機械のゲートにする（「機械ゲートと意味ゲートの分離」）。本カタログはこの道を採っており、根拠ラベルの表記と引用の照合はスクリプトが検査する。

本カタログでの実装 実測

このサイト自身が本パターンの実装である。n=1 の観測であり、一般法則としては書かない。

• 本文の主張には4つの由来ラベルを付ける — [公式]（ベンダーの一次資料）／[研究]（学術・第三者の公開研究）／[実測]（執筆者が自分の環境で観測した結果）／[不在確認]（一次資料に当たり、記述または出典が見つからないことを確認した）
• 名前の出典は別軸のラベルで扱う（[一次] / [通説] / [記述]）。主張の由来と呼称の由来は確かめ方が違うため、同じラベル体系に混ぜていない
• 「失敗の制度記憶化」のページは、同じ調査結果を「観測できたこと 実測」と「観測ではないこと（監査者の判断であり、実測 ではない）」に節ごと分けている。分けた理由も明記されており、反実仮想を回さずに見えることだけが [実測] を名乗れる、という基準になっている

⚠ そして、この構造でも中身の真偽は保証されなかった。 2026-07-25、根拠台帳に原文に存在しない句で終わる英語の逐語引用が記録された。欄は正しく、URL も取得日も揃っていた。それでも中身が違っていた。どの lint もビルドも検出しなかった。 検出できたのは、別の主体が独立に一次資料を取り直して照合したときだけである。

この事故から2つのことが言える。

1. 由来の欄は、検証を可能にするだけである。 欄があったからこそ「どの出典に当たればよいか」が一意に決まり、独立した照合が可能になった。欄が無ければ、何を確かめればよいかすら分からなかった
2. 書いた本人は自分の誤りに気づけない。 自己点検は生成時と同じ経路を辿るため、同じ結論に戻る。由来の欄は、他人が監査するために存在する

現在は、逐語引用ごとに照合の記録（検索語・ヒット数・日付・照合者）を並記することを機械で要求している。これも由来の欄であり、対象が「引用の中身をどう確かめたか」に移っただけである。

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

2026-07-26 に、次の8資料の本文全体（HTML は main 要素からタグを除去、.md は raw Markdown 全文）を取得し、22語を検索した。

ベンダー	資料	バイト数
GitHub	応答のカスタマイズ	892,478
GitHub	リポジトリのカスタム命令	698,276
GitHub	cloud agent のリスクと緩和策	575,557
GitHub	VS Code のカスタム命令	114,884
Anthropic	Claude Opus 5 のプロンプト設計	11,225
Anthropic	Claude Code のメモリ	616,932
Anthropic	Agent Skills の概要	20,256
Anthropic	Claude Code の Skills	953,891

observed facts / inference / assumption / hallucinat / cite / citation / provenance / do not fabricate / unverified / distinguish は全資料で0件である（inference のみ Claude Code の Skills に1件あるが、プロジェクトの起動方法を推測する文脈であり、記録の由来とは無関係である）。separate と source はヒットするが、いずれも命令ファイルの分割や Skill の構成要素の話であり、エージェントが書く記録の中で由来を分けよという趣旨のものは無かった。

「無い」であって「否定されている」ではない。 バイト数は全文を取得したことの記録であり、同一性の証明ではない（動的サイトはリクエストごとに数十バイト揺れる）。

別名

呼称	出典
由来を分けて記録する / Recording by Provenance	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い
Provenance	記述 — データ来歴の一般語としては広く使われるが、確認した範囲では、エージェントの記録に対する実践名として一次資料に現れない（上記8資料で provenance は0件）

エージェントが書く記録の由来を分ける、という実践に確立した呼称は見つかっていない。近い語（出典明記、引用規約、監査証跡）はいずれも一つの欄の名前であって、欄を分けるという設計そのものの名前ではない。

関連

• 失敗の制度記憶化 — 何を残すかが同パターン、残すときに由来をどう保つかが本パターン。同パターンのページは本パターンを実装した実例でもあり、観測と判断を節ごと分けている
• 検証対象の明示 — 由来の欄が決まると、検証すべき対象が決まる。本パターンは同パターンの前提を用意する
• 機械ゲートと意味ゲートの分離 — 欄の規約を命令で守らせるか機械で守らせるか。決定的に守らせたいものは機械の側へ置く
• 記録した判断を後から監査させる — 由来を分けて記録したものを、後から読み直させる。本パターンが記録の構造を作り、同パターンがその構造を使う
• 出力の契約を明示する — 出力の形の指定。由来の分離は形ではなく内容の帰属であり、軸が違う