Rollupのシステム開発の発注/外注/依頼/委託方法について

Rollupのシステムを発注するなら、まず「既存のL2上にアプリを開発する」のか「自社専用のRollupチェーンを立ち上げる」のかを分けて考えることが重要です。前者はスマートコントラクトと周辺アプリが中心ですが、後者はシーケンサー、ブリッジ、データ可用性、証明、監視、障害時の復旧まで含む基盤システム開発になります。

本記事では、Rollupのシステムを発注・外注・委託する際の進め方を、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較の順に解説します。2026年時点で確認できる公開価格と公式資料を参照しながら、初期費用だけでは見えにくいDA費、RPC、監査、24時間監視、鍵管理まで含めて判断できるように整理します。

▼全体ガイドの記事
・Rollupのシステム開発の完全ガイド

Rollupのシステムを発注する前に知っておきたい全体像

Rollupのシステム発注前に構成を整理するイメージ

Rollupは、トランザクションの実行をEthereumなどのL1の外側でまとめ、状態更新に必要なデータや証明をL1へ投稿する仕組みです。発注では「速くて安いチェーンを作る」という表現だけで依頼せず、どの処理をL2で行い、どの情報をL1や外部DAに残し、誰が運用するのかまで明確にします。

既存L2上のアプリ開発と独自Rollupは別の発注です

既存のBase、Arbitrum、OP Mainnet、ZKsyncなどにdAppを載せる場合、主な成果物はスマートコントラクト、バックエンド、ウォレット連携、管理画面、テスト、監査です。チェーンのシーケンサーやL1コントラクトを自社で構築する必要がないため、事業仮説を検証する段階ではこの方式が第一候補になりやすいです。

一方、自社専用のRollupを立ち上げる場合は、実行環境、シーケンサー、Batcher、ProposerやVerifier、ブリッジ、RPC、インデクサー、エクスプローラー、監視を準備します。独自ガス代、専用の手数料設計、許可型アクセス、チェーン間連携などの目的がなければ、独自チェーンの構築費と運用負担に見合わない可能性があります。

発注範囲はシーケンサー・DA・ブリッジまで含めます

ユーザーのトランザクションを受け付けて順序付けするのがシーケンサーです。シーケンサーが停止した場合に取引を再開できるか、単一運営者による検閲やMEV、鍵の漏えいにどう備えるかを要件に入れます。Optimistic Rollupでは不正を争うFault Proofやチャレンジャー、ZK Rollupでは証明を生成するProverとL1上のVerifierが重要です。

DAは、L2の状態を復元するための取引データを誰が取得できるかに関係します。Ethereumのblobを使う場合でも、blobは永続ストレージではありません。EthereumのEIP-4844ではblobの保持期間が約18日とされているため、監査・紛争対応・障害復旧に必要な履歴を別のアーカイブへ保管する設計が必要です(出典: Ethereum Improvement Proposal 4844、2026年8月確認)。

技術要件と事業・法務要件を分けて整理します

取引量や確定時間だけでなく、どの利用者がどの資産を扱うのか、トークンやステーブルコインを発行するのか、利用地域はどこかを整理します。金融・決済用途では、Rollup技術を採用することと、交換、カストディ、送金、仲介などのサービスを提供することを切り分ける必要があります。法令の適用は事業形態で変わるため、RFP作成段階から弁護士やコンプライアンス担当を参加させます。

Rollupのシステムの発注形態はどう選びますか?

Rollupの発注形態を比較するイメージ

結論から言うと、短期間で事業検証をしたい場合は既存L2またはRaaS、運用の自由度や独自経済圏を重視する場合はオープンソースStackの自社運用が候補です。新しいVMや証明方式そのものが競争力になる場合を除き、フルスクラッチは最後に検討します。

既存L2へのdApp開発を選ぶケース

既存L2への発注は、NFT、ゲーム、会員証、決済、データ証明など、アプリケーション価値を早く検証したい企業に向いています。チェーン基盤の保守を委託する範囲が小さく、開発会社にはコントラクト、API、画面、ウォレット、テスト、監査の見積もりを依頼しやすいです。

ただし、チェーン混雑時の手数料、親チェーンのアップグレード、ブリッジの仕様、RPC障害の影響は残ります。発注書には対応チェーン、利用するブリッジ、RPCの冗長化、トランザクション失敗時の再送、障害時のユーザー通知まで含めます。

RaaSへチェーン運用を外注するケース

