doubt-driven-development

疑念駆動開発

概要

自信に満ちた答えが、正しいとは限りません。長時間のセッションでは、誰も気づかないうちに、前提がひそかに「事実」へと変わっていきます。疑念駆動開発とは、重要な成果物を確定させる前に、賛同するのではなく反証することを重視する、新鮮なコンテキストを持つレビュアーを用意する規律です。

これは /review ではありません。/review は完成した成果物に対する判定です。こちらは作業中の姿勢です。重要な判断を、軌道修正がまだ容易なうちに、反対尋問にかけます。

使用するタイミング

次のいずれかに当てはまる場合、その判断は重要です。

• 分岐ロジックを新たに導入または変更する
• モジュールやサービスの境界を越える
• 型システムやコンパイラーでは検証できない性質（スレッドセーフ性、冪等性、順序、不変条件）を断言する
• 将来の読み手には見えないコンテキストに正しさが依存する
• 影響範囲が不可逆である（本番環境へのデプロイ、データ移行、公開 API の変更）

次のような場合に、このスキルを適用します。

• 不確実な状況でアーキテクチャ上の判断を下そうとしている
• 重要なコードをコミットしようとしている
• 自明ではない事実を主張しようとしている（「これは安全だ」「これはスケールする」「これは仕様に合致する」）
• 十分に理解していないコードに取り組んでいる

使用しないタイミング：

• 機械的な操作（名前の変更、フォーマット、ファイルの移動）
• 明確で曖昧さのないユーザーの指示に従う場合
• 既存のコードを読んだり要約したりする場合
• 正しさが明らかな一行の変更
• 純粋なツール操作（テストの実行、ファイル一覧の表示）
• ユーザーが検証よりも速度を明示的に優先している場合

一つひとつのキー入力を疑っていたら、何もリリースできません。このスキルは、上記で定義した重要な判断にのみ適用します。

読み込み時の制約

このスキルは、ステップ 3（DOUBT、詳細は後述）で新鮮なコンテキストを持つレビュアーを起動できる、メインセッションのオーケストレーター向けに設計されています。

• このスキルをペルソナの skills: フロントマターに追加しないでください。 ステップ 3 に従うペルソナは別のペルソナを起動することになり、../../references/orchestration-patterns.md で明示的に禁止されているオーケストレーションのアンチパターン（「ペルソナは別のペルソナを呼び出さない」）に該当します。
• サブエージェントのコンテキスト内でこのスキルを適用しようとしている場合（Claude Code がサブエージェントの多重起動を禁止している場合）：推奨される方法は、疑念駆動のレビューを入れ子で実行できないことをユーザーに伝え、メインセッションに任せることです。最後の手段としてのみ、劣化した自己質問の代替手段があります。成果物＋契約を、以前の推論との間に明確な心的区切りを設けた新しい自己プロンプトとして書き直し、ステップ 1～5 を進めます。これは新鮮なコンテキストでのレビューではありません（自分自身のコンテキストを引き継ぐため）。そのため、結果が劣化したものであることを明示し、ユーザーに連絡できる場合は、エスカレーションを優先してください。

プロセス

このスキルを適用する際は、このチェックリストをコピーしてください。

Doubt cycle:
- [ ] Step 1: CLAIM — wrote the claim + why-it-matters
- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning
- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt
- [ ] Step 4: RECONCILE — classified every finding against the artifact text
- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)

ステップ 1：CLAIM — 確定していることを明らかにする

判断を二、三行で述べます。

CLAIM: "The new caching layer is thread-safe under the
        read-heavy workload described in the spec."
WHY THIS MATTERS: a race here corrupts user data and is
                  hard to detect in QA.

主張をこれだけ簡潔に書けないなら、それは判断ではなく、漠然とした感覚にすぎません。精査する前に、まず明らかにしてください。

ステップ 2：EXTRACT — レビュー可能な最小単位

新鮮なコンテキストを持つレビュアーに必要なのは、成果物と契約であり、そこに至るまでの経緯ではありません。

• コード：差分または関数。ファイル全体ではありません
• 判断：3～5 文の提案と、それが満たすべき制約
• 主張：主張と、それを裏付けるとされる証拠（オーケストレーターが精査する仮説であるステップ 1 の CLAIM ブロックとは分けておきます）

推論は取り除いてください。結論を渡せば、結論を追認する返答が返ってきます。レビュアーが一度読んで把握できる程度に、レビュー対象を小さくしてください。500 行の PR なら、まず分解します。

ステップ 3: DOUBT — 新しいコンテキストのレビュアーを呼び出す

