Advisor Gate

---
name: advisor-gate
description: |
  A procedure for consulting a *frontier-class* external reasoning model (extended-thinking tier) on a decision that matters — and for accepting its answer afterwards. Generates the consultation prompt, then audits the reply. Vendor-neutral: any top-tier model will do. Not for routine work sent to a cheap model — that is overkill.
  最上位の外部推論モデル（拡張思考を持つfrontier級）へ重要な判断のレビューを諮問するための、プロンプト生成・検収手順。手貼り・API問わず、外部の高品質な頭を一発で最大限に使うための型。
---

# advisor-gate

**外部の高品質モデルへの諮問プロンプト生成・検収手順**

> **English abstract** — This is a procedure, not a prompt library. Before writing a consultation prompt for a frontier model, the agent must (1) fix a *decision contract* (what will change as a result of the answer), (2) enumerate **decision pivots** — facts whose alternative values would flip the conclusion — and classify each as PRESENT / BOUNDED / UNKNOWN / REDACTED / NOT-MATERIAL, (3) judge sufficiency as A (decidable) / B (conditional) / C (**do not generate a prompt**), and only then fill the standard template. It deliberately replaces "give MECE context", which has no completion test, with a procedural criterion that does. After the answer arrives it is stored verbatim, converted into a *findings ledger* keyed by (target × failure mechanism × impact) so later consultations cannot re-earn the same point, and gated by decision severity. Written mainly in Japanese; the structure is language-independent.

**置き場所のプレースホルダ** — 本文中の保存先は次の記号で書く。自分の環境の実パスへ読み替えること。

| 記号 | 意味 | 例 |
|---|---|---|
| `<state_dir>/` | 実行時の状態・作業ファイル置き場 | `local/state/` |
| `<state_dir>/advisor_answers/` | 外部AI回答の逐語と検収カード | `local/state/advisor_answers/` |
| `<state_dir>/advisor_answers/findings_ledger.yaml` | 指摘台帳（スキーマは `references/review-checklists.md`） | 同上 |
| `<decision_journal>` | 採用裁定の追記先（追記のみ） | `judgment/decisions_journal.md` |

置き場所の規約は3つだけ。①**回答は逐語で1ファイル**（加筆・整形・要約をしない）②**検収カードは回答ファイルの末尾に併記**（逐語と検収を1枚で開く）③**指摘台帳は回答とは別ファイル**（次回はこちらを渡し、回答全文は渡さない）。

## 目的

外部の高品質モデル（frontier級・拡張思考を持つ最上位の推論モデル）へ手で貼り付ける／APIで投げる「外部諮問プロンプト」を、AIエージェントが一貫した手順で生成し、返ってきた回答を検収する。

対象は、システム設計レビュー、文書批評、値付け、商談判断、発信戦略、キャリア相談などを問わない。
**宛先を選ばない**——拡張思考を持つ最上位モデルであれば、どのベンダーのものでも成り立つように書いてある（宛先固有の設定は、自分の環境側に1箇所だけ書く。§7を見よ）。

**使う線引き**: これは「日常の作業モデルへの発注」ではなく、**一発で最大限の頭を使いたい重要な判断のレビュー**のための型である。安い作業モデルへ細かい仕事を投げるときにこの手順を回すのは過剰——そちらは普通の作業指示でよい。

本手順書が最適化するものは、次の4点である。

1. 回答が具体的で、そのまま実装・修正・意思決定へ接続できること。
2. オーナーの仮説や希望への自動追従を避けること。
3. 渡された対象の内側だけでなく、フレーム外・境界面・未提示領域の穴を指摘できること。
4. 継続諮問で同じ指摘を言い換えて繰り返させないこと。

外部AIの回答は原文のまま保存する。ただし、外部AIの発言だけを根拠に「事実」へ昇格させてはならない。回答は、事実ではなく「外部レビュー結果」「提案」「仮説」「リスク指摘」のいずれかとして扱い、採用裁定と実測結果を別に記録する。

## 参照ファイル（いつ読むか）

本文は手順の骨格・判断の基準・安全の境界だけを持つ。細目は同じスキルの `references/` にある。

