スマートコントラクト監査とは？監査レポートの見方と確認ポイント

仮想通貨やDeFiのサービス紹介で「第三者監査済み」「スマートコントラクトは監査を受けた」と書かれていると、安全だと感じるかもしれません。しかし、監査済みという言葉だけでは、どのプログラムを、いつ、どこまで調べ、見つかった問題が修正されたのかは分かりません。

この記事では、初めて監査報告書を見る人が、英語の長いPDFでも何を先に探せばよいかを解説します。技術者としてコードを評価することを目的にせず、架空のサービス「MDR Vault」の監査報告書を一緒に読む形で、確認できる事実と確認できない事実を分けます。

先に結論：監査済みより「範囲・時点・指摘・対応」を見る

スマートコントラクトの監査は、外部の専門家などがコードや設計を点検し、欠陥や脆弱性を探す作業です。監査があることは一つの判断材料になりますが、すべての問題を発見した証拠ではありません。Ethereum公式のセキュリティ解説も、監査を万能な解決策として扱わないよう説明しています。

読者が最初に確かめたいのは、監査報告書の発行元と日付、対象のコード、発見された問題と重要度、開発者がどう対応したか、現在動いているコードが監査時と同じかという五つです。報告書が本物でも、そこに含まれない部分や後から変更された部分には別の検討が必要です。

監査を読む前の前提として、スマートコントラクトはブロックチェーン上で動くプログラムで、資産を移す条件などをコードで定めるものです。取引所が預かった資産と同じ仕組みではなく、利用者の承認や操作でコードが呼び出される場合があります。スマートコントラクトの基本は別記事で説明しています。

監査が調べる対象は「サービスのすべて」ではない

一つの暗号資産サービスには、ウェブサイト、ウォレット接続、スマートコントラクト、管理者の鍵、価格データ、外部システム、運営者の手続きなど多くの要素があります。監査報告書の対象が「資金を預けるコントラクト1個」なら、サイト全体、運営会社の財務、鍵管理、外部オラクルの正確さを同時に保証するものではありません。

たとえば「MDR Vault」という架空のサービスが、ユーザーのトークンを預かるVault.sol、利用者の権限を管理するRole.sol、報酬額を計算するRewards.solという三つの部品を使うとします。このうち監査対象がVault.solとRole.solだけなら、Rewards.solはその監査で点検されたと断定できません。別監査やテストがあるかは独立に調べる必要があります。

監査対象の一覧はScope、Contracts reviewed、Files in scopeなどの項目に置かれることがあります。さらに対象のリポジトリURLやコミットIDが示されていれば、どの時点のソースコードか特定する手掛かりになります。コミットIDは、プログラムの特定の版を区別するための識別子です。数字の大小に安全性の意味があるわけではありません。

監査日と公開日は同じではない

監査チームが2026年1月にコードを確認し、報告書が3月に公開され、サービスが7月に機能追加したという架空の時系列を考えます。監査日が1月なら、7月の追加コードが当初の監査に含まれない可能性があります。報告書の掲載日を見ただけでは、現在の稼働コードまで検証されたとは分かりません。

プロジェクトが複数回監査を受けていることもあります。古い監査報告書がトップページに残されている場合、新版の報告が公開されていないか、コードの更新履歴が追えるかを確認します。資料が見つからない場合、読者が独自に安全性を証明することは難しくなります。

架空の監査報告書を実際に読む練習

次は実在の監査ではなく、読み方を理解するために作った「MDR Vault」の想定例です。報告書冒頭には、監査チーム、調査期間、コードのバージョン、対象機能が記載されていたとします。発見事項は3件あり、そのうち1件はCritical、1件はMedium、1件はInformationalと書かれています。

この表だけを見て「Criticalが1件あるから絶対危険」「修正と書かれたから絶対安全」とは判断できません。第一に、Severityの区分や意味は監査チームによって異なります。第二に、修正内容が実際に検証されたか、運用中のコードに反映されたかを見る必要があります。第三に、Mediumとして残したものが利用者にとって重要な条件かもしれません。

CriticalやHighは何を表す？

