Web3・ブロックチェーン開発の外注判断基準｜法規制と技術選定で稟議書を書く指針

「Web3 で何かできないか」と経営層から言われて企画を進めているものの、ブロックチェーン開発を発注した経験のあるメンバーが社内に一人もいない。付き合いのある SIer に相談しても「ブロックチェーンは専門外」と言われる。ネットで検索しても「おすすめの開発会社◯選」ばかりで、そもそも自社が外注してよいのか、法規制で事業が止まらないか、どのチェーンを選べばよいのかという肝心の判断軸が出てきません。

Web3・ブロックチェーン開発の外注が難しいのは、判断すべき軸が「発注先の技術力」だけではないからです。法規制の解釈が固まっていない領域が多く、実装ミスがメインネット上で不可逆になる技術特性を持ち、秘密鍵管理という新しい運用リスクを伴います。既存の Web システム開発の物差しをそのまま持ち込むと、稟議書に書くべき論点そのものを見落とすリスクがあります。

とくに 2025 年 6 月に成立し、2026 年 6 月に施行予定の改正資金決済法により、暗号資産を扱う事業の規制枠組みは大きく変わります。事業構想の段階で「そもそもこのビジネスは仲介業に該当するのか」を確認せずに開発だけ先行させると、後戻りできない設計判断を後から覆すことになりかねません。

本記事では、Web3・ブロックチェーン開発の外注判断を、法規制・技術選定・外注先評価・費用相場・契約設計の 5 軸で整理します。会社紹介ではなく、発注者自身が「外注する / 内製する / 見送る」を切り分けるフレームと、稟議書に書き起こせる粒度の判断根拠を提示することを目指します。

読み終えたときに、役員会に提出する稟議書へ「なぜ外注するのか」「なぜこのチェーンを選ぶのか」「なぜこの契約形態か」「どのようなリスクをどう管理するか」を、自分の言葉で書ける状態を目標にしてください。

Web3・ブロックチェーン開発の外注が「普通のシステム開発」とは違う理由

Web3・ブロックチェーン開発の外注を検討する際、最初に押さえておくべきなのは「これまでの Web システム開発と同じ判断軸では足りない」という前提です。既存の外注ノウハウで対応できる部分と、Web3 特有の論点を新たに追加する必要がある部分を切り分けることで、稟議書の構成が見えてきます。

ここでは、発注者が最初に直面する 4 つの構造的な違いを整理します。「なぜ普通の外注と扱いを変える必要があるのか」を、社内の意思決定者に説明するための骨子として使ってください。

法規制が事業の可否を左右する（NFT・トークン・ステーブルコイン）

一般的な Web システム開発では、個人情報保護法や特定商取引法など、既にビジネス側で理解が進んでいる法制度への対応が中心になります。一方 Web3 領域では、発行するトークンや NFT の性質次第で、資金決済法・金融商品取引法の登録業務に該当し得るという構造上の差があります。

たとえば、NFT を発行してユーザーに販売する事業でも、そのトークンが「決済手段等の経済的機能」を持つと判断されれば暗号資産に該当し、暗号資産交換業の登録が必要となる可能性があります（NFT に関連する法規制と私法的な法律関係（PwC Japan））。二次流通のロイヤリティ設計、収益分配の仕組み、ステーブルコインの扱いなど、事業の構想段階で法規制のスクリーニングを行わなければ、開発が完了してもサービスを開始できないという事態が起こり得ます。

普通のシステム開発なら「まず作ってみて後で法務チェックをかける」が成立するのに対し、Web3 では「事業構想の段階で法務レビューを終わらせないと、そもそも設計に入れない」という順番の違いを意識してください。

実装ミスが不可逆になる技術特性（メインネット・スマートコントラクト）

ブロックチェーンの本番環境（メインネット）にデプロイされたスマートコントラクトは、原則として書き換えができません。プロキシパターンやアップグレード機構を組み込んでおけば部分的な修正は可能ですが、その仕組みも設計時に決めておく必要があります。

トランザクションもまた原則として取り消せません。誤送金や仕様バグによって資金が意図しないアドレスに移動した場合、通常のデータベース更新のようにロールバックすることはできず、修復にはコミュニティ合意や別途のリカバリスキームが必要になります。

これは既存の Web システムでは「本番リリース後にホットフィックスで修正」が成立していた発想を根本から変える要求です。テスト工程の重み付け、リリース判定の厳格さ、監査体制の要否など、開発プロセス全体の設計を見直す必要があります。

秘密鍵管理という「エンジニアリング + オペレーション」の新領域

