TL;DR

  • 契約レイヤーにおける損失の大部分は、再入（reentrancy）、オラクル操作、アクセス制御の失敗、算術および検証エラー、そして記述通りに動作する欠陥のあるビジネスロジックといった、ごく少数の繰り返し発生する脆弱性クラスに起因しています。どのクラスにも有名な被害事例が結びついており、業界はそれを通じてこれらの名称を定着させてきました。
  • 監査では、専門家による作業時間の予算の範囲内で、既知の脆弱性クラスやチームが表明した意図に照らして、コードの固定されたスナップショットを検証します。それ以外のほぼすべて、すなわち経済性、オラクル、ガバナンス、運用、依存関係、将来性などは、検証範囲外となります。監査レポートの「範囲」セクションを読むことは、その「バッジ」を読むよりも有益です。
  • 損失の分布は、監査が対象外とする要素――監査後の変更、除外されたコンポーネント、プロトコル間の相互作用、侵害された運用や経済設計――に加え、サンプリングでは必然的に見落とされる残存バグに起因するからです。「監査済みでありながらハッキングされた」事例のリストは、一つのジャンルを形成するほど長いのです。
  • 逆順で読むことです。まず範囲と前提条件、次に未解決の所見、3番目にデプロイされたコミットとの整合性、そして最後に（もしあれば）マーケティング要約です。レポートはプロセスの品質に関する証拠であり、何が「対象外」だったかを示す地図として読むのが最も有益です。
1つのブロックで

監査とは、特定の前提条件の下で特定のコードに対して専門家が行う、時間制限のあるレビューです。監査はリスクを低減しますが、設計上、経済的攻撃、オラクルの信頼性、アップグレードのガバナンス、コンパイラのバグ、オフチェーンインフラ、およびレポートが署名された後に変更されるあらゆる事象といった、失敗のカテゴリー全体を見逃してしまいます。 損失の構図は変化した。2026年上半期、スマートコントラクトの悪用はインシデントの約60％を占めたが、損失に占める割合はごくわずかだった。一方、インフラや鍵の侵害はインシデントの約15％を占めたが、損失の76％を占めた。コードを破ることは難しくなったが、それを取り巻く運用体制はそのペースに追いついていない。 監査済みのプロトコルでも失敗は起きる。Cetusでは2025年5月、複数の監査で見落とされていた単一の欠陥のあるオー…

スマートコントラクトでは、実際には何が問題を引き起こすのか？

簡単な回答

契約レイヤーにおける損失の大部分は、再入（reentrancy）、オラクル操作、アクセス制御の失敗、算術および検証エラー、そして記述通りに動作する欠陥のあるビジネスロジックといった、ごく少数の繰り返し発生する脆弱性クラスに起因しています。どのクラスにも有名な被害事例が結びついており、業界はそれを通じてこれらの名称を定着させてきました。

再入（Reentrancy）は典型的な例です。コントラクトが自身の状態を更新する前に外部アドレスへ価値を送信すると、受信側（これもコントラクト）が更新が反映される前にコールバックを行い、ループ状態で資産を吸い上げてしまいます。2016年のDAOハッキング事件（当時約6,000万ドルの被害）はこの問題の典型例として確立され、イーサリアムを二分する結果となりました。 10年経った今でも再入攻撃は発生しており、時には奇妙な形で現れることもあります。2023年のCurveインシデント（プール全体でおよそ7,000万ドルの被害）は、Vyperコンパイラ特定のバージョン内部における再入ガードの不備に起因していました。つまり、ソースコード上のロジックは妥当であったにもかかわらず、コンパイルの結果、不適切なバイトコードが生成されてしまったのです。ソースコードを検証していた監査人は、この問題を見逃してしまいました。

オラクル操作は入力データを標的とする。価格フィードを信頼するスマートコントラクトは、価格を歪めることで被害に遭う可能性があり、フラッシュローンは単一のアトミックトランザクション内でその歪みを引き起こす資金を供給する。2022年に約1億1400万ドルの被害が出たMango Marketsの事例は典型的なケースであり、その仕組みは依然として常套手段となっている。このクラスターの柱となる項目では、そのパターンを詳細に分析している。

