SonarQube Remediation Agent とは|コストをかけずに技術的負債を減らし続ける「修正ループ」

SonarQube Remediation Agent とは、SonarQube が検出したイシューを AI エージェントが修正し、検証済みのプルリクエスト(PR)として自動作成する機能です。

この記事でわかること

  • Quality Gate を通過したイシューが、なぜ技術的負債として残るのか
  • Remediation Agent の「修正ループ」が、どう回るのか
  • コストを増やさずに、コードベース全体を健全化できる 4 つの理由
  • Remediation Agent を足すと、いまの運用の何が変わるか

Quality Gate は「新しいコード」を守る仕組み:既存のイシューは放置されやすい

まず、SonarQube の基本的な流れを整理します。Quality Profile(ルールセット)が、コードの問題点を見つけます。そして、見つけた問題はすべてイシューとして登録されます。一方、Quality Gate(品質ゲート)の役割は別です。つまり、判定するのは「マージを止める条件」だけです。例えば、既定の Sonar Way は、新しいコードだけを見ます。新しいバグや脆弱性がないか、カバレッジが基準以上か、といった条件です。

多くの企業は、この Quality Gate の条件を絞っています。例えば「新しいコードに重大なバグや脆弱性を入れない」程度です。これは正しい設計です。なぜなら、開発を止めずに問題を指摘し続けられるからです。これが SonarQube の利点です。逆に、条件を厳しくしすぎると、パイプラインが止まり続けて形骸化します。なお、Quality Gate の設計は別の記事にまとめています。SAST 導入で失敗する 3 つの理由と対策の記事をご覧ください。

可視化はできた。しかし「誰がいつ直す?」が決まらない

しかし、ここで 1 つの問題が残ります。Quality Gate を通過したイシューは、ダッシュボードに溜まり続けます。つまり、軽度の脆弱性、保守性や軽微な信頼性の指摘です。これが、いわゆる技術的負債です。可視化はできています。ただし、直す人と時期が決まっていません。

理由は 3 つあります。

1 つ目は優先順位です。新機能、バグ修正、重大な脆弱性の対応が常に先に来ます。

2 つ目は作業の性質です。1 件ずつは小さく単純です。しかし、件数が多く、まとめて直すとレビューの負担が増えます。

3 つ目は時間です。「負債返済スプリント」を確保できるチームは多くありません。

そのため、イシューは増え続けます。さらに、AI コーディングアシスタントでコードの生成量が増えます。すると、この傾向は強まります。なお、既存コードの負債の扱い方は、別の記事でも整理しています。レガシーコードに SAST を導入する記事です。

SonarQube Remediation Agent とは:イシューを掃除する AI エージェント

Remediation Agent は、Sonar 社の AI エージェントです。2026 年 5 月に発表され、同年 6 月に正式リリースされました。イシューの修正に特化しています。もとは、シンガポール国立大学(NUS)の研究成果です。名前は AutoCodeRover です。これは自動プログラム修正の技術で、Sonar 社が 2025 年 2 月に買収しました。なお、Sonar 社そのものは、別の記事で紹介しています。SonarSource の会社概要と信頼性を評価した記事です。

汎用のコーディングアシスタントとの違いは、起点と検証にあります。まず、プロンプトを書く必要はありません。SonarQube のイシューが起点になります。さらに、リポジトリ全体のコンテキストを参照して修正を生成します。そして、Sonar の解析エンジンが修正を検証します。つまり、検証を通った修正だけが、PR として開発者に届きます。

Sonar 社が語る 3 つのループ:Remediation Agent は「コードメンテナンスループ」を担う

Sonar 社は 2026 年 3 月に、AI 時代の開発手法を発表しました。それが Agent Centric Development Cycle です。略称は AC/DC です。3 つの「ループ」で Guide → Verify → Solve を回す考え方です。ループの場所は 3 か所です。まず、コーディングエージェントの中と、プルリクエストです。そして、メインブランチのバックグラウンドです。

Remediation Agent が担うのは「コードメンテナンスループ」です。つまり、バックグラウンドで既存のイシューを直し続けます。さらに、Sonar 社自身も、この製品を次のように呼んでいます。「review → fix → verify のループを閉じる」エージェントです。出典はプレスリリースと公式ドキュメントです。