ブロックチェーン上で資産を動かすには秘密鍵が必要です。この秘密鍵の管理は、単なる情報セキュリティの問題ではなく、事業運営の根幹に関わるオペレーション設計になります。

秘密鍵を紛失すれば資産にアクセスできなくなり、盗まれれば即座に資金を持ち去られます。物理的な HSM（Hardware Security Module）による保管、複数人による署名を必須とする多重署名（マルチシグ）、鍵の分割管理（シャミアの秘密分散）など、選択肢は複数ありますが、いずれも運用オペレーションの設計まで含めて意思決定が必要です。

「外注先に鍵管理も任せる」のか、「発注者側で鍵を保管する体制を組む」のかは、契約設計と運用体制の両面に影響します。この論点は既存の Web システム開発の受発注では議論されず、Web3 プロジェクト固有の設計事項になります。

既存の Web 開発ベンダーとスキルセットが重ならない

ブロックチェーン開発で必要となるスキルは、既存の Web 開発とは重なりが限定的です。Solidity（Ethereum 系）や Rust（Solana 系）といったスマートコントラクト言語、EVM の実行モデル、ガス最適化、フロントエンドと Web3 ウォレットの連携、オンチェーンとオフチェーンのデータ設計など、専門性の高い領域が並びます。

そのため、既存の付き合いのある Web 開発ベンダーが「対応できます」と回答しても、実際にメインネットで運用実績のあるプロジェクトを持っているかは別問題です。ヒアリングの最初の段階で、「Solidity での本番デプロイ経験」「スマートコントラクト監査を受けたプロジェクト数」「メインネットでのインシデント対応履歴」を確認することで、実務経験の有無を切り分けられます。

Web3・ブロックチェーン開発を「外注する / 内製する / 見送る」の判断フレーム

Web3・ブロックチェーン開発の外注を検討する際、いきなり「どの会社に頼むか」から入ると、そもそも外注してよいのかという上位の意思決定を飛ばしてしまいます。稟議書に「なぜ外注するのか」を書けない状態で発注に進むと、途中で経営判断がひっくり返るリスクがあります。

このセクションでは、「外注する / 内製する / 段階的に内製化する / 見送る」の 4 択を、意思決定可能な軸で切り分けるフレームを提示します。絶対的な正解を出すためではなく、社内議論の起点として使ってください。

事業のコア度と社内スキルの 2 軸で切り分ける

判断の軸として最もシンプルに機能するのが、以下の 2 軸です。

• 縦軸: 事業のコア度（このプロダクトが自社の中長期の競争優位に直結するか）
• 横軸: 社内スキルの有無（現時点でブロックチェーン開発の実務経験者がいるか）

この 2 軸の 4 象限に、以下のような対応が対応します。

事業のコアではないが試したい PoC は全面外注で始めるのが合理的です。一方、将来のコア機能となる可能性がある場合は、初期は外注に頼るとしても、並行して社内で運用・保守できる体制を作ることを見据えた発注設計が必要になります。

PoC・プロトタイプ段階での外注が合理的な理由

新規事業として Web3 を検討する段階では、そもそもビジネスとして成立するかの検証が最優先課題です。この検証段階で内製にこだわると、以下のような機会損失が発生します。

• 検証結果が出るまでの時間が長期化する
• 内製メンバーの採用・教育に投資したが、検証結果が芳しくなく撤退となった場合、投資が回収できない
• 内製メンバーの学習曲線を待つ間に、市場環境が変化するリスクがある

PoC 段階では「外注してでも早く仮説検証を終わらせる」ことが、次のフェーズの意思決定に必要な情報を早く得るために合理的な選択です。ここで得た知見をもとに、次の段階で内製化を進めるかを判断してください。

本番運用を見据えたときの「段階的内製化」の設計

PoC・プロトタイプで事業性が確認できた後、本番運用に進む場合、そのままフルアウトソースを続けるとリスクが積み上がります。スマートコントラクトの改修判断、インシデント対応、コミュニティとの対話などが外注先依存になると、事業の意思決定スピードが落ちるためです。

段階的内製化の設計では、以下のような役割分担を検討します。

• 外注先が担う領域: スマートコントラクト実装、監査、初期のインフラ構築
• 自社が担う領域: プロダクト仕様策定、コミュニティ運営、鍵管理オペレーション、監視・アラート運用
• 移行期の設計: 外注先の技術者と自社エンジニアの共同作業期間を確保し、知識移転を計画的に進める

「いつまでにどの領域を内製に取り込むか」を発注時点でロードマップに書き込むことで、稟議書に「なぜ段階的内製化を選ぶのか」の論拠を書けます。

「今は見送る」を選ぶべきシグナル