RaaSは、OP Stack、Arbitrum系、ZK系などの基盤を使い、チェーンのデプロイ、クラウドインフラ、DA、RPC、アップデート、監視の一部をサービスとして委託する方式です。自社で全ノードを構築するより早く専用チェーンを試せますが、月額料金だけでなく、L1投稿費、DA費、Prover費、ブリッジ、エクスプローラー、追加サポートが別請求になることがあります。

公開価格の一例として、AWS MarketplaceのCaldera Rollups掲載情報では、1か月契約のRollup podが月額500米ドル、Blockscoutが月額500米ドルとされています。AWSの追加インフラ費がかかる旨も明記されているため、この金額を本番運用の総額とみなさないことが大切です(出典: AWS Marketplace「Caldera Rollups」、2026年8月確認)。

Stackの自社運用やフルスクラッチを選ぶケース

自社運用は、チェーンの設定、ノード、シーケンサー、アップグレード、監視、障害復旧を自社で管理する方式です。特定ベンダーへの依存を下げやすく、RFPで決めた運用要件を自社の方針に合わせられますが、ブロックチェーンエンジニア、SRE、セキュリティ、運用責任者を継続的に確保する必要があります。

新規VM、独自の証明方式、独自DA、独自ブリッジまで開発するフルスクラッチは、研究開発や強い差別化要件がある場合に限って検討します。既存の監査実績やツールを使いにくくなるため、発注前に「なぜ既存Stackで実現できないのか」を文書化できなければ、RaaSやStack利用へ戻す判断が合理的です。

Rollupのシステムを外注する進め方

Rollupの外注プロジェクトを進めるイメージ

Rollupの発注は、いきなり本番チェーンの開発契約を結ぶより、目的と責任分界を決めてからPoC、設計、本番の順に進めると失敗を抑えやすいです。特に資産を扱う場合は、機能の完成だけでなく、停止、再同期、出金、鍵の失効、履歴の復元を受入条件に含めます。

1. 目的・KPI・対象ユーザーを決めます

最初に、Rollupで解決したい課題を「手数料を下げる」「取引確定を早める」「自社経済圏を作る」「アクセスを許可制にする」などに分解します。月間取引数、ピーク時の秒間トランザクション数、許容遅延、停止許容時間、利用地域、資産の種類、想定TVLも仮置きします。

この段階で既存L2を使った小さなPoCを実施し、ウォレット接続、コントラクト、ブリッジ、トランザクション失敗時のUXを確認します。PoCの目的は本番品質を作ることではなく、独自チェーンが必要になる要因を数値で確かめることです。

2. RFPと要件一覧を作成します

RFPには、目的、対象ユーザー、業務フロー、機能要件、非機能要件、希望スケジュール、予算の考え方、納品物、運用体制、提案依頼事項を記載します。Rollup固有の項目として、OptimisticかZKか、EVM互換性、親チェーン、DA、シーケンサーの運営者、ガストークン、ブリッジ、証明、RPC、アーカイブ、アップグレード権限を並べます。

要件を「必須」「できれば必要」「提案に任せる」に分けると、各社の見積条件をそろえられます。たとえば、1,000TPSという希望値だけでは測定条件が不明です。トランザクションの種類、成功率、確定の定義、同時利用者数、負荷試験の時間、L1投稿の遅延まで定義して初めて比較可能になります。

3. 設計・開発・監査を分けて契約します

設計では、アーキテクチャ図、データフロー、鍵管理、障害時の状態遷移、復旧手順、監査方針を確定します。開発会社には、コントラクト、ノード設定、インフラコード、CI/CD、監視ダッシュボード、運用手順書を成果物として明示してもらいます。

監査は開発会社の自己チェックだけで完了させません。ブリッジ、入出金、メッセージング、証明検証、権限管理、アップグレード機構を対象に、独立監査やバグバウンティを組み合わせます。監査で見つかった指摘の修正確認を誰が担当するかも、工程と費用に含めます。

4. テスト・段階リリース・運用移管を行います

テストネットでは、通常機能だけでなく、シーケンサー停止、L1投稿失敗、RPCの遅延、ノード再同期、DAデータの欠損、証明生成の遅延、ブリッジ出金、管理者キーの切り替えを試験します。負荷試験の結果はTPSだけでなく、失敗率、確定時間、復旧時間、追加クラウド費用と一緒に記録します。

