Blog

「東大ブロックチェーン公開講座2025」第3回レポート：Web3アーキテクチャとスマートコントラクト開発を体系的に理解する

2026/2/24

技術ブログ

2. フロントエンド層：Next.js × Wagmi × Viem が現在の定番構成
　2-1. Next.js：Web2 のベストプラクティスをそのまま使える土台
　2-2. Wagmi：ウォレット接続とコントラクト操作の標準 Hooks
　2-3. Viem：軽量で型安全な RPC クライアント
　2-4. フロントエンドからチェーンまでの流れ

3. バックエンド層：Web3 を支える「見えない心臓部」
　3-1. API サーバーとしてのバックエンド
　3-2. インデックスサーバー：ブロックチェーンの “Google 検索”
　3-3. オフチェーン計算（Co-processor）
　3-4. TextDAO サンプルアプリに見るバックエンドの使い方

4. RPC & ノード層：Web3 を支える「インフラのインフラ」
　4-1. RPC Provider の役割
　4-2. フルノードを自前で持たない理由
　4-3. RPC Provider 障害と Web3 サービスへの影響
　4-4. 主要 RPC Provider の特徴

5. ブロックチェーン層：EVM・状態遷移・AO3の世界
　5-1. トランザクションと状態遷移
　5-2. 書き込み系と読み取り系の違い
　5-3. EVM の制約がアーキテクチャを決める
　5-4. DApps に向いている領域・向いていない領域

6. 開発・デプロイ・運用・法規制：プロダクトとして世に出すための最後の層
　6-1. 開発ツールチェーン：Hardhat と Foundry
　6-2. フロントエンド／バックエンドのデプロイ
　6-3. コントラクトのデプロイとコード検証
　6-4. 監視と運用
　6-5. トークン設計と法規制：暗号資産・前払式支払手段・電子記録移転権利

7. オンチェーンとオフチェーンの役割分担
・オンチェーンで担うべきこと
・オフチェーンで担うべきこと
・境界領域の設計ポイント

8. まとめ：Web3 アーキテクチャの本質

0. はじめに

こんにちは。23年卒 SD 部の C.MS です。

本記事は「東大ブロックチェーン公開講座2025」第3回レポートとして、第10〜14講義の内容を中心にまとめています。このブログシリーズは、23〜25 年卒の若手エンジニア 4 名がリレー形式で担当しており、ブロックチェーン・Web3 技術に興味がある方が、基礎を一通り学んだあとに、「全体像をしっかり整理したい」方を主な対象としています。

第1回では Bitcoin / Ethereum の基本構造、
第2回では Web3 の概念やインターネットとの関係

を取り上げました。

そして今回の第3回では、

・Web3 アプリケーションはどのようなレイヤーで構成されているのか
・スマートコントラクトと Web2 技術はどこでつながるのか
・実際の DApps 開発で、オンチェーンとオフチェーンをどう分担するべきか

といった、実務でのアーキテクチャ設計に直結する視点で講義内容を整理していきます。

記事はやや長めですが、フロントエンド / バックエンド / RPC / ノード / EVMといった複数レイヤーを横断して理解したい方にとって、役に立つ内容になっているはずです。

0-1. Web3 アーキテクチャは、なぜこんなに難しく見えるのか

「Web3 のアプリって、結局どうやって作ればいいのか分からない」
「Solidity でスマートコントラクトは書けるけれど、その先がイメージできない」
「フロントエンドやバックエンドとブロックチェーンが、どうつながっているのか曖昧だ」

2024〜2025 年の Web3 周りを見ていると、こういった声を本当によく見かけます。

一番の理由は、Web3 が「Web2 と Web3 をまたぐ技術領域」だからです。

オンチェーンだけ理解しても足りないし、Web2 だけ分かっていても全体像は見えません。実際の Web3 アプリケーションは、ざっくり次のような要素が組み合わさって動いています。

・「誰にも改ざんできないプログラム」としてのスマートコントラクト
・パスワードを使わずに署名で認証するウォレット
・チェーンとアプリをつなぐ RPC ノード
・React / Next.js などのフロントエンド技術
・検索・集計・AI・キャッシュを担うバックエンドとインデックスサーバー
・トークンや NFT を設計するときに無視できない法規制

