Claude Codeでビジネス戦略を対話する：9専門家パネル分析をAIで回す実践

Claude Codeはコード生成ツールとして語られることが多いですが、ビジネス戦略の壁打ち相手としても強力です。

SaaS企画のピボット判断で、9人の異なる専門家（Christensen、Porter、Drucker、Godin、Kim & Mauborgne、Collins、Taleb、Meadows、Doumont）を演じさせ、同じ意思決定を多角的に検討した記録。技術者が自分ひとりでビジネス判断を下すときの思考プロセスとして有用でした。

なぜ「9人の専門家パネル」か

個人開発者の意思決定の弱点

個人開発では、意思決定の相談相手がいません。自分ひとりで「市場規模」「差別化」「撤退基準」を考えると、得意な視点に偏ります。エンジニアなら技術的な実現可能性を過大評価し、マーケターなら市場性を過大評価する、といった具合です。

これを補うため、異なる専門性の視点を強制的に当てさせるアプローチが有効です。具体的には以下の9人を使いました。

各フレームは書籍や論文で体系化されており、AIに「このフレームで評価してほしい」と指示すると、そのフレームに沿った質問と指摘を返してきます。

実装：プロンプト設計

基本形

1
あなたは以下の9人の専門家パネルです。それぞれの視点から、
2
以下のSaaS企画について「合議制ではなく、各々が独立に」意見を述べてください。
3

4
【SaaS企画サマリー】
5
- ターゲット: EC事業者の管理職以上
6
- 課題: アクセス解析データだけでは売上変動の原因がわからない
7
- 提供価値: 外側（決済エラー・配送遅延・広告タグ）まで横断調査
8
- 検証状況: ヒアリング2件完了、うち1件は方向性支持、1件は懐疑的
9

10
【各専門家に求める観点】
11
- Christensen: 顧客は実際に何のジョブを雇おうとしているか
12
- Porter: 既存の代替手段（コンサル、BIツール、内製）との差別化
13
- Drucker: 「誰の」「何を」解決するのかが明確か
14
- Godin: このプロダクトのトライブ（熱狂的ファン）は成立するか
15
- Kim & Mauborgne: ERRC フレームで価値曲線を描いたとき、どうか
6 collapsed lines
16
- Collins: Hedgehog Concept（情熱/得意/経済）の交点にあるか
17
- Taleb: ブラックスワン（想定外の撤退シナリオ）は何か
18
- Meadows: このシステムのレバレッジポイントはどこか
19
- Doumont: 顧客への説明は1文で伝わるか
20

21
各専門家200-400字で、**反対意見も含めて**出してください。

重要：「反対意見を含めて」を明記する

AIに何も指定しないと、賛成・肯定寄りの意見ばかり返ってきます。**「反証思考で」「弱点を指摘して」**と明示する必要があります。

1
特に以下の観点を含めること：
2
- この企画が失敗するとしたら、どの仮定が崩れたときか
3
- 3年後にピボットを強いられる可能性がある論点
4
- 「やっぱりこれ、他のプロダクトでいいんじゃないか」となる理由

実際のアウトプット例

Christensen視点

顧客が”雇いたい”ジョブは「売上変動の原因を素早く特定する」ではない可能性がある。実際には「上司に説明できる材料が欲しい」が本当のジョブで、その場合はデータの正確さより説明のわかりやすさが価値になる。BIツールのカスタムレポート機能で代替されてしまうリスクがある。

Porter視点

既存の代替手段は3種類：(1)広告代理店のレポート、(2)内製SQLクエリ、(3)BIツールのダッシュボード。差別化ポイントは「外側まで調査する」だが、これが参入障壁になりうるかは不透明。大手BIベンダーが連携を強化すれば吸収される。バーゲニングパワーの弱い領域に見える。

Taleb視点

ブラックスワン候補：(1)主要データソースの仕様変更で連携が壊れる、(2)EC業界の統合で顧客セグメントが消失、(3)AIコモディティ化で「調査」自体が無料化。バーベル戦略として、90%は安全な副業収入（コンテンツ・既存スキル）、10%をこのSaaSに賭ける配分が妥当。SaaSにフルコミットは非対称なリスク。

