プロローグ —— 「Web3 は死んだ」言説と 2026 年の現実

2022 年のクリプトウィンター、2023 年の FTX の残骸、2024 年の SBF 終身刑、そして 2025 年の ETF 承認後にまた起こった「今度こそ本物」サイクル —— Web3 は毎年死亡宣告され、毎年ビルダーの数は増えてきた。2026 年春、正直に言うと、二つのことが同時に真である。

ひとつ。**コンシューマー dApp 市場はまだ小さい**。NFT バブルは終わり、「DeFi サマー」のような熱狂はもう来ない。一般ユーザーからガス代を受け取るモデルは L2 でも摩擦が大きい。

ふたつ。**インフラと開発者ツールはかつてないほど良くなっている**。Foundry が初めて「Web2 並みの DX」を与え、viem と wagmi がクライアント側の痛みを大幅に削り、OpenZeppelin 5.x が ERC 標準を安全に再利用できるようにし、Slither/Mythril/Echidna/Halmos が静的解析・シンボリック実行・ファズテストを日常に落とし込んだ。RPC は Alchemy・Infura・QuickNode の競争で値段が下がった。L2 は Arbitrum・Optimism・Base が定位置に着き、zkSync・Polygon zkEVM・StarkNet の ZK 陣営も生き残った。

本稿の前提は二つ。(1) 2026 年に本気でスマートコントラクトを書こうとする人に、どのツールを選ぶべきかを正直に整理する。(2) 一陣営だけでなく、EVM・Solana・StarkNet・Stylus (Rust) の四陣営を同じ軸で比較する。

> モデルは収束していく。**インフラが差を作る**。Solidity 0.8.x はこの 5 年でほとんど変わっていないのに、Hardhat と Foundry で働く体験はまったく別物だ。

価格・機能・性能の数値は速く動く。本稿の数字はすべて 2026 年 5 月時点であり、構造的な差異に焦点を当てる。半年後に数字が変わっても意思決定フレームは有効であってほしい。

1章 · 2026 年の Web3 開発地図 —— EVM / Solana / StarkNet / Stylus

まず全体像。2026 年のスマートコントラクトは四つの VM・言語陣営に分かれる。

**陣営 1 · EVM + Solidity/Vyper.** Ethereum mainnet とその上の L2 群(Arbitrum, Optimism, Base, zkSync Era, Polygon zkEVM, Linea, Scroll など)。言語は Solidity 0.8.x が圧倒的、Vyper は少数派の代替。ツールは Hardhat または Foundry。クライアントは ethers.js v6 か viem。世界のスマコン TVL の圧倒的多数がここにある。

**陣営 2 · Solana + Rust(Anchor) / Move(Sealevel).** Anchor フレームワークが Rust の上に IDL とボイラープレートを敷き、EVM から流れてきた開発者にも親しみやすくなった。Helius が Solana 専用 RPC を育て、Metaplex が NFT/トークン標準を作った。取引コストが低く TPS が高いので、ゲーム・決済の実験が多い。

**陣営 3 · StarkNet + Cairo.** StarkWare が作った ZK フレンドリーな言語 Cairo。2026 年では Cairo 2.x が一般的で、Starknet Foundry が Foundry スタイルのワークフローを持ち込んだ。コントラクトレベルで ZK 証明を自然に扱える、ほぼ唯一のメインストリーム選択肢。

**陣営 4 · Arbitrum Stylus + Rust/C/C++.** Arbitrum が WASM ベースの仮想マシンを EVM の隣に貼り付け、Rust で書いたコントラクトが Solidity コントラクトと同じチェーン上で共存する構造を作った。2024 年ベータ、2025 年 mainnet、2026 年が本格採用期。Solidity より 10〜100 倍ガス効率が良いが、エコシステムはまだ初期。

陣営選択は通常、「どのチェーンにデプロイするか」が先に決まれば自動で従う。Ethereum mainnet か L2 → EVM/Solidity。Solana → Rust/Anchor。StarkNet → Cairo。Arbitrum で Rust が得意なら Stylus。本稿の以降の章は、各陣営の核となるツールを同じフレームで整理する。

加えて **言語が同じでもツールは違う** ことを強調しておく。Solidity は一つの言語だが、Hardhat と Foundry はまったく別の開発体験を与える。Rust は一つの言語だが、Anchor (Solana) と Stylus SDK (Arbitrum) は違うモデルを敷く。ツール選択は時に言語選択より重要だ。

2章 · Hardhat (Nomic Foundation) —— クラシックな Solidity 開発環境

Hardhat は Nomic Foundation が作った、EVM 陣営の「既存標準」。JavaScript/TypeScript の上で、コンパイル・テスト・デプロイ・デバッグを一貫して束ねる。2018 年からあり、2026 年でも最大のユーザーベースを持つ。

中核フロー。

新規プロジェクト

npx hardhat init

コンパイル

npx hardhat compile

テスト (Mocha + Chai + ethers/viem)

npx hardhat test

ローカルネットワーク (HardhatNetwork, fork 可)

npx hardhat node

デプロイ (Ignition)

npx hardhat ignition deploy ./ignition/modules/MyModule.ts

Hardhat の真の魅力は **プラグインのエコシステム**。`@nomicfoundation/hardhat-toolbox` をインストールするだけで verify, gas-reporter, coverage, typechain が一括で入る。TypeScript ファーストクラス対応、`expect(tx).to.emit(...)` のような Chai matcher、過去のブロック状態をローカルで再現する Mainnet fork、Solidity からの `console.log` —— こうしたものが Hardhat エコシステムで育った。

2026 年時点で Hardhat の大きな変化は二つ。

**Hardhat 3 (Rust 再実装).** 2025 年末からベータで公開された Hardhat 3 は、コアを Rust で書き直してビルド・テストが大幅に速くなった。Foundry に奪われた「速度」の軸を取り戻そうとする試み。同じプロジェクトで Hardhat 2 比 2〜5 倍速いコンパイル・テストが報告されている。

**Hardhat Ignition.** 命令型 deploy スクリプト(`deploy.ts` に if-else でデプロイ順序を書く)を宣言的なモジュールに置き換えた。「このコントラクトはあのコントラクトのアドレスを必要とする」を依存グラフで表現すれば、Ignition が順序を解き、失敗した地点から再開できる。マルチステップデプロイ(例: Proxy + Implementation + Initialize)で特に光る。

