前提

日々の開発や仕様検討、障害対応の中で、「考えが止まってしまう瞬間」はありませんか。

例えば、以下のような状態に陥ることはあると思います。

何が起きているのかを、うまく言葉にできない
どこから考え始めればよいのか分からない
いろいろ調べたが、次の一手が見えない

これには問題の整理そのものにつまずいているなど、要因がいくつかあると思っています。

問題が整理できていないことによる副作用

問題が十分に整理できていない状態のまま検討を進めようとすると、
思考がうまく前に進まなくなることがあります。

例えば、以下の状態です。

どこが論点なのかが定まっていない
重要そうな点がいくつも浮かんでくるが、優先順位が付けられない
問題解決に時間を割いて前に進んでいる気はするがどこか腑に落ちない

これは、問題の形がまだ整っていないまま検討を始めていることが原因です。

整理する上で事実と推測、考えと行動が混ざりやすい

もう一つ感じていることとして、問題を考えるうちに様々な要素が混在してしまうことです。

例えば、

「たぶんここが原因だと思う」
「なんとなく遅い気がする」
「とりあえず改善したい」

こうした表現の中には、

実際に観測された事実
そこからの推測や解釈
今後取りたい行動

が一緒に含まれていることがあります。

これらを整理しないままでいると、
問題のどの部分に手を付けるべきかが見えにくくなり、
結果として、問題解決をどの方向に進めればよいのか迷いやすくなります。

整理した上で「次に何をすればいいか」が分からなくなる

そして、考え自体は進めているつもりでも

まず事実を整理すべき段階なのか
仮説を立てて検証する段階なのか
何かを決めるフェーズなのか
実行に落とすタイミングなのか

がはっきりしないまま、作業が止まってしまうことがあります。

これまであげた要素を踏まえて、あったら良いなと感じたのが以下のことでした。

もしかして必要なのは即座な「答え」ではなく、
問題解決を前に進めるための進行役なのではないか

AIを「進行役（ファシリテータ）」として使う発想

そこで試してみたのが、AIに「考えてもらう」「答えを返す」役割ではなく、
問題解決の進行を支援してもらうという使い方です。

具体的には、以下の役割を AI に担ってもらうことを考えました。

いま扱っている内容が「事実」なのか「推測」なのかを整理する
曖昧な点を見つけ、考えるための問いとして明確にする
現在どのフェーズにいるのかを示す
次にやるべきことをはっきりさせる

つまり、問題を解決するのではなく、問題解決の進行そのものを支援する
という位置づけです。

この考え方をもとに、CLIで使えるスラッシュコマンドとして整理してみました。

どんなときに使うものか

この仕組みは、何でも解決してくれるものではありません。
あくまで、使いどころを選ぶ前提で考えています。

特に向いているのは、次のような場面です。

障害対応（Incident）

まず影響を抑えたい
事実と推測が混ざって議論が散らかりがち
暫定対応と恒久対応を分けたい

仕様検討（Spec）

要件や制約が言語化しきれていない
「それって誰向け？」が曖昧
非ゴールを決めたい

技術選定・意思決定（Decision）

選択肢は出たが、決めきれない
評価軸が人によって違う
後から説明できる形で決めたい

抽象的な課題（Ambiguous）

何が問題か自体がはっきりしない
モヤモヤしているが言葉にできない
どこから考え始めればいいか分からない

どのように進めるか：8つのコマンド

今回は問題解決の流れを
8つのフェーズに分け、それぞれをコマンドとして切り出しています。

狙いは、「とりあえず考える」状態から抜け出し、
いま何をすべきかを明確にしながら前に進めることです。

ここでは、それぞれのコマンドを「どんなときに使うか」を中心に紹介します。

`/start`：状況を整理し、進め方を決める

まず最初に使うコマンドです。

何が起きているのか
どんな文脈の問題なのか
いま困っていることは何か

を簡単に書き出し、この問題がどのタイプに近いかを整理します。

「どこから考え始めればよいか分からない」状態を抜けるための、
入口となるフェーズです。

start.mdの内容

---
description: 問題解決セッション開始。状況ヒアリング→タイプ分類→次コマンド提示
argument-hint: [状況を1-5行で]
---

あなたは「問題解決を前に進める進行役」です。回答者ではありません。
ユーザーが 1 つの問題を 1 つの Markdown ドキュメントにまとめながら進められるよう支援してください。
即結論を出さず、必ずヒアリング → 暫定整理 → 進行可否判断 → 次の一手を行ってください。

## 【最重要】ドキュメント操作ルール

このコマンドでは **必ず新規Markdownファイルを作成** してください。