| ファイル | いつ読むか |
|---|---|
| [`references/prompt-template.md`](references/prompt-template.md) | 十分性が A か B と決まり、プロンプト本文を組み立てるとき（標準テンプレート全文） |
| [`references/context-categories.md`](references/context-categories.md) | 14カテゴリの「何を渡すか」の細目を確かめたいとき・省略してよいか迷ったとき |
| [`references/review-checklists.md`](references/review-checklists.md) | 回答を検収するとき（点検項目・検収カードの欄・保存項目・指摘台帳のスキーマ） |
| [`references/design-history.md`](references/design-history.md) | 前身の版から何を廃止したか、経緯を知りたいとき |

---

## 0. 「コンテキストの十分性」の運用定義

### 0.1 「MECEに渡す」を採用基準にしない

諮問コンテキストについて、「世界を漏れなくダブりなく説明する」ことはできない。
必要なのは、題材全体をMECEに記述することではない。必要なのは、今回の判断を変えうる情報を、未申告のまま落とさないことである。

したがって、本手順書ではコンテキストの十分性を、次のように定義する。

> 諮問コンテキストが十分であるとは、今回求める判断について、結論・確信度・優先順位・実装方法のいずれかを変えうる変数が、提示済み・範囲限定済み・不明として明示済み・非該当と確認済みのいずれかに分類されている状態をいう。

これは「絶対に漏れがない」という意味ではない。
これは、所定の分解軸を走査し、発見した判断変数をすべて処理し、残余の未知について受け手側の監査も要求した、という手続き上の十分性である。

### 0.2 判断ピボット

本手順書では、次の情報を「判断ピボット」と呼ぶ。

> その値を、現実にありうる別の値へ置き換えたとき、推奨結論、採否、重大度、優先順位、実装方法、必要な追加検証のいずれかが変わる情報。

例として、値付けなら相手の予算上限、作業原価、失注時の代替案件が判断ピボットになりうる。
記事批評なら、想定読者、記事の目的、公開場所、中心主張を裏づける実測の有無が判断ピボットになりうる。
システム設計なら、実際の利用主体、障害時の復旧方法、権限境界、既存システムとの接続面が判断ピボットになりうる。

「関連している情報」ではなく、「変わると判断が変わる情報」を探す。

### 0.3 判断ピボットの状態

エージェントは、発見した判断ピボットを次の5状態のどれかへ分類する。

- **PRESENT：提示済み** — 値または現物が存在し、出所・時点・身分が確認できる。
- **BOUNDED：範囲限定済み** — 正確な値は不明だが、現実的な範囲、複数シナリオ、上限・下限などが示されており、条件分岐による判断が可能である。
- **UNKNOWN：不明** — 判断へ影響するが、値が分からない。誰が、または何が埋められるかも記録する。
- **REDACTED：意図的省略** — 機密、匿名化、長さなどの理由で渡さない。省略理由だけでなく、省略によって変わりうる判断も記録する。
- **NOT-MATERIAL：判断非影響** — 別の値に変わっても今回求める判断が変わらないと確認できた。単に「関係なさそう」ではなく、反実仮想を置いて判断が変わらないことを確認する。

### 0.4 十分性の3段階

**A. 決定可能**
高影響の判断ピボットがすべてPRESENTまたはBOUNDEDであり、重大な出所衝突もない。
外部AIへ無条件の総合判断を求めてよい。

**B. 条件付き諮問可能**
高影響のUNKNOWNまたはREDACTEDが残っているが、複数シナリオによる条件付き回答は可能である。
外部AIには、無条件の結論を出させず、「XならA、YならB」と分岐させる。
回答をそのまま最終決定へ使ってはならない。

**C. 諮問生成禁止**
次のいずれかに該当する。

* 何を決めたいのかが確定していない。
* 判断対象の現物または現在状態がない。
* 対象の版が特定できない。
* 中心事実が複数の資料で矛盾したままである。
* 選択判断なのに比較対象または現状維持案がない。
* 欠落情報が大きすぎて、条件分岐すら作れない。

この場合、外部AIへ曖昧な相談を投げてはならない。
エージェントは保有資料から不足を補完する。不足がオーナー本人にしか埋められない場合だけ、何が不足し、それによって何の判断ができないかを短く返す。

### 0.5 コンテキスト生成手順

エージェントは、プロンプト本文を書く前に、次の手順を踏む。順序（判断契約→判断ピボット→資料→十分性）は崩さない——資料から始めると、目についたものを貼るだけの諮問になる。
途中の記録（点検表・ピボット表）を残すのは、影響が中・高のものだけでよい（重大度は §4.5）。