export default buildModule('LockModule', (m) => {

const unlockTime = m.getParameter('unlockTime', 1893456000n)

const lockedAmount = m.getParameter('lockedAmount', 1_000_000_000n)

const lock = m.contract('Lock', [unlockTime], { value: lockedAmount })

return { lock }

})

弱点も正直に。(1) Node.js/TypeScript の上で動くので CI が遅い —— 同じ Solidity コードを Foundry が 5 秒でコンパイルする間に Hardhat 2 が 30 秒かかる場合もある(Hardhat 3 で差は縮まったが、まだ Foundry には届かない)。(2) Solidity でテストを書けず TS/JS だけ —— `forge test` が Solidity で直接テストを書く点が決定的に違う。(3) ファズテストが弱い —— 標準では提供されず、プラグインを入れる必要がある。

それでも **豊富なプラグイン、TypeScript 親和、慣れた Node.js エコシステム** という武器のおかげで、特に「スマコン + フロントエンド + バックエンド」を一つのモノレポで扱うチームには依然として強い選択肢である。

3章 · Foundry (Paradigm) —— Forge / Cast / Anvil / Chisel

Foundry は Paradigm が作った、2026 年時点で事実上の「新標準」。最初から Rust で書かれていて非常に速く、**Solidity でテストを書く** という決定一つで開発体験を完全に変えた。

Foundry は四つのツールで構成される。

- **Forge** —— コンパイル・テスト・デプロイ。Hardhat の代替。

- **Cast** —— CLI からチェーンと会話するツール。`cast call`, `cast send`, `cast estimate`。ethers/viem の CLI 版だと思えばよい。

- **Anvil** —— ローカルノード/フォーカー。Hardhat Network の代替。

- **Chisel** —— Solidity REPL。一行ずつ実行するインタープリタ。

インストールは一行。

curl -L https://foundry.paradigm.xyz | bash

foundryup

最も決定的な違いは **テストが Solidity** である点。

// test/Counter.t.sol

contract CounterTest is Test {

Counter public counter;

function setUp() public {

counter = new Counter();

}

function test_Increment() public {

counter.increment();

assertEq(counter.number(), 1);

}

// ファズテスト —— forge が入力を自動生成

function testFuzz_SetNumber(uint256 x) public {

counter.setNumber(x);

assertEq(counter.number(), x);

}

}

Solidity でテストを書く利点は三つ。(1) コントラクトコードと同じ言語なのでコンテキストスイッチコストがゼロ。(2) `vm.prank(alice)` のような cheatcode で呼び出し元・時刻・ブロックを即座に切り替えられる。(3) `forge test` がすべての `testFuzz_*` 関数を自動的にファズテストとして認識 —— デフォルトで 256 回ランダム入力を実行。

そして **速度**。同じ 100 テストのプロジェクトで Hardhat が 30〜60 秒かかる作業を Forge は 2〜5 秒で終える。CI コストの大きいチームには決定的差。

Cast の例。

コントラクト関数の呼び出し

cast call 0xA0b8... "balanceOf(address)" 0xdeadbeef... --rpc-url $RPC

トランザクション送信

cast send 0xA0b8... "transfer(address,uint256)" 0x123... 1000 \

--private-key $PK --rpc-url $RPC

トランザクションのデコード

cast tx 0x4a3... --rpc-url $RPC

Anvil は Hardhat Network とほぼ互換のローカルノードで、**mainnet fork** がとても速い。`anvil --fork-url $MAINNET_RPC` で mainnet 状態をローカルに引き込んで実験できる。fork はあらゆる本気のスマコン開発の核となるワークフロー。

弱点も正直に。(1) JavaScript/TypeScript エコシステムとの統合が弱い —— フロントエンドにコントラクト型を自動エクスポートするようなものが Hardhat ほどスムーズではない。(2) プラグインエコシステムは Hardhat より狭い。(3) Solidity でテストを書く分、非 EVM ロジック(例: 外部 API 呼び出しの模倣)は書きにくい。

それでも 2026 年に新規プロジェクトを始めるなら **Foundry がデフォルト**。Hardhat は既存プロジェクトが多いか、TS エコシステムと深く結びついたチームに残る。

4章 · Solidity 0.8.x / Vyper —— 言語選択

EVM 陣営での言語選択肢は事実上二つ。Solidity と Vyper。

**Solidity 0.8.x** は 2021 年から続く安定ライン。最大の変化は 0.8.0 で導入された **チェック付き算術** —— オーバーフロー/アンダーフローが自動で revert する。それ以前の 0.7.x までは `SafeMath` ライブラリを毎回敷く必要があったが、今はデフォルトで安全。0.8.20 からは EVM バージョンを `paris`/`shanghai`/`cancun`/`prague` と明示でき、L2 ごとの互換性が扱いやすくなった。

2026 年時点の主要追加機能。

- **`unchecked { ... }`** —— 算術チェックを明示的に切るブロック。ガス節約用。

- **Custom errors** —— `error Unauthorized(address caller);` —— revert string よりガスが大幅に少ない。

- **`using ... for ...`** —— ライブラリ関数を型に attach。Solidity の confidence trick。

- **Transient storage (0.8.24+, Cancun)** —— `tstore`/`tload`。トランザクションの間だけ生きるストレージ。Reentrancy lock のようなパターンでガス節約。

- **Custom error 付き `require` (0.8.26+)** —— 以前は `revert MyError()` のみだったのが `require(cond, MyError())` も書ける。

Solidity 0.9 がいつ出るかは 2026 年 5 月時点で未定。0.8.x は 5 年目に入り、互換性を保ちながら漸進的に成長している。

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.26;

contract Vault {

error InsufficientBalance(uint256 requested, uint256 available);

mapping(address => uint256) public balances;

function withdraw(uint256 amount) external {

uint256 bal = balances[msg.sender];

if (amount > bal) revert InsufficientBalance(amount, bal);

unchecked { balances[msg.sender] = bal - amount; }

(bool ok, ) = msg.sender.call{value: amount}("");

require(ok, "send failed");

}

}

**Vyper** は Python の文法を借りた EVM 用言語。Vitalik が初期に推す雰囲気もあった。2026 年は Vyper 0.4.x が安定ライン。

