Security Audit Skill徹底チュートリアル：Claude CodeをAIセキュリティ監査員に変える、コードスキャンから脆弱性レポートまでの完全実践

コードレビューをAIに任せたいものの、検出結果をそのまま信用してよいか判断できないことがあります。
Security Audit Skillを使えば、Claude Codeを手順に沿ってコードを調べる補助監査員として運用できます。ただし、効果は対象範囲と利用可能なツールに左右され、発見の確定や安全性の保証には人手の検証が欠かせません。

Claude Codeで繰り返し行うレビュー手順を標準化したい開発者向けです。
検出内容を根拠付きの脆弱性レポートに整理したいセキュリティ担当者にも役立ちます。
AIエージェントを監査工程に導入する前に、責任範囲を整理したい技術責任者も対象です。

まず監査工程におけるSkillの役割を分けます

Security Audit Skillは、Claude Codeに監査の目的、確認手順、結果の記録方法を伝える再利用可能な指示です。Skill自体が脆弱性を確定したり、すべての弱点を検出したりするわけではありません。

実務では、役割を次のように分けると結果を扱いやすくなります。

• Skill：対象範囲、確認の順序、証拠の記録方法、報告形式を指定します。
• Claude Code：指示に従ってコードや関連文書を読み、データの流れや実装上の懸念を説明します。
• 設定済みのスキャンツール：対応するルールやパターンに基づいて検査し、ツール固有の出力を返します。
• 担当者：コードの実際の動作、到達可能性、影響度を検証し、報告内容と修正判断に責任を持ちます。

Security Audit Skillは、どのようにClaude Codeのコード確認を導きますか。
「セキュリティを確認する」とだけ依頼するのではなく、入力元から危険な処理までの追跡、該当箇所の記録、ツール結果との照合、確度の分類を指示します。レビュー観点の参考として、OWASP Top 10はWebアプリケーションの主要なリスクを扱う一覧ですが、そこに掲載された分類だけで全種類の問題を網羅できるわけではありません。OWASP Top 10: 2021をプロジェクトの技術構成に合わせて参照し、対象外のリスクも別途定義します。

スキャンを始める前に対象範囲と権限を決めます

範囲を「リポジトリ全体」とだけ記すと、生成物や依存ライブラリまで無差別に調べたり、重要な入口や信頼境界が伝わらなかったりします。逆に、対象ファイルだけを指定して関連する設定や呼び出し元を除外すると、問題の成立条件を見落とす可能性があります。

たとえば、自社が管理し、監査の許可を得ているsample-appを対象にするなら、指示には次の情報を含めます。

• 対象リポジトリと確認を許可されたブランチ、ディレクトリ
• 使用言語、主要な実行経路、認証や入力処理など重点を置く領域
• 除外する生成物、外部サービス、秘密情報を含み得るファイル
• 実行してよい読み取り専用スキャナーと、実行を許可しない操作
• 依存関係や設定ファイルなど、コードの判断に必要な周辺情報

Security Audit Skillを設定してClaude Codeにコードの安全性を確認させるには、何を指定しますか。
対象、重点リスク、利用可能な資料、禁止操作、発見時の証拠要件を明記します。プロジェクト構成が不足している場合、Claude Codeはルーティングや認証の境界を推測することになるため、根拠を確認できない項目は「要確認」に分類するよう指示します。

アクセス許可も先に確認します。Claude Codeの権限設定では、ツールや操作の許可・確認の扱いを制御できますが、Skillの文章だけで権限設定を迂回できるものではありません。公式の権限ルールと設定ファイルの説明を確認し、必要最小限の権限で開始してください。特に、書き込み、外部通信、シェルコマンドの実行を許す場合は、対象と目的を個別に確認します。

Skillファイルに検査順序と証拠要件を記述します

公式ドキュメントに沿ったSkillの配置例は、リポジトリ内の.claude/skills/security-audit/SKILL.mdです。Skillのフロントマターではnameとdescriptionが必須項目として示されています。形式や利用方法は変更される可能性があるため、導入時にはClaude CodeのSkills公式説明を確認してください。

以下は、監査の境界と報告要件を含めるための最小限の例です。実際の許可範囲やツール名に合わせて調整します。

---
name: security-audit
description: 許可されたリポジトリのコードを、指定されたセキュリティ観点と証拠要件に沿って確認します。
---

# 目的
指定された対象のコードを確認し、再検証可能な懸念事項を整理します。

# 範囲
- 指示で明示されたディレクトリと実行経路だけを対象にする
- 認証情報、個人情報、外部サービスへのアクセスを行わない
- 対象範囲が不明な場合は、推測で監査を進めず確認を求める

# 手順
- プロジェクト構成と関連する設定・呼び出し元を確認する
- 入力元、データの処理、危険な操作への到達経路を追う
- 許可された場合に限り、設定済みのスキャナーを実行する
- コード位置、該当する根拠、成立条件を記録する
- 確認済み、要確認、誤検知の候補に分けて報告する

# 報告要件
根拠が確認できない内容を確定した脆弱性として記載しない。
修正案は影響範囲と検証方法を添えて提示する。