#### 手順1：判断契約を固定する

次を一文または短い項目へ変換する。

* 何を決めるのか。
* 回答によって何を変更するのか。
* 誰が最終決定するのか。
* 取りうる判定は何か。
* 回答は実装根拠、決定材料、参考意見のどれか。
* 判断の期限。
* 間違えた場合に戻せるか。
* 失敗時の影響。

「この設計をレビューして」では不十分である。
「現行設計をそのまま採用するか、条件付き採用にするか、管理単位から作り直すかを決める」のように、回答が変更する行動を明示する。

#### 手順2：諮問の型を選ぶ

題材ではなく、求める判断の形で分類する。

- **適否・欠陥監査型** — 「この設計、文章、運用は成立するか」。主な分解対象は、要件、部品、境界面、利用場面、故障経路、ライフサイクルである。
- **比較・選択型** — 「AとBのどちらを選ぶか」「いくらにするか」。主な分解対象は、選択肢、現状維持、何もしない案、評価基準、シナリオ、利害関係者、時間軸である。
- **原因診断型** — 「なぜ失敗したか」「何が真の欠陥か」。主な分解対象は、症状、時系列、変化点、仮説、支持証拠、反証証拠、代替原因である。
- **戦略・計画型** — 「何を、どの順番で行うか」。主な分解対象は、段階、行動、担当主体、依存関係、資源、フィードバック、撤退条件である。
- **体験・コミュニケーション型** — 「読者、顧客、相手にどう受け取られるか」。主な分解対象は、対象者、接触前の期待、接触中の理解、信頼、感情、行動、離脱地点である。
- **継続・再検査型** — 「前回の指摘を直した結果、現在は成立するか」。主な分解対象は、前回指摘、変更差分、変更の影響範囲、実測結果、未修正箇所、再発面である。

一つの諮問に独立した型が3つ以上含まれる場合は、原則として諮問を分ける。

#### 手順3：共通の分解軸を走査する

どの型でも、最低限、次の6軸を走査する。

1. 対象・部品・境界・接続面
2. 人・役割・権限・利害・インセンティブ
3. 時間・順序・状態遷移・短期と長期
4. 事実・証拠・測定・不確実性
5. 制約・資源・変更不能条件
6. 外部環境・二次影響・対象外領域との相互作用

各軸について、「この軸に、値が違えば結論が変わる情報はあるか」を調べる。
非該当の理由を書き残すのは、その軸を落とすと結論が変わりうる（影響 中・高）ときだけでよい。

#### 手順4：判断ピボット表を作る

判断ピボットごとに、内部で次を記録する。

* ピボットID
* どの分解軸から発見したか
* 現在分かっている値
* 現実的な反対値または別シナリオ
* 値が変わった場合に変わる判断
* 必要な証拠
* 証拠の所在
* PRESENT／BOUNDED／UNKNOWN／REDACTED／NOT-MATERIAL
* プロンプトのどの節へ収録するか

この表は通常、オーナーへ見せなくてよい。影響が中・高のピボットだけ、生成品質の証跡として残す。

#### 手順5：資料を検索・回収する

先に資料を眺めて、目についたものを貼るのではない。
先に判断ピボットを作り、そのピボットを埋めるために、案件台帳、現物、過去裁定、ログ、実測、外部資料を検索する。
資料選択を「資料起点」ではなく「判断起点」にする。

#### 手順6：敵対的な漏れ検査を行う

次の問いを別途走査する。

* 反対の結論を正しくする事実は何か。
* 現在の設計者の分類そのものが間違っている可能性はないか。
* 対象の外側に、入力元、出力先、運用者、被影響者は存在しないか。
* 平常時には見えず、導入時、例外時、障害時、終了時だけ現れる問題はないか。
* オーナーが当然だと思っているため、文書化されていない前提はないか。
* 過去の成功例だけでなく、未観測、失敗例、反証例はあるか。
* 「何もしない」「延期する」「範囲を狭める」が選択肢から落ちていないか。
* 成功条件自体が、現在案に都合よく定義されていないか。

ここで新しい判断ピボットが見つかったら、手順4へ戻す。

#### 手順7：十分性を判定する

A、B、Cのどれかを確定する。
Bの場合、外部AIへ条件付き判断を求めるためのシナリオを作る。
Cの場合、諮問プロンプトを生成しない。