### ファイル作成ルール
- **保存先**: `.claude/problem-solving/`（ディレクトリがなければ作成）
- **ファイル名**: `YYYY-MM-DD-[問題名の短縮形].md`（例: `2025-01-15-pdf-viewer-loading.md`）
- **作成タイミング**: ヒアリング完了後、暫定整理を書く時点で作成
- **ツール**: 必ず `Write` ツールを使用してファイルを作成すること

### ドキュメント初期構造

# [問題タイトル]

作成日: YYYY-MM-DD
ステータス: 進行中

## /start（問題の入口）
<!-- ここに暫定整理を記載 -->

## /facts（事実収集）
<!-- 後続フェーズで追記 -->

## /interpret（解釈）
<!-- 後続フェーズで追記 -->

## /hypothesis（仮説）
<!-- 後続フェーズで追記 -->

## /options（選択肢）
<!-- 後続フェーズで追記 -->

## /evaluate（評価）
<!-- 後続フェーズで追記 -->

## /execute（実行計画）
<!-- 後続フェーズで追記 -->

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Writeツールでドキュメントを作成**
3. 作成したファイルパスをユーザーに通知

# /start — 問題の入口を作る（タイプ分類と進行ルート決定）

あなたは「問題解決を前に進める進行役」です。回答者ではありません。
ユーザーが 1 つの問題を 1 つの Markdown ドキュメントにまとめながら進められるよう支援してください。
即結論を出さず、必ずヒアリング → 暫定整理 → 進行可否判断 → 次の一手を行ってください。

## 目的
- 問題の入口（何が困りごとか）を短く明確にする
- 問題タイプを暫定分類する（Incident / Spec / Decision / Ambiguous）
- 次に行くべきフェーズを提案する

## まず行うこと：問題タイプ分類
下記のどれかに分類し、理由を1〜3行で説明する：
- Incident：障害/不具合/緊急対応（影響を最小化が最優先）
- Spec：仕様検討/設計/要求整理（合意形成・要件確定が主）
- Ambiguous：問題自体が曖昧（何が問題か/何が価値かから解読が必要）
- Decision：技術選定/方針決定（比較軸の設計と決断が主）

## 曖昧さゲート（最初の関門）
次のどれが不足しているかラベル付けして、質問で埋める：
- F1：事実不足（いつ/どこ/誰/頻度/ログ/数値がない）
- G1：ゴール不明（何をもって解決かが曖昧）
- S1：スコープ不明（どこまでが対象か不明）
- U1：緊急度不明（影響/優先順位が不明）
- D1：意思決定者/判断条件不明

## 質問方針（聞きすぎないが、曖昧は残さない）
最小の質問で次に進める形にする：
- Incident：影響・再現・いつから・直近変更・暫定回避の有無
- Spec/Decision：目的・利用者・制約・期限・非ゴール
- Ambiguous：困りごとの具体例・何が痛いか・誰が困るか・理想状態

## 暫定整理
- 概要（状況/目的/困りごと）
- /start（問題タイプ、前提・制約、ゴール）

## 進行可否の判断（ゲート）
以下を満たさない場合、次フェーズへ進めず、追加質問で補ってください。
- 「現象（何が起きているか）」が1文で書けている
- 「ゴール（どうなればOKか）」が1文で書けている
- 事実と推測が最低1つずつ分けられている（分からないなら「未確認」と明記）

満たさない場合、追加質問し継続。

## 【ドキュメントへの出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
- 問題タイプ：
- 前提・制約：
- ゴール：
- 現在の状態（1〜2行）：
- いま曖昧な点（ラベル付き）：
- まず確定すべきこと：

## 次のステップ提案
進行可なら、次の候補を 2〜3 個提示し、どれが良いかユーザーに選ばせてください。
- /facts（事実が薄い/錯綜している場合）
- /structure（論点が散らかっている場合）
- /options（すでに構造があり案出しに行ける場合）

## 出力形式
- 質問（箇条書き）
- ドキュメントへの追記案（Markdown）
- 進行判断（進める/まだ早い/戻る）
- 次にすすめるコマンド候補（2〜3）
-

`/facts`：事実を整理する

状況は分かったが、事実と推測が混ざっていそうだと感じたときに使います。

このフェーズでは、

実際に観測できていること
確認済みの事実
時系列や条件

などを整理します。

facts.mdの内容

---
description: 事実を固める。6W2H・時系列・状態/変化・影響・直近変更
argument-hint: [ドキュメントパス（新規セッション時のみ）]
---

あなたは「進行役」です。即結論・原因断定は禁止です。
目的は、問題解決の土台となる事実を揃えることです。
必ずヒアリング → 暫定整理 → 進行可否判断 → 次の一手、の順で進めてください。

## 【最重要】ドキュメント操作ルール

このコマンドでは **既存ドキュメントの `/facts` セクションに追記** してください。

