ビジネスモデルキャンバスの書き方｜9要素を仮説検証へつなぐ記入例

結論｜ビジネスモデルキャンバスは顧客と価値から書き始める

ビジネスモデルキャンバスは、9つの要素を順番どおりに清書する書類ではありません。誰にどの価値を届け、どう収益を得て、何を実行する必要があるかを一枚で仮置きする道具です。本稿では、依存関係を追いやすくするため、顧客側から実行側へ進む順序を推奨します。

最初に顧客セグメントと価値提案を置き、届け方、関係、収益へ進みます。その後、価値提供に必要なリソース、活動、パートナーを考え、最後にコストと収益が釣り合う条件を確認します。全体は、次の四段階です。

この4段階は、作成順を固定するためではなく、前の仮説を次の要素で確かめるための読み順です。途中で支払者や必要工数が合わないと分かったら、顧客セグメントや価値提案へ戻って書き直します。

完成の目安は全枠が埋まったことではなく、重要な記述がどの要素とつながり、何が未確認かを説明できることです。 空欄があれば「未確認」として残し、何を調べれば書けるのかを添えます。もっともらしい言葉で埋めるより、分からないことが見える方が次の行動を決めやすくなります。

Strategyzerの公式解説は、ビジネスモデルキャンバスを、事業モデルの説明、設計、検討、発明、変更に使う戦略・起業のための道具としています。一方で、9要素を埋める唯一の順番は示していません。本記事の順序は公式手順の引用ではなく、顧客から経済性までのつながりを確認しやすくする実務上の推奨です。

ビジネスモデルキャンバスとは｜9要素と全体構造

ビジネスモデルキャンバスは、事業が価値を生み、顧客へ届け、収益を得る仕組みを9つの要素で可視化します。中央に価値提案、右側に顧客へ届ける仕組み、左側に価値を作る仕組み、下部に収益とコストを置くことで、事業全体を同じ面で確認できます。

9要素には、それぞれ独立した説明を書くのではなく、隣り合う要素との関係が分かる言葉を置きます。たとえば収益の流れには「月額課金」とだけ書かず、どの顧客が何の価値へ、どの単位で支払うかを書きます。

9要素の価値は、項目を漏れなく並べることより、事業の因果関係を一枚で照合できることにあります。 価値提案を変えれば、必要な活動、届け方、価格、費用も変わる可能性があります。更新した要素だけを見るのではなく、影響を受ける要素へたどってください。

ビジネスモデル全体の考え方や収益モデルの選択を先に整理したい場合は、新規事業のビジネスモデル設計も参照できます。本記事では、構想を9要素へ実際に書き込み、検証へ渡す方法に焦点を絞ります。

書き始める前に決める3つの前提

キャンバスへ書き始める前に、「何を対象にするか」「どの時点を描くか」「記述の確度をどう示すか」をそろえます。ここが曖昧だと、ある人は現在の事業、別の人は三年後の構想を書き、同じ枠に事実と希望が混在します。

準備で長い資料を作る必要はありません。キャンバスの上部に対象、時点、版を記載し、付箋や記述へ事実・仮説・未確認の印を付けるだけでも、議論の前提を合わせられます。

一枚のキャンバスには、同じ顧客・価値・収益・実行条件で説明できる事業モデルだけを置きます。 顧客ごとに課題、購入経路、価格、提供方法が大きく違うなら、最初から別のキャンバスへ分けます。無理に一枚へ統合せず、後から比較する方が違いは明確です。

作業用の配置はStrategyzerの公式キャンバスPDFで確認できます。公式キャンバスを転載・改変して公開物へ使う場合は、Strategyzerが示すクレジット条件を確認してください。本記事内で独自の図解を作る場合も、元の枠組みを使う箇所には出典を明記します。

参加者がいる場合、書き始める前の用語統一も必要です。「顧客」が利用者を指すのか、契約者や支払者まで含むのか、「チャネル」が販売経路だけか、提供や支援の接点も含むのかを確認します。定義をそろえれば、表現の違いを事業上の対立と誤認しにくくなります。

ビジネスモデルキャンバスの書き方｜9要素の推奨順

公式に固定された唯一の記入順はなく、本記事で示すのは実務上の推奨順です。本記事では、新規事業で自社資産や製品案だけが先に固まることを避けるため、顧客セグメントと価値提案から始めます。その後、顧客が価値へ到達し支払う流れを置き、価値を作る実行条件とコストへ進みます。