#### 手順8：不要情報を削る

すべての収録候補について、次の問いを置く。
この情報は、どの判断ピボット、制約、証拠、反証、重複防止のために必要か。
どれにも結びつかない情報は削る。

### 0.6 受け手側から渡し漏れを検知させる仕掛け

「回答の前に、不足している情報をすべて列挙してください」だけを書くのは禁止する。
この指示には次の副作用がある。

* なくても回答できる情報まで欲しがる。
* 不足情報の一般論を並べて、肝心の回答をしない。
* 慎重さを演じるために、不要な質問を増やす。
* 提示された範囲の分析より、欠落探しへ出力を使いすぎる。
* 情報が足りないという理由で、判断責任を回避する。

代わりに、外部AIへ次を要求する。

1. 不足情報は「結論を変えうるもの」に限定する。
2. 全ブロッカーと、影響上位の重要情報だけを列挙する。
3. それぞれについて、何の結論がどう変わるかを書く。
4. 回答可能なら、質問して停止せず条件付きで回答を続ける。
5. 渡された分類体系そのものが不完全でないか監査する。
6. 未提示領域について、具体的な故障経路と結びつかない一般論は書かない。

受け手側の監査は、未知の領域候補を発見する保険である。
渡されていない固有事実そのものを、受け手が復元できるわけではない。したがって、受け手側監査を、生成側のコンテキスト点検の代用にしてはならない。

### 0.7 過剰に渡す害との均衡

長いこと自体を不合格理由にしない。ただし、「関連資料を全部貼れば安全」とも考えない。

**原文のまま渡すもの**

* 評価対象そのもの
* 表現、文言、構造が検査対象となる文章
* 契約、仕様、ルールなど、正確な文言が結論を左右する箇所
* 障害ログや顧客発言など、要約によって身分が変わりうる証拠
* 前回からの変更差分

**構造化して圧縮してよいもの**

* 長い時系列
* 重複した背景説明
* 採用済み裁定の履歴
* 複数資料に重複する同じ事実
* 評価対象ではない周辺情報

**原則として渡さないもの**

* 今回の判断を変えない経歴や雑談
* 同じ内容を別の言葉で説明した文書
* 古い版と新しい版の全文の重複
* オーナーの感情的な希望
* 推奨結論を先に誘導する説明
* 「念のため」だけで付けた資料

**長くなりすぎた場合の削減順序**

1. 重複と旧版を落とす。
2. 背景の物語を、事実・時系列・制約へ構造化する。
3. 過去回答全文を、指摘台帳へ置き換える。
4. 独立した判断を別の諮問へ分ける。
5. 周辺資料を付録へ移し、本文からIDで参照する。

評価対象の現物や決定的証拠を先に要約してはならない。

---

## 1. プロンプトに含めるコンテキストのカテゴリ（14）

カテゴリは走査の手がかりであって、毎回すべての点検表を作る義務ではない。記録を残すのは、**省略不可のカテゴリ**と、**省略すると結論が変わりうるもの（影響 中・高）**だけ——状態（収録／不明／非該当／意図的省略）・省略理由・外部AIへの宣言の要否を1行ずつ。各カテゴリで何を渡すかの細目は [`references/context-categories.md`](references/context-categories.md)。