すべての Web3 企画が「今すぐ着手すべき」ものではありません。以下のシグナルが複数当てはまる場合、意思決定として「今期は見送り、次年度に再検討」を選ぶ選択肢を残しておくのが合理的です。

• 事業構想が資金決済法・金商法のグレーゾーンに深く踏み込んでおり、法解釈の確定を待たないと事業リスクを取れない
• 投資回収期間の想定が 5 年以上と長く、その間の規制変更リスクを吸収できない
• 検証段階でも 1,000 万円を超える投資が必要で、失敗時の撤退コストが受け入れられない
• 自社の主力事業との関連性が薄く、社内の推進体制が組めない

「見送る」は失敗ではなく、投資判断として正当な選択です。稟議書には「なぜ見送るのか」「どのような状況になれば再検討するのか」を明記することで、意思決定の再現性が担保されます。

法規制の判断軸｜資金決済法・金商法・NFTのグレーゾーンを事前に潰す

Web3・ブロックチェーン開発の外注判断で最も見落とされやすいのが、法規制の事前スクリーニングです。外注先の技術力ではなく、事業構想そのものが規制に触れて実現できないケースがあり、開発着手前にここを潰しておく必要があります。

このセクションでは、発注者が押さえるべき法規制を 3 領域に分けて整理します。法務レビューを外注先とは別に立てるべきかどうかの判断基準にも触れます。

資金決済法の 2025 年改正で何が変わったか

2025 年 6 月 6 日に改正資金決済法が成立、6 月 13 日に公布され、2026 年 6 月に施行される予定です（令和8年6月施行！改正資金決済法の概要と実務対応（BUSINESS LAWYERS））。この改正には、Web3 事業の設計に影響する 3 つの重要ポイントがあります。

1. 電子決済手段・暗号資産サービス仲介業の創設

「媒介のみ」を業として行う場合を対象とした新たな仲介業として、「電子決済手段・暗号資産サービス仲介業」が創設されました。従来、暗号資産を扱う事業は暗号資産交換業の登録が必要でしたが、今後は「媒介のみ」なら仲介業として参入できます。仲介業者には利用者への説明義務や広告規制など一定の行為規制が課される一方、利用者の資産を預からないため、暗号資産交換業者等と比べて財務規制は限定的とされています（金融庁、暗号資産・ステーブルコイン仲介業制度を施行（ビットタイムズ））。

自社が構想している事業モデルが「媒介に留まるか」「資産を預かる交換業に該当するか」で必要な登録が変わります。この切り分けを設計段階で行う必要があります。

2. ステーブルコイン関連の改正

信託型ステーブルコイン（特定信託受益権）の定義が改正され、一定の条件のもと、要求払預貯金以外の方法で信託財産の管理・運用をすることが認められます。ステーブルコインを事業に組み込む場合、この改正で発行モデルの選択肢が広がる可能性があります。

3. 資産の国内保有命令

暗号資産交換業者および電子決済手段等取引業者に対する、資産の国内保有命令に関する規定が追加されました。海外拠点との資産管理を前提とする事業設計は再検討が必要です。

これらの改正は 2026 年 6 月の施行を控えており、今から企画する事業は改正後の枠組みでの適法性を前提に設計する必要があります。競合の記事の多くは改正前の状態で書かれているため、外注先候補が改正内容を踏まえた提案をできるかは選定時の重要な観点になります。

トークンの証券該当性（金融商品取引法との境界）

事業で発行するトークンが金融商品取引法上の「有価証券」に該当する場合、金融商品取引業の登録が必要となり、事業モデルの根本的な見直しを迫られます。

金融庁の考え方では、トークンが以下の 3 要件を満たす場合、集団投資スキーム持分に該当し、電子記録移転権利として有価証券とみなされる可能性があります（NFT に関連する法規制と私法的な法律関係(PwC Japan)）。

• 投資者から金銭等の出資・拠出を受ける
• 出資・拠出された金銭を用いて事業を実施する
• 当該事業から生じる収益等を出資者に分配する

たとえば、「トークン保有者に事業収益の一部を分配する」という設計は、この 3 要件に該当し得るため、有価証券として扱われる可能性を検討すべきです。二次流通のロイヤリティを設計する際も、それが「収益分配」に該当するかを慎重に確認する必要があります。

構想段階で「収益の一部を保有者に還元する仕組み」がある場合、法務の事前確認なしに開発着手すべきではありません。

NFT の分類基準と二次流通の扱い

NFT については、金融規制上の位置付けが個別のトークンの機能によって変わります。日本暗号資産ビジネス協会（JCBA）のガイドラインなどでは、NFT の分類基準として「決済手段等の経済的機能を有するか」が主要な判断軸として整理されています（NFT ビジネスに関するガイドライン（JCBA））。

