Solidity入門｜開発環境の選び方・基本構文・Sepoliaデプロイまで【2026年版】

Solidityの日本語記事は、TruffleとGanacheで環境を作りRopstenにデプロイする手順のまま止まっているものが多く、そのとおりに進めても最初の一歩で詰まります。3つとも、もう動きません。この記事では、コンパイラv0.8.36（2026年7月9日リリース）を前提に、いま動く開発環境の選び方、読める最小限の基本構文、SepoliaテストネットへのERC-20デプロイ、初心者が踏む脆弱性までを一本の線でつなぎます。

まとめ：2026年にSolidityを始めるための結論

• 言語の現在地：安定版はv0.8.36。開発は2025年以降Argot Collective（GitHubの argotorg/solidity）が担い、旧 ethereum/solidity はここへリダイレクトされる。0.8系のためオーバーフローは既定でチェックされる。
• 開発環境：まずブラウザのRemixで書いて動かす。本格開発はFoundry（v1.7.1）かHardhat 3（3.9.1）の二択で、TruffleとGanacheは選択肢から外す（どちらもアーカイブ済み）。
• テストネット：アプリ開発の既定はSepolia。ethereum.orgが「アプリケーション開発の推奨デフォルト」と明記している。Ropsten・Goerli・Holeskyはいずれも役目を終えている。
• 最初に書くもの：自作のトークンをゼロから書かず、OpenZeppelin Contracts（v5.6.1）を継承する。ERC-20は数十行で終わる。
• 詰まりやすい点：v0.8.36の既定EVMバージョンは osaka。Sepoliaやメインネットはそのままでよいが、追随していないL2や自前チェーンへ出すなら evm_version を明示して落とす必要がある。

Solidityとは：EVM上で動く契約を書くための静的型付け言語

Solidityは、Ethereum Virtual Machine（EVM）で実行されるスマートコントラクトを記述する言語です。書いたコードはコンパイルでバイトコードになり、トランザクションとしてブロックチェーンへ載ります。以後そのコードは特定のアドレスに紐づき、誰でも呼び出せる一方、書き換えはできません。文法はJavaScriptに似た見た目ですが、実体は静的型付けで、クラスに相当する contract が状態変数と関数を抱える構造をとります。

Webアプリとの決定的な違いは、実行のたびにガス代という実費がかかること、そしてデプロイ後の修正が原則できないことです。この2点が、後述する「短く書く」「先に検証する」という作法のすべての理由になっています。

2026年時点のバージョンと開発体制

最新安定版はv0.8.36で、2026年7月9日にリリースされました。押さえておくべき変更は、コンパイラの開発主体が移ったことです。ソースは argotorg/solidity に移管され、従来の ethereum/solidity というURLは現在このリポジトリへ転送されます。日本語の解説記事で参照先が古いままのものが多いため、公式の一次情報を追う際はリダイレクト先を確認してください。

言語仕様として重要なのは、0.8.0以降は算術演算のオーバーフロー・アンダーフローが自動的にrevertされる点です。2020年以前の記事が必ず勧めていたSafeMathライブラリは、もう要りません。

Solidityで実際に作られているもの

用途はトークン規格（ERC-20、NFTのERC-721）、分散型取引所などのDeFi、DAOの投票ロジック、NFTの発行・売買といったところに集中しています。共通点は「金銭的価値の移転ルールを、運営者にも変更させたくない」という要件です。逆に、頻繁な仕様変更が前提の業務ロジックや、大量データの保存には向きません。オンチェーンのストレージは極端に高価で、画像などの実体はIPFSのような外部ストレージに置き、コントラクトにはハッシュだけを載せるのが定石です（ブロックチェーン(Ethereum)と分散ファイルシステム(IPFS)の技術的背景と動画配信の課題で構成例を解説しています）。

スマートコントラクトの定義と、従来のDBとの線引き

スマートコントラクトは、あらかじめ定めた条件が満たされたときに自動で実行される、ブロックチェーン上のプログラムです。仲介者が処理を止めたり、記録を後から書き換えたりできない点が特徴で、この改ざん耐性と引き換えに、処理速度と保存コストを大きく犠牲にしています。「ブロックチェーンで置き換えられるか」を判断する段階なら、まずブロックチェーンと従来のデータベース: 主な違い点で適性を確認したほうが早く、またサトシ・ナカモトとは｜ビットコイン創設者の正体・候補者・資産はいくら？【2026】は、この改ざん耐性という発想がどこから来たかの背景にあたります。