Vyper の哲学は「単純で、明示的で、監査可能」。Solidity が持つ function modifier、継承、inline assembly のような「強力だが複雑な」機能を意図的に外している。Curve Finance のような大きな DeFi プロトコルが Vyper で書かれている。

Vyper 0.4 例

@external

@payable

def deposit():

self.balances[msg.sender] += msg.value

@external

def withdraw(amount: uint256):

assert self.balances[msg.sender] >= amount

self.balances[msg.sender] -= amount

send(msg.sender, amount)

いつ Vyper か。正直なところ **ほぼ使わない**。Solidity が圧倒的な第一選択肢で、Vyper は (a) Curve のような特定プロトコルとの互換性、(b) 可能な限りシンプルなコントラクトで監査面を狭めたいとき程度。新規プロジェクトを Vyper で始めるケースは稀。

5章 · Cairo (StarkNet) —— ZK フレンドリー言語

Cairo は StarkWare が作った ZK フレンドリーな言語。EVM の上に ZK 証明を載せるのではなく、最初から ZK 証明生成に最適化した仮想マシン(Cairo VM)を作り、その上の言語として設計された。**StarkNet** は Cairo VM 上で動く L2。

2026 年の Cairo は Cairo 2.x が標準。Cairo 1 と比べて Rust 風の文法(`fn`, `let`, traits, enums)になった。最初は学習曲線が急だが、Rust を知っていれば比較的馴染みやすい。

// 単純な ERC20 ライクなコントラクト

#[starknet::contract]

mod SimpleToken {

use starknet::ContractAddress;

use starknet::get_caller_address;

#[storage]

struct Storage {

balances: LegacyMap<ContractAddress, u256>,

total_supply: u256,

}

#[constructor]

fn constructor(ref self: ContractState, initial_supply: u256) {

let caller = get_caller_address();

self.balances.write(caller, initial_supply);

self.total_supply.write(initial_supply);

}

#[external(v0)]

fn transfer(ref self: ContractState, to: ContractAddress, amount: u256) {

let caller = get_caller_address();

let sender_balance = self.balances.read(caller);

assert(sender_balance >= amount, 'insufficient');

self.balances.write(caller, sender_balance - amount);

let recipient_balance = self.balances.read(to);

self.balances.write(to, recipient_balance + amount);

}

}

ツールは二つが核。

**Scarb** —— Cairo の Cargo。パッケージ管理、ビルド。`scarb build`, `scarb test`。Rust 開発者にはとても親しい。

**Starknet Foundry (snforge)** —— Foundry の Cairo 版。Solidity の Foundry が与えた DX を StarkNet に持ち込んだ。`snforge test` は速く、cheatcode も提供する。

scarb new my_starknet_project

cd my_starknet_project

scarb build

snforge test

StarkNet は 2026 年時点で他の L2 に比べて TVL が小さいが、**ZK 証明を一級市民として扱える、ほぼ唯一のメインストリーム選択肢** という点で特定のユースケース(プライバシーアプリ、ゲーム内の検証可能ランダム性、オフチェーン計算をオンチェーン証明として持ち込む)で強い。

Cairo の弱点。(1) エコシステムが EVM よりずっと小さい —— OpenZeppelin Cairo もあるが、ライブラリの厚みは違う。(2) 学習曲線が急 —— felt252 (field element) という独特の基本型、low-level cairo と Cairo 2.x の歴史の変遷など。(3) 採用市場が狭い —— Cairo を上手く書ける人は数えるほど。

いつ Cairo か。「ZK 証明による検証可能計算」がコア要件のとき、または StarkNet 生態系特化のプロトコル(例: dYdX v4 以前、AVNU、JediSwap)を構築するとき。

6章 · Anchor (Solana) —— Rust フレームワーク

Solana は Rust でコントラクト(Solana では「プログラム」と呼ぶ)を書く。ただし、生 Rust で直接 SBF (Solana BPF) プログラムを書くと、ボイラープレートが大量に出る —— アカウントのシリアライズ/デシリアライズ、権限チェック、instruction ディスパッチを全部手作業で。

**Anchor** がこの問題を解く。EVM での Hardhat や Truffle が果たした役割とほぼ同じ —— マクロでボイラープレートを隠し、IDL (Interface Definition Language) でクライアントコードを自動生成する。

use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]

pub mod my_counter {

use super::*;

pub fn initialize(ctx: Context<Initialize>) -> Result<()> {

let counter = &mut ctx.accounts.counter;

counter.count = 0;

Ok(())

}

pub fn increment(ctx: Context<Increment>) -> Result<()> {

let counter = &mut ctx.accounts.counter;

counter.count += 1;

Ok(())

}

}

#[derive(Accounts)]

pub struct Initialize<'info> {

#[account(init, payer = user, space = 8 + 8)]

pub counter: Account<'info, Counter>,

#[account(mut)]

pub user: Signer<'info>,

pub system_program: Program<'info, System>,

}

#[derive(Accounts)]

pub struct Increment<'info> {

#[account(mut)]

pub counter: Account<'info, Counter>,

}

#[account]

pub struct Counter {

pub count: u64,

}

EVM から来た人にとって Solana のコアモデルの違いは二つ。(1) **アカウントモデル** —— Solana ではすべてのデータがアカウントに存在する。コントラクトもアカウント、ユーザーもアカウント、トークン残高もアカウント。呼ぶときにどのアカウントを触るかを明示しなければならない。(2) **ステートレスなプログラム** —— コントラクトコードとデータが分かれている。一つのプログラムが多くのアカウントのデータを扱う。

Anchor ワークフロー。

新規プロジェクト

anchor init my-project

cd my-project

ビルド (Rust → SBF)

anchor build

ローカルテスト (solana-test-validator を起動)

anchor test

Devnet デプロイ

anchor deploy --provider.cluster devnet

テストは TypeScript で書く(Mocha ベース)。Anchor が IDL を生成し、IDL から TypeScript の型とクライアントが自動生成される。

describe('my-counter', () => {

const provider = anchor.AnchorProvider.env()

anchor.setProvider(provider)

const program = anchor.workspace.MyCounter as Program<MyCounter>

it('Increments', async () => {

const counter = anchor.web3.Keypair.generate()

await program.methods.initialize().accounts({ counter: counter.publicKey, user: provider.wallet.publicKey, systemProgram: anchor.web3.SystemProgram.programId }).signers([counter]).rpc()

await program.methods.increment().accounts({ counter: counter.publicKey }).rpc()

const account = await program.account.counter.fetch(counter.publicKey)

console.log('count:', account.count.toString())

})

})