一般的なアート NFT やトレーディングカード型の NFT は、通常は商品購入や役務提供の代金として使用することが考えにくいため、「決済手段等の経済的機能」を有さず、暗号資産には該当しないと解される場合が多いとされています。

一方、以下のような特徴を持つ NFT は、暗号資産または有価証券に該当する可能性が高まります。

• 発行者が二次流通市場で買い取りを行うことを表明している
• 保有者に対して発行事業の収益を分配する仕組みがある
• 商品券的な機能を持ち、加盟店等で決済手段として使える設計

二次流通のロイヤリティ設計は、NFT を扱う事業でとくに慎重な検討が必要な領域です。ロイヤリティの受取先、料率設定、それを保有者に分配するか否かなど、設計次第で法規制上の扱いが変わります。

発注前に法務レビューを外注先と分離すべきケース

原則として、法務レビューは外注先の技術者に任せず、Web3 領域の法務経験のある弁護士に事業構想の段階で依頼することを推奨します。以下のいずれかに該当する場合、独立した法務レビューは必須と考えてよいでしょう。

• トークン保有者に何らかの経済的利益（収益分配・ロイヤリティ・優待）を提供する設計がある
• ステーブルコインや決済機能を組み込む
• 二次流通市場を運営者として提供する
• 海外ユーザー向けにサービスを展開する（複数国の規制対応が必要）
• 資金決済法・金商法の登録業務に該当する可能性がある

法務費用は事業規模により幅がありますが、着手金 50〜200 万円程度、継続的な顧問契約で月額 10〜30 万円程度が一般的な水準です。開発費用のうちに法務費用を予算計上せず、後から法務対応で予算超過するケースをよく耳にしますので、稟議書には法務予算を独立項目として明記することをおすすめします。

技術選定の判断軸｜チェーン・言語・アーキテクチャの選び分け

外注先から「Ethereum で作ります」「Solana を使います」と提案されたとき、それが自社の事業要件に対して妥当な選定なのかを判断する物差しがないと、稟議書に「なぜこのチェーンを選ぶのか」を書けません。

このセクションでは、チェーン・言語・アーキテクチャの選定を判断するための軸を整理します。技術的な深掘りは外注先に任せる前提で、発注者が「選定の妥当性を問える」レベルの理解を目指します。

パブリック / プライベート / コンソーシアムの選び方

まず選定すべきなのは、ブロックチェーンの種類です。以下の 3 種類が主要な選択肢になります。

パブリックチェーン（Ethereum・Solana・Polygon 等）

• 誰でも参加でき、透明性が高い
• 手数料（ガス代）が発生し、スループットは種類によるが概して限定的
• グローバルなエコシステムと連携できる
• 向いている用途: NFT、DeFi、パブリックな取引記録

プライベートチェーン（Hyperledger Fabric、自社構築 EVM 互換チェーン等）

• 参加者を限定でき、内部データの秘匿性を保てる
• 手数料は自社でコントロール可能
• ノードの運用コストを自社が負担する
• 向いている用途: 社内システム、限定的な取引参加者間の記録管理

コンソーシアムチェーン（複数企業で運営、Hyperledger Fabric や Corda など）

• 複数の企業がノードを運営し、相互に信頼できる関係を構築
• パブリックの透明性とプライベートの制御性の中間
• ガバナンスと参加者の合意形成の設計が難しい
• 向いている用途: 業界横断のサプライチェーン、貿易取引記録

事業の性質（誰と誰の間の取引記録か・データを公開するか・トランザクション頻度・コスト感）から、この 3 種類のどれが妥当かを判断できるようになると、外注先の提案を評価できます。

主要パブリックチェーンの比較軸

パブリックチェーンを選ぶ場合、主要な選択肢の特徴を軸で整理しておくと、外注先の提案の妥当性を評価できます。

「まず Ethereum」と提案された場合、以下の質問で妥当性を確認できます。

• 想定するトランザクション頻度・件数に対して手数料は許容できるか
• ユーザーが Ethereum のガス代を負担する UX で問題ないか
• Layer 2（Polygon、Arbitrum、Optimism 等）を選ばない理由は何か
• 事業のグローバル展開想定はあるか、あるならエコシステムの厚さは重要か

外注先の技術者は自分たちの経験値のあるチェーンを提案しがちです。その選定が「発注者の実績経験」由来か、「事業要件との適合性」由来かを問うことが、発注者側の役割です。

スマートコントラクト言語とセキュリティ監査の関係

スマートコントラクトの実装言語は、選ぶチェーンによって決まります。

