Claude Code AIセキュリティ監査チュートリアル：Security Audit Skillのインストール、コードスキャンから脆弱性修正までの完全実践

NIST SP 800-218（SSDF）は、安全なソフトウェア開発を4つの実践グループに整理しています。この枠組みに沿って導入するなら、Security Audit SkillはClaude Codeを使った補助監査として扱い、出所と権限を確認してから対象を限定してスキャンしてください。指摘は開発者が証拠を検証し、修正後に再スキャンして初めて処理済みと判断します。AIの報告だけで安全性を確定することはできません。

今週は、まず隔離した作業用プロジェクトでスキルファイルと許可範囲を確認し、機密情報を含まないコードで一連の流れを試してください。Claude Codeでコードを確認したい開発者は、導入から再検証までの手順を追えます。セキュリティ担当者は権限と証拠の見方を、技術責任者はチーム導入の条件を確認できます。

導入前に監査の役割と限界を決める

Security Audit Skillは、監査の進め方や確認観点をClaude Codeに伝えるためのスキルです。スキルを追加すれば、それだけで脆弱性が証明されたり、プロジェクト全体の安全性が保証されたりするわけではありません。スキルの概要とSecurity Audit Skillの実際の定義ファイルを読み、何を調べ、どのような出力を求めるものかを先に把握してください。

監査の手順は、出所の確認、権限設定、対象の限定、指摘の検証、修正、再スキャンの順にします。これは、NIST SP 800-218のバージョン1.1が示す安全な開発の考え方とも整合します。スキャン結果は修正候補を見つけるための情報であり、手動レビューや必要なテストを省略する理由にはなりません。

Security Audit Skillをどこから入手し、信頼性をどう確かめますか。
提供元のリポジトリを開き、READMEに記された取得・導入方法を確認します。コマンドは記憶や第三者の記事から転記せず、リポジトリの記載と照合してください。配布元、変更履歴、ライセンス、スキルファイルの内容を確認できない場合は、導入を保留します。

第一段階：導入と権限を検査する

Claude Code本体がまだ使える状態でなければ、まず公式の導入手順を確認します。続いてリポジトリが案内する方法でスキルを取得し、実行前にファイルの差分と内容を読みます。スキルが何を指示しているかを確認しないまま、プロジェクト全体で有効にするのは避けてください。

次に、Claude Codeに許可する操作を監査目的に合わせて絞ります。公式のCLI権限説明で現在の権限設定を確認し、読み取りだけで足りる作業では、ファイル変更やシェル実行を安易に許可しないでください。スキルの指示文と実行権限は別のものです。説明文に「安全」と書かれていても、アクセスできるファイルや実行可能な操作まで安全になるわけではありません。

最初はバージョン管理下の隔離プロジェクトか、監査用の作業コピーで試します。実行前の変更をコミットまたは退避し、監査中に予期しない編集が起きても差分を確認できる状態にします。機密情報を含む本番環境や共有作業環境で、導入確認と初回実行を同時に進めないでください。

注意：スキルファイルに外部送信、広範なファイル読み取り、破壊的な操作につながる指示がないか確認してください。挙動を説明できない部分があれば、許可を与える前に切り分けます。

第二段階：対象と除外範囲を明示する

スキャン前に、対象ディレクトリ、確認したい機能、対象外にする領域を決めます。リポジトリ全体を一度に渡すより、認証、入力処理、データベースアクセスなど、確認目的に関係する範囲を指定したほうが、指摘をコードや実行経路に結び付けやすくなります。

たとえば、次のような依頼文を使い、実際のパスや機能名に置き換えます。これはプロンプト例であり、実行コマンドや設定ファイルではありません。

「src/auth/とsrc/api/の入力検証、認証、認可、データベース呼び出しを確認してください。vendor/と生成コードは対象外です。指摘ごとにファイルと行、到達条件、影響する処理、根拠を示してください。確証がない場合は脆弱性と断定せず、不足情報を明記してください。」

スキャンに不要な秘密鍵、アクセストークン、個人情報、実データは除去するか、ダミー値に置き換えます。テスト用の設定ファイルも、本物の認証情報が残っていないか確認してください。除外範囲を広げすぎると重要な処理を見落とす可能性があるため、除外理由を記録し、レビュー対象者が妥当性を確認できるようにします。

スキャン前にどの権限と範囲を整えるべきですか。
読み取りのみで調べられる段階では、変更権限を付与しない方針にします。対象ディレクトリ、除外対象、調べる脅威の種類、必要なプロジェクト情報を明記し、認証情報や本番データは渡さないでください。修正まで依頼する場合も、変更前後の差分をレビューできる環境に限定します。

第三段階：報告の根拠を読み、真偽を判定する