一見するとバラバラで、しかも専門用語だらけに見えます。しかし視点を少し変えると、この全体像はきれいな「6 層構造」として整理できます。

0-2. この記事でわかること

・Web3 アプリケーション全体を 6 つのレイヤーとして整理した俯瞰図
・ウォレット／フロントエンド／バックエンド／ノード／ブロックチェーンの役割の違い
・どこまでをオンチェーンに書き、どこからをオフチェーンに任せるべきかという考え方
・実際の開発でよく使われるツールやサービス
（Next.js / Wagmi / Viem / Infura / Hardhat / Foundry / MetaContractなど）の位置づけ
・トークン設計と法規制をざっくり押さえるための視点
（暗号資産 / 前払式支払手段 / 電子記録移転権利 / 資金決済法 / 金融商品取引法 / RWA / NFT など）

0-3. Web3 アプリケーションの全体像は「6 層構造」でとらえる

本記事では、Web3 のアーキテクチャを次の 6 層 に分解して説明します。

・ユーザー層（Wallet / Account / 署名）
・フロントエンド層（React / Next.js / Wagmi / Viem）
・バックエンド層（API / Indexer / Off-chain Compute）
・RPC & ノード層（Infura / Alchemy / QuickNode など）
・ブロックチェーン層（EVM / 状態遷移 / ブロック構造）
・開発・デプロイ・運用・法規制レイヤー

上から下へ追っていくと、ユーザーの画面からブロックチェーンの内部、そして開発・運用の現場までを一気に把握できます。

1. ユーザー層：ウォレットが担う認証・操作・資産管理

Web2 の世界では、サービスの入口は ID / パスワードか、Google ログインのようなOAuthです。一方で Web3 には、いわゆる「ログインフォーム」がありません。代わりに登場するのがウォレットです。ウォレットは、次の3つの役割を同時に担っています。

1-1. ログイン（認証）

Web2 では、

ユーザーがID/パスワードを入力する
サーバーがDBに保存されたハッシュと照合する

という流れで本人確認をします。

Web3では、これが署名（Signature）に置き換わります。

DApps（フロントエンド）が「このメッセージに署名してください」とウォレットに送る
ユーザーがウォレット上で内容を確認し、署名する
アプリ側は、署名とメッセージからアドレスを復元し「確かにこのアドレスの持ち主が署名した」と確認する

このように、ログイン = 署名という考え方に変わっています。

1-2. トランザクション送信（操作）

スマートコントラクトの状態を変える操作は、すべてトランザクションとしてチェーンに送る必要があります。

送金
NFTのmint / burn
DAOでの投票
プロトコルへの預け入れ（Deposit）

これらのトランザクションを組み立て・署名し・ネットワークに流すのもウォレットの役割です。

1-3. 資産管理

ウォレットには、以下のような情報が紐づきます。

ETH やトークン残高
NFT の保有状況
スマートコントラクトのオーナー権限
ガス代の支払い元

イメージとしては、銀行口座と身分証と印鑑を一つにまとめたものに近い存在です。

1-4. 実際によく使われるウォレット

MetaMask（ブラウザ拡張型の代表格）
WalletConnect（モバイルウォレットと DApps を接続するプロトコル）
Phantom / Rabby / Rainbowなど、用途特化のウォレット

開発側から見ると、「ユーザーがどのウォレットを選んでも、アプリ側では同じように扱いたい」ので、次のフロントエンド層でその差異を吸収していきます。

2. フロントエンド層：Next.js × Wagmi × Viem が現在の定番構成

講義で示されたアーキテクチャ図でも中心に描かれていたのが、React / Next.js / Wagmi / Viem というフロントエンドの組み合わせです。ここはまさに、Web2 の経験をそのまま活かせる部分です。

2-1. Next.js：Web2 のベストプラクティスをそのまま使える土台

Next.js はReact ベースのフレームワークで、Web2 の世界でも広く使われています。

サーバーサイドレンダリング（SSR）で表示が速い
SEOに強い（検索流入を狙いやすい）
API Routesによって、簡単なバックエンドも一緒に書ける
ルーティングとコード分割が自動