アクセス制御の失敗は、特に恥ずかしい類の脆弱性だ。修飾子が欠落しているために誰でも呼び出せる関数、開放されたままの初期化子、デプロイキーによって保持された特権ロールなどがこれにあたる。2017年のParityウォレットのインシデント（数千万が盗まれ、1億5000万ドル以上が永久に凍結された）は、いずれもこの問題に起因する。

より安全な言語が普及しているにもかかわらず、算術演算や検証のエラーは依然として発生している。Sui上で最大のDEXであるCetusは、2025年5月に約2億2300万ドルの被害を受けた。これは、あるオーバーフローチェックが誤った定数と比較されたため、細工された値が検証を通過し、流動性の計算を破綻させたことが原因である。 インシデントの事後分析によると、当該コントラクトは複数回にわたり監査を受けていた。事後の対応は記録として重要である：約1億6200万ドルが、バリデーターによる協調的な措置を通じて凍結され、コミュニティの投票により回収・補償プロセスへと移管された。悪用された総額と、凍結または回収プロセスに回された金額は別々に報告されるべきであり、最終的な純損失額は、仮定ではなく、日付入りの会計記録が存在して初めて明示されるべきである。

最後に、純粋な論理エラーについて：コンパイルされ、テストに合格し、記述通りに動作するものの、誤った結果を出してしまうコードです。2023年にEuler Financeが被った1億9700万ドルの損失は、寄付メカニズムと清算ロジックが組み合わさったもので、個々のコード行だけではその問題点が明らかではありませんでした。この種のエラーを検出するスキャナーは存在しません。なぜなら、アイデアそのものを除けば、技術的に破損している部分は何もないからです。

監査では実際に何が検証され、設計上、範囲外となるものは何でしょうか？

簡単な回答

監査では、専門家による作業時間の予算の範囲内で、既知の脆弱性クラスやチームが表明した意図に照らして、コードの固定されたスナップショットを検証します。それ以外のほぼすべて、すなわち経済性、オラクル、ガバナンス、運用、依存関係、将来性などは、検証範囲外となります。監査レポートの「範囲」セクションを読むことは、その「バッジ」を読むよりも有益です。

本格的な監査では、経験豊富な研究者による手動レビュー、静的解析、仕様書に基づくテストが行われ、発見事項を深刻度別に評価したレポートが作成されます。チームの仕様が間違っている場合、監査は誤った基準に対してコードをチェックすることになります。仕様書に明記されていない部分については、監査担当者が意図を推測します。これらはいずれも、見落としが生じる静かな要因となります。

構造的な限界については、明確に列挙しておく価値がある。監査は特定の時点におけるものであり、レビュー対象となったコミットのみが検証され、3か月後にリリースされたアップグレードは対象外となる。また、範囲が限定されており、周辺的なコントラクト、デプロイメントスクリプト、管理ツール、統合機能などは、予算の都合で頻繁に除外される。 また、仮定に満ちています。レポートでは、通常、誠実なオラクル、健全なトークン、信頼できる管理用キーを前提としていますが、これらはまさに攻撃者が決して共有しようとしない仮定そのものです。経済的なレビューを別途購入しない限り、経済的な側面は無視されます。操作下での支払能力、インセンティブの失敗、他の稼働中のプロトコルとの有害な組み合わせ可能性は、別の分野に属します。さらに、スタックの深さが浅いという問題もあります。コンパイラ、仮想マシン、およびその下層にあるノードソフトウェアは、ほとんどの場合、調査範囲に含まれません。しかし、Curveのインシデントはまさにその部分に起因していました。

時間的プレッシャーがこれらすべてをさらに悪化させます。監査会社は、攻撃者がデプロイ後に無制限の時間、ライブ状態、そしてチェーン全体のコンポーザビリティを手段として利用できる探索空間からサンプルを抽出するに過ぎません。この非対称性は構造的なものです。レビュー担当者は、固定された契約範囲内であらゆることを考えなければなりませんが、攻撃者には、誰もが見落としたたった一つの要素さえあれば、永遠に攻撃を続けられるのです。

