Skip to content
Published on

Web3 & スマートコントラクト開発 2026 — Hardhat / Foundry / Solidity / Cairo (StarkNet) / Anchor (Solana) / viem / wagmi / OpenZeppelin / Slither / Tenderly 徹底ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ —— 「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)で特に光る。

import { buildModule } from '@nomicfoundation/hardhat-ignition/modules'

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
import { Test } from "forge-std/Test.sol";
import { Counter } from "../src/Counter.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 の型とクライアントが自動生成される。

import * as anchor from '@coral-xyz/anchor'
import { Program } from '@coral-xyz/anchor'
import { MyCounter } from '../target/types/my_counter'

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 が難しい、バンドルサイズが大きい。

import { ethers } from 'ethers'

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 のあらゆるペインポイントを意識的に解く。

import { createPublicClient, http, parseEther } from 'viem'
import { mainnet } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'

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 依存を切った。

import { createConfig, http, WagmiProvider } from 'wagmi'
import { mainnet, base } from 'wagmi/chains'
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'

const config = createConfig({
  chains: [mainnet, base],
  transports: { [mainnet.id]: http(), [base.id]: http() },
})
const queryClient = new QueryClient()

function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <YourApp />
      </QueryClientProvider>
    </WagmiProvider>
  )
}

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 例
import { ConnectKitProvider, ConnectKitButton } from 'connectkit'

function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <ConnectKitProvider>
          <ConnectKitButton />
          <YourApp />
        </ConnectKitProvider>
      </QueryClientProvider>
    </WagmiProvider>
  )
}

選択基準。

  • 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;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

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 でも呼べる。

import { TenderlyConfiguration, Tenderly } from '@tenderly/sdk'

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。

import { createPublicClient, http, fallback } from 'viem'
import { mainnet } from 'viem/chains'

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 と似た位置。

import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'
import { createV1, mintV1, TokenStandard } from '@metaplex-foundation/mpl-token-metadata'

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 互換)
import { createPublicClient, http } from 'viem'
import { kaia } from 'viem/chains'

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)
import { createPublicClient, http } from 'viem'
import { astar, soneium } from 'viem/chains'

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 開発ツール

Solana / StarkNet / Stylus

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

ライブラリ・標準

セキュリティツール

モニタリング・RPC

L2

韓国・日本

あわせて読む

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

Discuss on Twitter • View on GitHub