Web3開発会社は単なるSolidityのコーディングやフロントエンドにウォレットを接続するチームではない
最も強力なプロバイダーは、プロトコルエンジニアリング、スマートコントラクトのセキュリティ、インフラ設計、データインデックス、コンプライアンス意識、そしてプロダクトデリバリーを一つの責任あるプロセスに統合しています。この区別は重要です。なぜなら、契約コードだけでなく統合層の失敗――特にそれが関わる場合――が、数億ドル規模の損失を引き起こしているからです。
2022年3月のRoninブリッジの攻撃では、攻撃者が検証者の資格情報を侵害した結果、およそ$625百万が盗まれました。同年2月のWormholeブリッジの攻撃では、検証失敗により約$320百万の損失が発生しています。これらの事例は、Web3開発サービスが鍵管理、メッセージ検証、監視、展開制御、運用ガバナンスを、アプリケーション機能と並行して取り組む必要性を示しています。
このガイドでは、Web3コンサルティング企業の評価方法、カスタムWeb3開発の範囲、配信モデルの比較、そしてWeb3ダッシュボード構築においてフロントエンドチャートだけではなく専門的なデータアーキテクチャが必要な理由を解説します。
Web3開発会社は実際に何を提供するのか？
Web3開発会社は、分散型アプリケーション、ブロックチェーンインフラ、スマートコントラクトシステム、データプラットフォーム、運用ツールのエンドツーエンドのエンジニアリングを担当します。その責任は、技術調査とアーキテクチャから導入、監視、セキュリティテスト、アップグレード、ドキュメント作成にまで及びます。最高のプロバイダーは、単なるソースコードの納品だけでなく、システムの挙動全体を担当し、アプリケーション層を超えた包括的な責任を持つべきです。
実際には、真剣な関与は通常、いくつかの連結した層をカバーします。
- プロダクトとプロトコルのアーキテクチャ： ユーザージャーニー、信頼の前提、経済フロー、権限、アップグレード要件を定義
- スマートコントラクトエンジニアリング： トークン、ステーキング、レンディング、ガバナンス、市場、ブリッジ、財務収納のロジックを実装
- フロントエンドとウォレット統合： 署名フロー、チェーン切り替え、トランザクションシミュレーション、エラーハンドリング、アカウント抽象化をサポート
- バックエンドとインデックス： イベントパイプライン、API、分析サービス、通知システム、照合プロセスを構築
- インフラストラクチャ： RPCプロバイダー、アーカイブノード、リレイヤー、キー管理、展開環境、可観測性、災害復旧を管理
- セキュリティ保証： 脅威モデル作成、コードレビュー、テスト、ペネトレーションテスト、インシデント対応準備
- 規制と運用調整： 技術設計をトークン分類、ライセンス、データ保護、市場アクセス要件と結びつける
このため、「Web3開発サービス」というフレーズは、「スマートコントラクトプログラミング」の同義語ではなく、広範な配信カテゴリを指すものとして扱うべきです。たとえば、ステーキングプラットフォームには契約、Webアプリケーション、価格オラクル、報酬計算エンジン、サブグラフ、財務のマルチシグウォレット、複数の特権的運用ロールが含まれる場合があります。これらのいずれかに欠陥があれば、製品の安全性が損なわれる恐れがあります。
Sokenでは、アセット、信頼境界、特権行動、外部依存関係、フェイルセーフ状態をマッピングし、その後実装決定を進める方式を採用しています。これにより、コードだけのレビューでは見落としがちなリスク（例：セキュアでないリレイヤー、サービス間の不整合な小数点処理、経済制限を回避できる管理者ロール）を早期に発見できます。
一般的な成果物例
| 提供範囲 | 典型的なアウトプット | 省略時の主要リスク |
|---|---|---|
| 調査 | 要件、脅威モデル、アーキテクチャ決定記録 | 間違った信頼モデルの構築 |
| プロトコル層 | コントラクト、インターフェース、デプロイスクリプト、テスト | ロジックや権限の失敗 |
| アプリケーション層 | Web／モバイルUI、ウォレットフロー、トランザクションUX | 署名エラー、ユーザ損失 |
| データ層 | インデクサー、API、分析、照合 | 不正確な残高報告や古い情報 |
| インフラ | CI/CD、ノードアクセス、秘密情報、監視 | 検出不能または復旧不可能なインシデント |
| 保証 | 監査改善、ペネトレーションテスト、運用マニュアル | コントロールの証拠なしにリリース |
また、開発範囲外の要素も明確に説明すべきです。例えば、オラクルサービス、管理システム、ブリッジ検証ネットワーク、法定通貨支払いコンポーネントなどは、専門ベンダーと別個に対応し、保証する必要があります。明確な境界は、エンジニアリング成熟度の証です。
創業者はWeb3コンサルと社内チームのどちらを選ぶべきか？
創業者は、特化したブロックチェーンの専門知識、迅速な納品、独立したセキュリティ監査、一時的なインフラやコンプライアンス能力へのアクセスが必要な場合にコンサルティングを選択すべきです。長期的なプロダクト所有や迅速なイテレーションには社内チームが適していますが、専門家の採用やセキュアな工学プロセスの確立には時間がかかります。
リスク、プロダクトの成熟度、そして各段階で必要となる能力に基づいて判断すべきです。
| 要件 | Web3コンサル | 社内チーム | ハイブリッドモデル |
|---|---|---|---|
| 初期アーキテクチャ | 専門家への迅速アクセス | 採用に時間がかかる | コンサルがリードし、チームはサポート |
| プロダクトコンテキスト | 構造化された調査が必要 | 組織的知識が豊富 | 共同所有 |
| スマートコントラクト専門知識 | 深い専門能力 | 採用次第 | 外部レビュー＋内部実装 |
| セキュリティの独立性 | 専門的なレビューが容易 | 利害関係の可能性 | 独立した外部保証 |
| 長期運用 | リテーナー契約が必要 | 最も所有権が強い | 内部所有＋専門支援 |
| コスト | 高日給、導入時間低 | 固定費高 | バランス良好 |
| 採用の柔軟性 | 即時対応可能 | 採用次第 | 長期的ターゲット採用 |
よくある誤解は、開発委託により責任も委ねられると考えることです。誤りです。プロジェクトオーナーは、信頼モデルの承認、運用キーの管理、第三者依存の検証、ビジネス前提の正確なエンコードに責任を持ち続ける必要があります。
実践的なモデルは、責任を以下の三段階に分けることです。
- アーキテクチャとリスクの定義：外部専門家を活用して前提を問い、セキュリティ境界を記録
- 構築と検証：コンサルのプロトコル専門知識と内部製品所有権を組み合わせる
- 運用移行：運用マニュアル、展開ノウハウ伝達、監視責任、リリース後サポート期間を設定
Sokenでは、この責任範囲を明示した責任マトリクスの作成を推奨します。誰がコントラクトを展開できるか、誰がアップグレードを承認するか、誰が財務操作を管理し、誰がアラートに対応するかなどを明確にしないと、インシデント時に複数の担当者が誰かが監視していると思い込んでいるケースが多いです。
コンサルタント選定には、単なる実績ではなく、以下の技術的質問も含めるべきです：
- チームはどのチェーン、仮想マシン、インデックスシステム、ウォレット標準をサポートしているか？
- アップグレード可能なコントラクトはどのようにガバナンスされているのか？
- 外部呼び出し、オラクル依存性、特権ロールのテストはどう行われているか？
- デプロイの再現性に関する証拠は何か？
- ソースコード、インフラアカウント、ドキュメント、運用資格情報の所有権は誰にあるか？
- プロジェクトがチェーンを変更したりトークノミクスを修正した場合どうなるか？
- 作業範囲に含まれるテストやセキュリティ関連活動は何か？
優れたdapp開発会社は、単にユーザーインターフェースだけでなく、トランザクション失敗、チェーンリオーダー、ノンス管理、ガス推定、ウォレット非互換性についても議論します。
カスタムWeb3開発に必要な内容は？
カスタムWeb3開発には、ドキュメント化されたアーキテクチャ、脅威モデル、テスト済みのプロトコルコンポーネント、堅牢なデータサービス、安全な展開制御、観測可能な運用インフラ、引き渡し計画が含まれるべきです。製品に特有の経済的または運用上の要件がある場合に価値を持ちますが、カスタムコードは、明確な価値や既知のリスク軽減がある場合に限ります。
「カスタム」の用語は頻繁に誤用されやすいです。既存のテンプレートのリブランドは必ずしもカスタム開発ではありません。オープンソースの実績あるコンポーネントの適応は、安全なエンジニアリングの選択肢です。重要なのは、各コンポーネントが信頼の前提と運用制約に合致しているかです。
カスタム構築の主要コンポーネント
1. プロトコルと経済設計
供給変更、手数料フロー、担保ルール、清算条件、報酬発行、ポーズ権限、アップグレード権を文書化。各経済変数には所有者、検証ルール、異常値に対する対応が必要です。
2. コントラクトとアプリケーションの境界
コントラクトは重要なインバリアントを保証し、フロントエンド頼みの不正行為防止だけに頼らない。アプリは明確なトランザクションプレビュー、シミュレーション（利用可能な場合）、理解しやすい失敗メッセージを提供。バックエンドも明示的に中央集権的な権威となるべきではありません。
3. データとインデックス構造
ブロックチェーンのデータは追加指向で非同期、再編成の可能性もある。インデクサーは重複したイベント、巻き戻し、チェーンリオーダー、欠落した履歴、プロバイダー間の不整合などを処理。ダッシュボードに表示される残高は、信用できるオンチェーン状態と照合できるべきです。
4. 展開とアップグレード管理
本番環境の展開にはバージョン管理されたスクリプト、多署名承認、環境分離、決定論的アーティファクト追跡、ロールバックまたは一時停止計画を使用。アップグレード可能コントラクトには、アップグレードプロキシだけでなく、ガバナンス制御、ストレージレイアウト検証、変更を周知する仕組みも必要です。
5. テストと保証
単体テスト、インバリアントテスト、結合テスト、フォークを利用したテスト、ファジング、静的解析、手動レビュー、運用訓練を組み合わせる。NISTのSecure Software Development Framework、SP 800-218やOWASPガイダンスも参考に。
セキュリティの洞察: 高額なWeb3失敗から守る最も有効な防御は、単一の監査ではなく、脅威モデル作成、インバリアントテスト、最小権限の展開、監視、インシデントリハーサルを連鎖させることです。これにより、見落としのリスクを最小化します。
過去の事例からも、この層状アプローチの重要性が明らかです。Euler Financeは、2023年3月に寄付と清算ロジックを絡めた攻撃によりおよそ$197百万を喪失しました。この事件はフロントエンドの問題だけではなく、プロトコルの会計処理、トークンフロー、攻撃者制御の状態遷移の連携に関わるものでした。2021年8月のPoly Networkは、クロスチェーンメッセージと特権実行ロジックに関与した攻撃で、初期見積もりで約$611百万の損失を引き起こしました。
規制対象や市場向けプロダクトを構築するチームは、技術設計と法的分析を連携させる必要があります。トークンの権利、管理体制、マーケティング主張、ガバナンス構造、クライアントの地域等は、導入要件に影響を与え得ます。Sokenの暗号法務サービスは、技術提供と並行して法的見解、トークン分類、コンプライアンス文書の作成に役立ちます。
SokenのWeb3開発＆セキュリティサービスは、アーキテクチャ設計、アプリケーションデリバリー、スマートコントラクトレビュー、ペネトレーションテスト、インフラ保証を組み合わせ、プロジェクトの範囲に応じて最適なソリューションを提供します。
Web3のダッシュボード作成はどう行う？
Web3のダッシュボード作成には、非同期のオンチェーンイベントからリアルタイムで照合・権限付きの情報に変換する検証済みデータパイプラインが必要です。完成したダッシュボードは、確定状態と保留状態を区別し、データの出所を明示し、リオーダーに対応し、未完成のインデックスを財務情報として扱わないように防止します。
DeFiプロトコルのダッシュボードは、従来の分析ページよりも運用制御システムに近く、総ロック価値（TVL）、担保比率、報酬発行、財務状況、ガバナンス提案、検証者のパフォーマンス、清算待ちリスト、クロスチェーンメッセージなどを表示します。それぞれの測定項目は出所や更新頻度、信頼度、失敗モードが異なります。
推奨されるダッシュボードのアーキテクチャ
-
ブロックチェーンデータのソース
信頼できるRPCエンドポイント、必要に応じたアーカイブアクセス、関連コントラクトのイベントリスナーを使用。重要な残高は、直接コントラクトリードや独立管理の情報源と照合。 -
取り込みと正規化
生のイベントを統一した内部モデルに変換。トークンの小数点、コントラクトのアップグレード、チェーン識別子、プロキシアドレス、イベントスキーマ変化に対応。 -
照合作業層
定期的にインデックスされた状態とオンチェーン状態を比較。差異を検知し、通知・記録し、無視しない。 -
APIとアクセス制御
公開分析と運用データを分離。認証・認可・レート制限・監査ログ・インジェクション・DoS防止策を適用。 -
フロントエンドとアラート
タイムスタンプ、ブロック番号、確定状況、出所ラベルを表示。重要なアラートは複数チャネルで関係者に通知。
ダッシュボードの種類と設計優先事項
| 種類 | 重要指標 | 重要コントロール |
|---|---|---|
| DeFiプロトコル | TVL、利用状況、担保、清算活動 | オラクルの鮮度＆照合作業 |
| 財務 | 資産残高、送金、承認、ベスティング | マルチシグの監査証跡 |
| ガバナンス | 提案、 quorum、投票力、実行状況 | スナップショットから実行までの一貫性 |
| ブリッジ運用 | メッセージ、検証者、確認、遅延 | リプレイ防止と異常アラート |
| NFTマーケット | 出品、販売、ロイヤルティ、所有権 | イベント順序とメタデータ整合性 |
| 検証者・ノード群 | 稼働率、取りこぼし、ピアの健全性 | アラートのエスカレーションと冗長性 |
ダッシュボードは、裏付けとなるデータが暫定的な場合でも、「確実」と示唆してはいけません。例として、ブロックに含まれるトランザクションは後にリオーダーされる可能性がありますし、クロスチェーンメッセージは一方のネットワークでは発行済みでも、もう一方では未確定であることがあります。「保留」「確定済み」「最終化済み」「照合済み」などのラベルは操作のコントロールであり、見栄えだけのものではありません。
SokenのWeb3ダッシュボード作成アプローチは、まずは指標辞書から始めます。すなわち、表示される全ての値について、定義・出所・計算方法・更新頻度・期待誤差・責任者を明示します。これにより、「treasury balance」といった用語を複数部門が異なる意味で使うミスを防ぎます。
データモデルの定義後、次はアプリケーション、コントラクト、API、インフラの独立したレビューを実施します。SokenのSecurity X-Rayは、詳細なセキュリティ評価の前段として有効です。
最優先推奨： 製品がコントラクト操作、特権ワークフロー、ブロックチェーンデータに依存している場合は、SokenのWeb3開発・監査・ペネトレーションテストサービスを利用し、展開前にアーキテクチャと制御の妥当性を検証してください。リオーダー処理や特権アクセス、照合、展開ガバナンスに関わるリスクこそ、技術的な総合評価に最も価値があります。
Web3開発会社が示すべきセキュリティコントロールは？
Web3開発会社は証拠をもって安全性を示す必要があります。具体的には、脅威モデル、テスト結果、アクセス制御設計、再現可能な展開、依存関係管理、監視計画、インシデント対応手順、独立レビューです。経験の主張だけではなく、リスクの特定・緩和・確認をどのように行っているかを示す資料が重要です。
最低限持つべき証拠パッケージは次の通りです。
- 脅威モデル： 資産、攻撃者、信頼境界、悪用ケース、残留リスクの許容範囲
- 権限一覧： 所有者、運用者、一時停止者、アップグレード管理者、リレイヤー、オラクル、緊急役割
- テスト記録： 単体、結合、ファズ、インバリアント、フォーク、ネガティブパス、回帰テスト
- 依存関係登録簿： コントラクトライブラリ、API、RPCプロバイダー、インデクサー、ブリッジ、オラクル、クラウドサービス
- 展開制御： 環境分離、多署名承認、秘密情報管理、アーティファクトハッシュ、変更履歴
- 監視計画： 異常な資金引き出し、権限変更、オラクル逸脱、失敗トランザクション、サービスダウンの閾値
- インシデント対応： 連絡先、エスカレーション、ポーズ権限、証拠保存、ユーザ通知、復旧判断
アクセス管理は特に重要です。展開キーは1人の開発者のPCに置かず、管理権限は役割と範囲で制限すべきです。Ronin攻撃の例からもわかる通り、運用セキュリティの脆弱さが、プロトコルの堅牢さを凌駕することがあります。
また、次のようなWeb3固有の故障モードへの対応も求められます。
- チェーンリオーダーとファイナリティの差異
- ネットワーク間のリプレイ攻撃
- 間違ったチェーンIDやドメインセパレータ
- トークン承認の乱用
- オラクルの鮮度遅延や操作
- プロキシストレージの衝突
- 精度や小数点誤差
- ガス負荷の高い入力によるDoS
- 外部呼び出し失敗・部分実行
- 依存性の停止やレート制限
当社の監査実績では、「ポーズ」機能は慎重に管理された安全策とみなします。迅速に起動できないポーズは効果的ではなく、また、1つの非保護アカウントからトリガーできるポーズは、中央集権化と危険性をもたらします。
さらに、Sokenの公開監査レポートを確認し、問題点の構造化、優先順位付け、修正方針を理解することもおすすめします。監査の質は方法論と技術的深さによって評価され、ページ数だけでなく、内容の理解も重要です。
チームはどのようにデリバリー・コンプライアンス・長期運用を管理すべきか？
Web3プロジェクトは、展開を終止点とせず、運用への移行をコントロールされた段階と捉えることが成功のカギです。資産やユーザを本番環境に公開する前に、責任者の明示、リリースゲートの設定、法的仮定の記録、監視範囲の確立、アップグレード手順、リリース後の見直しスケジュールを整備すべきです。
実践的なデリバリーワークフローは次の通りです。
-
プロダクトの境界を定義
オンチェーン・オフチェーン、管理・非管理、パーミッション型・パーミッションレス、サードパーティ依存を識別。 -
アーキテクチャ決定を記録
チェーン選定、ブリッジ利用、アップグレード性、オラクル設計、インデックス、ウォレットサポート、データ保持を記録。 -
最小限の安心できる機能を構築
初期機能と資産の露出を限定。未テストのガバナンス、レバレッジ、クロスチェーン通信、自動流動性は避ける。 -
敵対的テスト
不正入力、悪意あるトークン、操作した価格、乗っ取られた役割、古いデータ、失敗したRPC呼び出し、異常チェーン状態を検査。 -
ゲートを通じてリリース
コードレビュー、テスト完了、展開承認、監視準備、インシデント連絡を確認。 -
運用と再評価
受付アラート、特権活動、依存関係の変更、ユーザからの報告、経済仮定を定期見直し。
コンプライアンスも早期からプロダクトの設計と連携させる必要があります。国 jurisdiction、顧客種別、管理モデル、トークン権利、制裁管理、マーケティング戦略が導入やアクセス制限、トランザクションモニタリング、記録保持に影響します。SokenのCrypto Mapは、規制環境の比較検討に役立ちます。
長期的なメンテナンスも契約の明示が不可欠です。脆弱性対応時間、サポート対象チェーン、依存関係のアップグレード、緊急時対応、知的資産の所有権、ドキュメントの標準、スコープ変更の手順を規定します。最初の見積もりが低くとも、運用上の問題をすべて新規案件として扱えば、コストは膨らみます。
Soken Hubは、Web3の工学、セキュリティ、規制に関する研究・ガイダンスを集約した場所です。特に複雑な案件では、これら資料を内部決定ログに整理し、将来の開発者が特定のチェーンやプロキシモデル、オラクル、データパイプラインの選定理由を理解できるようにすることが望ましいです。
契約締結前にdapp開発会社をどう評価すればよいか？
技術的な調査、類似した納品実績の証拠、安全手法、所有条件、運用準備状況を総合的に評価すべきです。最も効果的な選定は、口頭プレゼンやプロトタイプ、サポートチェーンリストだけに頼らず、書面によるアーキテクチャの課題提示とサンプルアウトプットの評価を合わせて行います。
以下のチェックリストを活用してください。
技術面
- 取引の全フェーズを説明できるか？
- ウォレットエラー、ノンス競合、ガス推定、ファイナリティを理解しているか？
- インデクシングや照合の設計ができるか？フロントエンドのみでは不十分です。
- 特権ロールや経済インバリアントのテストを行っているか？
- 展開後のシステム運用能力はあるか？
セキュリティ成熟度
- コーディング前に脅威モデルは作成されたか？
- 監査結果は修正と再テストを経て管理されているか？
- 依存関係や第三者サービスは記録されているか？
- 運用キーは分離され、適切に管理されているか？
- インシデント対応計画は展開計画に含まれるか？
商業・所有条件
- コードリポジトリ、デプロイスクリプト、インフラアカウント、ドキュメントの所有者は誰か？
- オープンソースライセンスやサードパーティ要素は明示されているか？
- サポート期間はどうか？
- 重要な脆弱性に対するサービスレベルは？
- チェンジリクエストやチェーン移行、プロトコル変更はどう料金設定されるか？
プロダクトとコミュニケーション
- 提供者は安全性の低い前提を指摘できるか？
- マイルストーンと検証可能な受け入れ基準は連動しているか？
- 非技術者にリスクを明確に説明できるか？
- プロトタイプと運用可能システムを区別できるか？
最後に、候補企業に、提案製品がどのように失敗し得るかの「5つのケース」を特定させ、確率とインパクトで順位付けさせることも有効です。成熟したチームは、オラクルの稼働停止、運用者の盗難、トークンの小数点誤差、ダッシュボードの古いデータ、アップグレード失敗といったシナリオを恐れず議論します。
Web3コンサル会社は、不確実性の中での意思決定の質で評価されるべきです。フレームワークやライブラリ、チェーンは変わりますが、「脅威分析」「展開制御」「検証可能なデータ」「責任ある運用」といった原則は durable な指標です。
最も確実な次のステップは、事前に1ページのシステム境界と責任マトリクスを作成し、候補ごとに最も重大な失敗パスを特定させることです。契約書、ウォレット、API、ダッシュボード、サードパーティ、特権ロール、ターゲットユーザを含め、その上で潜在的なリスクを評価させてください。
Sokenの技術提供モデルは、カスタムWeb3開発とセキュリティ保証、運用準備を結び付け、アーキテクチャから運用までの一つの管理されたルートを提供します。