thinking-thought-experiment

思考実験

経験的な検証ができない場合は、規律ある反実仮想を実行します。変更は1つに限定し、条件を固定して、メカニズムを段階的に追跡し、含意の範囲を厳密に限定します。

使用する場面

• 障害、スケール、またはポリシーに関する挙動を、低コストで発生させたり測定したりできない場合（リージョン障害、負荷100倍、一方向のアーキテクチャなど）。
• 判断に多大なコストがかかる、または取り消しが難しく、実行前に思考上の追跡で破綻点を見つけられる場合。
• エッジケースを再現するコストが高くても、メカニズムの連鎖によって不足している制御を明らかにできる場合。

使用しない場面

• 低コストで実際のテストができる場合（負荷テスト、フラグ、クエリ、スパイクなど）→ テストを実行し、想像で代用しないでください。
• 敵対的なセキュリティ攻撃経路の分析 → 自由形式のシナリオではなく、レッドチームの構成を使用してください。
• メカニズムはすでにわかっていて、既知の事実に基づく判断だけが必要な場合 → 判断し、ドラマチックな話に仕立てないでください。
• 変数を1つに限定しない曖昧な「もしすべてがこうなったら」というブレインストーミング → 条件を絞り込むか、終了してください。

手順

1. 問いと切り分けを明示します。 主要な変数または反実仮想による変更を、厳密に1つだけ指定します。それ以外の条件はすべて固定し、対照となる世界として扱います。「それに加えて」という複数変数のシナリオは退けてください。
2. 初期条件を固定します。 システムの状態、負荷、構成、関係者、および変更しないものを明記します。別のエージェントが設定を再現できるほど、具体的な値を書いてください。
3. メカニズムを段階的に追跡します。 t0から、既知のコンポーネントとポリシーだけを用いて、何が故障し、待ち行列に入り、再試行され、または適応するのか、その理由とともに記録します。「その後、すべてが崩壊する」といった曖昧な表現は使わず、各段階に因果関係を示してください。
4. 不変条件と破綻点を抽出します。 何が維持されるか（不変条件）と、システムが要件（容量、正確性、安全性、UX）に最初に違反する段階を記録します。その連鎖を無効にする前提があれば明示します。
5. 含意の範囲を限定します。 連鎖によって正当化されるアクションや確認事項（上限、ガード、監視、再設計など）にだけ、洞察を結び付けます。切り分けの範囲を超える推測は、範囲外と明記します。
6. 結果を区別できる実際の確認方法を1つ示してから、終了します。 最も弱い因果関係について、それを確認または否定する最も低コストな観測や実験を示します。含意の範囲を限定した連鎖を1つ検討したら、そこで終了します。ある段階を今すぐ低コストでテストできる場合は、それ以上想像を続けず、そのテストに移ってください。

出力

思考実験の記録を出力します。

• question：検証対象の挙動または判断
• isolated_variable：対照となる世界と比べた単一の変更
• initial_conditions：固定する状態と変更しない条件
• consequence_chain：順序立てたメカニズムの各段階
• invariants：維持されるもの
• break_points：要件に最初に違反する点と重要な前提
• implication_bound：連鎖によってのみ正当化されるアクションや確認事項
• discriminating_check：弱い因果関係を確認または否定する、最も低コストな実際の観測

検証

• 切り分けの確認： 制御された条件を明示せず、自由に変化する変数が複数ある場合 → 無効です。設定し直してください。
• メカニズムの確認： 既知のコンポーネントやポリシーとの因果関係がない段階があれば → 書き直すか、削除してください。
• 含意の範囲： 連鎖から導かれない推奨事項は対象外です。
• 経験的検証の優先： 分析の途中で実際のテストが可能になった場合は、思考実験を中止してテストしてください。
• 過剰適用の防止： 再現可能な通常のデバッグや、レッドチームの脅威モデリングの代用として、このスキルを使わないでください。
• 終了条件： 独立した反実仮想を1つ設定 → 連鎖全体を追跡 → 含意の範囲を限定し、結果を区別できる確認方法を示す。この流れからシナリオを広げないでください。