Anchor の弱点。(1) マクロが多くてコンパイルエラーメッセージが曖昧。(2) Anchor バージョンと Solana CLI バージョンの互換性マトリクスが厄介 —— 0.31, 0.30, 0.29 の違いは把握しておく必要がある。(3) IDL があらゆる動的パターンを表現できるわけではない。

それでも 2026 年に Solana で本気で開発するなら **Anchor がデフォルト**。生の Solana プログラムを書くのは非常に特殊なケース(例: 極端なガス最適化)。

7章 · ethers.js v6 vs viem —— クライアントライブラリ

スマコンはチェーンにデプロイされるが、それを呼び出すコード(フロントエンド、バックエンド、ボット)は JavaScript/TypeScript で書く。クライアントライブラリがその橋渡し。

EVM 陣営で 2026 年の二強。

**ethers.js v6** —— クラシック。2017 年からあり、web3.js との大戦を生き残って事実上の標準になった。v6 は v5 の大規模リファクタリング版で 2023 年リリース。ES modules、ESM 親和、BigInt ネイティブ対応。弱点は TypeScript の型が微妙に弱い、tree-shaking が難しい、バンドルサイズが大きい。

const provider = new ethers.JsonRpcProvider('https://eth-mainnet.alchemyapi.io/v2/KEY')

const signer = new ethers.Wallet(privateKey, provider)

const contract = new ethers.Contract(address, abi, signer)

const tx = await contract.transfer(to, ethers.parseEther('1.0'))

const receipt = await tx.wait()

console.log('Block:', receipt.blockNumber)

**viem** —— wagmi を作ったチーム(wevm)が ethers.js を作り直したいという理由で 2022 年に開始。2026 年時点で 2.x が安定ライン。TypeScript ファースト(ABI 型の自動推論)、tree-shake 可能、バンドルが小さく速い、RPC 呼び出しの標準化。ethers のあらゆるペインポイントを意識的に解く。

const client = createPublicClient({ chain: mainnet, transport: http('https://eth-mainnet.alchemyapi.io/v2/KEY') })

const account = privateKeyToAccount('0x...')

// ABI 推論で transfer の引数・戻り値の型が自動的に絞られる

const hash = await client.writeContract({

account,

address: '0xA0b8...',

abi: tokenAbi,

functionName: 'transfer',

args: ['0x123...', parseEther('1.0')],

})

const receipt = await client.waitForTransactionReceipt({ hash })

viem のコアな違い。

- **abitype** —— ABI から TypeScript 型を自動推論。`functionName: 'transfer'` と書くだけで `args` が `[Address, bigint]` に絞られる。誤った引数はコンパイル時に弾かれる。

- **Tree-shaking** —— `parseEther` だけインポートすれば、それだけがバンドルに入る。バンドル小ささは Lighthouse スコアに直結。

- **関数ベース API** —— ethers はクラスベース、viem は関数ベース。コード分割が自然。

- **Action API** —— `client.readContract`, `client.writeContract`, `client.simulateContract` が一貫したインターフェース。

2026 年時点で **新規プロジェクトは viem がデフォルト**。ethers は既存コードベースが多いか v5 から v6 への移行を既に終えたチームのメンテナンスモードに残る。

**web3.js** は 2024 年に ConsenSys が sunset(公式サンセット)を宣言した。2026 年では web3.js 4.x が最後で、viem/ethers へ移行するのがコミュニティの合意。

8章 · wagmi v2 + ConnectKit / RainbowKit / Web3Modal (Reown)

上記のクライアントは「JS からチェーンを呼ぶ」レベルだが、React/Next.js のアプリを作るならその上にもう一層欲しい。ウォレット接続 UI、アカウント状態管理、キャッシュ、useEffect の抽象。

**wagmi v2** がそこに座る。wevm チーム(viem と同じチーム)が作った React フック ライブラリ。2.x からは viem の上に構築され、1.x の ethers 依存を切った。

const config = createConfig({

chains: [mainnet, base],

transports: { [mainnet.id]: http(), [base.id]: http() },

})

const queryClient = new QueryClient()

function App() {

return (

)

}

`useAccount`, `useBalance`, `useReadContract`, `useWriteContract`, `useWaitForTransactionReceipt` —— すべてが React Query の上でキャッシュ・リトライ・自動無効化。

function Balance() {

const { address } = useAccount()

const { data: balance } = useBalance({ address })

return <div>Balance: {balance?.formatted} {balance?.symbol}</div>

}

ウォレット接続 UI は wagmi 自体にはなく、三つのライブラリから選んで入れる。

**ConnectKit** —— Family.co(以前は ZORA の一部)が作ったクリーンな UI。wagmi と最も深く統合。ミニマルなデザイン、ダーク/ライト、カスタマイズ可。2026 年時点で ConnectKit 1.x。

**RainbowKit** —— Rainbow Wallet チームが作った、最も華やかな UI。トレンディな NFT/DeFi アプリの標準的なルック&フィール。虹のグラデーションがデフォルトテーマの特徴。wagmi v2 互換は RainbowKit 2.x。

**Web3Modal → Reown.** 元 WalletConnect の会社が 2024 年に Reown へ社名変更し、Web3Modal も **AppKit** にリネームされた。マルチチェーン(EVM + Solana + Bitcoin)対応が最も広い。最も「バックエンド」的 —— 600+ ウォレット対応、強力な分析。

// ConnectKit 例

function App() {

return (

)

}

選択基準。

- **ConnectKit** —— ミニマルデザイン、ダークモード良好、ロード速い。

- **RainbowKit** —— NFT/DeFi アプリ風に見せたいとき。虹トーン。

- **Reown AppKit** —— Solana も一緒に、600+ ウォレットが必要なとき。

三つとも wagmi の上で動くので underlying ロジックは同じ —— 差は UI/UX とマルチチェーン対応の幅。

9章 · OpenZeppelin Contracts 5.x —— 安全な標準実装

スマコンは一度デプロイすると修正が難しい(upgrade パターンはあるが複雑)。だから ERC20, ERC721, AccessControl, Pausable のような標準は **検証済み実装** を持ち込むのがほぼ必須。