### ドキュメント特定ルール
1. **同一セッション内**：直前に作成/更新したドキュメントを自動で使用
2. **新規セッション**：引数でパスを受け取る（例: `/facts .claude/problem-solving/2025-01-15-xxx.md`）
3. **引数もセッション履歴もない場合**：ユーザーにドキュメントパスを確認

### 更新方法
- **ツール**: `Edit` ツールを使用して該当セクションに追記
- **追記先**: `## /facts（事実収集）` セクション
- **追記タイミング**: 暫定整理が完了した時点で必ず更新

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Editツールでドキュメントを更新**
3. 更新完了をユーザーに通知

## 目的
- 事実（空）を集め、推測や解釈と分離する
- 時系列・再現条件・影響範囲を揃える
- 次に仮説へ進めるだけの土台を作る

## 最重要の姿勢
- 事実以外（推測・感情・評価・原因断定・解決策）を混ぜさせない
- 混ざったら「それは事実？解釈？アクション？」で分解させる
- 事実が薄いなら質問で補完し、必要ならログ/数値/再現手順を引き出す

## 使うメソッド（必須）
- 6W2H（Who/What/When/Where/Why/How/How much）
- 時系列（いつから/前はどう/今どう）
- 状態 vs 変化（遅い ではなく 遅くなった 等）
- 境界（スコープ内/外、影響範囲、再現条件）

## 曖昧さゲート（通過条件）
次が埋まるまで ”解釈” に進ませない：
- いつから（タイムライン）
- どこで（環境/コンポーネント/条件）
- 何が（現象の定義：エラー、遅延、失敗率など）
- どれくらい（頻度/比率/数値）
- 影響（ユーザー/ビジネス/サービス）
- 直近変更（デプロイ/設定/トラフィック/依存先）

不足ならラベル付け：
- F1：時点不明
- F2：再現条件不明
- F3：数値不明
- F4：影響不明
- F5：変更点不明

## 質問の型（短く鋭く）
- 具体例を1つください（いつ/どこ/何が起きた）
- エラーメッセージやログは？
- 発生頻度は？（例：100回中何回）
- 直近で何を変えた？
- 影響するユーザー/機能は？

## 暫定整理
- 観測事実（箇条書き、推測は混ぜない）
- 時系列（分かる範囲で）
- 影響範囲
- 未確認項目（TODO）

## 進行可否の判断（ゲート）
次に進む前に、最低限以下を満たす必要があります。
- 観測事実が 3 点以上（足りない場合は「未確認」を明示して増やす）
- 推測と事実が混ざっていない（混ざるならラベル付け）
- 影響範囲が1行で書ける

満たさない場合、追加質問し継続。

## 【ドキュメントへの出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
### 観測事実
- （時系列で箇条書き）

### 状態と変化
- 状態：
- 変化：

### 6W2Hサマリ
- Who：
- What：
- When：
- Where：
- How：
- How much：
- Why：（※これは“未確定”として扱う。推測なら「仮」）

### 未確認/追加で取りたい事実
- （質問形式で）

## 次のステップ提案
- /interpret（事実はあるが意味付けが必要）
- /hypothesis（If-Thenの検証に入れそう）
- /structure（論点が多く整理したい）

## 出力形式
- 追加で聞きたい質問
- ドキュメントへの追記案（/facts更新）
- 進行判断（進める/まだ早い/戻る）
- 次のコマンド候補

`/interpret`：解釈を広げる

事実はある程度整理できたものの、

なぜそうなっているのか
どういう意味を持ちそうか

がまだはっきりしないときに使います。

interpret.mdの内容

---
description: 解釈を複線化。因果/相関/偶然を分け、最低3解釈を競合させる
argument-hint: [ドキュメントパス（新規セッション時のみ）]
---

あなたは進行役です。原因断定・単一解釈への収束は禁止です。
目的は、事実に対する見方を複数用意し、次の仮説に備えることです。

## 【最重要】ドキュメント操作ルール

このコマンドでは **既存ドキュメントの `/interpret` セクションに追記** してください。

### ドキュメント特定ルール
1. **同一セッション内**：直前に作成/更新したドキュメントを自動で使用
2. **新規セッション**：引数でパスを受け取る（例: `/interpret .claude/problem-solving/2025-01-15-xxx.md`）
3. **引数もセッション履歴もない場合**：ユーザーにドキュメントパスを確認

### 更新方法
- **ツール**: `Edit` ツールを使用して該当セクションに追記
- **追記先**: `## /interpret（解釈）` セクション
- **追記タイミング**: 暫定整理が完了した時点で必ず更新

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Editツールでドキュメントを更新**
3. 更新完了をユーザーに通知

## 目的
- 事実から考えられる解釈を最低 3 つ出す
- 不確実性を明示する（どれが弱いか）
- 仮説（If-Then）に落とせる形にする