Web3 のための特殊なフレームワークというより、「普通に便利だから採用されている」ものだと考えると理解しやすいです。

2-2. Wagmi：ウォレット接続とコントラクト操作の標準 Hooks

Wagmiは、Ethereum 向けのReact Hooksライブラリです。代表的なHooksだけでも、

useConnect：ウォレット接続
useAccount：現在接続しているアカウント情報
useSignMessage：任意メッセージへの署名
useContractRead / useContractWrite：コントラクトの読み書き
useFeeData：ガス価格の取得

と、DApps に必要な機能が一通り揃っています。

これを自前で実装しようとすると、「各ウォレットごとの挙動の違い」「再接続」「エラー処理」 などで簡単に沼にハマります。Wagmi を使うことで、そういった細かい部分をかなり吸収できます。

2-3. Viem：軽量で型安全な RPC クライアント

Viem は、Wagmi の裏側で動くRPCクライアントです。

TypeScriptで型安全に扱える
ethers.jsより軽量
新しい EIPやチェーンへの対応が速い
Node.js / ブラウザの両方で動作

最近は「フロントエンドではViem、バックエンドではViemかethers.js」という構成もよく見られます。

2-4. フロントエンドからチェーンまでの流れ

ここまでの要素をつなげると、ユーザー操作は次のような流れになります。

Reactコンポーネント上でユーザーがボタンを押す
WagmiのHookが呼ばれ、ウォレットに署名や送信を依頼する
ViemがRPC Providerにリクエストを送る
RPC Providerがノード経由でブロックチェーンとやり取りする

この「流れ」をイメージできるようになると、バグ調査のときに「どこで止まっているのか」を追いやすくなります。

3. バックエンド層：Web3 を支える「見えない心臓部」

ここから、オンチェーンではない「サーバー側」の話に移ります。「ブロックチェーンは分散しているから、サーバーは不要なのでは？」という誤解は根強いですが、実際にはほとんどの Web3 サービスがしっかりしたバックエンドを持っています。理由は、ブロックチェーンそのものの性質にあります。

計算性能が低い
書き込みが高コスト（Gasが必要）
検索や集計が苦手（履歴を遡る処理は重い）
外部 API を呼べない
AI や画像処理など大きな計算は不向き

これらは設計上そうなっているので、今後も根本的には変わりません。そこでWeb2技術の出番です。

ただし講義では、「バックエンドはあくまでミドルウェアであり、オンチェーンの“最終的な真実”を書き換えてはいけない」という点が強調されていました。

OK：オンチェーンのイベントを集計してダッシュボード表示
NG：サーバー側で投票結果を決めてからチェーンに書く

といった線引きが重要になります。

3-1. API サーバーとしてのバックエンド

Express / NestJS / Next.js の API Routesなどで実装されます。典型的な役割は次のとおりです。

フロントエンドからのリクエストを受け取り、RPC / DB / 外部APIをまとめて呼ぶ
返却データの整形・キャッシュ
署名の検証（メッセージと署名からアドレスを復元し、本当に本人か確認）
検索条件のチェック、権限確認
Webhookの受信（RPC Providerや外部サービスからのイベント通知）

やっていること自体は普通の Web サービスとほとんど同じですが、「オンチェーンの真実と食い違った情報を返さない」 という点だけは特に気をつける必要があります。

3-2. インデックスサーバー：ブロックチェーンの “Google 検索”

ブロックチェーンはログを持っていますが、

「あるNFTを持っているユーザーを全部出して」
「この期間の投票結果を集計して」

のようなクエリは苦手です。そこで使われるのがインデックスサーバー（Indexer）です。

The Graph（Subgraph）
・スマートコントラクトのイベントを自動で取り込み、GraphQL で検索できるようにする仕組み
自前のIndexer（PostgreSQL+バッチ処理）
・バックエンドが定期的に RPC からログを取得し、DBに保存
・必要な集計カラムやビューを用意しておく

NFT マーケットプレイス、DeFi プロトコルのダッシュボード、DAO のガバナンスページなど、ほとんどの UI はこのインデックスサーバーを前提に設計されています。

3-3. オフチェーン計算（Co-processor）

