2026.11.11

SonarQube Hunter Agent とは｜SAST では見つからない「ロジックの脆弱性」を AI が探す

AI Security & Governance SonarQube

SonarQube Hunter Agent とは、静的解析（SAST）では見つけにくいロジックの脆弱性を、コード全体を読んで探す AI エージェントです。

Sonar 社が、2026 年 8 月 27 日に一般提供を始めました。提供先は SonarQube Cloud です。そして、同年 9 月には SonarQube Server にも対応しました。

不正アクセスによる情報漏えいの公表が続いています。一方、SonarQube の解析に合格していても、残る欠陥があります。それが、ロジックの脆弱性です。

ロジックの脆弱性とは、コードは書かれたとおりに動くのに、守るべき決まりが抜けている欠陥です。本記事では、ロジックの欠陥とも呼びます。例えば、次のようなものです。

URL の番号を変えると、他人の注文が見える（IDOR）
決済を済ませずに、注文を確定できる
時間がたっても、セッションが切れない

どれも、危険な書き方はしていません。そのため、書き方を調べる検査では見つかりません。

この記事でわかること

SAST や脆弱性診断だけでは足りない、技術的な理由
Hunter Agent が検出する 3 種類の脆弱性
候補を検証してから報告する仕組みと、その根拠
使い方と、Cloud・Server それぞれの条件
無料版からの進み方

SAST に合格しても残る脆弱性：なぜロジックの欠陥は見つからないのか

まず、SAST が得意なことを確認します。SAST は、危険な書き方をルールで見つけます。さらに、外部からの入力が危険な処理に届く経路も追います。そのため、SQL インジェクションや XSS は、高い確度で見つかります。しかし、この方法では見つからない脆弱性があります。

IDOR とは：コードは正しいのに、他人のデータが見える

ロジックの脆弱性の代表が、IDOR（Insecure Direct Object Reference）です。URL などの番号を書き換えるだけで、他人のデータに届く欠陥を指します。次のコードは、注文を 1 件返す API です。なお、説明用の例として、Java（Spring）で書きました。

@GetMapping("/orders/{id}")
public Order getOrder(@PathVariable Long id) {
    // ログイン済みかどうかは、フレームワークが確認している
    return orderRepository.findById(id).orElseThrow();
}

このコードに、危険な書き方はありません。例えば、ID は数値で、データベースへの問い合わせも安全です。しかし、注文が誰のものかを、どこでも確かめていません。つまり、ログインした利用者は、URL の番号を変えるだけで他人の注文を読めます。これが IDOR です。

足りないのは、持ち主を確かめる条件

直し方は、長くありません。検索の条件に、ログイン中の利用者を足します。

@GetMapping("/orders/{id}")
public Order getOrder(@PathVariable Long id,
                      @AuthenticationPrincipal AppUser user) {
    // 注文が、ログイン中の利用者のものかを確かめる
    return orderRepository.findByIdAndCustomerId(id, user.getId())
            .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
}

つまり、問題は「書かれたコード」ではなく、「書かれなかった条件」にあります。なお、他人の注文には 404 を返しています。403 を返すと、その番号の注文があると伝わるためです。

認証は通っていても、認可が抜けていると危ない

ここで、認証と認可を分けて考えます。認証は、利用者がだれかを確かめる処理です。つまり、ログインです。一方、認可は、その利用者にその操作を許してよいかを確かめる処理です。IDOR は、認証は正しく動いているのに、認可の確認が抜けている状態です。

この欠陥が危険な理由は 2 つあります。

特別な技術が要らない：正しくログインした利用者が、番号を書き換えるだけです。
大量に取り出せる：番号を順に変えれば、他人のデータを次々に読めます。米国 CISA などの共同勧告も、自動のツールで大規模に悪用できると警告しています。

そのため、IPA の「安全なウェブサイトの作り方」も、認証に加えて、認可の処理を実装するよう求めています。

SAST がこの欠陥を見つけられない 3 つの理由

SAST が見逃すのは、性能が足りないからではありません。調べ方の原理が違うからです。理由は 3 つあります。

危険な経路が無い：SAST は、入力が危険な処理に届く経路を追います。しかし、このコードの入力は、安全な問い合わせに渡るだけです。
正解がコードの外にある：「注文は本人だけが読める」という決まりは、業務の仕様です。そのため、書き方のルールにはできません。
確認の場所が決まっていない：持ち主の確認は、フィルターや別のクラスにあるかもしれません。つまり、1 つの関数だけでは判断できません。

