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

Rollupのシステム発注は、既存L2での小さな検証から始め、要件と責任範囲を決めたうえで、PoC、設計、監査を経て本番運用へ進む流れで行います。加えて、独自チェーンが本当に必要かを数値で確かめながら進めると、各段階で発注する範囲を判断しやすくなります。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

Rollupは、EthereumなどのL1の外側で取引をまとめ、状態更新に必要なデータや証明をL1へ投稿する仕組みです。発注する側は、L2で行う処理、L1や外部DAに残す情報、運用者を先に明確にしておきます。

既存L2上のアプリ開発と独自Rollupの違い

既存L2のdAppと独自Rollupは、成果物の範囲も運用責任の持ち方も異なります。

• 既存L2のdApp：チェーン基盤の上で、アプリ側を開発します。
• 既存L2を選ぶ目安：シーケンサーやL1コントラクトを自社で構築せず、事業仮説を検証したい段階に向きます。
• 独自Rollup：専用チェーンの基盤一式を構築し、そのまま運用します。
• 独自Rollupの判断：独自ガス代、専用手数料、許可型アクセス、チェーン間連携などの要件がなければ、費用と運用負担に見合わない場合があります。

既存L2の候補には、Base、Arbitrum、OP Mainnetがあります。ZKsyncなども候補になります。

成果物の中心は、スマートコントラクト、バックエンド、ウォレット連携です。管理画面、テスト、監査も発注に含めます。

独自Rollupでは、まず実行環境とシーケンサーを準備します。続いて、Batcher、ProposerやVerifier、ブリッジを整えます。RPCとインデクサー、エクスプローラーと監視も整えます。

シーケンサー・DA・ブリッジまでの発注範囲

発注時には、基盤要件として処理の順序付けと障害時の再開を決めておきます。検閲やMEVへの備え、鍵の管理、証明とデータ保管も合わせて定めます。

• シーケンサー：停止後の再開と検閲、MEV、鍵漏えいへの対策を決めておきます。
• 証明：Optimistic RollupではFault Proofやチャレンジャー、ZK RollupではProverとL1上のVerifierが対象です。
• DAと履歴：データの取得者とアーカイブ先を決めておくと、復旧や監査に役立ちます。

Ethereumのblobは永続ストレージではありません。EthereumのEIP-4844では保持期間が約18日とされるため、監査・紛争対応・障害復旧に使う履歴は、別のアーカイブへ保管する必要があります（出典: Ethereum Improvement Proposal 4844、2026年8月確認）。

技術要件と事業・法務要件の整理

技術要件では、取引量や確定時間を定めます。事業要件では、利用者と扱う資産、利用地域を整理します。加えて、トークンやステーブルコインの発行の有無も確かめます。

金融・決済用途では、Rollup技術の採用と、サービス提供を切り分けて考えます。サービス提供には、交換やカストディ、送金があります。仲介も同じ切り分けの対象です。

法令の適用は事業形態によって変わるため、RFPを作る段階から、弁護士やコンプライアンス担当者にも加わってもらいます。

Rollupのシステムの発注形態の選び方

短期の事業検証なら既存L2かRaaSを、運用の自由度や独自経済圏を求めるならStackの自社運用を検討します。フルスクラッチは、新しいVMや証明方式そのものが競争力になる場合を除き、最後の選択肢になります。

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

NFTやゲーム、会員証のほか、決済やデータ証明など、アプリの価値を早く検証したい企業に合います。チェーン基盤の保守範囲が小さいため、必要なアプリ機能を開発会社へ見積依頼しやすい方式です。

発注書には、対応チェーン、ブリッジ、RPCの冗長化を含めます。加えて、失敗時の再送と障害時のユーザー通知も盛り込みます。

発注書に盛り込んでも、チェーン混雑時の手数料や親チェーンの更新、ブリッジ仕様、RPC障害の影響は残ります。

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

RaaSの委託範囲と費用を比べるときは、サービス内容と追加料金を分けて確認します。委託範囲は、OP Stack、Arbitrum系、ZK系などを使う前提で決まります。

• 委託範囲：デプロイ、クラウド、DAの一部、RPC、更新、監視の一部を委託します。
• 追加料金：月額とは別に、L1投稿費やDA費、Prover費が請求される場合があります。ブリッジやエクスプローラー、追加サポートも別請求のことがあります。

全ノードを自社で構築するより、早く専用チェーンを試せる点が利点です。

AWS MarketplaceのCaldera Rollups掲載情報では、1か月契約のRollup podとBlockscoutが、それぞれ月額500米ドルです（出典: AWS Marketplace「Caldera Rollups」、2026年8月確認）。