開発環境の選び方：Remix・Foundry・Hardhat 3の三択

環境構築で迷う必要はありません。学習の最初はRemix、コードをGitで管理し始めたらFoundryかHardhat 3。この二段構えで十分です。

最初の一歩はRemix（インストール不要）

Remixはブラウザで動く公式IDEで、コンパイル・デプロイ・関数呼び出しまで完結します。ローカルにNode.jsもコンパイラも入れずに、コントラクトの動きを目で確認できるため、構文を覚える段階ではこれが最短です。仮想的なEVM（Remix VM）が内蔵されているので、ウォレットもテストネットのETHも不要な状態から始められます。

本格開発はFoundryかHardhat 3

Foundryは、テストもSolidityで書くのが最大の特徴です。テストコードのために別言語を覚えなくてよく、実行が速い。forge（ビルド・テスト）、cast（チェーンへの問い合わせ）、anvil（ローカルノード）で構成され、Ganacheが担っていたローカルノードの役割は anvil が引き継いでいます。

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

forge init hello-solidity
cd hello-solidity
forge build
forge test -vvv

Hardhat 3は、フロントエンドがTypeScriptで、テストもTypeScriptに寄せたい場合に選びます。Hardhat 3ではSolidityで書くテストにも対応したため、両方を混在させられる点が2系との違いです。判断基準は単純で、チームがJavaScript/TypeScript資産を持っているならHardhat 3、コントラクト単体の品質と実行速度を優先するならFoundry。両方を入れて迷うくらいなら、先にFoundryだけで一周してください。

古い記事を見分ける：Truffle・Ganache・Ropstenが出てきたら閉じる

検索で上位に出る日本語のSolidity入門記事は、2021年前後に書かれたものが少なくありません。次の語が手順に含まれていれば、その記事のとおりには動きません。

• Truffle / Ganache：ConsenSysが開発を終了し、リポジトリはそれぞれ2024年4月・2024年1月にアーカイブされた。npm install -g truffle から始まる手順は追わない。
• Ropsten / Rinkeby / Kovan / Goerli / Holesky：いずれも現在は使えない、または役目を終えたテストネット。アプリ開発のテストネットはSepoliaに一本化されている（Hoodiはバリデータ・プロトコル検証用で、コントラクト開発の入口ではない）。
• SafeMath：0.8.0以降は言語側でオーバーフローがチェックされるため不要。まだ必須と書いてあれば、記事全体が2020年以前の前提です。

基本構文：最小コントラクトを1つ読み切る

構文を網羅的に暗記するより、20行のコントラクトを完全に説明できるほうが先に進めます。次のコードにSolidityの主要素がほぼ入っています。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Counter {
    uint256 public count;                    // 状態変数：ストレージに永続化される
    address public immutable owner;          // デプロイ時に確定し以後変更不可

    event Incremented(address indexed from, uint256 newCount);
    error TooLarge(uint256 requested);       // カスタムエラー（0.8.4以降）

    constructor() {
        owner = msg.sender;                  // デプロイした人のアドレス
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "not owner");
        _;                                   // ここに本体が展開される
    }

    function increment(uint256 step) external onlyOwner {
        if (step > 100) revert TooLarge(step);
        count += step;                       // 桁あふれ時は自動でrevert
        emit Incremented(msg.sender, count);
    }

    function getCount() external view returns (uint256) {
        return count;                        // viewは状態を変えない＝ガス不要で読める
    }
}

pragmaとライセンス識別子

先頭の pragma solidity ^0.8.20; は、コンパイラのバージョン制約です。^ は「0.8.20以上、0.9.0未満」を意味し、0.8.36でもそのままコンパイルできます。上限をv0.8.36にピン留めしないのは、0.8系が破壊的変更を避ける運用のためで、実務でも下限だけを切る ^0.8.x が一般的です。なおOpenZeppelin Contracts v5系は自身が ^0.8.20 を要求するため、これより低い下限は指定できません。SPDXのライセンスコメントを省くとコンパイル時に警告が出ます。

可視性とstate mutability