各段階では、前の要素を確定事項として扱いません。後の要素を書いた結果、顧客や価値の前提が不自然だと分かれば戻って修正します。順番は思考を助ける案内であり、後戻りを禁止する工程ではないからです。

推奨順を使う目的は、各要素を機械的に埋めることではなく、前の仮説が次の要素で成立するかを連続して確かめることです。 たとえば個別の導入支援を顧客との関係へ置いたら、主要活動に支援業務、主要リソースに担当者、コスト構造に一社当たりの工数が必要です。どこにも影響しない記述は、具体性が足りないか、主要要素ではない可能性があります。

既存事業を見直す場合は、収益やコストから逆にたどる方法もあります。利益を圧迫する活動を特定し、それがどの顧客関係や価値提案に必要なのかを確認します。どこから始めても、顧客、価値、収益、実行条件を一つの流れとして読み直す点は共通です。

最初の版は、短い言葉を一枚一項目で置く形が基本です。長い説明を一つの付箋へまとめると、どの部分を検証して更新したか分からなくなります。「顧客」「状況」「価値」「証拠」を必要に応じて分け、関連する付箋を同じ色や識別子で結びます。

ビジネスモデルキャンバスの顧客側5要素は、支払うまでの流れで書く

顧客側では、誰に何を届けるかだけでなく、価値へ到達して支払うまでの流れを描きます。BtoBでは利用者、導入担当者、決裁者、契約者、支払部門が異なる場合があります。「顧客企業」と一語でまとめず、役割と場面を分けてください。

価値提案は、製品機能の一覧とは別物です。顧客が現在行っている行動、抱える制約、導入後に変わる結果を短く書きます。チャネルと顧客との関係は、販売時だけでなく、認知、比較、導入、利用、継続までの接点として整理します。

1．顧客セグメントは企業属性ではなく、役割と困る場面を書く

「大企業」「製造業」だけでは、誰の判断を変える価値か分かりません。たとえば「複数拠点の月次報告を集め、確認の往復を担う本社事業管理者」のように、役割と課題が起きる場面まで書きます。BtoBでは利用者、導入担当者、決裁者、契約者、支払部門が異なるため、同じ会社でも役割を分けてください。

2．価値提案は機能ではなく、顧客の行動や結果の変化を書く

「高機能で使いやすい」だけでは、導入前後の変化が不明です。「拠点ごとの報告形式をそろえ、本社と拠点の確認往復を減らす」のように、導入前後の変化を書きます。その変化が支払う理由になるかを、収益の流れと照合します。

3．チャネルは認知・比較・購入・提供・継続に分ける

「Web」「営業」とだけ書かず、顧客が知ってから使い続けるまでの接点を段階別に置きます。たとえば「既存顧客面談で認知、限定試用で比較、オンライン導入、月次支援で継続」と書けば、各段階の担当者と費用を主要活動・コスト構造へつなげられます。

4．顧客との関係は、関わる人・頻度・終了条件を書く

「手厚いサポート」では必要工数を見積もれません。「初期設定は導入担当者が個別支援し、定着後は共通手順へ移す」のように、誰が、どの頻度で、いつまで関わるかを書きます。個別支援が続くなら、主要活動・人員・価格にも反映が必要です。

5．収益の流れは、支払者・課金単位・支払時点をそろえる

「サブスクリプション」だけでは、収益が生まれる条件を確認できません。「本社部門が、利用拠点数に応じ、年単位で支払う」と書きます。利用者と支払者が違う場合は、支払者が何を確認すれば契約・更新するのかも仮説として置いてください。

顧客側の5要素は、「誰のどの変化に対して、誰がどの経路で支払うか」を一続きで説明できる状態にします。 利用者の評価が高くても、支払者の課題や承認条件が別なら、収益の流れは未確認です。利用者と支払者を線で結び、両者へ届くチャネルを確認します。

顧客セグメントと価値提案を詳しく検討するときは、バリュープロポジションキャンバスの使い方へ分けて考えられます。そこで得た顧客の仕事、困りごと、期待する結果を短く戻し、BMCではチャネル、収益、実行条件まで接続します。

収益の流れには、希望価格だけでなく支払いが発生する条件を書きます。契約時、利用開始時、成果発生時など、顧客が何を確認したら支払うのかを置きます。無料試行を含む場合は、誰がどの条件で有償へ移るのかを仮説として分けてください。

