【2026年版】AIで自社システムの脆弱性を自己診断する実践ガイド｜Claude・ChatGPT・GitHubと無料OSSツールで始める「攻撃者目線」の点検手順
- 1. はじめに——攻撃者がAIで探す時代、守る側もAIで先に見つける
- 2. 前提——自己診断で「やっていいこと・いけないこと」
- 3. 全体像——AI×無料ツールで行う5つの診断領域
- 4. ステップ1：外から見える自社を棚卸しする
- 5. ステップ2：Webサイト・Webアプリを診断する
- 6. ステップ3：ソースコードをAIでレビューする
- 7. ステップ4：部品（ライブラリ）と漏れた秘密情報を探す
- 8. ステップ5：クラウド・SaaSの設定を点検する
- 9. AIに結果を読ませるときのプロンプト設計
- 10. 落とし穴——AI・ツール活用で起きがちな5つの失敗
- 11. 規模別の「最小構成」プラン
- 12. よくある質問（Q&A）
- 13. まとめ——「攻撃者より先に、自分で見つける」を習慣にする
- 14. 参考リンク
1. はじめに——攻撃者がAIで探す時代、守る側もAIで先に見つける
2026年に入り、OpenAIの「Codex Security」やAnthropicの「Claude Security」など、AIがソースコードを読み、脆弱性を見つけて修正案まで出すツールが相次いで登場しました。これは守る側にとって大きな武器ですが、同じことは攻撃者にもできます。公開されているWebサイトやVPN装置の弱点を、AIを使って短時間で大量に探す攻撃はすでに現実のものです。
一方で、外部の脆弱性診断サービスに依頼すると、Webサイト1つでも数十万円以上かかることが珍しくありません。年1回の診断だけでは、日々の更新で生まれる新しい穴に追いつけないのも事実です。
本記事の核心は、「外部診断の代わり」ではなく「外部診断と外部診断のあいだを埋める自己診断」をAIで回すことです。筆者はネットワーク機器のTAC（技術サポート）やNOC（運用監視）に長年携わってきましたが、現場で見てきた事故の多くは「誰かが一度確認していれば防げた」ものでした。AIは、その「一度確認する」ハードルを大きく下げてくれます。
前回の記事「大企業のセキュリティ対策 見直しチェックリスト60」「中小企業のセキュリティ簡易チェック30」で見つかった課題を、実際に技術的に確かめる手順としてもお使いいただけます。
2. 前提——自己診断で「やっていいこと・いけないこと」
最初に、最も重要なルールを確認します。診断ツールは、使い方を誤ると攻撃と区別がつきません。
| 区分 | 内容 |
|---|---|
| やってよい | 自社が所有・管理し、責任者の承認を得たシステムの診断 |
| 事前確認が必要 | レンタルサーバー・クラウド・SaaS上のシステム（提供事業者の規約で禁止・申請制の場合がある）。制作会社や保守会社が管理するサイト（契約と同意が必要） |
| やってはいけない | 他社・取引先・グループ外のシステムの無断診断。「同じサーバーに同居している他社サイト」への影響も含む |
あわせて、次の3点を守ってください。
- 書面での承認を取る：診断の対象（URL・IPアドレス）、期間、実施者、使うツールを1枚にまとめ、責任者の承認を残します。トラブル時に「正当な診断だった」と説明する証拠になります。
- 本番環境への影響を想定する：能動的なスキャンは、大量のリクエストでサイトを重くしたり、問い合わせフォームから大量の送信をしてしまうことがあります。可能ならテスト環境で、本番なら夜間・低負荷の時間帯に、まずは受動的（パッシブ）なスキャンから始めます。
- AIに渡すデータを選ぶ：ソースコードや診断結果には、パスワード、APIキー、顧客情報が含まれることがあります。学習に使われない法人向けプランを使い、秘密情報は伏せてから渡すのが原則です。
本記事で紹介する手順は、すべて自社システムの防御を目的としたものです。他者のシステムに対して実行すると、不正アクセス禁止法違反や業務妨害に問われるおそれがあります。
3. 全体像——AI×無料ツールで行う5つの診断領域
自己診断は、次の5つの領域に分けると整理しやすくなります。AIの役割は「ツールそのもの」である場合と、「ツールの結果を読み解く通訳」である場合の2通りがあります。
| ステップ | 診断領域 | 主なツール | AIの役割 | 難易度 |
|---|---|---|---|---|
| 1 | 外から見える自社の棚卸し | Nmap、testssl.sh、証明書の公開ログ検索 | 結果の解釈・危険度の判断 | ★ |
| 2 | Webサイト・Webアプリ | OWASP ZAP、Nuclei、WPScan | 大量の検出結果の優先順位付け | ★★ |
| 3 | ソースコード | Claude Code（/security-review）、Codex Security、GitHub CodeQL＋Copilot Autofix、Semgrep | AI自身が脆弱性を発見・修正案を提示 | ★★ |
| 4 | 部品（ライブラリ）と秘密情報 | OSV-Scanner、Trivy、Gitleaks、Dependabot | 影響範囲の調査・更新手順の作成 | ★★ |
| 5 | クラウド・SaaSの設定 | Prowler、Microsoft Secure Score、Google Workspaceのセキュリティ状況ページ | 設定の意味と修正手順の解説 | ★★ |
中小企業でIT担当者が1人、あるいは不在の場合は、ステップ1・2・5から始めるのがおすすめです。自社でソフトウェアを開発している会社は、ステップ3・4の効果が特に大きくなります。
4. ステップ1：外から見える自社を棚卸しする
攻撃者が最初にやるのは「この会社は、インターネットに何を公開しているか」の調査です。守る側も同じことから始めます。
4.1 公開しているドメイン・サーバーを洗い出す
SSL証明書は発行されると公開ログ（Certificate Transparency）に記録されるため、「crt.sh」などの検索サイトで自社ドメインを調べると、忘れていたサブドメインや古いキャンペーンサイトが見つかることがよくあります。
4.2 開いているポートと暗号化の設定を確認する
- Nmap：自社のサーバーやVPN装置のIPアドレスに対し、外部から接続できるポート（入口）を調べます。リモートデスクトップ（3389番）やデータベースのポートが外部に開いていれば、それだけで重大な問題です。
- testssl.sh：Webサイトの暗号化設定（古いTLSバージョンや弱い暗号が残っていないか）を確認します。
bash
# 例：自社サイトのTLS設定を確認（自社の管理対象にのみ実行）
./testssl.sh https://www.example.co.jp4.3 AIに結果を読ませる
これらのツールの出力は専門的で、慣れないと判断が難しいものです。そこでAIの出番です。
text
あなたは企業のネットワークセキュリティ担当者です。
以下は当社が管理するサーバー（外部公開）に対するNmapの結果です。
1. 外部に公開すべきでないと考えられるポートを、危険度（高・中・低）付きで挙げてください。
2. それぞれについて、確認すべきことと対処方法を、IT担当者が実行できる粒度で説明してください。
3. 判断に追加情報が必要な項目は「要確認」として、何を確認すべきか書いてください。
（IPアドレスは伏せ字にしています）
---
（ここにNmapの結果を貼り付け）ポイントは、「要確認」という逃げ道を与えることです。AIに断定を求めすぎると、もっともらしい誤り（ハルシネーション）が増えます。
5. ステップ2：Webサイト・Webアプリを診断する
5.1 OWASP ZAP：まずは「ベースラインスキャン」から
OWASP ZAPは、世界で最も広く使われている無料のWeb脆弱性スキャナーの一つです。最初は、サイトを巡回してレスポンスを観察するだけの**ベースラインスキャン（受動的スキャン）**から始めます。攻撃的なリクエストを送らないため、本番環境への影響が比較的小さいのが特長です。
bash
# 例：Dockerでベースラインスキャンを実行し、HTMLレポートを出力
docker run --rm -v $(pwd):/zap/wrk ghcr.io/zaproxy/zaproxy:stable \
zap-baseline.py -t https://www.example.co.jp -r report.htmlセキュリティヘッダーの不足、Cookieの設定不備、情報が漏れるエラーメッセージなど、設定ミス系の問題を広く拾えます。国際的なWeb脆弱性ランキング「OWASP Top 10:2025」で2位に入った「セキュリティの設定ミス」は、まさにここで見つかる領域です。
5.2 Nuclei・WPScan：既知の脆弱性をテンプレートで確認する
- Nuclei：コミュニティが作成した数千のテンプレートで、既知の脆弱性や設定ミスを確認するツールです。能動的にリクエストを送るため、テスト環境か、承認を得た時間帯に実行します。
- WPScan：WordPressのバージョン、プラグイン、テーマの既知の脆弱性を確認します。中小企業のサイトの多くがWordPressであることを考えると、費用対効果の高いツールです。
5.3 AIで「本当に危ないもの」を絞り込む
スキャナーは数十〜数百件の警告を出すことがあり、そのすべてが本当の問題ではありません。レポートをAIに渡し、次のように依頼すると、対応の優先順位が付けやすくなります。
text
以下はOWASP ZAPの診断レポート（自社サイト、テスト環境）です。
- 誤検知の可能性が高いもの／実際に悪用され得るものに分類してください。
- 悪用され得るものは、想定される被害と修正方法（Apache／nginx／WordPressの設定例）を示してください。
- 根拠が不確かなものは推測であることを明記してください。6. ステップ3：ソースコードをAIでレビューする
自社でWebサービスやアプリを開発している場合、AIによるコードレビューは2026年時点で最も進化している領域です。
| ツール | 提供元 | 特徴 | 利用条件（2026年10月時点の公表情報） |
|---|---|---|---|
| Claude Code「/security-review」コマンド・GitHub Action | Anthropic | ターミナルから実行、またはプルリクエストごとに自動レビューし、修正案をコメント | Claude Codeの利用者 |
| Claude Security | Anthropic | コードベース全体をスキャンし、確信度・深刻度付きで報告。定期スキャンやSlack・Jira連携 | 2026年5月からEnterprise向けにパブリックベータ |
| Codex Security（旧Aardvark） | OpenAI | 脅威モデルを自動作成し、サンドボックスで検証してから報告 | 2026年3月に研究プレビューとして提供開始 |
| CodeQL＋Copilot Autofix | GitHub | 静的解析で検出し、AIが修正案を自動生成 | 公開リポジトリは無料、非公開はGitHub Code Securityの契約が必要 |
| Semgrep（Community Edition） | Semgrep | ルールベースの軽量な静的解析。CIに組み込みやすい | 無料で利用可能 |
各サービスの提供範囲や料金は頻繁に変わります。導入前に必ず公式情報をご確認ください。
6.1 おすすめの組み合わせ
AIのレビューは、ルールベースの静的解析では見つけにくい認可の不備（他人のデータが見えてしまう）やビジネスロジックの欠陥に強い一方、毎回同じ結果を返すとは限りません。そのため、
- CodeQLやSemgrepなどのルールベースの解析で、再現性のある「土台」の検査を行い、
- Claude CodeやCodex SecurityなどのAIで、文脈を読んだ深いレビューを行い、
- 人間（開発者）が最終判断する、
という三段構えが現実的です。Anthropic自身も、自動レビューは既存のレビューを「置き換えるものではなく補完するもの」と位置付けています。
6.2 AIへの指示例（Claude Codeなどのコーディングエージェント）
text
このリポジトリのセキュリティレビューを行ってください。特に以下を重点的に確認してください。
- ログインユーザーが、URLやIDを書き換えて他のユーザーのデータにアクセスできる箇所
- 管理者向け機能で、権限チェックが漏れている箇所
- 外部入力をSQL・シェルコマンド・テンプレートに渡している箇所
- ハードコードされたパスワード・APIキー
各指摘には、該当ファイルと行、悪用シナリオの概要、修正案、確信度（高・中・低）を付けてください。
コードの修正はまだ行わず、報告のみとしてください。最後の一文が重要です。AIエージェントにいきなり修正やコマンド実行をさせず、まず報告させることで、意図しない変更を防げます。
7. ステップ4：部品（ライブラリ）と漏れた秘密情報を探す
7.1 依存ライブラリの既知の脆弱性
現代のシステムは、自社で書いたコードより**外部のライブラリ（部品）**のほうがはるかに多いのが普通です。OWASP Top 10:2025でも「ソフトウェアサプライチェーンの不備」が3位に入りました。
- OSV-Scanner（Google）：プロジェクトが使っているライブラリを、公開脆弱性データベースと照合します。
- Trivy（Aqua Security）：ライブラリに加え、コンテナイメージやサーバーの設定も検査できます。
- Dependabot（GitHub）：脆弱なライブラリを検知し、更新のプルリクエストを自動作成します。
7.2 漏れた秘密情報（シークレット）
GitleaksやTruffleHogは、ソースコードやGitの履歴に、パスワードやAPIキーが残っていないかを調べるツールです。「一度コミットして、後で削除した」キーも履歴に残っているため、過去分まで含めて検査します。見つかったキーは、**削除ではなく無効化（ローテーション）**が必要です。
7.3 AIの使い方
脆弱性が見つかったライブラリについて、「自社のコードでその脆弱な機能を使っているか」「更新すると何が壊れる可能性があるか」をAIに調べさせると、対応判断が速くなります。
8. ステップ5：クラウド・SaaSの設定を点検する
情報漏えいの多くは、高度な攻撃ではなく設定ミスから起きています。
- Prowler：AWS・Azure・Google Cloudなどの設定を、数百項目のベストプラクティスと照らして確認する無料ツールです。
- Microsoft Secure Score（Microsoft 365）、Google Workspaceのセキュリティ状況ページ：管理画面から、多要素認証の設定率や外部共有の状況などを確認できます。追加費用なしで使えるため、中小企業にも特におすすめです。
これらの結果は英語・専門用語が多いため、AIに「この項目は何を意味し、当社のような従業員30名の会社で対応すべきか」と聞くと、優先順位を付けやすくなります。
9. AIに結果を読ませるときのプロンプト設計
ここまでの各ステップに共通する、AI活用の原則をまとめます。
| 原則 | 具体的なやり方 |
|---|---|
| 役割と前提を与える | 「自社の管理対象である」「テスト環境である」「業種・規模」を最初に書く |
| 秘密情報を伏せる | IPアドレス、ドメイン、顧客名、パスワード、APIキーは置き換えてから渡す |
| 出力形式を指定する | 危険度・根拠・修正案・確信度を表形式で出させる |
| 「わからない」を許す | 「要確認」「推測」を明記させ、断定を強制しない |
| 実行と報告を分ける | エージェントには、まず報告のみ。修正は人間が承認してから |
| 一次情報で裏を取る | CVE番号やバージョン情報は、メーカーやJVN（脆弱性対策情報データベース）で必ず確認 |
10. 落とし穴——AI・ツール活用で起きがちな5つの失敗
10.1 診断ツール自体が攻撃される
2026年3月、広く使われている脆弱性スキャナーTrivyの配布物やGitHub Actionが改ざんされ、CI環境の認証情報が盗まれるサプライチェーン攻撃が起きました。セキュリティツールも「信頼できる部品」ではないという教訓です。ツールは公式の入手元から取得し、GitHub Actionsはタグではなくコミットハッシュで固定し、診断用の環境には本番の認証情報を置かないようにしましょう。
10.2 AIの「もっともらしい誤り」を信じてしまう
存在しないCVE番号や、実際にはない設定項目をAIが示すことがあります。修正作業の前に、一次情報で必ず確認してください。
10.3 診断対象からの「プロンプトインジェクション」
AIエージェントにWebページやログを読ませると、そこに仕込まれた「AIへの指示」に従ってしまうことがあります。診断にAIエージェントを使う場合は、権限を最小限にし、外部送信やファイル削除などの操作には人間の承認を必須にします。
10.4 秘密情報をAIサービスに送ってしまう
設定ファイルやログをそのまま貼り付けると、パスワードやキーがAIサービスに送信されます。法人向けプランでも、送らないのが原則です。
10.5 「スキャンして終わり」になる
最も多い失敗です。見つけた問題を、誰が・いつまでに直すかを決めなければ、診断の意味はありません。結果は前回の記事のチェックリストと同じく、「高」は1週間以内、「中」は1か月以内など期限を決めて管理しましょう。
11. 規模別の「最小構成」プラン
| 項目 | 中小企業（IT担当1人・不在） | 中堅〜大企業（情報システム部門あり） |
|---|---|---|
| 頻度 | 四半期に1回 | 継続的（CI/CDに組み込み）＋月次レビュー |
| 最初にやること | Microsoft Secure Score等の確認、ZAPベースラインスキャン、WPScan | 攻撃対象の棚卸し、全リポジトリへのCodeQL・シークレットスキャン導入 |
| AIの使い方 | ChatGPTやClaudeの法人向けプランで結果を解説させる | Claude Code・Codex Security等をプルリクエストのレビューに組み込む |
| 外部の力 | 制作会社・保守会社と結果を共有。年1回は外部診断 | 年1回以上の外部診断・ペネトレーションテストで自己診断を検証 |
12. よくある質問（Q&A）
Q1. 自社のWebサイトなら、許可なく診断してもよいですか？ 自社が所有していても、サーバーがレンタルサーバーやクラウド上にある場合は、提供事業者の規約で診断が禁止・申請制になっていることがあります。主要なクラウドでは一部のサービスで事前承認なしの診断を認めていますが、条件があります。制作会社が管理している場合は、契約上の同意も必要です。社内の責任者の承認とあわせて、必ず事前に確認してください。
Q2. 無料のChatGPTやClaudeで診断結果を分析しても大丈夫ですか？ 個人向けの無料プランは、入力内容がモデルの学習に使われる設定になっている場合があります。業務で使うなら、学習に使われない法人向けプランを選び、そのうえで秘密情報は伏せて渡すのが安全です。
Q3. AIのコードレビューがあれば、外部の脆弱性診断は不要になりますか？ なりません。AIは見落としも誤検知もあり、毎回同じ結果を返すとも限りません。自己診断は「外部診断と外部診断のあいだ」を埋めるものと考え、年1回程度は専門家の診断で自己診断の精度を確かめることをおすすめします。
Q4. プログラミングができない経営者でも取り組めますか？ Microsoft 365やGoogle Workspaceの管理画面にあるセキュリティスコアの確認は、プログラミング不要で今日から始められます。表示された項目をAIに貼り付けて「何をすればよいか」を聞くだけでも、十分な第一歩です。ZAPなどのツールは、制作会社や詳しい社員に依頼するのが現実的です。
Q5. 診断中に重大な脆弱性が見つかったら、どうすればよいですか？ まず「すでに悪用されていないか」をログで確認し、悪用の形跡があればインシデントとして扱います。形跡がなければ、修正または一時的な回避策（該当機能の停止、アクセス制限）を優先度高で実施します。利用しているソフトウェア自体の未知の脆弱性であれば、メーカーやIPA（情報処理推進機構）への届出も検討してください。
13. まとめ——「攻撃者より先に、自分で見つける」を習慣にする
本記事のポイントは3つです。
- 自己診断は「自社の管理対象に、承認を得て」が絶対条件です。書面の承認、本番への配慮、AIに渡すデータの選別が、安全な自己診断の土台になります。
- AIは「ツール」と「通訳」の両方で使えます。コードレビューではAI自身が脆弱性を探し、ZAPやNmapの結果はAIが読み解く。この使い分けで、専門家がいない組織でも診断の質を上げられます。
- 最後に判断し、直すのは人間です。AIの指摘は一次情報で裏を取り、担当者と期限を決めて修正まで完了させて、初めて診断は意味を持ちます。
攻撃者は、AIを使って24時間あなたの会社の弱点を探しています。年1回の外部診断を待つのではなく、守る側もAIで、先に、継続的に見つけることが、2026年のセキュリティ対策の新しい標準です。
14. 参考リンク
- OWASP Top 10:2025
- OWASP ZAP 公式ドキュメント
- IPA「安全なウェブサイトの作り方」「ウェブ健康診断仕様」
- Anthropic「Automated Security Reviews in Claude Code」
- OpenAI「Codex Security」
- GitHub Docs「Copilot Autofix for code scanning」
- JVN iPedia（脆弱性対策情報データベース）
関連記事
- 【2026年版】大企業のセキュリティ対策 見直しチェックリスト60
- 【2026年版】中小企業のセキュリティ簡易チェック30
本記事で紹介したツールの仕様・提供条件は2026年10月時点の情報です。本記事の手順は自社が管理するシステムの防御を目的としており、他者のシステムに対する実行は行わないでください。
コメント