オンチェーン構築はプライベート vs パブリック、どっちにする?
はじめに:「自前ブロックチェーン」、本当に必要か?
ブロックチェーンを活用したシステム開発の話になると、決まって出てくる議論があります。
「セキュリティが心配だから、自前(プライベート)でチェーンを立てたい」
「流行りのL2を構築してエコシステムを作りたい」
特に、個人情報を扱う業務や、コンプライアンスに厳しい組織では、この傾向が顕著です。日本企業は「自前主義」が根強く、海外では当たり前になっているパブリックチェーンの活用が遅れがちです。
しかしながら、エンジニア視点で「運用保守」「コスト」「データの真正性」を突き詰めると、あえてパブリックチェーン(Ethereum、Solana、SUI等)を使うという選択肢こそが、最も合理的であるケースが多いのです。
本記事では、実際に検討した「証明書・資格情報のオンチェーン化」の事例をもとに、プライベート vs パブリックの比較検討プロセスを共有します。
1. 3つの構成を徹底比較
資格証明や契約書などをオンチェーン化するにあたり、以下の3つの構成案が考えられます。
| 構成 | 概要 |
|---|---|
| ① 自前(プライベートチェーン) | Hyperledger Fabric等で社内サーバーに構築 |
| ② 独自L2構築 | OP Stack、Polygon CDK、Arbitrum Orbit等を利用 |
| ③ パブリック利用(ハイブリッド) | Ethereum、Solana、SUI等のメインネットを利用 |
比較表
機能ごとに比較表を作りました。パブリック利用の手軽さが伝わると思います。