もう一歩進んだパターンとして、重い計算をオフチェーンで済ませて結果だけをオンチェーンに渡すという設計も増えています。講義ではこれを「Co-processor（コプロセッサ）」と呼んでいました。

大量データの統計処理
画像・動画の特徴抽出
ゼロ知識証明（ZK Proof）による検証用証明の生成

などをオフチェーン側で行い、その結果に対してオンチェーンで検証可能な証拠を添えることで、EVMの負荷を抑えつつトラストレス性を維持しようとするアプローチです。

3-4. TextDAO サンプルアプリに見るバックエンドの使い方

講義では、TextDAOという簡易DAOアプリが例として紹介されていました。

オンチェーン側：
・DAO のメンバー情報や投稿ルールをスマートコントラクトで管理
オフチェーン側：
・フロントエンドから送られてきたアイコン画像をpixelmatchで比較し、「似すぎていないか」をサーバーでチェック

ここで大事なのは、「どのアイコンが登録されるか」という最終決定はオンチェーンのコントラクトが担っている点です。サーバー側は「怪しいものを弾くための補助」や「画像処理」といった、オンチェーンでは重すぎる部分だけを担当しています。

このようにバックエンドは、

重い計算
検索・集計
外部APIやAIの利用

を担いつつ、「最終的な資産管理やルールの決定はチェーン側に任せる」 という線引きをするのが基本になります。

4. RPC & ノード層：Web3 を支える「インフラのインフラ」

フロントエンドとバックエンドがブロックチェーンと通信するときの入り口がRPC Providerです。

代表的なサービスとしては、

Infura
Alchemy
QuickNode
Ankr

などがあります。

4-1. RPC Provider の役割

トランザクションの受信とネットワークへのブロードキャスト
コントラクトの読み取り（eth_call）
アカウント残高の取得（eth_getBalance）
イベントログの取得（eth_getLogs）
WebSocketを使った新ブロック通知

アプリ側から見ると「HTTPS の API にリクエストを送っているだけ」に見えますが、その裏で

ノードのバージョン管理
再同期や障害対応
アーカイブノードの維持

などをすべて肩代わりしてくれています。

4-2. フルノードを自前で持たない理由

Ethereumのフルノードを自分で運用しようとすると、

ディスク容量
ネットワーク帯域
メンテナンス工数

がかなり重くなります。そのため多くのプロジェクトは、自前ノードを持たずにRPC Providerを利用しています。

4-3. RPC Provider 障害と Web3 サービスへの影響

RPC Providerが落ちると、スマートコントラクト自体は生きていてもアプリは動かなくなる場合があります。その意味で、Web3 のインフラは「ノード提供サービス」と切り離せない存在になっています。

4-4. 主要 RPC Provider の特徴

Infura：最も歴史が長く、標準的な選択肢
Alchemy：開発者向けのダッシュボードやモニタリング機能が充実
QuickNode：ゲームや NFT プロジェクトでよく利用される
Ankr：比較的安価にマルチチェーン対応

プロジェクトの規模や予算に応じて、これらを組み合わせるケースも多いです。

5. ブロックチェーン層：EVM・状態遷移・AO3の世界

ここからはオンチェーン側、つまりEthereum Virtual Machine（EVM）の話です。講義で示された図では、S0 → S1 → S2と状態が変化し、ブロックの中にトランザクションが並んでいるイメージが描かれていました。

5-1. トランザクションと状態遷移

Ethereumでは、世界の状態（State）を

S0 → S1 → S2 → …

のように、連続する状態の列としてとらえます。

各ブロックには複数のトランザクションが含まれている
ノードはそのトランザクションを順番に実行する
実行結果として新しい状態 S_{n+1}が得られ、そのハッシュがブロックヘッダーに記録される

という仕組みで、「誰がいつ何をしたか」という履歴を保証します。

ここで重要になるのが、操作順序の合意であるAO3（Agreement on Operation Order）という考え方です。

Operation：送金やコントラクト呼び出しといった「操作」
Order：それらの順番
Agreement：全ノードが同じ順番に合意すること

この 3 つが揃って初めて、世界中で同じ履歴と状態が共有されていると言えます。

5-2. 書き込み系と読み取り系の違い