OpenZeppelin Contracts がその役を担う。ConsenSys/OpenZeppelin Security がメンテナ。2024 年に 5.x が登場。

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.20;

contract MyToken is ERC20, Ownable {

constructor(address initialOwner) ERC20("MyToken", "MTK") Ownable(initialOwner) {

_mint(initialOwner, 1000000 * 10 ** decimals());

}

}

5.x の主な変更。

- **Custom errors 全面導入** —— `revert "string"` の代わりに `error Unauthorized();`。ガス効率 + デコード可能性。

- **AccessControl の強化** —— 権限モデルをモジュール化。`DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` のような一般的パターン。

- **`Ownable(initialOwner)`** —— コンストラクタで owner を明示。以前は `msg.sender` に自動セット。

- **`SafeERC20`** —— 互換性の悪いトークン(USDT のような non-standard return)を安全に扱う wrapper。

- **`UUPSUpgradeable`, `TransparentUpgradeableProxy`** —— アップグレードパターン。

- **`ERC2771Context`** —— meta-transaction (gasless) 対応。

インストールは npm/Hardhat/Foundry どこでも一行。

Hardhat / npm

npm install @openzeppelin/contracts

Foundry

forge install OpenZeppelin/openzeppelin-contracts

OpenZeppelin が提供しないものも押さえる。(1) ビジネスロジック —— DeFi の lending、AMM、デリバティブは自分で書く。(2) 最小ガスの追求 —— OpenZeppelin は安全性優先でガスは次。Solady (Vectorized) のようなガス最適化ライブラリが別に存在する。

Solana 陣営では **anchor-spl**(Solana Program Library の Anchor ラッパー)が同じような役割 —— SPL Token、Associated Token Account などの標準実装を提供。

10章 · セキュリティ —— Slither / Mythril / Echidna / Halmos symbolic

スマコンは一つのバグが数億ドルの損失を呼ぶ。2016 年の The DAO から 2022 年の Ronin、2023 年の Multichain まで —— あらゆる大型ハックはより良い静的解析で捉えられたものだ。2026 年のセキュリティツールチェーンは四つ。

**Slither (Trail of Bits).** 最も有名な静的解析。Python で書かれ、Solidity AST を解析して既知の脆弱性パターンを検出。Reentrancy、整数オーバーフロー、未初期化ストレージ、危険な low-level call、命名規約など 80+ の detector。

pip install slither-analyzer

slither contracts/

CI への組み込みも簡単。PR 毎に自動で動かすのが標準。

**Mythril (ConsenSys Diligence).** シンボリック実行ベース。EVM バイトコードをシンボリックに実行し、「どの入力が入れば assertion が壊れるか」を自動で探す。Slither より遅いが、より深く見る。

pip install mythril

myth analyze contracts/MyContract.sol

**Echidna (Trail of Bits).** プロパティベースのファズテスト。「この invariant は決して壊れてはならない」と宣言すると、Echidna が数千回ランダム入力を試して壊す入力を見つける。

// Echidna 例

contract VaultTest is Vault {

function echidna_balance_never_negative() public view returns (bool) {

return balances[msg.sender] >= 0; // 常に true でなければならない

}

}

echidna contracts/VaultTest.sol --contract VaultTest

**Halmos (a16z crypto).** 比較的新しい(2023 年〜)シンボリック実行ツール。コアな違いは Foundry のテストの上で直接動くこと —— `forge test` の代わりに `halmos` を呼ぶと、同じテストコードがシンボリックに実行される。

pip install halmos

halmos --contract VaultTest

**Foundry forge fuzz.** Foundry 内蔵ファザー。`testFuzz_*` 関数は自動で 256 回(デフォルト)ランダム入力で実行される。最も軽い第一防衛ライン。

function testFuzz_TransferDoesNotLoseValue(uint256 amount) public {

vm.assume(amount > 0 && amount <= token.balanceOf(alice));

uint256 before = token.balanceOf(alice) + token.balanceOf(bob);

vm.prank(alice);

token.transfer(bob, amount);

uint256 after = token.balanceOf(alice) + token.balanceOf(bob);

assertEq(before, after);

}

**Slang (Nomic Foundation).** 2024 年に Nomic が発表した Solidity コンパイラフロントエンド(Rust 製)。目標は「Slither を置き換える次世代解析インフラ」。2026 年時点ではまだベータだが、今後 Hardhat 3 と深く統合される予定。

実戦ワークフロー推奨。

1. **PR 毎に** Slither + Foundry forge fuzz。

2. **メジャーリリース毎に** Echidna + Mythril。

3. **invariant が重要なコントラクト** Halmos でシンボリック検証。

4. **mainnet デプロイ前** 外部監査(Trail of Bits、OpenZeppelin Security、ConsenSys Diligence、Code4rena のようなコンテスト)。

自動ツールは「監査の代替」にはならない。「監査に入る前に表面を狭める」。本気のプロジェクトは両方やる。

11章 · Tenderly —— モニタリング + シミュレーション + デバッグ

デプロイされたコントラクトを運用するには別のツールが必要。Etherscan は見るには良いが、トランザクションがなぜ失敗したかをデバッグするには足りない。

**Tenderly** がこの場所に座る。2018 年から EVM トランザクションデバッガとして始まり、今は総合プラットフォーム。

中核機能。

- **Transaction debugger** —— revert したトランザクションを行単位で追跡。どの require が失敗し、どの変数の値だったかをすべて表示。

- **Simulator** —— 「このトランザクションを送ったら何が起こるか」を mainnet fork 上で事前実行。ガス見積もり、ステート差分、イベント。

- **Alerts** —— コントラクトイベント、ステート変化、エラーを Slack/メール/Webhook へ通知。

- **Web3 Actions** —— トリガーベースのサーバーレス関数。特定イベントで自動的にコードを実行。

- **War Rooms** —— インシデント発生時にチームがリアルタイムで一緒にトランザクションをデバッグ。

API でも呼べる。

const tenderly = new Tenderly({ accountName: 'me', projectName: 'myproject', accessKey: process.env.TENDERLY_KEY })

const simulation = await tenderly.simulator.simulateTransaction({

transaction: { from: '0xA...', to: '0xB...', input: '0xa9059cbb...', value: '0', gas: 100000, gasPrice: '0' },

blockNumber: 'latest',

})