• Solidity: Ethereum・Polygon・BNB Chain・Avalanche 等の EVM 互換チェーン全般
• Rust: Solana、Near、Aptos、Sui 等
• Move: Aptos、Sui（Facebook（当時）の Libra プロジェクト由来）

言語自体の選択は外注先が担当する領域ですが、発注者として重要なのは「監査体制」です。スマートコントラクトはデプロイ後の修正が困難なため、デプロイ前にコード監査を第三者に依頼することが業界標準です。

監査を実施する主要企業には、CertiK、OpenZeppelin、Trail of Bits、Quantstamp などがあり、日本国内でも Blocksec Japan、LayerX などが監査サービスを提供しています。監査費用は、コード量・監査範囲・扱う資産価値により大きく変動しますが、標準的な MVP 規模のプロジェクトでは 100〜500 万円がひとつの目安になります。DeFi プロトコルなど扱う資産価値（TVL）が大きい案件では、複数社での重複監査やフォーマル検証を含めた投資が必要になり、監査費用の合計が 1,000 万円を超えるケースもあります。

外注先が「監査は不要」「社内でチェックする」と説明する場合、その姿勢自体がリスクシグナルになります。メインネット公開前の第三者監査は、Web3 プロジェクトの標準的な品質保証プロセスとして位置付けるべきです。

オフチェーン処理との組み合わせ設計

すべてのデータをオンチェーンに載せると、コストと性能の両面で成立しない設計になります。実際の Web3 サービスでは、オンチェーンとオフチェーンを組み合わせたアーキテクチャが標準です。

• オンチェーン: 資産の所有権、取引の記録、透明性が必要な情報
• オフチェーン: ユーザープロファイル、大容量ファイル、頻繁に更新される情報

たとえば NFT の画像データはオンチェーンには格納せず、IPFS などの分散ストレージや通常のクラウドストレージに置くのが一般的です。トークンのメタデータの一部だけをオンチェーンに載せる設計が採られます。

発注者としては、外注先に「どのデータをオンチェーンに載せ、どのデータをオフチェーンに置くのか」の設計方針を説明してもらい、その設計が事業要件と整合しているかを確認してください。

外注先を評価するチェックリスト｜実績・技術・監査体制・保守

外注先の技術力を評価する物差しがないまま相見積を取ると、「実績多数」「経験豊富」といった曖昧な自己申告に判断が引っ張られます。ここでは、外注先候補の提案書・面談で確認すべき具体的な質問項目をチェックリスト形式で整理します。

相見積時に各社を横並びで評価する共通の物差しとして活用してください。

メインネット実績を確認する具体的な質問

「ブロックチェーン開発の実績あり」という表現の実態は、テストネット止まりのプロトタイプから、複数年運用されているメインネットプロジェクトまで大きな幅があります。以下の質問で実態を切り分けられます。

• メインネットにデプロイしたプロジェクトの件数・稼働年数を教えてください
• 各プロジェクトが扱った累積取引額・ユーザー数を示してください（NDA の範囲内で）
• リード開発者としての関与か、下請けとしての関与かを明示してください
• プロジェクトのコミット履歴が公開されているリポジトリを示してください（可能な範囲で）
• プロジェクト終了後の保守運用も担当したか、また担当している場合の運用期間を教えてください

「◯件の実績」という数字ではなく、「どの深さで関わったか」「本番運用まで責任を持ったか」を確認することで、実態と提案書の差を埋められます。

スマートコントラクト監査体制の確認項目

デプロイ前の監査体制は、プロジェクトのリスク管理を評価する上で最も重要な観点の一つです。

• 過去のプロジェクトで第三者監査を受けた実績は何件あるか
• どの監査会社を利用したか、それぞれの監査費用の目安は
• 監査で指摘された重大脆弱性の対応履歴を教えてください
• 社内での事前レビュー体制（コードレビュー・シニアエンジニアによるチェック・自動解析ツールの活用）はどうなっているか
• 監査後にコードを修正した場合、再監査を依頼する運用になっているか

「監査は発注者の判断」と回答する外注先もありますが、業界標準として外注先自身が監査プロセスを推奨・案内できるかは、プロフェッショナリズムの重要な指標です。

秘密鍵管理・インシデント対応の確認項目

秘密鍵管理は、開発フェーズだけでなく本番運用の設計にも直結します。以下の観点で外注先の姿勢を確認してください。

• 開発段階でテストネット用の秘密鍵をどう管理しているか
• 本番デプロイ時の秘密鍵は発注者に譲渡するのか、外注先が管理するのか、その責任分界はどう設計するか
• 多重署名（マルチシグ）の運用を推奨するか、その理由は
• 過去のプロジェクトでインシデント（脆弱性発覚・鍵漏洩・不正取引）が発生した経験はあるか、発生時の対応はどうしたか
• 24 時間対応の緊急連絡体制はあるか、SLA としてどう定義しているか