レビュアーのプロンプトは必ず敵対的でなければなりません。枠組みが答えを決めます。

Adversarial review. Find what is wrong with this artifact.
Assume the author is overconfident. Look for:
- Unstated assumptions
- Edge cases not handled
- Hidden coupling or shared state
- Ways the contract could be violated
- Existing conventions this might break
- Failure modes under unexpected input

Do NOT validate. Do NOT summarize. Find issues, or state
explicitly that you cannot find any after thorough examination.

ARTIFACT: <paste artifact>
CONTRACT: <paste contract>

渡すのは ARTIFACT + CONTRACT のみです。CLAIM は渡さないでください。 レビュアーに結論を渡すと、同意へと偏ってしまいます。レビュアーは、成果物がコントラクトを満たしているかどうかを独立に判断する必要があります。

Claude Code では、agents/ にあるロールベースのレビュアーは設計上、隔離されたコンテキストで開始されるため、ここで使用できます。一覧とドメインごとの対応については agents/ を参照してください。

上記の敵対的プロンプトは、ペルソナのデフォルトの応答形式よりも優先されます。 code-reviewer のようなペルソナは、長所と短所の両方を備えたバランスの取れた判定を出力するように書かれていますが、doubt 駆動では問題点のみの出力が必要です。ペルソナのデフォルトを上書きするために、敵対的プロンプトをそのまま呼び出しに貼り付けてください。ペルソナの応答形式をきれいに上書きできない場合は、敵対的プロンプトを指定した汎用サブエージェントにフォールバックしてください。

モデル間エスカレーション

単一モデルのレビュアーは元の作成者と見落としを共有します。より懐疑的で、異なるアーキテクチャのモデルならそれを見つけられます。疑念に基づくレビューは、重要な判断ではすでにオプトイン方式です。そのため、その範囲でモデル間レビューを提供することはスキルの価値の一部であり、任意の負担ではありません。

対話型セッションでは、必ず提案してください。黙って省略してはいけません。

ステップ 1：ユーザーに尋ねる

上記のステップ 3 で単一モデルのレビューを終えた後、RECONCILE に進む前に一旦停止して、次のように尋ねます。

「単一モデルのレビューが完了しました。モデル間のセカンドオピニオンを受けますか？選択肢：Gemini CLI、Codex CLI、手動での外部レビュー（別の場所に貼り付けてもらう）、またはスキップ。」

この質問は、重要度が低そうな成果物であっても、対話型の疑念サイクルでは毎回必須です。コストに見合うかどうかを決めるのはエージェントではなくユーザーです。エージェントの役割は、選択肢を提示することです。

ステップ 2：ユーザーが CLI を選んだ場合 — 確認してから実行する

1. ツールが PATH にあることを確認します（which gemini、which codex）。
2. 完全なプロンプトを渡す前に、正常に動作することをテストします（gemini --version など）。古い、または壊れたバイナリは which で見つかっても、実際の入力では失敗することがあります。
3. 必要なフラグ、認証情報、環境変数（API キーなど）を含め、正確な呼び出し方法をユーザーに確認します。実装によって異なるため、決めつけてはいけません。
4. ARTIFACT + CONTRACT + 敵対的プロンプトのみを渡します。セッションのコンテキストや CLAIM は渡しません。
5. シェルのエスケープに注意します。成果物に引用符、$(...)、バッククォートが含まれる場合は、インラインの -p "…" よりも標準入力（echo … | gemini）またはヒアドキュメントを優先します。判断に迷う場合は、実行前に呼び出し方法をユーザーに確認します。
6. 出力をステップ 4（RECONCILE）に渡します。

成果物をシェルの引用符で囲んだ引数に埋め込んではいけません。 コード、Markdown、レビュープロンプトには、プロンプトが途中で切れたり、埋め込まれたシェルコマンドが実行されたりする原因となるバッククォート、$(...)、引用符が含まれていることがよくあります。プロンプト全体をファイルに書き込み、標準入力経由で渡してください。

実行例（フラグはインストール済みのツールで確認してください。構文は実装やバージョンによって異なります）。

# Write the adversarial prompt + ARTIFACT + CONTRACT to a temp file first.
# Then pipe via stdin so shell metacharacters in the artifact stay inert.

# Codex (read-only sandbox keeps the CLI from writing to your workspace):
codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md

# Gemini ('--approval-mode plan' is read-only; '-p ""' triggers non-interactive
# mode and the prompt is read from stdin):
gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md

