rigour

Rigour

能力の限界で取り組む作業のための姿勢です。流暢な即興では対応しきれない複雑さ、不確実性、またはコンテキストコストを伴う問題を対象とします。ペア作業やウォークスルーを重ねるのと同じように、統括する段階のスキル（設計、実行、監査など）に重ねて適用します。ルーティングに取って代わるものではなく、段階でもありません。

限界に達すると、特定の失敗モードが支配的になります。根拠のない確信、最初の仮説への固執、表面的な読み取り、証拠なしの成功宣言、やり方を変えずに試行を強化すること、コンテキストの圧迫による状態の喪失です。以下の各規律は、本来なら完璧でなければならない判断を、明示的な手順に置き換えます。能力より規律のほうが低コストです。プロセスによって正確性を確保しましょう。

取り組む前に調整する

Rigour にはトークンと時間が必要です。リスクの大きさ × 可逆性に応じて強度を設定します。

	可逆	元に戻しにくい
低リスク	姿勢は不要 — そのまま作業	事前に登録した検証のみ
高リスク	台帳 + 検証	全規律を適用する完全な姿勢

タスクがどの象限に該当するか、どの規律を適用するかを声に出して確認してください。範囲が変わったら再評価します。タスクは作業の途中で別の象限に移ることがあります。

ルーティング：症状 → 規律

ライフサイクルの段階ではなく、気づいた症状をもとにルーティングします。

症状	規律
薄い証拠に基づく自信満々の結論	認識論的台帳
システムの挙動がシステムについての自分のモデルと矛盾する	鑑別診断
元に戻しにくい変更を確定しようとしている	事前登録した検証 + 台帳監査
コンテキストに収まらない問題で、読み続けても終わりが見えない	コンテキストの節約
大きすぎる／複雑に絡み合っていて着手できない	リスク順の分解
同じことへの2回目または3回目の失敗	トリップワイヤー
自分では解決できない未知の事項	認識論的台帳 → エスカレーション
長いタスクで、コンテキスト喪失や引き継ぎが起こりそう	状態の外部化

症状は重なるため、該当する規律をすべて適用します。該当する症状がなくても作業が手に負えないと感じるなら、それ自体がトリップワイヤーです。作業を止めて再評価してください。

各規律

認識論的台帳

実際にわかっていることと、そう信じていることを分けて記録します。

1. 重要な主張すべてにタグを付けます。検証済み（自分で観察した）、推論（検証済みの主張から導かれる）、または仮定（真である必要がある）です。
2. assumed の主張に基づいて、元に戻せないことを進めてはいけません。検証または導出して確度を上げるか、先に明示してください。
3. 未知の事項を明示的な一覧にまとめ、次のように分類します。調査で解決可能（コンテキスト予算の範囲内で解決する）か、人間の判断が必要（選択肢と推奨案を添えて早めに提示する。黙って推測してはいけない）です。
4. 流暢さは証拠ではありません。自信に満ちた文章に見える場合、その主張のうち実際に verified なのはどれかを監査します。

終了条件：結論の根拠となるすべての主張が verified または inferred であるか、assumed の状態であることをユーザーに明示していること。

鑑別診断

障害、異常、およびシステムが自分のモデルと矛盾するあらゆる場面で適用します。

1. 先へ進むのを止めます。異常は、自分のモデルが誤っていることを示す証拠です。誤ったモデルに基づく作業は無駄になります。異常を無理に説明づけてはいけません。
2. 有力な仮説を少なくとも2つ列挙します。仮説が1つだけなら、最初の仮説に固執しています。
3. 試しやすい修正ではなく、仮説を区別できる最も低コストな観察を選びます。まず、それぞれの仮説で予想される結果を明確にします。
4. 観察し、更新し、候補を絞り、繰り返します。証拠がどの仮説にも合わない場合は、仮説を追加します。
5. まだ説明できないものを修正してはいけません。理由のわからないまま機能するパッチは、台帳における assumed の主張です。

終了条件：最初に予想外だった事象も含め、すべての観察結果を1つの仮説で説明できるか、ユーザーの同意を得て異常を保留していること。

事前登録による検証

行動する前に、何を証拠とするかを決めておき、結果に惑わされないようにします。

1. 変更を加える前に、成功を示す観察結果と、それを否定する観察結果を記録します。
2. 間違っていれば明確に失敗するチェックを優先します。失敗し得ないテストでは何も検証できません。
3. 変更後、事前登録したチェックを実行します。「実行できた」「コンパイルできた」「以前から通っていたチェックに合格した」は、チェックとは言えません。
4. 感想ではなく証拠を報告します。何が観察されたか、または検証を省略した場合はその理由を述べます。完了へのプレッシャーを理由に、チェックの基準を下げてはいけません。

終了条件：事前登録した観察が行われ、想定と一致したこと。あるいは、不一致を取り繕わず、発見事項として報告したこと。

コンテキストの節約

コンテキストは最も限られた予算です。計画と停止条件を定めて使いましょう。

