【入門編】スマートコントラクト手動監査におけるチェックリストの策定 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

こんにちは！スマートコントラクトの開発に挑戦されている皆さん、日々のコーディングお疲れ様です。「ブロックチェーンの世界は一度デプロイ（公開）したら書き換えられない」と聞いて、なんだか冷や汗をかいていませんか？

自動で脆弱性を見つけてくれるツール（SlitherやMythrilなど）も便利ですが、実はそれだけでは防げない「人間の勘違い」や「ビジネスロジックの隙」が原因で、億単位の暗号資産がハッカーに盗まれる事件が後を絶ちません。

今回は、自動ツールでは絶対に検知できない「スマートコントラクトの手動監査チェックリスト」について、私たちの身近にある「家の防犯」にたとえながら、一歩ずつ優しく紐解いていきましょう！

—

1. なぜ自動ツールだけでは不十分なの？（家の鍵の例え）

最新のセキュリティツールを入れたからといって、100%安心というわけではありません。これは、「頑丈なオートロックの玄関ドアをつけたのに、窓の鍵を全開にしたまま旅行に出かけるようなもの」です。

自動ツールは「コードの書き方に明らかなバグがないか」を見つけてくれますが、「このお金の引き出しルール、そもそも仕組みとして変じゃない？」という、人間のビジネスロジックの矛盾までは理解してくれません。だからこそ、人間の目でしっかりとチェックする「手動監査」が不可欠なんです。

—

2. 手動監査チェックリスト：3つの重要ポイント

それでは、実務で絶対に確認してほしい3つのポイントを、身近な例えと一緒に見ていきましょう！

ポイント①：アクセス制御の欠如（合鍵の管理ミス）

例え話： 家の合鍵を誰でも勝手に作れる状態で、リビングの真ん中にポンと置いておくような状態です。
脆弱性の中身： 「誰でもこの関数を呼べてしまう」状態になっていると、悪意ある人が勝手に管理者権限を奪ったり、他人の資金を動かしたりできてしまいます。

実際の危険なコード例

// 【危険なコード】誰でも呼べてしまう関数
address public owner;

function withdrawAll() public {
    // 誰が呼んでも送金されてしまう！
    payable(msg.sender).transfer(address(this).balance);
}

対策済みのコード例

// 【安全なコード】オーナーだけが呼べるように制限する
address public owner;

// オーナーだけを実行可能にする「鍵（修飾子）」
modifier onlyOwner() {
    require(msg.sender == owner, "Error: オーナーしか実行できません！");
    _; // 条件クリア後に元の処理を実行
}

function withdrawAll() public onlyOwner {
    // これならオーナー以外はアクセスできません
    payable(msg.sender).transfer(address(this).balance);
}

—

ポイント②：ビジネスロジックの不整合（自動販売機の釣り銭泥棒）

例え話： 自動販売機に100円を入れたあと、ボタン連打で1000円分のジュースと釣り銭が出てきてしまうような、計算やルールの矛盾です。
脆弱性の中身： 外部のコントラクトを呼び出す順番を間違えると、お金を引き出す処理が完了する前に何度も同じ関数を呼び出されてしまう「リエントランシー（再入可能性）攻撃」などがこれに該当します。

対策のポイント（Checks-Effects-Interactionsパターン）

お金のやり取りをする時は、必ず「①条件チェック -> ②内部データの更新 -> ③外部送金」の順番を守りましょう。

// 【安全な送金パターンの例】
mapping(address => uint256) public balances;

function withdraw(uint256 _amount) public {
    // 1. チェック：残高足りてる？
    require(balances[msg.sender] >= _amount, "Error: 残高不足です");

    // 2. 更新：先に自分の残高を減らす（重要！）
    balances[msg.sender] -= _amount;

    // 3. 相互作用：最後に相手にお金を送る
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success, "Error: 送金に失敗しました");
}

先にお金のデータを減らしておけば、万が一ハッカーが不正に割り込んできても、「もう残高がありません」と突っぱねることができます。

—

ポイント③：ガス制限とループ処理の罠（満員電車のパンク）

例え話： 10人乗りのエレベーターに、無理やり100人乗ろうとして途中で動かなくなってしまうような状態です。
脆弱性の中身： スマートコントラクトの処理には「ガス（手数料）」の上限があります。配列（リスト）の要素数がユーザーの増加とともに増えていく設計にしていると、ある日突然、処理が途中でストップして二度と動かなくなってしまいます。

対策のポイント

ユーザー全員のリストを一度のループ処理で回すようなコードは避け、必要に応じてデータを分割（ページネーション）して処理する設計にしましょう。

—

さいごに：一歩ずつ、確実に安全なコードへ

スマートコントラクトのセキュリティと聞くと、なんだか難しそうに感じるかもしれません。でも、基本は「もし自分が泥棒だったら、どこを突っ突くだろう？」という視点（悪意あるユーザーの目線）を持つことです。

今日ご紹介したチェックリストを、あなたの開発フローの「デプロイ前の最終関門」としてぜひ取り入れてみてください。焦らず一歩ずつ、堅牢なWeb3の世界を作っていきましょう！