スマートコントラクト監査はなぜ高いのか（2025年版）

私が所属するフィンランドの監査企業SC Audit Studioのブログ記事「Why Some Smart Contract Audits Are So Expensive (2025 Edition)」を日本語訳しました。

はじめに

監査は、Web3プロジェクトの予算の中でも最も大きな費目のひとつです。見積もりが「数千ドル」から「数十万ドル」まで幅広く提示されると、たいていこんな疑問が浮かぶでしょう。「いったい何が、この金額を左右しているのか？」と。2025年の監査市場は、これまで以上に成熟し、高額化し、そして多様化しています。本記事では、なぜ一部の監査がこれほど高くつくのかを、実際の市場ベンチマークと複数の監査モデルの比較を交えて深掘りしていきます。

2025年の最新料金ベンチマーク

以下は、2025年の市場から得られたデータです。実例の肌感覚と、今後の方向性をつかむのに役立ちます。後ほど扱う「コンテスト型」と「従来型」のモデルを比較する際の基準にもなります。

補足

プライベート監査ファームのCD Securityは、段階別の参考価格を以下のように提示しています。

コンテスト型（クラウドソース）と従来型の監査の比較

料金に関する多くのレポートは、従来型の監査（専任チームを割り当て、手動でレビューを行うファーム）を念頭に置いています。ところが近年では、コンテスト型・クラウドソース型の監査プラットフォームの存在感が増してきました。ここでは、2025年時点でのこの2つのモデルを、費用・価値・リスクの観点から比較します。

直近のケーススタディ：コンテスト型と従来型（2024〜2025年）

以下は、公開された監査レポート、開示された賞金プール、そして2024〜2025年の市場データを私たちが独自に集約した、代表的な直近の事例です。行数（LOC）は、本番用の対象範囲内のSolidityコードに正規化し（テスト、モック、デプロイ用スクリプトは除外）、コンテストの提出物については重複を排除したうえで、High（重大）、Medium（中）、Low（軽微）、Informational（情報提供レベル）という標準的な区分に振り分けました。裏付けの取れない伝聞ベースの費用情報は除外しています。従来型監査の正確な費用はNDA（秘密保持契約）下にあることが多く、公開された具体的な数値が得られなかった場合は、比較可能な開示済み案件をもとにした狭めのレンジを示しています。

注記 データは、いくつかの監査ファームの公開アーカイブと、公開コンテストプラットフォームをもとに、任意の形でリサーチしたものです。1 2 3 4 5

上記データから見えること

• コンテスト型は、Low、Informationalの問題を素早く大量に表面化させます（広さ）。一方、従来型は、全提出数に対する設計・ロジック関連の発見の割合が相対的に高くなります（深さ）。
• 再監査（検証）サイクルは、従来型の案件のほうが構造化され、時間的にも区切られています。コンテスト型では、重複を整理し修正を検証するために、内部または外部のフォローアップを別途必要とすることがよくあります。
• LOCあたりの費用は、複雑さの高い従来型のスコープほど割安に近づきます。脅威モデリングやアーキテクチャ分析といった固定的な立ち上げコストが、より多くのコードに分散して償却されるためです。
• 形式手法・不変条件の証明を追加すると、費用は15〜30%ほど上がりますが、計算ロジックの重いプロトコル（AMM、ステーキング・デリバティブ、ブリッジ）では、残存するHigh、重大度のリスクを下げる効果があります。
• 今回のサンプルでは、賞金プールが約75000ドルを超えると、ユニーク参加者の層の厚み（質の高いレビュアーが増える）が高まり、少なくとも1件のHigh、または複数のMediumが見つかる傾向と相関していました。つまり、ある飽和点までは、追加投資に対する限界的なリターンが見込めるということです。

上記データからざっくりベンチマーク

• 従来型：中規模スコープで、監査済みLOCあたりおよそ11〜22ドル（再監査の時間を含む）。形式手法を加えたり、スケジュールを圧縮したりすると、30ドル超まで上がることもあります。
• コンテスト型：実効的な支出はLOCあたり約8〜18ドル（賞金プールのみ）。内部トリアージとエンジニアリングの工数を加えると、実際の内部コストは15〜25%増えることがよくあります。
• Highの中央値：両モデルとも、5〜8K LOCあたり0〜2件。その分布は、モデルそのものよりも、プロトコルの新規性に大きく左右されます。

監査費用を押し上げる要因と、その正当性

費用を押し上げるレバーは数多くあります。直近のデータや各モデルの特徴と合わせて見ると、監査が「とても高額」になる条件と、なぜ高く払うことが無駄ではなく、ときに理にかなっているのかが見えてきます。以下を理解しておくと、提示された見積もりが妥当なのか、過剰なのかも見極めやすくなります。