報告を受け取ったら、深刻度ラベルより先に、ファイル位置、入力から問題箇所までの経路、攻撃者が制御できる条件、実際の影響を確認します。OWASPのセキュアコードレビュー指針に沿い、該当コードだけでなく、呼び出し元、検証処理、権限境界も追ってください。

たとえば、入力値がSQL文に連結されているという指摘なら、値が外部から制御可能か、実際に該当クエリへ到達するか、プレースホルダーなどで安全に扱われているかを確かめます。CWE-89はSQLインジェクションの分類と緩和策を説明していますが、分類名が一致するだけでは、そのコードに脆弱性がある証拠にはなりません。コードの流れや安全なクエリ処理を示すテスト結果を根拠として残します。

指摘は、次の三つの判定に分けると後続作業が明確になります。

確認済み：到達可能な入力経路と影響をコードまたは再現テストで説明できる状態です。
誤検知：安全な処理、到達不能な経路、または前提条件の不成立をコード上で確認できた状態です。
要追加確認：呼び出し元、実行時設定、権限などの情報が足りず、結論を出せない状態です。

この判定はツールの深刻度を置き換えるものではなく、根拠の確かさを整理するためのものです。OWASPの静的解析ガイドも、静的解析を開発上の確認手段として位置付けています。誤検知と判断した場合も、理由や参照コードを記録し、次回のレビューで同じ議論を繰り返さないようにします。

第四段階：修正案をレビューして再スキャンする

確認済みの問題は、指摘文をそのままコード変更に置き換えず、プロジェクトの設計に合う修正方法を開発者が選びます。入力検証の追加だけで解決するのか、安全なAPIへの置き換えが必要なのか、認可の位置を直すべきなのかを、データの流れと既存設計から判断してください。

修正後は、該当する単体テストや統合テストを実行し、差分レビューで意図しない変更が混ざっていないか確認します。その後、同じ対象範囲と同じ依頼条件で再スキャンします。指摘が消えたことだけではなく、修正による回帰がないこと、関連する別経路が残っていないことも確認します。

修正後の再スキャンで何をもって完了としますか。
修正箇所、対応した指摘、根拠となるコード変更、関連テスト、再スキャン結果をひとまとめに記録します。未解決の指摘は、未確認の理由、影響範囲、次の対応者を明記して残します。一度のスキャンで全ての脆弱性を検出できるとは限らないため、監査結果を包括的な安全証明として扱わないでください。

今週の導入判断：条件に合う実行環境を選ぶ

実行場所はMacであることを前提にせず、コードへのアクセス方法、データ持ち出しの制約、必要な開発環境、権限管理のしやすさで決めます。手元の環境でリポジトリと必要な依存関係を扱え、機密情報を外へ出さずに運用できるなら、ローカルでの試行から始められます。遠隔作業が必要でも、データ管理や認証の要件を満たせないなら、機密性の高いコードをその環境に置かないでください。

実行環境の選択チェック

上から順に確認し、該当する分岐を選んでください。必須条件を確認できないときは、別の環境へ急いで移るのではなく、条件が明らかになるまでスキャンを保留します。

[ ] コードをローカルに保持する必要があり、手元の環境で依存関係とテストを扱える
→ ローカル実行を選びます。 手元で条件を満たせない場合は、管理されたリモート環境のアクセス制御とデータ保護条件を確認します。
[ ] チームで作業環境を共有する必要があり、利用者ごとの権限とデータの扱いを確認できる
→ 管理されたリモート環境を選びます。 条件を説明できない場合は、機密コードを持ち込まず管理者へ確認します。
[ ] macOS固有の動作確認が監査目的に含まれ、既存環境では必要な確認を実行できない
→ Mac環境を候補にします。 macOS固有の要件がなければ、Macを前提に選ぶ必要はありません。
[ ] 環境情報、認証方法、データ保護条件のどれかを確認できない
→ 環境選定とスキャンを保留します。 必要な情報がそろってから、最小権限で再開します。

このチェックは環境選定のための運用上の目安であり、脆弱性の深刻度や環境の安全性を保証する評価ではありません。現在の実行環境に、設定の属人化、共有時の権限管理の難しさ、macOS固有テストの不足があるなら、要件を満たすMac環境が選択肢になることがあります。一方、安定した長期利用が必要な場合や物理インターフェースが不可欠な場合は、レンタルが最適とは限りません。

遠隔Macを短期間の検証に使う場合は、作業前に本サイトの案内で提供内容を確認し、不明な環境条件は本サイトへ問い合わせてから、コードを持ち込むか判断してください。

最後に、導入元の記録、スキル内容の確認、最小権限、対象と除外範囲、機密情報の除去、指摘の根拠、修正差分とテスト、再スキャン、未解決リスクの担当者を一つずつ確認します。すべてを説明できる状態になってから、チームの日常的なコードレビューへ広げてください。