リーンキャンバスをClaudeで作る — 新規事業の危うい前提を洗い出す手順

新規事業のアイデアは、メモの段階では筋が通って見えます。つまずくのは、そのメモに「顧客は本当にその課題で困っているのか」「お金を払うのか」といった未確認の前提が混ざっていることに気づかないまま、作り始めてしまう場面です。

リーンキャンバスは、この未確認の前提を1枚に並べる道具です。ClaudeのProjectsにアイデアメモと顧客ヒアリングの記録を置けば、キャンバスの下書きと、外れたときの打撃が大きい前提の一覧まで会話で作れます。この記事では、資料の置き方、指示文、前提を検証の順に並べる方法、Claudeの出力を鵜呑みにしないための確認までを順に扱います。

リーンキャンバスは何を1枚にまとめる道具か

リーンキャンバスは、アッシュ・マウリャ(Ash Maurya)が2010年に作った1枚もののビジネスモデル・テンプレートです。アレクサンダー・オスターワルダーのビジネスモデルキャンバスを、極めて不確実な状況で動くスタートアップ向けに改めたものと説明されています。元のキャンバスから、主要パートナー・主要活動・主要リソース・顧客との関係の4ブロックを外し、課題・ソリューション・主要指標・圧倒的な優位性に置き換えた構成です。

基本の9ブロックは次のとおりです。

提供元のページには、「既存の代替手段」「アーリーアダプター」「ハイレベルコンセプト」を加えた12ブロックの版も載っています。最初は9ブロックで十分で、後から足せます。

この道具の狙いは、キャンバスを埋め切ることではありません。埋めた結果として、どのブロックが推測だけで書かれているかが見えるようになることにあります。Claudeに任せる価値も、きれいな清書より、推測と根拠を分けて見せてくれる点にあります。

なぜProjectsに資料を置くのか

通常のチャットに毎回メモを貼り直す方法でも、キャンバスは作れます。ただ、新規事業の検証は数週間かけて資料が増えていく作業です。ヒアリングのたびに記録を足し、キャンバスを更新し、前提の状態を見直します。

Projectsは、チャット履歴とナレッジ(資料の置き場)を持つ独立した作業スペースです。ナレッジに入れた資料は、そのProjectのどのチャットからも使われます。プロジェクト指示を設定すれば、Claudeの振る舞いも全チャットで揃います。無料アカウントを含む全ユーザーが使えますが、無料プランで作れるのは5つまでです。

押さえておく挙動が1つあります。Projectの中でも、チャット同士で文脈は共有されません。ナレッジに追加した情報だけが、別のチャットに引き継がれます。あるチャットでキャンバスを改訂しても、その結果をファイルとしてナレッジに戻さない限り、次のチャットのClaudeはそれを知りません。この制約は、後の手順7で運用に組み込みます。

有料プランでは、ナレッジがコンテキストウィンドウの上限に近づくと、Claudeが自動でRAGモードに切り替えます。容量は最大で約10倍に広がります。ヒアリング記録が十数本に増えても追加できる一方、検索で拾った断片をもとに答える形になるため、特定の発言の引用には確認が要ります。この点はつまずきの節で扱います。

手順の全体像

手順1〜2: Projectを作り、資料を置く

claude.aiの「Projects」を開き、右上の「+ New Project」から作成します。名前と説明を入れる欄がありますが、Claudeはこの2つを見られません。Claudeに伝えたいことは、名前や説明ではなく、プロジェクト指示かナレッジに書きます。

置く資料の例を示します。

00_idea_memo.md        アイデアメモ(誰の何をどう解決するか、自分の言葉で)
01_lean_canvas.md      9ブロックの見出しだけを並べた空のテンプレート
10_interview_A_20261003.txt   ヒアリング記録(1件1ファイル)
11_interview_B_20261005.txt

ファイル名に役割と日付を入れておくと、Claudeに「どの資料のどの発言か」を答えさせるとき、照合が楽になります。ヒアリング記録は、1回のヒアリングを1ファイルにします。複数人分を1つに連結すると、発言者の取り違えが起きやすくなるためです。

アイデアメモは、整えすぎないほうが役に立ちます。「なんとなく良さそう」と思った理由、競合を見て感じたこと、根拠のない数字の見込みも、そのまま書いておきます。推測が混ざっている箇所こそ、Claudeに洗い出してほしい対象だからです。

ヒアリング記録の取り扱い

ヒアリング記録には、相手の氏名や社名、社内事情が含まれがちです。アップロード前に、氏名は「A氏」、社名は「X社」のような記号に置き換えておくと、後から共有範囲を変えるときにも扱いやすくなります。

