トークンは発行すべきか？ポイントのままと比べる判断手順と発行後のKPI

会員向けのサービスを運営している会社で、事業責任者がこう言い出します。「会員に配っているポイントを、トークンに変えたらどうだろう」。トークンにすれば会員がもっと動き、新しい資金も集まるかもしれない。一方でCFOは不安です。報酬として配ったトークンがすぐ売られる。使う人は増えないまま、運営資金が尽きていく。ロック解除が一度に来て、出回る量が急に増える。どれも、トークン事業でよく起きる失敗だからです。

この二人が決めたいのは二つです。一つは「そもそもトークンを発行すべきか」。もう一つは「発行した後、何を測り、どうなったら設計をやり直すか」です。短く言えば、まず「トークンなし」の案、つまり今のポイントや円の決済で続ける案をつくって比べます。3段階の確認を通らなければ発行しません。発行する場合も、見直し・縮小・撤退の条件を発行前に決めておきます。値上がりや資金調達は、設計の目標にしません。

この記事でわかること

• トークンを発行すべきかを確かめる3段階の手順
• 発行した場合に、どんな条件で仕組みが壊れるかの探し方
• 発行後に見るKPIと、見直し・縮小・撤退を決める条件

配分や供給、使い道、ガバナンスといった設計の基礎はトークノミクスとは？設計要素・手順・失敗しない考え方で解説しています。先にこちらを読むと、判定の手順が追いやすくなります。

トークンを発行すべきかを3段階で確かめる

さきほどの会社がたどる順番は、次の3段階です。どの段階でも、答えが「いいえ」なら発行しません。

1. トークンなしの案と比べる：普通のデータベースや契約、ポイント、円などの法定通貨での決済で同じ結果が出せるなら、発行しません。
2. 参加者ごとの台帳で必要性を確かめる：誰がどんな価値を入れ、どんな権利を得て、どう抜けるのか。これを書き切れなければ、発行しません。
3. 壊れる条件を探す：需要が届かない、報酬が売られる、ロック解除が一度に来る。こうした条件で、トークンなしの案より悪くなるなら発行しません。

3段階を通っても、発行は「仮説を試すこと」にすぎません。発行後に仮説を確かめるKPIを決めておきます。見直し・縮小・撤退の条件も、発行前に決めておきます。

最初に「トークンなし」の案をつくる

この会社が最初につくるのは、トークンの配分表ではありません。今の事業として、価値がどう流れるかを1枚の図にします。図に書くのは、顧客、使われる場面、提供する価値、お金を払う人、費用、品質の指標です。

誰が誰に何を提供するかも描きます。あわせて、次のものがどう動くかを書き込みます。

• 法定通貨やステーブルコインでの支払い
• サービス内のクレジット（この会社なら、今のポイント）
• 評判やデータ

そのうえで、いったんトークンを外してみます。中央のデータベース、契約、ポイント、法定通貨の決済、今あるアクセス権で、同じ結果を出せるかを比べます。会員の台帳も精算も自社で完結しているなら、次の表の1行目にある「見送る兆し」に当たります。

次の5つの問いのうち、右の列に当てはまるものが多いなら、発行は見送るのが妥当です。

事業責任者の「会員がもっと動く」「資金が集まる」は、それだけではトークンが要る理由になりません。「コミュニティをつくる」「価格を上げる」も同じです。トークンが要る理由は、次のつながりで書きます。

トークン機能 → 変えたい行動 → 生まれる顧客価値 → 観測KPI

どれか一つでも測れないと、あとで「トークンの機能が実際に効いたか」を判定できません。このつながりは、発行後に見直すときの測り方の設計図にもなります。

参加者ごとに「何を出し、何を得て、どう抜けるか」を1枚の表に書く

トークンなしの案で答えが出なければ、次は参加者ごとの台帳です。参加者は、次の8つに分けて考えます。

• 利用者、供給者、検証者・運用者
• 開発者、投資家、チーム
• トレジャリー、ガバナンスの参加者

それぞれについて、同じ5つの項目を書きます。

• 仕組みに入れる価値と、受け取る価値
• トークンで得る権利
• 負う費用・リスクと、抜ける方法

関係者の名前を並べただけの図では足りません。さきほどの会社なら、まず会員（利用者）の行から書きます。会員はトークンで、今のポイントでは得られないどんな権利を得るのか。そこが空欄のままなら、話は前に進みません。

