「Web3で新しい事業を考えたい。でも、誰から何の対価を受け取ればよいのだろう」
NFTやトークンの活用案は浮かんでも、売上と運営費を並べるところで手が止まることがあります。
私たちOMK編集部が事業の設計でまず整理したいのは、顧客が使い続ける理由と、その価値を届け続けるためのお金の流れです。
Web3のビジネスモデルは、顧客・提供価値・収益源・費用を一組にして考えます。
この記事では、主な収益方式を比較し、事業者の立場ごとに売上を分ける方法と、小さく検証する手順を紹介します。
読み終えたら、自社の案を一枚の設計メモへ落とし込み、次に確かめる数字まで決められます。
- 顧客・提供価値・収益源・費用を一組で整理する。
- 取引総額、自社の売上、ネットワーク手数料を分けて見る。
- 利用者数が少ない場合も計算し、継続利用と対応費を検証する。
Web3のビジネスモデルとは
Web3のビジネスモデルとは、ブロックチェーンなどを使って顧客へ価値を届け、対価を受け取り、運営を続ける仕組みです。
Web3には一つの厳密な定義があるわけではありません。ethereum.orgは、ブロックチェーンや暗号資産、NFTなどを通じた利用者の所有を、その考え方の中心に挙げています。[1]
ただし、技術の特徴を書き並べるだけでは、事業として誰の困りごとを解決するのかが見えません。
たとえば、複数の施設で使えるデジタル会員証を考える場合、利用者にとっての価値は、会員資格の確認や特典の利用が分かりやすくなることです。
施設側には、参加施設をまたいだ資格確認を行いやすくする価値が考えられます。どちらを顧客にするかで、課金先も必要な機能も変わります。
利用者から会費を受け取る案と、施設から管理システムの利用料を受け取る案を、最初から別々に書いてみましょう。
仕組みの説明を、顧客の行動へ置き換える
「NFTを発行する」という説明は、提供する仕組みを表しています。
事業の説明へ進めるには、「誰が、いつ、何をできるようになるか」を足す必要があります。
たとえば、イベント参加者が持つ証明を、別の主催者も確認できる設計なら、何を共通化し、誰が確認を引き受けるかが論点になります。
確認するだけなら既存のデータベースで足りるのか、複数の運営者が共通の記録を参照する必要があるのかを比較します。
ここでWeb3を使う理由が説明できると、開発すべき範囲と、利用者へ説明すべき内容が具体的になります。
技術そのものの全体像は、Web3とは何かを解説した記事で確認できます。
主な収益方式を、誰が払うかで比較する
ここでは企画を整理するため、収益方式を四つに分けます。業界全体を網羅する分類ではなく、自社案を比較するための枠組みです。
| 収益方式 | 主な支払者・対価 | 確かめる点 |
|---|---|---|
| 販売 | 購入者/コンテンツや利用権 | 販売後の提供期間・費用 |
| 継続課金 | 利用者・契約企業/継続的な機能や支援 | 更新の理由・継続率 |
| 取引手数料 | 取引参加者/取引の場や成立支援 | 成立額・料率・一件の対応費 |
| 基盤・支援 | 導入企業/基盤の利用や導入・運営支援 | 利用量・対応範囲・必要人員 |
同じサービスで複数の方式を組み合わせることもできます。ただし、最初の検証では中心となる支払者と対価を一つ決めると、結果を読み取りやすくなります。
販売型は、買った後に提供する内容まで決める
デジタルコンテンツや利用権を販売する場合、購入時に何を渡し、その後に何を提供するかを分けて書きます。
一度の販売で継続的なサポートまで約束すると、販売後も費用が続きます。提供期間、利用回数、問い合わせの範囲を価格とセットで考えましょう。
発行数を増やせば売上が増える、という前提だけでは、対応人数やサービスの供給能力が計画から抜け落ちます。
先に提供できる数量を確認し、その範囲で価格と販売数を検証します。
継続課金型は、更新時にも価値があるかを見る
月額利用料や年会費を設けるなら、顧客が次の期間にも対価を払う理由を明らかにします。
初回登録の便利さだけでなく、継続中の機能、更新される内容、日々の運営負担の軽減などが検証対象になります。
契約数と利用実態を分けて見れば、料金を払っているものの使われていない状態にも気付けます。
会員証そのものの導入条件や特典運用は、NFT会員証の企業導入で詳しく扱っています。
取引手数料型は、取引総額と自社売上を分ける
取引の場を提供し、成立した取引から手数料を受け取る場合、扱った金額のすべてが運営会社の売上になるわけではありません。
たとえば計算例として、取引総額が100万円、運営会社の手数料率が5%なら、手数料は5万円です。100万円を運営会社の収益力として比較しないようにします。
手数料の対象がどの取引なのか、取消時に返すのか、決済や送金の費用を誰が負担するのかも必要な条件です。
取引数だけでなく、一件を成立させるためにかかる対応費まで確認すると、運営上の負担が見えてきます。
基盤・支援型は、利用量と対応範囲を合わせる
他社のWeb3サービスを支える基盤や運営支援も、事業案になります。
たとえばAlchemyの公式料金ページには、利用量に応じた課金と法人向けプランが掲載されています。これは基盤の利用を対価にする実例です。[2]
自社で同様の案を考える際は、処理量だけでなく、問い合わせ対応、障害時の連絡、契約上の提供範囲も整理します。
導入支援と月々の運用支援を分けて見積もれば、初期作業と継続作業のどちらに人手が必要かを確認できます。
売上の受取人と、費用の負担者を分ける
Web3の事業では、利用者、サービス提供者、販売の場を運営する会社、ネットワークなど、複数の相手が関わります。
同じ支払いの説明でも、誰の立場から見るかによって売上と費用が変わります。
お金の流れは、相手の名前と受け取る理由まで書いて確認します。

