DePINの採算の計算方法｜何を何単位で売るかと1単位の利益・拡大の判断

ある道路画像のDePIN（分散型物理インフラネットワーク）で、カメラを載せて走る参加者はどんどん増えました。集まる画像も増えています。ところが、お金を払って使う顧客は、まだほとんどいません。

事業責任者が知りたいのは、次の3つです。

• 誰に、何を、何単位で売るのか
• 1単位売ると、いくら残るのか
• いつ設備を広げてよいのか

短く答えると、まず顧客が何を何単位買うかを具体的に決めます。次に、1単位の値段から、契約・検証・提供・請求にかかる費用を引きます。そして、1単位ごとと顧客1社ごとの両方で採算が合うと確かめてから、設備を広げます。

以下では、この事業の事業責任者とプロダクト責任者が、売る単位を決め、採算を計算し、見積もりから請求までを記録し、拡大を判断するまでを追います。DePINの基本はDePIN入門、需要の検証から本番運用までの開発工程の全体はDePINネットワークの作り方にまとめています。

誰に、何を、どの単位で売るか

同じ物理資源でも、買い手によって価値の単位は違います。

• 通信事業者は、転送データ量と到達率を買う
• 物流会社は、指定した道路の新しい画像を買う
• AI開発会社は、要件を満たして完了した計算ジョブを買う

「カバレッジ」「データ」「GPU時間」のような供給側の言葉だけでは、何をいくつ渡せば契約を果たしたことになるのかが決まりません。検収も請求も、1つに決められません。

そこで、次の5つの順に絞り込みます。どれかで止める条件に当たったら、先へ進みません。

段階ごとに作るものは、後半の「実装する人向けの詳細」にまとめました。

実例を1つ挙げます。Heliumでは、ネットワークの利用料をData Credits（DC）で払います。1 DCは0.00001米ドルに固定されています。IoTでは、アプリケーションのペイロード（送信データ本体）24バイトごとに1 DCを使います。Mobileでは、1 GBを0.10米ドルとして扱います（Helium公式Docs: Data Credit）。

トークンの価格ではなく、顧客が分かる利用単位と、法定通貨での価格を固定した例です。

1単位ごと、顧客1社ごとに、いくら残るか

1単位の採算がよくても、顧客ごとの導入の費用で赤字になることがあります（後の計算例で見ます）。そのため、採算は1つの比率にまとめず、2段で見ます。まず利用単位ごとの限界利益を確かめます。次に、顧客の獲得・導入の費用を含めて、顧客ごとに集計します。

利用単位限界利益 = 顧客単価 − 供給者への利用連動支払 − 検証費 − 帯域・保存費 − 決済費 − 利用連動サポート費

顧客貢献利益 = 利用単位限界利益 × 有償利用量 − 顧客固有の導入・保守費

獲得費回収月数 = 顧客獲得費 ÷ 月次顧客貢献利益

プロトコルの開発費や全社の管理費のような固定の費用は、別に管理します。初めの段階で、すべての固定費を1単位へ機械的に割り振ると、困ったことになります。利用が増えれば良くなる原価と、設計を変えなければ減らない費用を、見分けられなくなるのです。

一方、次のものは有償の利用量に混ぜません。

• 無料のPoC
• 運営者自身の購入
• 財団の資金によるクレジットの消費

計算例：道路画像を企業に売る場合

冒頭の事業で、物流会社が、指定した1 kmの道路について、週ごとに更新された画像を買うとします。1単位は「1 km・1週」です。

• 顧客価格：1 km・1週あたり120円
• ネットワークのデータ原価：55円
• 品質の検証と変換：18円、配信：7円
• 決済・サポートの引当：10円

この場合、利用単位限界利益は30円、限界利益率は25%です。

ただし、利用量だけでは評価できません。月に40万単位を使う顧客でも、初回のデータ接続に600万円、毎月の専用運用に120万円かかるとします。見るべきは、月次の利用単位限界利益1,200万円から専用運用費を引いた1,080万円で、獲得・導入の費用を回収できるかです。

反対に、少量の顧客では、1単位が黒字でも、導入の費用を回収できません。そのため、最低利用額、標準のAPI、導入費の別請求が必要になります。