console.log(simulation)

dApp のフロントエンドで「トランザクションを送る前に事前シミュレーション」というパターンはとても一般的。ユーザーがガスを払って失敗するのを防ぐ。

代替。**Phalcon (BlockSec)** —— デバッグ/モニタリングで似た領域。**OpenZeppelin Defender** —— もう少し運用・自動化寄り。**Forta** —— オンチェーン脅威検知。

2026 年時点で総合パッケージとしては Tenderly が一番強い。無料枠が広く、サイドプロジェクトはタダで足り、本番は月 50〜500 ドルの帯。

12章 · Alchemy / Infura / QuickNode / Helius —— RPC プロバイダ

スマコンと話すには誰かがノードを動かしてくれる必要がある。自前でノードを立てるのは高く面倒だ —— Ethereum mainnet ノード一つの同期に SSD 2TB と数日。だから RPC プロバイダ市場は大きい。

**Alchemy.** 米国 SF 本社。2026 年時点で市場シェア 1 位に近い。EVM 全般(Ethereum, Polygon, Arbitrum, Optimism, Base, zkSync, Polygon zkEVM, Starknet, Linea, Scroll)+ Solana。Notify (イベント webhook)、NFT API、Enhanced API (データインデックス)。無料枠は月 3 億 compute unit。

**Infura.** ConsenSys 所有。最も古い RPC プロバイダの一つ。MetaMask がデフォルトで Infura を呼ぶ —— だから依存性が事実上の標準。EVM 全般 + IPFS ゲートウェイ。無料枠は日 10 万リクエスト。一度ダウンした件(「Infura が落ちたら web3 が落ちる」批判)があり、マルチ RPC パターンが推奨される。

**QuickNode.** マイアミ本社。30+ チェーン対応、EVM 以外にも Solana、Cosmos、Polkadot。Marketplace に多様なアドオン。価格は使用量ベース。

**Helius.** Solana 専用 RPC。Solana はトランザクション処理が EVM と大きく違う(並列実行、lamports、slot など)ので、Solana 特化プロバイダの意味がある。Helius が Solana RPC シェアで最大。Webhook、DAS (Digital Asset Standard) API、enhanced parsing。

**Public RPC.** 無料公開 RPC もある —— eth.llamarpc.com、cloudflare-eth.com、rpc.ankr.com/eth。サイドプロジェクトには十分だが、本番では SLA なしで rate limit がきつく推奨しない。

選び方。

- **EVM 中心 + フルスタック** Alchemy。

- **MetaMask 互換・シンプルさ** Infura。

- **複数チェーン同時に** QuickNode。

- **Solana 本気で** Helius。

- **サイドプロジェクト** 無料枠どれでも。

**マルチ RPC パターン** —— 本番では必ず二つ以上のプロバイダを置いて fallback。viem の `fallback` transport、ethers の `FallbackProvider`。

const client = createPublicClient({

chain: mainnet,

transport: fallback([http('https://eth-mainnet.g.alchemy.com/v2/KEY1'), http('https://mainnet.infura.io/v3/KEY2')]),

})

一つのプロバイダがダウンしても自動で次にロールオーバー。

13章 · L2 —— Arbitrum / Optimism / Base / zkSync / Polygon zkEVM / StarkNet

Ethereum mainnet は高くて遅い。だから L2 がある。2026 年のメインストリーム L2 を六つ整理。

**Arbitrum.** Offchain Labs が運営。Optimistic Rollup。L2 中 TVL 1 位 —— 2026 年基準でおよそ 300〜500 億ドルの範囲。EVM 同等(mainnet の Solidity コードがほぼそのまま動く)。Stylus が横に貼り付いて Rust コントラクトも可能。

**Optimism.** OP Labs が運営。Optimistic Rollup。2 位。Superchain ビジョン —— OP Stack を基盤とするネットワーク連合。Base、Worldchain、Mode などが OP Stack 上で動く。

**Base.** Coinbase が運営。OP Stack の上に構築。2023 年ローンチ、2026 年にはユーザー数で最大級の L2。Coinbase ユーザー 8000 万人に直接露出するのが強み。Onchain Summer のようなマーケティングで dApp 集客を積極的に。

**zkSync Era.** Matter Labs が運営。ZK ロールアップ。EVM 互換(完全同等ではないがほぼ)。独自コンパイラ(zksolc)。ガスが安く、確定性 (finality) が速い。

**Polygon zkEVM.** Polygon が運営。ZK ロールアップで EVM 同等度がとても高い。Polygon 生態系(Polygon PoS、CDK、Miden)の一部。

**StarkNet.** StarkWare が運営。Validity ロールアップ。Cairo 言語を使用。EVM 非互換 —— 別の生態系。

選び方。

- **TVL・エコシステムの厚み** Arbitrum。

- **OP Stack・Superchain** Optimism / Base / OP Stack 派生チェーン。

- **Coinbase ユーザー露出** Base。

- **EVM 互換 ZK** zkSync Era / Polygon zkEVM。

- **ZK を一級扱い** StarkNet。

ガス代はすべて mainnet 比で 10〜100 倍安い。ガス vs 確定性 vs エコシステムの trade-off が選択基準。

**Linea** (ConsenSys)、**Scroll**、**Mantle** (BitDAO)、**Mode** (OP Stack)、**Blast** (yield-native) のような小規模 L2 もある —— それぞれの特化領域があり、「どこにデプロイするか」はユーザーがどこにいるかに依る。

14章 · Arbitrum Stylus —— Rust スマートコントラクト (EVM と同じチェーン)

2025 年に Stylus が mainnet に乗ったことは、2026 年時点で本格採用期に入った最大の変化の一つ。

中核アイデア。**EVM と同じ Arbitrum チェーンで WASM ベースのコントラクトも動く**。つまり Rust で書いたコントラクトが Solidity コントラクトと同じチェーン上で共存し、互いに呼び合える。

// Stylus コントラクト例

extern crate alloc;

use stylus_sdk::{prelude::*, alloy_primitives::U256};

#[storage]

#[entrypoint]

pub struct Counter {

count: StorageU256,

}

#[public]

impl Counter {

pub fn count(&self) -> U256 {

self.count.get()

}

pub fn increment(&mut self) {

let v = self.count.get();

self.count.set(v + U256::from(1));

}

}

デプロイフロー。

