スマートコントラクト監査会社は、対応言語・実績・範囲・手法・費用と期間・レポートと修正確認・日本語対応の7基準で比較する。見積依頼前の準備と、監査後のバグバウンティとの組み合わせ方まで発注側の視点で整理した。
スマートコントラクト監査会社は、知名度や価格だけで選ぶと比較の軸がぶれる。対応言語や実績など7つの基準をそろえて比べるのが、実務的な進め方だ。本記事では、2〜3社に同じ条件で見積を依頼し、最後に1社を選ぶまでに確かめることを発注側の視点でまとめる。順に見ていこう。
スマートコントラクト監査会社の選び方とは？
スマートコントラクト監査会社の選び方とは、監査の対象・手法・成果物・費用を同じ基準で並べ、自社のコードに合う依頼先を決める手順である。
監査は、本番公開前のコードを第三者が読み、脆弱性や設計上の問題を指摘する業務だ。公開後の修正が難しいコントラクトでは、公開前に外部の目を入れる工程として位置づけられる。ただし、監査会社ごとに得意なチェーンや報告の形式は違う。比較の軸を先に決めておかないと、見積を並べても判断できない。
監査会社を選ぶ前に何を確認すべきか？
選ぶ前に確認すべきは、監査対象のコード範囲・使用言語とチェーン・公開予定日の3点である。これが決まらないと、監査会社は見積と日程を正確に出せない。
- 対象範囲：どのリポジトリのどのコントラクトを監査に含めるか。外部ライブラリや運用スクリプトの扱いも決める。
- 言語とチェーン：Solidity・Vyper・Rustなどの言語と、公開先のチェーンを明示する。
- 日程：公開日から逆算し、修正と再監査に使える期間を確保する。
監査の依頼は、仕様が固まり、テストを揃えた段階で行うのが目安だ。開発途中のコードを出すと、指摘の多くが後の変更で意味を失う。開発全体の進め方はスマートコントラクト開発の進め方と、よくある落とし穴で整理している。
監査会社の実績や信頼性はどう見極めるか？
実績は件数ではなく、公開された監査報告書の中身で見極める。自社と同じ言語・チェーンの報告書を2〜3本読み、指摘の深さを比べると判断しやすい。
- 指摘が該当コードの位置と発生条件まで書かれているかを確認する。
- 監査した案件で後に事故が起きた場合、事後の分析を公開しているかを確認する。
- 担当する監査人の人数と日数の開示を、見積の段階で求める。
「監査済み」の表示が多いことは、あまり当てにならない。範囲・人数・日数が分からなければ、同じ「監査済み」でも点検の密度は大きく異なるからだ。
監査の範囲と手法は何を比較すべきか？
比較すべきは、範囲に含まれるコントラクトと観点、そして手動レビュー・自動ツール・形式検証の組み合わせである。人手による点検が主体かどうかで、論理の誤りを拾える度合いが変わる。
| 手法 | 主に見つけるもの | 見積で確認したい点 |
|---|---|---|
| 手動レビュー | 論理の誤り・権限設計の不備 | 担当人数と日数 |
| 自動ツール（静的解析等） | 既知の型の脆弱性 | 使用ツールと誤検知の扱い |
| ファジング・テスト追加 | 想定外の入力での挙動 | 追加したテストを納品するか |
| 形式検証 | 仕様どおりに動くことの証明 | 証明の対象とする性質の範囲 |
観点の抜けは、OWASPが公開するスマートコントラクト向けの脆弱性一覧に照らせば見つけやすい。2025年版の一覧は10項目からなる（出典：OWASP『Smart Contract Top 10』2026年10月閲覧、OWASP）。アクセス制御の不備、価格オラクルの操作、論理の誤り、リエントランシなどが含まれる。各社の見積に書かれた観点が、この10項目をどこまで含むかを並べて比べるとよい。
監査の費用と期間の相場はどう見積もるか？
費用と期間は、対象コードの量と複雑さ、監査人の人数と日数でほぼ決まる。相場の数字を探すより、同じ範囲を2〜3社に示し、人数と日数の内訳で比べる方が判断を誤りにくい。
- コード行数とコントラクト数など、見積の前提を各社でそろえているかを確認する。
- 人数と日数の内訳、修正確認が料金に含まれるかを確認する。
- 着手可能日を確認する。監査会社の予定が埋まっていると、着手まで待つ期間が生じる。
- オラクルやブリッジなど外部連携を追加範囲として扱うかを確認する。
安ければよい、とは限らない。安い見積は、範囲の狭さや日数の短さを反映している場合もあるため、前提の差を先に確かめる。
監査報告書と再監査対応では何を確認するか？
報告書では、指摘ごとの重大度・該当箇所・修正案と、修正後の確認（再監査）が範囲に含まれるかを確かめる。修正確認がないと、直したコードを第三者が見ないまま公開することになる。
- 重大度（CriticalからInformationalまで等）の基準が定義されているかを確認する。
- 修正後のコミットを確認し、各指摘の対応状況を最終版に反映してもらえるかを確認する。
- 報告書を公開するなら、その形式と、公開前に表現を調整できる範囲を聞いておく。
- 監査対象のコミットハッシュが明記されているかを確認する。
最後の点は見落としやすい。監査後にコードを変えれば、変更部分は監査の対象外になる。公開するコードと監査したコミットが一致しているかを、発注側で確かめる運用にする。
監査だけで安全と言えるのか、バグバウンティとどう組み合わせるか？
監査だけでは安全とは言えない。監査は全てのバグを見つけるものではなく、追加の点検にあたる。公開前の監査と、公開後のバグバウンティや監視を重ねて備えるのが基本だ。
ethereum.orgも同じ見方だ（出典：ethereum.org『Smart contract security』2026年2月、ethereum.org）。開発とテストで見落とした問題を拾う、追加の点検という位置づけだ。同じページはバグバウンティも紹介している。脆弱性を見つけた外部の研究者に報奨金を払う仕組みである。監査は期間を区切った点検だが、バグバウンティなら公開後も外部の目を入れ続けられる。両者は補い合う関係にある。
| 施策 | 時期 | 役割 |
|---|---|---|
| テスト | 開発中 | 仕様どおりに動くかを確かめる |
| 監査 | 公開前 | 第三者が設計とコードを読む |
| バグバウンティ | 公開後 | 外部から継続して脆弱性を探してもらう |
| 監視・緊急停止の手順 | 運用中 | 異常な取引を検知し、被害を抑える |
見積依頼の前に発注側は何を準備すべきか？
準備すべきは、仕様書・テスト一式・監査対象のコミット固定・説明文書の4つである。これが揃うと、監査人が仕様の確認に使う時間が減り、論理の検証に日数を回せる。
- 仕様書：コントラクトごとの役割、権限、想定する利用の流れ。
- テスト：単体テストと統合テスト、その網羅率。
- コミット固定：監査中はコードを変えないコミットを決める。
- 説明文書：NatSpec形式のコメントや構成図。
ethereum.orgの同じページも、コードと構成を分かりやすく文書化しておくと監査しやすくなると述べている。秘密保持契約や報告書公開の可否も、見積依頼の段階で取り決めておく。そうすれば、契約のあとで手戻りが起きにくい。
監査会社の比較表はどう作ればよいか？
比較表は7つの基準を行に置き、候補の2〜3社を列に並べて作る。各社の回答を同じ表に書き込めば、範囲や日数の前提の違いがすぐに分かる。
| 基準 | 確認すること |
|---|---|
| 1. 対応言語・チェーン | 自社と同じ言語・チェーンの公開報告書があるか |
| 2. 実績 | 同種案件の公開報告書で、指摘の深さを読めるか |
| 3. 監査範囲 | 対象コントラクト・外部連携・運用スクリプトの扱い |
| 4. 監査手法 | 手動レビュー・自動ツール・形式検証の組み合わせ |
| 5. 費用・期間 | 人数と日数の内訳、着手可能日 |
| 6. 報告書・修正確認 | 重大度の定義、再監査の有無、コミットの明記 |
| 7. 連絡体制 | 日本語での窓口、質疑の手段と頻度 |
日本語対応は、仕様の背景を正確に伝えるうえで比較軸になる。ここは軽く見ないほうがよい。英語でのやり取りが前提なら、仕様書の英訳と質疑の窓口を誰が担うかを発注側で決めておく。
既存記事から整理した監査会社選定の確認項目
※ご提案です。当社の実施実績ではありません。
以下は、株式会社ファーリープ（Farleap）が公開している2本の記事の論点を、監査会社の選定に絞って整理し直した独自の確認表である。業界で定められた基準ではない。Web3受託開発会社の選び方では、外部監査の要否を判断し手配できるかを発注先の確認項目に挙げた。開発の進め方の記事では、テストと監査を最初から範囲に含めることを勧めている。
- 公開日から逆算した日程に、修正と再監査の期間を含めたか
- 監査対象のコードとコミットを固定したか。
- 仕様書とテスト一式を添えて、2〜3社に同じ範囲で見積を依頼したか
- 人数・日数の内訳と再監査の有無を比較表に記入し、公開報告書で指摘の深さも比べたか
- 公開後のバグバウンティと監視の方針を決めたか
監査を含む開発体制の検討は、Web3・FinTechのサービスで扱っている。
まとめ
スマートコントラクト監査会社は、対応言語から連絡体制までの7基準をそろえて比べる。見積依頼の前に仕様書・テスト・コミットを固め、2〜3社に同じ条件で依頼すれば、人数と日数の内訳で比較できる。監査で全てのバグが見つかるわけではない。だからこそ、公開後のバグバウンティと監視まで含めて体制を決める。
よくある質問
スマートコントラクト監査はいつ依頼すればよいか？
仕様が固まり、テストが揃った段階で見積を依頼するのが目安だ。監査会社によっては着手まで待つ期間があるため、公開日から逆算して日程を押さえる。修正と再監査に使う期間も、最初から日程に含めておく。
監査会社は何社に見積を依頼すべきか？
2〜3社に同じ範囲・同じ資料で依頼すると比較しやすい。1社だけでは見積の妥当性を判断しにくく、多すぎると各社との質疑に対応する負担が増える。比べるときは総額ではなく、人数と日数の内訳で見る。
監査を受ければスマートコントラクトは安全か？
監査は全てのバグを見つけるものではない。テストとバグバウンティに加えて、公開後の監視とも組み合わせる。事故が起きる可能性と、起きたときの被害の両方を小さくする設計にする。
日本語に対応していない監査会社でも問題ないか？
問題がないかは発注側の体制次第である。仕様の背景を英語で正確に伝えられる担当者がいれば、比較対象に入れてよい。いない場合は、仕様書の英訳と質疑の窓口を誰が担うかを先に決めておく。
更新履歴
2026-10-10 初稿公開。
本記事は技術・事業設計の解説であり、暗号資産の売買や投資を勧誘するものではない。暗号資産交換業・資金移動業等の該当性は資金決済法・金融商品取引法に基づき専門家に確認を。