「必要に応じてスキャナーを使う」だけでは実行条件が曖昧です。どのツールがすでに設定されているか、実行が許可されているか、結果をどのファイルや記録で確認するかを指示に加えます。利用できるツールや保護機能の範囲は設定に依存するため、Claude Codeのセキュリティ説明も合わせて確認します。

承認済みのコードでスキャンし、発見を検証します

監査は、実行前に対象と権限を確定し、実行後に証拠を確認する流れにします。例のsample-appは自社で管理し、確認を許可されたコードとします。

• 対象のブランチとディレクトリを指定し、除外対象も記録します。
• Claude Codeにプロジェクト構成、関連する入力経路、重要な設定を先に確認させます。
• Skillに定めた観点に沿ってコードを調べさせ、必要な場合だけ許可済みスキャナーを実行します。
• 検出ごとにファイルと行、関連する呼び出し元、入力から処理までの根拠を収集します。
• 該当コードを開いて根拠を照合し、成立条件が説明できないものは確定扱いにしません。
• 監査範囲、使用したツール、未確認箇所を含めて結果を保存します。

スキャン結果はどのように検証・分類しますか。
「入力値が危険な処理に渡る」という指摘なら、実際に入力が制御可能か、途中で検証・変換されるか、該当処理に到達する経路があるかをコードで確認します。スキャナーの警告とコード上の証拠が一致しない場合は、警告をそのまま確定所見にせず、差異を記録します。

分類は、根拠が確認できた問題、成立条件などの追加確認が必要な項目、コードや実行経路と照合して問題が成立しないと判断した項目に分けます。CWEの説明では、ソフトウェアの弱点と、実際に悪用可能な脆弱性は同じ意味ではありません。CWEの定義に関するFAQを参照し、弱点の候補を実際の影響が確定した脆弱性と混同しないようにします。

Claude Codeの出力にファイル名や行番号があっても、それだけでは証拠になりません。該当コード、呼び出し経路、設定、ツール出力が同じ結論を支えているかを人が確認します。

発見を追跡可能な脆弱性レポートにまとめます

Claude Codeのコードスキャン結果を、どのように脆弱性レポートへ整理しますか。
指摘をそのまま並べるのではなく、別の担当者が同じ場所を確認して判断を再現できる情報に整えます。報告には、次の要素を含めます。

• 分類と状態：弱点の種類、確認済みか要確認か、誤検知と判断した根拠
• 対象位置：ファイル、行、関連する関数や設定
• 証拠：問題につながるコード、データの流れ、スキャナー出力
• 影響判断：成立条件、影響する機能やデータ、判断に残る不確実性
• 修正案：変更する処理と、既存機能への影響を抑える方法
• 検証方法：修正後に確認するテストやスキャン、再確認した担当者

スキャンの記録が「入力の検証が不足している可能性」とだけ述べている場合、そのまま確定した脆弱性とは書きません。まず入力元と処理箇所を結び付け、到達条件が確認できれば根拠と影響を記載します。確認できない場合は「要確認」とし、追加で必要なログ、設定、実行時の確認事項を示します。

報告の枠組みは、実装者が修正し、別の担当者が再検証できることを基準に整えます。NISTのSSDFは、セキュアなソフトウェア開発の取り組みを4つの実践グループに整理しています。NIST SP 800-218を参照し、発見の記録だけでなく、修正と再確認まで工程に含めてください。

提出前に確認項目を一つずつチェックします

次の項目を実行し、未確認の欄があれば報告書に明記します。

• [ ] 監査対象の所有者と許可範囲を確認し、対象外のコードやサービスに触れていない
• [ ] 使用した権限、ツール、対象ブランチを記録し、許可されていない操作を実行していない
• [ ] 秘密情報や個人情報を不要にプロンプトやレポートへ複製していない
• [ ] 重大な指摘について、コード位置、データの流れ、成立条件を担当者が確認した
• [ ] ツールが検査できない言語、設定、実行時の挙動を未確認事項として区別した
• [ ] 修正後の確認方法を記し、再スキャンや関連テストの結果を追記できる状態にした
• [ ] 推測や未検証の影響を、確定した脆弱性として報告していない

特に、認証やアクセス制御に関わる問題、機密データへの到達、複数コンポーネントをまたぐ処理など、影響の判断に実行環境や設計背景が必要な場合は、セキュリティ担当者の追加評価を行います。自動スキャンで指摘がなかったことも、監査対象に弱点が存在しない証明にはなりません。

運用環境を選び、監査を継続可能にします

ローカル環境は、短時間の確認や手元のコード修正と同時に進める用途に向きます。一方、依存ツールの導入状態が開発者ごとに異なる、共有された監査環境を管理しにくい、長時間の作業を手元の端末に依存させたくない、といった場合には運用上の負担が生じます。遠隔のMac環境も、権限設計や秘密情報の扱いを別途決める必要があるため、監査の正しさを自動で高めるものではありません。

まずは許可されたリポジトリで小さく試し、Skillの指示と人手の確認にずれがないかを確かめます。継続的な遠隔開発環境が必要な場合は、Zutcloudの日本向けMacレンタル情報で提供内容を確認し、導入条件の確認にはヘルプセンターを参照してください。既存のローカル環境で短時間の監査を完結できるなら、レンタル環境を追加する必要はありません。