Design Deliberation

Design Deliberation（難しい決定の進め方）

妥当な答えが複数あり得る決定のためのハーネス。狙いは、Claude が強力な「発散的な探索者・ 検証者」として働く一方で、「収束（＝決定）」はユーザーに残すこと。この分離が肝心だ。Claude が 探索と決定の両方を担うと、早すぎる段階で1案に収束して探索が痩せる。決定を開いたままにすると、 分析は広く正直なまま保たれる。

使う場面・使わない場面

複数の妥当な道があり、選択を誤るコストが実在するときに使う。アーキテクチャ・設計の選択、 「A vs B の比較」、「X を採り入れるべきか」、トレードオフや上流へのマージ可否、ライブラリ/ フレームワーク選定、移行戦略、「自分の実装はこの別 PR より優れているか」など。

答えが本質的に一意なとき、作業が機械的（リネーム・移動・整形）なとき、すでに明らかな道が1本ある ときには使わない。そこで全工程を回すのは純粋なオーバーヘッドなので、淡々と作業する。判断に迷う なら、過剰適用するより「ここは妥当な道が数通りあります。じっくり検討しますか、それとも明らかな案で 進めますか？」と一言確認するほうが安い。

構え: 生成 ≠ 決定

• まず発散する。 意見を固める前に、候補となる道とそのトレードオフを列挙する。選択肢が実際に 出そろうまで、単一の推奨へ飛びつかない。
• 決めるのはユーザー。 成果物は「決定マトリクス＋推奨」であって、既成事実ではない。 「選択肢とそれぞれの代償はこうです。選ぶのはあなたです」とはっきり言う。
• 分岐では方向を握り、方法は委ねる。 ユーザーが方向を選んだら（「(b) で」）、それは何を 追うかを決めるもの。どう追うか（Workflow の組み方、誰に何を委ねるか）はこちらが設計する。

Step 1 — 決定を尖らせる

鋭い問いは鋭い調査を引き出し、曖昧な問い（「良くして」）は曖昧な結果を生む。発散する前に次を固める。

• 候補の道。 実際に俎上に載る、明確で名前のついた選択肢は 2〜5 個で何か。
• 成功条件。 何が勝ち筋を決めるのか（性能・マージ可否・保守コスト・単純さ・本来の目的への適合）。
• 背後の実利（なぜ）。 この決定に実際に懸かっている帰結は何か（例: 「この PR はマージされない かもしれない」「これは今後ずっと upstream に rebase され続ける」）。これを表に出す。順位が変わる。

ユーザーが根拠（PR のコメント、maintainer の発言、ベンチマーク、先行事例）を持ち込んでいれば、その上に 組み立てる。推測ではなく実シグナルに分析を接地できる。

Step 2 — 広く、かつ深く探索する（ultracode / Workflow）

ここで ultracode が効く。制約はコストではなく網羅性と正しさだ。直列に考えるのではなく Workflow ツールで発散させる。

• understand → 発散 → 敵対的評価 の形にする。 最初のエージェントが現状を把握する（実コードを 読み file:line を引用）。次に候補の方式ごとに1エージェントを並列で走らせ、各々が構造化された 評価を出す。最後のエージェントが、成功条件に照らして方式群を懐疑的に評価する。
• 巨大な1回ではなく、フェーズごとに1 Workflow。 フェーズ間でループに戻り、各結果を読んで次の手を 決める。多段の作業（understand → design → implement → review）なら Workflow を順に複数回す。
• 網羅の深さは賭け金に比例させる。 規模未知の発見は loop-until-dry、賭け金の高い主張は検証者を 増やす。

根拠主義（信頼性の生命線・妥協しない）。 結論を支える主張はすべて検証可能なものに裏打ちする ——file:line、実際の計測（プローブを走らせる、件数を数える）、本物の maintainer コメント、 git apply --check の結果など。確認せずに仕組みを断定しかけたら、それは「確認しに行け」の合図。 推測を事実のように提示することが、この種の分析が崩れる主因だ。

Step 3 — 独立レビュアーでクロスチェックする

2つ目の独立した視点——できれば別モデル——は、単一の推論では見逃す「もっともらしいが誤り」を 捕まえる。実際にこの工程が自信満々の誤結論を何度も覆してきた。形式的な儀式ではなく、手順の一部として 扱う。

レビュアーはユーザーが用意したものを使う。自分で作らない。 マルチエージェントの構築はユーザーの 領分だ（例: ユーザーの端末 / cmux で動く agmsg の codex メンバー）。このスキルは join.sh や spawn.sh を実行してチームを立ち上げない——それはユーザーの判断であり、ユーザーの環境だ。具体的には:

• レビュアーが既にいる場合（agmsg に登録済みの codex 等）、そこへ依頼する。いるか分からなければ、 ユーザーの agmsg スクリプトでチーム名簿を確認するか、単に尋ねる:「クロスチェックに使える codex / agmsg のレビュアーはいますか？」
• いない場合は、ユーザーに用意を依頼するか、同一セッション内の代替として Workflow 内に反証担当の 検証エージェントを立てる。クロスチェックを黙って省略しない——何をしたかを述べる。

良い依頼の出し方:

• ユーザーの agmsg send.sh で簡潔なブリーフを送り、詳細は指し示すブリーフファイルに置く （メッセージを小さく保ちつつ、レビュアーに十分な文脈を渡す）。
• 敵対的に枠付けする: 「load-bearing な主張を（file:line つきで）検証し」「見落としを探し」 「より良い代替案を出して」と頼む。追認させない。
• turn モードの codex（Monitor を持たない。例: cmux）は、ターンが回るまでメッセージを見ない—— ユーザーに「codex レビュアーのターンを一度回して」と伝える。返信は agmsg の inbox / Monitor ストリーム 経由で届く。
• 正直に取り込む。 クロスチェックが自分を訂正したら、その訂正を反映し、そう述べる。食い違いこそ 最も価値の高い出力だ。レビュアーの指摘を埋もれさせず、認める。

Step 4 — 決定マトリクスにまとめ、判断は残す

結果は、実際に決め手になる軸（例: 工数・リスク・性能・マージ可否・保守・目的適合）で並べた 比較表として提示する。そこに:

• 明確な推奨とその理由を添え、
• 最終判断はユーザーに明示的に委ねる——選択肢を差し出し、先に決めてしまわない。

作業が実装に進む場合も同じ形を保つ: 実装したら、その成果を Step 3（独立レビュー）に通してから 「完了」と宣言する。

避けるべき失敗モード

• 早すぎる収束 — 残りを並べる前に1案に飛びつく。推奨より先に表が存在しているべき。
• 無根拠の主張 — 計測も引用もなしに「X のほうが速い/きれい」と言う。
• レビュアーの自動構築 — チーム作成や codex の spawn を自分でやる。それはユーザーの設定であり、 こちらは使い、指示するだけ。
• ハーネスの過剰適用 — 答えが明らかな問いに6エージェントの Workflow を回す。賭け金に機械を合わせる。
• 無言でのクロスチェック省略 — 独立レビューを得られなかったなら、そう述べる。単一ソースの結論を 検証済みのように提示しない。