---
title: "Solidityスマートコントラクトのセキュリティに関するベストプラクティス12選"
description: "専門家によるセキュリティのヒントとツールでスマートコントラクトを保護する。"
---

# Solidityスマートコントラクトのセキュリティに関するベストプラクティス12選

<ImageBlock
  src="https://media.alchemy.com/1762971572-smart-contract-security.png"
  alt="コードセキュリティを表す抽象的なシールド"
  width={5760}
  height={2700}
  priority
/>

スマートコントラクトは、ブロックチェーンの魔法を支える存在だ。オンチェーンロジックを自動化するコードブロックであり、分散型レンディングプロトコルの清算閾値から現実資産のトークン化まで、あらゆることを規定する。

しかし大きな力には大きな責任が伴う。特にセキュリティに関してはそうだ。1つのバグが大規模なエクスプロイトにつながりかねず、誰も自分のプロジェクトが数百万ドル規模のハッキング事件の見出しになることを望まない。

2025年上半期だけでも、[エクスプロイトと侵害により23億ドル以上の暗号資産が失われ](https://www.quillaudits.com/reports/crypto-exploits-h1-report-2025)、そのうちアクセス制御の問題だけで16億ドル以上を占めた。Ethereumや類似チェーン上で[Solidity](https://www.alchemy.com/overviews/solidity)を使って開発しているなら、セキュリティを固めることは選択肢ではない。ユーザーの資金を守り、自分の評判を保つために不可欠なことだ。

この記事では、スマートコントラクトセキュリティが実際に何を意味するのかを解説し、主要な脆弱性のいくつかを掘り下げ、コード例付きの実践的なベストプラクティスを紹介する。これにより、コードを堅牢にし、メインネットに安全なコントラクトをデプロイする助けとなるはずだ。

そして忘れてはならないのは、メインネットにデプロイする前に必ずテストネットでテストすることだ。ユーザーがコントラクトに資金を送り始める前に脆弱性を見つけておく方がはるかに良い。

## スマートコントラクトセキュリティとは何か

[スマートコントラクト](https://www.alchemy.com/overviews/solidity-smart-contract)とは、特定の条件が満たされたときに実行される自己実行型のコードだ。仲介者なしで転送、投票、あるいは複雑なDeFi操作を処理する自動化された契約と考えればよい。バイトコードとしてブロックチェーンにデプロイされ、一度稼働すると不変になるため、コントラクトの欠陥は誰の目にも触れる状態になる。

ここでのセキュリティとは、コードが盤石であることを確認することに尽きる。コントラクト自体がオンチェーン資産をカストディすることが多いためだ。ハッカーは特定のコントラクトから資金を引き出せるか。コントラクトのロジックは奇妙なエッジケースでも崩れないか。資産は不正アクセスから守られているか。

これらの問いに脆弱性があれば、悪意のあるアクターがコントラクトからユーザー資金を抜き取り、自分のものにできてしまう。こうした脆弱性から身を守るには、入力チェック、設計パターン、コード監査の実装を検討し、メインネットデプロイ前にコードを強化する必要がある。

より詳しい導入については、[Ethereumのスマートコントラクトセキュリティに関するドキュメント](https://ethereum.org/en/developers/docs/smart-contracts/security/)を参照してほしい。

## なぜセキュリティがあなたにとって重要なのか

安全でないコントラクトを構築することは、ユーザーにとってリスクなだけでなく、プロジェクトを一晩で崩壊させかねない。プロジェクトから資金が抜かれると、ユーザーは信頼を失い、多くの場合戻ってこない。ブロックチェーンの不可逆性により、資金が失われればそれで終わりだ。ここにチャージバックは存在しない。そして資金が一瞬で消え去るのと同じように、あなたの評判も消え去る。

数十億ドルがオンチェーンで動く中、ハッカーは常に弱点を探っている。最近の統計がその大きさを示している。2025年上半期だけで23億ドルが失われた。その損失の大半は、[不適切なアクセス制御やリエントランシー](https://www.quillaudits.com/reports/crypto-exploits-h1-report-2025)のような防げるはずのバグに起因する。セキュリティを優先することで、ユーザーを守り、信頼を築き、プロジェクトが一つのトランザクションでゼロになるという悪夢を避けられる。

市場に出回っているツールとベストプラクティスを活用すれば、機能するだけでなく堅牢なコードを書くためにできることは数多くある。

## スマートコントラクトの脆弱性を理解する

スマートコントラクトの脆弱性を理解する上で役立つリソースの一つが[OWASP](https://owasp.org/)（Open Web Application Security Projectの略）だ。これは世界中のソフトウェアセキュリティ向上のために無料のリソースを作成する非営利団体である。彼らの[Smart Contract Top 10](https://owasp.org/www-project-smart-contract-top-10/)は、実際のエクスプロイトや数十億ドル規模の損失を引き起こしたインシデントのデータに基づく、ブロックチェーンアプリにおける最も危険な脆弱性のリストのようなものだ。

このリストは、各エコシステムにおけるハッキングのパターンから導き出された、監査やコントラクト設計で優先すべき脆弱性の一覧を開発者に提供する。2025年版では、[昨年だけで9億5300万ドルの損失](https://cybersecuritynews.com/owasp-top-10-2025-smart-contract/)につながったアクセス関連の欠陥のようなリスクが強調されている。コードをレビューする際、これらの一般的な脆弱性を意識することは、コードの堅牢性を築き始めるための良い基盤となる。

1. **アクセス制御の脆弱性**: 権限チェックの欠落などにより、権限のない者がデータや機能を操作できてしまう欠陥。このリストのトップに位置するのには理由がある。盗まれた管理者キーによってコントラクトが枯渇させられる、というのが典型例だ。単純だが効果的で、非常に頻発する。
1. **価格オラクル操作**: ハッカーは外部データフィード（オラクル）を改ざんして価格を歪め、不良貸付や不正な取引を引き起こすことができる。正確な価格が重要なDeFiで特によく見られる。
1. **ロジックエラー**: コントラクトが意図しない動作をするバグ。トークンの過剰発行や報酬の誤計算などだ。あらゆるエッジケースをカバーしなければならない脆弱性であり、コントラクトロジックの徹底的な監査が求められる。
1. **入力検証の欠如**: ユーザー入力をチェックしないと、不正なデータがロジックを壊したりオーバーフローを悪用されたりする恐れがある。
1. **リエントランシー攻撃**: 外部呼び出しにより、実行途中でハッカーが関数に再侵入できてしまい、しばしば複数回の引き出しにつながる。
1. **未チェックの外部呼び出し**: 失敗した呼び出しを処理しないと、コントラクトが誤った前提のまま処理を続けてしまう。
1. **フラッシュローン攻撃**: 即時ローンを悪用し、単一トランザクション内で市場やプロトコルを操作する。
1. **整数のオーバーフローとアンダーフロー**: 数値が限界を超えて折り返す際の計算誤りが、誤った計算や資金の盗難につながる。
1. **安全でない乱数**: 予測可能な不十分なRNGは、ゲームや抽選で悪用されうる。
1. **サービス拒否（DoS）攻撃**: ガスを大量消費する操作でコントラクトを過負荷にし、使用不能にする。

OWASPの詳細については、[Smart Contract Top 10ページ](https://owasp.org/www-project-smart-contract-top-10/)を参照してほしい。Ethereum固有のヒントについては、[セキュリティガイドライン](https://ethereum.org/en/developers/docs/smart-contracts/security/)を確認してほしい。

## スマートコントラクトセキュリティのベストプラクティス12選

脅威の全体像を理解したところで、実践的な防御策に踏み込んでいこう。OWASPリストに挙げられた各脆弱性には、何千ものコントラクトで実戦テストされてきた対応するベストプラクティスが存在する。

以下のセクションでは、これらの一般的な欠陥を一つずつ取り上げ、脆弱なパターンと安全な実装の両方を示す具体的なコード例とともに解説する。これを防御のプレイブックとして捉えてほしい。一貫して適用すれば攻撃対象領域を減らせる、単純明快なテクニックだ。

### 1. `delegatecall`を慎重に使う

`Delegatecall`を使うと、あるコントラクトが自身のストレージを使いながら別のコントラクトのコードを実行できる。ライブラリやアップグレードには非常に便利だが、呼び出されたコードが変数を書き換えてしまうと予期しない状態変化につながりうるためリスクがある。オーナーアドレスなどの重要な状態を上書きしたり資金を抜き取ったりする悪意あるロジックをハッカーが注入する、主要なエクスプロイトの背後にはこれがある。

危険なのは、`delegatecall`が呼び出し元コントラクトのコンテキスト（`msg.sender`、`msg.value`、ストレージ）を保持するため、外部コードが完全な権限を持って実行される点だ。絶対に必要な場合にのみ使用し、コントラクト間でストレージレイアウトが完全に一致していることを確認すること。スロットのずれはデータの破損を招く。

脆弱な例を示す:

<CodeSnippet language="solidity" code={`contract LibraryContract {
    address public owner; // Slot 0
    
    function updateOwner() public {
        owner = msg.sender; // Changes caller's storage slot 0!
    }
}

contract VulnerableProxy {
uint256 public value; // Slot 0 - MISMATCH!
address public owner; // Slot 1

    function delegateCall(address lib) public {
        // DANGER: updateOwner() will overwrite 'value', not 'owner'!
        lib.delegatecall(abi.encodeWithSignature("updateOwner()"));
    }

}`} />

より安全なアプローチはこうだ:

<CodeSnippet
  language="solidity"
  code={`contract SecureProxy {
    address public implementation;
    address public owner;
    
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }
    
    function execute(bytes memory data) public onlyOwner {
        (bool success,) = implementation.delegatecall(data);
        require(success, "Execution failed");
    }
}`}
/>

**ベストプラクティス:** [OpenZeppelinのアップグレード可能コントラクト](https://openzeppelin.com/contracts/)のような確立されたプロキシパターンを使い、バージョン間で同一のストレージレイアウトを維持し（変数の順序変更や型変更を絶対に行わない）、`delegatecall`を信頼できる監査済みのコントラクトのみに制限し、内部で`delegatecall`を安全に使用する`library`キーワード付きのライブラリの利用を検討し、`delegatecall`にユーザー制御可能なアドレスを決して許可しないこと。それは即座の乗っ取りベクトルとなる。

### 2. リエントランシーガードを使う

リエントランシーは、関数が状態更新を完了する前に外部呼び出しが制御を渡してしまうときに発生し、呼び出し元が残高更新前に引き出しなどの動作を繰り返し実行できてしまう。これはOWASPのWeb3リスクトップリストで第5位にランクされ、[悪名高いDAOハック（6000万ドルの損失）](https://www.gemini.com/cryptopedia/the-dao-hack-makerdao)など、暗号資産史上最大級のハッキングの一因となった。

攻撃者は、資金送金と状態更新の間にあるこのリエントランシーの隙間を悪用し、引き出し関数を再帰的に呼び出すことでコントラクトを枯渇させることができる。外部コントラクトは常に敵対的であると想定すべきだ。

脆弱な例:

<CodeSnippet language="solidity" code={`contract VulnerableBank {
    mapping(address => uint256) public balances;
    
    function withdraw() public {
        uint256 bal = balances[msg.sender];
        require(bal > 0);
        
        // DANGER: Sends Ether before updating balance!
        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent);
        
        balances[msg.sender] = 0; // Too late - already reentered!
    }
}

contract Attacker {
VulnerableBank bank;

    fallback() external payable {
        if (address(bank).balance >= 1 ether) {
            bank.withdraw(); // Calls withdraw again!
        }
    }

    function attack() external payable {
        bank.withdraw(); // Starts the loop
    }

}`} />

安全な実装:

solidity

\`import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureBank is ReentrancyGuard \{ mapping\(address =&gt; uint256\) public balances;

<CodeSnippet language="solidity" code={`import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureBank is ReentrancyGuard {
mapping(address => uint256) public balances;

    function withdraw() public nonReentrant {
        uint256 bal = balances[msg.sender];
        require(bal > 0);

        // Update state BEFORE external call
        balances[msg.sender] = 0;

        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent);
    }

}`} />

**ベストプラクティス:** OpenZeppelinの`ReentrancyGuard`修飾子を使い、Checks-Effects-Interactionsパターン（検証 → 状態更新 → 外部呼び出し）に従い、ユーザー自身が資金を引き出すpull-over-pushパターンの採用を検討すること。

### 3. 認証には`tx.origin`ではなく`msg.sender`を使う

`tx.origin`という呼び出しは元のトランザクション発起者を遡って追跡するのに対し、`msg.sender`は直接の呼び出し元を指す。この違いはセキュリティ上非常に重要だ。複数コントラクトにまたがる呼び出しチェーンでは、`tx.origin`は常に一定のままだが、悪意のある中間コントラクトによって、あなたのコードが元のユーザーを認可済みだと誤認するよう悪用されうる。

攻撃者はあなたの関数を呼び出すフィッシング用コントラクトを作成できる。もしあなたが`tx.origin`をチェックしていれば、それはトランザクションを開始した被害者を指してしまい、認証を完全に迂回されてしまう。`msg.sender`は常に直接の呼び出し元であるため、アクセス制御において信頼できる。`tx.origin`は、特にトランザクションの発起者が必要な稀なケースのみに使い、認証には決して使わないこと。この脆弱性はOWASPのリスク第1位であるアクセス制御の欠陥に直結している。

脆弱な例:

<CodeSnippet language="solidity" code={`contract VulnerableWallet {
    address public owner;
    
    constructor() { owner = msg.sender; }
    
    function transfer(address payable to, uint256 amount) public {
        require(tx.origin == owner, "Not owner"); // BAD!
        to.transfer(amount);
    }
}

// Attacker tricks owner into calling this
contract MaliciousContract {
function attack(address wallet) public {
// When owner calls this, tx.origin == owner// So the wallet thinks the call is authorized!
VulnerableWallet(wallet).transfer(payable(msg.sender), 1 ether);
}
}`} />

安全な実装:

<CodeSnippet
  language="solidity"
  code={`contract SecureWallet {
    address public owner;
    
    constructor() { owner = msg.sender; }
    
    function transfer(address payable to, uint256 amount) public {
        require(msg.sender == owner, "Not owner"); // GOOD!
        to.transfer(amount);
    }
}`}
/>

**なぜこれが重要か:** オーナーが誤って悪意のあるコントラクトとやり取りしてしまった場合（フィッシングリンクをクリックする、侵害されたアプリを使うなど）、そのコントラクトは脆弱なウォレットを枯渇させることができる。なぜなら`tx.origin`は依然としてオーナーを指しているからだ。`msg.sender`であれば、オーナーアドレス自身のみが送金を認可できる。認証とアクセス制御チェックには必ず`msg.sender`を使うこと。

### 4. Solidityの可視性修飾子を正しく使う

可視性修飾子はアクセスの境界を定義する: `public`（内部・外部を問わず誰からでも呼び出し可能）、`external`（コントラクト外からのみ）、`internal`（このコントラクトと継承先のコントラクト）、`private`（このコントラクトのみ）。古いSolidityバージョンでは、修飾子を省略するとデフォルトで`public`となり、機密性の高い関数が意図せず外部の攻撃者に晒されてしまうことがあった。

誤った可視性設定により、本来制限されるべき管理者関数をハッカーが呼び出したり、重要な状態変数を操作したりするエクスプロイトが発生してきた。可視性は常に明示的に宣言すること。セキュリティ対策であると同時に、可読性の向上にもなる。

solidity

\`contract VulnerableBank \{ mapping\(address =&gt; uint\) balances;

<CodeSnippet
  language="solidity"
  code={`contract VulnerableBank {
    mapping(address => uint) balances;
    
    // BAD: accidentally public in old Solidity
    function resetBalance(address user) { 
      balances[user] = 0; // anyone can call this!
    }
    
    // GOOD: explicit visibility
    function deposit() external payable {
    balances[msg.sender] += msg.value;
    }
    
    function _updateInternal() internal { 
        // only this contract + children
    }
}`}
/>

デプロイ前に、可視性修飾子の欠落や誤りを検出するため[Slither](https://github.com/crytic/slither)のような静的解析ツールを使用すること。

### 5. ブロックタイムスタンプの操作を避ける

バリデータは`block.timestamp`を小さな範囲内（Ethereumではおおよそ±15秒）で操作できるため、正確なタイミングや乱数のソースとしては信頼できない。マイナーやバリデータは自らに有利になるようタイムスタンプを調整し、支払いのトリガー、抽選での勝利、時間ベースのチェックの回避などを行うことができる。

そのため、秒単位が重要となる重要なロジックに`block.timestamp`を使ってはならず、乱数生成には絶対に使わないこと。「24時間経過したか」といった大まかな時間見積もりには問題ないが、正確な条件判定には危険である。

脆弱な例:

<CodeSnippet
  language="solidity"
  code={`contract TimestampLottery {
    uint public lastPlay;
    
    fallback() external payable {
        require(msg.value == 10 ether);
        require(block.timestamp != lastPlay);
        lastPlay = block.timestamp;
        
        // BAD: validator can manipulate timestamp to win
        if (block.timestamp % 15 == 0) {
            payable(msg.sender).transfer(address(this).balance);
        }
    }
}`}
/>

タイミングに関するより良いアプローチ:

<CodeSnippet
  language="solidity"
  code={`contract BlockBasedTiming {
    uint public startBlock = block.number;
    
    // Use block numbers instead (~12s per block on Ethereum)
    function isTimePassed(uint blocks) public view returns (bool) {
        return block.number >= startBlock + blocks;
    }
}`}
/>

乱数については、自作しないこと。代わりに[Chainlink VRF](https://chain.link/vrf)や類似の検証可能ランダム関数オラクルを使用し、暗号学的に安全で改ざん耐性のある乱数を得ること。

### 6. 算術のオーバーフローとアンダーフローを避ける

0.8より前のSolidityバージョンでは、整数が最大値または最小値を超えると静かに折り返してしまう。つまり`uint8`は255からインクリメントすると0になり、0からデクリメントすると255になる。

これにより、攻撃者がトークンを無限に発行したり、巨大な数値に折り返るマイナス残高を作り出したり、重要なチェックを迂回したりする壊滅的なエクスプロイトが発生してきた。

脆弱な例（0.8より前）:

<CodeSnippet language="solidity" code={`pragma solidity 0.7.0;

contract UnsafeToken {
mapping(address => uint8) public balances;

    function transfer(address to, uint8 amount) public {
        balances[msg.sender] -= amount; // Underflow: 0 - 1 = 255
        balances[to] += amount;         // Overflow: 255 + 1 = 0
    }

}`} />

自動オーバーフロー保護のためSolidity &gt;=0.8にアップグレードする:

<CodeSnippet language="solidity" code={`pragma solidity ^0.8.0;

contract SafeToken {
mapping(address => uint8) public balances;

    function transfer(address to, uint8 amount) public {
        balances[msg.sender] -= amount; // Reverts on underflow
        balances[to] += amount;         // Reverts on overflow
    }

}`} />

古いSolidityから抜け出せない場合は、OpenZeppelinのSafeMathライブラリを使うこと。0.8以上ではチェックが組み込まれており自動的にリバートするが、ガス最適化のために意図的に折り返し動作を望む場合は`unchecked \{\}`ブロックを使用できる。

### 7. 堅牢なアクセス制御を実装する

破損したアクセス制御は、権限のないユーザーに特権的な関数の実行を許してしまう。これはOWASPのWeb3トップ10で第1位の脆弱性であり、2025年上半期だけで16億ドル以上の損失を引き起こした。適切なガードがなければ、攻撃者は資金を枯渇させ、トークンを発行し、コントラクトを一時停止し、所有権を変更できる。

よくある間違いとしては、修飾子の欠落、認証に`tx.origin`を頼ること、あるいはアップグレード時に見落とされがちな単純な`require\(msg.sender == owner\)`チェックの使用などが挙げられる。解決策は、最小権限の原則に基づくロールベースのアクセス制御だ。各アドレスには絶対に必要な権限のみを与える。

OpenZeppelinを使った安全な実装:

<CodeSnippet language="solidity" code={`pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";

contract SecureVault is AccessControl {
bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");
bytes32 public constant OPERATOR_ROLE = keccak256("OPERATOR_ROLE");

    constructor() {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(ADMIN_ROLE, msg.sender);
    }

    function withdrawFunds() public onlyRole(ADMIN_ROLE) {
        // Only admins can withdraw
    }

    function updateConfig() public onlyRole(OPERATOR_ROLE) {
        // Operators handle config, not full admin
    }

}`} />

ロール割り当てを定期的に監査し、重大な変更には時間遅延付きの管理者アクションを実装し、重要なロールにはマルチシグウォレットを使うこと。認証には決して`tx.origin`を使わないこと。自前で実装するのではなく、[OpenZeppelin AccessControl](https://docs.openzeppelin.com/contracts/5.x/access-control)のような実戦テスト済みのライブラリを活用すること。

### 8. オラクル連携を操作から保護する

オラクルはブロックチェーンと現実世界のデータを統合するが、中央集権的であったり容易に操作されうるものであると、攻撃者は虚偽の情報を送り込んであなたのコントラクトを悪用できる。この種のエクスプロイトはOWASPのWeb3リスクで第2位にランクされ、DeFiプロトコルから数億ドルを枯渇させてきた。

フラッシュローン攻撃はしばしばオンチェーンの価格オラクルを操作する（単一のDEXを価格ソースとして使うなど）。これにより、ハッカーは価格を人為的に吊り上げたり暴落させたりして、ポジションを清算したり、流動性プールを枯渇させたり、担保不足のローンを発行したりできる。単一の価格ソースや、1つのトランザクション内で操作可能なスポット価格に決して依存しないこと。

Chainlinkを使った安全なオラクル利用:

<CodeSnippet language="solidity" code={`pragma solidity ^0.8.20;

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract SecurePriceFeed {
AggregatorV3Interface internal priceFeed;
uint256 private constant STALENESS_THRESHOLD = 3600; // 1 hour

    constructor(address _aggregator) {
        priceFeed = AggregatorV3Interface(_aggregator);
    }

    function getLatestPrice() public view returns (int) {
        (
            uint80 roundId,
            int price,
            ,
            uint256 updatedAt,
            uint80 answeredInRound
        ) = priceFeed.latestRoundData();

        require(price > 0, "Invalid price");
        require(answeredInRound >= roundId, "Stale price");
        require(block.timestamp - updatedAt < STALENESS_THRESHOLD, "Price too old");

        return price;
    }

}`} />

ベストプラクティス: 複数のデータソースを持つChainlinkのような分散型オラクルネットワークを使い、重要な処理には時間加重平均価格（TWAP）を実装し、鮮度を検証し価格範囲をサニティチェックし、可能であれば複数のオラクルを集約すること。ネットワーク固有のフィードとセキュリティ上の考慮事項については[Chainlinkのドキュメント](https://docs.chain.link/)を確認すること。

### 9. すべての入力を徹底的に検証する

ユーザー入力の検証を怠ると、攻撃者は悪意のあるデータを注入したり、予期しない動作を引き起こしたり、コード内のエッジケースを悪用したりできる。これはOWASPのWeb3脆弱性で第4位にランクされ、資金の枯渇やコントラクトロジックの破壊の一般的な手口となっている。

適切なチェックがなければ、ユーザーはゼロ値を渡して手数料を回避したり、負の値を渡して算術を悪用したり、ゼロアドレスや悪意のあるコントラクトを指すアドレスを渡したり、範囲外アクセスを引き起こす配列インデックスを渡したりできる。すべての外部入力は、安全性が証明されるまでは信頼できないものとして扱うべきだ。多層防御とは、あらゆる境界で検証を行うことを意味する。ユーザー提供のデータを処理する前に、範囲、null値、配列長、ビジネスロジックの制約をチェックすること。

適切な入力検証:

<CodeSnippet language="solidity" code={`pragma solidity ^0.8.20;

contract SecureDeposit {
mapping(address => uint256) public balances;
uint256 public constant MAX_DEPOSIT = 1000 ether;

    function deposit(uint256 amount) public payable {
        require(amount > 0, "Amount must be positive");
        require(amount == msg.value, "Amount mismatch");
        require(amount <= MAX_DEPOSIT, "Exceeds max deposit");
        require(
            amount <= type(uint256).max - balances[msg.sender],
            "Balance overflow"
        );

        balances[msg.sender] += amount;
    }

    function transfer(address to, uint256 amount) public {
        require(to != address(0), "Invalid recipient");
        require(to != address(this), "Cannot transfer to contract");
        require(amount <= balances[msg.sender], "Insufficient balance");

        balances[msg.sender] -= amount;
        balances[to] += amount;
    }

}`} />

\}\`

金額がゼロでなく範囲内であること、アドレスがnullや無効でないこと、配列インデックスが範囲内であること、ビジネスロジックの制約が満たされていることを常に検証すること。

Solidity 0.8.4以上ではカスタムエラーを使い、詳細なメッセージ付きのガス効率の良いリバートを実現すること。

### 10. 外部呼び出しを安全に処理する

他のコントラクトへの外部呼び出しは、戻り値をチェックしなければ静かに失敗しうる。この問題はOWASPのWeb3リスクで第6位にランクされ、資金が塞き止められたり、実際には失敗した処理をコントラクトが成功したと仮定してしまうことにつながってきた。

`call\(\)`、`delegatecall\(\)`、`send\(\)`のような低レベル呼び出しは、自動的にリバートするのではなく、成功を示すブール値を返す。これらの戻り値を無視すると、あなたのコントラクトは誤った前提のまま実行を続けてしまい、実際には送金されていないのに送金されたと思い込んだり、失敗した重要な処理が完了したと思い込んだりする可能性がある。ERC-20の`transfer\(\)`も、一部の実装ではリバートせずfalseを返すため、この問題を抱えている。

脆弱なパターン:

<CodeSnippet
  language="solidity"
  code={`function unsafeTransfer(address payable recipient) public {
    recipient.send(1 ether); // Returns false on failure, but continues!// Contract thinks transfer succeeded
}`}
/>

安全な実装:

<CodeSnippet
  language="solidity"
  code={`contract SecureCaller {
    event CallExecuted(address target, bool success);
    
    function safeCall(address target, bytes memory data) public returns (bytes memory) {
        (bool success, bytes memory result) = target.call(data);
        require(success, "External call failed");
        
        emit CallExecuted(target, success);
        return result;
    }
    function safeTransfer(address payable recipient, uint256 amount) public {
        (bool success, ) = recipient.call{value: amount}("");
        require(success, "Transfer failed");
    }
    
    // For ERC-20 tokens, use SafeERC20 from OpenZeppelin
}`}
/>

\}\`

外部呼び出しの戻り値は常に取得しチェックすること。Ether送金には、非推奨の`send\(\)`や`transfer\(\)`よりも`call\{value: x\}\(""\)`を優先すること。トークン送金には、失敗時にリバートしない非標準的なERC-20実装を扱えるOpenZeppelinのSafeERC20ラッパーを使用すること。

### 11. フラッシュローン攻撃を緩和する

フラッシュローンは、同一トランザクション内で返済する限り、担保なしで巨額の資金を借りることを可能にする。攻撃者はこのロジックを悪用して価格を操作したり、プールを枯渇させたり、プロトコルロジックを悪用したりできる。これはOWASPのWeb3リスクで第7位にランクされ、DeFi全体で数十億ドルが失われてきた。

ハッカーはフラッシュローンで得た資金を使ってオラクル価格を人為的に歪めたり、大規模な丸め誤差を悪用したり、脆弱なコントラクトロジックを引き起こす一時的な市場状況を作り出したりする。ハッキング事件で何度も繰り返されてきた典型的なパターンはこうだ。数百万ドルを借り、価格オラクルや流動性プールを操作し、あなたのプロトコル内の価格誤りを悪用し、ローンを返済し、差額を懐に入れる。これらすべてが1つのトランザクション内でアトミックに行われる。

脆弱なパターン:

<CodeSnippet
  language="solidity"
  code={`contract VulnerablePool {
    function getPrice() public view returns (uint) {
        // BAD: using spot price that can be manipulated
        return tokenReserve / ethReserve;
    }
    
    function borrow(uint amount) public {
        uint collateral = getPrice() * userCollateral[msg.sender];
        require(collateral >= amount, "Insufficient collateral");
        // Attacker manipulates price in same transaction!
    }
}`}
/>

より良いアプローチ:

<CodeSnippet
  language="solidity"
  code={`contract SecureLending {
    mapping(address => uint256) public lastBorrow;
    
    function borrow(uint256 amount) public {
        // Add cooldown between borrows
        require(block.number > lastBorrow[msg.sender] + 2, "Too soon");
        lastBorrow[msg.sender] = block.number;
        
        // Use TWAP or Chainlink instead of spot price
        uint256 price = chainlinkOracle.getPrice();
        uint256 collateral = price * userCollateral[msg.sender];
        
        require(collateral * 150 / 100 >= amount, "Need 150% collateral");
    }
}`}
/>

防御策: スポット価格の代わりに時間加重平均価格（TWAP）やChainlinkを使うこと。重要な処理には複数ブロックにまたがるクールダウンを追加し、過剰担保を要求し、状態変化後にプロトコルの健全性を検証すること。フラッシュローンが不要であれば、完全にブロックすることも検討すべきだ。

### 12. 重要な関数におけるロジックエラーを避ける

重要な関数におけるロジックエラーは、コントラクトの中核的なセキュリティ前提を崩し、壊滅的な結果を招きうる。この種のエラーはOWASPのWeb3リスクで第3位にランクされている。技術的には「正しい」コードであるにもかかわらず、こうした欠陥がシステム全体を蝕むためだ。

コンパイラで検出される構文バグとは異なり、ロジックエラーはすべてのチェックを通過しながら誤った結果を生み出す。ループのオフバイワンエラー、演算順序の誤り、エッジケース処理の欠落、あるいは条件の欠陥などだ。典型例としては、送金後に残高を更新し忘れる、`&gt;`の代わりに`&gt;=`を使う、あるいは手数料を誤った順序で計算して精度損失を引き起こすといったものがある。

よくあるロジックエラー:

<CodeSnippet
  language="solidity"
  code={`contract LogicErrors {
    mapping(address => uint256) public balances;
    
    // ERROR 1: Balance updated AFTER transfer (reentrancy risk!)
    function withdraw(uint256 amount) public {
        payable(msg.sender).transfer(amount);
        balances[msg.sender] -= amount; // Too late!
    }
    
    // ERROR 2: Off-by-one lets loop access invalid index
    function distribute(address[] memory users) public {
        for(uint i = 0; i <= users.length; i++) { // Should be // Crashes on last iteration!
        }
    }
}`}
/>

修正版:

<CodeSnippet
  language="solidity"
  code={`contract SecureLogic {
    mapping(address => uint256) public balances;
    
    function withdraw(uint256 amount) public {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        
        // Update state BEFORE external call
        balances[msg.sender] -= amount;
        payable(msg.sender).transfer(amount);
    }
    
    function distribute(address[] memory users) public {
        for(uint i = 0; i < users.length; i++) { // Correct boundary// Safe iteration
        }
    }
}`}
/>

**防御策:** Checks-Effects-Interactionsパターン（検証 → 状態更新 → 外部呼び出し）に従い、エッジケース（ゼロ、最大値、空の配列）のユニットテストを書き、Foundryを使ったファジングでランダムな入力をテストし、「分配総額はプール残高を決して超えてはならない」といった不変条件を定義すること。重要な関数には常にピアレビューを実施すること。

## 人気のスマートコントラクトセキュリティツール6選

上記のベストプラクティスは堅牢性を高める助けとなるが、人間の目では見逃しかねないエラーを捕捉できるツールも必要だ。コードの監査に使える定番から最新のツールまでを以下に紹介する。

1. **Slither**: 40以上の検出器を備えた静的解析ツール。迅速なスキャンとコントラクトの詳細出力に優れる。[GitHub](https://github.com/crytic/slither)。
1. **Mythril**: 複数チェーンに対応し、シンボリックな問題を発見できるEVMバイトコード解析ツール。MythXの一部。[GitHub](https://github.com/ConsenSys/mythril)。
1. **Securify**: Ethereum Foundationの支援を受けた、37以上の欠陥に対応する精密な静的解析スキャナー。ウェブサイト（現在は利用不可）。
1. **Foundry**: Solidity向けの最新のテスト・ファジングフレームワーク。不変条件テストがロジックバグの発見に特に威力を発揮する。[Book](https://book.getfoundry.sh/)。
1. **Certora**: コードが仕様と数学的に一致することを証明する形式検証ツール。[Website](https://www.certora.com/)。
1. **Echidna**: 脆弱性を対象としたプロパティベースのファザー。[GitHub](https://github.com/crytic/echidna)。

これら6つのツールに加え、[Code4rena](https://code4rena.com/)のようなプラットフォームと提携し、報奨金付きの監査を利用することもできる。

## スマートコントラクトを守るために：まとめ

開発者としてのゴールはシンプルだ。ハッキングされないコントラクトを構築し、ユーザーの資金を守り、アプリを円滑に稼働させ続けること。そのプロセスにおいては、上記のベストプラクティスを取り入れ、セキュア・バイ・デザインの姿勢を身につけるべきだ。

アップグレード可能なプロキシ（[OpenZeppelin Upgrades](https://docs.openzeppelin.com/upgrades-plugins/)経由）、モジュール化されたコード、そしてアカウントアブストラクション（UX/セキュリティ向上のためのERC-4337など。詳細は[ERC-4337ガイド](https://www.alchemy.com/overviews/what-is-account-abstraction)を参照）を活用すること。ユニットテスト、形式検証、プロによる監査、ランタイムモニタリング（[Fortress](https://forta.org/)経由など）、そして[Immunefi](https://immunefi.com/)でのバグバウンティを実施すること。ユーザー、そしてプロジェクトの成功はこれにかかっている。

コントラクトセキュリティに関するさらなるリソースについては、以下を参照してほしい。

- [Ethereum Security Best Practices](https://ethereum.org/en/developers/docs/smart-contracts/security/)
- [OpenZeppelin Contracts Docs](https://docs.openzeppelin.com/contracts/)
- [Solidity by Example](https://solidity-by-example.org/)
- [Consensys Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/)

## よくある質問

### Solidityスマートコントラクトを書く際に従うべき最も重要なセキュリティパターンは何か？

最も重要なパターンには、Checks-Effects-Interactionsの使用、リエントランシーガードの実装、すべての入力の検証、明示的な可視性修飾子の設定、ロールベースの権限による適切なアクセス制御の遵守が含まれる。

### コントラクトでリエントランシー攻撃を防ぐにはどうすればよいか？

OpenZeppelinのReentrancyGuard修飾子を使い、外部呼び出しの前にコントラクトの状態を更新するChecks-Effects-Interactionsパターンに従い、ユーザー自身が資金を引き出すpull-over-pushパターンの採用を検討すること。

### なぜ認証にはtx.originではなくmsg.senderを使うべきなのか？

tx.originは、あなたのコードに元のユーザーが認可済みだと誤認させる悪意のある中間コントラクトによって悪用されうる。一方msg.senderは常に直接の呼び出し元を指すため、アクセス制御において信頼できる。

### Solidityで算術のオーバーフローとアンダーフローから身を守るにはどうすればよいか？

エラー時に自動的にリバートする組み込みのオーバーフロー/アンダーフローチェックを備えたSolidity 0.8.x以降にアップグレードすること。古いバージョンについては、OpenZeppelinのSafeMathのような十分にテストされたライブラリを使用すること。

### テストとセキュリティ監査はスマートコントラクトセキュリティにおいてどのような役割を果たすのか？

包括的なユニットテスト、Foundryのようなツールを使ったファジング、Slitherによる静的解析はエッジケースや脆弱性の発見に役立ち、独立したセキュリティ監査はメインネットデプロイ前にロジックの欠陥を特定するのに役立つ。

### Solidityでdelegatecallを安全に扱うにはどうすればよいか？

delegatecallは信頼でき監査済みの実装にのみ使用し、ユーザー制御可能なアドレスには決して使わず、コントラクト間で同一のストレージレイアウトを維持し、OpenZeppelinのアップグレード可能コントラクトのような確立されたプロキシパターンを優先すること。

### フラッシュローン攻撃からスマートコントラクトを守るにはどうすればよいか？

スポット価格の代わりに時間加重平均価格（TWAP）やChainlinkオラクルを使い、重要な処理には複数ブロックにまたがるクールダウンを実装し、過剰担保を要求し、状態変化後にプロトコルの健全性を検証すること。

### スマートコントラクトのセキュリティテストにはどのようなツールを使うべきか？

人気のツールには、静的解析のためのSlither、テストとファジングのためのFoundry、バイトコード解析のためのMythril、デプロイ前の包括的な脆弱性スキャンのためのSecurifyなどがある。