Team・Enterpriseプランでは、作成時に公開範囲を選びます。「Keep it private」なら、自分と招待したメンバーだけが見られます。組織全体に公開した場合でも、そのProject内で行った自分のチャットは、手動で共有しない限り他のメンバーからは見えません。ただし、ナレッジに置いた資料は、閲覧できるメンバーから読まれます。ヒアリング記録を入れるProjectは、非公開から始めるのが無難です。管理者が公開Projectを無効にしている組織では、組織全体への共有そのものが選べません。

手順3: プロジェクト指示で「根拠か推測か」を固定する

プロジェクト指示は、「Set project instructions」から入力します。保存すると、そのProjectのすべてのチャットに効きます。

キャンバス作成では、次の4点を指示に入れます。

あなたは新規事業の仮説検証を支援するアナリストです。
ナレッジの資料だけを根拠にします。
 
1. キャンバスの各項目には、末尾に必ずタグを付ける。
   [根拠: ファイル名] 資料に書かれている内容
   [推測] 資料に書かれておらず、あなたが補った内容
2. 数字(市場規模、単価、転換率など)は資料にあるものだけを使う。
   資料に無い場合は「未入力」と書き、推定値を作らない。
3. 顧客の発言を引くときは、原文を一字も変えずに引用し、
   ファイル名を添える。要約は引用として扱わない。
4. 「前提」とは、外れたときに事業が成り立たなくなる仮定を指す。
   前提ごとに、外れたときの影響と、現時点の根拠の厚さを書く。

2番目の規則が特に効きます。市場規模のような数字は、Claudeが一般知識から「それらしい値」を出しやすい部分で、そのまま書かれるとキャンバスが根拠のある数字と区別できなくなります。「未入力」と書かせておくと、次のヒアリングで何を聞くかが決まります。

指示の効果は、ここで確かめます。資料を絞った状態で試しに「顧客セグメントを書いて」と頼み、タグが付いて返ってくるかを見ます。タグが付かない、あるいは[推測]が1つも出ない場合は、指示が効いていないか、アイデアメモの情報量が多すぎる可能性があります。

手順4: キャンバスの下書きを作らせる

新しいチャットで、次のように依頼します。

00_idea_memo.md と10番台のヒアリング記録をもとに、
01_lean_canvas.md の9ブロックを埋めてください。
最後に、[推測]タグが付いた項目の数をブロック別に数えてください。

返ってくるキャンバスで最初に見るのは、内容の出来より[推測]の分布です。例えば次のような偏りが出ることがあります(形式を示すための例です)。

この例では、課題はヒアリングで裏づけがあり、収益とチャネルは完全に推測という読み方になります。「顧客は困っている」ことは確かめられても、「払う」「見つけてもらえる」はまだ誰にも聞いていない、という状態です。ヒアリングが課題の確認だけに偏った初期の新規事業では、よく見られる形です。

Claudeが数えた件数は、手元でも数え直します。タグ付けの漏れや、数え間違いが混ざることがあるためです。

手順5: ブロックごとの「はず」を前提台帳にする

キャンバスの各行には、「〜のはず」という前提が隠れています。「購買担当は月に数時間を見積作業に使っているはず」「年間10万円なら払うはず」といった具合です。これを1行ずつ取り出し、台帳にします。

キャンバスの各項目から、暗黙の前提を取り出し、表にしてください。
列は次の5つです。
ID / 前提(「〜のはず」の形) / 関係するブロック /
外れたときの影響(事業が成り立たない / 計画の修正で済む) /
現時点の根拠(資料のファイル名、無ければ「なし」)

台帳の例です。これも形式を示す例で、実際の事業の値ではありません。

「外れたときの影響」の列は、Claudeの判断をそのまま採らず、自分で読み直します。A1が外れれば課題自体が存在しないので、事業は成り立ちません。A3が外れても価格を変えれば続けられます。この差を決めるのは事業の中身を知っている人で、Claudeは叩き台を出す役です。

手順6: 検証の順序と合格ラインを決める

前提が並んだら、どれから確かめるかを決めます。見る軸は2つです。

• 外れたときの影響が「成り立たない」か
• 現時点の根拠が薄いか

両方に当てはまる前提が、最も危うい前提です。上の例ではA2がこれにあたります。ただし、順序は危うさだけで決まりません。前提には依存関係があります。顧客が実在しなければ課題の深さは測れず、課題が深くなければ支払い意欲は聞く意味が薄くなります。A1(課題)が確かめられるまで、A3(価格)を詰めても得るものが少ないということです。

Claudeには次のように頼みます。

