Claude CodeでAI参謀チームを作る-スタートアップ経営者のための全32レシピ+CLAUDE.mdテンプレート付き

AI経営者の参謀@ひで

2026/04/19

¥3,980

はじめに -- なぜ「経営者こそClaude Code」なのか、もう概念論はいらない

こんにちは。ひでです。

「経営者はAIを使うべき」「Claude Codeがすごい」。

そういう記事、もう十分読みましたよね。

この記事は概念論をやりません。

Claude Codeを使ってスタートアップ経営の実務をどう回すか、32個のレシピとして全部書きました。

プロンプトはコピペできる形で載せています。

出力例も、Claude Codeが実際に返す内容に近い形で書いています。

読んだその日から使えるように作りました。

この記事が解決する問題

スタートアップ経営者がClaude Codeを使おうとしたとき、ぶつかる壁は3つあります。

1つ目は「プロンプトの書き方がわからない」。

ChatGPTで「事業計画を作って」と聞いてみたことがある人は多いと思います。

でも返ってくるのは教科書的な一般論で、自社の状況に合った内容じゃない。

2つ目は「エンジニアじゃないと使えないと思っている」。

Claude Codeは「コード」という名前がついているけれど、経営業務にこそ使えるツールです。

ターミナルを開いて日本語で指示を出すだけ。

3つ目は「経営業務に特化したレシピ集がない」。

プロンプト集はネットに大量にあります。

でもその多くはエンジニア向けか、一般的な業務効率化の話です。

資金調達、採用、事業計画、ピボット判断 -- こういう経営特有の業務にフォーカスしたプロンプト集は、ほとんど存在しないんですよ。

この記事は、3つ全部を解決します。

既存コンテンツとの違い -- 「批判エージェント」という武器

すでにClaude Code活用の良い記事はいくつか出ています。

梶谷さんの記事は業務OS全般の設計思想として優れているし、他にも体験談ベースの良いコンテンツがあります。

この記事の最大の違いは、全32レシピに「批判エージェント（Devil's Advocate）」を組み込んでいることです。

経営者の周りには、イエスマンが集まりやすい。

社員は気を遣う。

共同創業者にも遠慮がある。

VCには弱みを見せたくない。

結果、自分の判断に対して本気でツッコんでくれる人がいない。

Claude Codeなら、遠慮なく反論してくれます。

「その成長率の根拠は？」「この前提が崩れたらどうする？」「Plan Bがないのは致命的では？」

これが、この記事で繰り返し登場する「批判エージェント」です。

AIに褒めてもらうのではなく、AIに叩いてもらう。

このアプローチが、経営の意思決定の質を一段引き上げます。

Before/After -- Claude Code導入でスタートアップ経営者の1日はこう変わる

Before -- 経営者の典型的な1日

多くのスタートアップ経営者の1日を想像してみてください。

8:00-9:00 業界ニュース・競合動向のチェック（1時間）
9:00-11:00 VC向けピッチ資料の修正（2時間）
11:00-12:00 採用候補者のJD作成（1時間）
13:00-14:30 提案書の叩き台作成（1.5時間）
14:30-16:00 事業計画の数値見直し（1.5時間）
16:00-17:00 投資家向け月次レポートの整形（1時間）
17:00-18:00 社内通知・メール対応（1時間）

合計8時間のうち、「経営者でなければできない仕事」はどれくらいあるか。

正直に言えば、ほとんどが「資料を整える」「情報を集める」「叩き台を作る」作業ですよね。

経営者の時間単価で考えると、この8時間のコスト、馬鹿にならないですよ。

After -- Claude Codeが"AI参謀チーム"になった1日

同じ1日を、Claude Codeを導入した場合で再構成してみますね。

8:00-8:15 業界ニュースのブリーフィング確認（15分。Claude Codeが要約済み）
8:15-8:45 VC向けピッチ資料のレビューと判断（30分。叩き台+批判エージェントのツッコミがすでに出ている）
8:45-9:00 JDの確認・微調整（15分。テンプレートから自動生成済み）
9:00-9:30 提案書の方向性を判断（30分。3パターンの叩き台から選ぶだけ）
9:30-10:30 事業計画の意思決定に集中（1時間。数値の試算+批判的レビューが揃っている）
10:30-10:45 月次レポートの最終チェック（15分。フォーマット整形済み）

午前中で終わります。

午後は、顧客との面談、チームとの1on1、パートナー交渉 -- 経営者にしかできない仕事に使えます。

削減できる時間は、月に換算すると約40時間。

これは「効率化」ではなく、「経営者の時間の再配分」です。

全32レシピの一覧 -- Claude Codeでスタートアップ経営のここまでできる