9視点揃うと、自分では気づかなかった論点が必ず出てきます。上の例だと「Christensenの指摘する”説明できる材料が本当のジョブ”」は、プロダクトを「分析ツール」から「レポート作成ツール」に再定義するべきかという問いを生みます。

ラウンド設計：1回で終わらせない

9専門家を1回呼ぶだけでは浅いです。複数ラウンドで深掘ります。

ラウンド1: 企画全体の評価

上記の基本プロンプト。9専門家が各自の視点でコメント。

ラウンド2: 最も厳しい意見への反論

1
ラウンド1で最も厳しかった意見（Talebの「AIコモディティ化」リスク）
2
について、他の専門家から反論または補強意見をください。

専門家同士を議論させます。Collinsの「Hedgehog Conceptでは独自の情熱・得意・経済の交点が守る」vs Talebの「それでも外部環境変化には脆弱」といった対立が生まれます。

ラウンド3: 具体的な意思決定への翻訳

1
ここまでの議論を踏まえ、以下を決定してください：
2
- 今月のアクション（3つ以内）
3
- 6ヶ月後のGO/WAIT/ABORT判定基準
4
- 撤退トリガー（定量・定性）

抽象的な議論を実行可能なアクションに落とします。ここでDoumontの「1文で伝わるか」が効いてきます。

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

1. 自分の盲点が見える

エンジニアは「作れるか」「技術的に面白いか」を無意識に優先します。DruckerやGodinの視点は顧客中心で、作り手の自己満足を容赦なく指摘してきます。

2. 「次に何を検証すべきか」が明確になる

9専門家がそれぞれ違う仮定を疑うので、検証の優先順位が自動的に見えます。例：「Porterの言う差別化リスクを検証するには、競合3社のデモを触る」「Christensenのジョブ仮説を検証するには、ヒアリング対象を20人→管理職特化に絞る」。

3. 意思決定の記録がそのまま残る

会話ログがすべて残るので、3ヶ月後に読み返して「なぜこの判断をしたか」を思い出せます。個人開発の意思決定は文書化されないことが多く、これは大きな利点です。

落とし穴と対処

落とし穴1: AIが”もっともらしい”だけの意見を返す

対処：具体性を要求します。

1
各専門家のコメントには、以下を必ず含めること：
2
- その専門家が過去に書いた書籍/論文の該当する概念名
3
- 具体例（他のプロダクト・業界の事例）
4
- この企画に対する定量的な基準（数値のある撤退ライン）

落とし穴2: 自分の結論に合わせて誘導してしまう

対処：事前に「どんな結論が出ても受け入れる」と宣言してから始めます。ピボット・撤退の可能性を含めて判断させます。

落とし穴3: ラウンドを回しすぎて疲弊する

対処：3ラウンドで切ります。ラウンド1=評価、ラウンド2=対立、ラウンド3=決定。これ以上やっても精度は上がらず、意思決定が遅れるだけです。

落とし穴4: AIの意見を「答え」と錯覚する

対処：AIは壁打ち相手であって判断者ではありません。最終的な判断は自分がします。AIの出力は「自分の思考を刺激するための材料」と割り切ります。

適用範囲

この手法が効くシーン：

• 個人開発の企画評価・ピボット判断
• 副業/独立の戦略立案
• プロダクトの差別化設計
• 撤退・継続の判断
• 採用・外注の判断

効きにくいシーン：

• 純粋な技術選定（フレームワーク比較など。ビジネス要素が薄い）
• 緊急の障害対応（じっくり議論する時間がない）
• 数値計算やデータ分析（専門家パネルより素直な計算の方が正確）

まとめ

ビジネス戦略の壁打ち相手がいない個人開発者にとって、多視点の専門家パネルをAIで再現するのは極めて効果的でした。コードを書かせるだけではもったいないです。