「監査済み」と「監査で問題が見つからなかった」は同じことですか？
違う。「監査済み」は、プロジェクトが監査会社に依頼して報告書を作成させたことしか意味しない。その報告書には複数のCriticalやHigh等級の発見事項が記載されていることも十分あり得る——重要なのは、それらの発見事項がその後修正されたかどうかだ。5件のCriticalを記載しつつ全て再監査で確認されたFixedの報告書は、範囲が極端に狭く発見ゼロの報告書よりも、実は信頼できる場合が多い。前者は監査チームが実際に深く掘り下げたことを示し、後者は単に範囲設定が保守的すぎて問題を見つける機会自体がなかった可能性があるからだ。
監査の質を判断するには「通過したかどうか」という二元的なラベルではなく、何が発見され、その後どう処理されたかを見る必要がある。
なぜ同じ契約でも監査会社によって意見が異なることが多いのですか？
監査は本質的に専門的判断であり、ユニットテストのように「通れば通った」という機械的な検証ではない。同じコードでも、経験豊富な監査員は特定の境界条件（リエントランシー攻撃、整数オーバーフローなど）に特に注意を払う一方、異なる背景を持つ監査員は着目点が異なる——これが大規模なプロトコルが単一の報告書に頼らず、2社以上の独立した監査会社にそれぞれ依頼することが多い理由でもある。
これは監査に価値がないという意味ではなく、1つの報告書は「このチームが、この手法で、この期間内に」行った検査結果を表しているにすぎず、「この契約が絶対に安全である」という最終的な証明ではないことを示している。
バグバウンティ（脆弱性報奨金制度）は監査報告書の代替になりますか？
代替ではなく補完関係にある。監査は限られた時間内に固定チームが一度集中的に検査するものだ。バグバウンティは検査範囲をより広範なホワイトハッカーコミュニティに開放し、報奨金というインセンティブで継続的かつ長期的な監視と引き換えにする。監査は構造的・体系的な設計上の欠陥を見つけるのが得意で、バグバウンティは監査期間中には発生しなかった、特定のオンチェーン状態の組み合わせが必要なエッジケースをしばしば捉える。
成熟したプロジェクトは通常両方を併用する——まず監査で明らかな構造的問題を排除し、ローンチ後もバグバウンティを長期的な第二の防衛線として開放し続ける。監査を唯一かつ一度限りのセキュリティチェックとして扱うことはない。
技術的背景がなく、Severityの技術的詳細を理解できない場合、監査報告書が信頼できるかどうかを他にどう判断すればよいですか？
技術的な詳細を理解できなくても、いくつかの構造的なシグナルはまず確認できる。監査会社が業界で有名な独立機関か（プロジェクト自身が設立した関連会社ではないか）、報告書が公開されアクセス可能か（非公開の監査はそれ自体で信頼性が下がる）、Critical／High項目の修復状況が明確に表示されているか、それとも意図的に曖昧にされているか、監査日がプロジェクトの現在のコードバージョンより明らかに前になっていないか。
これらはSolidityを読める必要がなく、技術的な発見事項を一行ずつ確認するよりも、その報告書が「見せるために作られた」ものか「実際に使うために作られた」ものかを素早く見抜く手がかりになることが多い。
DeFiプロジェクトが「監査済み」を謳っているのを見ると、多くの人はそれを安全性の保証だと受け取ってしまうが、この結論そのものが最も重要なステップを飛ばしている——監査報告書には実際に何が書かれ、何が書かれていないのかという点だ。同じ報告書でも、読み方を知っている人はそこからプロジェクトの信頼性を判断できるが、知らない人には「PASSED」というラベルしか見えない。スマートコントラクト監査報告書の本当の価値を判断する鍵は、Scope（範囲）・Severity（重大度分類）・Findings（発見事項）という3つのセクションにある。
すべての監査報告書は冒頭にScopeセクションを設け、実際に検査した契約ファイル、バージョン、対応するコミットハッシュを明記する。このセクションは最も見落とされやすいが、監査が「意味を持つかどうか」を判断する最初の関門である。よくある問題は、監査報告書が固定したコミットハッシュが、プロジェクトが実際にデプロイした契約バージョンと完全に一致していないことだ——その間に「軽微な修正」であっても何らかのコード変更があれば、監査報告書の結論は現在稼働中の契約にはもはや適用されない。もう一つよくあるケースは、監査範囲がガバナンス契約やアップグレード機構など特定のモジュールを意図的に除外していることだ。プロジェクトが「監査済み」を強調するだけで範囲から何が除外されたかを開示しない場合、それ自体がさらに問うべきシグナルである。
監査の発見事項は通常Critical、High、Medium、Low、Informationalに分類されるが、この分類は客観的な物理法則ではなく、監査チームが「攻撃者が実際にどれだけ奪えるか」に基づいて下す専門的判断である。同じ脆弱性でも監査チームによって異なる重大度が付けられることがあり、保守的にエッジケースをすべて高く評価するチームもあれば、より緩やかなチームもある。報告書を見る際は、Criticalの総数だけを数えるより、それらのCriticalやHigh項目が最終的にプロジェクト側によって実際に修正されたか、それとも報告書公開後に音沙汰がないかを確認する方が価値がある。多くの監査報告書には修復状況（Fixed／Acknowledged／Won't Fix）が付記されており、AcknowledgedまたはWon't Fixとなっている高重大度項目は、プロジェクト側がリスクの存在を認識しながら対処しないことを選んだことを意味する——これは「見逃された」脆弱性よりも警戒に値する。なぜならそれは既に白日の下に晒されながら意図的に残された穴だからだ。
2021年8月のPoly Network事件は具体的な例である。Poly NetworkはEthereum、Binance Smart Chain、Polygonの3チェーンを接続するクロスチェーンプロトコルで、攻撃者はクロスチェーン呼び出し間の権限検証の欠陥を突いて、約6億1100万ドル相当の資産を一度に流出させた。これは当時のDeFi史上最大級の単一事件だった。事後分析によれば、原因はクロスチェーン契約呼び出し間のアクセス制御設計にあり、当初噂されていた単一キーパーの秘密鍵漏洩ではなかった。攻撃者は最終的に資金の大部分を返還したが、この事件が浮き彫りにした問題は今も残っている——ブリッジ契約間の権限検証は、監査の範囲設定や複雑さの見積もりにおいて特に見落とされやすい攻撃対象領域である。
修復状況フィールド自体も注意深く読む必要がある。「Fixed」は理想的には監査チームが再監査を行い、修正が新たな問題を introducing していないことを確認した状態を意味するが、一部のプロジェクトは監査チームによる再確認を経ずに自己申告で「修復済み」とするだけのこともあり、そうした未検証の自己申告修復は、再監査記録のある修復より明らかに信頼性が低い。もう一つよくある言葉のすり替えは「リスク緩和」を「リスク解決」として包装することだ——例えば元々の脆弱性にマルチシグやタイムロックを追加して攻撃のハードルを上げただけで、根本的なロジックの欠陥自体は修正されていないケースがある。この場合、脆弱性は依然として存在し、悪用の難易度が上がっただけである。
さらに、監査報告書は「監査時点」のコード状態しか反映していない。プロジェクトがその後に機能を追加したりロジックを変更したりしても、新たに追加された部分について再監査を受けていなければ、元の監査報告書が正直に保証できる範囲は縮み続けているにもかかわらず、「この部分は監査後に追加されたものだ」と自発的にユーザーに開示するプロジェクトはほとんどない。
次に「監査済み」を売りにしているプロジェクトを見かけたら、あと5分かけて3つのことを確認する価値がある。監査が固定したコミットハッシュが現在実際にデプロイされているものと一致するか、CriticalまたはHigh項目でAcknowledgedやWon't Fixとマークされたものがないか、そして監査日がプロジェクトの最新のコード更新より前ではなく後になっているかどうかだ。どれも大した時間はかからないが、「PASSEDのバッジを見て安心する」段階から「そのPASSEDが実際に何をカバーし、何をカバーしていないかを知っている」段階へと引き上げてくれる——そしてこの差こそが、資金が本当に安全かどうかを左右することが多い。