前提台帳を、検証する順に並べ直してください。
並べる基準は、(1) 他の前提が成り立つための土台になっているか、
(2) 外れたときの影響が大きいか、(3) 確かめるコストが低いか、の順です。
各前提に「検証方法」と「合格ライン」を添えてください。
合格ラインは、結果を見る前に決められる数値で書いてください。

合格ラインは、結果を見る前に決めることに意味があります。ヒアリングを終えてから基準を決めると、良い結果に都合のよい基準を選びがちです。「10人に聞いて、現行手順を変えてもよいと答えたのが3人以上」のように、数と条件を先に書き込んでおきます。Claudeの案はそのまま採用せず、自分の事業の規模に合わせて数字を調整します。

手順7: ヒアリングの結果を戻して更新する

ヒアリングを終えたら、記録を新しいファイルとしてナレッジに追加し、台帳を更新します。

11_interview_B_20261005.txt を追加しました。
前提台帳の各行について、新しい記録で根拠が増えたもの、
反証になったもの、変化がないものに分けてください。
反証があれば、引用を原文のまま示してください。

更新が済んだら、確定したキャンバスと台帳を、日付付きのファイルとしてナレッジに戻します。たとえば 02_lean_canvas_20261012.md です。チャットの文脈は引き継がれないため、確定版が次のチャットの出発点になります。古い版は残しておき、キャンバスがどう変わったかを後から追えるようにします。

つまずきやすい点

Claudeがキャンバスを「それらしく」埋めてしまう。資料が少ないとき、ブロックはきれいに埋まります。[推測]タグの数が多い状態は異常ではなく、むしろ正しい出力です。タグが一つも付かないほど滑らかなキャンバスは、指示が効いていないか、資料に書かれていない内容を根拠ありとして書いている疑いがあります。タグの付いた引用元ファイルを開いて確かめます。

ヒアリングの引用が原文と一致しない。ヒアリング記録が増えてRAGモードになると、Claudeは資料全体を毎回読むのではなく、関連する断片を取り出して答えます。引用は原文と一字違わないとは限りません。反証として使う発言は、ファイルを開いて検索し、原文と照らしてから台帳に載せます。複数の逐語録を横断して引用を機械で照合する方法は、インタビュー逐語録の横断分析で扱っています。

自分の質問が仮説に寄っている。ヒアリングで「この機能は便利だと思いますか」と聞けば、多くの相手は「はい」と答えます。記録を渡したうえで、Claudeに「質問が答えを誘導している箇所」を挙げさせると、次のヒアリングの質問を直す材料になります。誘導の判定も叩き台にすぎないので、最終判断は記録を読んだ自分で行います。

課題の確認で満足してしまう。台帳の[推測]が収益とチャネルに偏ったまま、課題のヒアリングを重ねても、検証は進みません。偏りが見えた時点で、次のヒアリングの質問を「いま使っている代替手段にいくら払っているか」のような支払いの話へ寄せます。

新しいProjectsの画面と違う。公式の案内では、Projectsの新しい版がベータとして段階的に提供されています。最初の対象は、Claude Codeを使う一部のProとMaxの利用者です。新しい版では、プロジェクトが1つの会話になり、Claudeが作業を並列のスレッドに分けて進めます。チャットとCoworkの既存のProjectsは従来どおり動きます。この記事の手順は、従来のProjectsを前提にしています。Claude CodeのProjectsの変更点は、Claude CodeのProjectsが刷新にまとめています。

手順を回す回数の目安

ひと巡りの流れは、キャンバスの下書き、前提台帳、検証順の決定、ヒアリング、台帳の更新です。1巡ごとに、[推測]の数が減ること、もしくは反証が出て前提が書き換わることのどちらかが起きていれば、検証は前に進んでいます。どちらも起きないまま巡る場合は、ヒアリングの相手か質問が前提に届いていません。

最初のProjectsの使い方から確認したい場合は、Claude Projects完全ガイドが出発点になります。資料が増えたときの挙動は、Claude ProjectsのRAG検索に詳しく書いています。想定問答を作って練習する使い方は、価格交渉の値引き条件と想定問答が近い手順です。

まとめ

リーンキャンバスをClaudeで作る価値は、清書の速さより、推測がどこに溜まっているかを可視化できる点にあります。資料を根拠か推測かで仕分けさせ、推測を前提に分解し、危うい順に確かめる。この流れを回すと、新規事業の最初の数週間で何を聞きに行くかが具体的になります。

Claudeが出すのは叩き台です。外れたときの影響の大きさも、合格ラインの数字も、事業を知っている人が決めます。ヒアリングの引用は原文で確かめ、確定したキャンバスはファイルとしてナレッジに戻す。この2つを守れば、Projectsは検証の記録を積み上げる場所として使えます。