意思決定の精度は、判断する前にどれだけ「失敗の解像度」を上げられたかで決まる。プロダクトのローンチや採用、戦略転換のような後戻りの効かない判断ほど、リスクを並べた箇条書きでは足りない。必要なのは、未来の失敗を物語として見ることだ。
この記事ではClaude Codeの「スキル」機能を使って、ゲイリー・クラインのプリモーテム手法を再利用可能なワークフローに落とし込む方法を解説する。Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。
プリモーテムは「6ヶ月後、計画は既に失敗した。なぜか」と問う手法。Claudeに与えると、礼儀正しいリスク列挙ではなく具体的な失敗ストーリーを書く。
実装は6ステップ——文脈収集／フレーミング／生のリスト生成／並列サブエージェントによる深掘り／統合レポート／HTML出力。失敗理由ごとに並列実行することが質を決める。
適用するのは「後戻りが効かない判断」だけ。日常のタスクで使うと過剰投資になる。判断フローは本記事の比較表を参照。
プリモーテムとは何か——カーネマンが「最も価値ある」と評した手法
プリモーテム（pre-mortem）は、心理学者ゲイリー・クラインが2007年に提案した意思決定手法だ。直訳すれば「事前検死」。事後分析（ポストモーテム）は失敗が起きた後に原因を解剖するが、プリモーテムは判断を実行する前に「これはすでに失敗した」と仮定して原因を遡及的に列挙する。
ダニエル・カーネマンは著書および講演で、プリモーテムを「自分が知る中で最も価値ある意思決定技術のひとつ」と評している。Google、Goldman Sachs、Procter & Gambleなどの企業が大規模な判断の前にこの手法を実施することで知られている。
なぜ単純な「リスクを挙げてください」では足りないのか。クラインが指摘した認知的トリックがここにある。
「何が悪くなる可能性がありますか」と問われると、人は防衛的・礼儀正しい答えを返す。「すでに失敗しました。なぜですか」と問われると、脳が物語モードに切り替わり、はるかに具体的で、創造的で、正直な失敗理由を生成する。
この差分は人間の認知だけでなく、LLMの応答にも明確に表れる。同じ計画を「何がリスクですか」と尋ねた場合と「これは6ヶ月後に失敗しました。なぜですか」と尋ねた場合では、後者の応答のほうが具体例・固有名詞・時系列を含む密度の高い記述になる。失敗を「すでに起きたこと」として扱うことで、抽象的なリスク評価が具体的な原因分析に変わる。
プリモーテムは「失敗したと仮定して原因を遡る」事前検死の手法
カーネマンが「最も価値ある意思決定技術」と評し、Google等が採用
「失敗済み」フレーミングが具体的で正直な答えを引き出す
なぜLLMにプリモーテムが効くのか——「失敗済み」フレーミングの認知的トリック
LLMは大量のテキストを学習している以上、「事故が起きた後に原因を分析する文章」を膨大に内部化している。事故報告書、障害分析、ポストモーテム、敗戦後の戦記、医療事故の検証——人類は「失敗の事後説明」を書くことに長けており、その記述パターンが学習データに豊富に含まれている。
プリモーテムは、この「事後分析の記述パターン」を意思決定前に呼び出すプロンプト技法だ。「失敗済み」と仮定することで、LLMは慎重なリスク列挙モードではなく、報告書を書くモードに入る。出力は単なる箇条書きではなく、時系列・登場人物・転換点を含む物語に変わる。
この差分を実際に観察すると次のようになる。
| 問い方 | LLMの応答パターン | 弱点 |
|---|---|---|
| 「このプランのリスクは？」 | 抽象的な箇条書き、ヘッジ表現多め、「〜の可能性がある」 | 抽象度が高く、対策に落ちにくい |
| 「何が見落とされていますか？」 | 一般論的な観点リスト、コンテキスト依存度低い | プランの詳細に根ざさない |
| 「弱点を批判してください」 | 防御的に対立軸を作る、論争的になる | 否定のための否定になる |
| 「6ヶ月後、これは失敗した。なぜか」 | 物語形式、固有名詞、時系列、転換点を含む | そのままだと冗長になる傾向 |
物語形式の出力には冗長さという欠点があるが、これは構造化のテンプレートを与えることで制御できる。次節で見るように、Claude Codeのスキル化はこの「物語の制御」が中核となる。
Claudeスキルとしてのプリモーテム——6ステップの構造
Claude Codeのスキル機能は、再利用可能なワークフローをフォルダとMarkdownで定義する仕組みだ。スキル機能そのものは Claude Skillsを徹底解説｜スキルはフォルダ で網羅しているので、ここではプリモーテム特有の設計に絞る。
プリモーテム・スキルの全体像はこのような6ステップになる。
対象・関係者・成功基準"] --> B["2. フレーミング
『6ヶ月後、失敗した』を明示"] B --> C["3. 生のリスト生成
包括的な失敗理由"] C --> D["4. 並列サブエージェント
各失敗理由を深掘り"] D --> E["5. 統合レポート
最確率／最危険／隠れた仮定"] E --> F["6. 出力
HTML + Markdown"] style B fill:#cc785c,color:#fff style D fill:#cc785c,color:#fff
オレンジ色で強調した2つのステップが、このスキルの肝だ。フレーミング（ステップ2）と並列サブエージェント（ステップ4）を省略すると、それは「単なるリスク評価」になる。順を追って設計を見る。
ステップ1：文脈収集——最小限の閾値
プリモーテムは抽象的な計画には適用できない。「新サービスを立ち上げたい」では具体性が足りず、失敗ストーリーが空想になる。スキルは実行前に最低限の3点が揃っているかを確認する。
- 対象物の明確性: 構築する製品、立ち上げ、採用、価格設定など、判断の対象は何か
- 関係者の特定: 影響を受けるユーザー、チーム、ステークホルダーは誰か
- 成功基準: 何が達成されれば成功と呼べるか（失敗はその逆として定義される）
不足している場合、Claudeは1問ずつ対話的に質問する。3問同時に投げない。これは認知負荷を下げるための設計判断で、ユーザーが各質問に正直に答えやすくする効果がある。
ステップ2：フレーミング——省略不可の宣言
了解しました。プリモーテムを実施します。
前提：6ヶ月後です。このプランは失敗しています。
何が悪かったのか理解しようとしています。
このたった3行が、出力の質を最も大きく左右する。Claudeはこの宣言を経由した後、内部状態として「失敗は確定済み」という立場で残りのステップを進める。
ここを省略すると、ステップ3以降は丁寧なリスク評価になる。スキル設計では、フレーミングを別ステップに切り出して、必ず明示的なテキスト出力として残すことが重要だ。
ステップ3：生のリスト生成
包括的な失敗理由のリストを生成する。各項目は次の3条件を満たす。
- プランの詳細に根ざしている（汎用的な「市場が変化する」ではダメ）
- 特定かつ本物の脅威である
- 1〜2文で簡潔に述べられている
このステップではまだ深掘りしない。網羅性が目的だ。10〜20項目程度に広げる。
ステップ4：並列サブエージェント——深さの確保
ここがプリモーテム・スキルの設計上の核心だ。失敗理由ごとに独立したサブエージェントを並列起動する。各エージェントは1つの失敗理由について以下を生成する。
- 失敗ストーリー: 2〜3段落で、実際に起きた出来事を時系列で詳述
- 根底にある仮定: その失敗を可能にした前提条件（1文）
- 早期警告信号: 観察可能で測定可能な2つの指標
なぜ並列なのか。理由は2つある。
深掘り"] --> S2["失敗2
深掘り"] --> S3["失敗3
深掘り"] end subgraph 並列実行 P0["メイン"] --> P1["失敗1"] P0 --> P2["失敗2"] P0 --> P3["失敗3"] P1 --> Pj["統合"] P2 --> Pj P3 --> Pj end
第1に、コンテキストの混線を避けるため。順次実行すると、前の失敗理由の分析結果が後の失敗理由の分析に影響して、視点が収斂してしまう。並列なら各失敗理由は独立した視点で深掘りされ、互いに関連しない多様な角度の分析が並ぶ。
第2に、時間効率のため。10個の失敗理由を順次深掘りすれば10倍の時間がかかる。並列なら最も遅いエージェントの時間で済む。サブエージェント機能の詳しい使い方は Claude Codeのベストプラクティス完全ガイド2026年版 を参照してほしい。
ステップ5：統合レポート
並列で生成された深掘り分析を、メインエージェントが5つの観点で統合する。
- 最も起こりやすい失敗: 確率順で最優先すべき失敗モード
- 最も危険な失敗: 確率は低いが起きると致命的な失敗モード
- 隠れた仮定: 全分析を通じて共通する最大の前提条件
- 修正プラン: 具体的で検証可能な改善策
- チェックリスト: 実行前に確認・準備する3〜5項目
修正プランは「価格を検討する」のような曖昧な表現ではなく、「20人で$Xの価格をテストしてから確定する」のような検証可能な行動として書く。
ステップ6：出力形式
premortem-report-[timestamp].html # スキャン用ビジュアルレポート
premortem-transcript-[timestamp].md # 詳細な議論記録
HTMLとMarkdownを両方出すのは、用途が違うからだ。次節で詳しく扱う。
並列サブエージェント設計——なぜ段階実行ではなく同時実行か
スキルの実装で最も判断が分かれるのは、ステップ4の並列度をどう設計するかだ。失敗理由が15個あったら15個全て同時に走らせるのか、5個ずつバッチにするのか、それとも順次なのか。
経験的には、並列度は失敗理由の数と一致させるのが正解だ。理由は前述の「視点の独立性」確保にある。バッチを切ると、同じバッチ内のエージェントは事実上ほぼ同時の出力になるが、バッチ間で前のバッチの結果がメインエージェントの状態を経由して漏れることがある。
ただし、Claude Codeのサブエージェントには実行コストとAPI制限がかかる。失敗理由が30個になるような大規模プロジェクトでは、ステップ3の生のリスト生成時点で「最も重要な10個」に絞る前処理を入れるとよい。優先順位は次の表のように決める。
| 優先度 | 判定基準 | 例 |
|---|---|---|
| 高 | 起こると即座に致命的、かつ確率も中以上 | 主要顧客の離脱、データ漏洩、規制違反 |
| 中 | 致命的だが確率低 or 痛いが致命的でない | 競合の追随、内部抗争、技術的負債の表面化 |
| 低 | 起きても回復可能、確率も低い | 軽微なバグ、季節性の売上変動 |
「高」と「中」の上位を合わせて10個程度を並列に深掘りすると、コストと網羅性のバランスが取れる。
並列実行で得られる出力は、メインエージェントが集約する。集約時のプロンプトは「全エージェントの分析を読み、共通項と相違点を抽出せよ」と指示する。共通項が「隠れた仮定」となり、相違点が「最も起こりやすい失敗 vs 最も危険な失敗」の対比軸になる。
agent-prompt.md）に切り出すと再利用しやすい。スキルディレクトリは「フォルダごと知識パッケージ」として扱える設計なので、テンプレート分離は自然な設計判断だ。
出力形式の比較——HTMLレポート vs Markdownトランスクリプト
プリモーテム・スキルが2種類の出力を生成するのは、読み手と用途が違うためだ。
| 観点 | HTMLレポート | Markdownトランスクリプト |
|---|---|---|
| 主な読み手 | 経営層、ステークホルダー、自分の未来 | 実装担当、深掘りしたい本人 |
| 読まれ方 | スキャン（5〜10分で全体把握） | 精読（30分以上、引用しながら） |
| 構造 | カード型、色分け、視覚的階層 | 議事録形式、時系列、全プロンプト記録 |
| 持続性 | プレゼン・共有・PDF出力に向く | 後で再現・追加分析に向く |
| 改修コスト | 高（CSS触る必要） | 低（テキストエディタで編集） |
HTMLレポートは、ダーク背景（#0a0e1aのような深い藍）に各失敗理由を色分けカードで並べる構造を推奨する。なぜダークかというと、プリモーテムの心理的フレーミング（「失敗の事後検死」）と視覚的に整合するためだ。明るい白背景のレポートで「データ漏洩により会社が解散しました」と書くと違和感が大きい。
Markdownトランスクリプトは、ステップ1〜6で交わされたやり取りを全て時系列に記録する。これは将来同じ判断を再評価するときの「素材」として残す。3ヶ月後に「あのとき何を見落としたのか」を検証する際、HTMLレポートだけでは元の文脈が削ぎ落とされていて再現できない。
両方を生成するのは冗長ではなく、用途分離だ。HTMLは「他人に渡すもの」、Markdownは「自分が後で読むもの」と割り切ると設計が明確になる。
適用判断フローチャート——どのプロジェクトで使うべきか
プリモーテムは強力だが、すべての判断に適用するのは過剰投資だ。「ランチに何を食べるか」にプリモーテムを実施しても、得るものより費やす時間のほうが大きい。
判断の目安をフローチャートで示す。
普通に判断"] Q1 -->|訂正に大きなコスト| Q2{"判断ミスのコストは？"} Q2 -->|小さい| OUT2["軽量レビューで十分"] Q2 -->|大きい or 致命的| Q3{"関係者は複数か？"} Q3 -->|単独判断| OUT3["短縮版プリモーテム
3〜5の失敗理由"] Q3 -->|チーム・組織判断| OUT4["フルプリモーテム
10〜15の失敗理由 + 並列深掘り"] style OUT4 fill:#cc785c,color:#fff style OUT3 fill:#d4a574,color:#000
具体的にフルプリモーテムを推奨する場面は次のようになる。
| シナリオ | プリモーテムの効用 |
|---|---|
| 製品・機能のローンチ | 「リリース後に静かに失敗する」シナリオを事前列挙 |
| 採用判断（特に上位ポジション） | 文化フィット・期待値ミスマッチを言語化 |
| 戦略転換・ピボット | 既存顧客への影響、組織の慣性、コミュニケーション失敗 |
| 大規模リファクタリング | テストカバレッジの盲点、移行期間の運用ミス |
| 予算・投資配分 | 機会損失、ROI見積もりの楽観性 |
| パートナーシップ締結 | インセンティブ不一致、出口戦略の欠如 |
逆に、次のような場面では使わない。
- 訂正可能な日常タスク（コード変更、メール返信、設計の小修正）
- 既に十分なポストモーテム蓄積がある反復作業（毎日のデプロイなど）
- 時間制約が厳しく、判断の遅延コストがミスのコストを上回るケース
通常のリスク評価との違い——比較表
プリモーテム・スキルと、よくある「事前リスク評価」「SWOT分析」「リスクマトリクス」を並べて比較する。
| 観点 | プリモーテム | リスク評価会議 | SWOT分析 | リスクマトリクス |
|---|---|---|---|---|
| 中核の問い | 「失敗した、なぜか」 | 「何がリスクか」 | 強み・弱み・機会・脅威 | 確率×影響度の格付け |
| 出力の粒度 | 物語、時系列、固有名詞 | 箇条書き | 4象限のリスト | マトリクス上のドット |
| 心理的バイアスへの効果 | 楽観バイアスを破る | 弱い（既知のリスクの再確認） | 中立 | 数値化により安心感を与える危険 |
| LLMとの相性 | 高（事後分析パターンを呼び出す） | 中 | 中 | 低（数値の根拠が乏しくなりがち） |
| 適した場面 | 後戻り不可の重大判断 | 定期レビュー | 戦略策定の初期 | プロジェクト管理の文書化 |
| 必要な時間 | 30〜90分（自動化で短縮可） | 60分前後 | 30〜60分 | 15〜30分 |
プリモーテムは「物語化の圧力」が他手法と決定的に違う
リスクマトリクスは数値化により逆に安心感を生む副作用がある
LLM自動化との相性が最も高いのがプリモーテム
実装時の落とし穴と対処
プリモーテム・スキルを実装する際、よく踏む地雷を整理する。
落とし穴1：フレーミングを省略してリスク列挙に退化する
最も多いミス。SKILL.mdに「ステップ2: フレーミング」を独立した必須ステップとして書かないと、Claudeが効率化の名のもとにステップ3に直行することがある。明示的に「失敗済みフレーミングのテキストを出力してから次へ進む」と指示する。
落とし穴2：失敗理由の生成数を絞りすぎる
「3〜5個の失敗理由を挙げよ」と指示すると、最も明白な失敗しか出てこない。プリモーテムの価値は「見落としていた失敗」を見つけることにあるので、最初は10〜20個に広げるのが正解だ。深掘りするのはその後で絞る。
落とし穴3：並列サブエージェントを順次に変える
実装の都合で「並列だとコストが心配」と順次実行に変えると、視点の独立性が失われる。コスト対策は並列度を保ったまま「失敗理由を絞る」で対処すべきで、順次化は最後の手段だ。
落とし穴4：修正プランが抽象的になる
「価格戦略を見直す」「コミュニケーションを改善する」といった抽象的な修正は実行に落ちない。修正プランは必ず「20人にテスト価格$Xで提示し、転換率を測る」「リリース2週間前にユーザー上位50人へ事前案内メール」のように、検証可能な行動として書く。
落とし穴5：HTMLレポートを軽視する
「Markdownだけで十分」と思いがちだが、HTMLにする労力は意外に投資対効果が高い。チームで共有する場面、未来の自分が振り返る場面、PDFに出力して経営層に渡す場面で、視覚的階層がある資料は段違いに使われる。Markdownのままだと埋もれる。
まとめ：意思決定の解像度を上げる道具
プリモーテムは、判断の質を上げる道具のなかで最もコストパフォーマンスが高い。実施時間は30〜90分、必要なのは紙とペンだけ（あるいはClaude Codeのスキル1つ）、効果はカーネマンが「最も価値ある」と評するほど大きい。
Claudeでスキル化することの本質的な利点は、再現性と継続学習だ。チームの誰が呼び出しても同じ品質のプリモーテムが走り、過去のレポートはMarkdownトランスクリプトとして蓄積されていく。3ヶ月後、6ヶ月後に「あのとき予見した失敗のうち、いくつ実際に起きたか」を検証する素材になる。
この検証フィードバックがプリモーテム・スキル自身を改善する。「自社の文脈で見落としやすい失敗パターン」をスキル内のテンプレートに追加し、組織固有の事前検死手法に育てていける。スキルがフォルダである意味——それは知識を蓄積するパッケージだから——がここで活きる。
要点を再整理すると以下のようになる。
- フレーミングは省略不可: 「失敗済み」と明示せずに進めると単なるリスク評価に退化
- 並列サブエージェント: 失敗理由ごとに独立した深掘りで視点の多様性を確保
- 2種の出力: HTML（他人に渡す）+ Markdown（自分が後で読む）で用途を分離
- 適用判断: 後戻り不可かつ判断ミスのコストが高い場面に限定
- 修正プランは検証可能に: 抽象的な改善ではなく、具体的な行動と指標を書く
判断を誤る代償が高いほど、判断する前に失敗を見ておくことの価値は跳ね上がる。次にローンチや採用、戦略転換の場面が来たら、判断の前に1時間だけプリモーテムに割り当ててみてほしい。