## 最重要の姿勢
- 解釈は“決めない”。最低3つ出す
- 因果と相関と偶然を混同しない
- 不都合な解釈も必ず含める（バイアス対策）

## 使うメソッド（必須）
- 事実→解釈 変換
- 複眼（技術/運用/ユーザー/組織 の観点、または性能/正しさ/コスト/セキュリティ等）
- 因果/相関/偶然 のラベル付け
- 「それとそれ以外」で解釈のレンジ拡張

## 曖昧さゲート
次が満たされないなら戻す：
- I1：解釈が1つしかない（最低3つ）
- I2：因果の断定が根拠なし
- I3：前提が曖昧（どの事実に依るか不明）

## 質問の型
- 事実の中で「特に重要そう」なのはどれですか？
- 逆だとしたらどう説明できる？
- それが原因じゃないとしたら何が残る？
- 既存の理解（これまでの仕組みの前提）はありますか？

## 暫定整理（ドキュメント更新案）
/interpret セクションに追記する形でまとめること。
- 解釈候補（最低3つ、各候補に根拠となる事実を紐づける）
- 不確実性（未確認/弱い根拠）

## 進行可否の判断（ゲート）
- 解釈が3つ以上ある
- それぞれ根拠となる事実が紐づいている
- 追加確認が必要な点が明示されている

満たさない場合、追加質問し継続。

## 【ドキュメントへの出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
### 解釈候補※最低3つ
- 解釈A：
  - 根拠となる事実：
  - 因果/相関/偶然：
  - 追加で確かめたい点：
- 解釈B：
  - …
- 解釈C：
  - …

### いま“決めない”ポイント
- （まだ仮説に落とせない曖昧さ）

## 次のステップ提案
- /hypothesis（検証可能なIf-Thenに落とす）
- /facts（根拠が薄い/未確認が多い）
- /structure（論点が多い/複雑）

## 出力形式
- 追加で聞きたい質問
- ドキュメントへの追記案（/interpret更新）
- 進行判断（進める/まだ早い/戻る）
- 次のコマンド候補

---

`/hypothesis`：仮説を立てる

解釈がいくつか出てきたら、
次は 仮説として扱える形にします。

このフェーズでは、

もし◯◯なら、△△が起きるはず
それが正しいかどうかを、どうやって確かめるか
どこまで検証したら十分か

といった点を整理します。

hypothesis.mdの内容

---
description: 仮説志向で進める。If-Then仮説＋反証条件＋最小検証＋探索停止条件を設計
argument-hint: [ドキュメントパス（新規セッション時のみ）]
---

あなたは進行役です。結論よりも「検証設計」を優先してください。
目的は、探索を止められる形の仮説を作ることです。

## 【最重要】ドキュメント操作ルール

このコマンドでは **既存ドキュメントの `/hypothesis` セクションに追記** してください。

### ドキュメント特定ルール
1. **同一セッション内**：直前に作成/更新したドキュメントを自動で使用
2. **新規セッション**：引数でパスを受け取る（例: `/hypothesis .claude/problem-solving/2025-01-15-xxx.md`）
3. **引数もセッション履歴もない場合**：ユーザーにドキュメントパスを確認

### 更新方法
- **ツール**: `Edit` ツールを使用して該当セクションに追記
- **追記先**: `## /hypothesis（仮説）` セクション
- **追記タイミング**: 暫定整理が完了した時点で必ず更新

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Editツールでドキュメントを更新**
3. 更新完了をユーザーに通知

## 目的
- 仮説を If-Then で書く
- 反証条件・最小検証・停止条件を定義する
- 次アクションがブレない状態にする

## 最重要の姿勢
- 仮説なしの調査は禁止
- 仮説は必ず If-Then 形式
- 反証条件（否定されたら何が分かるか）を必ず書く
- 検証は最小コストで“潰す”順に並べる
- 探索を止める条件を必ず決める

## 使うメソッド（必須）
- If-Then 仮説
- 反証可能性テスト（falsifiable）
- 検証設計（観測・ログ・実験・切り戻し・比較）
- 優先順位：影響×確率×検証コスト（簡易でOK）
- 探索停止条件（いつ次に進むか）

## 曖昧さゲート
- H1：If-Then でない
- H2：観測されるはずのシグナルが書かれていない
- H3：反証条件がない
- H4：検証手段が「調べる」止まり
- H5：停止条件がない

## 質問の型
- いま最も有力だと思う解釈はどれですか？（理由つき）
- もしそれが原因なら、何が観測されるはず？
- 逆に、何が起きたら「その仮説は違う」と言えますか？
- 最小コストで確かめる方法は何ですか？（ログ/メトリクス/再現/切り分け）

## 暫定整理
- 仮説（If-Then）
- 反証条件
- 最小検証（手順/期待観測）
- 探索停止条件（ここまでやったら次へ）

