2026-04-24

Webサービスのリリース前監査をClaude Codeのサブエージェントで自動化した話

概要

今回はWebサービスを公開する前のリリース前監査を、Claude Codeのサブエージェントで並列自動化したツールを作ったので紹介していきます。

自作のWebサービスをリリースするとき、セキュリティ・法務・プライバシー・コンテンツ・OSSライセンス・運用コストなど見るべき観点が多いんですよね。
こんなの個人でチェックできるわけないですよ。。。

だからと言って無視すると色々大変なことになる（- -;

そこで、Claude Code のサブエージェント機能を使って、6つの観点を並列に走らせて Go / Conditional Go / No-Go を自動判定するツールを自作しました。

実際に故意に脆弱にしたテスト環境を監査させたら、Critical 10件 / High 19件 を取りこぼさず検出できたので、使用感も含めて書いていきます。

まぁあくまで実験レベルの試みなので、まったり見ていってください！

それではやっていきましょう！

この記事を鵜呑みにする人はいないと思いますが、念のため。
AIを過信せず、自分の目でのチェックしてください。
場合によっては各分野の専門家の意見を得ることを視野に入れてください
当サイトはいかなる賠償や責任を負いません。
あくまで自己責任で実施してください。
あくまで実験としてこの記事をご確認ください。

目次

• 作ったもの
  • 全体構成
• なぜ作ったか
  • 手動チェックの限界
  • 要件整理
• この監査ツールでチェックしていること
• 判定ロジック
  • Short-circuit判定の理由
• 実装のポイント（Claude Codeの機能活用）
  • 1. スラッシュコマンドで起動
  • 2. audit-request.mdの自動生成
  • 3. エビデンス保存ルール
  • 4. チェックリスト鮮度監視
• 実際に動かしてみた
  • 実行コマンド
  • 結果
  • 主なCritical指摘（抜粋）
• 使ってみた所感
  • メリット
  • 課題
• まとめ

作ったもの

ざっくり言うと、対象フォルダを渡すと、リリース可否（Go / Conditional Go / No-Go）を根拠付きで返してくれるCLIツールです。

Claude Code 上で次のように呼ぶだけで動きます。

コマンド

/release-audit [監査対象のパス]

内部では 6 つのサブエージェントが並列で動き、最後に判定用のエージェントが全部を統合してレポートを書き出します。

全体構成

アーキテクチャを図にするとこんな形です。

リリース前監査エージェントの全体構成（6 観点を並列実行 → release-judge が統合判定）

6つのサブエージェントが並列で動くので、順番に回すより体感 3〜5 倍くらい速いです。

その分、トークンが一瞬で溶けます。。。 MAXプラン以上でないと多分動きません。

なぜ作ったか

手動チェックの限界

リリース前チェックって、観点が多い割に抜け漏れたときの事故が致命的ですよね。

＜手動チェックの悩み＞

• 観点がいくつもあって、毎回チェックリストを見返すのが面倒
• 色々な人にヒヤリングする必要があるので大変
• 見るべき条文（薬機法、景表法、個情法）の最新版を毎回確認しないといけない
• 見逃しなどの人為的ミスが発生する

人の目に頼る運用だと、どこかで必ず事故るというのは世の常だとおもいます（- -;

要件整理

最初にざっくり要件を決めました。

＜要件＞

• 観点ごとに独立したエージェントで走らせて、1観点が壊れても他は動く
• 判定ロジックは人間が読めるMarkdownで残す（ブラックボックス化しない）
• 各findingsには「該当ファイル:行番号」＋「参照条文URL」をエビデンスとして必須化
• 法令・CVEベースのチェック項目は鮮度を自動監視

この監査ツールでチェックしていること

ここが一番設計に時間をかけたところです。
観点ごとに .claude/agents/<name>.md としてサブエージェント定義を分け、対応するチェックリストを checklists/<name>.md に置いています。