作成:OMK編集部。本文の事業設計・検証手順を図解。
ネットワーク手数料は、サービス利用料と別に確認する
Ethereumでは、処理に必要な計算資源に対する費用としてガス代が発生します。実行に失敗した取引でも、処理に使ったガスの費用がかかる場合があります。[3]
サービス利用料に何が含まれるかを決める際は、ネットワークで処理する費用を誰が負担するかも確認してください。
利用者が払う設計なら、操作前に費用が分かる導線が必要です。事業者が負担する設計なら、利用回数が増えたときの支出を見積もります。
利用者に無料と案内する部分も、事業全体では費用の負担先を残しておきます。
二次流通のロイヤリティは、受取条件を確かめる
NFTが再販売されるたびに、必ず作り手へ収益が入ると想定するのは避けましょう。
ERC-2981はロイヤリティの金額や受取先を伝えるための標準ですが、支払い自体は任意であることを明記しています。[4]
計画へ組み込むには、利用する販売先の対応、契約条件、実際に受け取れる取引の範囲を確認する必要があります。
基本計画では初回販売やサービス利用の対価を整理し、二次流通による受取額は条件を分けて検討すると、前提の違いが見えやすくなります。
トークンの価格と、顧客から得る対価を混ぜない
顧客がサービスへ支払った金額と、自社が保有するトークンの価格変動は、事業の評価では分けて追います。
価格が上がったときだけ運営を続けられる計画では、サービスそのものが顧客に選ばれているかを判断しにくくなります。
独自トークンを設計するなら、利用上の役割、発行する必要性、配布後に維持する仕組みを先に言葉にしてみてください。
法令や会計上の取扱いは、名称だけで決めず、権利の内容や販売方法などを整理して専門家へ確認します。
小さな計算例で、続けられる条件を見る
ここからは、月額サービスを検討するための仮定を置いた計算例です。実在企業の業績や料金相場を示すものではありません。
月額2,000円で100人が利用し、決済などの変動費を売上の5%、一人当たりの提供費を600円、月間の固定運営費を8万円とします。
| 項目 | 計算 | 月間金額 |
|---|---|---|
| 売上 | 2,000円×100人 | 200,000円 |
| 売上連動費 | 売上×5% | 10,000円 |
| 提供費 | 600円×100人 | 60,000円 |
| 固定運営費 | 月額の仮定 | 80,000円 |
| 上記費用控除後の差額 | 売上−上記三つの費用 | 50,000円 |
この条件で残る5万円は、表に入れた費用を差し引いた差額です。初期開発費、税金などを含む最終的な利益ではありません。
ネットワーク手数料や問い合わせ対応をどの費目へ入れたかも、見積もり時に明記します。別途発生するものがあれば計算へ追加してください。
利用者数が少ない場合も計算する
同じ単価と費用条件で利用者が50人なら、売上は10万円、売上連動費は5,000円、提供費は3万円です。
固定運営費8万円を引くと、差額はマイナス1万5,000円になります。100人のときだけを見ると、この不足が隠れてしまいます。
一人増えたときに残る額は、2,000円から100円と600円を引いた1,300円です。
この条件を一定と置くと、固定運営費8万円を上回るには62人が必要です。62人では差額600円となり、追加費用を吸収する余裕は小さいことも分かります。
人数が増えたときに人員やシステムの追加費用が発生するなら、その人数から条件を変えて計算し直します。
売上が立つ時期と、支払う時期も揃える
年間契約で先に代金を受け取る案では、入金後も一年分のサービス提供が続きます。
入金額だけを見て余裕があると判断せず、今後の提供費に充てる分を月ごとに並べておくと、必要な資金を考えやすくなります。
逆に、開発会社への支払いが先で顧客からの入金が後なら、開始時に必要な資金を別に用意する必要があります。
収益の見込みと、支払期日に用意できるお金の両方を確認しましょう。
Web3を使う範囲を、既存の方法と比較する
事業案がまとまったら、同じ価値を会員サイトや通常のデータベースでも提供できるかを比較します。
比較の目的は、顧客の行動を改善する部分へ開発と運営の費用を使うことです。
| 比較する点 | 既存の方法で考える案 | Web3を使うなら確かめる点 |
|---|---|---|
| 資格の確認 | 自社の会員データで確認 | 複数の運営者が共通の記録を参照する必要があるか |
| 利用者の操作 | 通常のログインと決済 | 管理する情報や操作の負担を説明できるか |
| 運営の変更 | 管理画面や規約で対応 | 変更できる範囲・権限・停止時の手順が決まっているか |
複数社で記録を参照したい場合でも、参加企業の合意やデータ更新の責任は別途必要です。技術を選ぶだけで運営上の取り決めが完了するわけではありません。
利用者が何を自分で管理し、困ったときはどこへ連絡するかまで、一連の利用手順として描いてみましょう。
企業側のウォレットの権限や引継ぎは、企業のWeb3ウォレット管理へ切り分けて確認できます。
事業案の評価では、こうした管理作業に使う人の時間も費用として置いてください。
事業案を検証する四つの手順
最初の検証では、扱う顧客と利用場面を絞ります。対象が広すぎると、誰の反応によって結果が変わったのかを追いにくくなります。
誰が、どの場面で困っているかを聞きます。
現在の解決方法と、手間や費用がかかる箇所を記録します。
誰から何の対価を受け取るかを決めます。
価格・利用人数・提供費・運営費を同じ期間で並べます。
対象人数と提供内容を絞り、実際の利用手順を確かめます。
問い合わせや手作業にかかった時間も残します。
支払意思、継続利用、対応費を開始前の条件と比較します。
次に変える箇所を決め、同じ条件で再確認できる記録を残します。