• コードの複雑さと規模（行数、モジュール構成）
  相互に依存する多くのコントラクト、クロスチェーンのオラクル、ブリッジ、アップグレード機能、マルチシグなど、可動部が多いほど、攻撃対象領域と洗い出すべきエッジケースが一気に膨れ上がります。モジュールが増えるたびに、テストすべき経路と潜在的な脆弱性が増え、レビュアーの時間・ツール・テストもより多く必要になります。
• 高いステーク額、大きなTVL、ミッションクリティカルな機能
  ユーザー資金、トレジャリー、ガバナンスのオラクルなど、バグが大きな金銭的損失や評判の毀損につながりうる部分を扱う場合です。ステーク額が大きいほど、求められるデューデリジェンス（精査）の水準も上がります。
• 新規性の高いカスタムロジック、参照できる前例の乏しさ
  ロジックが独自で、一般的なパターンに従っていない場合、監査者はモデルを一から構築し、新しい攻撃ベクトルを考え抜き、異常な障害モードまで入念にテストする必要があります。その分、時間と費用がかかります。
• 監査者、ファームの評判・専門性
  強い実績やブランド価値を持つトップファーム（Trail of Bits、OpenZeppelin、ConsenSys Diligenceなど）は、より高い料金を取ります。単に技術力ゆえだけでなく、その監査レポートが、ユーザー・投資家・取引所にとって高い「信頼の価値」を持つからです。
• 規制、投資家からの期待
  監査はセキュリティのためだけでなく、信頼を示すために行われることもあります。投資家、取引所、保険会社が、特定のファームによる監査や、正式な報告書、証明などを要求する場合があり、そうした要件は費用を押し上げます。
• 監査の深さ・スコープと追加の成果物
  監査には幅があります。表層的な脆弱性スキャン + 自動ツール → より深い手動レビュー → 形式検証 → 結合テスト / ペネトレーションテスト → 本格的なレッドチーム / 攻撃シナリオのシミュレーション、という具合です。さらに、ガス最適化、性能テスト、コンプライアンス対応、ユーザー向けドキュメント、ローンチ後のモニタリング、バグバウンティなどの付加サービスも加わります。レイヤーを1つ増やすごとに、費用は大きく上がります。
• 短納期
  ローンチ前や資金調達の締め切りに間に合わせるために結果を急ぐ場合、監査者は人員を増やし、残業し、他の作業を後回しにすることになるため、プレミアム価格になります。
• 複数ラウンド + 修正対応 + 再監査
  多くのプロジェクトは、何回の修正（監査者やコンテスト提出者からの指摘に対するもの）と再検証が必要になるかを過小評価しがちです。監査者が問題を報告し、開発側が修正し、監査者が再レビューする。コードがパッチや新機能で進化すれば、新たなチェックも必要になります。優れた監査者は、良質なドキュメントを提供し、修正の組み込みやエッジケースの議論も支援してくれます。これらは「初回のひと通り」を超えて費用に積み上がっていきます。

すべての要因を組み合わせると、費用はだいたいどうなるか

以下は、上記の費用要因の多くを組み合わせた場合に、2025年時点で妥当に見込まれるおおよそのレンジです。

実践的なヒント：セキュリティを犠牲にせず費用を抑えるには？

監査は高額なので、コストを妥当な範囲に保ちながらセキュリティを確保するための、実践的な戦略を挙げておきます。

• コードベースをきちんと整えておく
  きれいなアーキテクチャ、良テスト、ドキュメント、内部監査。きれいな状態で出すほど、監査者が基本的な部分に時間を浪費せずに済みます。
• スコープを明確に定義する
  必ず監査すべきもの（重要モジュール、高リスク部分）と、後回しにできるものを切り分けます。監査をフェーズに分割するのも一案です。
• 複数の見積もりを取る
  従来型ファーム、小規模ファーム、コンテストプラットフォーム。価格だけでなく、スコープと成果物を含めて比較します。
• コンテストやコミュニティ監査を補完として使う
  一部はコンテストで回し、コア・リスクの高い部分は従来型監査にかける、という組み合わせができます。
• 再監査と修正対応を見込んでおく
  問題の修正と、修正の検証のために、追加の費用と時間を予算に織り込みます。
• プラットフォーム、チェーンの選択を考慮する
  ツールやエコシステムが充実したチェーン上で構築すると、監査費用を抑えられる場合があります。
• 可能なら急ぎすぎない
  スピードが必須でない限り、監査者に十分な時間を与えるほうが、プレミアムを抑えられることがよくあります。