Remediation Agent の 3 つの動き方

  • スケジュール実行:メインブランチのバックログから、修正可能なイシューを自動で選んで直します。なお、頻度(毎日または毎週)、時刻、タイムゾーンは管理者が設定します。また、1 回の実行で、リポジトリごとに最大 5 件を 1 本の PR にまとめます。
  • 手動アサイン:Issues 画面で直したいイシューを選び、「Fix with Agent」を押します。また、「Fixable by Agent」で絞り込めます。ただし、一度に送れるのは 20 件までです。
  • PR 修正:PR の解析で Quality Gate が不合格になったときに動きます。そして、新しいイシューの修正案を、PR 上で提案します。

本記事で中心に扱うのは、1 つ目のスケジュール実行です。なぜなら、人の操作なしに回り続けるループを作れるのは、この方式だからです。なお、Enterprise プランでは Hunter Agent を併用できます。これはロジックレベルの脆弱性を見つけるエージェントです。そして、その検出結果も修正対象になります。

なお、Hunter Agent が何を見つけるのかは、SonarQube Hunter Agent を解説した記事にまとめています。

Remediation Agent の修正ループ:定期実行 → 修正 → 検証 → PR → マージを繰り返す

ここからは、ループを 1 周分追います。例えば、設定は「毎日 22:00、Asia/Tokyo」です。人が関わるのはループの最後、PR のレビューとマージだけです。一方、残りはエージェントがバックグラウンドで回します。

ループの前半:イシューを選び、修正し、検証する(自動)

  1. イシューの選定:設定した時刻に実行が始まります。そして、メインブランチのイシューから、修正可能なものを最大 5 件選びます。なお、対象は保守性・信頼性と一部のセキュリティのルールです。
  2. 修正の生成:組織に登録した LLM で修正案を生成します。なお、LLM は OpenAI または Anthropic の API キーで接続します。また、該当箇所だけでなく、リポジトリ全体のコンテキストを参照します。
  3. クローズドループ検証:修正後のコードに、Sonar の解析エンジンを再実行します。そして、元のイシューが解消され、新しいイシューがない修正だけが次に進みます。一方、検証に失敗した修正は破棄され、開発者の目には触れません。つまり、ループの中にもう 1 つ小さな「生成 → 再解析」のループがあります。
  4. PR の作成:検証を通った修正を、ルールとファイル種別ごとにまとめて PR にします。なお、イシューごとに 1 コミットです。さらに、PR の説明には違反したルール、解説、差分が含まれます。

CI が落ちたら:Remediation Agent がビルドログを読んで直す

まず、PR が作られると、既存の CI がそのまま動きます。そのため、テストやビルドは通常の PR と同じ条件で実行されます。さらに、CI が失敗した場合も、エージェントが対応します。ビルドログを読み、失敗を直すコミットを追加で push します。なお、再試行は最大 3 回で、進捗は PR の説明に記録されます。ただし、この自動リカバリーの対象は GitHub Actions のワークフローです。

ループの後半:人がレビューしてマージし、次の実行へ

まず、レビュー担当者は PR を開きます。そして、差分とルールの解説を確認してマージします。エージェントは PR を出すだけで、マージは行いません。ブランチ保護ルール、必須レビュアー、ステータスチェックも、そのまま適用されます。また、実行履歴はプロジェクトの Agent activity 画面に残ります。そのため、何が選ばれ、どれだけ時間がかかったかを後から追えます。

マージが終われば、次の実行時刻にループがまた回ります。「負債返済スプリント」を計画しなくても、仕組みが勝手に進めてくれる。つまり、これがループの価値です。例として「毎日 22:00」を挙げましたが、頻度は毎週でも構いません。チームのレビュー体制に合わせて選べます。

Remediation Agent の利点:開発者のコストを増やさずにコードベース全体を健全化する

「AI が直してくれる」こと自体は、価値の中心ではありません。価値は、人的コストをかけずに回り続けるループができることです。対象は、直す人と時期が決まっていなかった技術的負債です。ここでは、利点を 4 つに整理します。

1. 開発者は新機能・バグ修正・重大な脆弱性に集中できる

「Quality Gate は通過するが、放置はしたくない」。そうしたイシューの修正を、エージェントがバックグラウンドで引き受けます。そのため、開発者の時間は、本来の仕事に向けられます。つまり、新機能の開発、バグの修正、重大な脆弱性の対応です。ただし、PR のレビューは必要です。それでも、ゼロから直すのとは負担が違います。また、エージェントの対象は、いまの Quality Profile のイシューです。つまり、ルールの調整に費やしてきた時間は、そのまま活きます。