AWSの追加インフラ費も別にかかるため、この金額を本番運用の総額とみなすことはできません。

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

自社運用とフルスクラッチは、運用体制と開発範囲に分けて検討します。

• Stackの自社運用：チェーン設定から障害復旧まで自社で管理し、ベンダー依存を下げて運用要件を自社方針に合わせられます。
• 必要な人材：ブロックチェーンエンジニアやSRE、セキュリティ、運用責任者を、継続して確保する必要があります。
• フルスクラッチ：新規VMや独自証明方式、DA、ブリッジまで作る方法です。研究開発や強い差別化要件がある場合に限って検討します。
• 選定時の確認：既存の監査実績やツールを使いにくいため、既存Stackで実現できない理由を文書化できなければ、RaaSかStack利用へ戻すのが合理的です。

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

目的と責任分界を決めてからPoC、設計、本番の順に進めると、いきなり本番開発を契約するより失敗を抑えやすくなります。資産を扱う場合は、停止や再同期、出金を受入条件にします。鍵の失効や履歴復元も、受入条件に含めます。

1. 目的・KPI・対象ユーザーの設定

Rollupで解決したい課題は、手数料の低減や取引確定の迅速化、アクセス制御などに分けて整理します。自社経済圏を作る狙いがあれば、それも課題に加えます。

数値は、まず仮の値で置いておきます。月間取引数やピーク時TPSに加え、許容遅延と停止許容時間、利用地域も書き出します。資産と想定TVLも、同じように仮の値で示します。

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

2. RFPと要件一覧の作成

各社の見積条件をそろえるため、RFPには次の要件を分けて記載します。

• 基本情報：目的と対象ユーザー、業務フロー、機能・非機能要件を書きます。希望日程、予算、納品物、運用体制、提案依頼事項も入れます。
• Rollup固有の項目：OptimisticかZKか、EVM互換性を決めます。親チェーンやDA、シーケンサー運営者、ガストークンも含めます。
• 接続・運用項目：ブリッジや証明、RPC、アーカイブ、更新権限の条件です。
• 性能の測定条件：取引種別や成功率、確定の定義を揃えて示します。同時利用者数、負荷試験時間、L1投稿遅延も入れます。

要件を「必須」「できれば必要」「提案に任せる」に分けると、各社の見積条件をそろえられます。たとえば、1,000TPSという数字だけでは、測定条件が分からず比べられません。

3. 設計・開発・監査の契約の分け方

設計の段階では、アーキテクチャ図やデータフロー、鍵管理、障害時の状態遷移を確定させます。さらに、復旧手順と監査方針も固めます。

成果物には、コントラクトやノード設定、インフラコードを明記します。CI/CDや監視画面、運用手順書も書き出します。

監査は、開発会社の自己チェックだけで終わらせず、対象を分けて契約に書きます。

• 独立監査の対象：ブリッジ、入出金、メッセージングを、独立監査やバグバウンティに含めます。
• 監査の追加範囲：証明検証や権限管理、更新機構も、監査で確かめる範囲です。

監査指摘を直したあとの確認を誰が担当するかも、工程と費用に含めます。

4. テスト・段階リリース・運用移管

テストから運用移管までは、次の順に確認します。

1. テストネットでは通常機能に加え、シーケンサー停止、L1投稿失敗、RPC遅延、ノード再同期を試します。
2. 負荷試験ではTPSや失敗率、確定時間を記録します。
3. 本番は、利用者数やTVLに上限を設けたうえで、段階的に開放します。
4. 運用移管では、ソースコードだけでなく鍵や設定、ログを引き継ぎます。

テストネットでは、DA欠損、証明遅延、ブリッジ出金、管理者キー切替も対象です。負荷試験では、復旧時間と追加のクラウド費用も残します。運用移管では、バックアップや復元手順、問い合わせ履歴も対象です。

リリース後は、オンコール網と監視アラートを決めます。インシデントの重大度や一次対応時間も定めます。特に、緊急停止と再開の承認者は、あらかじめ決めておきます。

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

費用は、方式やチェーンの所有範囲、監査範囲で変わります。運用時間や想定取引量によっても上下します。

ここに載せる金額は、市場共通の固定料金ではなく、リサーチノートと公開価格をもとにした編集上の推定です。そのため、要件定義後の個別見積もりを代わりに示すものではありません。

構築パターン別の初期費用

開発範囲が広がるほど費用も期間も増えるため、方式別の目安を比べます。

• 既存L2のdApp：300万〜2,000万円で、期間は2〜6か月ほどです。
• RaaSのテストネット・PoC：100万〜1,000万円、期間は1〜3か月程度が目安です。
• RaaS本番Rollup：ブリッジや監視、運用を含めると、初期費用は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