この弱点は、以前から知られています。例えば、OWASP Top 10 の 2017 年版は、こう書いています。アクセス制御の検出は、静的でも動的でも、自動テストには通常向かない、と。そのため、最良の方法は手動のテストだとされてきました。

脆弱性診断や CVE の照合でも、見つけにくい

では、ほかの検査ではどうでしょうか。まず、依存ライブラリやコンテナイメージの検査は、公表済みの脆弱性（CVE）と照合します。しかし、自社で書いたコードの認可の穴に、CVE はありません。

次に、動いているアプリを外から調べる自動の診断ツールです。このツールは、異常な入力を送って反応を見ます。一方、IDOR の攻撃は、正しい形式の ID を送るだけです。そして、応答も正常です。つまり、「他人のデータが返った」と判断するには、業務の意味を知る必要があります。

もちろん、専門家が手で診断すれば見つけられます。ただし、診断は、ある時点の確認です。Sonar 社は、外部のペネトレーションテストを「年に 1〜2 回」と表現しています。一方、コードは毎日変わります。

情報漏えいのニュースと、ロジックの脆弱性の関係

不正アクセスの入口は、1 つではありません。例えば、盗まれたパスワード、ネットワーク機器の脆弱性、設定の誤りがあります。また、個々の事案の原因は、公表されないことも多くあります。Hunter Agent が関係するのは、自社のアプリや API のロジックの欠陥が入口になる場合です。ただし、この種類は決して少なくありません。

公的な資料が示す、アクセス制御の不備の多さ

OWASP Top 10:2025：1 位は「アクセス制御の不備」です。さらに、テストしたすべてのアプリケーションで、何らかの不備が見つかったとしています。
米国 CISA・NSA とオーストラリア ACSC の共同勧告（2023 年）：IDOR は、情報漏えいで頻繁に悪用されているとしています。また、数百万人規模の個人情報や金融情報が侵害されたと述べています。
IPA「安全なウェブサイトの作り方」：「アクセス制御や認可制御の欠落」を、独立した項目として扱っています。

なお、共同勧告は、この欠陥の難しさにも触れています。使われ方が 1 件ずつ違うので、共通のライブラリや関数 1 つでは防げない、という指摘です。そのうえで、開発者には、自動のツールによるコードレビューを勧めています。

実例：番号を変えるだけで、他人の応募情報が読めた

2025 年に、研究者が McDonald's の採用サイト「McHire」の欠陥を報告しました。原因は 2 つです。まず、管理画面に初期の認証情報でログインできました。そして、もう 1 つが IDOR でした。応募者の番号を 1 つずつ減らすと、別の応募者の情報が返ったのです。

研究者によると、対象は 6,400 万人を超える応募者の情報でした。なお、欠陥は報告の翌日に修正されています。つまり、巧妙な攻撃でなくても、番号を変えるだけで大量の情報に手が届きます。

SonarQube Hunter Agent とは

SonarQube Hunter Agent は、こうしたロジックの脆弱性をソースコードから探す、Sonar 社の AI エージェントです。セキュリティの研究者がコードを監査するときの進め方を、エージェントが行います。そして、結果は SonarQube のイシューとして出ます。つまり、新しい画面を覚える必要はありません。

提供は段階的に進みました。まず、2026 年 5 月にアルファ、7 月にベータが始まりました。そして、8 月 27 日に SonarQube Cloud で一般提供になりました。さらに、9 月 29 日公開の SonarQube Server 2026.5 から、オンプレミスでも使えます。

Hunter Agent が検出する 3 種類の脆弱性

アクセス制御の不備：IDOR、認可の確認の欠落や誤り、権限昇格、機密データの露出、CSRF です。
ビジネスロジックの脆弱性：必須の手順の省略、繰り返せる操作の悪用、回数制限の欠落です。
認証とセッション管理の欠陥：セッション固定、切れないセッション、弱いパスワード再設定、多要素認証の欠落などです。

先ほどの IDOR は、1 つ目に当たります。一方、決済を済ませずに注文を確定できる流れは、2 つ目です。また、クーポンを何度でも使える処理も同じです。なお、対応する CWE の一覧は、公式ドキュメントにあります。対応言語は、SonarQube が対応する言語すべてです。

SAST・SCA と Hunter Agent の役割分担

Hunter Agent は、SAST の置き換えではありません。SAST と SCA に続く、3 つ目の層です。

SAST：自分で書いたコードの、危険な書き方を見つけます。
SCA：依存ライブラリの、公表済みの脆弱性を見つけます。
Hunter Agent：自分で書いたコードの、足りない確認や手順の抜けを見つけます。