観点	主なチェック項目
Security	OWASP Top10（SQLi / XSS / コマンドインジェクション）、.env 混入、シークレットのハードコード、CSP・HSTS、Cookie（Secure / httpOnly / SameSite）、依存脆弱性
Legal	薬機法禁止ワード（「治る」「予防効果」）、景表法（「日本一」「効果があります」）、ステマ規制の [PR] 表記、特商法表示、免責事項
Privacy	個人情報保護法第21条（プラポリ未設置）、Cookie同意UI、平文パスワード保管、越境移転通知、漏洩報告体制
Content	禁句フィルタ（guards/forbidden-words.txt）、外部リンクのホワイトリスト整備
License	GPL汚染判定、THIRD_PARTY_NOTICES の整備、ライセンス互換性（MIT/Apache/BSD 許可 ⇔ GPL-3.0 制限）
Ops-Cost	バックアップ体制の明文化、インシデント対応手順、レート制限、RTO/RPO 定義

各エージェントには「エビデンスに条文URLを必ず添えること」を強く指示していて、「個人情報保護法第21条違反」のように条文番号まで出てくるレポートになります。

判定ロジック

ここが今回の肝で、Critical が出た観点によってロジックを変えているのがポイントです。

条件	判定
legal / security / privacy のいずれかで Critical ≥ 1	No-Go（short-circuit）
いずれかの観点で Critical ≥ 1	No-Go
Critical = 0 かつ High ≥ 3	No-Go
Critical = 0 かつ High 1〜2	Conditional Go（修正期限付き）
Critical = 0 かつ High = 0	Go（Medium/Low は改善推奨）

Short-circuit判定の理由

法務・セキュリティ・プライバシーはどれか一つでもCriticalがあった時点でthe endなので、他観点の細かいfindingsを眺める前に即No-Goで返すようにしました。

フロー的にはこんな感じです。

Go / Conditional Go / No-Go の判定フロー（法務・セキュリティ・プライバシーは短絡で即 No-Go）

「とりあえず動くけど不安が残る」を Conditional Go として明示的に残すことで、「修正期限付きで通す」といった運用を行いやすくしました（^^b

実装のポイント（Claude Codeの機能活用）

1. スラッシュコマンドで起動

.claude/commands/release-audit.md にコマンド定義を書くと、/release-audit <パス> でClaude Codeから呼び出せます。

中身はざっくりこんなフローです。

＜オーケストレータの処理＞

1. audit-request.md の存在確認（無ければ自動生成）
2. reports/YYYY-MM-DD_<フォルダ名>/ を作成
3. 6つの監査サブエージェントを1メッセージで並列起動
4. release-judge が各JSONを統合して Go/No-Go 判定
5. judgement.md のパスを提示

ポイントは手順3で、1つのメッセージ内で複数のAgent呼び出しを書くと並列実行される仕様を活用しています。

2. audit-request.mdの自動生成

最初は「依頼書テンプレを手で書いてね」方式にしていたんですが、これもAIでよくね？と思ったので途中で方針転換しました。

現在は `audit-request.md` が無い場合、対象フォルダの README.md / package.json / wrangler.toml / 設定ファイルを自動スキャンし、4つの簡単な質問に答えるだけで依頼書を自動生成する仕組みにしています。
おかげで事前準備ほぼゼロで監査に入れるようになりました（^^

3. エビデンス保存ルール

各findingには以下を必須化しています。

finding.schema.json抜粋

{
  "id": "SEC-002",
  "severity": "critical",
  "title": "JWT_SECRET がハードコードされている",
  "file": "src/auth.js",
  "line": 14,
  "snippet": "const SECRET = 'hardcoded-dev-secret-do-not-use';",
  "reference": "https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password",
  "remediation": "環境変数から読み込む形に修正"
}

また`.env` ファイルの中身は「存在のみ」を記録して、中身は絶対に読まないルールにしています。
監査結果のレポートに機密情報が写り込むのを防ぐためです。
セキュリティは大事。

4. チェックリスト鮮度監視

法令やCVEベースのチェック項目は時間で陳腐化します。
なので各チェックリストの冒頭に last-reviewed: YYYY-MM-DD を書いておき、180日以上経過していたら judgement.md に警告を出すようにしました。

checklists/legal-jp.md冒頭

---
name: legal-jp
last-reviewed: 2026-03-15
description: 日本向けサービスの法令チェックリスト（薬機法・景表法・特商法）
---