スマートコントラクトの関数には、大きく分けて2 種類あります。

状態を変える関数（書き込み）
状態を読むだけの関数（読み取り）

前者は必ずトランザクションが必要で、Gas代もかかります。後者はRPC Providerに対する単なる問い合わせなので、トランザクションもGas代も不要です。

DApps の設計では、「ユーザーがボタンを押したとき、それはチェーンに書き込む操作なのか、読むだけなのか」を意識しておくと、UXの設計がしやすくなります。

5-3. EVM の制約がアーキテクチャを決める

EVMの特徴として、次のような制約があります。

計算性能が高くない（1 ブロックあたりの命令数に制限がある）
Storage書き込みのGasコストが非常に高い
外部APIを直接呼べない
真の乱数を生成できない（Oracleが必要）

このため、

ループ回数に上限を設ける
なるべくイベントログやオフチェーンストレージを活用する
重要なロジックだけをオンチェーンに絞る

といった設計上の工夫が必要になります。

5-4. DApps に向いている領域・向いていない領域

講義では、「何でもかんでもブロックチェーンでやればよいわけではない」という点を、ユースケースの四象限を使って説明していました。

オンチェーンに向いている例
・資産残高の管理
・投票結果やルールの最終決定
・NFTの所有権の記録
オフチェーンに向いている例
・画像認識・AI 推論
・レコメンドやランキングの計算
・大量ログを使った高度な分析

資産管理やルールの最終決定は、「誰が・いつ・何をしたか」を全員で共有することに価値がある領域です。一方で、AI推論やレコメンドは結果さえ正しければよく、全ノードが同じ計算を繰り返す必要はありません。こうした「DApps に向いている領域／向いていない領域」を頭に置くと、オンチェーンとオフチェーンの分担がぐっと設計しやすくなります。

6. 開発・デプロイ・運用・法規制：
プロダクトとして世に出すための最後の層

最後に、実際の開発・運用・法務まわりを簡単に整理しておきます。

6-1. 開発ツールチェーン：Hardhat と Foundry

学習やPoC段階では、とくに次の2つがよく使われます。

Hardhat

JavaScript / TypeScriptベースで学びやすい
ethers.jsとの統合がしやすい
plugin・テンプレートが豊富

Foundry

超高速なテスト実行
Solidityでテストを書ける
fuzzテストなど高度な検証がしやすい

小規模なプロジェクトや初学者向けにはHardhat、大規模で性能や検証を重視するならFoundry、という使い分けもよく見られます。講義でも、MetaContractと組み合わせたFoundryベースの開発フローが紹介されていました。

6-2. フロントエンド／バックエンドのデプロイ

フロントエンド・バックエンドのホスティングは、基本的に完全にWeb2の世界です。

フロントエンド：Vercel / Netlify / Cloudflare Pagesなど
バックエンド：AWS / GCP / Railway / Renderなど

スマートコントラクトだけがチェーン上にデプロイされ、それ以外は普通にクラウドで動く、という構成がほとんどです。

6-3. コントラクトのデプロイとコード検証

テストネット（Sepolia / Holeskyなど）で検証
L2（Arbitrum / Optimism / Baseなど）で本番運用
必要に応じてEthereum Mainnetにもデプロイ

という流れが一般的です。

デプロイ後は、EtherscanやSourcifyなどでソースコード検証を行うことで、ユーザーがコードを確認できる状態にしておくのが、今ではほぼ必須になっています。

6-4. 監視と運用

Web2と同様に、Web3でも運用フェーズは重要です。

RPC のエラー率・レイテンシ
コントラクトイベントの監視（異常な挙動がないか）
フロントエンドのレスポンス時間・エラーログ
ガス価格の急変

これらをSentry / Grafana / 各種モニタリングサービス / Tenderlyなどで追いかけます。

6-5. トークン設計と法規制：暗号資産・前払式支払手段・電子記録移転権利

GVA法律事務所による講義では、日本法の枠組みを使って、トークンを大きく次のように整理していました。

暗号資産（資金決済法）
前払式支払手段（同上）
電子記録移転権利（金融商品取引法）