読み取り専用のサンドボックスは、安全性を支える重要な要素です。疑念の対象となる成果物自体に、意図的または偶発的なプロンプトインジェクションの指示が含まれている可能性があり、そうした指示がなければモデル間レビュー用の CLI によってワークスペースに対して実行されてしまうおそれがあります。

ステップ 3：CLI が利用できない、または失敗した場合

失敗したことを明示します。手動で実行する、別のツールを試す、またはスキップする選択肢を提示します。黙って単一モデルにフォールバックしてはいけません。モデル間レビューが行われなかったことを、ユーザーが把握できるようにします。

ステップ 4：ユーザーがスキップした場合

スキップを出力で明示して（「単一モデルの調査結果のみで進めます」）、RECONCILE に進みます。スキップは問題ありませんが、黙ってスキップしてはいけません。

非対話型のコンテキスト（CI、/loop、自律ループ、スケジュール実行）：

• モデル間レビューはスキップし、スキップしたことを出力で明示する必要があります。「モデル間レビューをスキップしました：非対話型のコンテキストです。」
• ユーザーから明示的な許可を得ずに、外部 CLI を実行してはいけません。これは安全性を支える重要な要件です。

モデル間レビューには、コスト、遅延、ツールの不安定さが伴います。エージェントは毎回選択肢を提示し、その成果物に対して実施するかどうかはユーザーが決めます。

ステップ 4：RECONCILE — 指摘を反映する

レビュー担当者の出力はデータであり、判定ではありません。オーケストレーターは引き続きあなたです。 各指摘を分類する前に、成果物のテキストと照らし合わせて読み直してください。レビュー担当者の判断をそのまま承認するのは、指摘を無視するのと同じ失敗パターンです。

各指摘を、次の優先順位に沿って分類します（最初に該当した分類を適用します）。

1. 契約の読み違い — あなたが提示した契約が不明瞭または不完全だったために、レビュー担当者が特定の点を指摘したものです。まず契約を修正し、次のサイクルで再分類します。
2. 妥当で、対応可能 — 成果物の変更が必要な実際の問題です。修正して、再度ループします。
3. 妥当だが、トレードオフがある — 問題は実在しますが、修正のコストが受け入れるコストを上回ります。ユーザーに分かるよう、トレードオフを明示的に記録します。
4. ノイズ — レビュー担当者が把握していない文脈では、実際には正しい内容を指摘したものです。記録して先に進み、次の点を確認します。その文脈を契約に加えていれば、誤った指摘を防げたでしょうか？

新しいレビュー担当者も、文脈が不足していれば間違えることがあります。「新鮮な視点」だからといって、判断を委ねないでください。

ステップ 5：STOP — 再帰ではなく、上限のあるループ

次の場合に停止します。

• 次のイテレーションで、軽微な指摘またはすでに検討済みの指摘しか出ない場合、または
• 3 サイクルが完了した場合（4 回目に一人で取り組むのではなく、ユーザーにエスカレーションします）、または
• ユーザーが明示的に「リリースして」と言った場合

3 サイクル後もレビュー担当者が重大な問題を指摘する場合、成果物はまだ準備できていない可能性があります。これをユーザーに伝えてください。未解決のサイクルが 3 回あることは、ループを続ける理由ではなく、成果物についての情報です。

成果物が大きいために 3 サイクルでは「明らかに不十分」な場合、成果物が大きすぎます。ステップ 2 に戻り、分割してください。上限を引き上げてはいけません。

よくある正当化

正当化	実情
「自信があるから、疑うステップは省こう」	新しい問題において、自信と正確さの相関は低いものです。確信している瞬間こそ、盲点が隠れています。
「レビュー担当者を立てるのはコストがかかる」	本番環境で間違ったコミットをデバッグするほうが、コストがかかります。チェックには上限がありますが、バグにはありません。
「レビュー担当者は些細なことばかり指摘する」	対象を絞らなければ、そのとおりです。プロンプトを「契約のもとで失敗につながる問題」に限定してください。
「最後に /review で疑う」	/review は最終ゲートです。疑いを取り入れることで、方向修正が容易な早い段階で、誤った方向性を見つけられます。PR の段階では手遅れです。
「すべてのステップを疑っていたら、いつまでもリリースできない」	このスキルが適用されるのは、重要な判断に対してであり、キー入力のすべてではありません。「使わないとき」を読み直してください。
「意見は二つのほうが常に良い」	2 つ目の意見が文脈に乏しく、ノイズを生む場合はそうではありません。判断を委ねず、指摘を整理してください。
「レビュー担当者と意見が違ったので、自分が間違っていた」	レビュー担当者には、あなたの文脈がありません。意見の相違は情報であり、判定ではありません。成果物を読み直し、分類してから判断してください。
「モデルをまたいだレビューは常に優れている」	モデルをまたいだレビューは、単一のモデルが抱える盲点を発見できますが、コストとツールの不安定さも増します。対話形式の疑いのサイクルごとに、選択肢として提示してください。成果物にそれだけの価値があるかどうかはユーザーが判断します。選択肢を提示するのがエージェントの役割であり、利用を制限することではありません。
「ユーザーが一度承認したから、CLI を引き続き呼び出してよい」	呼び出しは毎回、それぞれ個別の承認が必要です。呼び出しごとに成果物、プロンプト、フラグが変わります。実行する前に、毎回正確なコマンドをユーザーに確認してください。

