AIに「どの思考技法を使うべきか」を判定させる：56個ライブラリからのメタ思考設計

問題解決の思考技法は世の中に大量にあります。5 Whys、Fishbone、Pre-mortem、Inversion、SCAMPER、Six Thinking Hats、MECE、Issue Tree……名前だけ知っていても、いざ問題を前にすると「今これに何を使うべきか」が出てこないことが多いです。

そこで試しているのが、56個の思考技法をライブラリ化しておき、「今この問題にどの技法が効くか」を AI 自身に選別させるメタ思考フレームワークです。Plan mode と Sub agent の組み合わせで、判断根拠を透明化したまま回せます。

なぜ「技法選択」を AI に任せるのか

人間は得意な技法に偏る

問題解決の現場で起きることは決まっていて、自分が好きな技法を毎回使ってしまう現象です。5 Whys が好きな人は何でも 5 Whys、ロジックツリー派は何でもツリーに分解します。問題の性質と技法の相性を毎回ゼロから考えるのは負荷が高く、つい慣れた道具に手が伸びます。

これは個人だけでなくチームでも起きます。「うちは Fishbone でやる文化」と決めてしまうと、Fishbone が向かない問題（時系列の遅延要因や、外部環境変化など）でも無理に当てはめます。結果、得られる洞察が浅くなります。

AI は技法カタログを横断できる

AI は技法カタログを丸ごと参照できるので、「この問題の性質に合うのはどれか」を56個から並列に評価できます。人間が頭の中でやろうとすると、思い出せる範囲（多くて10種類）でしか選べません。

加えて AI は「選んだ理由」を言語化させられます。後から「なぜこの技法を選んだか」を読み返せるので、判断の透明性が確保できます。

実装：3フェーズに分けて選別させる

Phase 1: 情報収集（問題の性質を AI に把握させる）

最初に、問題のメタ情報を AI に渡します。何を解きたいかではなく、問題の構造を伝えるのがポイントです。

1
以下の問題について、性質を分析してください。
2
分析項目（各1-2行）:
3

4
1. 問題のタイプ（原因究明 / 設計 / 評価 / 予測 / 意思決定 のどれか）
5
2. 既知度（既知の問題か / 新規の問題か）
6
3. 時間制約（即応必要 / 中期 / 長期）
7
4. 関係者数（個人 / 小チーム / 組織横断）
8
5. 失敗の性質（顕在 / サイレント / 反復 / 一回性）
9
6. データの有無（定量データあり / 定性のみ / データ不足）
10
7. 不確実性（高 / 中 / 低）
11

12
【問題】
13
スケジュールジョブのサイレント障害が月に数回発生し、
14
気づくのが下流ジョブの停止後になるケースが続いている。
15
既存の監視・アラートはあるが鳴っていない。

ここで AI が問題の性質を勘違いしていないかを人間が必ず確認します。Phase 1 のアウトプットがズレていると、Phase 2 で見当違いの技法が選ばれます。

Phase 2: 技法選別（56個ライブラリから候補を絞らせる）

技法ライブラリは別ファイルとして用意しておきます。1技法あたり以下のフォーマットでまとめておくと、AI が判断しやすくなります。

1
## 技法名: 5 Whys
2
- 目的: 表層原因から根本原因への深掘り
3
- 向く問題: 単線的な因果が想定される / 既知タイプの障害
4
- 向かない問題: 複数原因の絡み合い / 確率的な事象
5
- 必要データ: なし（事実の積み重ねで進む）
6
- 所要時間: 30分〜1時間
7
- 出力形式: 因果チェーン

これを 56 技法分用意します。最初は大変ですが、一度作れば再利用できます。

Phase 2 では Sub agent を立ち上げ、ライブラリと Phase 1 のメタ情報を渡して、Top 3 候補と落選理由を出させます。

1
以下の問題性質に最も合う思考技法を、添付ライブラリから
2
Top 3 選んでください。さらに、検討したが外した技法を
3
3つと、外した理由も出してください。
4

5
【出力フォーマット】
6
## 採用候補
7
1. 技法名 - 採用理由（問題性質のどの軸に合致するか）
8
2. ...
9
3. ...
10

11
## 検討して外した
12
1. 技法名 - 外した理由
13
2. ...
14
3. ...

「外した理由」を出させるのが効きます。これがないと AI が最初に思いついた3個を返すだけで、本当に比較した形跡が残りません。

Phase 3: 評価（選別の妥当性を別の AI に検証させる）

最後に、Phase 2 の結果を別のセッションに投げて検証させます。

1
以下は問題分析と、選ばれた技法 Top 3 です。
2
この選択に対して、以下を評価してください:
3

4
1. 採用された3技法は、互いに重複していないか
5
2. 採用された3技法で、問題性質の主要な軸を全てカバーしているか
6
3. 「外された技法」の中に、本来採用すべきものはないか
7
4. 全く検討されていない技法カテゴリはないか
8

9
評価は批判的に行ってください。
10
妥当な選択ならその根拠を、不適切な選択なら代替案を出してください。

このセルフレビューがないと、Phase 2 の AI が自信過剰に1案を推しすぎる問題が出ます。別セッションで批判的レビューさせると、第3者視点が確保できます。