これらは決して監査そのものを否定する議論ではありません。これは、「監査済み」という表記を「制約下にある専門家によるサンプリング」と解釈すべきだという主張であり、それによってその認証が担える範囲を適切に評価するものです。

Diagram of smart contract audit scope showing reviewed code at the centre surrounded by out-of-scope risks including oracles, upgrades, governance, economics, compiler and operations
図1. スマートコントラクト監査の対象範囲と、その枠外にある脆弱性の領域。

なぜ監査済みのプロトコルは依然として数億単位の損失を被るのか？

簡単な回答

損失の分布は、監査が対象外とする要素――監査後の変更、除外されたコンポーネント、プロトコル間の相互作用、侵害された運用や経済設計――に加え、サンプリングでは必然的に見落とされる残存バグに起因するからです。「監査済みでありながらハッキングされた」事例のリストは、一つのジャンルを形成するほど長いのです。

最近のデータにより、この傾向が定量的に明らかになった。 TRM Labsの集計によると、2026年上半期には過去最多となる207件のインシデントが発生したが、総損失額は10億ドル未満で、前年同期比58％減となった。スマートコントラクトの悪用はインシデント全体の約60％を占めたが、損失額に占める割合はごくわずかであった。一方、インフラへの攻撃、鍵、署名環境、運用アクセスなどは、インシデント全体の約15％を占めるに過ぎなかったが、損失額の約76％を占めた。 2025年の数値は、この傾向をより過酷な形で物語っていた。約34億ドルが盗まれ、その大半は15億ドル規模のBybit盗難事件によるもので、これは契約そのものではなく、署名ワークフローを標的とした攻撃であった。攻撃者は最も脆弱な層へと移行しており、長年にわたる監査の結果、運用面と比較して契約のバグを悪用することは相対的に困難になっている。

監査済みのコード自体が機能不全に陥った場合、その理由は通常、前述の分類によって説明される。Cetus：珍しい言語コンテキストにおける検証上の微妙な点であり、過去に複数の企業で同様の事例が見られたが、悪用された価値の大部分は後に凍結され、被害者への返還に充てられた。Euler：各機能間で生じた新たなロジックであり、各機能は局所的には正しかった。 Curve：ソースコードの直下のレイヤー。これら以外にも、レビュー後にリリースされたアップグレード、完璧な契約にもかかわらず不注意に扱われた管理者キー、そしてプロトコルのモデルが想定していなかったトークンや市場との相互作用などから、小規模なインシデントが絶え間なく発生している。

また、希少性による経済的要因もあります。トップクラスのレビュー能力は限られており高価であるため、プロジェクトは、本来3回の監査が必要なリスクがあるにもかかわらず1回の監査のみでリリースしたり、納期を重視して選ばれた企業によるマーケティング向けのレビューのみでリリースしたりすることがあります。監査バッジは、こうしたあらゆるばらつきを1つの言葉に凝縮してしまいます。そのため、洗練された投資家はレポートを読み、コミットハッシュとデプロイされた内容を照合し、監査済みのプロトコルに対する未監査のアップグレードを、未監査のコードとして扱うのです。

Chart comparing smart contract exploits at sixty percent of incidents with a small share of losses against infrastructure and key compromises at fifteen percent of incidents and seventy-six percent of value, per TRM Labs
図2. 2026年上半期：攻撃種別ごとのインシデントシェアと価値シェアの比較。

監査を超えて、本格的なセキュリティスタックとはどのようなものか？

簡潔な答え：多層化され、失敗を前提とした構成です。具体的には、複数の独立したレビュー、効果的な箇所での形式手法やファジング、継続的な監視、経済的サーキットブレーカー、タイムロックされた変更、バグ報奨金制度、そして万が一侵入された際の事前の訓練済み対応計画などです。各層が異なる見落としパターンを捕捉する点が、多層化の真の意義です。