本番では、利用者数やTVLに上限を設け、段階的に開放します。リリース後はオンコールの連絡網、監視アラート、インシデントの重大度、一次対応時間、緊急停止と再開の承認者を定めます。運用移管では、ソースコードだけでなく、鍵、設定、ログ、バックアップ、データ復元手順、ベンダーへの問い合わせ履歴も引き継ぎます。

Rollupのシステムの費用相場とコストの内訳

Rollupのシステム費用を見積もるイメージ

Rollupの発注費用は、方式、チェーンの所有範囲、監査範囲、運用時間帯、想定取引量で大きく変わります。以下の金額は市場全体の固定料金ではなく、リサーチノートと公開価格をもとにした編集上の推定です。要件定義後の個別見積もりを代替するものではありません。

初期費用は構築パターンで分けて考えます

既存L2上のdAppとスマートコントラクト開発は、編集用の推定で300万〜2,000万円程度、期間は2〜6か月が一つの目安です。RaaSを使ったテストネットやPoCは100万〜1,000万円程度、1〜3か月程度が目安になります。本番RollupをRaaSで立ち上げ、ブリッジ、監視、運用まで委託する場合は、初期費用1,500万〜6,000万円程度、3〜9か月程度のレンジで見積もるケースがあります。

複数ノードやセキュリティ体制を含む自社運用の独自Rollupは、5,000万〜2億円程度、9〜18か月程度の推定レンジです。新規VM、証明系、ブリッジなどをフルスクラッチで作る場合は、1億〜5億円以上、18〜36か月以上になる可能性があります。いずれも特定会社の確定価格ではなく、機能、体制、監査、法務、運用の範囲で上下します。

見積書では開発費を工程別に分解します

見積書は一式表記ではなく、要件定義、プロトコル・チェーン設計、スマートコントラクト、ノード・インフラ、フロントエンド、テスト、監査対応、リリース、運用設計に分けます。リサーチノートの編集用目安では、要件定義10〜15%、プロトコル・チェーン設計15〜25%、スマートコントラクトとノード実装25〜40%、テスト・負荷試験10〜20%、監査・リリース・運用設計15〜30%程度です。

第三者監査は、規模や対象範囲により数百万円から数千万円以上になることがあります。監査費を開発費に含めるのか、監査会社へ直接支払うのか、指摘修正と再監査を何回まで含むのかを確認します。開発費が安くても監査や復旧設計を削っていれば、後から大きな追加費用になるため注意が必要です。

ランニングコストはTCOで比較します

ランニングコストには、クラウド、ノード、RPC、インデクサー、エクスプローラー、DA、L1ガス、Prover、バックアップ、監視、セキュリティパッチ、オンコール、監査更新が含まれます。Conduitの公式RPC料金表では、Freeが月額0米ドル、Proが月額50米ドルで、Proには10億CUが含まれ、超過分は100万CUあたり0.10米ドルと記載されています。ただし、これはRPCの公開例であり、Rollup全体の運用費ではありません(出典: Conduit公式ドキュメント、2026年8月確認)。

本番運用の推定では、RaaSの月額、クラウド、DA、監視、保守、サポートを合わせて月50万〜500万円程度、自社運用では年1,000万〜1億円超となる可能性があります。これらは取引量、SLA、ノード数、Proverの計算資源、監査頻度で変わるため、月額固定費と従量費を分けた見積もりを依頼します。

RollupのRFPと要件整理で決めるべき事項

RollupのRFPと要件を整理するイメージ

RFPは、開発会社に価格だけを聞く文書ではありません。同じ前提で提案と見積もりを出してもらい、各社の違いを比較するための文書です。Rollupでは技術選択と運用責任が費用に直結するため、機能要件と同じ分量で非機能要件を記載します。

事業要件と利用シナリオを記載します

RFPには、対象サービス、利用者、取引やメッセージの流れ、対応する資産、収益モデル、対象国、データ保存期間、管理者の権限、社内承認フローを記載します。ゲームならゲーム内資産とユーザー体験、金融なら本人確認、取引記録、凍結、監査証跡など、チェーン以外の業務要件も漏らさないようにします。

ピーク時の負荷は、平均値と分けて示します。1日100万件でも、特定の10分に集中する場合と24時間均等に発生する場合では必要なシーケンサー、RPC、インデクサーの設計が変わります。トランザクションのサイズ、コントラクト実行の複雑さ、同時接続数、許容する再送回数も資料に含めます。

技術・非機能要件を数値と責任者で決めます