2. 人を増やさず、ループのたびに負債が減る

最大の利点は継続性です。1 回の実行で最大 5 件は、小さく見えます。しかし、ループは止まりません。例えば、毎営業日に実行するとします。すると、1 リポジトリあたり月に最大 100 件のペースです。計算は 5 件 × 20 営業日です(筆者の試算)。人的コストをかけずに、コードベース全体を健全な状態に近づけられます。しかも、開発者を増やす必要もありません。また、オープン中の PR が一定数に達したら一時停止する上限も設定できます。そのため、レビューが追いつかないほど PR が溜まることもありません。

3. 検証済みの修正だけが届くので、レビューの負担が軽い

生成 AI の修正案で心配なのは、「直したつもりで別の問題を入れる」ことです。しかし、PR になるのは、クローズドループ検証を通った修正だけです。さらに、CI の失敗も自分でリカバリーします。つまり、レビュー担当者は「意図どおりに直っているか」の確認に集中できます。ループが回るほどレビューの件数は増えますが、1 件あたりの負担は小さく保たれます。

4. ループの対象・頻度・上限を管理者がコントロールできる

まず、有効化はプロジェクト単位です。また、エージェントがアクセスできるリポジトリは限られます。つまり、DevOps プラットフォーム側でバインドしたものだけです。さらに、頻度、オープン PR の上限、修正の種類は変更できます。また、管理画面から、いつでも停止もできます。Sonar 社も、まず 1〜2 リポジトリで試すことを推奨しています。出力に慣れてから広げる進め方です。

比較表:手動修正・AI CodeFix・Remediation Agent の違い

SonarQube には AI CodeFix もあります。これは、1 件のイシューに対して修正案を生成する機能です。そこで、3 つの違いを 1 枚にまとめました。手動修正、AI CodeFix、Remediation Agent の 3 つです。

項目手動で直すAI CodeFixRemediation Agent
起点開発者が着手を決める開発者が Issues 画面で修正案を生成するSonarQube のスケジュール、Quality Gate の不合格、手動アサイン
繰り返し人が時間を確保したときだけ人がボタンを押したときだけ○ スケジュールで自動的にループする(毎日 / 毎週)
修正を書くのは開発者LLM が提案し、開発者が適用エージェントが生成し、コミットまで行う
検証レビューと CI開発者が確認○ Sonar の解析エンジンで再解析。CI の失敗も自動で修正(最大 3 回)
成果物コミット1 イシューの修正案(diff)検証済み PR(1 回の実行で最大 5 件)
向いている場面設計変更を伴う修正目の前の 1 件を素早く直すバックログを人手をかけずに減らし続ける
対応プラン(SonarQube Cloud)−Team / EnterpriseTeam(年額)/ Enterprise + 追加サブスクリプション

すでに SonarQube を使っているチームが Remediation Agent を足すと変わること

無償版で運用しているチームは多いはずです。例えば Community Build や、SonarQube Cloud の無料枠です。そうした現場でも、「見つける」「可視化する」までは十分に機能しています。また、ルールの調整や誤検知の判断も、すでに済んでいるはずです。つまり、足りないのは「直す」の部分だけです。Remediation Agent は、その整った状態をそのまま入力にして動きます。

ここでは、変わる点を 3 つに分けて見ていきます。なお、Community Build でできることは、別の記事で整理しています。SonarQube IDE の Connected Mode を解説した記事です。

1. 溜まったイシュー一覧が「やることリスト」から「AIの自動修正リスト」になる

いまのイシュー一覧は、誰かが時間を取らないと減りません。一方、Remediation Agent を足すと変わります。その一覧が、ループの入力になります。エージェントが見るのは、いまの Quality Profile のイシューです。つまり、ルールを一から整え直す必要はありません。これまでの運用で整えてきたものが、そのまま前提になります。

2. 負債返済の工数が「開発者の時間」から「ループの実行回数」になる

これまで負債を減らす手段は、開発者の時間を確保することだけでした。しかし、その時間は新機能やバグ修正と常に競合します。Remediation Agent を足すと、問いが変わります。「誰の時間を使うか」ではなく「何回ループを回すか」になります。必要な費用は 2 つです。1 つは、Remediation Agent のサブスクリプションです。もう 1 つは、自社の LLM API の利用料です。なお、前者は固定、後者は実行量に応じた従量です。