TCOで比べるため、運用費と公開価格の範囲を整理します。

• 運用費：クラウド、ノード、RPC、インデクサー、エクスプローラー、DA、L1ガス、Prover、バックアップ、監視、セキュリティパッチ、オンコール、監査更新。
• RPCの公開例：公式RPC料金表では、Freeは月額0米ドル、Proは月額50米ドルです。
• Proの利用枠：10億CUを含み、超過分は100万CUあたり0.10米ドルです（出典: Conduit公式ドキュメント、2026年8月確認）。
• RaaSの運用費：月額利用料に加えて、クラウドやDA、監視、保守、サポートを合わせると、月50万〜500万円程度と推定されます。
• 自社運用の推定：年1,000万〜1億円超となる可能性があります。

Conduitの価格は、RPCの公開例にすぎず、Rollup全体の運用費ではありません。

実費は、取引量やSLA、ノード数で変わります。Proverの計算資源や監査頻度によっても変わるため、月額固定費と従量費を分けて見積もります。

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

RFPは、価格を尋ねるだけの文書にせず、同じ前提で提案と見積もりを受けて、各社の違いを比べるための文書です。技術の選択と運用責任は費用に直結するため、非機能要件も記載します。

事業要件と利用シナリオ

利用シナリオと負荷条件をそろえるため、RFPには次の情報を記載します。

• 事業・運用情報：サービスや利用者、取引やメッセージの流れを書きます。資産や収益モデル、対象国、保存期間、管理者権限、社内承認も含めます。
• 業務固有の要件：ゲームならゲーム内資産や体験、金融なら本人確認や取引記録、凍結、監査証跡を含めます。
• ピーク負荷：1日100万件でも、10分に集中する場合と24時間に均等に流れる場合では、必要なシーケンサーやRPC、インデクサーが変わります。
• 処理条件：取引サイズやコントラクト実行の複雑さ、同時接続数、許容する再送回数を示します。

技術・非機能要件の数値と責任者

見積もりと責任分界をそろえるため、技術と非機能の要件を項目ごとに定めます。監視は、「24時間監視」と書くだけでは足りません。

• 基盤：採用するStackやEVM互換性、親チェーンを定めます。OptimisticかZKか、DA方式、シーケンサーも含めます。
• 接続・データ：Prover・Verifierとブリッジ、RPCに加え、インデクサー、エクスプローラー、データ搬出も指定します。
• 非機能：可用性やRTO・RPO、復旧・確定時間を指定します。監視範囲、バックアップ、ログ保存、脆弱性対応、SLA対象も対象です。
• 監視対象：RPCやシーケンサー、L1へのBatch投稿を個別に指定します。DA、Prover、ブリッジ残高も対象です。

検知後の対応も、RFPで決めておきます。一次対応やエスカレーション、利用者への告知、復旧判断の責任者が含まれます。

納品物と終了時のデータ搬出

納品物と終了時の引き継ぎ条件を、次のように明記します。

• 納品物：ソースコード、コントラクトのアーティファクト、設定、インフラコードが中心です。CI/CD、鍵管理手順、監視設定も含みます。
• 記録類：テスト結果、監査報告書、運用手順書、障害対応記録。
• RaaSの所有権：チェーン契約や管理者権限、シーケンサー鍵、DAデータについて、誰が所有するかを明記します。ログやインデックス、バックアップも対象です。
• 移管条件：標準形式での出力や、期間・費用・支援範囲を決めます。秘密情報の返却・破棄、ブリッジやRPCの切替、利用者への告知も条件に入れます。

移管できないサービスは、月額が安くても事業継続のリスクが高くなります。

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

プロトコル開発元やRaaS事業者、インフラ会社、SIer、監査会社は、立場も役割も異なります。同じ基準で順位を付けるとずれが出るため、提供レイヤーと障害時の責任者を整理して、会社を組み合わせます。

会社の役割と実績

技術提供元の資料と、実装・運用会社の実績を分けて確認します。たとえば、Polygon Developer DocsのCDK案内は、提供元の資料として参考になります。

• OP Stack：OP Labs・Optimismの公式ドキュメントで、構成や更新方針を確かめます。
• Arbitrum系：Arbitrumのチェーン立ち上げ案内を踏まえ、デプロイやブリッジ、運用、障害対応の実績を見ます。
• 提供元と運用会社：Polygon CDKやAgglayerでは、両者を分けて確認します。
• 会社の証跡：稼働チェーン、障害履歴、監査報告、コード公開範囲、緊急連絡体制を提示してもらいます。

委託先の運用力は、プロトコル元の知名度ではなく、実装・運用会社の実績で確かめます。