技術要件は、採用Stack、EVM互換性、親チェーン、OptimisticまたはZK、DAの方式、シーケンサーの構成、Prover・Verifier、ブリッジ、RPC、インデクサー、エクスプローラー、データ搬出の可否を確認します。非機能要件は、可用性、RTO・RPO、復旧時間、確定時間、監視範囲、バックアップ、ログ保存、脆弱性対応、SLAの対象を記載します。

「24時間監視あり」という表現だけでは不十分です。RPCだけを監視するのか、シーケンサー停止、L1へのBatch投稿失敗、DAの取得不能、Prover遅延、ブリッジ残高の異常まで検知するのかを分けます。検知後の一次対応、エスカレーション、ユーザーへの告知、復旧判断の責任者もRFPで指定します。

納品物と終了時のデータ搬出を明記します

納品物には、ソースコード、スマートコントラクトのアーティファクト、設定ファイル、インフラコード、CI/CD、鍵管理手順、監視設定、テスト結果、監査報告書、運用手順書、障害対応記録を含めます。RaaSの場合は、チェーン契約、管理者権限、シーケンサー鍵、DAデータ、ログ、インデックス、バックアップを誰が所有するのかを確認します。

契約を終了した後に別会社へ移管できるかも重要です。データを標準形式でエクスポートできるか、移管期間と費用、サポートの範囲、秘密情報の返却・破棄、ブリッジやRPCの切り替え、利用者への告知を事前に決めます。移管不能なサービスは、月額が安くても事業継続リスクが高くなります。

Rollupの委託先選定と見積比較のポイント

Rollupの委託先と見積を比較するイメージ

委託先は、プロトコル開発元、RaaS事業者、インフラ会社、SIer、スマートコントラクト監査会社を同じ基準で順位付けしないことが大切です。どのレイヤーを誰が提供し、障害時に誰が責任を負うのかを整理したうえで、必要な会社を組み合わせます。

会社の役割と実績を一致させます

OP Stackを採用するなら、OP Labs・Optimismの公式ドキュメントで構成とアップグレード方針を確認し、実装会社がどこまで対応できるかを見ます。Arbitrum系なら、Arbitrumのチェーン立ち上げ案内に示されるカスタム項目を踏まえ、実際のデプロイ、ブリッジ、運用、障害対応の経験を確認します。プロトコル元の知名度だけで、発注先の運用力まで推測しないことが重要です。

Polygon CDKやAgglayerなどを比較する場合も、技術の提供元と本番展開・運用の担当会社を分けて確認します。Polygon Developer DocsのCDK案内では、チェーン構築とエコシステム連携に関する情報を確認できます。候補会社には、稼働中のチェーン、障害履歴、監査報告書、ソースコードの公開範囲、緊急時の連絡体制を提示してもらいます。

見積比較は金額ではなく前提条件をそろえます

見積書を比較するときは、初期費用、月額固定費、従量費、第三者費用、追加変更費、保守費を分けます。L1ガス、DA、Prover、クラウド、RPC、監査、バグバウンティ、法務、SLA、夜間対応が含まれるかを同じ表に転記します。安い見積もりほど、含まれない項目を確認することが重要です。

期間も、単に「6か月」と比べません。要件定義、設計、テストネット、監査、本番移行、運用移管の各期間を分け、発注者側のレビュー期間を含むか確認します。提案内容に未確定の技術選択が残っている場合は、調査・設計フェーズを先行発注し、その後に本番開発の見積もりを更新する方法もあります。

セキュリティと復旧力を評価します

セキュリティ評価はコントラクト監査だけで終わらせません。ブリッジの資産集中、管理者キー、マルチシグ、Timelock、シーケンサーの認証、ノード間通信、Prover、DAの復元性、ログ改ざん、アップグレード手順を脅威モデルに入れます。OWASPのSmart Contract Security Verification Standardも、要件やテスト項目のたたき台として活用できます。

委託先には、シーケンサーが停止した場合の再開時間、L1コントラクトに異常があった場合の緊急停止、出金が詰まった場合の代替経路、DAデータが取得できない場合の復旧方法を説明してもらいます。過去のインシデントを隠さず、再発防止策と残る制約を提示できる会社ほど、長期運用のパートナーとして評価しやすいです。

Rollupの契約形態と責任分界の決め方

Rollupの契約と責任分界を確認するイメージ

Rollupでは、請負契約だけで全工程を固定するより、要件の不確実性に応じて契約を分けることが有効です。設計や調査は準委任、成果物と受入条件が固まった開発は請負、運用はSLA付きの保守・運用委託とするなど、工程ごとに適した形を選びます。

