# Design Deliberation > 妥当な答えが複数あり得る難しい決定のための Claude の進め方。アーキテクチャ・設計の選択、 「どの方式で行くか」、選択肢の比較、「X を採り入れるべきか」、トレードオフ / マージ可否 / 移行戦略の判断、ライブラリや実装ルートの選定などで使う。ユーザーが手順を明示的に頼まなくても、 「A と B を比較して」「Z はやる価値があるか」のように複数の道があり選択を誤るコストが実在する 場面では必ず発動すること。このスキルは、(1) ultracode / Workflow で広く深く発散調査して 選択肢を敵対的に評価し、(2) 結論を、ユーザーが既に用意している独立レビュアー（例: agmsg の codex メンバー）に反証前提でクロスチェックさせ、(3) すべての主張を根拠（file:line・実測・ 実シグナル。推測ではなく）に接地し、(4) 決定マトリクスを提示したうえで最終判断はユーザーに残す。 答えが一意な作業・機械的な編集・明らかに道が1本の場合には使わない。 ※答えがほぼ一意の技術選定や軽い比較質問では発動しない。研究・教育の構想や知の構造化の相談は tmllab-thinking-like-gendo が担当。 - Skill: `yosukeiida/design-deliberation` (Agent Skill) - Install (CLI): `npx skillmds@latest add yosukeiida/design-deliberation` - Raw SKILL.md: https://api.skillmd.com/api/skills/yosukeiida/design-deliberation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: YosukeIida (https://skillmd.com/u/yosukeiida) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/yosukeiida/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 を回す。賭け金に機械を合わせる。 - **無言でのクロスチェック省略** — 独立レビューを得られなかったなら、そう述べる。単一ソースの結論を 検証済みのように提示しない。