Hunter Agent の仕組み：候補を挙げ、確かめてから報告する

LLM にコードを読ませると、ロジックの欠陥が見つかることがあります。しかし、そのままでは運用に乗りません。Hunter Agent の工夫は、モデルの外側の仕組みにあります。まず、専門のプロンプトを段階的に並べた手順に沿って動きます。そして、候補を挙げ、確かめ、残ったものだけを報告します。

LLM にそのまま頼む場合との違い

Sonar 社は、汎用のプロンプトの弱点を具体的に挙げています。例えば、同じコードに 2 回試すと、結果が 3 件にも 60 件にもなる、という指摘です。結果が毎回変わると、チームは対応の手順を作れません。

そこで、Hunter Agent は対策を 2 つ入れています。まず、検証を専門に行うサブエージェントです。候補は、攻撃の道筋を示せたものだけが残ります。次に、実行ごとの一貫性です。これは、設計の目標に置かれています。さらに、各結果には、エージェントがたどった経路が付きます。そのため、レビューする人が根拠を追えます。

また、大きなリポジトリは、分割して調べます。Sonar 社は、1,000 万行を超えるコードにも対応できると説明しています。

精度の根拠と、まだ分からないこと

Sonar 社は、数値を 2 つ公表しています。

報告した結果が本物である割合（適合率）は、平均 80〜90%
社内のテストで、著名なオープンソースから 200 件を超える未知の脆弱性を発見

ただし、どちらも Sonar 社自身の発表です。筆者が調べた範囲では、第三者による検証は見つかりませんでした。また、発見した脆弱性の一覧も見つかりませんでした（2026 年 11 月時点）。そのため、自社のコードで試して確かめるのが確実です。なお、試用については後半で触れます。

使われるモデルと、コードの扱い

公式ドキュメントによると、Hunter Agent は Sonar 社の Foundation Agent の上で動きます。そして、現在のモデルは Claude の Sonnet と Opus です。ただし、特定のモデルに依存しない設計とされています。

また、Hunter Agent はソースコードを読むだけです。アプリを動かしたり、攻撃したりはしません。そして、コードと結果は、SonarQube Cloud の組織の中に留まります。なお、外部に出るのは、モデルの推論の呼び出しだけです。

Hunter Agent の使い方：有効化から最初のスキャンまで

ここでは、SonarQube Cloud の手順を説明します。インストールするものは、ありません。なお、画面の名前は 2026 年 11 月時点のものです。詳しくは設定のドキュメントをご覧ください。

組織とプロジェクトで有効にする

組織の管理者が、Administration の AI capabilities を開きます。
「Allow project admins to enable scheduled scans」を有効にします。
プロジェクトの管理者が、Analysis の Hunter Agent を開きます。
ブランチを選び、Scan Now を押します。

また、定期的な実行もできます。Manage scheduling で、ブランチ、頻度、時刻を選びます。例えば、Sonar 社は、main ブランチへの週次か月次の実行を挙げています。スキャンはバックグラウンドで動くので、プルリクエストや CI は止まりません。なお、組織とプロジェクトは、GitHub、GitLab、Azure DevOps のいずれかと連携している必要があります。

結果は、いつものイシュー一覧に出る

結果は、プロジェクトのイシュー一覧に並びます。また、Hunter Agent のページでは、分類ごとの件数と重大度を確認できます。さらに、絞り込みには hunter-agent タグを使います。そして、各結果には「なぜ問題か」と「どう直すか」の説明が付きます。担当の割り当てや状態の変更は、ほかのイシューと同じです。なお、詳細は結果の見方のドキュメントにあります。

見つけた欠陥を、Remediation Agent に直させる

2026 年 10 月から、修正も任せられるようになりました。イシューを選んで「Fix with Agent」を押すと、SonarQube Remediation Agent が修正案を作ります。修正は、1 件ごとに 1 つのプルリクエストで届きます。なお、対象は main ブランチの結果で、一度に選べるのは 20 件までです。そして、マージするかどうかは人が決めます。

ただし、Remediation Agent の契約が別に必要です。仕組みは、Remediation Agent の修正ループを解説した記事にまとめています。

SonarQube Server（オンプレミス）で Hunter Agent を使う場合

SonarQube Server でも、2026.5 から使えます。対象は Enterprise と Data Center のエディションです。ただし、Cloud と違う点が 2 つあります。

エージェントを自社の基盤に置く：SonarQube Server とは別のコンテナとしてデプロイします。
LLM を自社で用意する：LLM プロバイダーを設定します。必要なモデルは、主が Opus 4.8、副が Sonnet 4.6 です。