実行側の4要素｜資源・活動・パートナー・コストを書く

実行側では、顧客側で仮置きした価値を本当に作り届けられるかを確認します。自社が持つ資産をすべて並べるのではなく、特定の価値提案、チャネル、顧客との関係に欠かせないものだけを主要要素として残します。

リソースと活動は分けます。技術、データ、人材、設備、顧客接点はリソースであり、それらを使って開発、提供、支援、改善することが活動です。パートナーには会社名だけでなく、何を補完し、どの条件へ依存するかを記載します。

1．主要リソースは、価値提供に不可欠な資産だけを残す

保有資産の一覧ではなく、特定の価値を作り届けるために欠かせない人材、技術、データ、設備、顧客接点、権利を書きます。保有していても、利用権限・品質・更新頻度が条件を満たさなければ「使えるリソース」ではありません。

2．主要活動は、価値と収益に直結する仕事を書く

開発、販売、初期設定、提供、支援、改善など、顧客価値の実現に必要な活動を書きます。誰が、いつ、どの頻度で行うかまで置くと、顧客が増えたときに個別対応が増え続けないか、必要人員を確保できるかを判断できます。

3．キーパートナーは、補完する役割と依存条件を書く

「候補企業と連携」だけでは、実行可能性が不明です。相手が補う資源・活動、責任分担、費用、データや成果物の扱い、切り替え条件を書きます。相手の協力が得られなければ成立しない要素は、未確認の重要仮説として扱います。

4．コスト構造は、収益と同じ顧客単位・期間で比べる

開発費だけでなく、顧客獲得、初期設定、利用支援、保守、外部連携の費用を、初期費・固定費・変動費に分けます。顧客一社または一拠点を増やしたときの収益と費用を同じ期間で比べると、価格や提供方法のどこを検証すべきかが見えます。

実行側の記述は、「自社に何があるか」ではなく、「顧客価値を成立させるために何が必要か」から選ぶことが基本です。 価値提案へ結び付かない資産や活動は、主要要素から外すか、なぜ必要なのかを再確認します。逆に、顧客へ約束した関係や提供方法に必要な活動がなければ、顧客側へ戻って修正します。

コストは、予算総額だけでは接続が不明です。顧客を一社増やしたときに増える費用、利用がなくても発生する費用、検証段階だけに必要な費用を分けます。収益と単位をそろえることで、価格や提供方法の仮説をどこから検証するかが見えます。

パートナーへ依存する場合、相手が提供する資源や活動、こちらが負う責任、切り替えに必要な条件の明示が必要です。「候補企業と連携」と書くだけでは実行可能性を判断できません。契約、データ利用、品質、納期、知的財産など、成立に必要な確認事項を未検証仮説として残します。

記入例｜架空のBtoBサービスをビジネスモデルキャンバスへ整理する

ここでは、複数拠点から月次報告を集める本社部門を支援する架空のサービスを例にします。実在企業や実在サービスの分析ではなく、各要素の粒度と接続を示すための例です。記述は確定情報ではなく、顧客確認や提供検証によって更新する初期仮説として扱います。

例では、利用者と支払者を分け、価値提案から収益・活動・コストへつながるように書きます。一つの欄だけを読んでも完結させず、どの要素を前提にしているかが分かる表現にします。

記入例で重要なのは、各欄の文章のうまさではなく、一つの仮説が外れたときに変更する欄を追えることです。 たとえば「初期支援後は共通手順へ移れる」が外れれば、顧客との関係だけでなく、主要活動、必要人員、コスト、価格を見直します。関連する付箋へ同じ識別子を付けると影響範囲を追いやすくなります。

例を自社へ置き換える際は、企業名や製品名だけを差し替えないでください。顧客が困る具体的な場面、現在の代替、支払者、提供に必要な活動を自社の事実から書き直します。分からない箇所は空欄のままにせず、「誰に何を確認するか」を添えた未確認項目へ変えます。

一枚に複数の顧客案を置きたい場合、まず別々のキャンバスから始めるのが基本です。その後、価値提案、チャネル、価格、活動が共通する部分だけを比較します。統合を先に行うと、どの顧客のための価値とコストなのかが読めなくなります。

作成後のビジネスモデルキャンバスは、事実・仮説・未確認を分ける

9要素を書き終えた後は、文章を整える前に記述の確度を分ける段階です。確認済みの事実には、対象、取得日、観測した行動や記録を付けます。仮説には、何が起きれば支持または修正するかを書き、未確認には情報源と確認担当を置きます。