冗長なレビューは、レビュー担当者固有のギャップを捕捉します。異なる企業、異なる手法、異なる盲点に加え、同じコードに対して数百人の独立した研究者を投入するコンテストプラットフォームも活用します。 形式検証は、数学的モデルに対して特定の性質、保存則、アクセス不変条件を証明します。その限界は、誰かが明示的に定式化した性質しか検証できない点にあります。ファジングと不変条件テストは、状態空間を機械的に徹底的に検証し、検証の境界領域である「ケトゥス級」の脆弱性検出に優れています。これらは十分に低コストであるため、導入されていないこと自体がリスクのシグナルとなっています。

バグ報奨金は市場を変える：リスク価値に見合った適切な規模の常設の報奨金制度は、見落としを発見した研究者に、犯罪と競合し得る合法的な報酬をもたらす。最大のDeFi報奨金は数百万を支払ってきたが、そのコストに見合うだけの価値があった。

実行時防御は、予防がデプロイ時点で終わることを前提としています。モニタリングはメモプールや状態を監視して攻撃の兆候を探し、サーキットブレーカーはブロックごとの流出額を制限したり、異常時に一時停止したりします。アップグレードやパラメータ変更に対するタイムロックは、ガバナンスで承認された内容が本番環境に反映される前に、世界中が数日間かけて検証する時間を確保し、密かな変更を公的な変更へと転換します。レート制限は、総流出額を部分的な流出額に変換します。これは、当アカデミーのカストディに関する記事全体に貫かれている「影響範囲の制限」という哲学と同じものです。

また、損失データが示すように、運用上のリスクはコード上のリスクを上回っているため、コントラクトを管理する鍵には、コントラクトと同等の厳格さが求められる。分散型署名権限、クォーラムによる承認、独立したデバイス上での明確な署名、そして単独のオペレーターがトレジャリー・コントラクトを単独でアップグレードできない仕組みだ。Bybitのインシデントは、腐敗しうるワークフローを通じて管理される完璧なコントラクトは、裏口のある完璧なコントラクトに過ぎないという、絶え間ない教訓である。

ユーザーや資金配分者にとって、チェックリストは以下の質問に集約されます。デプロイされたコミットに対して、独立したレビューが何回行われるか。管理キーにはどのような権限があり、どの程度の遅延とクォーラムの下で実行されるか。何がプロトコルを経済的に破綻させるのか、そしてチームはその分析を公開しているか。報奨金はいくらか。一時停止計画は何か。公開文書でこれらの質問に答えるプロトコルは、そのセキュリティ文化を伝えています。バッジで答えるプロトコルも、また別のことを伝えているのです。

専門家は監査報告書をどのように読むべきか？

簡単な回答

逆順で読むことです。まず範囲と前提条件、次に未解決の所見、3番目にデプロイされたコミットとの整合性、そして最後に（もしあれば）マーケティング要約です。レポートはプロセスの品質に関する証拠であり、何が「対象外」だったかを示す地図として読むのが最も有益です。

まずは範囲から始めましょう。どの契約か、どのコミットか、何が除外されたか、そしてデプロイされたバイトコードはレビューされたコードと一致しているか。ブロックエクスプローラーを使えば検証は容易であり、不一致は日常的に確認すべきほど頻繁に発生します。コミットAの監査は、コミットBについては何も語っていません。

前提条件を攻撃対象領域のリストとして読み解く。「管理者は誠実であると仮定する」とは、管理者キーの侵害が評価すべきリスクであることを意味する。「Oracleの挙動は範囲外」とは、Mangoパターンが検証対象外であることを意味する。明記された前提条件の一つひとつが、レビューが停止した境界であり、境界こそが攻撃者が狙う場所である。

発見事項は、その数よりも対応状況によって評価すべきです。12件の重大な問題が解決されたレポートは、熱心なチームと徹底したレビューアを反映している可能性があります。一方、問題のないレポートは、表面的な合格に過ぎない場合もあります。懸念すべきパターンは、問題が認識されながらもそのままリリースされた場合、あるいは監査人が再レビューを行っていない方法で修正された場合です。修正後の再監査が行われたかどうかを確認してください。修正によって新たに生じたバグは、繰り返し発生する典型的な問題です。