有料エリアに収録している全32レシピの一覧です。

各レシピにはコピペ用プロンプト、エージェントチーム構成、出力例、カスタマイズのヒントが付いています。

資金調達（4レシピ）

#1 ピッチ資料の構成・ストーリー壁打ち -- シリーズA調達に向けてピッチデックを作り直すとき
#2 VCとの面談準備（想定Q&A生成） -- VC面談の前日に、厳しい質問への切り返しまで用意したいとき
#3 投資家向け月次レポート作成 -- 月初の投資家アップデートを手早く仕上げたいとき
#4 バリュエーション根拠の整理 -- 次回ラウンドの交渉前に算定根拠を固めたいとき

戦略・意思決定（6レシピ）

#5 競合の動向リサーチ+サマリー -- 四半期の戦略会議前に競合の動きを整理したいとき
#6 事業計画の壁打ち・反論役 -- 自分の事業計画に穴がないか、徹底的にツッコんでほしいとき
#7 ピボット判断のフレームワーク整理 -- 事業の方向性に迷いが生じたとき
#8 OKR/KPI設計の叩き台 -- 四半期のOKRを設計する、または初めてOKRを導入するとき
#9 新規事業の市場規模ざっくり試算 -- 新規事業アイデアのTAM/SAM/SOMを概算したいとき
#10 PMF仮説の検証設計 -- PMFに到達したかの判断基準を設計したいとき

組織・採用（5レシピ）

#11 JD（求人票）の作成 -- 新ポジションの採用を開始するとき
#12 面接質問の設計（ポジション別） -- 面接で聞くべき質問と評価基準を整理したいとき
#13 1on1の事前準備（論点整理） -- メンバーとの1on1を実りあるものにしたいとき
#14 評価制度・等級設計の叩き台 -- 評価制度を新設または改定するとき
#15 チーム構成の最適化相談 -- 次に誰を採用すべきかの判断材料がほしいとき

営業・顧客（4レシピ）

#16 提案書・見積書の叩き台 -- 大型案件の提案準備を速く進めたいとき
#17 顧客インタビューの要約+インサイト抽出 -- インタビュー後に構造化された示唆を得たいとき
#18 失注分析（なぜ負けたかの整理） -- 大型案件を落としたとき、本当の原因を掘り下げたいとき
#19 顧客セグメント別のペルソナ整理 -- マーケ戦略の見直しや新機能の優先順位判断をしたいとき

プロダクト（4レシピ）

#20 PRD（要求仕様書）の叩き台 -- エンジニアへの要件伝達で齟齬を減らしたいとき
#21 ユーザーフィードバックの分類・優先順位付け -- フィードバックが溜まって整理できていないとき
#22 ロードマップの壁打ち -- 四半期のロードマップに戦略的な一貫性を持たせたいとき
#23 リリースノート・お知らせ文の作成 -- 新機能リリースやメンテナンス告知を複数チャネル向けに作りたいとき

法務・管理（4レシピ）

#24 契約書のリスクチェック（一次レビュー） -- 取引先から届いた契約書の論点を把握したいとき
#25 利用規約・プライバシーポリシーの叩き台 -- 新サービスのローンチ時に規約の雛形がほしいとき
#26 株主総会・取締役会の議事録整理 -- 法定記載事項を漏らさず議事録を整えたいとき
#27 補助金・助成金の要件チェック+申請書叩き台 -- 補助金の公募を見つけて、自社が対象になるか確認したいとき

日常業務（5レシピ）

#28 朝の経営ブリーフィング -- 毎朝の情報収集を15分に圧縮したいとき
#29 会議のアジェンダ設計 -- 重要な会議を「議題の羅列」から「意思決定の場」に変えたいとき
#30 議事録→ネクストアクション自動抽出 -- 会議後にアクションアイテムを漏れなく整理したいとき
#31 英語メール・海外パートナー対応 -- 海外VCやパートナーとのやり取りをスムーズにしたいとき
#32 ブログ・note・SNS発信の叩き台 -- 経営者としての情報発信を続けたいが時間がないとき

【無料公開】レシピ #6 -- Claude Codeで事業計画を壁打ち・反論役エージェントの全手順（フル版）

32レシピの中で、批判エージェントの価値が最も伝わるレシピをひとつ、無料で全文公開します。

実際にClaude Codeでこのレシピを実行すると、以下のように3つのエージェントが順番に分析し、最後に批判エージェントがVCに突っ込まれるポイントを洗い出してくれます。

このレシピを試してから、残りを購入するか判断してください。

こんな場面で使う

事業計画を見直す場面を想像してみてください。

来期の計画を作っている。

売上予測、ユーザー獲得数、必要な採用人数...。