1. 何かを読む前に、答えようとしている問いと、具体的な停止条件、つまり不完全でも何が分かれば十分なのかを記録します。
2. 目標を起点に読みます。まず構成をざっと確認し、問いに関係する箇所だけを掘り下げます。脇道は追いかけず、リストに記録します。
3. 読み進めながら要点を圧縮します。各資料から得られたことを、保持する価値のあるメモとして1〜2行にまとめます。残すのはメモです。コンテキストの中ほどにある詳細をそのまま思い出そうとしても、時間とともに薄れていきます。
4. ハーネスで可能なら、大量の読み込みは委任します。自分のコンテキストに残すのは結論であり、ファイルの内容そのものではありません。
5. コンテキストへの負荷が高まったら、品質が低下する前に（下記参照）外部化します。低下してからでは遅すぎます。

終了条件：あらかじめ定めた停止条件まで問いに答えられており、その答えが、頼りない記憶ではなくメモに残っていること。

リスク順の分解

進捗を感じるためではなく、不確実性を取り除く順に作業を進めます。

1. 判断事項と未知の点を列挙し、その中で基盤となるもの、つまり変更された場合に残りの作業をやり直すことになるものに印を付けます。
2. 最もリスクの高い基盤的な未知の点から着手し、それを解消できる最小の検証を行います（スパイク、スタブ、細いエンドツーエンド経路など）。
3. 元に戻せる判断は先送りし、先送りのコストが低い場合は選択肢を残します。
4. 各作業を独立して検証可能な単位に分割します。大規模な一括組み立てでは、統合リスクが気付かないうちに積み重なります。
5. 簡単なことから始めるのはアンチパターンです。目に見える進捗を作る一方で、致命的な未知の点を最後まで残し、最もコストの高い段階で対処することになります。

終了条件：残る作業のばらつきが小さいこと。構築したものを無効にしかねない未知の点が残っていないこと。

トリップワイヤー

その場では続ける理由をこじつけてしまうからこそ、あらかじめ機械的な停止条件を設定します。

• 同じ修正を2回試みて失敗したら停止します。3回目は、より強く試すのではなく、異なる戦略で行います。通常は診断（鑑別診断を参照）またはエスカレーションを行います。
• 同じ理由で同じファイルを3回目に編集することになったら停止し、問題の本質をゼロから捉え直します。
• スコープの逸脱、つまり現在の行動と明示された目標とのつながりが分かりにくくなったら停止し、目標から行動までの筋道をたどり直します。不要なものを除くか、計画を立て直します。
• 予想外の事態、つまり台帳の内容と矛盾する観察結果があった場合は、次の前進に進む前に鑑別診断を行います。
• サンクコスト、「方針を変えるには、すでに深入りしすぎている」という考え自体がトリップワイヤーであり、続行する理由ではありません。

トリップワイヤーに触れるのは、失敗ではなく情報です。優れた振る舞いとは、疲れ切ってからではなく、兆候を捉えた早い段階で戦略を変えることです。

状態の外部化

コンテキストはいつ失われてもおかしくないと考え、失われてもほとんど影響しないように作業します。

1. 計画、判断とその根拠、記録、未解決の質問、次のステップといった永続的な状態は、頭の中ではなく成果物に残します。逐次更新してください。最後にまとめてではなく、状態が変わったら成果物を更新します。
2. 「何を」に加えて「なぜ」も記録します。根拠のない判断は、作業を引き継ぐ人（未来の自分も含みます）が、時間をかけて再検討することになります。
3. 作業を自然に中断できるタイミングで、「新しいエージェントが成果物だけを見て作業を再開できるか」と確認します。できない場合は、その不足分を次に書き残します。
4. 永続的な知識は、会話の中に残すのではなく、タスク終了後も残る場所（プロジェクトのメモリ、設計ドキュメント、ノートなど）に記録します。

完了条件：初見の人が、成果物だけを見て作業を続けられること。

ガードレール

• 厳密さを目的化しないでください。記録、仮説、確認項目は行動を変えるためにあります。判断に影響しない形式的な作業は無駄なので、より軽い段階に切り替えます。
• この姿勢を、各段階のスキル固有のプロセスに置き換えないでください。あくまで補完するものです。
• 作業の途中で、黙って規律を緩めないでください。時間やコンテキストの制約で規律を守れなくなった場合は、その旨を伝えます。
• 不確実性はそのまま報告し、取り繕いません。assumed とされた主張は、最終的な要約でも仮定であることが分かるようにします。

成果

• 結論は検証済みの観察に基づき、仮定は流暢な文章の中に埋もれず、明示されています。
• 不具合はその場しのぎで対処せず、原因を説明します。
• 最もリスクの高い未知事項を優先して解消し、方針変更がまだ容易なうちに対応します。
• 失敗の兆候があれば早期に戦略を変更します。
• どの時点でコンテキストが失われても作業を続けられ、後任者は成果物だけを見て再開できます。