作成:OMK編集部。本文の事業設計・検証手順を図解。
続ける条件と、見直す条件を先に置く
検証後に都合のよい数字だけを選ばないよう、開始前に判断の条件を決めておきます。
たとえば、想定価格での継続希望、主要機能の利用回数、一人当たりの対応時間を、同じ期間で確認する方法があります。
何人中の何人が利用したか、どの期間の記録かを残すと、次回の検証と比べやすくなります。
無料参加者の反応と、有料で利用する人の反応も分けて記録します。好意的な感想と支払意思を同じ指標へまとめないことが大切です。
顧客には価値があるものの対応時間が長すぎるなら、案を捨てる前に対象や提供範囲を狭める選択肢があります。
反対に、運営が容易でも支払う理由が伝わらなければ、技術の追加より先に顧客と提供価値を見直します。
コミュニティを通じて継続利用を支える設計なら、Web3コミュニティ運営の参加導線や運営の考え方も参考になります。
社内で共有する設計メモ
企画書を厚くする前に、次の項目を一枚へまとめます。未確認の箇所には、調べる相手と確認日を書いておきましょう。
| 記入する項目 | 書く内容 |
|---|---|
| 顧客と課題 | 支払う人・使う人・困っている場面 |
| 提供価値 | 利用後にできること・今の方法との違い |
| Web3の役割 | 共通の記録など、使う部分と必要性 |
| 売上の条件 | 対価・単価・人数・受取時期 |
| 費用と責任 | 初期費・継続費・担当者・外部への支払い |
| 検証の条件 | 期間・対象・指標・継続と見直しの基準 |
とくに、支払う人と使う人が違う事業では、それぞれの判断材料を用意します。
利用者に便利でも、費用を出す企業側が導入の効果を確認できなければ、契約まで進みにくくなります。
営業担当、運営担当、開発担当が同じメモを読み、約束する内容と費用の範囲が一致しているかを確認してください。
費用や条件が変わったときには、古い見積もりをそのまま使わず、変更箇所と確認日を残します。
Web3のビジネスモデルに関するよくある質問
- 独自トークンを発行しないとWeb3の事業になりませんか?
-
企画の出発点は、顧客へ何を提供するかです。
独自トークンの発行を先に決めず、既存の基盤で必要な機能を実現できるかを検討します。
- NFTの販売後も継続収益を得られますか?
-
継続課金や追加サービスなど、対価を受け取る仕組みと提供内容の設計が必要です。
二次流通のロイヤリティは受取条件を確認し、自動的に得られる収益として計画へ入れないようにします。
- 最初の検証では何を測ればよいですか?
-
想定価格での支払意思、実際の利用、提供にかかった費用を同じ期間で確認します。
登録者数だけで結論を出さず、継続して使う理由と対応時間も記録しましょう。
- Web3を使うか、通常の会員サイトにするか迷います。
-
同じ顧客の課題を、両方の方法でどう解決するかを書き出します。
複数の運営者との記録共有、利用者の負担、費用、運営責任を比較して判断します。
顧客の価値と、お金の流れから設計を始める
Web3のビジネスモデルを考えるときは、誰のどんな行動を変え、その対価を誰から受け取るかを一文で書いてみてください。
次に、継続的に必要な費用と担当者を並べ、小さな利用規模でも成り立つ条件を確認します。
最初の一歩は、技術の一覧を作ることより、検証できる事業案を一枚にまとめることです。
自社の顧客や既存サービスに合わせて活用案を整理したい場合は、OMKへのお問い合わせで、対象顧客、提供したい価値、現在の課題をお知らせください。
事業案のどこを先に確認するか、一緒に整理するところから始められます。
参考資料
- ethereum.org|Introduction to Web3 ↩
- Alchemy|Pricing ↩
- ethereum.org|Gas and fees ↩
- ERC-2981|NFT Royalty Standard ↩
出典確認日:2026年10月5日