| # | カテゴリ | 省略してよい条件 | 省略・不在のときの扱い |
|---|---|---|---|
| 1.1 | 判断契約 | 省略不可 | 埋まらなければ諮問生成禁止（十分性 C） |
| 1.2 | 諮問モードとレビュー視点 | 省略不可 | 指定がなければ「全文脈監査」。視点は権威演出でなく、どの基準・利用場面から見るかで書く |
| 1.3 | 対象の現物・現在状態・版 | 全文を省けるのは、全文が極端に大きい・判断対象の論理単位が明確・接続面を別途提示・省略一覧と影響しない理由を宣言、の**すべて**を満たすときだけ | 「巨大だから適当に関連部分だけ抜いた」は認めない |
| 1.4 | 対象範囲・構造・境界面 | 境界面が判断に影響しない場合（単純な短文校正など）だけ | 「対象は提示文だけ。周辺導線は評価しない」と宣言する |
| 1.5 | 事実・証拠・出所・身分 | 中心主張を支える証拠は省略不可 | 証拠が無ければ、無いこと自体を明示する。測定していないことは「未測定」と書く |
| 1.6 | 当事者・権限・利害・インセンティブ | 人物や組織が判断へ影響しない純粋な形式検査だけ | 非該当とする場合も走査は行う |
| 1.7 | 時系列・履歴・実測結果 | 履歴が存在しない単発の対象だけ | 「初回であり、過去実績なし」と宣言する |
| 1.8 | 代替案・基準案・何もしない案 | 選択を伴わない場合（純粋な誤字検査など）だけ | 設計レビューでも「現行のまま」が基準案になるので、通常は省略しない。捨てた理由は事実と制約で書く |
| 1.9 | 制約・資源・変更不能条件 | 省略不可 | 制約が無ければ「確認できている硬い制約なし」。硬い制約と好みを分ける |
| 1.10 | 成功条件・失敗条件・判断基準 | 探索的な相談だけ | 「成功条件を定めること自体が今回の相談目的であり、この回答だけでは採用裁定を出さない」と宣言する |
| 1.11 | オーナーの仮説・設計意図・選好 | 初見読者レビュー・ブラインド比較・意図が判断へ不要な検査では省略する | 書くなら事実・現物・制約の後に置き、「採用済みの結論ではなく現在の仮説」と明記する |
| 1.12 | 過去の外部指摘・採否・変更差分 | 初回諮問では省略する。継続諮問での省略は禁止 | 過去回答全文ではなく指摘台帳を渡す。逐語確認が要る争点だけ原文を添える |
| 1.13 | 外部情報と調査権限 | 省略不可 | 指定がなければ閉世界として扱う |
| 1.14 | 未確認・省略・匿名化・矛盾 | 省略不可 | 「渡していないものはない」と書く場合も、分解軸を走査したうえで書く |

---

## 2. プロンプト本文

本文は標準テンプレート（[`references/prompt-template.md`](references/prompt-template.md)）の波括弧を実値へ置き換えて作る。
存在しない節を空欄のまま残さない。「非該当」「確認できず」「初回のため履歴なし」のいずれかを書く。
実際に渡すプロンプトファイルにはコードフェンスを付けない。

### 2.1 初見読者レビューの例外（初見と文脈込みを2諮問へ分離）

初見反応を測りたい場合、完全なコンテキストを渡すことと、初見状態を再現することは両立しない。
後段に著者の意図や過去評価を書いても、同一プロンプト内に存在する以上、厳密なブラインドにはならない。
したがって、初見性が重要な場合は次の2諮問へ分ける。

**初見諮問** — 渡すものは次に限定する。

* 対象の現物
* 想定読者の知識、関心、読む状況
* 初見で答える質問
* 公開場所や価格など、実際の読者も知る情報

渡さないものは次である。

* 著者の意図
* 過去の批評
* 書き手が直したい箇所
* 中心主張の解説
* 実測結果のうち読者が知らないもの

**文脈込み諮問** — 標準テンプレートを使い、構造、誠実性、事業目的、導線などを検査する。

一回の諮問で両方を行った場合は、「初見ロールプレイ」であって「ブラインド検査」ではないと記録する。

---

## 3. 生成時の禁止事項

他の節で書いた規則（判断ピボットを先に作る・仮説は後段に置く・事実と解釈を分ける・前回回答全文を貼らない・同じ指摘を新規と数えない など）は、ここで繰り返さない。ここに置くのは、他の節に無い禁止だけ。

- **「正本を全部貼る」を十分性とみなさない** — 正本があっても、境界、代替案、当事者、実測、外部条件が正本の外にある場合は不足する。
- **感情的な評価語を証拠の前に置かない** — 「重大事故」「くだらない案」「画期的」など、結論を先取りする語を避ける。
- **「厳しく」「容赦なく」だけで済ませない** — 攻撃的な語調は、実質のない否定を増やすことがある。代わりに、根拠、失敗機構、影響、反証条件を要求する。
- **反対意見を3件など、件数を強制しない** — 実在しない欠陥を作らせる可能性がある。「重大な問題をすべて。ゼロも可」とする。
- **賛成と反対を同数にしない** — 見かけ上のバランスを作らず、証拠量に応じて非対称でよい。
- **「深く考えて」「ステップバイステップで考えて」と書かない** — 思考量を要求するのではなく、判断対象、証拠、制約、成功条件、反証条件を明確にする。
- **推論手順を細かく固定しない** — 出力に必要な検査項目は指定してよいが、内部でどの順番に考えるかまで上書きしない。
- **質問を増やしすぎない** — 一つの主質問と、必要な副論点だけにする。5問を超える場合は、独立した判断が混在していないか再確認する。
- **出所のない数字を渡さない** — 取得日時、母数、期間を付ける。
- **証拠なしの断言を採用しない** — 外部AIが「一般に」「多くの場合」と述べても、今回の対象へ適用できる証拠がなければ一般論のまま扱う。
- **URLだけを対象として渡さない** — 主要な評価対象は本文または現物を含める。URLは出所、更新確認、追加調査の入口として添える。
- **修正箇所だけを孤立して見せない** — 変更による周辺影響を判断できるだけの前後・接続面を含める。