判断の目安は単純です。例えば、開発者が 1 件のイシューを直してレビューを通すのに 30 分かかるとします。毎営業日に 5 件のループが回れば、月に最大 100 件です。つまり、最大 50 時間分の作業に相当します(筆者の試算)。この時間を新機能に回せる価値と、サブスクリプションの費用を比べます。すると、答えは出しやすいはずです。実際の件数は Agent activity 画面で確認できます。そのため、パイロットで測ってから判断できます。

3. 「品質をどう上げたか」を数字で説明できる

無償版の運用では、「SonarQube を入れた」とは言えます。しかし、「負債がどれだけ減ったか」は示しにくいことがあります。Remediation Agent のループが回ると、数字が残ります。マージされた PR の数と、バックログの減り方が、成果の数字になります。そのため、経営層や監査への説明にも使えます。

比較表:いまの運用と、Remediation Agent を足した運用

SonarQube をすでに使っているチームの視点で、変わる点だけを並べました。

項目いまの運用(無償版の例)Remediation Agent を足した運用
イシューの検出・可視化○○ そのまま使う
新しいコードを止める(Quality Gate)○(Community Build はメインブランチのみ)○ PR 分析も含む
既存イシューの修正人が時間を確保したときだけ○ ループが定期的に修正(1 回最大 5 件 / リポジトリ)
修正の検証レビューと CI○ Sonar エンジンの再解析 + CI 失敗の自動修正
負債の推移増えがちループのたびに減る
成果の説明イシュー件数の推移のみマージ済み PR 数と Agent activity の履歴
必要なもの無償Cloud:Team(年額)/ Enterprise + 追加サブスクリプション。Server:2026.5 以降の Enterprise Edition 以上

無償版からの進み方:Cloud の無料枠と Community Build で近道が違う

SonarQube Cloud の無料枠を使っているなら、最短の道があります。Team プラン(年額)に上げて、Remediation Agent を追加します。プロジェクトや設定はそのまま使えます。

一方、Community Build の場合は、2 つの道があります。コードを SaaS に置けるなら、SonarQube Cloud へ移行する道です。移行先は Team プラン(年額)です。オンプレミスの要件があるなら、SonarQube Server を上げる道です。対象は、2026.5 以降の Enterprise Edition 以上です。どちらも、まず 1〜2 リポジトリで試せます。

Remediation Agent 導入前に確認すること:対応プラン・言語・LLM の扱い

※ 2026 年 11 月時点の公式ドキュメントに基づきます。変わりやすい情報のため、最新は公式サイトでご確認ください。

対応プランと料金

SonarQube Cloud では、サブスクリプションを追加して利用します。追加できるのは、Team(年額)と Enterprise プランです。また、利用量には上限があります。なお、超過分の扱いはプランによって決まります。一方、SonarQube Server では、対象は 2 つのエディションです。Enterprise Edition と Data Center Edition です。また、バージョンは 2026.5 以降が必要です。こちらも、ライセンスとは別のサブスクリプションです。料金は公式サイトでご確認ください。

対応言語と DevOps プラットフォーム

  • 対応言語:Java、JavaScript / TypeScript、Python、C#、PHP(SonarQube Cloud のみ)。また、Secrets の修正案にも対応します。
  • 対象イシュー:信頼性(Reliability)、保守性(Maintainability)、一部のセキュリティルール。
  • プラットフォーム:バックログの修正は 3 つに対応します。GitHub、GitLab.com、Azure DevOps です。一方、PR 修正は GitHub と GitLab です。これは SonarQube Cloud の場合です。

LLM とソースコードの扱い

Remediation Agent は、自社の API キーで動きます(BYOK 方式)。OpenAI または Anthropic のキーを、組織レベルで登録します。対応モデルは 2 系統です。Claude は Opus 4.6 / 4.7 / 4.8 / 5 です。GPT は GPT-5.3 Codex、GPT-5.5、GPT-5.6 Sol です。なお、Sonar 社の推奨は Claude Opus 4.6 または GPT-5.5 です。

修正対象のコードとイシューの情報は、LLM に送られます。つまり、経路は自社のプロバイダーアカウントです。SonarQube Server を自社環境で動かしている場合も同じです。そのため、データの学習利用や保持には、そのプロバイダーの利用規約が適用されます。社外にコードを出す際のルールがある組織では、導入前に確認しておきましょう。なお、詳しい設定手順は、公式ドキュメントにまとまっています。

