DePINネットワークの作り方｜払う顧客を先に確かめる開発の進め方と止める条件

ある通信会社の新規事業チームが、DePINで地域の通信網を作ろうとしました。小さな無線機器を置いてくれる人を募り、稼働に応じてトークンで報酬を払う仕組みです。報酬が効いて、機器は順調に増えました。

ところが、その通信をお金を払って使う顧客が見つかりません。試験価格を示しても、契約しようという企業が出てこない。機器が増えるほど、報酬と交換・問い合わせの費用だけがふくらんでいきます。

このチームがつまずいたのは、お金を払う人を確かめる前に、設備を増やしたからです。DePINを作るとき、最初に決めるのは設備の数ではありません。「誰がお金を払って使うのか」と「何を1単位として測り、請求するのか」です。たとえば、確かめ済みの1kWhや、使える通信の1分がその単位になります。

そのうえで、機器の見分け方、実績の確かめ方、支払い、報酬、不正対策を、まず小さな範囲でひととおり動かします。設備を増やすのは、その後です。以下では、通信・エネルギー・データ・モビリティの分野でDePIN事業を立ち上げる新規事業責任者とCTOが、どの順で作り、どこで止めるかを見ていきます。前半は事業責任者が決めること、後半は技術の設計です。

DePINそのものの仕組みや代表的なプロジェクトの基礎はDePIN入門、分野ごとの全体像はDePIN完全マップ 2026にまとめています。

この記事でわかること

• DePINにすべきかの見分け方と、お金を払ってもらう単位の決め方
• 試験から本番までの6段階と、各段階で止める条件
• 機器の見分け方と、不正を防ぐ実績の確かめ方

まず「誰が、何にお金を払うか」を確かめる

DePINで分散できるものは、いくつもあります。設備の所有、設置、運用、計測、検証、価格の決め方、精算、ガバナンスです。すべてを分散する必要はありません。

たとえば、地域の通信の届く範囲を外部の運用事業者が提供するとします。その実績を複数の主体が確かめ、自動で精算する。この場合は、共有の台帳とプログラムで動く精算に意味があります。一方、自社の機器だけを自社のバックエンドで管理し、計測値と請求も自社で確定するなら、話は別です。通常のIoTプラットフォームと銀行決済で、要件を満たせる可能性が高いでしょう。

次の5つの項目で、どちらに当てはまるかを見ます。

PoC（小さな試験運用）を始める前に、対象を絞ります。お金を払う需要者は少なくとも1種類、供給者も1種類、支払いの対象も1単位です。

「貢献」のようなあいまいな単位では、あとから測り直すことも、不正を見つけて断ることもできません。そこで、測り直せて、不正なら断れる単位で数えます。たとえば、確かめ済みのkWh、使える通信の時間（分）、受け付けたセンサーの記録、完了した計算処理です。

「1単位」を、契約・計測・精算の共通の軸にする

サービス単位には、誰が、どの機器で、いつ、どこで、何を提供し、どの品質の条件を満たしたかをひも付けます。単位が決まれば、同じ出来事からいろいろなものを導けます。APIの形式、機器が送る計測データ、実績を確かめるルール、料金、報酬、SLAの試験条件です。記録の例は、後半の「実装の詳細」に載せました。

料金と報酬は分けて考えます。顧客が払う料金は、需要の側から見た価値です。運用事業者への報酬は、供給を集めて品質を保つための費用です。

両方を同じトークンの価格に頼らせると、ゆがみが出ます。利用は増えていないのに、投機で値が上がって供給だけが増える。逆に値が下がって、必要な地域から設備が引き上げられる。そうしたことが起きます。

最初の検証では、法定通貨に直した1単位当たりの採算も並べて見ます。次の式がプラスになる条件を確かめます。

顧客単価 − 検証・通信・ブロックチェーン手数料 − 運用事業者報酬 − サポート・交換費

どの段階で何を作り、どこで止めるか

開発は、次の6段階で区切ります。どの段階も、次へ進む条件を満たしてから進みます。

各段階で測るものは、次のとおりです。

• 0. 課題の検証：払う意思、必要な地域・品質、調達のコスト
• 1. 閉じた試行：データの欠け、設置にかかる時間、サポートの件数、1単位の原価
• 2. 確かめられるMVP：誤って受け付けた・誤って断った件数、不正の再現、計算し直したときの一致
• 3. 精算のMVP：誤差、手数料、確定までの時間、二重支払い、鍵の運用
• 4. 地域への展開：需要を満たせた率、稼働率、交換率、地域ごとの粗利
• 5. 開かれたネットワーク：一部への集中の度合い、判定ルールを変えた影響、障害からの復旧、資金の管理

止める条件も、段階ごとに先に決めておきます。次のような場合は、トークンの設計でごまかさず、サービスか運用のやり方に戻ります。

• 需要者が、PoCの価格でも契約しない
• 検証の費用が、1単位の粗利を超える
• 機器の交換とサポートで、地域ごとの粗利がマイナスになる
• 不正を見分けるルールが、正しい運用事業者を大量に断ってしまう

