はじめに
こんにちは！ エンジニア４年目のTKDです！
今回は、2026年5月12日に開催されたClaude Code Meetup Japan #5で「Claude Agent SDKを活用した脆弱性調査自動化」というタイトルで登壇してきたので、その内容を紹介します。
この記事は、LLMを使った業務効率化に興味がある方や、セキュリティ運用の自動化で悩んでいる方に向けた記事です。
今回の発表では、脆弱性調査において、調査やレポート作成をLLMに任せる半自動化について話しました。
このようなLLMを利用した取り組みで、定常業務に割く工数を減らすことで、より本質的な課題に取り組める時間を増やし迅速にプロダクトの価値を顧客に届ける状態を目指しました。
登壇資料
登壇資料はこちらです。
登壇内容
今回の発表では、Claude Agent SDKを使って脆弱性調査を半自動化した取り組みについて紹介しました。
主に以下の内容について話しました。
- 手作業で行っていた脆弱性棚卸しの流れ
- Claude Agent SDKを使ったCLIの構成
- 半自動化するときの判断ポイント
- LLMを安全かつ安く扱うためのTips
先に結論を述べると、AIに全部任せなくても十分役に立つという話です。
APIの制約や安全性から面倒で曖昧な調査をAIに任せ、管理ツールへの最終記入や判断は人間側に残す形にしました。
発表の背景
普段の脆弱性棚卸しでは、いろいろなツールや画面を行き来する必要がありました。
手作業では、ざっくり以下のような流れになります。
- yamoryからSlackに脆弱性通知が届く
- yamoryをブラウザで開いて未対応項目の詳細を確認する
- エディタとClaude Codeで対象コードベースで使っているか調べる
- 影響と対応方針を考える
- GitHub Discussionsに脆弱性詳細や影響調査内容を書き、対象サービスのラベルを付ける
- yamoryに調査内容、対応期限、対応方針を書いてステータスを変更する
毎回同じような確認も多いですが、逐一調査対象のコードや外部情報も見に行く必要があります。
そこで、調査と調査レポート作成の部分をClaude Agent SDKで自動化できないか試しました。
なぜ全部自動化しなかったのか
今回は、検知から投稿までをすべて自動化するのではなく、CLIで実行できる半自動の形にしました。
理由は主に以下です。
- 脆弱性自体の危険度はyamoryのSlack通知で確認できる
- 緊急対応か定常業務内での対応かは、人間が一目で振り分けられる
- yamoryのAPIがReadのみで、Writeに対応していない
- 担当者のローカル実行にすることで、Claudeのサブスクプランを使える
個人的には、こういった対応を間違えるとまずい業務では、いきなりE2Eの全自動を目指さなくてもよいと思っています。
今回はAPIの制約や安全性を総合的に考えて半自動にしました。
実際の感じからも、手動実行できるCLIレベルでも十分便利でした。
作成したCLIの概要
今回作成したCLIでは、ざっくり以下の流れで処理しています。
- yamory APIから、期間やステータスで絞り込んだ脆弱性一覧を取得する
- 既存のGitHub Discussionsタイトルを確認する
- CREATE / COMMENT / SKIP の処理判定を行う
- Claude Agent SDKでコード調査、草案作成、ラベル付けを行う
- 調査結果とyamory記入例をGitHub Discussionsへ投稿する
- 必要に応じてSlackに通知する
このCLIによって、体感では1件あたり5分から10分ほどかかっていた作業が、 バックグラウンド処理込みで体感約2分程度で進められるようになりました。
半自動設計のポイント
今回意識したのは、決定論的に処理できる部分と、LLMに任せる部分を分けることです。
コードで記述している部分は以下です。
- yamoryからの一覧取得、検索、詳細取得
- 既存Discussion検索によるCREATE / COMMENT / SKIP判定
- 安全性ガードレール
- GitHub Discussionsへの投稿
一方で、LLMが担当している部分は以下です。
- CVE、PoC、修正済みバージョンなどの外部情報調査
- 現環境での悪用可能性や影響評価
- 推奨対応方針の下書き
- Discussionへのラベル付け
判断材料を集めるところはAIに寄せつつ、判断を間違えると危険な部分は人間が確認するようにしました。
この線引きをしておくと、他のLLMを必要とする業務にも応用しやすいと思います。
細かいTips
LLMに渡す範囲を狭くする
まず、LLMに何でも渡さないようにしました。
期間や状態の絞り込み、重複判定、冪等性、共有ON/OFFのような部分はコードで固定しています。
LLMには、利用状況の調査、影響評価の下書き、推奨対応方針の下書き、記入例の作成を任せました。
これにより、お得で安全にLLMを扱いやすくなります。
読み取りを自作ツールで行う
次に、対象リポジトリの読み取りは自作ツールで行うようにしました。
自作ツールでは、read onlyにしたうえで、ファイルサイズ、拡張子、ファイルパスを解析的に検査しています。
repo外のファイル、secret、巨大ファイル、バイナリなどを拒否することで、安全性を確保しています。
Claude Agent SDKでは、@toolアノテーションでツール化できるので、このあたりも実装しやすかったです。
ツールを絞る
Claude Agentに渡すツールも絞りました。
脆弱性調査では、WebSearchと読み取り専用のrepo検索、repoファイル読み取りツールだけを許可しています。
読み取りを自作ツール以外からできないようにすることで、意図しないアクセスを防ぎやすくしました。
Claude Code標準プロンプトは必要な場所だけ使う
Claude Codeの標準プロンプトは、コード探索のようにClaude Codeのハーネスとしての強みがほしい場所だけで使いました。
たとえば、脆弱性調査ではClaude Code標準プロンプトに脆弱性調査用の追加指示を加えています。
一方で、GitHubのラベル付けのような小さい判定では、候補ラベルから選ぶ小さな構造化タスクとしてAgentを分けました。
広い調査と小さい判定でAgentを分けるのは、個人的に扱いやすい設計だと思っています。
登壇してみて
今回登壇してみて、想像以上に多くの方の前で発表することになり非常に緊張する発表でした！
また、作るときは壁打ちや制約で自然に半自動になったのですが、発表資料を作る中で、全自動化を目指すのではなく、人間とコードとLLMで役割を分けることの重要性を改めて考える機会になりました。
まとめ
今回は、Claude Code Meetup Japan #5で「Claude Agent SDKを活用した脆弱性調査自動化」について登壇した内容を紹介しました。
今回紹介した流れは、脆弱性調査以外にも使えると思っています。
明日から使えるポイントとしては、以下の3つです。
- 無理にE2Eの全自動にせず、半自動を狙う
- LLMが得意とする情報集めや例文作成をメインに使う
- 最終記入、冪等性、確認導線は人間とコードで設計する
興味がある方は、ぜひ参考にしてみてください！
ここまで読んでいただきありがとうございました！
