スマートコントラクトのセキュリティが通常のソフトウェアのセキュリティと異なるのはなぜですか？
スマートコントラクトのセキュリティがほかと異なるのは、コードが公開され、多くの場合は資金を直接管理し、通常はデプロイ後に変更できないためです。ウェブアプリの不具合なら一晩で修正できますが、コントラクトの不具合はコードを読む誰にでも発見でき、チームが目を覚ます前に悪用される可能性があります。Ethereum.orgは、スマートコントラクトの欠陥による損失を10億ドル超と推定し、初期の事例として2016年のDAOへのハッキングを挙げています。
架空の4人の開発スタジオ、ラークスパー・ラボを考えてみましょう。メンバーが資金を預け、自分の持ち分を引き出せるシンプルな共同貯蓄の仕組みを開発しています。開発者のコフィは、デプロイ前にレビュー用のメモを残します。『withdrawは送金してから残高を0にする。setFeeは誰でも呼び出せるが、後で制限する。チュートリアルに載っていた古いバージョンのコンパイラを使用。報酬トークンの価格は、小規模な取引プール1つから取得。テスト：入金＋出金を手動で1回試し、動作した』。どの項目も、既知の脆弱性の種類に当てはまります。
スマートコントラクトで特によく見られる脆弱性は何ですか？
スマートコントラクトで特に多い脆弱性は、アクセス制御の不備、価格オラクルの操作、ロジックの誤り、入力検証の欠如、再入可能性です。これらは2025年版のOWASPスマートコントラクトの脆弱性上位10項目に挙げられています。Ethereum.orgでも、同じ主要な分類が取り上げられています。
リエントランシー
コントラクトが自身の記録を更新する前に、資金を送ったり、別のコントラクトを呼び出したりします。悪意のある受取側は、古い残高がまだ表示されている間に再び呼び出しを行い、もう一度資金を引き出します。残高をゼロにする前に支払いを行うコフィの出金関数は、その典型です。一般的な対策は、最初に状態を更新し、ほかのコントラクトとのやり取りを最後に行うことです。これはよく、チェック・エフェクト・インタラクションと呼ばれます。
アクセス制御
誰でも呼び出せる重要な関数です。コフィの公開関数setFeeでは、見知らぬ人でも手数料を変更できてしまいます。Ethereum.orgでは、所有者の役割、役割に基づくアクセス制御、複数署名による承認といった仕組みを説明しています。
整数のオーバーフローとアンダーフロー
計算結果が上限を超えて折り返され、ゼロ未満の残高が巨大な数値になる現象です。Ethereum.orgによると、Solidity 0.8.0以降では標準でこの計算を拒否しますが、古いコードには明示的なチェックが必要です。コフィが古いコンパイラを使っていることが重要なのは、このためです。
オラクルの不正操作
攻撃者が価格を動かせる、流動性の低い単一の市場から価格を取得することです。攻撃には、1回のトランザクション内で借り入れと返済を行うフラッシュローンがよく使われます。堅牢な設計では、分散型オラクルや時間平均価格を使います。
論理と検証の誤り
意図した設計に合っていないルールや、金額がゼロの場合や想定外の住所など、一度もチェックされない入力です。
チームではスマートコントラクトをどのようにテスト・監査しますか？
単一の方法ですべてを検出することはできないため、チームは複数の段階でスマートコントラクトをテスト・監査します。自動テスト、解析ツール、テストネットワークへの配置、独立したレビューを行い、多額の資産を扱うコントラクトでは、外部監査と脆弱性報奨金制度も利用します。
1. 単体テストとプロパティテスト
すべての関数について、受信側が呼び出し元を再度呼び出す場合など、悪意のある動作も含めてテストを作成してください。ファジングでは、数千ものランダムな入力を自動的に試します。
2. 静的解析
Ethereum.orgでは、コードを走査して既知の危険なパターンを検出するツールとして、Slither、Mythril、Aderynなどを挙げています。
3. ネットワークをテストします
メインネットの前に、公開テストネットにデプロイしてください。Ethereum.orgは、アプリケーションとコントラクトの開発にSepoliaを推奨しています。テストネットのイーサは現実の価値を持たないことを前提としているため、ミスをしても費用はかかりません。
4. 査読と監査済みライブラリ
バージョン管理を行い、変更のたびに独立した確認担当者によるレビューを受けます。アクセス制御を一から実装するのではなく、OpenZeppelin Contractsなど、十分にレビューされたライブラリを使います。
5. 監査、報奨金制度、監視
独立した第三者による監査は検証を強化しますが、ethereum.orgが指摘するように、すべてのバグを見つけられるわけではありません。残るリスクには、バグ報奨金制度、緊急停止機能、イベント監視で対応します。
セキュリティレビューには、不十分な例と改善した例でどのような違いがありますか？
不十分なレビュー：「入金と出金を手動でテスト済みです。問題なく動作し、デプロイ可能です。」正常系のテストでわかるのは、正直な利用者に対してコントラクトが機能することです。しかし、攻撃者はまさにそのような利用者ではありません。
改善したレビュー：再入可能性：withdrawは送金前に残高をゼロにするようになり、悪意のある受信側コントラクトを使って再呼び出しを試みるテストもあります。アクセス制御：setFeeは、監査済みライブラリの所有者ロールのみに制限され、権限のない第三者からの呼び出しが失敗することをテストします。コンパイラ：現行の0.8系バージョンに更新し、オーバーフローチェックを有効にしています。オラクル：単一プールの価格を分散型の価格フィードに置き換え、急変に対する妥当性確認の制限も設けています。テスト：単体テスト、ファジング、静的解析を実施し、すべての検出事項を説明します。その後、Sepoliaで2週間、同僚に不具合や脆弱性を探してもらいます。実際の資金を受け入れる前に外部監査を予約済みです。
スマートコントラクトのセキュリティでよくある間違いは何ですか？
最も多い間違いは、呼び出し元がすべて正直であるかのように、正常系だけをテストすることです。ほかにも、後で制限するつもりで管理機能を開放しておく、古いコンパイラを使うチュートリアルのコードをコピーする、1つの価格情報源だけを信じる、監査を保証とみなす、テストネットでの検証を省く、一時停止や更新の計画なしにデプロイする、といった間違いがあります。
このレッスンはTosheo.aiの中でどのように位置づけられていますか?
これは、ブロックチェーン講座のブロックチェーンカテゴリーに属するコード実習レッスンです。この無料ページでは、各手順を文章で説明します。実際のコントラクトのコードを確認・修正し、テスト用ネットワークでテストを実行する実習の完全版は、登録後に選べる任意のコード実習コースで提供します。基礎が初めての方は、スマートコントラクトの解説から始めてください。Tosheo.aiは全日制の集中講座でも、専門監査人の資格課程でもありません。また、ここにある内容はいずれも投資助言ではありません。実際の価値を持つ資産を扱うコントラクトには、専門家による監査が必要です。
出典と対象範囲
ethereum.org、スマートコントラクトのセキュリティ（確認日：19 October 2026） ↗