thinking-map-territory

地図と領土

ドキュメント、テスト、図、メトリクス、コメント、メンタルモデルは地図です。実行中のコードと実際のデータが領土です。両者が食い違う場合は、領土を確認してモデルを更新します。現実を説明に合わせようとしてはいけません。

使用する場面

• 観察した動作が、ドキュメント、テストの期待値、図、コメント、ダッシュボード、または以前の前提と矛盾している場合。
• システムに関する主張が、現在のコードやデータではなく、二次情報に基づいている場合。
• テストは合格するものの、本番環境や手動での動作に問題がある場合。
• 実際に何が起きるかを調べる前に、なぜそうなるのかを推測しようとしている場合。
• 判断が、モデル、スキーマ、またはメトリクスが現在も有効かどうかに左右される場合。

使用しない場面

• 編集を依頼された成果物が地図である場合（ドキュメント、図、仕様など）。その成果物こそがタスクの領土です。
• 今回のセッションですでに同じパスを確認している場合。その観察結果を再利用してください。
• 地図が信頼できる生成元である場合（コード生成された型、派生スキーマなど）で、乖離が主張されていない場合。
• 食い違いが判断に影響しない場合。記録して先に進んでください。
• 領土を確認した後で因果関係の仮説が競合する場合。科学的方法に切り替えてください。
• セキュリティの悪用手法を構築する場合。レッドチームを使用してください。このスキルで扱うのはモデルと観察結果の食い違いだけです。

手順

1. 地図を特定する。 信頼している表現を具体的に示します。どのドキュメント、テスト、メトリクス、図、コメント、または前提なのかを明記してください。言い換えではなく、主張を引用してください。
2. 領土の確認方法を特定する。 コードパス、実行時の値、クエリ、再現手順、最近の変更、またはライブメトリクスなど、その主張を証明または反証する観察内容を指定してください。
3. 情報源と鮮度を確認する。 地図の出所（作成者、生成方法、最終更新日）と、デプロイ、設定、データの変更に対して古くなっている可能性があるかを確認します。要約よりも、一次情報である最新の情報源を優先してください。
4. 領土を観察する。 実際のコードパスを読む、実行または計測する、実データをクエリする、あるいは動作を再現してください。シグネチャや名前だけから予測してはいけません。
5. 差分を記録して更新する。 領土が地図と矛盾する場合、リリース済みの動作については領土を優先します。食い違いを記録し、モデルを修正してから、修正箇所（コード、地図、またはその両方）を判断してください。地図に記載されていないパスも記録してください。次に問題が発生しやすい箇所です。
6. 解決したら止める。 具体的な観察によって主張が確認または否定されたら、同じパスの再確認を止めてください。

出力

Map: <claim + source + freshness>
Territory check: <what was inspected/run/queried>
Observation: <concrete result, not interpretation>
Delta: <aligned | map wrong | territory incomplete>
Updated model: <corrected understanding>
Action: <fix code | update map | no decision impact>
Uncovered: <paths no map covers>

検証

• 領土を観察せずに地図から推論した場合、古い二次情報を信頼した場合、またはどちらも確認せずに誤ったドキュメントにコードを合わせた場合は、検証は失敗です。
• 矛盾が解消されるか、判断に関係しなくなったら止めてください。
• 過剰適用の防止：地図を編集するとき、地図が生成元として信頼できる情報源であるとき、または食い違いが次のアクションに影響しないときに、システム全体を再検証してはいけません。