インシデント対応の質問に対して「起きたことがない」と回答する場合、経験値が低い可能性があります。「起きたときにどう動くか」を具体的に説明できるかを重視してください。

継続保守の体制と契約範囲

Web3 プロジェクトは、デプロイ後もチェーンのアップグレード対応、ライブラリのアップデート、モニタリング体制の維持など、継続的な保守が必要です。

• 保守契約の標準スコープを教えてください（監視・アップグレード対応・障害対応など）
• チェーンのハードフォーク・仕様変更への追従は保守契約に含まれるか
• 利用ライブラリの脆弱性対応（例: OpenZeppelin のアップデート追従）は保守契約に含まれるか
• 月額保守費用の目安と、追加開発が発生した場合の請求モデルを教えてください
• 保守エンジニアの体制（専任か兼任か、ローテーションはあるか）を教えてください

「保守は別途相談」と回答する外注先が多いですが、この段階で保守設計の考え方を示せない外注先は、本番運用フェーズでの伴走能力に不安が残ります。

費用相場と段階別アプローチ｜PoCからフルスケールまでの投資判断

Web3・ブロックチェーン開発の費用は、段階（PoC・プロトタイプ・本番 MVP・フルスケール）によって桁が変わります。各段階の目的と契約形態を切り分けて設計することで、リスクを段階的に絞りながら投資判断を進められます。

以下に示す費用レンジは、ブロックチェーン開発の費用相場（netsujo） をはじめとする複数の公開情報を参照しつつ、発注者の意思決定単位に合わせて本記事で段階を分解した目安です。個別プロジェクトの見積は、要件範囲・監査要否・扱う資産価値・チェーン選定により大きく変動しますので、あくまで社内議論の起点として活用してください。なお本記事では「発注前の構想・要件定義」フェーズ（一般に 50〜200 万円程度）は法務レビュー費用と合わせて別枠で扱い、以下は外注開発が実際に走り始める PoC 以降の費用を段階別に示しています。

PoC 段階（200〜500 万円）の目的と契約形態

PoC の目的は「そもそも技術的に実現可能か」「事業として成立し得る手応えがあるか」を確認することです。この段階では、細部の作り込みではなく検証仮説を早期に確認することが優先されます。

• 期間: 1〜3 ヶ月
• 成果物: 技術検証レポート・簡易プロトタイプ（テストネット上）
• 契約形態: 準委任契約が適合。要件が固まりきっておらず、検証を進めながら仮説を修正する動きが必要なため
• 意思決定ゲート: PoC の結果を受けて、プロトタイプ段階に進むか見送るかを判断

準委任契約を選ぶことで、外注先の稼働時間の範囲内で試行錯誤ができます。請負契約にすると、成果物の定義を検証開始前に固定しなければならず、検証の柔軟性を損ないます。

プロトタイプ段階（500〜1,500 万円）の技術的意思決定

プロトタイプ段階では、PoC で確認できた仮説をもとに、実際のユーザーにテストできる形の試作品を作ります。この段階で、本番運用に向けた技術選定の骨格を固めます。

• 期間: 3〜6 ヶ月
• 成果物: 動作するプロトタイプ（テストネット上、または限定ユーザー向けのメインネット）
• 契約形態: 準委任 + 部分的な請負（機能単位で切り出せる部分は請負）
• 意思決定ゲート: プロトタイプでのユーザー反応・技術的な検証結果を受けて、本番 MVP に進むか判断

この段階で選定するチェーン・言語・アーキテクチャは、後の本番運用まで影響します。「なぜこの選定か」を稟議書に書ける論拠を、外注先とともに整理しておくことが重要です。

本番 MVP 段階（1,500〜3,000 万円）の運用体制構築

本番 MVP はメインネット上で実際にユーザーに提供する最小限のプロダクトです。この段階から、技術面だけでなく運用体制の構築も並行して必要になります。

• 期間: 6〜12 ヶ月
• 成果物: メインネット上で稼働する MVP・監査済みのスマートコントラクト・監視ダッシュボード・運用手順書
• 契約形態: 請負契約（スマートコントラクトの実装部分）+ 準委任契約（監査対応・運用体制構築）を組み合わせる
• 意思決定ゲート: MVP のユーザー獲得状況・トランザクション実績を受けて、フルスケール段階に進むか判断

この段階で必ず組み込むべき投資項目は以下です。

