症状：AI Coding Agentが監査を始めない、候補が多すぎて確認できない。
最短解決策：security-audit-skillを隔離環境と最小権限で動かし、機械的な初期監査に限定して、重要な指摘は人間が再確認してください。
このスキルはコードベースの初期監査、定型的な脆弱性調査、証拠付きレポートの下書きに向いています。一方、実稼働環境への侵入テスト、攻撃の自動実行、リリース前の最終承認まで任せるものではありません。
この記事を読むべき人
DevSecOpsの監査手順を統一したい技術責任者、バックエンド開発者、オープンソースプロジェクトの保守担当者向けです。特に、権限、ログ、監査コスト、手動レビューの分担を決める段階で役立ちます。
Last updated
2026年9月21日。公式リポジトリのREADME、SKILL.md、レポートSchema、検証スクリプト、テストファイルを確認した内容です。インストール方式や対応エージェントは更新される可能性があるため、実行前にsecurity-audit-skill公式リポジトリの最新状態を再確認してください。
監査対象の切り分け
最初に、監査の目的を3種類に分けます。
- 全量監査：リポジトリ全体の構成、入力面、依存関係、権限境界を把握します。
- 定向調査：認証、ファイル処理、API入力など、対象を絞って候補を探します。
- セキュリティ問答：特定の関数や設定について、コードと設定を根拠に確認します。
公式のSKILL.mdでは、偵察、範囲の記録、候補の発見、検証、整理、レポート化という6段階の流れが示されています。公式のSKILL.mdを読まずに、単に「このコードを安全か確認して」と依頼すると、監査範囲と証拠の不足に気付きにくくなります。
このスキルの長所は、同じ観点を何度も確認できることです。短所は、コードの業務仕様や運用上の例外を完全には理解できず、候補を脆弱性として断定する危険が残ることです。
インストールと起動のつまずき
導入前の確認
- Node.jsを用意します。入手先はNode.js公式ダウンロードページを使い、プロジェクトで許可されたバージョンを選びます。
- 公式READMEに記載された
skills addの手順で、security-audit-skillを追加します。コマンドはリポジトリの更新で変わる可能性があるため、古い記事からコピーしないでください。 - AI Coding Agentがスキルの配置場所を読み取れることを確認します。
- 対象コードを別の作業ディレクトリに配置し、読み取り専用を基本にします。
- 初回は小規模な検証用リポジトリで、監査開始、ファイル生成、終了処理を確認します。
Claude Codeで使う場合は、まずClaude Code公式の開始手順に沿って、エージェント自体が正常に起動する状態を作ります。Codexなど別のエージェントで使えるかは、公式リポジトリがそのエージェントへの対応を明示しているか、実際にスキルを認識するかで判断してください。コミュニティの設定例だけで互換性を保証しないことが重要です。
起動しない場合の確認順
- スキルのパスが、現在起動しているエージェントの探索対象に入っているか。
- 監査対象の作業ディレクトリを、エージェントが参照できているか。
- Node.jsと必要なツール呼び出しが利用できるか。
- 子エージェントを並列起動する設定が、実行環境の権限で許可されているか。
- リポジトリの読み取り、ビルド、テスト実行に必要な権限が不足していないか。
インストール成功と監査開始は別問題です。スキル名を認識していても、実行ツール、作業ディレクトリ、権限のいずれかが欠けると、質問への一般的な回答だけが返る場合があります。
偵察とカバレッジ台帳
AI安全監査の誤りは、脆弱性を見逃すことだけではありません。人気のあるsrcやAPIディレクトリだけを調べ、ジョブ、管理用スクリプト、設定ファイル、移行処理を対象外にすることも危険です。
最初の偵察では、次の項目を記録します。
- アプリケーションの構成と主要な実行経路
- 外部入力、ファイル、環境変数、Webhookの入口
- 認証、認可、信頼境界
- 外部サービスと秘密情報の受け渡し
- 調査済み、未調査、対象外にしたディレクトリ
例えば、決済APIを調べる際にルートハンドラーだけを対象にすると、非同期ジョブが同じ入力を再利用している事実を見落とす可能性があります。台帳に「API入口は確認済み、バックグラウンドジョブは未確認」と残せば、次の探索対象が明確になります。
監査方式の選択
| 方式 | 向いている場面 | 必要な確認 | 主な弱点 |
|---|---|---|---|
| 全量監査 | 新規取得したリポジトリ、構成変更後 | 全ディレクトリと入口の台帳 | 時間とレビュー量が増える |
| 定向調査 | 認証や入力処理の修正後 | 対象範囲と除外理由 | 周辺コードを見落としやすい |
| セキュリティ問答 | 既知の関数や設定の確認 | 回答の根拠ファイルと行 | 広い問題の発見には不向き |
誤検知を減らす検証設計
AI Coding Agentによる自動安全監査で誤検知を減らすには、発見と検証を分離します。発見側は候補を広く拾い、検証側は再現条件、到達可能性、影響範囲を確認します。同じ推論だけで発見から確定まで進める設計は避けてください。
公式Schemaでは、少なくとも次の状態を区別して扱います。
confirmed：コードと実行経路の証拠がそろい、問題として確認できるものneeds_validation：疑わしいが、追加の実行確認や仕様確認が必要なものrejected：調査の結果、脆弱性として扱えないもの
状態の意味は、公式のreport-schema.jsonと検証スクリプトで確認します。needs_validationをそのまま重大な問題としてチケット化すると、開発チームの調査負担が増え、重要な指摘が埋もれます。
注意：対象コードの実行、ビルド、ブラウザー操作、ファジングは、実データと本番資格情報から切り離してください。監査用のコピーを作り、失敗しても復旧できる状態を先に用意します。
サンドボックス権限の確認表
| 管理項目 | 推奨する初期設定 | 実行前の判定 |
|---|---|---|
| ネットワーク | 原則拒否。必要な宛先だけ一時許可 | 外部通信の理由を記録できるか |
| 秘密情報 | 本番キー、個人トークンを渡さない | 環境変数と設定ファイルを確認したか |
| 書き込み先 | 専用の一時ディレクトリに限定 | リポジトリ本体を変更しないか |
| 実行権限 | 非特権ユーザーを使用 | 管理者権限を要求していないか |
| リソース | CPU、メモリ、実行時間を運用側で制限 | 停止手順とログがあるか |
OSレベルの隔離が用意できない場合、監査対象を信頼できるコードだけに限定し、ビルドや実行を伴う検証を後回しにします。スキルが動くことと、安全に動かせることは同じではありません。
findings.jsonからレビュー可能な報告書へ
機械可読の結果は、チームが判断できる証拠に変換して初めて使えます。各Findingには、少なくとも対象ファイル、位置、問題の種類、再現条件、証拠、影響範囲、修正案、検証状態を対応付けます。
再現手順も、攻撃対象へそのまま使える実行コードではなく、テスト用入力、到達した関数、観測された結果を安全な範囲で記述します。外部システムへの接続や実在サービスへの攻撃手順は、監査レポートに含めないでください。
変換の流れは次の5段階です。
- Schemaと検証スクリプトでJSONの構造を確認します。
confirmed、needs_validation、rejectedを分けます。- 同じ根拠を持つ重複候補をまとめます。
- 問題、強化提案、未確認候補を別の章にします。
- Markdownで、概要、証拠、影響、再現条件、修正案、残課題を出力します。
公式テストファイルにも、期待される入力と出力の確認材料があります。公式テストファイルと照合し、JSONが生成されたという理由だけで内容を信頼しないでください。
実運用での判断
security-audit-skillを導入する価値が高いのは、監査対象が頻繁に変わり、同じ確認項目を繰り返し実行するチームです。反対に、仕様が口頭でしか存在しないシステム、実データへの接続が不可避な検証、重大なリスクを即時判断する案件では、人間のセキュリティ担当者を中心に置く必要があります。
利点
- 初期偵察と監査範囲の記録を標準化しやすい
- 繰り返しのコード確認を自動化できる
- Findingを構造化し、レビュー担当者へ渡しやすい
- 定向調査と全量監査を使い分けられる
欠点
- 業務仕様を誤解した候補が出る
- ビルドや実行を許可すると隔離リスクが増える
- エージェントごとのスキル互換性を個別に確認する必要がある
needs_validationのレビューがなくなるわけではない
ローカル環境とクラウドMacの選択
手元の端末だけで試す場合、導入は速い一方、開発ツールと個人データが同じ環境に残りやすく、長時間処理中に端末を占有します。端末の権限設計が既に整っていない場合、監査用の専用環境を分けるまでが本当の作業になります。
| 選択肢 | 適する条件 | 注意点 |
|---|---|---|
| 手元のMac | 小規模な検証、読み取り中心の監査 | 端末内の秘密情報と作業領域を分離する |
| 独立した開発環境 | 継続的な監査、複数担当者 | アクセス権、ログ保存、破棄手順を設計する |
| クラウドMac | 手元の端末に余裕がない、遠隔で引き継ぎたい | セッション保持、接続元、ログとデータ削除を確認する |
Macを使った開発環境の準備を比較するなら、まずKvmzenのMacレンタル利用ガイドで接続方法と運用上の確認点を整理し、必要な地域の日本向けMacレンタル案内を確認してください。これは監査結果の正確性を保証するものではなく、隔離された作業場所を用意するための選択肢です。
レンタルを検討する境界
ローカル端末での試走が終わり、監査対象を継続的に扱う段階では、個人のMacをそのまま使う方法に弱点があります。開発作業と監査データが混在しやすいこと、端末を閉じると長時間処理や引き継ぎが止まりやすいこと、担当者ごとに権限とログの設定がばらつくことです。
その場合、KvmzenのMacレンタルを独立した開発環境として比較する価値があります。必要な期間だけ環境を分け、セッション保持やログ保存の手順をチーム側で定義できるなら、手元の端末不足を補う現実的な方法になります。ただし、物理インターフェースが必要な監査や、長期にわたり常時高負荷で使う用途では、自社設備や専用環境の方が適する場合もあります。
最初にローカルで小さなコードベースを試し、confirmedとneeds_validationの扱い、権限、ログ、破棄手順を確認してください。そのうえで隔離環境が必要になった段階で、KvmzenのMac環境を候補の一つとして比較すると、監査結果ではなく実行環境の不足を理由に作業が止まる事態を避けやすくなります。