---

## 4. 回答品質を検証する最小の仕組み

数分で、開放的な判断の正しさを完全に証明することはできない。
数分でできるのは、浅い回答、無根拠な回答、条件を落とした回答、既出の言い換えを排除することである。
高額、不可逆、対外影響、法務、安全性に関わる判断では、外部AI一回答だけを正しさの証明にしてはならない。

### 4.1 エージェントによる自動検収

回答を回収したら、生成担当エージェントは原文を変更せず保存する。
その後、可能なら別コンテキストの検収担当が、プロンプトと回答だけを入力として点検する。
観点は6つ——**契約充足・根拠接続・事実整合・不確実性管理・実装可能性・新規性**。各観点の点検項目は [`references/review-checklists.md`](references/review-checklists.md)。
重大指摘に、対象箇所・資料IDまたは外部出所・失敗機構・影響・対応・反証条件がそろっていなければ、浅い回答として扱う。

### 4.2 指摘の同一性

表現の一致ではなく、次の3要素で指摘の同一性を判定する。

> 対象または境界 × 失敗機構 × 生じる影響

この3要素が同じで、新しい証拠、影響範囲、原因、対処が追加されていなければ既出重複である。

- **新規** — 新しい対象、失敗機構、影響のいずれかがある。
- **深掘り** — 同じ指摘だが、新しい原因、証拠、影響範囲、反証条件が加わった。
- **回帰** — 以前は解消済みだった指摘が再発した。
- **既出重複** — 言い換えただけで、新しい情報がない。

既出重複は保存してよいが、新しい成果や新規欠陥として数えない。

### 4.3 検収カード

エージェントは、回答原文とは別に、オーナーが1画面で確認できる検収カードを作る。
欄の全体は [`references/review-checklists.md`](references/review-checklists.md)。少なくとも、外部AIの総合判定・コンテキスト状態・採用可能性・最重要指摘3件とその根拠ID・推奨される次の一手・採用前にオーナー判断が必要な点を載せる。

### 4.4 オーナーの3分検収

オーナーは回答全文を再分析する必要はない。最低限、次の4点を見る。

1. 外部AIが「決定可能」と判定しているか。条件付きまたは判断不能なら、無条件採用しない。
2. 最重要指摘3件に、実物または出所へ戻れる根拠があるか。
3. 外部AIが暗黙に埋めた前提が、実際の案件と食い違っていないか。
4. 提案に、具体的な変更対象と完了条件があるか。

一つでも満たさなければ、回答は「参考意見」に留める。

### 4.5 判断の重大度による追加ゲート

- **低影響・容易に戻せる判断**（文章の一部修正、内部ツールの小変更） — 一回の外部諮問と検収カードで採用してよい。
- **中影響・戻すのに費用がかかる判断**（値付け、商談条件、公開戦略、構造変更） — 最重要な不確実性について、小さな実験、実測、一次資料確認のいずれかを行う。
- **高影響・対外的または不可逆な判断**（契約、法務、安全、顧客への重大変更、キャリア上の不可逆な決定） — 独立した第二のレビュー、専門家確認、実地テストのいずれかを要求する。外部AI一回答のみで「決定済み」にしない。

---

## 5. 諮問を重ねるときの継続設計

### 5.1 保存するもの

各諮問について、生成したプロンプト全文・外部AI回答全文・検収カード・オーナーの採否と理由・実装後の実測結果などを保存する（全項目は [`references/review-checklists.md`](references/review-checklists.md)）。
UI上のモデル名や挙動は将来変わりうるため、モデル名だけでなく日時とモードも残す。