関数には可視性（external / public / internal / private）と、状態への関わり方（view / pure / payable）を付けます。初心者が最初に理解すべきは view で、状態を変えない関数はトランザクションを発行せずに読めるためガス代がかかりません。逆に、状態を書き換える関数はすべて有料です。public の状態変数には同名のgetterが自動生成されるので、上のコードで getCount() は本来不要な冗長さも含んでいます。

mapping・構造体・配列の使い分け

キーから値を引くだけなら mapping(address => uint256) を使います。ただしmappingには全キーを走査できないという制約があり、一覧表示が要るなら配列の併用が要ります。そしてここで、ガス代の現実が効いてきます。配列を全件ループする関数は、要素が増えるほどガスが増え、いずれブロックのガス上限に当たって永久に実行できない関数になる。オンチェーンでの全件ループは、原則として設計ミスだと考えてください。

エラー処理はrequireとカスタムエラー

失敗時は状態変更をすべて巻き戻す（revert）のが基本です。文字列付きの require(cond, "msg") は読みやすい反面、文字列をバイトコードに埋め込むぶんガスを食います。そのため引数付きで理由を返せるカスタムエラー（error TooLarge(uint256)）が主流になりました。require(cond, TooLarge(step)) のようにrequireへ直接カスタムエラーを渡す記法は0.8.26でvia-IR限定として導入され、0.8.27から通常（レガシー）のパイプラインでも使えます。0.8.36を使うならそのまま書けます。0.8.26以前のコンパイラが対象なら、if (...) revert TooLarge(step); の形にしてください。

eventとmodifier

eventはブロックチェーンのログに記録を残す仕組みで、フロントエンドが状態変化を検知する唯一の実用的な手段です。indexed を付けたパラメータは絞り込み検索の対象になります（通常のイベントで最大3つ、anonymous 指定時のみ4つ）。modifierは前提条件を関数から切り出す仕組みで、_; の位置に関数本体が展開されます。所有者チェックのような繰り返し条件はmodifierへ寄せるのが慣例です。

実装からデプロイまで：SepoliaにERC-20を出す

トークンをゼロから実装する必要はありません。監査済みのOpenZeppelin Contracts（v5.6.1）を継承します。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

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

contract IssohToken is ERC20, Ownable {
    constructor(address initialOwner)
        ERC20("Issoh Token", "ISH")
        Ownable(initialOwner)          // v5系はオーナーを引数で明示する
    {
        _mint(initialOwner, 1_000_000 * 10 ** decimals());
    }

    function mint(address to, uint256 amount) external onlyOwner {
        _mint(to, amount);
    }
}

OpenZeppelin v5系では Ownable のコンストラクタに初期オーナーのアドレスを渡す必要があります。引数なしで Ownable() と書く記事はv4系の内容なので、そのままではコンパイルが通りません。

Foundryでビルドしてテストする

依存を入れてビルドし、テストを回します。テストもSolidityで書けるため、コントラクトと同じ頭のまま検証できます。

forge install OpenZeppelin/[email protected]

# これが無いと @openzeppelin/... のimportが解決できずビルドが落ちる
echo '@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/' >> remappings.txt

forge build
forge test -vvv

# 特定関数だけをファズテストにかける
forge test --match-test testFuzz_Mint -vvv

この remappings.txt の1行を忘れると forge build が最初のimportで失敗します。OpenZeppelinの公式ドキュメントもFoundryでの導入手順としてこのリマッピング追加を指示しており、入門者が最初に詰まる定番の場所です。

Sepoliaへデプロイして検証まで通す

アプリ開発の既定テストネットはSepoliaです。ethereum.orgは「Sepoliaはアプリケーション開発における推奨デフォルトのテストネット」と明記しています。テスト用ETHは無料ですが、フォーセットごとに配布条件が違い、ここも初心者が止まる場所です。Google Cloud Web3のフォーセットはGoogleアカウントだけで受け取れます。Alchemyはメインネット側に一定額（0.001 ETH程度）の残高を求め、PoW FaucetはGitcoin Passportのスコアを見るなど、Botよけの条件が付きます。まったくETHを持っていない状態なら、Google Cloud Web3から始めるのが確実です。

forge create src/IssohToken.sol:IssohToken \
  --rpc-url $SEPOLIA_RPC_URL \
  --private-key $PRIVATE_KEY \
  --broadcast \
  --constructor-args $OWNER_ADDRESS \
  --verify --etherscan-api-key $ETHERSCAN_API_KEY