報酬を配るなら、自己申告やウォレットの数を成果にしないことです。不正にも報酬を払いかねません。1人が複数のIDを作ってだまし取る不正（シビル攻撃）や、質の低いものの量産です。そのため、報酬の条件には次のことも含めます。

• 何で測るか、どの期間で判定するか、上限はいくらか
• 異議を申し立てる手順
• 不正時に預けた資産を没収する仕組み（スラッシング）か報酬の取り消し、誤判定のときの回復

一方、ネットワークの安全をトークンで守るプロトコルの場合は、検証者・運用者の行が中心になります。運用者への報酬は、稼働時間で決めないようにします。正しく提供したサービスの量、品質、確かめられること、障害からの回復に結び付けます。

需要も「買いたい人が増える」で済ませません。誰が、どのサービスや権利のために、いつ、いくら必要とするかに分けて書きます。

供給者が支払いで受け取ったトークンをすぐ売るなら、利用で買われるのと同時に売りも出ます。ステーキングで一時的に出回る量を減らしても、安心はできません。報酬が実際の需要や外部の収益で支えられていないと、将来売られる量を増やすだけになりえます。

この表を書き切れない参加者がいるなら、その参加者にトークンは要りません。

判定に関わる設計の要点だけ押さえる

権利・供給・トレジャリー・ガバナンスの一般的な設計は基礎の記事で扱っています。ここでは、この会社が発行を判定し、発行後に見直すときに効く点だけをまとめます。

• 権利：「決済」「アクセス」「ステーキング」「ガバナンス」と名前を付けるだけでは足りません。いつ権利が生まれ、誰が使い、いつまで有効か。移せるか、どんなときに取り消すか。管理者の権限と、障害時の代わりの手段も決めます。一つのトークンに機能を載せるほど、権利どうしがぶつかります。
• 供給：配分の円グラフだけでは見えません。ロック解除、新規発行、報酬、トレジャリーの支出、バーン、ロックを、同じ時間軸の台帳で見ます。最大供給量が固定でも、大きなロック解除があれば出回る量は急に増えます。バーンがあっても、新規発行の方が多ければ希少にはなりません。ベスティングは、区分ごとに貢献の期間と達成目標に合わせます。
• トレジャリー：CFOが見る運営を続けられる期間（ランウェイ）は、トークンの枚数では測りません。支払う通貨ごとの資産、固定費と変動費、支払いの約束、換金のしやすさ、売れる上限で測ります。自社トークンを高い値で見積もると、危うい循環を見落とします。費用のために売るほど、価格も換金のしやすさも同時に悪くなる循環です。基本・下振れ・危機の場合ごとに、トークン以外で運営できる月数を出します。
• ガバナンス：投票で決まったことだけを、支出の理由にしません。変えられない権利、利用者が抜けられる範囲、緊急時の限られた権限を決め、規約とコードの両方に入れます。抜けられる範囲は、可決から実行までの待機期間（タイムロック）中について決めます。

発行した場合に壊れる条件を先に探す

台帳が書けたら、次はシミュレーションです。目的は、将来の価格を当てることではありません。設定値と参加者の行動をいろいろに組み合わせ、仕組みがどこで行き詰まるかを探します。

• 資金が足りなくなる、安全性が落ちる
• 一部に集中する、報酬を出しすぎる
• 抜ける人が一度に出る

この試験で「トークンなしの案より悪くなる条件」が現実的な範囲にあるなら、発行を見送るか、規模を小さくします。

モデルを組むのは、CFOや事業責任者本人でなくてかまいません。二人が決めるのは、どの場合を試すかと、どんな結果なら見送るかです。組むのは設計・実装の担当者で、その進め方は後半の「実装する人向けの詳細」にまとめています。専用のシミュレーションの道具を使うかどうかも選べます。二人が確かめるのは、道具ではなくモデルの式と仮定です。

この会社で試しておきたいのは、表の上から5行です。最後の「安全性が危うくなる」の行は、一方の、ネットワークの安全をトークンで守るプロトコルの場合の話です。

見た目が精密なモデルでも、前提が甘いと結論はもろくなります。たとえば、全員が合理的に同じ行動をとる前提や、いつでも十分に売り買いできる前提です。