cargo install --force cargo-stylus

cargo stylus new my_counter

cd my_counter

cargo stylus check

cargo stylus deploy --private-key $PK --endpoint $RPC

利点。

- **ガス効率** —— WASM が EVM よりずっと効率的で、数学が重いコントラクトは 10〜100 倍ガスを節約。

- **Rust 生態系** —— 既存の Rust crate (BLS、ZK ライブラリ、大整数ライブラリ)が使える。

- **C/C++ も** —— 理論上、WASM にコンパイルできるなら何でも。

欠点。

- **Solidity 生態系と断絶** —— OpenZeppelin Contracts のようなものを Stylus 用に書き直す必要。

- **監査プール** —— Solidity 監査は慣れたものだが、Stylus 監査は新しい領域。

- **Arbitrum 限定** —— 他の L2 への移植が難しい。

いつ Stylus か。「数学が重いコントラクト(ZK verifier、オンチェーン ML 推論、大規模数値計算)」で。一般的な DeFi/NFT は Solidity がまだ標準。

15章 · Metaplex —— Solana NFT 標準

Solana NFT は OpenSea が一時的に対応してすぐ撤退したが、Magic Eden を中心に自己市場が生きている。標準は **Metaplex** が定める。

Metaplex Foundation は Solana 上の NFT/トークン標準を作る非営利。主な標準二つ。

**Token Metadata Program.** Solana の SPL Token の上にメタデータ(名前、シンボル、URI、ロイヤリティ)を載せる標準プログラム。NFT は本質的に supply=1 の SPL Token + Token Metadata。

**Token Extensions (Token-2022).** SPL Token の次バージョン。transfer hook、confidential transfer、interest-bearing などの拡張機能。NFT でも活用。

ツールは二段構え。

**Sugar CLI** —— キャンディマシン (Candy Machine、Metaplex の NFT ミントインフラ)を CLI で扱う。コレクションのアップロード、ホワイトリスト、価格設定。

sugar create-config

sugar upload

sugar deploy

sugar mint

**Umi (Universal Metaplex Interface).** JavaScript/TypeScript から Metaplex プログラムを呼ぶ SDK。wagmi と似た位置。

const umi = createUmi('https://api.devnet.solana.com')

const mint = generateSigner(umi)

await createV1(umi, {

mint,

authority: umi.identity,

name: 'My NFT',

uri: 'https://arweave.net/...',

sellerFeeBasisPoints: percentAmount(5.5),

tokenStandard: TokenStandard.NonFungible,

}).sendAndConfirm(umi)

NFT 市場が 2026 年に小さくなったのは事実だが、「オンチェーン資産を表現する標準」としての価値は生きている。Solana ゲーム、メンバーシップ、RWA (Real World Assets) で Metaplex 標準が引き続き使われる。

16章 · 韓国 —— カカオ クレイトン → PIO Network 統合、Lambda256

韓国 Web3 は 2018〜2021 年の ICO・NFT バブルで大きなモメンタムがあり、その後 KYC 強化・トラベルルール・LUNA 事件で冷え、2024〜2026 年の ETF 時代に再整備される流れ。

**クレイトン → PIO Network.** カカオが作った EVM L1 クレイトンは 2024 年に Finschia (LINE のチェーン) と合併して **PIO Network** (または Kaia) に統合された。カカオ + LINE の合算ユーザーが日本・東南アジア・韓国に大きなポテンシャル。2026 年時点で PIO/Kaia 上の dApp 生態系が再形成中。KaiaScan (Etherscan 互換)、Klaytn SDK は Kaia SDK へ。

// Kaia 呼び出し (viem 互換)

const client = createPublicClient({

chain: kaia,

transport: http('https://public-en.node.kaia.io'),

})

**Dunamu と Lambda256.** Dunamu (Upbit の運営会社) のブロックチェーン子会社が Lambda256。Luniverse という BaaS プラットフォームを運営し、2026 年時点では企業用トークン発行・NFT・STO (Security Token Offering) インフラを提供する。

**韓国 STO.** 2026 年時点で証券型トークン(Security Token)制度が段階的に導入されており、機関発行市場が形成されつつある。Dunamu・Pingo・新韓・NH などが STO インフラを準備中。

**韓国 dApp.** OpenSea Korea、クリップ(カカオ)、MetaMask + Kaikas、Upbit NFT(現在は整理済)、韓国のゲーム会社(WemadeのWemix、Com2uSのXPLA、NetmarbleのMBX) —— ゲームチェーンが韓国 Web3 の大きな軸。P2E 規制のため主にグローバル市場向け。

Lambda256・Klip・Kaia Wallet の KYC・トラベルルール体制が 2024 年から非常に強化され、韓国ユーザーが dApp を使うのに摩擦がある。グローバル dApp を作る際は韓国ユーザー向けのガイド/代替フローを別に置くのが一般的。

17章 · 日本 —— Astar Network (渡辺創太), Oasys

日本は韓国と同様 2018〜2021 年のバブル後に整備期を経たが、政府の Web3 政策が韓国よりフレンドリーという違いがある。岸田政権の「Web3 ホワイトペーパー」、自民党 Web3 PT (プロジェクトチーム)、デジタル庁の NFT ガイドライン。

**Astar Network.** 渡辺創太が作った Polkadot パラチェーン。2026 年時点で日本最大級の Web3 プロジェクト。ASTR トークン。EVM と Wasm 両方をサポート。Soneium (Sony Block Solutions Labs + Astar) という L2 も 2024 年にローンチ。

// Astar/Soneium (EVM)

const client = createPublicClient({ chain: astar, transport: http() })

**Oasys.** ゲーミング特化チェーン。2022 年ローンチ。バリデータが日本のゲーム会社(バンダイナムコ、スクウェア・エニックス、セガ、コナミ、グリー、double jump.tokyo など)で構成される点が特徴。ゲーム dApp のガスをゼロに(verse-layer 構造)。

**JPYC.** 日本円ステーブルコイン。2021 年から発行。2026 年時点で日本国内の決済・送金で一部使用。

**韓国との違い.** 日本は (1) 政府が Web3 を産業として育てる意志が強い、(2) ライン・ソニー・バンダイなどの大企業が直接参加、(3) 税制が段階的に合理化(以前は未実現益にも課税する厳しい条件があったが改善)。だから日本のビルダーには PIO Network よりも Astar/Soneium/Oasys が大きな選択肢になる。