実際に動かしてみた

ツールの挙動確認のため、故意に脆弱にしたテスト環境（audit-test-harness）を用意して監査させてみました。
Node.js + SQLite の簡単なAPIサーバーに、教科書通りの脆弱性をわざと詰め込んだ代物です。

実行コマンド

コマンド

/release-audit C:\PG\監査テスト

結果

判定	Critical	High	Medium	Low	合計
No-Go	10	19	12	1	42

Short-circuit で security / legal / privacy 3観点同時にCritical発火したので、即No-Goとなりました。

主なCritical指摘（抜粋）

＜Security＞

• SEC-001: .env ファイルがリポジトリに混入
• SEC-002: JWT_SECRET がハードコード（hardcoded-dev-secret-do-not-use）
• SEC-003: SQLインジェクション（文字列結合でSQL構築 4箇所）
• SEC-004/005: OSコマンドインジェクション（/ping・zipExport エンドポイント）
• SEC-006: eval() 使用（任意JS実行可能）
• SEC-007: SSRF（任意URLへのサーバーサイドfetch）

＜Legal / Privacy＞

• LEGAL-002: プライバシーポリシー未整備（個人情報保護法第21条 違反確定）
• PRIV-001/002: プラポリ未設置＋ .env 存在

わざと仕込んだ脆弱性を一つも取りこぼさず、条文番号付きで指摘されてきたのでかなり手応えがありました（^^b

LEGAL-002の「個人情報保護法第21条」という条文番号も自動で出てきて素直に感動しました（^^
チェックリストに条文URLを参照として書いておくと、エージェント側が根拠を添えた上で指摘してくれます。
これがあるとレビューを受ける側も「何を直せばいいのか」が即分かって便利ですね。

使ってみた所感

メリット

＜メリット＞

• 並列実行でレビュー時間が大幅短縮（6観点 × 手動20分 = 2時間 → 5〜10分）
• エビデンス付きなので、指摘された側が条文まですぐ確認できる
• 観点ごとにエージェント定義が分離されていて、メンテしやすい
• JSON出力があるので、後日差分監査（前回との突合）がしやすい

課題

＜課題＞

• Short-circuitで止まった観点は未検査のまま（=修正後に再実行が必要）
• ClaudeCodeの利用枠消耗が激しい
• チェックリストの鮮度監視は自動だが、更新作業自体は手動
• AIなので100%信用することが難しい。結局手動での確認が必要

特にAIなので100%信用することが難しい。結局手動での確認が必要については、正直難しいですね。
監査ツールの監査ツールを入れるとか？
まぁ結局いたちごっこなので最後は人の目ですね。。。

まとめ

今回はWebサービスのリリース前監査を、Claude Codeのサブエージェントで並列自動化するツールを紹介しました。

ポイントをおさらいすると以下のとおりです。

＜まとめ＞

• 6観点のサブエージェントを並列起動して大幅時短
• legal / security / privacy Critical はshort-circuitで即No-Go
• findingsには条文URLとファイル行番号をエビデンスとして必須化
• .env の中身は読まないルールで監査ツール自体の事故を予防
• チェックリストにlast-reviewedを持たせて鮮度警告

今回の実験はかなり面白かったです。
結果からすると課題も多いので、監査を全自動化はきっと難しいですね。。。

個人開発でもチーム開発でも、リリース前の不安を減らすのにはかなりお勧めです（^^

監査の人って結構きつい言い方してくる人が多いので、こういったツールを作って監査人から厳しいお言葉を受けないようにできるのは結構大きいと思います！

似たような悩みを持っている方の参考になったらうれしいです！

以上となります。
AIを使えば使うほどに仕事を奪われる可能性を危惧します。もっと頑張らないと！
いいですか、気合と根性が大切ですよ（^^
それではお疲れさまでした！

この記事をシェア X B! f

« 前の記事 スマホだけ横にちょっとスクロールできる現象を直す方法（CSS overflow-x clip） 次の記事 » npm ciで「Exit handler never called!」エラーが発生したときの対処法

エンジニアリング

エンジニアリング, AI, Claude Code