冒頭のチームは、1つ目の条件に当たったまま機器を増やしてしまったことになります。

トークンとブロックチェーンは、精算の要件が固まってから選ぶ

最初の試行は、データベースの台帳でもかまいません。誰がどの判定を変えられ、何を第三者が確かめ、いつ支払いを確定するか。これが固まってから、パブリックチェーン、許可型の台帳、通常のデータベースを比べます。

比べる軸は、エコシステムの知名度ではありません。次のような点です。

• 取引が確定する確かさ、手数料とその変動
• アカウント抽象化（ウォレットの使い勝手や回復をプログラムで決められる仕組み）、鍵の復旧、プライバシー
• 更新、データの索引作り、法定通貨との出し入れ、障害時に人が介入できるか

トークンを使う場合も、供給を集めること、サービス料金の支払い、ガバナンスを1つの資産に詰め込む必要はありません。報酬の式には版を付けて管理します。入力した出来事、除いた理由、丸め、料率、確定した時刻から、計算し直せるようにしておきます。

価値・価格・規制上の扱いは、技術の仕様だけでは決まりません。発行・販売・交換・カストディ（資産の保管・管理）を伴う場合は、法律・会計・税務の論点を、技術の設計と並行して洗い出します。

本番の運用は、スマートコントラクトの外まで広がる

DePINでは、スマートコントラクトの外にある仕事が、サービスが止まらないかを左右します。現地での設置、電源・通信、機器のソフト（ファームウェア）、交換、問い合わせ、もめごとの処理です。

運用事業者向けの手順書には、次のことを入れます。開梱、初期設定、設置の検査、オフラインからの復旧、鍵の紛失、所有者の変更、返送・廃棄です。

プラットフォームの側では、次のものを見張ります。

• サービス単位を受け付けた率、データ取り込みの遅れ、確認待ちの件数
• 報酬の突き合わせの差、機器のソフトの版の分布
• 地域ごとの通信の届く範囲と、需要を満たせた率

障害の種類ごとに、用意しておくことは次のとおりです。

• 鍵・コントラクトの障害：一時停止の範囲、複数人の承認、影響するサービス単位、再開したときの再送の扱いを決める。
• オラクル・検証する側の障害：確かめていない出来事を報酬の対象にしない。保留中の順番待ちと、計算し直しに使う版を残しておく。
• ブロックチェーンの停止・手数料の高騰：サービスの提供と精算を切り離し、二重に精算せず後日確定できるようにする。
• 機器の脆弱性：ソフトへの署名、段階的な無線での更新、元に戻す手段、強制的な失効、交換対象の特定を用意する。
• 異議の申し立て：判定の理由と証拠の参照先を運用事業者に示し、人が審査する権限とSLAを決める。

どこを自社で作り、どこを外部に頼むか

サービス単位、検証の方針、需要者側の業務の流れは、その事業ならではのものです。自社で作るか、自社でしっかり管理すべき部分です。

一方、次のものは要件を満たす既存のサービスを比べて選べます。ウォレット、RPC（ノードとの通信）、インデクサー（チェーンのデータを検索しやすく整える仕組み）、機器の接続、KYC（本人確認）、法定通貨での決済、安全なハードウェアです。

プロトコルを複製して手を入れられることと、ハードウェアの供給網、現地のサポート、需要者への営業を回せることは、別の力です。

本番に進む前に、次の5つがそろっているかを確かめます。

この5項目がそろうまでは、公開トークンや、許可なしで参加できる登録を、主な目標にしません。小さくても「需要→利用→検証→請求→報酬→サポート」が一周する仕組みを作る。その方が、参加者の数だけを増やすより、本番に進めるかを早く判断できます。

技術の構成：生のデータや位置情報はチェーンに載せない

ここからは、CTOが決める技術の設計です。まず全体の構成から見ます。

センサーの生のデータは量が大きく、個人や位置の情報を含むこともあります。削除を求められうるデータもあり、チェーンに書くと扱いにくくなります。そのため、こうしたデータはそのままチェーンに置きません。ブロックチェーンに置くのは、機器の登録簿、検証結果の確約値（後から中身を確かめられるよう固定したハッシュなど）、精算に要る最小限の状態です。大きなデータや、削除を求められうるデータは、アクセスを制限した保管場所で管理します。

全体は、次の6つの層に分けます。

各層が持つ情報と、起きやすい障害は、後半の「実装の詳細」にまとめました。

IoTeXのW3bstreamも、この分け方をとっています。DePIN固有の計算を、チェーンの外の証明生成器で実行し、結果と正しさの証明をスマートコントラクトに渡す構成です（IoTeX: Overview of W3bstream）。ただしこれは選択肢の1つです。すべてのPoCにゼロ知識証明が要る、という意味ではありません。

機器の見分け方：ウォレットを持たせるだけでは足りない

機器を見分けるには、いくつかの情報を結び付けます。製造時か登録時の鍵、機種、ソフトの版、所有者・運用事業者、設置の状態、失効しているかです。

秘密鍵をふつうのファイルとして置くと、機器を複製されやすくなります。そこで、セキュアエレメント（鍵を守る専用のチップ）やTEE（信頼できる実行環境）を使う場合があります。

