---
name: derive-optimal-solution
description: Generic thinking protocol for deriving optimal solutions through iterative self-checking. Invoke BEFORE searching within the given problem space whenever the user asks for advice, judgment, evaluation, or choice. Reframes the problem, generates options, evaluates trade-offs, runs a self-answer check (does this answer the user's actual question at the right granularity, reach upstream, match expectations, offer non-obvious value?), and loops back to upstream tracing or same-level reframing if the check fails — until convergence. Applies across any domain — technical, process, organizational, decision-making, career. Triggers when the user uses evaluation or reconsideration language ("which is best", "root cause", "is this really needed", "sustainable long-term", "ほんとうに", "そもそも", "最善は", "根本は", "筋が良い"), when validating the soundness of someone's proposal from multiple perspectives, when the problem spans multiple layers (tech / process / org / regulation / UX / cost), or when clear trade-offs exist.
---

# Derive Optimal Solution

相手が設定した問題空間の中で解を探すのではなく、**問題を再構成し、選択肢を棚卸しし、評価し、最適解を推奨する** 汎用思考プロトコル。ドメイン非依存。

## 典型的な失敗

相手が「A という問題があるので B という対策を考えている」と聞いてくる → A を所与として B の実装詳細に踏み込む → A を発生させている上流 C を見逃す (C を変えれば A も B も不要になる可能性)。**問題は定義ではなく解釈の対象**として扱う。

## 典型的な視点シフト

| 相手が設定した問題 | 上流の問題 |
|---|---|
| API が遅い | データモデルが深い 1:N:N |
| テストが壊れる | 依存方向が逆転 |
| バグ修正が連鎖する | 責務分割がモジュール境界と不一致 |
| 会議が長い | 議題と決定者が事前未定 |
| チームが疲弊 | 目標とインセンティブが矛盾 |
| リリース事故が続く | 本番と開発の環境差がコードで吸収 |
| 採用がうまくいかない | 基準とオンボーディングが別人格 |
| 売上が伸びない | 顧客セグメントと提供価値が不整合 |
| 方針がぶれる | 決定者と責任者が分離 |

**パターン**: 症状は末端で観測、原因は上流の選択・整合にある。

## 適用の深さ

問題のサイズに応じて深さを調整する:

- 小さな相談: Step 1〜3 のみ軽く。Sub Agent は使わない (オーバーヘッド負け)
- 中規模: 全ステップ通すが各 1〜2 案。Sub Agent は任意
- 大きな判断 (下記のいずれかに該当): 厳密に全ステップ、5〜7 案、採点表、不確実性明記。**Step 4 / 5 / 7 は Sub Agent で並列化**
  - 案を 5 案以上生成する想定
  - 影響範囲が 2 層以上にまたがる (技術なら UI / ドメイン / DB / インフラ、組織なら個人 / チーム / 組織 / 契約)
  - 不可逆な意思決定が絡む (スキーマ変更・契約締結・組織再編・データ移行 等)
  - 関係者 3 人以上が結論を見る (PR レビュー・設計レビュー・経営判断 等)

「中規模か大規模か迷ったら大規模側に倒す」。1 つでも該当したら大規模扱い。「中規模として直列で済ます」を裁量補完で選ばない。

## 思考プロトコル

Step 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10 の順。解決策を書く前に必ず通す。スキップ項目があれば提示保留。

### 大前提: 問いの粒度を変えない

「上流に遡る」は相手が **問うた粒度の中で** の上流遡及。粒度のメタ変換 (技術問 → 行動選択肢、設計問 → 意思決定構造) は禁止。

**判定**: 推奨案に「実装する / コメントする / 別 issue を立てる / 寝かせる / 人に委ねる」のような **行動選択肢 (action item)** が混じったら粒度ずれの兆候。元の粒度で再考。例外は相手が明示的に「行動選択肢を出して」「次の一手を」と問うた場合のみ。

**ステップ → 出力節の対応**: Step 1〜3 → 「問題の再構成」、Step 4〜5 → 「選択肢の棚卸し」、Step 8 → 「評価軸」、Step 9 → 「採点表」。

**Step 4 vs Step 8 の境界**: Step 4 は **問題の性質** を変える (「誰の問題か」「境界は」)、Step 8 は **案の性質** を測る (「根本に届くか」「可逆か」)。同じ語が両方に登場したら:

| 概念 | Step 4 (問題の性質) | Step 8 (案の性質) |
|---|---|---|
| 可逆性 | 問題自体が今やらないと不可逆か | 案が失敗時に戻せるか |
| 主体 | 誰のための問題か | 扱わない |
| コスト | 所与の予算制約は本当か | 案の実行・維持コスト |
| 前例 | 類似事例でどう解かれたか | 扱わない |

### Step 1: 症状 vs 構造を切り分ける

相手は「症状」を話している可能性がある。症状 ≠ 問題。

- 症状例:「エラーが出る」「会議が長い」「チームが疲弊」「売上が伸びない」
- 構造例:「権限設計が破綻」「意思決定の所有者不在」「目標とインセンティブが逆行」「顧客セグメントと提供価値が噛み合わない」

**書き下す**: 相手の問題 X は症状か、構造か。

### Step 2: 上流に 2 段遡る

「なぜ」を 2 回以上。1 回で止まらない。

- なぜ発生する? → 直接原因
- なぜ直接原因がある? → **上流の要因 / 設計 / 前提**
- 上流を変えれば問題が消える可能性があるか?

**書き下す**: 上流の要因 X は何か。X を変える選択肢は存在するか。

### Step 3: 相手が所与として書いた前提を疑う

相談文には「X は所与」「Y は既に決まっている」と明示されていない前提が多数含まれる。**相手が方針として書いた語句 (動詞・副詞・モーダル) を機械的に抜き出し、各前提に「これは本当に必要か?」を 1 つずつ当てる**。

Step 2 の上流遡及が「なぜ?」で縦に掘るのに対し、本ステップは「所与の前提を機械的に洗い出して疑う」横の操作。上流遡及だけでは相手の提案空間に閉じ込められるため独立させる。

判定手順:

1. 相談文から「相談者が採用予定と書いた方針」を語句単位でリストアップ (最低 3 つ)。抽出対象は **動詞・目的語**(毎日実行する / 同期する / 全件走査する / 事前計算する 等) **+ 副詞・モーダル** (「とりあえず」「一応」「念のため」「様子見で」「念のため」「まずは」 等)
   - 副詞・モーダルは単独で抽出するのではなく **隣接する動詞とセット** で扱う (例: 「とりあえず 1on1 を増やす」→ 抽出: `とりあえず増やす`)。副詞・モーダルは「**根拠の弱さの証拠**」として扱う (「とりあえず」は仮説不在のシグナル、「念のため」は影響範囲未確認のシグナル)
2. 各方針について根拠が示されているか確認 (法令 / 契約 / 仕様書 / 既存システム制約 / 数値実測 等)
3. 根拠が弱い or 不明な前提が 1 つでもあれば、**その前提を変える案を Step 5 の案リストに必ず含める**

**「根拠の弱さ」の判定基準** (Yes / No の 2 値):

| 判定 | 条件 |
|---|---|
| 強い根拠 | 相談文内に法令 / 契約 / 既存仕様書 / 物理的制約 / 数値根拠 のいずれかが明示されている |
| 弱い根拠 (疑うべき) | 上記が相談文内に書かれていない。「こうしています」「こう進めています」と方針だけ書かれているもの |

境界が曖昧なら **弱い側に倒す** (前提を疑う案を 1 つ Step 5 に足すだけで済み、不要なら採点で下位に落ちる)。

この前提疑いで見つかる案は、しばしば最も軽く (Step 6 の重さ 1 相当) かつ根本的な解になる。スキップすると相手の提案空間に閉じ込められる。

**例**: 「毎日バッチで全件再集計する」と相談文に書いてあったら、「毎日」「全件」は所与か? 根拠が示されていなければ、「差分だけ・イベント駆動で更新する」を Step 5 の選択肢に必ず含める。

### Step 4: 問題空間の境界を広げる (6 次元)

相手の問題空間の**外側**に候補があるか。各次元で問い直す:

| 次元 | 問い |
|---|---|
| 時間軸 | 短期 / 中期 / 長期で答えが変わるか |
| 主体 | 誰が / 誰のために / 誰と解くか |
| スコープ境界 | 境界を引き直せば問題が消えないか |
| 前提条件 | 所与の制約は本当に必要か (規制・予算・技術・関係者) |
| 抽象レベル | 症状 / 構造 / 原理のどこで解くか |
| 業界・前例 | 既知の解・類似事例 (業界 / 同種プロダクト / 自組織) |

(可逆性・漸進性は Step 8 の評価軸で扱う。Step 4 は問題の見方を変える)

非技術文脈の例:

- 時間軸: 「今年の売上問題」を「3 年後の市場位置取り」と解釈し直すと答えが変わる
- 主体: 「エンジニアの負荷問題」を「採用市場での雇用主競争力」として解くと選択肢が広がる
- 前提条件: 「Slack で決めるべき」と言われた議論を「そもそも非同期でいいか」から問う

**並列化** (大きな判断時): 6 次元を 2〜3 Agent に束ねて分散。束ね方例: `時間軸 + 抽象レベル` / `主体 + スコープ境界` / `前提条件 + 業界・前例`。各 Agent に担当次元ごとに 2〜4 候補を根拠付きで出させる。

### Step 5: 案を 3 つ以上生成する

最低 3 案、できれば 5〜7 案。比較軸が生まれる。

**「枠組みの外側にある選択肢」の判定テスト**: 候補案を「相手の提案と並べたとき、以下のどれか 1 つが異なるか」で判定する。どれも同じなら内側、1 つでも異なれば外側。

1. **解く場所** (どの層 / どの制御点で解くか) が違うか
2. **抽象レベル** (症状対処 / 構造変更 / 原理の再定義) が違うか
3. **時間軸** (今実行する / 先に検証する / 延期 / やらない) が違うか

**「解く場所」は層 + 制御点の 2 段で捉える**:

- **層**: どの責務領域か (技術なら UI / アプリ / DB / インフラ、非技術なら個人 / チーム / 組織 / 契約)
- **制御点**: 層の中でどの要素を操作するか (構造変更 / 制約変更 / 入力を絞る / 処理変更 / 境界を引き直す)

同じ層に見えても制御点が違えば別の解。特に **「構造を新しく作る」より「既存の入力・前提を絞る」** ほうが大抵コストが低い — 層を決めたら「この層で触れる制御点を全部挙げたか?」を自問。

単なる「相手が思いつかなかった具体案」(3 軸すべて同じ) は **内側**。

**Step 4 (スコープ境界) との違い**: Step 4 は「問題の見方を変える」(問題側)、Step 5 の外側は「解の出し場所を変える」(解側)。

**生成時の指針**:

- **「どこで問題を解くか」** を変えて多様化 (原理 / 構造 / 運用 / 契約 / 人事 / 外部依頼 / やらない)
- 相手の案があれば**変形案**を含める
- **却下された案の改善版**がないか検討 (状況が変わっている可能性)
- **「そもそもやらない / 放置 / 延期」**を必ず入れる

**並列化** (大きな判断時): 層ごとに 1 Agent で並列生成。技術例: UI / ドメイン / DB / 運用 の 4 Agent (「やらない / 延期」は運用 Agent に含む)。各 Agent に「この層で触れる制御点を全部挙げる」と指示。本体が全案を集約して Step 6 へ。

### Step 6: 解の「重さ」で優先順位をつける

Step 5 で生成した案を、**加える責務の重さ** で並べる。軽いほうから優先検討。ドメイン非依存の 5 段階 (軽い順):

1. **既存の要素に状態を足す** — 属性を 1 つ追加し、既存の判定条件を書き換えるだけ
2. **既存の入力や前提を絞る** — 新しい仕組みは作らず、既存処理への入力や適用範囲を限定
3. **既存の要素に情報を複製する** — 値の複製・コピー保持。同期責務が発生
4. **新しい要素や仕組みを足す** — 新エンティティ / 新テーブル / 新フロー / 新ルール / 新役割
5. **既存の原則や境界に例外を足す** — 既存の標準ルール・共通規約・取り決めに分岐や特例 (多段防御や一貫性を損なうリスク)

ドメイン別読み替え (技術例): 1 = 列/フラグ追加、2 = クエリ条件・スコープを絞る、3 = 非正規化列・キャッシュ、4 = 新テーブル・新サービス、5 = 共通規約に例外ルートを足す。プロセス・組織・意思決定でも同じ 5 段階で読み替え可 (1 = 既存への属性付与、2 = 範囲を絞る、3 = 情報複写、4 = 新役職・新会議体、5 = 既存原則に例外)。

**原則**: 同等効果なら **軽い案を主推奨**。重い案はバックアップ扱い。重さ 3 以上を主推奨にするなら「軽い案では解けない具体的な制約」を明示する (示せないなら軽い案へ)。

重さの違いが効く軸: 影響範囲 (新仕組みは全体回帰 / 状態追加は局所) · 移行コスト (複製は過去遡及 / 状態追加はデフォルト値) · 運用責務 (新フローは人手 / 絞り込みは場所明確) · 可逆性 (新仕組みは物理残存 / 状態や条件は書き換え可)。

### Step 7: 相手の提案の帰結を予測する

相手は **自分の提案のメリット** は説明するが、**実装後に発生する問題** は見えていない (だから相談してきている)。ここで **相手の代わりに帰結を予測** する。「相手の提案をそのまま採用したら 3 ヶ月後・1 年後に何が起きるか」。

**視点** (最低 3 つ検討):

- **スケール時**: 対象が N 倍 (画面・エンドポイント・利用者・拠点 等) に増えたとき
- **変更時**: 関連する要件・仕様が変わったとき (新機能・新ユースケース)
- **新メンバー参入時**: 設計を知らない人が引き継いだとき
- **時間経過時**: データ量・履歴・案件数が蓄積したとき
- **例外ケース発生時**: 想定外の入力・異常系 (タイムアウト・部分失敗・競合 等)
- **関連領域への波及**: 同じパターンが別のエンティティ・別ドメインで必要になったとき

**並列化** (大きな判断時): 6 視点を 3〜6 Agent に分散 (1 Agent 1〜2 視点)。各 Agent に「この視点で帰結を予測し、受け入れ可能 / 受け入れ難いを判定。他視点・総合判断はしない」と指示。

**帰結の評価**: 各帰結を「受け入れ可能 / 受け入れ難い」で判定。**1 つでも「受け入れ難い」があれば、相手の提案は症状対処にとどまっている可能性**。その場合:

- Step 2 の上流遡及に戻る (なぜその帰結が起きるか = 上流の設計が不適切)
- Step 5 で、その帰結を **構造的に発生させない** 案を生成
- Step 9 の採点表で、その帰結への耐性を評価軸に加える (例: 「帰結 X への脆弱性」)

**受け入れ難い帰結の典型パターン**:

- **適用忘れの再発**: 「全箇所に同じ規約/ルール/チェックを守らせる」系。新箇所追加で漏れる
- **二重管理の同期責務**: 「元データと複製データの両方を持つ」系。片方の更新忘れ
- **暗黙の契約**: 「コードを読んでも理由が分からない」系。新メンバーが壊す
- **多段防御の破壊**: 「既存の標準ルールに例外を足す」系。重ねて担保していた一貫性の層を壊す
- **過去データへの遡及困難**: 「これから作るデータだけ対応」系。既存データに同じ問題が残る

これらが予測できたら相手の提案は **主推奨にしない**。Step 5 に戻って帰結を発生させない案を生成。

### Step 8: 評価軸を明示する

「筋が良い」を曖昧にしない。文脈に応じて 3〜6 軸選ぶ:

- **根本性**: 症状ではなく原因に届くか
- **堅牢性**: 抜け漏れ・不確実性・人の入れ替わりに強いか
- **耐久性**: 時間経過・環境変化・要件拡大に耐えるか
- **コスト**: 実行・維持・学習・移行の総量
- **可逆性**: 失敗時に戻せるか
- **明快性**: 当事者外・新参者から理解できるか
- **多段防御**: 1 層破れて別が止まるか (安全重視文脈)

軸選択の指針: 安全性重視なら堅牢性 + 多段防御、スピード重視なら可逆性 + コスト、長期運用なら耐久性 + 明快性。

### Step 9: 採点表で比較する

軸 × 案の表。✅ / ⚠️ / ❌ の 3 段階。

- **相手の提案を必ず 1 列含める** (自分の推しを通すための表にしない)
- 表に落ちない価値 (美学、一貫性、政治的制約) は補足テキストで
- **集計スコアを作らない**。軸の重要度は文脈依存で一律ではなく、単純合計は質的判断を歪める。パターンを可視化する道具であって点数で順位をつける道具ではない

### Step 10: 自答チェックと反復ループ

推奨を出す前に以下 7 問を自問。**1 つでも No なら出力せず、上流ループか横展開ループに入って Step 5 以降を回し直す**。

判定は **Yes / No の 2 値**。「部分的 Yes」「条件付き Yes」は作らない (グレーゾーンは構造的に No 扱い)。

| # | 自答 | Yes 判定の客観基準 | No なら |
|---|---|---|---|
| Q1 | 相手が問うた **粒度** の問いに直接答えているか? | 推奨案リストに行動選択肢 (action item) が混じっていない | 横展開ループ |
| Q2 | **症状ではなく上流** に届いているか? | Step 2 で遡った上流 (2 段目以上) を直接変える案が、推奨または採点表上位に含まれる | 上流ループ |
| Q3 | 相手の **暗黙の期待** と整合しているか? | 相手が問いで言及・前提化した語 (「再検証」「比較」「最適」等) すべてを成果物中で扱っている | 横展開ループ |
| Q4 | **新規性** があるか? | 推奨案または却下対象に、相手の問いに直接書かれていなかった案・観点・制約が 1 つ以上含まれる | 横展開ループ |
| Q5 | Step 7 で予測した **受け入れ難い帰結** を回避しているか? | 受け入れ難い帰結が推奨案採用で構造的に発生しない (または局所化) と明示。相手の提案を主推奨にするなら受け入れ難い帰結が 1 つも存在しない | 上流ループ |
| Q6 | 主推奨より **軽い案 (Step 6 の重さ分類で小さい数値)** で、**同等以上の効果**を持つ案が候補リストに存在しないか? | 主推奨の重さ ≦ 他のすべての「主要評価軸で同等以上」の案の重さ。「同等効果」の判定基準は **相談者が問題として挙げた症状 (エラー / 苦情 / ボトルネック) が解消されるか** (一般的な美しさや理想度ではない) | 横展開ループ (重さ原則の再適用) |
| Q7 | 相手が **所与として書いた前提** を Step 3 でリストアップし、そのうち **根拠が弱い前提を変える案** が候補リストに含まれているか? | 相手の方針動詞 3 つ以上を抽出し、根拠が弱い前提それぞれに対して「その前提を変える案」を Step 5 に含めた | 横展開ループ (Step 3 に戻る) |

すべて Yes なら出力。Q1〜Q7 の判定結果は **出力テンプレートの `## 反復記録` 節に逐項で記載する**(各 Q について Yes/No と理由 1 行)。記載がないことは Q1〜Q7 を Yes 判定する根拠にならない。形式的通過を防ぐためのハードルなので省略しない。

#### 上流ループ (Upstream Loop)

Q2 / Q5 で「もっと深く遡れる余地がある」と判断した場合:

1. Step 2 の「なぜ」を **もう 1 段増やす** (3 段目・4 段目へ)
2. 新しい上流が見つかったら、それを反映して Step 4 以降をやり直す
3. **無意味判定** (以下なら打ち切って横展開ループへ):
   - **粒度逸脱**: 新上流が相手の問うた粒度の外側 (技術問なのに経営方針・法改正に到達)
   - **行動不能**: 抽象的すぎてその層で行動可能な案が出ない
   - **スコープ越境**: 相手の権限・影響範囲の外側
   - **重複**: 1 段増やした上流が Step 2 で既に言及済みと本質的に同じ
4. 上流追跡で新案を 1 つも生成できなかったら打ち切り

#### 横展開ループ (Lateral Loop)

Q1 / Q3 / Q4 / Q6 / Q7 で「粒度や捉え方が合っていない」、または上流ループが無意味になった場合:

1. Step 1 の「症状か構造か」を **見直す**
2. Q7 が No なら **Step 3 に戻り** 前提を機械的に再リスト化する。それ以外は Step 4 の 6 次元のうち、**まだ問い直していない次元** を選ぶ
3. 問題の再構成を **書き直して** Step 5 に戻る

#### ループの打ち切り基準

- **収束**: Q1〜Q7 すべて Yes になった時点で出力
- **発散打ち切り**: 同じシナリオで **3 回ループ** しても自答チェックが通らない場合 → 最善を尽くした保守的推奨として出力 + 不確実性節に「自答チェック未通過: Qn (理由)」を明記
- **振動打ち切り**: 上流ループ → 横展開ループ → 上流 → 横展開 と振動する場合、3 サイクル目で打ち切る (問題自体が ill-defined の可能性)

#### 各ループの記録

ループに入ったら最終出力の「不確実性」節の前に追記:

```
## 反復記録
- ループ 1 (上流): Q2 が No → 上流に 1 段遡って X を発見、案 G を追加
- ループ 2 (横展開): Q1 が No → 主体を変えて再構成、案 H を追加
- 収束: Q1〜Q7 すべて Yes
```

推奨の **過程の透明性** が出力に残り、判断の妥当性を後から検証できる。

## Sub Agent 並列化の方針

独立した複数視点の深掘りが要る箇所は、本体で順次やると先の視点に引きずられて後が浅くなる。`general-purpose` Sub Agent に分散。

| 並列化する | 並列化しない |
|---|---|
| Step 4 (6 次元の境界拡張) | Step 1〜3 (思考の連鎖が必要) |
| Step 5 (「解く場所」別の案生成) | Step 6 (全案を見比べる) |
| Step 7 (帰結予測 6 視点) | Step 8 / 9 (本体で統合) |
| | Step 10 (軽量) / 上流ループ・横展開ループ (収束指向) |

**渡し方の原則** (全並列箇所共通):

- 自己完結プロンプト: 問題の再構成・上流・担当する次元/視点を明示 (会話履歴は見えない前提)
- スコープ限定: 「この次元/視点だけ」。推奨・総合判断はさせない
- 出力形式指定: 箇条書きで候補案 or 帰結を返す
- 1 メッセージ内で複数 Agent を同時発行

## アンチパターン

- **即座に賛成・反対しない**: 全ステップを通さず返答しない
- **自説を防衛しない**: 自分の案 A と相手の案 B を並べて比較。自説を捨てる覚悟を持つ
- **1 案で答えない**: 比較可能な 3 案以上。最終推奨は 1 つで良い
- **ドメインに閉じない**: 技術相談でもプロセス・組織・契約・外部委託・やらない、も選択肢
- **前提を所与にしない**:「規制が」「上司が」「慣例で」と言われても、今も有効かを問う
- **却下案を無批判に受け入れない**: 却下理由が弱ければ再浮上。状況が変わっている可能性
- **実行詳細に先走らない**: 「どう実行するか」の前に「何を実行するか」「そもそも実行するか」

## 実行時の指針

### 出力テンプレート

**最終出力はこのテンプレートに従う**。下記チェックリストは内部検証用で出力には含めない。

**ステップ → 出力節のマッピング** (どの節にどの Step の処理を載せるか):

- Step 1〜2 → `## 問題の再構成` の「観測している症状」「上流の構造」に書く
- Step 3 → `## 問題の再構成` の末尾に `### 所与の前提と根拠` 表として書く (抽出語句・根拠の有無の 2 列表)
- **Step 4 → `## 問題の再構成` の末尾に `### 境界拡張` として書く** (6 次元のうち本問題で意味のある 1〜3 次元のみ。意味のない次元は省略可。独立節を作らず必ずこの位置に置く)
- Step 5 → `## 選択肢の棚卸し` (相手の提案・現状維持・上流を変える案・前提を崩す案・やらない/延期 を最低 1 つずつ含める)
- Step 6 → 各案末尾に `重さ: N` を付記
- Step 7 → `## 相手の提案を採用した場合の帰結予測`
- Step 8 → `## 評価軸`
- Step 9 → `## 採点表`
- Step 10 → `## 反復記録` に Q1〜Q7 の判定 (Yes/No + 理由)。ループに入った場合のみループ記録も追記

```markdown
## 問題の再構成
- 相手が設定した問題: ...
- 観測している症状: ...
- **上流の構造**: ...
- **本質的な問い**: ...

### 所与の前提と根拠 (Step 3)
| 抽出語句 | 根拠の有無 | 判定 |
|---|---|---|
| 動詞句 1 | ... | 強い / 弱い |
| 副詞・モーダル + 隣接動詞 (例: とりあえず増やす) | ... | 強い / 弱い |

### 境界拡張 (Step 4)
本問題で意味のある 1〜3 次元のみを書く (時間軸 / 主体 / スコープ境界 / 前提条件 / 抽象レベル / 業界・前例 から選ぶ)。

## 選択肢の棚卸し
各案の末尾に Step 6 の重さ (1〜5) を `重さ: N` 形式で必ず付記する。
- 案 A (相手の提案): ... 重さ: N
- 案 B (現状維持): ... 重さ: N
- 案 C (上流を変える): ... 重さ: N
- 案 D (既知事例に倣う): ... 重さ: N
- 案 E (前提を崩す): ... 重さ: N
- 案 F (やらない / 延期): ... 重さ: N

## 相手の提案を採用した場合の帰結予測
- 帰結 1 (スケール時): ... → 受け入れ可能 / 受け入れ難い
- 帰結 2 (変更時): ... → 受け入れ可能 / 受け入れ難い
- 帰結 3 (新メンバー参入時): ... → 受け入れ可能 / 受け入れ難い
(受け入れ難いものがあれば、その帰結を構造的に発生させない案を推奨候補に入れる)

## 評価軸
(文脈に応じた 3〜6 軸)

## 採点表
| 軸 | A | B | C | D | E | F |
|---|---|---|---|---|---|---|
| ... |

## 推奨
1 案を選ぶ。選ばなかった案の却下理由も明記。
複数案のシーケンシャル (先に X、結果次第で Y) / 段階的 (Phase 1: X, Phase 2: Y) も許容。

## 反復記録
Step 10 自答チェック Q1〜Q7 の判定結果を逐項記載する (省略不可)。
- Q1 (粒度): Yes / No — 1 行理由
- Q2 (上流): Yes / No — 1 行理由
- Q3 (暗黙の期待): Yes / No — 1 行理由
- Q4 (新規性): Yes / No — 1 行理由
- Q5 (受け入れ難い帰結): Yes / No — 1 行理由
- Q6 (軽い案で同等効果なし): Yes / No — 1 行理由 (採点表で他案優位の場合は特に厳密に書く)
- Q7 (前提疑い): Yes / No — 1 行理由
ループに入った場合は「ループ N (上流|横展開): Qn が No → 追加した案 / 修正した観点」を追記。

## 不確実性
確信を持てない部分を正直に。
```

### 境界判断の原則

指示の境界で迷ったら:

- **粒度の選び方**: 文脈で意味のある最小単位で切る。技術なら「層 (UI / ドメイン / DB)」、組織なら「役割 (個人 / チーム / 組織)」、時間軸なら「意思決定サイクル」
- **情報が足りない次元**: 省略可。該当なしと明示して進む
- **指示同士の競合** (「やらない案を必ず入れる」vs「軸の制約で評価不能」等): 実用性優先。形式のために無意味な案を入れない
- **自分で生成した案を自分で却下** (相手の却下案の再浮上ではない): 通常の却下理由で済ませる。「再浮上」アンチパターンは相手の既却下案にのみ適用

迷いは「不明瞭点」として上げるのでなく、**境界判断の根拠を「裁量補完」に書いて進む**。

### チェックリスト (解決策提示の直前)

- [ ] 症状と構造を切り分けたか (Step 1)
- [ ] 上流に 2 段遡ったか (Step 2)
- [ ] 相手が所与として書いた前提を動詞単位でリストアップし、根拠の弱い前提を変える案を含めたか (Step 3)
- [ ] 6 次元のうち最低 3 つで境界を広げたか (Step 4)
- [ ] 案を 3 つ以上、相手の提案を 1 列含めたか (Step 5)
- [ ] ドメイン外と「やらない / 延期」を入れたか (Step 5)
- [ ] 案の重さで優先順位をつけ、軽い案を主推奨にしたか (Step 6)
- [ ] 相手の提案の帰結を 3 つ以上予測し、受け入れ可能かを判定したか (Step 7)
- [ ] 受け入れ難い帰結があれば、構造的に回避する案を推奨したか (Step 7)
- [ ] 評価軸を明示し採点表を作ったか (Step 8 / 9)
- [ ] 却下理由と不確実性を書いたか
- [ ] Step 10 自答チェック Q1〜Q7 の判定結果を反復記録に明記したか
- [ ] Q6 (軽い案で同等効果がないか) / Q7 (前提を疑ったか) を特に意識的に確認したか
- [ ] 大きな判断なら Step 4 / 5 / 7 で Sub Agent を並列起動したか (小/中規模は不要)

1 つでも "いいえ" があれば保留して戻る。

## 適用の型 (問題の再構成までの例)

具体の選択肢や推奨は書かない。**Step 1〜3 でどこまで遡れば上流に届くか** の相場感だけ示す。

### 技術設計 — 特定 API のレイテンシが悪化している

- 設定: 特定エンドポイントが遅い → キャッシュやインデックスを足したい
- 上流: クエリ形状と集約境界 (1:N:N の深いリレーション) がユースケースと不一致
- 本質: 速くする前に、そのデータ形でそのユースケースを満たすのが妥当か

### プロセス — 末端で事故が続く

- 設定: 特定段階 (レビュー / リリース / 受付) で事故が続く → 強化したい
- 上流: 事故を生む構造 (環境差 / 責任分散 / 手戻り経路) が上流に散在
- 本質: 見逃しを減らすことと、見逃しても平気な構造を作ることは別問題ではないか

### 意思決定 — 二者択一で意見が割れる

- 設定: 選択肢 X / Y のどちらを採るか
- 上流: 「何を基準に選ぶか」が未合意
- 本質: 選ぶ前に、選ぶための基準を作る必要はないか

ドメインに関係なく同じプロトコルを適用できる。

## ultrathink との併用

`ultrathink` が「思考時間を使う許可」なのに対し、このスキルは「どこに時間を使うか」の方向付け。併用で**上流の構造を深く掘る**ことに時間を投入できる。