欄単位ではなく、付箋や一文単位で状態を分けることが大切です。同じ価値提案の中でも、困りごとの存在は確認済みで、支払意思や提供コストは未確認ということがあります。

作成後の最初の仕事は、最も危険な仮説を一つ選び、証拠を得る方法と結果に応じて変える要素を決めることです。 外れたときに顧客、価値、収益など複数の要素が崩れる仮説、現時点で確度が低い仮説を優先します。書きやすい要素から検証するのではなく、判断への影響で選びます。

Strategyzerの仮説検証に関する公式解説は、事業案を顧客にとっての魅力、実行可能性、経済的な成立可能性などの仮説へ分け、重要な仮説から実験する考え方を示しています。BMCの記述は証拠そのものではないため、顧客の行動、試用、契約、提供工数など観測可能な情報へ結び付けます。

検証計画には、次の項目を含めます。

• 確かめる仮説と、対応するキャンバスの要素
• 仮説が成立すると考えた根拠と、まだ分からないこと
• 観測する顧客行動、提供結果、費用などの証拠
• 実施担当、対象、期限、記録場所
• 結果に応じて継続、修正、保留を判断する条件

具体的な検証設計は新規事業の仮説検証も参照できます。検証後は結果だけを報告せず、どの要素をどう変えたかを版として残します。変更しなかった場合も、その判断に使った証拠を記録してください。

ビジネスモデルキャンバスで起きやすい5つの間違い

書き方の間違いは、要素名を覚えていないことより、粒度や接続がそろっていないことで起きます。Strategyzerの公式解説も、適切な粒度、要素間の明確なつながり、具体的な言葉、現在と将来、事実と仮説の区別を確認項目として挙げています。

以下の5つを、完成前のチェックとして使います。一つでも当てはまる場合は、言葉を追加する前に対象と接続を見直します。

1．一枚に複数の事業を混ぜると、誰のためのモデルか読めない

顧客ごとに価値・価格・活動が違う案を一枚へ入れると、どの収益とコストが対応するか追えません。顧客・価値・収益の組み合わせが違う案は分けて作り、後から共通部分を比較します。

2．抽象語だけで埋めると、次に何を確かめるか決まらない

「高品質」「効率化」「デジタル」「連携」は方向性であって、検証できる記述ではありません。対象・行動・条件・単位を加え、何が起きれば正しいと言えるかまで書きます。

3．9要素を別々に書くと、前提が外れた影響を追えない

収益の流れに対応する支払者や価値提案がなければ、数字だけが独立します。関連する付箋へ同じ色や識別子を付け、顧客から価値、収益、活動、コストまで一続きで説明します。

4．現在と将来を混ぜると、今できることを誤認する

現在保有する資産と取得予定の資産、現行の顧客関係と目標の関係を同列に置くと、実行可能な範囲が分かりません。現状版と目標版を分けるか、色と凡例で状態を区別します。

5．仮説を事実として扱うと、投資判断が期待に寄る

顧客ニーズや支払意思に根拠がないのに断定すると、確認すべき前提が見えなくなります。記述ごとに事実・仮説・未確認を分け、対象、取得日、観測した行動、次の確認方法を残します。

読みやすいキャンバスは、情報量が多い一枚ではなく、重要な要素とそのつながりを短い言葉で説明できる一枚です。 詳細な仕様、調査記録、計算根拠は別資料へ置き、キャンバスから参照できるようにします。BMCだけですべての事業情報を表そうとしないでください。

もう一つの見落としは、更新履歴を残さないことです。色を変えるだけで上書きすると、どの証拠で前提を変えたか分かりません。版、更新日、変更理由、判断者を残し、前の版と比較できる状態にします。

作成したキャンバスを説明するときも、一度に全体を見せて読み上げる必要はなく、要点から示す方が明快です。Strategyzerの公式解説は、顧客、価値、収益、必要な活動などを論理的な物語として順に結ぶことを勧めています。発表用には、中心となる接続を一つずつ示し、詳細は質疑や別資料へ分けます。

リーンキャンバス・VPC・事業計画書との使い分け

BMCは、すべての問いに答える万能な書式ではないからです。顧客の課題と価値を深く理解したいとき、初期の課題・解決策を絞りたいとき、実行計画や資金計画を詳細化したいときでは、適した道具が異なります。目的に応じて行き来し、同じ情報を形式だけ変えて重複記入しないようにします。