--verify まで通しておくと、Etherscan上でソースコードが公開され、誰でもロジックを読める状態になります。検証されていないコントラクトは、実運用では信用されないと考えてください。秘密鍵を環境変数やコマンド履歴に残す運用は本番では避け、ハードウェアウォレットやキーストアを使います。

ハマりどころ：既定EVMバージョンがosakaになっている

ここが2026年に新しく生まれた落とし穴です。v0.8.36の既定EVMターゲットは osaka（Fusakaアップグレード相当）で、Solidity公式ドキュメントのターゲット一覧でも osaka がdefaultと記載されています。EVMバージョンが新しいと、そこで追加されたオペコードを含むバイトコードが生成されるため、まだ追随していないチェーンやL2にデプロイすると、原因の掴めない失敗やコンパイル済みコードの不整合を起こします。対象チェーンに合わせて明示的に落とすのが安全です。

# foundry.toml
[profile.default]
solc_version = "0.8.36"
evm_version = "cancun"      # 追随していないチェーンに出すときだけ落とす

誤解しないでほしいのは、常に落とすべきではないということです。SepoliaとEthereumメインネットはFusakaに追随済みなので、既定の osaka のままで問題ありません。明示的に cancun などへ落とす必要があるのは、まだ追随していないL2や自前のプライベートチェーンにデプロイする場合です。公式ドキュメントも「対象と異なるEVMバージョンでコンパイルすると、誤った挙動や失敗を招く」と警告しています。デプロイ先が対応しているEVM版を確認しないまま出す運用が事故のもとで、方向はどちらもありえます。

初心者が踏む脆弱性：ガス代より先に守るべきもの

スマートコントラクトのバグは、パッチを当てて直す、という選択肢がありません。資金が抜かれたあとで気づくのが典型です。頻出の3つだけは、書き始める前に頭に入れてください。

リエントランシー：送金の前に状態を更新する

送金相手がコントラクトの場合、送金処理の途中で相手のコードが動き、こちらの関数をもう一度呼び返せます。残高をゼロにする前に送金していると、残高が残ったまま何度でも引き出されます。防ぎ方は「Checks-Effects-Interactions」、つまり検証→状態更新→外部呼び出しの順を守ることです。

mapping(address => uint256) private _balances;

function withdraw() external {
    uint256 amount = _balances[msg.sender];
    require(amount > 0, "no balance");

    _balances[msg.sender] = 0;                        // 先に状態を更新（Effects）
    (bool ok, ) = msg.sender.call{value: amount}("");  // 外部呼び出しは最後（Interactions）
    require(ok, "transfer failed");
}

順序を守れない構造になったときは、OpenZeppelinの ReentrancyGuard を継承して nonReentrant 修飾子を付けます。Cancun以降のトランジェントストレージを使う ReentrancyGuardTransient も同梱されており、こちらはガス消費が小さくなります。ただしトランジェントストレージ（tstore/tload）はEVMのCancun以降が前提のため、デプロイ先が対応しているかを先に確認してください。

アクセス制御漏れ：tx.originで認証しない

tx.origin はトランザクションの起点となったアドレスを返しますが、これを認証に使うと、被害者が悪意あるコントラクトを一度呼んだだけで、そのコントラクトが被害者になりすませます。認証は必ず msg.sender で行い、権限管理はOpenZeppelinの Ownable（単独オーナー）か AccessControl（ロール単位）に任せるのが安全です。初期化関数やmint関数に修飾子を付け忘れる、という単純な漏れも実際の被害として多く報告されています。

オーバーフローは解決済み、では何が残っているか

0.8系で算術は自動チェックされるようになりましたが、unchecked { } ブロックの中だけはチェックが外れます。ガス最適化のためにuncheckedを使う例をコピーする場合、その中の演算は自分で安全性を保証しなければなりません。もう一つ残るのが整数除算の切り捨てです。Solidityに小数はなく、割り算は必ず切り捨てられます。分配ロジックで先に割ってから掛けると端数が消えるため、掛けてから割るのが鉄則です。

監査に出す前に自分でやること