• 評判の良い監査者、コンテストプラットフォームを選ぶ
  信頼性は重要です。安くても重大な問題を見逃す監査は、後々の損失や信頼の喪失という形で、かえって高くつきかねません。

コンテスト型と従来型、どちらを選ぶべき？事例が裏づける使い分け

• コードがフィーチャーフリーズ（機能凍結）に近づいた段階で、まずコンテストを実施し、実装上のバグの大きな分類や、軽微なロジックの問題を一気に洗い出します。
• その前後に従来型監査を行い、アーキテクチャの脅威モデリング、経済的・モジュール横断的な不変条件、修正セットの構造的な検証を担います。
• 高リスク、または新規性の高いプロトコルには、ハイブリッドが向いています。最初に従来型で深く掘り下げ、コンテストで広く拾い、最後に修正後のクリティカルな経路へ重点的な再監査・形式検証を行う、という流れです。

まとめ

スマートコントラクト監査が高額なのは、それが単なるコードのチェックではなく、リスクの管理だからです。2025年には、「安い監査」と「プレミアムな保証」のあいだの差が、さらに広がりました。監査が特に高額になるのは、次のような要因が重なるときです。

• 大規模で複雑なコードベース
• 金銭的な損失や信用の毀損につながるリスクの大きさ
• 強い評判を持つ監査ファームやプラットフォーム
• スコープの深さ（手動レビュー、形式手法、複数ラウンドの監査）
• 緊急性、コンプライアンス、追加の成果物

コンテスト・クラウドソース型のモデルは、興味深い選択肢を提供します。特定のモジュールやリスクプロファイルに対しては、より柔軟で、おそらくより費用効率が高い場合もあります。ただし、信頼・責任・保証が重要になるミッションクリティカルな部分については、従来型監査を置き換えられるものではない、というのが一般的な見方です。

セキュリティの予算を組むなら、価格そのものではなく、何に対してお金を払っているのかを理解してください。予算は保守的に、スコープは慎重に、監査パートナーは賢く選ぶ。監査は高く見えるかもしれませんが、セキュリティを省いたり、投資を怠った代償は、ほとんどの場合監査コストをはるかに上回ります。

私たちについて

SC Audit Studioは、プロトコルのセキュリティ評価を専門としています。

私たちの専門家チームは、プロジェクトの安全性と信頼性を確保することに力を入れています。ぜひ一緒に、プロジェクトのセキュリティを高めていきましょう。安心してプロダクトを世に送り出せるよう、私たちがしっかりサポートします。

SC Audit Studio情報

Webサイト：https://scauditstudio.com/
X（旧Twitter）：https://x.com/SCAuditStudio

よくある質問（FAQ）

• 似たようなスコープでも、なぜ監査の見積もりはこれほど幅があるのですか？
  「似ている」コードベースでも、テストの品質、ドキュメントの明確さ、アーキテクチャの複雑さ、外部依存、アップグレードのパターン、新規性といった点で、しばしば中身が異なります。同じLOCの2つのプロトコルでも、モデリングと環境構築まで考慮すると、アナリストの工数は2〜3倍ぶれることがあります。
• LOCあたりの価格は、見積もりを比較する信頼できる方法ですか？
  あくまで大まかな目安としてのみ有効です。質の高い監査は、LOCに比例しない脅威モデリングや不変条件の設計を、序盤に重点的に行います。LOCあたりの単価が極端に低い場合は、深さの浅さや、レビュアーが1人だけであることを示していることがよくあります。
• セキュリティを犠牲にせず、監査費用を下げるには？
  スコープを凍結し、デッドコードを取り除き、脅威モデルと権限の対応表（ロールマトリクス）を用意し、テスト・不変条件のカバレッジを充実させ、終盤のリファクタリングを避けることです。監査の途中で変更が少ないほど、再監査のサイクルも減ります。
• コンテスト型と従来型、どちらを選ぶべきですか？
  広く表面を素早く洗い出すならコンテスト型、深さ（アーキテクチャ、経済性、形式手法）が必要なら従来型を使います。ミッションクリティカルなローンチでは、両者を組み合わせたハイブリッドが効果的です。
• 再監査は通常含まれていますか？
  多くのファームは、限定的な修正、差分レビューを1回含めています。大規模なリファクタリング、大幅な遅延、スコープの追加は、通常は新しいSOW（作業範囲記述書）の対象になります。ラウンド数と所要時間は、事前に明確にしておきましょう。
• 監査は複数回必要ですか？
  TVLが大きい、あるいは新規性の高いプロトコルでは、たいてい「深い監査 →コンテスト→重点的な最終レビュー」という流れが適しています。シンプルなトークンなら、的を絞った監査1回 + バグバウンティで済むこともあります。