• 監査費用: 100〜500 万円（標準規模の MVP。DeFi など高リスク領域では 1,000 万円を超える場合あり）
• 法務レビュー費用: 50〜200 万円（改正資金決済法対応を含む）
• インフラ費用: 月額 20〜100 万円（ノード運用・監視・ログ保管）
• オペレーション体制構築: 内製化を並行進行する場合、人件費として別途計上

「開発費だけ」を稟議書に書くと、後から監査・法務・インフラで予算超過するのが典型的な失敗パターンです。稟議段階で総額を分解して計上してください。

フルスケール段階（3,000 万円〜）の内製化との併走

フルスケール段階では、事業として本格的な運用と機能拡張が続きます。この段階で外注のみに依存する構造を続けると、事業意思決定のスピードが落ち、保守費用が積み上がる構造になります。

• 期間: 継続的
• 成果物: 機能拡張・パフォーマンス改善・新チェーン対応など、ロードマップに沿った継続開発
• 契約形態: 内製チームと外注先の共同開発体制が現実的
• 意思決定ゲート: 半期・年次ごとの事業レビューで、内製比率と外注比率のバランスを見直す

フルスケール段階では、内製メンバーの採用・教育コストが年間 2,000〜5,000 万円程度発生し得ます。この投資に見合う事業性が確認できていることが、フルスケール移行の前提条件です。トークンや DEX を扱う大規模プロトコル、独自のプライベートチェーン基盤を構築するケースでは、初期投資だけで数千万円〜1 億円規模に達することもあり得ます（参考: ブロックチェーン開発の費用相場（netsujo））。

契約設計と失敗回避｜請負・準委任・秘密鍵管理・不可逆リスク

Web3 開発の外注では、既存の業務委託契約の知識だけでは対応できない差分があります。ここでは、稟議書の「契約形態と責任分界」章に書ける粒度で、Web3 特有の契約設計論点を整理します。

法務部との議論の起点として、以下の 4 つの論点を押さえておきましょう。

請負と準委任の使い分け（工程ごとの選択）

Web3 開発では、工程によって適合する契約形態が異なります。全工程を単一の契約形態でまとめると、途中の柔軟性を損なうか、成果物の定義が曖昧になるリスクがあります。

工程ごとに個別契約を締結する方式を採る場合、契約書の作成・管理コストが増えるため、包括契約に個別発注書を組み合わせる方式が実務的に運用しやすい構成です。

秘密鍵の受け渡しと責任分界

秘密鍵の管理は、契約設計における最重要論点の一つです。以下の観点で、責任分界を明確に契約書に書き込む必要があります。

• 開発中の秘密鍵（テストネット用）は誰が管理するか、紛失時の責任はどうなるか
• 本番デプロイ時の秘密鍵は発注者が生成するか、外注先が生成するか
• 生成後の秘密鍵はどのように発注者に引き渡すか（物理受け渡し・暗号化通信・信頼できる仲介者経由）
• 引き渡し後の秘密鍵漏洩は、発注者と外注先のどちらの責任か
• 多重署名を採用する場合、各署名者は誰か、意思決定プロセスはどう設計するか

推奨される設計としては、本番用の秘密鍵は発注者が自社で生成し、外注先には運用に必要な範囲でのみ権限を持つ副次的な鍵を渡す構成です。この設計を契約書と手順書の両方に明記することで、責任分界が明確になります。

メインネットデプロイの検収基準

スマートコントラクトは、メインネットデプロイ後の修正が困難なため、通常の Web システム開発以上に検収基準を厳格にする必要があります。契約書に明記すべき検収項目としては、以下が挙げられます。

• 第三者監査の完了と、指摘事項の対応完了（監査レポートを検収資料に含める）
• テストネット上での運用試験の実施結果（トランザクション件数・障害発生の有無）
• セキュリティテスト（フォーマルベリフィケーション・ファジングなど）の実施結果
• ドキュメント整備（アーキテクチャ図・運用手順書・インシデント対応手順）
• 鍵管理の引き継ぎ完了（秘密鍵の受領・多重署名の設定完了）

「動作するかどうか」の検収では、Web3 プロジェクトの品質保証としては不十分です。運用フェーズを見据えた検収基準を契約前に発注者・外注先で合意しておくことが重要です。

スマコン脆弱性の責任範囲と保険

スマートコントラクトに脆弱性が発覚し、資金が流出した場合の責任範囲は、契約書に明示的に書き込まないと解釈で揉めるリスクがあります。

• 開発期間中の脆弱性（デプロイ前に発覚）: 外注先の責任で修正
• 監査で指摘された脆弱性: 監査費用の範囲内で対応
• 本番運用開始後の脆弱性（デプロイ後の発覚）: 発注者・外注先の責任範囲を契約書で切り分ける
• 既知の脆弱性を悪用した攻撃: 保守契約の範囲でパッチ対応
• 未知の脆弱性を悪用した攻撃: 免責範囲を契約書で明確化