18章 · 誰が何を選ぶべきか —— DeFi / NFT / L2 / ZK 意思決定ツリー

最後に、短く正直な意思決定ツリー。

**Q1. どのチェーンにデプロイするか？**

- Ethereum mainnet または EVM L2 (Arbitrum, Optimism, Base, zkSync Era, Polygon zkEVM, Linea, Scroll) → EVM/Solidity → 2章へ。

- Solana → Anchor/Rust → 6章へ。

- StarkNet → Cairo → 5章へ。

- Arbitrum + 数学の重いコントラクト → Stylus/Rust → 14章へ。

**Q2. EVM で Hardhat? Foundry?**

- 新規プロジェクト → **Foundry**。速くて、Solidity でテスト。

- 既存プロジェクトまたは大きなモノレポ(フロント・バック・コントラクト) → **Hardhat (3)**。TS 生態系と滑らか。

- 両方入れて併用するチームも多い。Forge でテストして Hardhat Ignition でデプロイ。

**Q3. JS クライアントは ethers? viem?**

- 新規プロジェクト → **viem**。TypeScript ファースト、小さく速い。

- 既存コードが ethers v6 → 維持。移行コストをかける必要はない。

- **web3.js は新規で書かない**。サンセット済み。

**Q4. wagmi に何の UI?**

- ミニマルで速く → **ConnectKit**。

- デザイン華やかに → **RainbowKit**。

- Solana + EVM 一緒に、600+ ウォレット → **Reown AppKit**。

**Q5. セキュリティツールはどこまで?**

- サイドプロジェクト → Slither + Foundry forge fuzz。

- 本気のプロトコル → 上記 + Echidna + Mythril + Halmos。

- mainnet の大口資金 → 上記 + 外部監査 1〜2 回 + Code4rena のようなコンテスト。

**Q6. RPC はどこから?**

- EVM → **Alchemy** または **Infura**。マルチ RPC fallback 必須。

- Solana → **Helius**。

**Q7. NFT をやるなら?**

- EVM → OpenZeppelin ERC721/ERC1155 + Magic Eden/OpenSea。

- Solana → Metaplex + Magic Eden。

- 「NFT 市場が死んだ」は正しいが、NFT 標準は依然として使われる —— メンバーシップ、RWA、ゲームで生きている。

**Q8. 韓国・日本市場を狙うか?**

- 韓国 → グローバルな EVM/L2 でビルドし、韓国ユーザー向けガイドを別に。PIO Network はカカオユーザー露出が必要なときに。

- 日本 → Astar/Soneium/Oasys のほうが日本市場に近い。政府もフレンドリー。

19章 · 参考 / References (Web3 は変動が激しい)

> **注意** —— Web3 プロジェクトは速く pivot するか終了する。下記のリンクは 2026 年 5 月時点のもので、特に小さな L2 や SDK は名前が変わったり消えたりすることがある。常に一次情報を確認すること。

EVM 開発ツール

- Hardhat — https://hardhat.org/

- Hardhat Ignition — https://hardhat.org/ignition/

- Foundry — https://book.getfoundry.sh/

- Foundry GitHub — https://github.com/foundry-rs/foundry

- Solidity — https://soliditylang.org/

- Vyper — https://docs.vyperlang.org/

- Slang (Nomic) — https://nomicfoundation.github.io/slang/

Solana / StarkNet / Stylus

- Anchor — https://www.anchor-lang.com/

- Solana docs — https://solana.com/docs

- Cairo — https://www.cairo-lang.org/

- Starknet — https://www.starknet.io/

- Starknet Foundry — https://foundry-rs.github.io/starknet-foundry/

- Arbitrum Stylus — https://arbitrum.io/stylus

- Stylus SDK — https://docs.arbitrum.io/stylus/

クライアント / フロントエンド

- ethers.js — https://docs.ethers.org/v6/

- viem — https://viem.sh/

- wagmi — https://wagmi.sh/

- abitype — https://abitype.dev/

- ConnectKit — https://docs.family.co/connectkit

- RainbowKit — https://www.rainbowkit.com/

- Reown AppKit — https://docs.reown.com/appkit/overview

ライブラリ・標準

- OpenZeppelin Contracts — https://docs.openzeppelin.com/contracts/5.x/

- Solady — https://github.com/Vectorized/solady

- Solana Program Library — https://spl.solana.com/

- Metaplex — https://developers.metaplex.com/

セキュリティツール

- Slither — https://github.com/crytic/slither

- Mythril — https://github.com/Consensys/mythril

- Echidna — https://github.com/crytic/echidna

- Halmos — https://github.com/a16z/halmos

- Foundry fuzz docs — https://book.getfoundry.sh/forge/fuzz-testing

モニタリング・RPC

- Tenderly — https://tenderly.co/

- OpenZeppelin Defender — https://www.openzeppelin.com/defender

- Alchemy — https://www.alchemy.com/

- Infura — https://www.infura.io/

- QuickNode — https://www.quicknode.com/

- Helius — https://www.helius.dev/

L2

- Arbitrum — https://arbitrum.io/

- Optimism — https://www.optimism.io/

- Base — https://base.org/

- zkSync — https://zksync.io/

- Polygon zkEVM — https://polygon.technology/polygon-zkevm

- Linea — https://linea.build/

- Scroll — https://scroll.io/

韓国・日本

- PIO Network (旧 Kaia/Klaytn) — https://www.kaia.io/

- Lambda256 — https://lambda256.io/

- Astar Network — https://astar.network/

- Soneium — https://soneium.org/

- Oasys — https://www.oasys.games/

- JPYC — https://jpyc.jp/

あわせて読む

- Awesome Solidity — https://github.com/bkrem/awesome-solidity

- Awesome Foundry — https://github.com/crisgarner/awesome-foundry

- L2BEAT (データ) — https://l2beat.com/

- DefiLlama — https://defillama.com/

スマートコントラクトは一行のコードが数億ドルを動かす。ツールがその責任に見合うかどうかが、すなわち安全性そのものになる。Hardhat か Foundry、Solidity か Cairo か Rust、viem か ethers、どの RPC、どの L2 —— これらの決定が集まってプロトコルの運命を作る。2026 年のインフラはかつてないほど良い。そのツールを正直に知って、賢く選ぼう。