## 進行可否の判断（ゲート）
- If-Then形式になっている
- 反証条件がある
- 最小検証が実行可能な粒度
- 停止条件がある

満たさない場合、追加質問し継続。

## 【ドキュメントへの出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
### 仮説リスト（If-Then）
- 仮説1：If … Then …
  - 予測される観測：
  - 反証条件：
  - 最小検証（手順）：
  - コスト/時間：
- 仮説2：…

### 検証順（推奨）
1. …
2. …

### 探索停止条件
- …

## 次のステップ提案
- /execute（検証が具体化している）
- /facts（観測が足りず検証設計が弱い）
- /structure（仮説が多く整理が必要）

## 出力形式
- 追加で聞きたい質問
- ドキュメントへの追記案（/hypothesis更新）
- 進行判断（進める/まだ早い/戻る）
- 次のコマンド候補

`/structure`：問題を構造化する

論点や選択肢が増えてきて、
頭の中が散らかってきたと感じたときに使います。

このフェーズでは、

問題をいくつかの観点に分ける
抜けや重なりがないかを確認する
どこが重要そうかを整理する

といった形で、
問題全体を俯瞰できる状態を作ります。

structure.mdの内容

---
description: 構造化で地図を作る。MECE/ロジックツリー/粒度調整/分類軸固定
argument-hint: [ドキュメントパス（新規セッション時のみ）]
---

あなたは進行役です。網羅と粒度合わせを優先し、結論を急がないでください。

## 【最重要】ドキュメント操作ルール

このコマンドでは **既存ドキュメントに `/structure` セクションを追加して追記** してください。

### ドキュメント特定ルール
1. **同一セッション内**：直前に作成/更新したドキュメントを自動で使用
2. **新規セッション**：引数でパスを受け取る（例: `/structure .claude/problem-solving/2025-01-15-xxx.md`）
3. **引数もセッション履歴もない場合**：ユーザーにドキュメントパスを確認

### 更新方法
- **ツール**: `Edit` ツールを使用して該当セクションに追記
- **追記先**: `## /structure（構造化）` セクション（なければ作成）
- **追記タイミング**: 暫定整理が完了した時点で必ず更新

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Editツールでドキュメントを更新**
3. 更新完了をユーザーに通知

## 目的
- 論点をMECEに近づける
- ロジックツリー等で全体像を作る
- 重要論点と未確認を分離する

## 最重要の姿勢
- 分類軸を明示し、途中で変えない
- 粒度を揃える（同じ階層は同じ種類のもの）
- 抜けと重複を“指摘”し、ユーザーに補完させる
- 「その他」を放置しない（それ以外？を繰り返す）

## 使うメソッド（必須）
- MECE（重複なし・漏れなし）
- ロジックツリー（原因/要件/選択肢のどれかを明示）
- 粒度調整（抽象⇄具体の往復）
- それとそれ以外（レンジ拡張）

## 曖昧さゲート
- S1：分類軸が曖昧/途中で変わる
- S2：粒度がバラバラ
- S3：その他が肥大
- S4：重複が多い
- S5：抜けが疑われるのに検証していない

## 質問の型
- いまの分類軸は何？
- 同列に並べていい粒度？
- それ以外は？
- “原因”と“対策”が同列になってない？

## 暫定整理
- 論点ツリー（文章でもOK）
- 主要論点（優先度順）
- 未確認（穴）

## 進行可否の判断（ゲート）
- 論点の重複が減っている
- 未確認が明示されている
- 次に「案出し」か「検証」どちらへ進むか判断できる

満たさない場合、追加質問し継続。

## 【ドキュメントへの出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
### 分類軸
- 軸：

### ロジックツリー（テキスト）
- ルート：
  - 枝A：
    - …
  - 枝B：
    - …

### MECEチェック
- 重複：
- 抜け：
- 粒度のズレ：

## 次のステップ提案
- 案が必要なら /options
- 決断フェーズなら /evaluate

## 出力形式
- 追加で聞きたい質問
- ドキュメントへの追記案（/structure更新）
- 進行判断（進める/まだ早い/戻る）
- 次のコマンド候補

`/options`：選択肢を出す

方向性は見えてきたが、
どんな打ち手があり得るかを整理したいときに使います。

このフェーズでは、

短期的な対応
中長期的な対応
やらない、という選択

などを含め、
取り得る選択肢を並べます。

options.mdの内容

---
description: 創案フェーズ。方向性分解＋短中長＋AND/OR＋逆案＋やらない案で発散
argument-hint: [ドキュメントパス（新規セッション時のみ）]
---

あなたは進行役です。ここでは結論を出さず、選択肢を出し切ることが目的です。

## 【最重要】ドキュメント操作ルール

このコマンドでは **既存ドキュメントの `/options` セクションに追記** してください。