実際に動かすとどうなるか

「サイレント障害多発」という性質に対して、3フェーズを回したときの典型例です。

Phase 1 の出力例

問題タイプ: 原因究明 + 設計（再発防止）
既知度: 既知（似た事象が複数回）
時間制約: 中期
関係者数: 個人〜小チーム
失敗の性質: サイレント + 反復
データ: 定量（実行ログ）あり、定性（運用感覚）あり
不確実性: 中（原因仮説は複数）

Phase 2 の出力例（採用候補 Top 3）

Pre-mortem — サイレントかつ反復する性質に対し、未来から逆算して「再発時に何が起きているか」を先回りで描く
Fishbone（特性要因図） — 複数原因の絡み合いに強く、定量データを各骨に紐付けやすい
Bow-tie analysis — 原因系（左半分）と結果系（右半分）を独立に分解できるので、検知の盲点と影響緩和を別々に設計できる

Phase 2 の出力例（外した技法）

5 Whys — 単線的な因果を仮定する技法だが、サイレント障害は複数の原因が同時に成立しやすく不適
SCAMPER — 主に新機能・新製品の創発系で、原因究明には弱い
Six Thinking Hats — 多視点の発散には強いが、データに基づく原因究明より意思決定向き

Phase 3 の出力例（批判レビュー）

採用された3技法は重複が少なく、原因系と対策系の両方を含んでいる点で妥当です。ただし、「FMEA（故障モード影響解析）」が検討されていないのが気になります。サイレント障害の「気づかなさ」は検出度（D）の評価で扱える領域であり、Bow-tie より定量的な優先順位付けが可能です。Top 3 のうち1つを FMEA に置き換えるか、補助技法として併用することを推奨します。

このように、別セッションで批判的レビューさせると漏れが見つかります。

エンジニアにとっての価値

1. 「思考の思考」が外注できる

問題解決の難所は、問題そのものを解く前段階の「どう解くか」を決めるところです。ここを AI に外注できると、本題に入る前のエネルギー消費が大幅に減ります。

2. 判断根拠が透明・後追い可能になる

3フェーズの出力をすべて記録しておけば、3ヶ月後に「なぜこの技法を選んだか」「他に検討した候補は何か」が読み返せます。チーム内で共有するときも、結論だけでなく選択の経緯を共有できるので説得力が増します。

3. Plan mode + Sub agent の使い分け学習になる

3フェーズはそれぞれ役割が違います。Phase 1 は情報整理、Phase 2 は候補絞り込み、Phase 3 は批判的レビュー。同じ AI でも、目的が違えば別セッションに分けるべきことが体感できます。これは他のワークフロー（リサーチ・設計レビュー・コードレビュー）にも応用できる原則です。

落とし穴と対処

落とし穴1: ライブラリが薄いと選択肢が偏る

技法を10個しか定義していないと、AI は10個の中から無理やり3個選びます。最低でも30〜50技法は揃えるのが目安です。56個まで増やすと、原因究明・設計・評価・予測・意思決定の5タイプそれぞれに10技法ずつ確保できます。

落とし穴2: メタ情報の粒度が粗すぎる

Phase 1 で「問題タイプ: 全部」のように粗く出ると、Phase 2 でも「全部に効く技法」が選ばれて意味がなくなります。問題タイプは1つか2つまでに絞らせます。複数タイプが混在しているなら問題を分割すべきサインです。

落とし穴3: Phase 3 を省略する

時間が惜しくて Phase 3 をスキップすると、Phase 2 の選択がそのまま採用されます。3技法のうち1つは漏れていることが経験上多いので、Phase 3 を省略すると痛い目を見ます。Phase 3 は5〜10分で終わるので、必ず通します。

落とし穴4: 技法を選んだ後の「実行」を AI に丸投げする

技法選別までは AI に任せて良いですが、実際にその技法で問題を分析する作業は人間が主導するか、AI と対話しながら進めます。AI に「Pre-mortem を実行してください」と丸投げすると、もっともらしい一般論しか返ってこないことが多いです。

適用範囲

この手法が効くシーン：

反復している問題で、これまでの解き方が効いていないとき
チームで問題解決に入る前の「どう解くか」を決めるミーティング
自分が属さない領域の問題を相談されたとき
大きな意思決定の前に、検討漏れがないかチェックするとき

効きにくいシーン：

即応が必要な障害対応（選んでいる時間がない）
単純な技術選定（フレームワーク比較などは技法以前）
答えが既に見えている問題（検証だけで足りる）

まとめ

ステップ	ポイント
1. ライブラリ準備	30〜50技法を一定フォーマットで
2. Phase 1: メタ情報	7軸で問題性質を AI に分析させ、人間が確認
3. Phase 2: 候補絞り	Top 3 + 外した技法3つを必ず出させる
4. Phase 3: 批判レビュー	別セッションで漏れ・重複を指摘させる
5. 実行は人間主導	技法選別は AI、適用は人間

「思考の思考」を AI に外注すると、判断根拠が透明になり、後から検証可能になります。Plan mode と Sub agent の高度な使い分けとしても応用範囲が広いです。問題解決のスタート地点でつまずくことが減りました。