要件整理・PoCは準委任が向いています

独自チェーンの要否、方式、DA、シーケンサー、規制対応が未確定な段階では、作業時間や調査成果を基準にする準委任契約が適しています。調査結果、アーキテクチャ案、比較表、リスク一覧、PoCコード、次工程の見積条件を成果として定義すると、作業の進捗を評価しやすくなります。

開発は成果物・受入条件・変更手続きを定めます

請負契約にする範囲では、ソースコード、コントラクト、設定、テスト結果、監査対応、手順書などの成果物と、受入テストを具体化します。TPS、確定時間、復旧時間、出金、権限、ログ、データ復元などを測定可能な条件にし、未達時の再実施、減額、延期、契約解除などの扱いを契約書で確認します。

運用委託はSLA・鍵・データ所有を明確にします

運用契約では、稼働率だけでなく、どのサービスがSLA対象かを明記します。RPCの可用性だけを保証するのか、シーケンサー、Batch投稿、DA、Prover、ブリッジ、エクスプローラーまで含むのかで意味が変わります。障害の重大度、一次応答時間、復旧目標、報告書、再発防止、計画メンテナンスも定めます。

管理者キー、シーケンサー鍵、クラウドアカウント、DNS、ログ、バックアップ、監査資料の所有者を発注者側に置き、委託先には必要最小限の権限を付与します。契約終了時の返却、消去証明、引き継ぎ支援、ベンダー側の再委託先まで確認します。ここが曖昧なままでは、技術的には移行できても事業としてチェーンを取り戻せない場合があります。

よくある質問(FAQ)

Rollupのシステム発注に関するよくある質問

Rollupの発注では、技術方式、費用、委託先、法務、運用責任について同じ疑問が繰り返し出ます。ここでは、発注前に確認しておきたい質問へ直接回答します。

Rollupのシステムは既存L2の利用と独自チェーンのどちらがよいですか?

アプリの検証や早期リリースが目的なら、既存L2の利用が第一候補です。独自ガス代、専用ブロックスペース、許可型アクセス、独自経済圏など、既存L2では解決できない要件がある場合にRaaSや自社運用を検討します。

Rollupのシステムを外注すると費用はいくらかかりますか?

既存L2上のdAppは編集上の推定で300万〜2,000万円程度、RaaSの本番チェーンは1,500万〜6,000万円程度、自社運用の独自Rollupは5,000万〜2億円程度が一つの目安です。監査、DA、L1ガス、Prover、RPC、24時間監視、法務を含むかで変わるため、初期費用とTCOを分けて見積もってもらいます。

ZK Rollupならスマートコントラクト監査は不要ですか?

不要にはなりません。ZK Rollupでも、ブリッジ、入出金、証明検証、管理者権限、アップグレード、Prover、ノード、アプリのコントラクトにリスクがあります。ZKだから安全と決めつけず、独立監査、テスト、運用監視、緊急停止、復旧手順を含む脅威モデルを作ります。

Rollupのシステム開発は請負契約と準委任契約のどちらがよいですか?

要件や技術選択が固まっていない調査・PoCは準委任、成果物と受入条件が明確な開発は請負、継続監視や障害対応はSLA付きの運用委託が向いています。全工程を一つの契約にまとめる場合でも、工程ごとの成果物、費用、責任、変更手続きを分けて記載します。

まとめ

Rollupのシステム発注をまとめるイメージ

Rollupのシステムを発注するときは、最初に既存L2上のアプリ開発と独自Rollupチェーンの構築を分けます。独自チェーンが必要なら、RaaS、オープンソースStackの自社運用、フルスクラッチの順に、目的、自由度、運用体制、移行可能性を比較します。

発注前にRFPで責任分界とTCOを可視化します

RFPには、取引量、確定時間、DA、シーケンサー、ブリッジ、監視、復旧、監査、鍵、データ搬出、SLAを記載します。見積比較では、初期開発費だけでなく、L1ガス、DA、RPC、Prover、クラウド、監査、保守、インシデント対応を含むTCOをそろえます。公開価格は一部サービスの参考値であり、本番の総額ではない点にも注意します。

小さなPoCから発注を始めます

最初の相談では、完成したチェーンをいきなり発注するのではなく、事業目的と技術選択を確認する調査・PoCから始める方法が安全です。PoCの結果をもとに、発注範囲、契約形態、委託先、費用、運用体制を更新し、本番Rollupに進むか既存L2を採用するかを判断します。

▼全体ガイドの記事
・Rollupのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。