目次
- はじめに
- Hunter Agent とは
- 利用条件と、これから確認したいこと
- まとめ
1. はじめに
2026年10月中旬に行われた SonarQube World Tour 東京に参加してきました。World Tour では SonarQube の活用事例や新しい製品が紹介されていました。セキュリティ関連のニュースが相次ぐ中、新しい製品の中で特に気になったのが Hunter Agent です。
Hunter Agent は、ソースコードを直接解析し、ルールベースの解析だけでは発見が難しい、アクセス制御や業務ロジックなどに関わる脆弱性を探す セキュリティ対策 AI エージェント です。
今回は、Hunter Agent のどこに期待しているのかを書いていきます。まだ自分では試せていないので、使ってみた結果ではなく、公開資料や Sonar の担当者から聞いた説明をもとにした紹介です。なお、情報は2026年11月現在のものです。
攻撃側も AI を使う時代
AI は開発を支援する一方で、攻撃側にも使われています。情報漏洩やサイバー攻撃の報道が相次ぐ中、AI が攻撃に悪用された事例も報告されています。Anthropic の報告では、2025年9月に検知した活動について、Claude Code を悪用した侵入活動が説明されています。
こうした状況では、自社サービスの脆弱性対策は十分なのか、追加の対策として何ができるのか気になるところです。既存の対策を補う選択肢の一つとして、Hunter Agent があると考えています。
SonarQube と AI を組み合わせる
SonarQube は、ソースコードを解析して品質やセキュリティ上の問題を見つける製品です。静的解析では、定義されたルールやデータの流れなどを調べます。解析結果を 品質ゲート という基準に照らし、変更を受け入れてよいかの判断にも使えます。この解析の強みは、共通の基準で再現性のある確認（決定論的チェック）ができることです。
対して、従来の SonarQube の静的解析では、ルールベースで解析するため、設計意図や複雑な業務ロジックが絡む問題を見つけることは難しいという弱点がありました。これを補完する形でAIによるレビューや脆弱性のチェックがあれば、もっと網羅的に問題を見つけることができると言えます。
今回の World Tour での各企業の講演でも、AI の判断だけで終わらせず、静的解析やテストを組み合わせる使い方が紹介されていました。
Sonar の近況と新製品
Sonar がこの World Tour で紹介していた製品群もこの組み合わせるスタイルを踏襲しており、また Sonar が今まで培ってきた生産性改善と、セキュリティ対策の専門部隊としてのノウハウが詰まったものだと感じました。
それぞれ少しだけ紹介します。利用できる機能や条件は、製品・契約によって異なる点にご注意ください。
Sonar Vortex
Sonar Vortex は、AI がコードを書く前と、書いた直後を支える製品です。プロジェクトの構造やコーディング規約、セキュリティ上の制約などを AI に渡し、生成・変更したコードを SonarQube の解析エンジンで検証します。
特にAIエージェントに提供するコンテキスト情報の精度が高いようで、AIエージェントがプロジェクトに合ったコードを生成しやすくなり、手戻りを減らす効果があるようです。結果、例えばリファクタリング時ではトークン消費について 36% の削減効果があったとコメントが出ています。
Gitar
Gitar は、PR のレビューから修正・CI の確認までを支えるエージェントです。PR はコードの変更をレビュー・統合するための単位で、CI はビルドやテストなどを自動実行する仕組みです。
コードの指摘だけでなく、CI が失敗した原因を調べ、修正案を作り、CI を通るか確認するところまで扱うと説明されています。特に強力だと感じたのは、レビューで参照するコンテキストの範囲です。Sonar の方から聞いたところでは、複数のリポジトリを跨いでコンテキストを集め、他のPRとの整合性を確認し、Slack や JIRA でのやり取りをリンクすることでそのやり取りまで踏まえたレビューを実施してくれるとのことです。
Remediation Agent
Remediation Agent は、SonarQube ですでに見つかった問題の修正を支えるエージェントです。SonarQube 上の指摘事項（Issue）に対して、修正案を生成・検証し、人がレビューするための PR を作成します。
Gitar が PR をトリガーに動く機能というのに対し、こちらは SonarQube の Issue をトリガーにして動く機能です。既存の課題を対象にするほか、対象となる問題を定期的に修正提案する使い方もあるようです。問題を検出しても、その対応が後回しになってしまい、技術的負債が徐々にたまっていくことがあるかと思います。Remediation Agent はこの技術的負債の解消を継続的に支援します。
Hunter Agent
Hunter Agent は、まだ見つかっていない業務ロジックなどの脆弱性を探すエージェントです。PR の変更を中心に見る Gitar や、検出済みの Issue の修正を支援する Remediation Agent に対し、コードベースを深く調べ、新しい問題を見つける役割を担います。
ここからは、今回特に気になった Hunter Agent を見ていきます。
2. Hunter Agent とは
Sonar の公式ドキュメントでは、主な調査対象として、次の三つが挙げられています。
- アクセス制御の不備：その利用者に許可されていない情報や操作へアクセスできてしまう問題。
- 業務ロジックの脆弱性：必要な手順を飛ばせる、回数や利用量の制限をすり抜けられる、といった問題。
- 認証・セッション管理の欠陥：本人確認やログイン状態の管理に関わる問題。
例えば、ログインした利用者が、他人の情報まで見られてしまうケースです。「誰であるか」を確かめるのが認証で、「その情報を見てよいか」を確かめるのが認可です。ログインを確認するだけでなく、取得する情報がその利用者に許可されたものかも確認する必要があります。
Hunter Agent は、こうしたコードの意図と実装の関係を調べるものとして説明されています。疑わしい箇所を挙げるだけでなく、候補の裏付けを確認し、理由とコード位置を添えて SonarQube 上で Issue として報告します。
結果を普段の Issue と同じように扱えるので、開発者が内容を確認し、担当者の割り当てや修正判断につなげられます。「見つけました」で終わらず、対応につながる形で受け取れるのもよいところだと思います。
なお、Hunter Agent はソースコードを静的に解析するもので、アプリケーションを実行したり、稼働中のサービスに攻撃したりする製品ではありません。実行時の挙動や運用設定を確かめる検証とは分けて考える必要があります。
Sonar のノウハウが詰まった専門的な調べ方・確かめ方を、エージェントが利用する
AI に「脆弱性を調べて」と頼むこと自体はできます。ただ、専門知識がなければ、調査の順序や観点を適切に指示し、見つかった候補が本当に問題なのかを検証することは容易ではありません。調査の観点に抜けがないか、疑わしい処理経路に別の制御がないか、どのような前提で問題が成立するのかまで確かめる必要があります。AI がそれらしい結果を返しても、それだけでは「十分に調べられた」と判断しにくいと思います。これは Mythos のような高性能なモデルを利用できたとしても生成AIという性質上、例外ではありません。
公式記事の Get started with SonarQube Hunter Agent では、Hunter Agent が単一のプロンプトではなく、専門的な複数段階の調査手順を使うと説明されています。候補を別のエージェントへ渡して裏付けを確認し、裏付けられない候補は除外するとされています。
この調査で使われる専門的な手順が Playbook です。また、Hunter Agent 動く基盤が Foundation Agent です。ここでは内部構成の説明は省きますが、モデルの推論能力に、Sonar の専門的な調査手順と、候補を確かめる仕組みが組み合わされているのがポイントだと考えています。
自分たちで同じような仕組みを用意するなら、最初の指示を作るだけでは終わらなさそうです。講演でも、調査手順の更新や品質評価、裏付け確認、根拠や課題管理の運用・保守まで含めて考える、という話がありました。
Sonar の知見が反映された手順と、その実行・検証の仕組みまで製品として利用できるのは、かなり心強いなと思います。単に指示を作る時間が減ることよりも、自分では指示しきれない専門的な調査方法を補ってくれそうなところに、期待しています。
最先端の AI モデルを取り入れる取り組み
もう一つ気になっているのが、Sonar が OpenAI Daybreak ディフェンス ネットワークに参加したという話です。
こちらの記事で、Hunter Agent に OpenAI GPT Cyber Models を導入できることを説明しています。このプログラムを通して、フロンティアモデルや脆弱性調査用のリミットが解除されたモデルを、サービスとして利用できるようです。
専門的な調査手順があり、その上で脆弱性調査用モデルの推論能力を活用する。この組み合わせにより、高い検出精度と一貫性を備え、監査可能な結果が得られるよう設計されているとのことです。
注意点として、現時点では、Daybreak 経由の特定モデルは SonarQube Cloud での利用になるとのことです。これは Hunter Agent が Cloud でしか利用できないという意味ではないですが、SonarQube Server では、ユーザー側でモデル用意する必要があります。また、ユーザー側でモデルを用意する場合、現在は Anthropic の Opus または Sonnet を用意する必要があるようです。
3. 利用条件と、これから確認したいこと
SonarQube Cloud / Server で使う際の基本条件
Hunter Agent は、Cloud / Server の両方で提供されています。
| 項目 | SonarQube Cloud | SonarQube Server |
|---|---|---|
| 対象プラン・エディション | Enterprise plan | 2026.5 以降の Enterprise / Data Center edition |
| 契約 | Hunter Agent を利用するための別途サブスクリプションが必要 | （Cloud同様） |
| モデル/実行基盤 | Sonar提供のモデル（OpenAI Daybreak 提供）を利用 | ユーザー側でモデルを用意する必要あり(BYOK) |
あくまでこの記事執筆時点での情報なので、検討時は、最新の情報をリポジトリ連携などの前提や、モデル・契約の詳細は、使う環境に合わせて確認ください。
コストについて
Hunter Agent は SonarQube Server / Cloud のライセンスとは別途サブスクリプションの契約を結んで利用する流れになります。公開資料では、Hunter Agent の製品側の消費単位を scan units とし、コード規模に応じた区分で消費すると説明されています。具体的な消費量は、契約やモデル提供元のキーを持ち込むかによっても異なります。
モデル自体のトークン消費について、 SonarQube Cloud では、scan units にそのコストが含まれていますが、SonarQube Server では Hunter Agent の利用枠と、モデルのトークン消費・推論費用は、分けて見ておく必要があります。
トライアルで確かめたいこと
まだ私自身も触ったことがあるわけではないので、今後実際に触るときには、次の点を見ていきたいと思っています。
- 有効な問題を見つけてくれるか：対応が必要な問題か、理由や成立条件を人が確認できるか。
- 既存の解析を補えるか：同じ対象で、従来の解析では見つからなかった問題があるか。
- 対応の負担はどうか：指摘を理解し、優先順位や修正方針を決めるまでに、どれぐらいの手間がかかるか。
- 継続して使えるか：実行時間、トークン消費、対象規模や実行頻度との関係はどうか。
問題がたくさん出てきたからよい、というわけでもないと思います。内容や裏付け、対応にかかる手間まで含めてみていきたいです。
4. まとめ
本記事では、SonarQube World Tour 東京で紹介された Hunter Agent の概要と、期待している点を紹介しました。
脆弱性対策で困っている方にとって、SonarQube の解析に加えて何を使うか、検討のヒントになっていれば嬉しいです。
Hunter Agent の利用やトライアルの検討については、クレスコへご相談ください。利用条件の確認や、Sonar への確認・取り次ぎを通じて、検討のお手伝いができればと思います。