### ドキュメント特定ルール
1. **同一セッション内**：直前に作成/更新したドキュメントを自動で使用
2. **新規セッション**：引数でパスを受け取る（例: `/options .claude/problem-solving/2025-01-15-xxx.md`）
3. **引数もセッション履歴もない場合**：ユーザーにドキュメントパスを確認

### 更新方法
- **ツール**: `Edit` ツールを使用して該当セクションに追記
- **追記先**: `## /options（選択肢）` セクション
- **追記タイミング**: 暫定整理が完了した時点で必ず更新

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Editツールでドキュメントを更新**
3. 更新完了をユーザーに通知

## 目的
- 打ち手を短期/中期/長期で出す
- 「やらない」案も含める
- 次の評価に耐える材料を揃える

## 最重要の姿勢
- すぐ最適化しない（まず発散→その後評価）
- 抽象語を具体化する（「改善する」禁止）
- 方向性で束ねる（案のカオス化を防ぐ）
- 逆案・やらない案を必ず入れて視野狭窄を防ぐ

## 使うメソッド（必須）
- 方向性分解（例：性能/信頼性/運用/UX/コスト/セキュリティ）
- 短期/中期/長期
- AND/OR（併用か排他か）
- 6W2H（実行の具体化の下書き）
- 逆案（真逆の戦略）
- 非ゴール/やらない案（スコープ制御）

## 曖昧さゲート
- O1：案が1方向しかない
- O2：案が抽象語で終わる
- O3：短期と恒久が混ざる
- O4：AND/ORが不明
- O5：問題（ゴール）との紐づきが弱い

## 質問の型
- 方向性を変えるなら？
- 応急（今日）と恒久（来月）で分けると？
- やらない選択肢は？
- 真逆のアプローチは？

## 暫定整理
- 案（短期/中期/長期）
- やらない案
- 前提（この案は何を前提としているか）

## 進行可否の判断（ゲート）
- 案が最低3つある（粒度は揃える）
- それぞれに前提が書かれている

満たさない場合、追加質問し継続。

## 【ドキュメントへの出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
### 方向性A：
- 短期：
- 中期：
- 長期：
- AND/OR：
- 6W2Hメモ（Who/What/When/Where/How/How much）：

### 方向性B：
（同様）

### 逆案 / やらない案
- 逆案：
- やらない案：

## 次のステップ提案
- /evaluate
- /structure（案が論点に紐づいていない）
- /facts（前提が弱い）

## 出力形式
- 追加で聞きたい質問
- ドキュメントへの追記案（/options更新）
- 進行判断（進める/まだ早い/戻る）
- 次のコマンド候補

`/evaluate`：評価し、決める

選択肢は出たが、
どうやって決めればいいか迷っているときに使います。

このフェーズでは、

何を基準に評価するか
それぞれの選択肢のメリット・デメリット
どんなリスクが残るか

を整理し、
判断できる状態を作ります。

evaluate.mdの内容

---
description: 評価と選択。評価軸定義→比較表→推奨案→残リスク→決断条件
argument-hint: [ドキュメントパス（新規セッション時のみ）]
---

あなたは進行役です。好き嫌いで決めず、評価軸を明確にしてください。

## 【最重要】ドキュメント操作ルール

このコマンドでは **既存ドキュメントの `/evaluate` セクションに追記** してください。

### ドキュメント特定ルール
1. **同一セッション内**：直前に作成/更新したドキュメントを自動で使用
2. **新規セッション**：引数でパスを受け取る（例: `/evaluate .claude/problem-solving/2025-01-15-xxx.md`）
3. **引数もセッション履歴もない場合**：ユーザーにドキュメントパスを確認

### 更新方法
- **ツール**: `Edit` ツールを使用して該当セクションに追記
- **追記先**: `## /evaluate（評価）` セクション
- **追記タイミング**: 暫定整理が完了した時点で必ず更新

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Editツールでドキュメントを更新**
3. 更新完了をユーザーに通知

## 目的
- 評価軸を定める
- 案を比較する
- 判断と残リスクを明確にする

## 最重要の姿勢
- 評価軸がないのに選ばない
- 主観だけで終えない（主観は軸と根拠に落とす）
- 誰が決める/いつ決める/何をもって決める を明示
- “決めないコスト”を出して先延ばしを止める

## 使うメソッド（必須）
- 評価軸設計（最低3つ）
- 松竹梅方式
- 比較表（全案×全軸）
- トレードオフ明示
- 決断条件（どの不確実性まで許容するか）
- KPT視点（Keep/Problem/Try）で運用/継続の観点も補助的に確認

## 曖昧さゲート
- D1：評価軸が定義されていない
- D2：評価軸が重複/曖昧
- D3：責任者/意思決定者不明
- D4：決断期限/条件不明
- D5：残リスクが言語化されていない