パブリック利用の場合、画面UI/UXやビジネスロジックに注力できる。L2の場合特にブリッジ管理がセキュリティリスクが高く鬼門。
非機能の観点でも見ていきましょう。
| 項目 | ① 自前(プライベート) | ② 独自L2構築 | ③ パブリック利用 |
|---|---|---|---|
| 初期コスト | 中〜高(サーバー構築、開発費) | 高(L2基盤構築、ブリッジ開発) | 低(API連携のみ) |
| 年間運用コスト | 高(インフラ+人件費) | 高(シーケンサー運用等) | 低(従量課金) |
| 第三者証明 | ✕(自社署名のみ) | △(L1に依存) | ◎(分散ノードが検証) |
| 持続可能性 | ✕(担当者・予算消失リスク) | △(技術的負債が蓄積) | ◎(グローバルインフラが維持) |
| 相互運用性 | ✕(閉じたネットワーク) | △(L1とのブリッジのみ) | ◎(標準規格、DID/VCで発行者・受領者の認証も可能) |
| 技術的難易度 | 中(Hyperledger習得) | 高(シーケンサー、ブリッジ管理) | 低(RPC/SDK利用) |
| スケーラビリティ | 限定的(自社リソース依存) | 中(L2設計に依存) | ◎(チェーン側が処理) |
| コンプライアンス | ◎(完全自社管理) | ○(設計次第) | ◎(ハイブリッド構成で対応可) |
年間コスト試算(10万トランザクション/年)
| 構成 | 年間コスト | 内訳 |
|---|---|---|
| パブリック(Solana) | 約0.5〜1万円 | tx単価 ≈ $0.00025 × 100,000 |
| パブリック(Ethereum L2) | 約1〜5万円 | Polygon, Arbitrum等 |
| 独自L2構築・運用 | 300万円〜 | EC2/GCE + 運用工数 |
| 自前プライベート | 300万円〜 | オンプレ or クラウド + 運用工数 |
結論から言うと、年間1,000万tx超のような大規模でない限り、多くのケースで「③ パブリック利用」が合理的です。中小規模でL2や自前チェーンを構築するのは、「コンビニに行くためにプライベートジェットを買う」ような過剰投資と言えます。
2. 「自前チェーン」が陥る運用の沼
経営層は「データの主権」や「個人情報保護」を理由に自前を好みますが、エンジニアリング観点では以下のリスクがあります。
「俺が正義」のパラドックス
プライベートチェーンのノード管理者が全員「身内」である場合、それは自社が発行したデータを、自社のサーバーで『正しい』と言っているだけになります。
# プライベートチェーンの検証フロー
発行者: 自社 → 署名者: 自社 → 検証者: 自社
これはRDBMS + デジタル署名と何が違う?とも言えます。
ブロックチェーンの本質的価値である「第三者による検証」が機能しません。
サステナビリティの欠如
構築時は良くても、5年後に誰がそのノードをメンテするのでしょうか?
- Hyperledger Fabricのバージョンアップ対応
- コンセンサスノードのOS/ミドルウェア更新
- 障害時のフェイルオーバー設計・運用
予算や担当者が消えれば、システムはレガシーな遺物になります。
多くの場合、その場限りのシステムとして望まれていないと思います。
3. 「独自L2」はコストが見合わない
「流行りのL2ならどうか?」という議論もあります。
技術的なハードル
- シーケンサー運用: 単一障害点になりやすく、可用性設計が複雑
- ブリッジのセキュリティ: L1⇔L2間の資産移動は攻撃対象になりやすい
- 周辺ツール: Explorer、Indexer、Wallet対応など全て自前構築
独自L2が正当化されるケース
- トランザクション量が年間1,000万件以上
- 独自のガバナンスやトークノミクスが必要
- L1のgas代が事業コストに直結する規模
中小規模では、明らかにオーバーエンジニアリングです。
4. パブリックチェーンの選択肢
「パブリックチェーン」と一口に言っても特性は様々です。用途に応じて選定しましょう。
| チェーン | TPS | Finality | tx単価 | 特徴 |
|---|---|---|---|---|
| Ethereum | ~15 (L1) | ~15分 | $1~50 | 最大エコシステム、L2で拡張 |
| Solana | ~65,000 | ~400ms | $0.00025 | 高速・低コスト、Visa採用 |
| SUI | ~120,000 | <1s | $0.001 | Move言語、オブジェクトモデル |
| Polygon PoS | ~7,000 | ~2s | $0.01 | Ethereum互換、低コスト |
| Arbitrum | ~40,000 | ~1s | $0.01~0.1 | Ethereum L2、EVM互換 |
重要なのは、どのチェーンを選んでも「第三者による検証」という本質的メリットは享受できるという点です。
5. 「パブリックは信用できない」は過去の話
「パブリックチェーンは誰が管理しているか分からなくて怖い」という声をよく聞きます。しかし、現実では企業が大学で採用され始めています。
金融の巨人が採用
Visa × Solana
Visaは国際送金の決済手段(USDC)として、Ethereumに加えてSolanaを正式採用。2023年開始のステーブルコイン決済は、年間35億ドル以上の決済量に達しています。
PayPal × PYUSD
PayPalは独自ステーブルコイン「PYUSD」をEthereumとSolanaで発行。4億人のユーザー基盤を持つ決済大手が、パブリックチェーンを選択しています。
ITインフラの巨人がサポート
Google Cloud
Google CloudはSolanaのバリデータを運用し、BigQueryでSolanaの全データを検索可能にしています。
📎 Google Cloud Just Became a Solana Validator - Decrypt
📎 Solana goes live on Google Cloud's BigQuery - The Block
AWS
AWSはBlockchain Node Runnersで、Ethereumに続きSolanaを公式サポート。
「Google/AWSがインフラを支えているチェーン」と「自社サーバー室の自前チェーン」、5年後の持続可能性はどちらが高いでしょうか?
日本企業の動向
Sony × Soneium
SonyはEthereum L2「Soneium」を2025年1月にメインネットローンチ。OP Stackを採用し、テストネットで1,400万ユーザー、5,000万トランザクションを処理。注目すべきは、Sonyが「閉じたプライベートチェーン」ではなく「パブリックL2」を選択した点です。
千葉工業大学
日本の大学で初めて、学位証明書をNFT(SBT)として発行。Polygon上でBlockcerts規格に準拠し、W3C Verifiable Credentials(VC)と組み合わせたハイブリッド構成を採用しています。
6. 解:「ハイブリッド構成」の実装アプローチ
では、パブリックチェーンで「個人情報」をどう守るのか?ここで採用するのがハイブリッド構成です。
アーキテクチャ概要