さらに、Real World Asset（RWA）トークンやNFTについては、個別業法（酒税法・古物営業法・不動産特定共同事業法・景品表示法・著作権法など）が絡んでくる可能性がある、という話もありました。開発者の立場から見ると、すべての条文を覚える必要はありませんが、少なくとも次の2点は押さえておくべきです。

利益分配・投資性があるかどうか
・トークン保有者にプロジェクトの収益を分配する
・ステーキング報酬が実質的に投資商品になっている
このような設計の場合、証券性が問題となり、電子記録移転権利として金融商品取引法の対象となる可能性があります。
決済・送金手段として機能しているかどうか
・プラットフォーム内の支払いに広く使われる
・日本円などの法定通貨と安定した交換が前提になっている
このようなトークンは、暗号資産や前払式支払手段として資金決済法の対象となる可能性があります。

NFT や RWA の場合も、「実質的に何をしているのか」を軸に判断されます。

ランダム販売NFTは賭博性や景品表示法の問題
アート作品やキャラクターを扱う場合は著作権法

などが関係してきます。

重要なのは、「トークンのスマートコントラクトを実装する前に、ビジネスモデルと法的な位置付けを確認しておく」ことです。講義でも、エンジニア側が最低限のキーワード（暗号資産 / 前払式支払手段 / 電子記録移転権利 / 資金決済法 / 金融商品取引法など）を理解し、早い段階で法務とコミュニケーションを取ることの重要性が繰り返し強調されていました。

7. オンチェーンとオフチェーンの役割分担

ここまでの内容を踏まえて、オンチェーンとオフチェーンの役割分担を改めて整理しておきます。

オンチェーンで担うべきこと

資産管理（残高、所有権、ロック状態など）
ルールの最終決定（投票結果、清算条件など）
誰が・いつ・何をしたかという履歴の保存

オフチェーンで担うべきこと

データ検索（フィルタリング、ソート、ページング）
集計・分析（グラフ表示、ランキングなど）
AI・画像処理・大量データ処理
ログの保管やアーカイブ
ユーザーごとのダッシュボード生成

境界領域の設計ポイント

オンチェーンのイベントログをインデックスサーバーで加工し、フロントに渡す
オフチェーンで行った計算は、その結果をオンチェーンで検証可能な形（ZK Proofや署名付きデータ）にする
「バックエンドが勝手に結果を決める」のではなく、「オンチェーンの状態を補助的に扱う」構造を保つ

8. まとめ：Web3 アーキテクチャの本質

長くなりましたが、Web3アプリケーションを6層構造で整理すると、次のようになります。

ユーザー層：ウォレットがログインでありIDであり銀行口座
フロントエンド層：Next.js / React上でWagmi / Viemを使ってウォレットと対話する
バックエンド層：API・Indexer・Co-processorがブロックチェーンの弱点を補う（ただし最終決定はチェーン側）
RPC&ノード層：Infura / Alchemyなどが「ノードへの窓口」として動く
ブロックチェーン層：EVMとAO3が「誰にも改ざんできない世界の状態」を作る
開発・デプロイ・運用・法規制：ツールチェーンとクラウド・法律まで含めて初めてプロダクトになる

特に重要なのは、次の3点です。

オンチェーンに何を残すかを設計すること
・すべてをオンチェーンに詰め込もうとせず、「資産管理とルール最終決定」を中心に据える。
ウォレットと署名の仕組みを理解すること
・Web3のログインは ID/パスワードではなく署名。ウォレットが UX とセキュリティの要になる。
トークン設計と法規制を早い段階から意識すること
・暗号資産 / 前払式支払手段 / 電子記録移転権利の違いを理解し、技術だけで完結しない領域だと認識する。

この6層構造と考え方を頭に置きながら、講義で示された大きなアーキテクチャ図を眺めてみると、

「なぜこの箱がここにあるのか」
「どの線がオンチェーンで、どれがオフチェーンなのか」

が、以前よりはっきり見えてくるはずです。そして何より、自分でDAppsを設計するときに「どのレイヤーで何をやるか」を落ち着いて考えられるようになる。それが、この第3回レポートのいちばんのゴールです。

最後までご覧いただきありがとうございました！
これを機にCasleyDeepInnovationsにも興味を持っていただけると嬉しいです！

この記事を書いた人