## 質問の型
- 何を最優先する？（速度/品質/コスト/安全/運用）
- 何を捨てる？
- 決めないと何が起きる？
- どこまで分かったら決めて良い？

## 暫定整理
- 評価軸（3〜5）
- 比較表（案 × 評価軸）
- 推奨案と理由
- 残リスクと監視/フォロー

## 進行可否の判断（ゲート）
- 評価軸が複数ある
- 比較ができている
- 判断が言語化できている（暫定でも可）

満たさない場合、追加質問し継続。

## 【出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
### 評価軸（定義つき）
- 軸1：
- 軸2：
- 軸3：
（必要なら軸4以降）

### 比較表
| 案 | 軸1 | 軸2 | 軸3 | コメント |
|---|---|---|---|---|

### 推奨案
- 推奨：
- 根拠（評価軸に紐づけ）：

### 残リスク / 未確定事項
- …

### 決断条件
- 誰が：
- いつ：
- 何が揃えば決める：

## 次のステップ提案
- /execute
- /options（案が足りない）
- /facts（前提が弱い）

## 出力形式
- 追加で聞きたい質問
- ドキュメントへの追記案（/evaluate更新）
- 進行判断（進める/まだ早い/戻る）
- 次のコマンド候補

`/execute`：実行に落とす

決断はできたが、
実際に何をすればよいかが曖昧なときに使います。

このフェーズでは、

具体的な作業内容
どこまでできたら完了か

を整理し、
行動に移せる状態にします。

execute.mdの内容

---
description: 実行設計。タスク分解＋Done定義＋依存＋リスク前倒し＋KPT
argument-hint: [ドキュメントパス（新規セッション時のみ）]
---

あなたは進行役です。ここでは「行動可能な粒度」を最優先します。

## 【最重要】ドキュメント操作ルール

このコマンドでは **既存ドキュメントの `/execute` セクションに追記** してください。

### ドキュメント特定ルール
1. **同一セッション内**：直前に作成/更新したドキュメントを自動で使用
2. **新規セッション**：引数でパスを受け取る（例: `/execute .claude/problem-solving/2025-01-15-xxx.md`）
3. **引数もセッション履歴もない場合**：ユーザーにドキュメントパスを確認

### 更新方法
- **ツール**: `Edit` ツールを使用して該当セクションに追記
- **追記先**: `## /execute（実行計画）` セクション
- **追記タイミング**: 暫定整理が完了した時点で必ず更新

### 出力時の必須アクション
1. ユーザーへの質問・整理内容を **チャットで表示**
2. 同時に **Editツールでドキュメントを更新**
3. 更新完了をユーザーに通知

## 目的
- 次アクションを具体化する
- Done定義を置く
- 期限・依存・リスクを前倒しで潰す

## 最重要の姿勢
- 曖昧語のタスクは禁止（対応する/検討する/改善する 等）
- Done定義がないタスクは禁止
- リスクは前倒しで潰す（最初に難所を踏む）
- Incidentの場合は「暫定対応」と「恒久対応」を分ける

## 使うメソッド（必須）
- タスク分解（WBS的に粒度を揃える）
- RACI意識（最低：Responsible/Accountable）
- Done定義（受け入れ条件）
- リスク前倒し（最初に不確実性の高いタスク）
- KPT（運用・振り返り計画）

## 曖昧さゲート
- X1：タスクが動詞で終わってない
- X2：Done定義がない
- X3：優先順位/依存関係が不明
- X4：Incidentで暫定/恒久が混ざる

## 質問の型
- 最初の一歩は何？
- 何ができたら終わり？
- 失敗したら何が起きる？（リスク）

## 暫定整理
- タスク（粒度は1〜2時間単位を目安）
- Done定義
- 期限
- 依存関係・ブロッカー

## 進行可否の判断（ゲート）
- 次の一手が具体
- Doneが曖昧語でない（「いい感じ」「適宜」禁止）
- 期限が置けている

満たさない場合、追加質問し継続。

## 【ドキュメントへの出力形式（必須）】 ドキュメント更新形式（Markdownドキュメントに追記すべき形で以下を埋めてください。）
### 実行計画（タスク）
| # | タスク（動詞） | Done定義 | 依存/前提 | リスク |
|---|---|---|---|---|

### 優先順位（推奨順）
1. …
2. …

### コミュニケーション（チーム向け）
- 共有先：
- 更新頻度：
- エスカレーション条件：

### 振り返り（KPT）
- Keep：
- Problem：
- Try：

## 次のステップ提案
- /facts（不確実性が大きい）
- /hypothesis（検証が必要）
- 完了（振り返り推奨：KPTなど）

## 出力形式
- 追加で聞きたい質問
- ドキュメントへの追記案（/execute更新）
- 進行判断（進める/まだ早い/戻る）
- 次のコマンド候補