スマートコントラクトの脆弱性による損害は、時に数億円規模になることがあります。この損害を全額外注先に賠償させる契約は現実的ではなく、多くの場合、賠償上限を契約金額の範囲内などに設定する交渉が行われます。

近年では、スマートコントラクトの脆弱性を対象とするサイバー保険も登場しています。保険金額・保険料は契約内容によりますが、リスク移転の選択肢として保険活用も検討する価値があります。

稟議書に落とす｜Web3・ブロックチェーン開発 外注判断チェックリスト

ここまでの内容を、稟議書に落とし込むためのチェックリストとして整理します。役員会での説明や、外注先候補との相見積比較の物差しとして、そのまま利用できる形で提示します。

稟議書に書くべき 7 つの意思決定項目

役員会に提出する稟議書には、以下の 7 項目を明記することを推奨します。

1. 事業構想の法規制チェック

   • 資金決済法・金融商品取引法の該当性判断結果
   • 独立した法務レビューの実施状況
   • 2026 年 6 月施行予定の改正資金決済法への対応方針

2. 外注 / 内製 / 見送りの判断

   • 事業のコア度と社内スキルによる象限判断
   • 選択した理由（PoC 段階か本格運用か・投資回収期間・撤退可能性）

3. 技術選定の判断根拠

   • チェーン選定（パブリック/プライベート/コンソーシアム）の理由
   • 主要チェーンの中でその選択肢を選ぶ理由
   • オンチェーン/オフチェーンの分割設計

4. 外注先候補の評価スコア

   • メインネット実績・監査体制・秘密鍵管理・保守体制の 4 軸で相見積を比較
   • 選定理由を明文化

5. 段階別の投資判断ゲート

   • PoC → プロトタイプ → 本番 MVP → フルスケールの段階ごとの投資額
   • 各段階の意思決定ゲートと撤退条件

6. 契約形態と責任分界

   • 工程ごとの請負/準委任の切り分け
   • 秘密鍵管理の責任分界
   • スマートコントラクト脆弱性の責任範囲

7. 保守運用体制

   • 保守契約のスコープ・費用・SLA
   • 内製化ロードマップ（段階的内製化を選ぶ場合）
   • インシデント対応体制

これらを稟議書に書き切ることで、「なぜ外注するのか」「なぜこの選定か」「どのようなリスクをどう管理するか」に対する答えを、意思決定者に対して過不足なく提示できます。

相見積時の横並び比較表テンプレート

複数の外注先候補から相見積を取る際、以下の観点を横並びで比較すると、判断が組み立てやすくなります。

この表を埋める作業を通じて、「何を答えられない外注先か」も可視化されます。回答できない項目が多い候補は、経験の実態を再確認する材料になります。

最初の 3 ヶ月で何をするかのアクションプラン

Web3・ブロックチェーン開発の外注検討を始めてから最初の 3 ヶ月で取り組むべきアクションを、時系列で整理します。

1 ヶ月目: 事業構想の法規制スクリーニング

• Web3 領域の法務経験のある弁護士に事業構想の法務レビューを依頼
• 資金決済法・金商法の該当性を確認
• 2026 年 6 月施行予定の改正資金決済法への対応方針を法務と協議
• 事業構想として「進める / 見直す / 見送る」の一次判断

2 ヶ月目: 技術選定と外注先候補のリストアップ

• チェーン選定の一次判断（パブリック/プライベート/コンソーシアム）
• 外注先候補を 3〜5 社リストアップ
• 各社にヒアリング（メインネット実績・監査体制・保守体制）
• PoC 段階の見積を各社から取得

3 ヶ月目: 相見積の比較と PoC 契約締結

• 相見積を横並び比較（本記事のテンプレート活用）
• 稟議書のドラフト作成（7 項目を網羅）
• 役員会での説明・承認
• 選定した外注先と PoC 契約を締結・キックオフ

この 3 ヶ月間で、事業構想の妥当性判断・技術選定の方向性・外注先の選定・投資判断が組み立てられます。ここから先の PoC・プロトタイプ・本番 MVP のフェーズは、各段階の意思決定ゲートでの再判断を通じて、段階的にリスクを絞り込みながら進めていくことになります。

Web3・ブロックチェーン開発の外注は、「何から手をつければよいか分からない」から始まる企画が多いですが、判断すべき軸を分解して 1 つずつ確認していくことで、稟議書に書ける論拠が組み立てられます。本記事のチェックリストを、社内議論の起点として活用してください。