自分では筋が通っていると思うけれど、共同創業者にも遠慮がある。

VCに見せる前に穴を潰しておきたい。

でも壁打ち相手がいない。

これは多くのスタートアップ経営者が経験する「孤独な意思決定」の典型例です。

エージェントチーム構成

このレシピでは、3名のエージェントチームを組みます。

ビジネスアナリスト: 事業計画の各要素を構造的に分析する。市場環境、競合状況、財務計画の整合性をチェック
マーケットサイジングの専門家: TAM/SAM/SOMの妥当性を評価し、成長率の前提を検証する
批判エージェント（Devil's Advocate）: 計画の全ての前提に対して「本当にそう言えるのか？」と反論する。具体的には「この成長率の根拠は何ですか？類似企業のデータはありますか？」「この前提が崩れた場合のPlan Bが見当たりません」「3年後の市場予測を根拠にしていますが、1年後に前提が変わるリスクをどう評価していますか？」といった指摘を行う

コピペ用プロンプト

まず、CLAUDE.mdに以下を追記してください（一度だけ）。

## 事業計画レビューの方針
- 楽観的な前提には必ず根拠を求める
- 数字の出典が不明な場合は指摘する
- Plan Bがない計画は不完全と判断する
- 「もっともらしいが根拠のない成長率」を見逃さない

次に、Claude Codeを起動して以下のプロンプトを実行します。

以下の事業計画について、3つの視点からレビューしてください。

【事業計画の内容】
・事業概要: [あなたの事業の1〜2行の説明]
・現在のフェーズ: [シード/プレシリーズA/シリーズA]
・現在の主要KPI: [MAU、MRR、チャーン率など、手元にある数字]
・来期の売上目標: [金額]
・前提となる成長率: [月次/年次の成長率]
・必要な採用人数: [人数と職種]
・主な施策: [3つ程度]

【3つの視点でレビュー】

視点1: ビジネスアナリスト
- 事業計画の各要素の整合性をチェック
- 売上目標と施策の因果関係を検証
- 競合環境を踏まえた実現可能性を評価

視点2: マーケットサイジングの専門家
- 成長率の前提が市場環境と整合しているか
- TAM/SAM/SOMの推定が妥当か
- 類似企業の成長カーブと比較して現実的か

視点3: 批判エージェント（Devil's Advocate）
- 全ての前提に対して「なぜそう言えるのか」を問い詰める
- 最もリスクの高い前提を3つ特定する
- 各リスクに対してPlan Bを要求する
- 「この計画で最も楽観的な部分はどこか」を指摘する

最後に、3つの視点を踏まえた総合評価と、計画を改善するための具体的なアクション3つを提示してください。

出力例（抜粋）

上記プロンプトに対して、たとえば「BtoB SaaSで月次成長率15%を前提に来期ARR 1.2億円を目指す」という計画を入力した場合、以下のような出力が得られます。

視点1: ビジネスアナリストの分析

売上目標ARR 1.2億円に対して、現在のMRR 300万円からの到達には月次成長率15%の維持が必要です。ただし、施策として挙げられている「営業チーム増員」と「プロダクト改善」の間に優先順位が不明確です。営業増員のリードタイムを考慮すると、Q1-Q2は既存施策での成長が前提になりますが、その根拠が示されていません。

視点2: マーケットサイジングの専門家の評価

BtoB SaaSの月次成長率15%は、シリーズA前後の企業としては上位10〜25%に入る水準です。SaaS Capitalやchartmogulのベンチマークデータによると、ARR $1M〜$5M帯のSaaS企業の月次成長率中央値は8〜12%程度です。15%を持続的に達成している企業は、明確な競合優位性（技術的moat、独占的チャネル等）を持つケースがほとんどです。御社の競合優位性を具体的に示す必要があります。

視点3: 批判エージェントの指摘

最もリスクの高い前提3つ:

1. 月次成長率15%の持続性 -- 現在の成長率が15%だとしても、MRR 300万→1,000万円のフェーズで同じ成長率を維持できるかは別問題です。顧客単価とチャーンの変動を織り込んでいません。Plan Bとして成長率10%シナリオでの着地点を試算すべきです。

2. 採用計画の実現可能性 -- エンジニア3名、セールス2名の採用を前提にしていますが、採用市場の逼迫を考慮すると、計画通りに採用できるのは半年後以降になる可能性が高い。採用が遅れた場合の施策遂行への影響が未検討です。

3. チャーン率の前提 -- 月次チャーン率2%を前提にしていますが、これは現在の少数顧客での実績値であり、顧客数が増加したときに同じ水準を維持できるかの検証がありません。チャーン率が3%に上昇した場合、ARR達成は大幅に遅れます。