一般に重大度は、問題が起きた場合の影響や悪用されやすさなどを踏まえて評価されます。Critical、High、Medium、Low、Informationalのような段階を使う監査会社がありますが、共通の絶対基準ではありません。報告書の冒頭にあるSeverity definitionsを読み、その会社がどう分類しているか確認しましょう。

同じ「資金を動かせる」問題でも、誰でも即時実行できるのか、特別な管理権限や複雑な条件が必要なのかで深刻さが変わり得ます。利用者向けの説明には「影響を受ける資金」「必要な条件」「修正の範囲」を探します。知識が足りず判断できない場合は、無理に独自採点するより、監査結果の公開状況や公式の追加説明を確認するほうが適切です。

Statusの言葉を読む：ResolvedとAcknowledgedは違う

監査で問題が見つかったあと、開発側の対応には複数の状態があります。Resolvedは修正されたことを示す文脈で使われますが、修正方法を監査人が再確認したかは報告書次第です。Mitigatedは影響を緩和する対策、Acknowledgedは問題を認識したがそのまま残した状態などを指すことがあります。用語の厳密な定義は文書ごとに確認します。

架空のMDR-01で、開発者が権限チェックを追加し、監査側がその修正コミットを再レビューしたとしましょう。この場合は、単に開発者が「対応済み」と投稿した場合より確認できる根拠が増えます。それでも修正箇所が別の問題を生まないか、他の未監査コードが影響しないかまで一切保証するものではありません。

MDR-02について「運営側が相場を監視するからコード変更なし」と記載されているなら、監査報告書から分かるのは、問題を認識し、ある運用策を説明したという事実です。市場急変時に対応が間に合うか、担当者が常に対応できるかは別の問いです。市場で約定価格が成立する過程は仮想通貨の価格が決まる仕組みで説明しています。市場の約定価格と、サービスが判定に使う参照価格は同じとは限りません。

実際に動いているコントラクトと監査対象は同じ？

ここは初心者が見逃しやすい重要点です。スマートコントラクトには、後から機能の実装先を切り替えられる「アップグレード可能な構成」があります。利用者がアクセスするアドレスが同じでも、背後の処理内容を変更できる設計があるため、「アドレスが同じ＝監査時のコードも同じ」とは限りません。

監査報告書に示されたコードのコミット、現在の公開ソース、実際のデプロイ先のコントラクトアドレス、管理者やアップグレード権限を照合する必要があります。ただし一般利用者がこれを完全に検証するのは難しいため、公式が現在の実装・監査適用範囲を明示しているかが判断材料となります。コントラクトのコードや取引履歴を調べる入口はブロックエクスプローラーの読み方で紹介しています。

また、監査が完了したあとに一部の権限が変更された可能性もあります。誰が資産を停止できるのか、どの条件でアップグレードできるのか、変更までに待機時間があるのか、といった情報は利用者の資産に関わります。投票で決める仕組みがあっても、承認した提案を誰が執行するかは別の場合があります。

レポートが本物かどうかを確認する

検索上位にあるPDFやSNSの画像が、必ずしも正式な監査報告書とは限りません。プロジェクトの公式サイトにリンクがあるかを見るだけでなく、監査会社自身の公開ページやリポジトリから該当報告書を確認できるか調べます。報告書名、対象プロジェクト名、日付、コードのバージョンが一致するかも確かめます。

一方、監査会社のサイトに掲載されているからといって、プロジェクト全体の安全が保証されるわけでもありません。正式に受けた監査でも、対象外の箇所、監査後のコード変更、外部システムの障害、運営者の不正などのリスクは残ります。OpenZeppelinの監査準備ガイドは、監査の成果物として指摘事項の報告書を作り、開発側がその問題に対処する流れを説明しています。

読むのが難しいPDFならこの順番で探す

最初にPDFの目次からExecutive SummaryまたはSummaryへ進み、監査の全体像を把握します。次にScopeで何が対象だったか確認します。さらにFindingsに移って重大な指摘を読み、開発者の対応と再検証の有無を調べます。最後にDisclaimerやLimitationsを読んで、調査範囲の制約を確認します。全文のソースコードを解読できなくても、この順なら最低限の評価材料を集められます。