最後に、レポートを時間軸に位置づけてください。レポートはいつ作成されたものか、それ以来いくつのアップグレードがリリースされたか、そしてプロトコルの変更履歴が「変更されたコードは未監査のコードである」という原則を遵守しているかを確認してください。活発に開発が進められているプロトコルにとって、重要なのは単一の文書ではなく、セキュリティパイプライン、リリースごとのレビュー、常設の報奨金制度、モニタリングといった一連のプロセスです。数年前の1つの優れたレポートは単なる「遺物」に過ぎず、遺物は稼働中のシステムを保護することはできません。

要点を整理すると、監査は必要であり、有益ではあるが不十分であり、監査を依頼する専門家たちも同様の見解を示すでしょう。監査の真の成果は「未知の要素の低減」であり、未知の要素は管理されるものであって、決して排除されるものではありません。

よくある質問

監査済みのプロトコルは安全に使用できますか？

より安全ですが、誤差の幅は大きいです。監査を行うことで、既知の脆弱性カテゴリがレビュー対象のコードに残存する可能性は低くなります。しかし、経済的な設計、オラクル、アップグレード、運用、そして未発見の脆弱性カテゴリについては考慮されていません。最近の被害データによると、盗まれた価値の大部分は現在、これらの「抜け穴」を通じて流出しています。監査は、管理者キーのポリシー、タイムロック、報奨金の額、監視、実績などと同様に、判断材料の一つとして扱うべきです。

なぜ、発見すべきものがなくなるまで監査を続けないのですか？

なぜなら、レビューは予算の制約下で事実上無限の探索空間からサンプルを抽出するのみであるのに対し、攻撃者は稼働中の状態に対して無期限に探索を行うからです。 レビューを増やしても、残存リスクは逓減するものの縮小し続けます。リスクをゼロにすることはできず、監査が構造的に見落としている脆弱性クラス、将来の変更、新たに生じるコンポーザビリティ、侵害されたオペレーターなどは、レビュー担当者の作業時間を増やしても縮小しません。そのため、成熟したスタックでは、5回目の同一の監査を行う代わりに、バウンティ、ファジング、監視、および影響範囲の制限に追加の予算を充てているのです。

監査と形式検証の違いは何ですか？

監査とは専門家によるレビューであり、人間とツールが問題を探し出すものです。形式検証とは、コードがモデル下で明示的に規定された性質を満たしていることを数学的に証明することです。検証は適用可能な範囲においてより強力ですが、その有効性は性質とモデルの質に依存します。明示されていない性質や誤った仕様を含む契約であっても、形式的には完全に正しいと証明されていても、形式検証では失敗とみなされます。最も強力なパイプラインでは、最も重要なコンポーネントに対して、この両方を併用しています。

バグ報奨金は実際に効果があるのか？

インセンティブの論理は妥当であり、実績もそれを裏付けています。主要なプラットフォームは、運用中であればプロトコルに数億の損失をもたらしたであろう重大な不具合の発見に対し、数百万規模の報奨金を支払ってきました。報奨金の信頼性は、その金額よりも重要です。明確な対象範囲、迅速な優先順位付け、確実な支払い、そして研究者への支払いを怠った前歴がないこと。資金不足や敵対的な報奨金プログラムは、ないよりはましですが、研究者に他所で情報を売るよう促してしまうため、むしろ悪影響です。

ユーザーとして、プロトコルのセキュリティ文化を測る最良の指標は何でしょうか？

権限の扱いに注目してください。管理者キーで何ができるか、誰がそれを保持しているか、どのようなタイムロックやクォーラムが設定されているか、そしてそれが公開されているかどうかです。自らを可視的に制約し、アップグレードを遅らせ、署名を分散させ、経済分析を公開し、報奨金プログラムに資金を投入しているチームこそが、その文化を示しているのです。バッジの数は、ページ上で最も参考にならない数値です。

出典および参考文献

この記事の主な参考文献（2026年7月時点）。変動の激しい数値については、四半期ごとの見直しごとに再確認を行っています。

簡単なクイズ: 定着しましたか?

基本的な事項を確認するためのいくつかの質問がありました。解説付きの解答が続きますが、あなたの将来のポートフォリオを除いて誰もあなたを採点しません。

問題 1/5
スマートコントラクトの監査とは、正確には何でしょうか？

これは役に立ちましたか?