Web3リーガル・プレイブック：ビルダーが押さえるべき50のFAQ

プロトコルをローンチしたりオンチェーンプロダクトをスケールさせたりすることは、もはや技術だけの話ではありません。トークン発行からウォレットのプライバシーまで、規制当局の目は厳しく、ユーザーは消費者レベルの保護を求めています。自信を持ってビルドを続けるには、難解なリーガルメモをプロダクトの意思決定へ変換する体系的な方法が欠かせません。Web3の弁護士に寄せられる代表的な50の質問を土台に、このプレイブックはビルダーがすぐに動ける指針へと噛み砕きます。

1. 設立とガバナンス：Devco、財団、コミュニティを分離する

• 適切な法人格を選ぶ。 給与、知財、投資家のデューデリに対応するなら、従来型のC-CorpやLLCが依然として有利です。プロトコルや助成プログラムを運営するなら、別の非営利法人や財団を設け、インセンティブとガバナンスをクリーンに保ちましょう。
• 関係性はすべて文書化。 知財譲渡契約、秘密保持契約、クリフ・ロックアップ・悪意ある行為者へのクローバックを備えたベスティングスケジュールを整備します。取締役会の承認を記録し、トークンのキャップテーブルも株式台帳と同じ精度で管理しましょう。
• エンティティ間の境界を明確に。 開発会社はライセンスに基づいて開発できますが、予算、財務ポリシー、意思決定権は独自の定款や憲章を持つ財団やDAOに置きます。DAOに法的主体性が必要な場合は、LLCなどのラッパーを使いましょう。

2. トークンと証券：ユーティリティ設計と根拠の記録

• ラベルではなく実態を見られると想定する。 「ガバナンス」「ユーティリティ」と名乗るだけでは不十分で、稼働中のネットワークでユーザーが利用し、投機的な期待を煽っていないことが重要です。ロックアップは投機抑制に役立ちますが、安定性やアンチ・シビル対策として正当化しましょう。
• アクセス権と投資商品を切り分ける。 アクセストークンはプロダクトパスとして設計し、価格設定・ドキュメント・マーケティングがサービス利用権を強調するようにします。ステーブルコインは準備資産や償還権によって決済・電子マネー規制が適用される可能性があります。
• ステーキングや利回りは金融商品として扱う。 APRの提示、プール運用、チームの努力への依存は証券リスクを高めます。マーケティングは平易にし、リスク要因を開示し、SAFTで資金調達したならローンチまでの適法な計画を描きましょう。
• NFTも証券になり得る。 分割所有、収益分配、利益を約束する表現は投資と見なされます。明確なライセンスを備え、消費用途に焦点を当てたNFTの方がリスクが低いです。

3. 資金調達と販売：ネットワークの価値を語り、投機は煽らない

• 成熟した開示を行う。 目的、機能、ベスティング、割り当て、移転制限、依存関係、資金使途は販売資料に含めます。マーケティング文面もこれらと整合させ、「保証された利回り」といった表現は避けましょう。
• 法域の境界を尊重する。 米国など高リスク地域で遵法できないなら、ジオフェンシング、適格性チェック、契約での制限、販売後のモニタリングを組み合わせます。トークン販売はもちろん、エアドロップでもKYC/AMLが求められるケースが増えています。
• プロモーションリスクを管理する。 インフルエンサーとの施策ではスポンサー関係を明示し、コンプライアンスした台本を用意します。取引所上場やマーケットメイク契約は書面合意、利益相反チェック、正確なコミュニケーションが必須です。

4. AML・税務・IP：プロダクトにコントロールを織り込む

• 自分たちの規制上の立場を把握。 非カストディアルなソフトウェアはAML負担が軽いですが、フィアット連携、カストディ、仲介型の交換を扱えば送金業者やVASP規制の対象になります。制裁スクリーニング、エスカレーション手順、必要に応じたトラベルルール対応を準備しましょう。
• 会計上はトークンを現金同等物として扱う。 トークン受領時は時価で収益計上され、後の売却で損益が発生します。従業員・業務委託へのトークン付与はベスト時に課税されることが多いので、書面契約で基礎価額を追跡し、ボラティリティに備えましょう。
• 知的財産の境界を尊重する。 NFTやオンチェーンコンテンツには明確なライセンスを添付し、第三者OSSの条件を順守し、商標を登録します。AIモデルを訓練する場合はデータセットの権利を確認し、センシティブな情報を除去しましょう。

5. プライバシーとデータ：収集を最小限に、削除に備える

• ウォレットアドレスも個人データと見なされ得る。 IPアドレスやデバイスID、メールと組み合わせれば識別可能情報になります。必要最小限のデータのみ収集し、可能な限りオフチェーンに保管し、ハッシュ化やトークナイズを活用します。
• 削除請求に対応できるよう設計する。 レジャーが不変でもプライバシー法からは逃れられません。PIIはオンチェーンに書き込まず、削除依頼があれば参照を除去し、ハッシュから再識別できないようリンクを断ちます。
• テレメトリーの透明性を確保。 クッキーバナー、アナリティクスの開示、オプトアウト手段は必須です。重大度レベル、通知タイムライン、連絡窓口を含むインシデント対応計画を文書化しましょう。

6. オペレーションとリスク：早期に監査し、継続的に情報共有

• 監査し、結果を開示する。 独立したスマートコントラクト監査、必要に応じた形式的検証、継続的なバグバウンティは成熟度を示します。レポートを公開し、残存リスクを率直に説明しましょう。
• 明確な利用規約を整備。 カストディの有無、利用資格、禁止行為、紛争解決、フォーク時の対応を明記します。利用規約、プライバシーポリシー、プロダクト挙動を一致させましょう。
• フォーク、保険、越境展開を計画。 サポートするチェーン、スナップショット日、移行手順を選択する権利を確保します。サイバー、犯罪、D&O、テックE&Oなどの保険を検討し、グローバル展開では各国の規約ローカライズ、輸出管理の確認、EOR/PEOの活用で雇用区分の誤りを防ぎます。
• 紛争対応の準備。 仲裁やクラスアクション放棄がユーザー層に適しているか事前に判断します。法執行機関からの要請はログを取り、法的手続きを確認し、鍵を保有していないなど技術的な限界を説明しましょう。

7. ビルダーのアクションチェックリスト

• 自社の役割を整理：ソフトウェアベンダーか、カストディアンか、ブローカー類似か、決済仲介か。
• マーケティングは事実と機能に集中し、投機的リターンを示唆する表現を避ける。
• カストディと個人データ収集を最小限にし、避けられない接点は文書化する。
• トークン配分、ガバナンス設計、監査状況、リスク判断に関するドキュメントを常に更新する。
• 初期段階から法務、コンプライアンスツール、監査、バグバウンティ、税務専門家の予算を確保する。

8. リーガルアドバイスをプロダクトスピードへ転換する

規制はビルダーを待ってくれません。成果を変えるのは、リーガルの観点をバックログの優先順位付け、財務管理、ユーザーコミュニケーションに組み込むことです。スプリントレビューに法務を参加させ、インシデント対応を訓練し、開示文面もUXと同様に継続改善しましょう。そうすれば、50のFAQは障壁ではなく、プロトコルの競争優位になります。