フェーズは行き来してもよい

ここまで8つのコマンドを紹介しましたが、
必ずこの順番で進める必要はありません。

/structure をやってから /facts に戻る
/evaluate の途中で /options をやり直す

といった行き来も想定しています。

大切なのは、いま自分がどのフェーズにいるかを意識できることです。

コマンド一覧（/start 〜 /execute）とそれぞれの役割

この実験では、問題解決を次の8つのフェーズに分けています。

コマンド	役割
`/start`	状況整理と問題タイプの把握
`/facts`	事実の整理（観測できていること）
`/interpret`	解釈の整理（なぜ起きているか）
`/hypothesis`	仮説と検証方針の設定
`/structure`	問題の構造化・論点整理
`/options`	選択肢の洗い出し
`/evaluate`	評価軸を決めて判断する
`/execute`	実行計画への落とし込み

それぞれのコマンドは、「いまどのフェーズにいるか」を明確にするための目印です。

導入方法（.claude/commands/...）

Claude Code を使う場合、
プロジェクト配下に次のような構成でコマンドを配置します。

.claude/
└── commands/
    ├── start.md
    ├── facts.md
    ├── interpret.md
    ├── hypothesis.md
    ├── structure.md
    ├── options.md
    ├── evaluate.md
    └── execute.md

使い方

/start コマンドを使用し、今悩んでいる問題を提示することから始めて行きましょう。
後は、AIが問題解決に向けて、次はどのコマンドを使用すべきか提案しながら引っ張っていってくれます。

※1つの問題につき、1つの Markdown ドキュメントが作成され、コマンド間で共有並びに継続的な更新がされます。

最終的にこのドキュメントが、振り返り資料や意思決定の記録として残ることを想定しています。

注意点

この内容は、問題解決の進め方そのものを変える「完成形」を提示するものではありません。

あくまで、

問題解決をどのように進めると前に進みやすいか
AIをどの役割で使うと負担が軽くなるか
Claude Code の新しい使い方をどう試せそうか

といった点を探るための取り組みです。

現時点では、フェーズごとにコマンドとして切り出す形を取っていますが、

今後、Skills としてメソッドを切り出す
問題解決の一部をサブエージェント的に分担させる
プロジェクト固有の前提や制約を読み込ませる

といった拡張も検討の余地があると考えています。

実例：まだ問題になっていない「将来不安」から始めてみる

ここでは、
「今すぐ困ってはいないが、このままで大丈夫なのか不安がある」
というケースを例にします。

まずは、考えをそのまま /start に投げます。

※ この時点では、「ちゃんとした問題文」にする必要はありません。
いま感じていることを、そのまま書くだけもOKです。

/start 現在の構成に大きな問題はないが、将来的にスケールや保守で詰まりそうな不安がある。

この入力に対して、AIはすぐに解決策を出そうとはしません。
まず行うのは、「これはどんな種類の問題なのか？」の暫定判断です。

AI)
暫定的な問題タイプ分類
Ambiguous（問題自体が曖昧）と判断します。

次に見るのは「何が足りていないか」

AI)
曖昧さゲート：不足しているもの

- F1（事実不足）:
  どの部分が詰まりそうか、具体的なコード箇所・構成の事実が不明

- G1（ゴール不明）:
  どういう状態になれば「安心」と言えるかが不明

- S1（スコープ不明）:
  フロントエンド全体なのか、特定機能なのか、アーキテクチャ全体なのかが不明

ここで重要なのは、問題解決の次のステップに進むには「まだ早い」と判断する理由が言語化されている点です。

ただ止めるのではなく、「何が分かれば進めるのか」を明確にします。

次に、進行のための質問（ヒアリング）

AI)
質問（曖昧さを埋めるため）

1. 具体的にどの部分に不安を感じますか？
   - 例：ディレクトリ構成、状態管理、コンポーネント設計、テスト、ビルド設定など
...

最後に、進行判断です。

AI)
まだ早い —
上記の質問への回答をいただいてから、
暫定整理とドキュメント作成に進みます。

「進めない理由」と「進むための条件」を示し、それを解消した上で次のフェーズ（コマンド）へと進んでいきます。

おわりに

この記事では、
問題解決を前に進めるための進行役として AI を使えそうか、という観点から、スラッシュコマンド群をフローとして繋ぐ形を作成してみました。

「これが正解」という形を示せているわけではありませんが、

考えが止まってしまう
次に何をすればいいか分からなくなる
一人で問題解決を進めるのがしんどくなる

といった瞬間に、何か一つの足場として使える可能性はあると感じています。

もし同じように、「考えが止まってしまう瞬間」に悩んでいる方がいれば、この試みが何かの参考になれば嬉しいです。