日本で発行するなら、法律上の扱いを並行して確かめる

さきほどの会社が日本で発行するなら、法律上の扱いも同時に確かめます。日本では、トークンという名前ではなく中身によって、適用される法律が変わりえます。見られるのは、たとえば次の点です。

• 移せるか、どこで使えるか
• 法定通貨や暗号資産と交換できるか、収益の分配があるか
• 発行・販売・管理の仕組み

金融庁の「ICO（Initial Coin Offering）について」も、ICOの仕組みによっては資金決済法や金融商品取引法などの規制の対象になると説明しています。

さらに2026年7月には、暗号資産を金融商品取引法の枠組みへ移す改正法が成立しました。発行者の情報公表などの扱いが変わります。改正の状況と事業者の準備は暗号資産の金商法改正への対応にまとめています。

ホワイトペーパーを書き終えてから免責の文を足すのでは遅すぎます。トークンが要るかの判定と同時に、次のことを法務などの担当者と確かめます。

• 権利、販売する主体、購入の対価
• 移転、償還、利益・収益との関係
• 資産の保管（カストディ）、対象の地域、本人確認とマネー・ローンダリング対策（KYC/AML）
• 会計・税務

設計を変えると、法律上の扱いや必要な業務が変わることがあります。そのため、法律上の判断とトークン設計の版を結び付けて管理します。

発行後は、仮説ごとのKPIで見直しを決める

この会社が発行に進むと決めても、いきなり全会員に配るわけではありません。本番の前に、取り消せない度合いと扱う資金の量を少しずつ増やします。進める順は次のとおりです。

1. ブロックチェーンの外での試作（オフチェーン）
2. 本番と同じ仕組みの試験用ネットワーク（テストネット）と、参加者を限った試行
3. 上限を付けた本番ネットワーク（メインネット）

それぞれの段階で、先へ進む条件と前へ戻る条件を決めます。結果が悪いとき、トークンの発行量を増やして問題を隠してはいけません。

仮説ごとに、何を測り、悪くなったら何を決めるかは次のとおりです。この会社が見るのは、表の3行目を除く4行です。3行目の「安全対策の予算」は、ここでもプロトコルの場合の話です。

KPIは画面に並べるだけでは足りません。誰が、どのくらいの頻度で見て、どの基準値を超えたら何を提案・停止できるか。そこまで決めておきます。

見直しの選択肢は、報酬の条件や発行量の調整だけではありません。

• 機能を小さくする
• トークン必須だった機能を、トークンなしに戻す
• 権利と残った財産を定めた手順で撤退する

発行前に「トークンなしの案」をつくっておくと、この戻り先がはっきりします。さきほどの会社なら、戻り先は今のポイントです。供給の仕組みを大きく変えた実例は、Astar Networkのトークノミクス変更で詳しく扱っています。

最初に何をつくるか（設計レビューに出すもの）

さきほどの二人が最初に机に並べるのは、トークンなしの案を含む価値の流れ図1枚です。設計レビューに出すものは、次の10点です。

発行するかを判定するためにつくるもの

1. トークンなしの案を含む価値の流れ図と、「トークンは要らない」と言える条件
2. 参加者ごとの価値・権利・費用・リスク・抜け方の台帳
3. サービスの需要と、受け取った人の売りを分けた、需要と売りの仮説
4. 基本・下振れ・危機の場合ごとの、トレジャリーで運営できる期間
5. 参加者の行動モデル、設定値の範囲、試す場合、結果の分布、壊れる条件

発行して運用するためにつくるもの

6. 機能ごとの状態の移り変わり、権限、障害のパターン
7. 配分、ベスティング、新規発行、バーン、ロック、トレジャリーをまとめた時系列の供給台帳
8. ガバナンスの規約、提案から実行までの手順、緊急時の権限、抜ける条件
9. 段階的な始め方、KPI、停止・元に戻す・設計し直す条件
10. 法務・会計・税務・セキュリティで未確定のことと、その責任者

5つ目の行動モデルや結果の分布は、二人が自分で計算するものではありません。担当者が組んだモデルの式と仮定を、二人がレビューします。

実装する人向けの詳細

ここからは、さきほどの会社でCFOから依頼を受けて仕組みを組む担当者の話です。プロトコルを設計・実装する人にも、そのまま当てはまります。

権利とガバナンスの部品