よくある質問

Remediation Agent は無料で使えますか?

いいえ。別のサブスクリプションが必要です。SonarQube Cloud の場合で説明します。追加できるのは、Team(年額)と Enterprise プランです。一方、AI CodeFix は、1 件ずつ修正案を生成する機能です。そして、こちらは Team 以上のプランに含まれています。なお、トライアルやお見積りは、Sonar 社または弊社にお問い合わせください。

Remediation Agent はどのくらいの頻度で動きますか?

スケジュール実行は、毎日または毎週です。時刻とタイムゾーンは、管理者が指定します。1 回の実行で、リポジトリごとに最大 5 件を 1 本の PR にまとめます。また、手動アサインは好きなタイミングで送れます。一方、PR 修正は、Quality Gate が不合格になるたびに動きます。

Remediation Agent が勝手にマージすることはありますか?

ありません。エージェントは PR を作るところまでで、マージは開発者が行います。また、ブランチ保護や必須レビュアーなどの既存ルールも、そのまま有効です。

Remediation Agent と AI CodeFix の違いは何ですか?

AI CodeFix は、開発者が画面上で使う機能です。1 件のイシューを選び、修正案を生成します。また、適用も開発者が行います。一方、Remediation Agent は、起点が違います。つまり、スケジュールや Quality Gate の不合格を起点に動きます。そして、バックグラウンドで修正を生成します。さらに、Sonar の解析エンジンで検証してから PR として届けます。つまり、目の前の 1 件なら AI CodeFix です。一方、バックログを減らし続けるループなら Remediation Agent です。

修正が間違っていたらどうなりますか?

まず、検証に失敗した修正は PR になりません。次に、PR の CI が失敗した場合は、エージェントがログを読みます。そして、最大 3 回まで修正を試みます。それでも直せなかったイシューは、開発者が引き継げます。なお、内容は PR の要約や Agent activity 画面で確認できます。そして、最終的な判断は、通常どおり人のレビューで行います。

無償の Community Build や無料枠のまま、Remediation Agent は使えますか?

使えません。SonarQube Cloud では、追加のサブスクリプションとして提供されます。なお、対象は Team(年額)と Enterprise プランです。

Community Build からは、2 つの道があります。まず、SonarQube Cloud の Team プランへの移行です。次に、SonarQube Server を上げる道です。Server の対象は 2026.5 以降です。エディションは Enterprise か Data Center です。なお、Server の LLM は、インスタンス管理者が設定します。接続先は Azure AI Foundry か AWS Bedrock です。さらに、OpenAI 互換のエンドポイントも選べます。

まとめ:Quality Gate で「入口」を守り、Remediation Agent のループで溜まったイシューを減らす

SonarQube で「見つける」「可視化する」は、すでにできているはずです。足りないのは「直す」の仕組みです。Quality Gate で止めるのは、重大な問題だけで構いません。つまり、開発スピードを守る運用として、正しい設計です。しかし、その設計では、通過したイシューが溜まり続けます。そこで、Remediation Agent の修正ループが、溜まったイシューを減らします。1 回最大 5 件ずつ、検証済みの PR にして返し続けます。

ルールの調整や誤検知の判断を積み重ねたチームほど、ループはすぐに回ります。開発者は新機能・バグ修正・重大な脆弱性に集中し、PR のレビューに数分使うだけ。この運用が回り始めると、変化が積み上がります。開発者を増やさずに、コードベース全体が健全になっていきます。まずは、1〜2 リポジトリでループを回してみてください。

なお、SonarQube には、コンテナイメージの脆弱性を調べる新機能もあります。SonarQube のコンテナスキャンを解説した記事で紹介しています。

Remediation Agent のご相談はお気軽にどうぞ

弊社は SonarQube のリセラーです。無償版からの移行設計、ライセンスのご提案、技術サポートまで対応しています。「Remediation Agent を足すと、うちのイシューはどれだけ減るのか」。そう試算したい方もいるでしょう。その場合は、お問い合わせフォームからご連絡ください。また、パイロット用のトライアルもご案内できます。

参考リンク(Sonar 公式)

Ryuji Goto
AUTHOR
Ryuji Goto
新規CTA