検証フロー
# 検証者(企業の人事担当など)による検証
def verify_credential(pdf_file, on_chain_hash):
# 1. 提出されたPDFのハッシュを計算
local_hash = sha256(pdf_file)
# 2. オンチェーンのハッシュと比較
if local_hash == on_chain_hash:
# 3. 発行者の署名を検証
if verify_issuer_signature(on_chain_hash):
return "✓ 有効な証明書です"
return "✗ 改ざんの可能性があります"
メリット
- コンプライアンス遵守: 個人情報はチェーンに流れない → GDPR/個人情報保護法クリア
- 第三者証明: ハッシュ値は世界中のノードが検証 → 発行者でも改ざん不可能
- スモールスタート: RPC/SDK経由でAPI連携のみ → 初期・運用コスト極小
- 相互運用性: W3C DID/VC規格準拠で他サービス連携可能
7. 日本の「ガラパゴス化」リスク
ここで警鐘を鳴らしておきます。
日本は歴史的に「自前主義」が強く、携帯電話のガラパゴス化を経験しました。自前の選択はブロックチェーンでも同じ轍を踏む可能性があります。
「孤立」か「接続」か
世界の企業は自社システムをパブリックチェーンに「接続」しようとしています。そこ(オンチェーン)に世界中のユーザーと資産があるからです。
自前チェーンにこだわるのは、ユーザーを「イントラネット」に閉じ込めるのと同じです。パブリックチェーン採用は、ユーザーをVisa・Google・Sonyが参加するグローバル経済圏に接続することと同義です。
まとめ:まずは「公共交通機関」を使おう
エンジニアとして「独自チェーンを作る」ことは技術的に面白い挑戦ですが、実運用を考えると「パブリックチェーン」に乗るのが合理的です。
| プライベート | パブリック | |
|---|---|---|
| ネットワーク | イントラネット | インターネット |
| 交通手段 | 自家用車・専用道路 | 公共交通機関 |
| 経済圏 | 自社ポイント | 世界共通通貨 |
| 開発 | フルスクラッチ | SaaS/API利用 |
推奨アプローチ
- まずはハイブリッド構成で「ハッシュ値だけパブリックに刻む」
- トランザクション量が増えたら既存L2移行を検討
- 年間1,000万tx超で初めて独自L2を検討
独自チェーン構築は、トランザクションが爆発的に増えてからでも遅くありません。
補足:研究・ビジネスの最前線
また、「パブリックチェーンは研究対象にならない」は誤解です。むしろパブリックチェーン上で、いかにプライバシーを守りつつ実用的なアプリケーションを作るかこそが、現在もっともホットな研究テーマです。
- Zero-Knowledge Proof(ZKP): データを開示せずに検証
- Verifiable Credentials(VC): W3C標準の検証可能な資格情報
- Decentralized Identity(DID): 自己主権型アイデンティティ
これらの技術とパブリックチェーンの組み合わせが、次世代の認証・証明基盤を形作っています。
参考リンク一覧
| 企業/組織 | 内容 | URL |
|---|---|---|
| Visa | Solanaでのステーブルコイン決済 | https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.19881.html |
| PayPal | PYUSD on Solana | https://newsroom.paypal-corp.com/2024-05-29-PayPal-USD-Stablecoin-Now-Available-on-Solana-Blockchain,-Providing-Faster,-Cheaper-Transactions-for-Consumers |
| Google Cloud | Solanaバリデータ運用 | https://decrypt.co/113632/google-cloud-just-became-a-solana-validator |
| Google Cloud | BigQuery Solana統合 | https://www.theblock.co/post/258770/solana-live-on-google-cloud-bigquery |
| AWS | Solanaノードサポート | https://aws.amazon.com/blogs/web3/run-solana-nodes-on-aws/ |
| Sony | Soneiumメインネットローンチ | https://decrypt.co/300589/sony-debuts-soneium-mainnet-advancing-ethereum-layer-2-for-entertainment |
| 千葉工業大学 | NFT学位証明書発行 | https://prtimes.jp/main/html/rd/p/000000039.000042635.html |
Discussion