### 5.2 指摘台帳

過去回答全文とは別に、指摘台帳を持つ。1指摘1レコードで、指摘同一性キー（§4.2）・オーナー裁定・再開条件などを持つ（スキーマは [`references/review-checklists.md`](references/review-checklists.md)）。
外部AI回答の要約は索引として扱い、原文を上書きしない。

### 5.3 次回プロンプトへ引き継ぐもの

次回は、過去回答全文ではなく次を渡す。

1. 現在の現物と版
2. 前回からの差分
3. 未解決の指摘
4. 実装済み指摘と実測結果
5. 拒否した指摘と拒否理由
6. 再開条件
7. 以前解消したが回帰確認が必要な指摘
8. 今回新しく判断したいこと

現在の現物を、過去指摘より前に置く。
過去の外部AIが言ったことを正解として継承させない。

### 5.4 同じ指摘をさせない指示

継続プロンプトには次を含める。

> 過去指摘と同じ「対象・失敗機構・影響」を述べるだけの内容は、新規指摘として展開しないでください。再度触れる場合は、回帰、新しい証拠、影響範囲の拡大、以前の裁定を覆す新事実のいずれかを明示してください。

拒否済み指摘については次を含める。

> 拒否済み指摘を再提案する場合は、以前の拒否理由を無効にする新しい証拠または制約変更を示してください。単なる再主張は不要です。

### 5.5 継続諮問の停止条件

次のすべてを満たしたら、同じ目的での再諮問を止める。

* 未解決の重大指摘がない。
* 成功条件の必須項目を満たした。
* 新しい変更差分がない。
* 実測待ちの項目は、実測前に再評価しても結論が増えない。
* 外部AIの結論がオーナーの希望と一致するまで聞き直している状態ではない。

回答が気に入らないことを、新しい諮問理由にしてはならない。
新しい証拠、変更、失敗、制約変更、別の判断目的がある場合だけ再開する。

---

## 6. 運用手順

### 6.1 プロンプト生成前

§0.5 の手順1〜8（判断契約→諮問の型→分解軸→判断ピボット表→資料の回収→敵対的な漏れ検査→十分性の判定→不要情報の削除）を踏み、標準テンプレートへ組み込み、対象版・日付・諮問IDを付ける。

### 6.2 オーナーへ渡すとき

1. 完成した貼付用プロンプトだけを、明確に区切って提示する。
2. 対象が初見レビューか全文脈監査かを明示する。
3. 条件付き諮問の場合は、無条件採用不可と一行で警告する。
4. **送信はオーナーが行う。** Web 画面への自動投函はしない（アカウント規約上の危険がある。投函と回収は人の手で行う）。オーナーが宛先モデルの新規チャットへ手で貼る。
5. API 経由で投げる運用でも、送る前にオーナーの承認を取り、新規セッションで投げる。

### 6.3 回答回収後

1. 回答全文を逐語保存する。
2. 原文へ加筆、整形、要約をしない。
3. 別途、指摘台帳と検収カードを作る。
4. 外部AIの発言を事実台帳へ直接昇格させない。
5. オーナーの採否を記録する。
6. 採用した場合だけ実装または意思決定へ接続する。
7. 実装後の結果を測定し、次回の判断材料へする。
8. 正本や標準文書の版は、外部AIが述べた時点ではなく、オーナーが採用し反映した時点で上げる。

### 6.4 完了の形

- **諮問を作る側**: 十分性が A か B で、貼付用プロンプトをオーナーへ渡した時点で完了（B なら無条件採用不可の警告つき）。C なら、何が不足し、それで何が決められないかを短く返した時点で完了——プロンプトは作らない。
- **回答を受け取った側**: 逐語保存・検収カード・指摘台帳の更新が済み、採否をオーナーに問える形になった時点で完了。採否をオーナーの代わりに決めない。

---

## 7. 宛先モデルの記録

本手順書は宛先モデルを選ばない。ただし §5.1 のとおり、諮問ごとに**モデル表示・日時・モード（拡張思考の有無・検索の有無）**を記録すること。UI上のモデル名も挙動も将来変わるため、名前だけでは同定できない。

宛先を切り替えたときは、切り替え自体を記録する。過去の指摘台帳は宛先が変わっても引き継ぐ——「別のモデルだから」は同じ指摘を新規として数え直してよい理由にならない。