使い分ける基準は、事業の段階だけではなく、今答えたい問いです。BMCで価値提案が曖昧だと分かればVPCへ戻り、重要仮説を早く整理したければリーンキャンバスを使い、証拠が増えて実行条件を固める段階では事業計画書へ展開します。

道具を使い分ける目的は資料を増やすことではなく、現在の不確実性へ最も具体的に答えられる問いを選ぶことです。 BMCで空欄が見つかったら、それを別の書式で埋めるのではなく、顧客確認、実行条件の調査、費用の試算など必要な行動へ変えます。

BMCと事業計画書は、役割の異なる資料です。BMCは全体の仮説と接続を短く共有するのに向き、事業計画書は実行方法、体制、資金、期間を詳しく定めるのに向きます。キャンバスの前提が変わったら、詳細計画のどこへ影響するかも更新します。

道具を行き来するときは、同じ顧客セグメントや価値提案へ共通の識別子を付けます。表現が少し違うだけで別の仮説に見えることを防ぎ、どの資料が現在の判断根拠かを明示できます。

よくある質問

ビジネスモデルキャンバスの順番、空欄、顧客の分け方、記述量、更新時期について、実務で迷いやすい点へ回答します。

Q. ビジネスモデルキャンバスを書く順番は決まっていますか

A. 公式に固定された唯一の順番はなく、本記事で示すのは実務上の推奨順です。本記事では、顧客と価値を起点に、届け方・関係・収益、実行条件、コストへ進む順番を推奨しています。既存事業の採算を見直す場合は収益やコストから始めても構いません。どの順で始めても、最終的には9要素のつながりを確認してください。

Q. 空欄が残っていても問題ありませんか

A. 空欄そのものは問題ではありません。分からないのに推測で埋めると、仮説が事実に見える方が危険です。「未確認」と明記し、確認先、質問、担当、期限を書きます。次の会議では、埋まった枠の数ではなく、重要な空欄へ必要な証拠が増えたかを確認します。

Q. 複数の顧客セグメントを一枚に書けますか

A. 価値提案、チャネル、支払条件、主要活動がほぼ共通なら、一枚で関係を示せます。ただし役割や購買の流れが大きく違う場合は、顧客ごとにキャンバスを分けてください。別々に作った後で共通部分と違いを比較すると、統合できる範囲を判断しやすくなります。

Q. 一つの要素にはどこまで詳しく書けばよいですか

A. 会議の参加者が意味を同じように理解し、他の要素との接続を説明できる粒度が目安です。「営業」「効率化」だけでは曖昧ですが、長い仕様書を貼る必要もありません。顧客、行動、条件、単位を短く置き、証拠や計算の詳細は参照資料へ分けます。

Q. ビジネスモデルキャンバスはいつ更新しますか

A. 重要な仮説に関する新しい証拠を得たとき、顧客・価格・提供方法・パートナーなどの前提を変えたときに更新します。定例会議の日まで待つ必要はありません。更新日、変更前後、根拠、判断者を残し、変更した要素から影響先へ順に確認してください。

まとめ｜ビジネスモデルキャンバスを検証可能な仮説へ変える

ビジネスモデルキャンバスの書き方で重要なのは、9要素を空欄なく埋めることではありません。顧客と価値から始め、届け方、収益、実行条件、コストをつなぎ、未確認の前提を見つけることです。記入順は公式に固定されていないため、事業の目的に合わせて使いながら、後戻りして修正します。

• 対象、時点、事実・仮説・未確認の区別を決めてから書く
• 顧客セグメントでは利用者、決裁者、支払者を分ける
• 価値提案は機能ではなく、顧客の行動や結果の変化として書く
• 顧客との関係を主要活動・人員・コストへ接続する
• 収益とコストは同じ顧客単位・期間で比較する
• 作成後は重要仮説、証拠、担当、期限、判断条件を決める

一枚の情報量を増やすほど、良いキャンバスになるわけではありません。重要な仮説を短く置き、詳細は別資料へ分けます。顧客や提供条件が違う案はキャンバスを分け、比較した後に共通部分だけを統合してください。

最初の一歩は、顧客セグメントと価値提案を一つずつ仮置きし、利用者・決裁者・支払者と、次に確かめる行動を書き添えることです。 その二つからチャネル、収益、活動、コストへ線を伸ばし、つながらない記述を未確認仮説として検証へ移してください。