OpenZeppelin Contracts 5.xのGovernanceは、ガバナンスを別々の部品として扱っています。投票力、定足数、集計、成立の閾値、タイムロックです。DAOの構築全体はDAO開発の解説で補足しています。

ENS DAO Constitutionは、上位の原則を定めた例です。トレジャリーの収入は、まずENSの長期的な存続と開発に使うとしています。

供給の部品と会計式

OpenZeppelinのVestingWalletは、解除される額を計算する部品です。ただし、スケジュールが事業として妥当かまでは保証しません。

供給の台帳には、ブリッジ（別のチェーンとのあいだの移動）で出入りする分も入れます。供給と需要は、期間tごとに次の会計式で突き合わせます。価格を出す式ではありません。どの出来事が、出回りうる量と売り買いの需要を変えるかを、漏れなく数えるための式です。

• 流通量＝ロック解除分＋新規発行＋トレジャリーからの配布＋ブリッジでの純流入−バーン−新たなロック
• トークンの純需要＝サービスでの購入＋担保としてのロック＋ガバナンスのためのロック−受取人の売却−報酬の売却−ロック解除分の売却

変数名で書くと次のとおりです。

circulating_supply[t]
= unlocked[t] + emissions[t] + treasury_distributions[t] + bridge_net_in[t]
- burns[t] - newly_locked[t]

net_token_demand[t]
= service_purchases[t] + collateral_lock[t] + governance_lock[t]
- recipient_sales[t] - reward_sales[t] - unlock_sales[t]

シナリオ試験で変える入力と、残す記録

前半の6つの場合で、変える入力は次のとおりです。最後の「セキュリティ危機」は、前半と同じくプロトコルの場合です。

各シナリオでは、次のものを保存します。

• 初期値、確率分布、エージェント（参加者）の行動方針
• 外から起きるイベント、実行回数、乱数のシード（再現用の初期値）
• 結果の分布

過去のデータで合わせ込めない仮定は、仮定だと明示し、幅を広めに取ります。cadCADなどのシミュレーションの道具を使う場合も、モデルの式と仮定を先にレビューできる形にします。レビューするのは、前半で試す場合と見送る結果を決めたCFOや事業責任者です。

KPIの分け方とパラメータ変更の記録

KPIは、次の分母・集団で分けて見ます。

パラメータを変えるときは、次の記録を付けます。

• 仮説、対象の版、予想される影響
• シミュレーション、実施日、元に戻す条件

変更後は、同じ条件の集団と期間で差を測ります。都合のよい指標だけを選ばないようにします。

関連する記事

• 設計要素の基礎：トークノミクスとは？設計要素・手順・失敗しない考え方
• ステーキング報酬の個別の設計：ステーキング／ファーミングのインセンティブ設計
• DAOのトレジャリーの統制：DAOガバナンスの実行設計
• DePINでの報酬の持続性：DePINトークノミクスの持続性

XTELAができること

私たちは、トークンなしの基準案を含む価値の流れと権限の整理から、スマートコントラクトとデータの設計、壊れる条件を探すシミュレーション、段階的なローンチのPoC、発行後のKPIの監視とガバナンスの運用までを設計・開発します。貴社の事業で「発行しない」という結論が出れば、トークンなしの構成で進める設計も一緒に作ります。価格形成や資金調達、法的な分類の判断は私たちの仕事ではなく、法的な判断は弁護士と連携して進めます。技術の仮説を検証できる仕様に落としたい場合はお問い合わせください。

主要参考資料

• Kivilo et al., Designing a Token Economy: Incentives, Governance, and Tokenomics（2026）
• Zargham et al., Engineering Token Economy with System Modeling
• cadCAD documentation
• OpenZeppelin Contracts 5.x: Finance / VestingWallet
• OpenZeppelin Contracts 5.x: Governance
• ENS DAO Constitution
• 金融庁「ICO（Initial Coin Offering）について ～利用者及び事業者に対する注意喚起～」（2017年10月27日）

本記事の前提：法令を含む一次資料は2026年8月12日に確認しました（2026年7月の改正法の成立は9月24日に確認）。その時点の公開情報にもとづく、一般的な技術・事業設計の解説です。トークンや法令・会計上の扱いは変わることがあります。個別の事業では、最新の一次資料をもとに法務・会計の担当者と確かめてください。