ただし、ハードウェアを信頼の起点にする仕組みが証明できる範囲は限られます。「特定の機器の上で、特定のソフトが動いた」までです。センサーが現実を正しく測ったことまでは保証しません。

1. 登録：製造番号だけに頼らず、機器の鍵と、所有・運用する主体を登録する。
2. 構成の証明：必要な用途に限って、ソフトや安全なハードウェアの状態を確かめる。
3. 鍵の更新：運用事業者の交代、鍵の更新、機器の交換を、履歴付きで処理する。
4. 失効：盗難、改ざん、弱い版を見つけたらすぐに止め、過去の報酬への影響の扱いを決めておく。

peaqの公式ドキュメントには、実装の例があります。機器をDID（分散型識別子）として登録し、暗号の鍵とサービスの接続先をDID Document（DIDにひも付く公開情報）に結び付けるものです（peaq: Onboard a Machine）。採用するときは、DIDがあるかだけでなく、鍵をどこで作るか、復旧、失効、バックエンドとのひも付けを、自社が想定する攻撃に照らして確かめます。

実績の確かめ方：正しく動いたかと、報酬を払うかを分けて判断する

署名で分かるのは、誰が送ったかと、改ざんがないかです。機器が本当にその場所にあったか、きちんと動いていたかは、署名からは分かりません。そのため、物理の世界での活動の証明は、1つの暗号技術だけでは完結しません。

そこで検証の方針には、いくつかの材料を組み合わせます。複数のセンサーの整合、時間・位置のもっともらしさ、近くの機器からの観測、需要者の利用記録、異常の検知、抜き取りの監査です。

よくある攻撃や計測の誤りと、その見つけ方・対応は次のとおりです。

IoTeXは、DePINの検証の課題として、自己取引、怠ける供給者、悪意ある応答を挙げています。そして、機器の識別と、チェーンの外で確かめられる計算を組み合わせる方法を示しています（IoTeX: The DePIN Verification Problem）。

証明の方式は、ずっと同じとは限りません。Heliumは、ビーコン（送信する信号）とwitness（それを受信した観測）で、無線の届く範囲を確かめていました。しかし2026年7月6日にProof-of-Coverage（この届く範囲の証明）をやめ、過去のデータは履歴として参照できる形で残しています（Helium: Oracle Data File Format）。証明の方式は、実際の利用に対する価値と、不正への強さを見ながら評価し続ける必要があります。

自社の設計でも、ほかのネットワークの証明方式の名前をそのまま借りません。サービス単位ごとに、偽装するのにかかる費用と、誤って判定したときの費用から、判定のルールを作ります。

実装の詳細

ここからは、前半で後回しにした記録の形と、各層の中身を、実装する担当者向けにまとめます。

サービス単位の記録例

{
  "service_unit_id": "su_...",
  "device_id": "did:...",
  "operator_id": "op_...",
  "window": {"start": "...", "end": "..."},
  "measurement": {"type": "coverage_minute", "value": 60},
  "evidence_hash": "sha256:...",
  "verifier_policy_version": "v1.3",
  "decision": "accepted",
  "settlement_id": "set_..."
}

各層が持つ情報と、主な障害

関連記事

• 設備をどこに何台置けば需要を満たせるか（需要セルと最大被覆の考え方、「4. 地域への展開」での再計画）：DePINの設備配置計画
• 需要者の支払いから原価・報酬までを単位ごとに分ける方法：DePINの需要と単位採算の設計
• 鍵の保管場所の選び方と、リモート構成証明の検証手順：DePIN機器のIDとリモートアテステーション設計
• 検証の段階分け、報酬の保留・確定、異議申し立ての流れ：DePINのデータ品質と報酬不正対策
• 報酬が需要の収益でまかなえているか、補助金のような発行に頼っているかを見分ける指標：DePINトークノミクスの持続性評価
• 壊れた機器の交換、報酬の引き継ぎ、廃棄時の鍵の失効：DePIN機器の保守・交換・廃棄

XTELAができること

私たちは、DePIN構想を「誰が何に払うか」とサービス単位の定義から一緒に組み立て、デバイス・データ取り込み・検証・精算コントラクトをつなぐ最初の一周を実装します。10〜50台規模の閉じた試行で単位原価と不正の再現テストを回し、本番へ進むかどうかを数字で判断できる状態まで作ります。貴社の設備や需要者が決まっている段階なら、お問い合わせからご相談ください。

主要参考資料

• IoTeX Documentation: The DePIN Verification Problem
• IoTeX Documentation: Overview of W3bstream
• IoTeX Documentation: Build a Decentralized WiFi Network
• Helium Documentation: Oracle Data File Format
• peaq Documentation: Onboard a Machine
• A Taxonomy for Blockchain-based Decentralized Physical Infrastructure Networks

資料の確認日と注意

公開されている仕様は2026年9月24日に確認しました。技術設計の整理で、法的・投資上の助言ではありません。プロトコル、法令、料金は変わるので、採用する時点の一次資料と対象地域の要件を確かめてください。