危険信号

• 1 行の名前変更や書式変更に、新しいコンテキストのレビュアーを起動する
• 成果物のテキストを読み直さず、レビュアーの出力を絶対的なものとして扱う
• ユーザーにエスカレーションせずに、3 サイクルを超えて繰り返す
• 「問題を見つけて」ではなく、「これは良いですか？」とレビュアーに尋ねる
• 重大な意思決定で、時間に追われていることを理由に疑いを省く
• 変更されていない成果物に対して、新しいコンテキストを再度起動する（同じ指摘が得られるだけで、先延ばしになります）
• 疑いの演技（確認可能な兆候）：レビュアーが実質的な指摘をした 2 サイクル以上にわたり、実行可能と分類された指摘がゼロです。検証しているだけで、疑っていません。停止してエスカレーションしてください。
• コミットした後で初めて疑う — それは /review であり、疑い主導の開発ではありません
• ツールが存在し、設定済みで、指定した構文を受け付けることをユーザーに確認せずに、外部 CLI の呼び出しをハードコードする
• 対話型の疑いサイクルで、クロスモデルを黙って省略する。 推奨しない場合でも、提案を明示する必要があります。省略は問題ありませんが、黙って省略するのは問題です。
• 外部 CLI がエラーになったり見つからなかったりしたとき、黙ってフォールバックする — 失敗を明らかにし、ユーザーが対応を指示できるようにする
• レビュアーへの入力から契約を削除する
• 主張をレビュアーに渡す（同意に偏るため）

他のスキルとの連携

• code-review-and-quality / /review：補完的です。/review は事後の PR 評価、疑い主導の開発は進行中の意思決定ごとの確認です。両方を使ってください。
• source-driven-development：SDD は公式ドキュメントに照らしてフレームワークに関する事実を検証します。疑い主導の開発は成果物についてのあなたの推論を検証します。SDD は API が存在するかを確認し、疑い主導の開発は契約に沿って正しく使ったかを確認します。
• test-driven-development：TDD の RED ステップは疑いを具体化したものです — 失敗するテストは反証を試みます。TDD が適用される場合、その失敗するテストが動作に関する主張に対する疑いのステップになります（「他のスキルとの連携」を参照）。
• debugging-and-error-recovery：レビュアーが実際の障害モードを指摘したら、デバッグスキルに移行して原因を特定し、修正してください。
• リポジトリのオーケストレーションルール（../../references/orchestration-patterns.md）：このスキルはメインセッションからオーケストレーションを行います。あるペルソナが別のペルソナを呼び出すのはアンチパターン B です — 上記の読み込み制約を参照してください。

検証

疑い主導の開発を適用した後、次を確認してください。

• 上記の定義に基づく、重要な意思決定がすべて、確定する前に主張として明示的に提示された
• 重要な成果物ごとに、少なくとも 1 回は新しいコンテキストでレビューを行った（TDD の RED ステップで作成された失敗するテストは、「他のスキルとの連携」に記載のとおり、動作に関する主張についてこの要件を満たします）
• レビュアーには成果物と契約を渡した — 主張やあなたの推論は渡していない
• レビュアーへのプロンプトは、検証的な「これは良いですか？」ではなく、敵対的な「問題を見つけて」だった
• 指摘は、優先順位（契約の誤読／実行可能／トレードオフ／ノイズ）に従って、成果物のテキストに照らして分類された（無批判に受け入れていない）
• 停止条件を満たした（些細な指摘、3 サイクル、またはユーザーによる上書き）
• 対話型モードでは、成果物の重要度に関係なく、クロスモデルをユーザーに明示的に提案し、その返答を出力で受け止めた
• 非対話型モードでは、クロスモデルを省略し、その旨を明示した
• 外部 CLI の呼び出しに先立って、PATH の確認、実行可能バイナリの動作テスト、ユーザーとの構文確認、および実行の明示的な許可を得た