ページに「No critical issues」とあっても、MediumやLowの指摘がないとは限りません。また調査対象がごく一部なら重大な問題が見つからなかった事実の意味も限定されます。Findingsの件数そのものより、対象範囲、残る問題の性質、現在の稼働状態をあわせて読みましょう。

監査報告書では分からない三つのこと

一つ目は将来の市場価格です。監査は技術上の安全性などを調べるものなので、トークンが値上がりするか、流動性が確保されるかを約束しません。二つ目は運営者の約束が必ず守られるかです。管理権限を持つ人が適切に行動するかどうかはコードのレビューだけでは測れません。

三つ目は秘密情報やウェブサイトの安全性です。利用者が偽サイトに接続して不正な署名をしたり、ウォレットの復元フレーズを入力したりする被害は、コントラクトの監査とは別に起こり得ます。接続・署名・承認の違いを理解しておくと、監査済みの名称を悪用した誘導にも対応しやすくなります。

架空の二つのプロジェクトを比べるとき

Aプロジェクトは「監査済み」と大きく書いてあるものの、対象コードや報告書へのリンクがないとします。Bプロジェクトは監査報告書を公開し、対象コミット、未解決の指摘、修正予定、現在のデプロイ情報が整理されています。Bのほうが読者に確認可能な情報は多いですが、だからBが絶対安全という結論にもなりません。

Aは情報不足で評価しにくい、Bは評価の材料が公開されている、という違いを認識することが第一歩です。またBに未解決の重大な指摘があるなら、透明性が高いことと利用するのが適切かは別の問題です。情報が分からない場面では、資産を動かさず学習や公式資料の確認に留める選択もできます。

監査報告書の「対象版」と現在版をどう照合する？

架空のMDR Vaultに、監査対象コードのコミットがAAA、現在の公式リポジトリのコミットがBBBと記載されている場合を考えます。AAAとBBBが異なることだけでは、危険な改変があったとは言えません。監査後に説明文だけを修正した可能性もあれば、資金を動かす権限の部分を変更した可能性もあります。差分の内容と、新しい部分について追加監査が行われたかを見る必要があります。

さらにアップグレード可能な構成では、利用者が接続する入口のアドレスと、処理を実行する実装コードのアドレスが別の場合があります。入口のアドレスが以前と同じでも、実装先が差し替えられればコードの働きは変わり得ます。監査レポート内で両方の識別情報が示されているか、現在のデプロイ情報を運営元がどう説明しているかを確認するのが実用的です。

ただし、一般利用者がコード差分の安全性を独力で断定する必要はありません。公開された資料を突き合わせても対象版を確認できないときは、その不明点を残したまま「監査済み」の宣伝を信用しないという判断ができます。サポートへ問い合わせるなら「現行コントラクトの実装アドレス」「その版を対象とした監査報告書」「未解決の指摘への対応」の三点を具体的に質問すると、抽象的な安全宣言より情報を得やすくなります。

よくある質問

監査済みならハッキングされませんか？

いいえ。監査はすべての欠陥を見つける保証ではありません。対象外の機能、監査後の変更、外部依存先の問題などによるリスクは残ります。

Criticalが0件なら問題なしですか？

そうとは限りません。重大度の基準、監査対象、残るMediumなどの指摘を確認します。そもそも対象外のコードに問題がないという意味ではありません。

Resolvedと書かれていれば確認は終わりですか？

報告書で誰が修正を確認したか、対象コードが現在の稼働コードに反映されているかまで見る必要があります。状態の言葉だけでは十分ではありません。

監査会社の名前が書かれたPDFは信じてよいですか？

発行元の公式ページから存在と版を確かめます。画像やコピーだけでは真正性を判断できません。正式な報告書でも安全保証ではありません。

まとめ：監査は安全の証明書ではなく、問題を探した記録

監査報告書を読むときは、発行元・対象コード・時点・指摘の内容・修正状況を一組で確認します。「調べられたこと」と「今の利用者が知りたいこと」が一致しているかが最も大切です。監査済みの表示だけで資産を預ける判断をせず、分からない点はそのまま残る不確実性として扱いましょう。