Hivemapperの公式資料も、同じ構造を説明しています。Map Credits（Hivemapperのデータを使うためのクレジット）の卸売価格に加えて、開発者が追加の原価を負担し、最終顧客への価格を決める構造です。追加の原価は、API、顧客のデータパイプラインへの組み込み、画像処理などです（Hivemapper公式Docs: HONEY Burn and Mint）。ネットワークの原価と、顧客に渡す完成品の原価は、分けて考える必要があります。

見積もりから請求まで、1件ずつ今どの段階かを記録する

需要を売上に変えるには、営業の指標だけでは足りません。1件ごとの利用が、どの条件を満たせば請求できるかを、仕組みとして作ります。

最小限の段階は次のとおりです。

1. 見積もり済み：顧客、利用単位、品質、単価、上限、対象期間を見積もる。
2. 契約済み：最低利用額または容量の予約と、キャンセルの条件を契約する。
3. 依頼あり：APIや管理画面で、対象の地域・期間・品質を指定する。
4. 提供済み：物理資源またはデータを提供し、元のイベントを保存する。
5. 検証済み／不合格：重複、不正、品質不足、期限超過を判定する。
6. 検収済み／異議あり：顧客の検収、または異議の申し立てと、再判定の期限を記録する。
7. 請求済み／精算済み：請求書の行と、供給者への精算を、同じ利用IDに結び付ける。

失敗したイベントを消すと、提供量、請求量、供給者への報酬の差を説明できなくなります。そのため、失敗したイベントも消しません。

1件ごとの利用には、顧客、製品、地域、期間、数量、品質の版、価格の版、検証結果、請求書の行、精算IDを結び付けて追います。処理し直しても同じ利用を二重に請求しない仕組み（冪等キー）も持たせます。状態名と項目名は後半にまとめました。

ブロックチェーンには何を置くか

販売にかかわる情報には、機密で変更が多いもの、容量が大きいもの、個人や位置にかかわるデータがあります。そのため、ブロックチェーンに置くのは、精算に必要な最小限の記録だけにします。

それぞれをその場所に置く理由は、後半にまとめました。

Filecoinのストレージ契約（storage deal）も、この考え方です。条件は当事者どうしでまずオフチェーンで交渉します。合意した契約だけを、ストレージ提供者がオンチェーンに公開します（Filecoin Spec: Deal Flow）。すべての販売の過程をブロックチェーンに移すのではなく、複数の主体が確かめる契約の状態だけを共有する例です。

顧客、供給者、検証者、運営者が1社で、請求と支払いも通常の契約で済むなら、署名付きの監査ログと業務DBで足ります。

比べるのは費用です。オンチェーンにして突き合わせの手間が減る額より、ガス代、鍵管理、障害対応、プライバシー対策の総費用が大きければ、採用しません。

需要のKPIを、どう追うか

営業・利用・採算を、同じ顧客コホート（開始時期別の顧客群）で追います。段階ごとの主な指標と、気をつけたい見かけの成長は次のとおりです。

各KPIの分母は、後半にまとめました。

月ごとの合計だけを見ていると、古い顧客の拡大で、新しい顧客の悪化が隠れます。契約開始月、製品、地域、価格の版ごとのコホートで、次のものを追います。

• 無料から有料への転換と、利用開始までの日数
• 90日後の利用量
• サポートの原価と、限界利益

供給が増えた地域でも、有償の依頼が増えなければ、拡大を止めます。

障害のとき、顧客への請求と供給者への精算をどう止めるか

DePINでは、一部だけが壊れる障害が起きます。

• 設備は動いたが、検証の仕組みが止まった
• 提供は済んだが、請求の処理が失敗した
• 顧客へ返金したが、供給者にはもう支払っていた

全体を一度に巻き戻すのではなく、利用IDごとに状態を止めます。

• 計測が止まった：推定値で自動請求しません。未検証の待ち行列へ隔離し、顧客の再実行か、免除の条件を当てはめます。
• 検証が遅れた：請求と供給者への精算を保留します。期限を過ぎたときの暫定の処理と、後日の差額の扱いを決めておきます。
• 価格が取れない：最後のトークン価格で顧客に請求しません。契約済みの法定通貨の単価を保ちます。
• イベントが二重に届いた：冪等キーで重複を拒否します。元のイベント、処理し直し、請求書の行を、同じ追跡IDに残します。
• 品質に異議が出た：証拠を残し、再判定する人、期限、返金、供給者への報酬の調整を分けて決めます。