つまり、解析は自社の基盤の上で動きます。なお、手順は、Server 向けのドキュメントにあります。

いまの SonarQube に Hunter Agent を足すと何が変わるか

SonarQube を使っているチームには、すでに SAST の層があります。Hunter Agent は、その上に、ロジックの欠陥を見る層を足します。まず、違いを表にまとめます。

比較表：SAST だけの運用と、Hunter Agent を足した運用

項目	SAST だけの運用	Hunter Agent を足した運用
見つかる脆弱性	インジェクションや XSS など、書き方の欠陥	○ 加えて、アクセス制御・ビジネスロジック・認証の欠陥
調べ方	ルールと、データの流れの解析	○ コード全体を読み、候補を検証する
ロジックの欠陥を探す手段	人のレビューと、定期の診断	○ 出荷前のコードで、継続して探す
実行のタイミング	コミットやプルリクエストごと	定期（週次・月次）か手動。バックグラウンドで動く
結果の扱い	SonarQube のイシュー	○ 同じイシュー一覧に並ぶ
費用	無料の範囲でも使える	Enterprise と、Hunter Agent の契約が必要

Hunter Agent が向くプロジェクト、向かないプロジェクト

公式ドキュメントは、向くプロジェクトを具体的に挙げています。認証、認可、業務の流れを持つバックエンドや API です。

マルチテナントの SaaS：利用者は、自分の組織のデータだけを見られる必要があります。
EC サイト：決済、割引、返金が、決まりどおりに動く必要があります。
業務アプリ：役割、権限、承認の流れが、重要な操作を守っています。

一方、静的なサイトや UI 部品のライブラリは、対象から外れます。なぜなら、アクセス制御や業務ロジックが、ほとんど無いからです。

無料版からの進み方

Hunter Agent は、無料の範囲では使えません。しかし、いまからできることはあります。

いまの解析を続ける：SAST が見る範囲は、引き続き SonarQube に任せます。まだ使っていないチームも、ここから始められます。
認可の観点をレビューに足す：「この ID のデータは、本人のものか」を、コードレビューで確かめます。
試用で、自社のコードに当てる：Sonar 社は、無料トライアルを案内しています。M サイズのプロジェクトを 2 つほどスキャンできます。ただし、Enterprise プランが前提で、申し込みは営業への問い合わせです。

なお、SAST の導入でつまずきやすい点は、SAST 導入で失敗する 3 つの理由と対策にまとめています。

導入前に確認すること

条件は、2026 年 11 月時点の公式情報にもとづきます。変わりやすいので、契約の前に公式ページをご確認ください。

プラン：SonarQube Cloud は Enterprise プランが必要です。一方、SonarQube Server は、2026.5 以降の Enterprise か Data Center です。
契約：Hunter Agent は、プランとは別の製品です。そのため、追加の契約が要ります。
料金：料金ページには載っていません。なお、消費量は「スキャンユニット」で数え、コードの行数の区分で決まります。
連携：プロジェクトが、GitHub、GitLab、Azure DevOps のいずれかと連携していること。

よくある質問

Hunter Agent は、無料版で使えますか？

使えません。SonarQube Cloud の無料枠と、SonarQube Community Build は対象外です。必要なのは、Enterprise のプランかエディションと、Hunter Agent の契約です。ただし、無料トライアルがあります。なお、申し込みは Sonar 社の営業への問い合わせになります。

Hunter Agent は、SAST の代わりになりますか？

なりません。なぜなら、役割が違うからです。SAST は、SQL インジェクションや XSS のような欠陥を担当します。一方、Hunter Agent は、書き方に現れないロジックの欠陥を担当します。つまり、両方を使います。

脆弱性診断やペネトレーションテストは、不要になりますか？

不要にはなりません。まず、診断は、動いているアプリを外から確かめます。一方、Hunter Agent は、出荷前のソースコードを読みます。そのため、診断の前に、コードの段階で欠陥を減らせます。また、ソースコードに現れない設定やインフラの問題は、調べません。

Claude などの LLM に直接コードを読ませるのと、何が違いますか？

原理は同じです。実際、Hunter Agent も Claude のモデルで動いています。違いは、モデルの外側の仕組みです。具体的には、段階的な手順、候補の検証、実行ごとの一貫性です。さらに、結果は SonarQube のイシューになり、定期実行もできます。なお、AI によるチェックと SonarQube の関係は、SonarQube と Claude Security を扱った記事でも整理しています。