外部監査は費用も期間もかかります。その前に、forge test でのユニットテストと、ランダム入力を投げるファズテスト（forge test のfuzzing）、静的解析ツール（Slitherなど）による検査を通してください。少なくとも「オーナーだけが呼べるはずの関数を、他人が呼べないこと」を明示的にテストする。ここまでやらずに監査へ出すのは、費用の使い方として効率が悪すぎます。

学習ロードマップと、Solidityを学ばないほうがいい人

学習の順路は、Remixで構文を触る → CryptoZombiesやSolidity by Exampleで小さなコントラクトを写経する → Ethernautで脆弱性を突く側を経験する → Foundryでテスト込みの開発に移る、という並びが最短です。とくにEthernautは、攻撃者の視点でコントラクトを壊す演習で、セキュリティの理解が一段変わります。公式ドキュメントは仕様の一次情報として常に手元に置いてください。

そのうえで、はっきり言っておきます。Web3領域で働く意思がないWebエンジニアが、汎用スキルとしてSolidityを学ぶ費用対効果は高くありません。Solidityが動く場所はEVM互換チェーンに限られ、書ける対象は「価値の移転ルール」に偏っています。ガス代の制約から、ふつうのアプリ開発で身につけた設計の勘（テーブル全件走査、リッチなデータ構造、後からの仕様変更）はほとんど逆向きに働きます。学ぶ理由がブロックチェーン開発の職務そのもの、あるいは自社プロダクトへの組み込み検討であるなら投資に値しますが、「新しい言語を一つ増やす」目的なら、他の選択肢のほうが回収は早い。市場そのものの見通しについてはWeb3.0の未来展望とその課題で整理しています。

よくある質問

Solidityの読み方は？

「ソリディティ」です。英単語としては「固さ・堅牢さ」を意味します。カタカナ表記では「ソリディティ」がほぼ定着しており、日本語の技術文書でもこの表記が使われます。

Solidityの難易度は高いですか？

文法そのものはJavaScriptやJavaを触ったことがあれば数日で読めます。難しいのは言語ではなく、ガス代・不可逆性・攻撃者が常時存在するという実行環境の前提です。「コンパイルが通るコード」と「本番に出せるコード」の距離が、一般的なWeb開発よりはるかに遠い、と考えてください。

Solidityエンジニアの年収はどのくらいですか？

正規雇用の求人がブロックチェーン専業企業と暗号資産事業者にほぼ限られるため、母数が小さく、レンジも案件ごとの振れ幅が大きいのが実情です。一般的なWeb系より高い提示を見かける一方、募集自体が途切れる時期もあり、平均値を出すこと自体にあまり意味がありません。金額よりも「Solidityだけで職を探すと選択肢が狭い」という構造を先に見てください。既存のバックエンド・フロントエンドの経験に上乗せするスキルとして持つのが、現実的な使い方です。最新の相場は求人サイトの掲載レンジで確認してください。

Truffleはまだ使えますか？

新規採用は避けてください。Truffleは2024年4月、Ganacheは2024年1月にリポジトリがアーカイブされ、更新は止まっています。既存プロジェクトの保守で使い続ける以外の理由はありません。移行先はFoundryかHardhat 3で、ローカルノード（Ganache）の代替はFoundryの anvil です。

デプロイにお金はかかりますか？

テストネット（Sepolia）でのデプロイは、フォーセットから無料でテスト用ETHを入手できるため実費はかかりません。メインネットにデプロイする場合のみ、コントラクトのサイズとガス価格に応じた実費のETHが必要になります。学習と検証の段階でメインネットを使う理由はありません。

スマートコントラクトの言語はSolidity以外にもありますか？

EVM向けにはPython風の文法を持つVyperがあり、意図的に機能を絞ることで安全性を高める設計です。ただし日本語・英語ともに情報量、ライブラリ（OpenZeppelinなど）、求人のいずれもSolidityが圧倒的で、最初に学ぶならSolidityが妥当です。EVM以外のチェーン（SolanaのRustなど）は言語もランタイムも別物になります。

関連記事

• ブロックチェーン(Ethereum)と分散ファイルシステム(IPFS)の技術的背景と動画配信の課題
• ブロックチェーンと従来のデータベース: 主な違い点
• Web3.0の未来展望とその課題
• サトシ・ナカモトとは｜ビットコイン創設者の正体・候補者・資産はいくら？【2026】