監視では、契約量だけでなく、次のものも警報の対象にします。

• 依頼から検証済みまでの遅れと、不合格率
• まだ請求していない残高と、請求と精算の差額
• 顧客ごとのサポート時間

売上が増えていても、未処理の残高とサポート費が同時に増えているなら、単位あたりの採算は悪くなっています。

設備を広げてよいかを、3つの条件で判断する

1. お金を払ってもらえるか：運営者と利害関係のない顧客が、決めた利用単位に払い続けている。
2. 繰り返せるか：標準の導入手順で、顧客ごとの追加開発と獲得費を回収できる。
3. 提供し続けられるか：需要が増えても、品質、検証、サポートを保ち、利用単位限界利益がプラスである。

3つを満たすまでは、広い地域への供給の拡大や、独自トークンの発行を、需要の検証の代わりにしません。

容量の予約が要る事業では、顧客の最低利用の約束と、供給側の最低品質・稼働の約束を、同じ地域と期間で対応させます。ブロックチェーンは、その対応を複数の主体で共有する必要が確かめられた段階で足します。

需要からの収益が、供給者への報酬をどこまで賄えているかをネットワーク全体で測る方法はDePINトークノミクスの持続性評価で扱います。需要の大きい地域から設備を置く順番はDePINの設備配置計画、検証費を左右する不正対策はDePINのデータ品質と報酬不正対策をご覧ください。DePIN全体のカテゴリと代表プロジェクトはDePIN完全マップ 2026にまとめています。

実装する人向けの詳細

絞り込みの段階ごとに作るもの

• 顧客：顧客区分、利用業務、代替手段
• 成果：現行値と期待値、検収条件
• 利用単位：単位、品質、地域、時間窓
• 価格：基本料、従量料、最低利用額
• 提供原価：検証、帯域、精算、サポート原価

状態名と追跡する項目

前半の段階は、状態名では次のとおりです。quoted（見積もり済み）、committed（契約済み）、requested（依頼あり）、delivered（提供済み）、verified / rejected（検証済み／不合格）、accepted / disputed（検収済み／異議あり）、invoiced / settled（請求済み／精算済み）。

追跡する項目は、usage_id、顧客、製品、地域、時間窓、数量、品質版、価格版、検証結果、請求書行、精算IDです。再処理のときも同じ利用を二重に請求しないよう、冪等キーを持たせます。監視の遅延はrequestedからverifiedまでで測ります。

Filecoinで合意した契約をオンチェーンに公開する関数はPublishStorageDealsです。

置き場所の理由

• 見込み顧客、商談、契約書：機密情報と変更が多い
• 生の位置・画像・センサーデータ：容量、プライバシー、削除対応
• 利用要求と提供結果：障害復旧と顧客対応に詳細が必要
• 検証済み数量・品質：ルール変更と再判定へ対応
• 支払・供給者精算：返金、税務、照合が必要

KPIの分母

• 獲得：対象条件を満たす見込み顧客
• 導入：契約済み顧客
• 利用：購入可能な検証済み単位
• 品質：顧客が要求した利用単位
• 採算：顧客・製品・地域別の有償利用

XTELAができること

私たちは、貴社の需要仮説を利用単位と価格版に落とし、usage_idで見積もりから検収・請求・供給者精算までをつなぐデータモデルと管理画面を実装します。利用単位の限界利益と顧客貢献利益を顧客コホート別に出すダッシュボードを作り、三つのゲートを数字で判断できる状態にします。オンチェーン精算を入れるかどうかも、その数字を見ながら一緒に決めます。個別の設計相談はお問い合わせからご連絡ください。

主要参考資料

• Helium Documentation: Data Credit（2026年9月24日確認）
• Hivemapper Documentation: HONEY Burn and Mint（同日確認）
• Filecoin Spec: Deal Flow（同日確認）

資料の確認日と注意：仕様と出典は2026年9月24日に確認しました。技術・事業設計の一般情報であり、需要予測や投資・法務・税務・会計の判断を代替するものではありません。料金、プロトコル仕様、会計上の扱いは変わるため、導入時点の公式資料と専門家の判断を確認してください。