見積比較の前提条件

見積もりは、初期費用や月額固定費、従量費に加えて、第三者費用、変更費、保守費を分けて示してもらいます。

見積もりを比べるときは、安い見積もりほど含まれていない項目を確かめ、含まれる範囲と期間の数え方をそろえます。

• 費用の範囲：L1ガス、DA、Prover、クラウド、RPCの費用が含まれるかを、同じ表で比べます。
• 付帯対応：監査やバグバウンティ、法務、SLA、夜間対応の扱いを確かめます。
• 期間の内訳：「6か月」とだけ書かれていると比べにくいため、工程ごとに分けて見ます。
• 数える工程：要件定義や設計、テストネット、監査、本番移行、運用移管に加え、発注者側のレビュー期間も含めます。

技術選択が未確定なら、調査・設計を先行発注し、その後に本番開発の見積もりを更新する方法もあります。

セキュリティと復旧力の評価

委託先の安全対策と復旧力は、次の情報で評価します。

• 脅威モデル：ブリッジの資産集中、管理者キー、マルチシグ、Timelock、シーケンサー認証、ノード間通信、Prover、DA復元性、ログ改ざん、更新手順。
• 確認基準：OWASPのSmart Contract Security Verification Standardも参考になります。
• 復旧手順：停止後の再開時間、L1コントラクト異常時の緊急停止、出金詰まり時の代替経路、DA取得不能時の復旧方法。
• 運用実績：過去のインシデントや再発防止策、残る制約を示せる会社は、長期の運用先として評価できます。

ここに挙げた項目は、要件やテスト項目を作るときのたたき台になります。

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

要件の不確実性に応じて、工程ごとに契約を分けます。設計や調査は準委任、成果物と受入条件が固まった開発は請負、運用はSLA付きの保守・運用委託が候補になります。

要件整理・PoCの準委任

独自チェーンの要否や方式、DA、シーケンサー、規制対応が未確定なら、作業時間や調査成果を基準にする準委任が適しています。

調査結果やアーキテクチャ案、比較表を成果として定めておくと、進捗を評価しやすくなります。リスク一覧やPoCコード、次工程の見積条件も、成果に含めます。

開発の成果物・受入条件・変更手続き

請負では、ソースコードやコントラクト、設定を成果物として定めます。テスト結果や監査対応、手順書も含めて、受入テストを具体化します。

TPSや確定時間、復旧時間は、測定できる数値の条件にします。出金や権限、ログ、データ復元も、同様に条件として書きます。未達だった場合の再実施や減額、延期、契約解除も、契約書で確かめます。

運用委託のSLA・鍵・データ所有

運用委託の責任範囲は、SLA、所有権、契約終了時の扱いに分けて定めます。

• SLA対象：稼働率に加えて、RPCのみを対象にするか、シーケンサーやBatch投稿、DA、Prover、ブリッジ、エクスプローラーまで含めるかを明記します。
• 障害対応：重大度、一次応答、復旧目標、報告書、再発防止、計画メンテナンスを定めます。
• 所有・権限：管理者キーやシーケンサー鍵、クラウド、DNS、ログ、バックアップ、監査資料は発注者が所有します。委託先には最小限の権限を与えます。
• 契約終了時：返却や消去証明、引き継ぎ支援、再委託先を確認します。曖昧だと、技術上は移せても事業として取り戻せないことがあります。

よくある質問（FAQ）

発注前に多い質問に、技術方式、費用、委託先、法務、運用責任の面から答えます。

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付き運用委託が向いています。

全工程を一つの契約にまとめる場合も、工程ごとの成果物と費用、責任、変更手続きを分けて記載します。

まとめ

まず、既存L2上のアプリ開発と独自Rollup構築を分けて考えます。独自チェーンが必要な場合は、RaaS、自社運用、フルスクラッチの順に、目的や自由度、運用体制、移行可能性を比べます。

発注前のRFPによる責任分界とTCOの整理

RFPには、取引量と確定時間、DA、シーケンサー、ブリッジを記載します。監視や復旧、監査、鍵、データ搬出、SLAも含めます。

見積比較では、初期費用だけでなくTCOをそろえて見ます。L1ガスやDA、RPC、Proverまで含めます。クラウドや監査、保守、インシデント対応も、同じ比較に入れます。公開価格は一部サービスの参考値で、本番の総額を示すものではありません。

小さなPoCから始める発注

完成したチェーンをすぐ発注するのではなく、事業目的と技術選択を確かめる調査やPoCから始めると安全です。

PoCの結果をもとに、発注範囲や契約形態、委託先を更新します。費用と運用体制も見直したうえで、本番Rollupか既存L2かを判断します。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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