SonarQube（ソナーキューブ）とは？できること・料金・使い方と品質ゲートの設定【2026年10月】

SonarQube（読み方は「ソナーキューブ」）は、ソースコードを実行せずに解析して、バグ・セキュリティ上の問題・保守しにくいコード・重複・テストカバレッジ不足を見つけるコード品質ツールです。開発元はSonarSource（ブランド名Sonar）で、解析結果に「品質ゲート」という合否基準を当て、不合格ならCIのパイプラインを失敗させ、必須チェックと組み合わせてプルリクエストのマージも止められます。CIを失敗させるだけならリンターでもできますが、SonarQubeはカバレッジ・重複・問題件数など複数の指標をまとめて判定し、その推移を履歴として残す点が違います。

本記事では、2026年10月時点の公式ドキュメント（SonarQube Server 2026.5 LTA・Community Build 26.10）をもとに、できること、無料版と有償版の違いと料金、対応言語、Dockerでの使い方、解析結果の見方、GitHub ActionsとJenkinsへの組み込み、権限設定までを順に説明します。

まとめ：SonarQubeの要点

• できること：静的解析で問題を検出し、既定の品質ゲート「Sonar way」で新規コードの合否を判定します。条件は「新しい問題ゼロ」「新規のセキュリティホットスポットを全件レビュー」「新規コードのカバレッジ80.0%以上」「新規コードの重複3.0%以下」の4つです。
• この記事で比較する主要4製品：無料で自社サーバに入れる「Community Build」、有償の「SonarQube Server」（Developer／Enterprise／Data Center）、SaaSの「SonarQube Cloud」（旧SonarCloud）、エディタ拡張の「SonarQube for IDE」（旧SonarLint）です。
• 料金：Community BuildとSonarQube for IDEは無料です。SonarQube Cloudは非公開コード5万行（50k LOC）まで無料、有償のTeamプランは10万行で月額34ドルからです（2026年10月時点の料金ページ表記）。Serverは解析する行数に応じた年額で、金額は問い合わせです。
• 無料版の限界：Community Buildはブランチ解析とプルリクエスト解析を持たず、C・C++・Swiftなども解析できません。PRごとに品質ゲートで止めたいならDeveloper Edition以上かSonarQube Cloudが必要です。
• 2026年の変更点：セキュリティホットスポットは廃止に向かっており、組み込みルールはもうホットスポットを出しません。組み込みの品質プロファイルは「Sonar way core／extended／comprehensive」の3段階になり、ZIPファイルからのインストールは非推奨（DockerかHelmを推奨）になりました。

SonarQubeでできること：検出する問題と品質ゲート

SonarQubeは、スキャナーが送ってきた解析結果をサーバで集計し、プロジェクトごとの問題一覧・指標・履歴をWeb画面に表示します。静的解析そのものの仕組みや、テストとの役割分担は静的解析とは？実行せずに欠陥を見つける仕組みとツールの選び方で扱っているので、ここではSonarQube固有の機能に絞ります。

検出する問題の種類と指標

検出結果は、セキュリティ・信頼性（バグ）・保守性（コードスメル）の3つの品質に分かれます。あわせて、テストカバレッジ、重複した行とブロック、循環的複雑度と認知的複雑度、コード規模も指標として記録します。重複の考え方はコードの重複の記事で詳しく説明しています。

カバレッジは、SonarQubeが自分で測るのではなく、JaCoCoやJest・pytest-covなどが出力したレポートを取り込んで表示します。テストを実行してレポートを作る工程をCIに入れておかないとカバレッジは0%のままになり、既定のSonar wayでは、新規コードのうちカバレッジ対象となる行が20行以上あり、カバレッジが80%未満の場合にカバレッジ条件で不合格になります。

セキュリティホットスポットの廃止と脆弱性への移行

セキュリティ関連の指摘には、これまで2種類ありました。脆弱性はそのまま修正が必要な問題、セキュリティホットスポットは「安全かどうかを人がレビューして判断すべき箇所」で、「To review」「Acknowledged」「Fixed」「Safe」の4つの状態を持ちます。Sonar wayは新規のホットスポットが全件レビュー済みであることを合格条件にしています。

このホットスポットは廃止の途中です。公式の更新後の作業手順によると、Server 2026.5とCommunity Build 26.10では組み込みルールがホットスポットを出さなくなり、同じルールが脆弱性（MQRモードでは「セキュリティ」の問題）として指摘します。データベースに残っている既存のホットスポットは、管理者が POST /api/hotspots/migrate_to_issues で、ルールに応じて脆弱性かコードスメル（MQRモードではセキュリティか保守性の問題）へ変換します（dryRun=true で件数だけ確認可能）。Serverでは2027.1への更新時にこの移行が強制的に走るので、件数が多いインスタンスはプロジェクト単位で先に移行しておくと、更新が長引きません。

SQLインジェクションのように、入力がどこから流れてきたかを追って検出する「インジェクション脆弱性の検出」は、Developer Edition以上の機能です。依存ライブラリの既知脆弱性を調べるSCAは、Enterprise Edition以上に追加契約する有償製品「SonarQube Advanced Security」の機能で、SAST全般の位置づけはSASTとはの記事で比較しています。

品質ゲート「Sonar way」の4条件と新規コードの考え方

品質ゲートは「このコードはリリースしてよいか」を条件の組み合わせで判定する仕組みです。組み込みの品質ゲートはSonar wayとAIエージェント開発向けの「Sonar way for agentic AI」の2つで、既定で使われるSonar wayは読み取り専用です。Sonar wayは次の4条件を新規コードに対して適用します。

既存コードの指摘がどれだけ残っていても、新しく書いた・変更したコードが条件を満たせば合格します。レガシーなプロジェクトに入れた直後に何千件も指摘が出ても、全部を直してから使い始める必要はありません。変更したところから直す考え方はボーイスカウトルールと同じです。

「新規コード」の範囲は、前のバージョン以降・直近N日・特定の解析以降・参照ブランチとの差分の4方式から選びます。既定は「前のバージョン以降」で、日数方式を選んだときの既定値が30日です。変更行が20行未満なら重複条件が、カバレッジ対象の新規行が20行未満ならカバレッジ条件が無視される仕組み（fudge factor）が既定で有効です。ただし判定対象は設定された新規コード範囲全体なので、今回の修正が1行でも、その範囲に対象行が20行以上あればカバレッジ条件で不合格になることがあります。プルリクエストの解析では、新規コードに対する条件だけが使われます。

品質プロファイルは3段階に：Sonar way core・extended・comprehensive

品質ゲートが「合否の基準」なのに対し、品質プロファイルは「どのルールで解析するか」というルールセットです。名前が似ていますが、品質ゲートのSonar wayとは別物です。次表の信頼性・保守性ルールはSonarの推奨ルールに限り、重大度はMQRモードの表記です。2026.5と26.10から、言語ごとに3つの組み込みプロファイルが用意されました（公式の組み込み品質プロファイル解説）。

旧版から更新した場合は、各プロジェクトのプロファイルも言語ごとの既定も更新前のまま残ります。新しく入れたインスタンスだけが、ルール数の少ないcoreで始まります。

製品ラインナップと料金：Community Build・Server・Cloud・for IDE

2024年10月29日のブランド統合で、SonarCloudは「SonarQube Cloud」、SonarLintは「SonarQube for IDE」に改称されました。無料版の「Community Edition」も2024年12月の24.12から「Community Build」になっています。古い記事の製品名は、次の表のように読み替えてください。

Serverの3エディションで増える機能

SonarQube ServerにはDeveloper・Enterprise・Data Centerの3エディションがあり、いずれもインスタンス単位・年額で、解析する行数（LOC）の上限に対して料金を払います。無料のCommunity Buildとの差が大きいのはDeveloper Editionです。

• Developer：ブランチ解析、プルリクエスト解析とPRへの結果表示、インジェクション脆弱性の検出。言語はC・C++・Objective-C・Swift・ABAP・T-SQL・PL/SQLが加わります。
• Enterprise：複数プロジェクトをまとめるポートフォリオ、セキュリティレポート、SCIMによるユーザーの自動プロビジョニング、監査ログ、トークンの最大有効期限の強制。依存ライブラリを調べるSCAは、別契約のAdvanced Securityで追加できます。言語はApex・COBOL・JCL・PL/I・RPG・VB6・Gosuが加わります。
• Data Center：Enterpriseの機能に、冗長構成による高可用性と水平スケールを足したものです。

AI関連の機能は、Community Buildには入っていません。AIが書いたコードに専用の品質基準を当てる「AI Code Assurance」はDeveloper以上、LLMで修正案を出す「AI CodeFix」はEnterpriseとData Centerだけの機能で、対象はJava・JavaScript・TypeScript・Python・HTML・CSS・C#・C++の一部ルールです（公式のAI CodeFix解説）。2026.5で加わった、修正のプルリクエストを自動で作る「Remediation Agent」と、静的解析では見えないアクセス制御の不備などを探す「Hunter Agent」はEnterprise以上で、別売りのサブスクリプションと、サーバとは別に動かすコンテナが必要です。

DeveloperとEnterpriseは14日間の無料トライアルがあります。Serverの料金ページには金額が掲載されておらず、エディションと行数（LOC）の段階を選んでSonarSourceの営業窓口に問い合わせる形式です。

SonarQube Cloudの料金とLOCの数え方

SonarQube Cloudは、非公開プロジェクト5万行までの無料枠が期限なしで使えます。有償はTeamとEnterpriseの2プランで、料金ページではTeamが解析行数10万行まで月額34ドルから、行数に応じて段階的に上がります。OSIライセンスの公開リポジトリは無料です。

課金対象の行数は、各プロジェクトの直近の解析で数えた行数の合計です。ブランチがある場合は最も大きいブランチだけを数え、解析回数は関係しません。6,000行のプロジェクトを月に100回解析しても6,000行です。

リリースサイクルと版番号の読み方

SonarQube Serverは2か月ごと（年6本）に新版が出て、版番号は「年.リリース番号.パッチ番号」（例：2026.5.2）です。10.8までは「メジャー.マイナー.パッチ」形式でした。年6本のうち2本が長期サポートのLTA（Long-Term Active、旧称LTS）で、直近は2026.1と2026.5です。2026.5以降のLTAは、有償版の利用者がリリースから12か月、EnterpriseまたはData CenterエディションでEnterprise Supportを契約していれば18か月パッチを受けられます。2026年10月時点のダウンロードページの表記は「2026.5.2 LTA」で、Dockerでは 2026.5-lta-<エディション> タグで取得できます。

Community Buildは別系統で、ほぼ毎月「26.10.0.133078」のような番号で出ます。2026年10月時点の最新は2026年10月12日公開の26.10です。LTAはないので、更新し続ける前提で運用します。

対応言語：Community Buildの21言語と有償版で増える言語

「30言語以上に対応」という紹介をよく見かけ、公式サイトは「40以上の言語・フレームワーク」と表記していますが、これは有償版やCloudを含めた数です。無料のCommunity Buildは、ダウンロードページの表記で21の言語・フレームワークに対応します。

このほかServerのドキュメントの対応表では、Dart・Groovy・Shell・YAML・JSON・GitHub Actions・Azure Pipelines・Ansible・PowerShell（ベータ）がServerとCloudでは対象、Community Buildでは対象外です。C・C++のプロジェクトを無料版で解析しようとしても対象外なので、ここで選ぶエディションが決まることがあります。

「Java」には2つの意味があるので注意してください。解析対象としてのJavaは全エディションが対応しています。一方、サーバをZIPで動かすにはJava 21か25のJDKが必要で、これは解析対象のJavaのバージョンとは別の話です。

SonarQubeの使い方：Docker起動と初回解析の手順

Dockerでの起動と初期ログイン

試すだけなら、公式が案内しているDockerの1行で起動できます。community タグがCommunity Buildです（2026年10月時点で latest も同じイメージ）。

docker run -d --name sonarqube \
  -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true \
  -p 9000:9000 sonarqube:community

起動したら http://localhost:9000 を開き、ログインID admin、パスワード admin でログインします。初回ログイン時にパスワードの変更を求められます。SONAR_ES_BOOTSTRAP_CHECKS_DISABLE は内部のElasticsearchの起動前チェックを止める試用向けの設定で、このコンテナは同梱のH2データベースを使います。H2は公式が「テスト向けで本番には推奨しない」と明記しており、同時アクセスに弱く、レプリケーションや堅牢なバックアップの機能を持たないので、使い続けるなら次の要件で構築し直します。

本番運用のシステム要件

2026.5と26.10で、ZIPファイルからのインストールは非推奨になりました。今は動きますが将来のリリースで提供が終わるため、新しく構築するならDockerイメージかHelmチャートを選びます。

MySQLは対応データベースに含まれていません。PostgreSQL 14は2026.5の対応範囲から外れているので、旧版から更新する前にデータベースの版も確認します。Linuxでは、内部で動くElasticsearchのためにカーネル設定の下限があり、満たしていないと起動に失敗します。Dockerで動かす場合もホスト側で設定します。恒久的に設定するには、次の内容を2つのファイルに書きます（sonarqube はSonarQubeを動かすユーザー名）。

# /etc/sysctl.d/99-sonarqube.conf
vm.max_map_count=524288
fs.file-max=131072

# /etc/security/limits.d/99-sonarqube.conf
sonarqube   -   nofile   131072
sonarqube   -   nproc    8192

systemdのサービスとして起動する場合、後半のユーザー制限はユニットファイルの [Service] に LimitNOFILE=131072 と LimitNPROC=8192 を書きます。今のセッションだけ変えるなら、rootで sysctl -w vm.max_map_count=524288 のように実行します。この前提を満たせないAzure App Service・AWS App Runner・AWS Fargateは非対応と明記されており、Azure Container InstancesとAzure Container Appsも推奨されていません。

スキャナー別の解析コマンドと接続設定

画面で「Create new project」からプロジェクトキーを決め、解析用のトークンを発行したら、ビルドツールに合ったスキャナーで解析を送ります。Mavenではプロジェクトキーの既定値が groupId:artifactId になるため、画面で別のキーを作成した場合は、解析コマンドに -Dsonar.projectKey=作成したキー を追加します。Maven・Gradleのスキャナーは sonar.host.url（または環境変数 SONAR_HOST_URL）を指定しないと送信先がSonarQube Cloudになるので、自前のサーバに送るときは必ず指定します。Maven用スキャナーは、JRE自動プロビジョニングを使う場合は実行ホストのJava 11以上で利用でき、使わない場合はJava 21以上が必要です。

# Maven（スキャナーのバージョンを固定）
mvn clean verify org.sonarsource.scanner.maven:sonar-maven-plugin:5.8.0.7211:sonar \
  -Dsonar.host.url=http://localhost:9000 -Dsonar.token=<トークン>

# Gradle（org.sonarqube プラグインを適用済みの場合）
./gradlew build sonar -Dsonar.host.url=http://localhost:9000 -Dsonar.token=<トークン>

# 専用スキャナーのないビルド環境では SonarScanner CLI
# C#・VB.NETは対象外。SonarScanner for .NETを使用
sonar-scanner -Dsonar.projectKey=my-app -Dsonar.sources=src \
  -Dsonar.host.url=http://localhost:9000 -Dsonar.token=<トークン>

トークンとURLは環境変数 SONAR_TOKEN・SONAR_HOST_URL でも渡せます。CIではコマンド引数に直書きせず、環境変数にシークレットとして渡します。

Java（Maven）のJaCoCoカバレッジ取り込み設定

Javaのプロジェクトでカバレッジが0%のまま表示されるときは、JaCoCoレポートの生成と取り込みを確認します。SonarQubeが直接読めるJavaのカバレッジ形式はJaCoCoのXMLレポートなので、jacoco-maven-plugin の prepare-agent と report の2つのゴールを、スキャナーより前に実行します（公式のJavaカバレッジ設定）。次の plugin 要素は、pom.xml の build 内の plugins に追加します。

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.8.15</version>
  <executions>
    <execution>
      <id>prepare-agent</id>
      <goals><goal>prepare-agent</goal></goals>
    </execution>
    <execution>
      <id>report</id>
      <goals><goal>report</goal></goals>
      <configuration>
        <formats><format>XML</format></formats>
      </configuration>
    </execution>
  </executions>
</plugin>

レポートの既定の出力先 target/site/jacoco/jacoco.xml はスキャナーが自動で探すので、単一モジュールなら追加の設定は要りません。マルチモジュールで集約レポートを別の場所に出す場合は、sonar.coverage.jacoco.xmlReportPaths にそのパスを指定します（ワイルドカードとカンマ区切りの複数指定が可能）。

解析結果の見方：Summary画面と評価A〜Eの基準

解析が終わったら、プロジェクトの「Analysis > Summary」を開きます。いちばん上の品質ゲートの判定が緑なら合格で、不合格なら落ちた条件ごとに「今の値」と「基準値」が並ぶので、そこから該当する問題の一覧へ移れます。その下の「New code」と「Overall code」のタブは、新規コードだけの指標とコード全体の指標の切り替えです。既定のSonar wayでは新規コードの条件で合否を判定するので、まずNew codeを見ます。カスタム品質ゲートで全体コードの条件も設定している場合、ブランチ解析ではOverall code側の条件も確認します。

各品質にはA〜Eの評価が付きます。セキュリティと信頼性は「最も重い問題が1件でもあるか」で決まり、保守性は技術的負債の比率で決まります（公式の指標定義、MQRモードの場合）。

技術的負債の比率は「すべての保守性の問題を直す推定時間 ÷（1行の開発コスト × コード行数）」です。1行の開発コストは既定で30分ですが、設定で変更できます。上表の保守性評価の閾値も既定値です。公式の例では、6万3,987行で負債12万2,563分のプロジェクトが6.4%となり、評価はBです。セキュリティと信頼性は件数ではなく最も重い1件で決まるので、Blockerが1件残るだけで、ほかが全部きれいでもEになります。評価だけでなく、Issues画面で重大度（Blocker・High・Medium・Low・Info）を絞り込んで重いものから片付けるのが近道です。

新しい問題は、その行を最後にコミットした人がSonarQubeのユーザーと対応づけられれば、その人に自動で割り当てられます。誤検知なら「False positive」、あとで直すなら「Accepted」にできます。画面上の用語は、管理者が「Administration > Configuration > General Settings > Mode」で選ぶモードで変わります。MQRモードは「セキュリティ・信頼性・保守性」と重大度Blocker・High・Medium・Low・Info、Standard Experienceは「脆弱性・バグ・コードスメル」と重大度Blocker・Critical・Major・Minor・Infoで表示します。

CI/CDへの組み込み：品質ゲート不合格でパイプラインを止める設定

解析をCIに入れただけでは、品質ゲートが不合格でもビルドは成功扱いのまま進みます。止めるには、スキャナーにゲートの結果を待たせる設定が別途必要です。CI/CDの全体像はCI/CDとはで説明しています。

GitHub Actionsの設定例

公式のアクション SonarSource/sonarqube-scan-action（2026年10月時点の最新はv8.3.0）を使います。リポジトリ直下の sonar-project.properties に sonar.projectKey=my-app を書いておき、ワークフローは次のようにします。ただし公式READMEは、Maven・Gradle・.NETでビルドするプロジェクトにはこのアクションではなく各ビルドツール用のスキャナーを使うよう案内しています。その場合は同じジョブの run で前述の mvn … sonar や ./gradlew build sonar に -Dsonar.qualitygate.wait=true を付けて実行します。

name: SonarQube
on:
  push:
    branches: [main]
jobs:
  sonarqube:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - uses: SonarSource/sonarqube-scan-action@v8
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ vars.SONAR_HOST_URL }}
        with:
          args: >
            -Dsonar.qualitygate.wait=true

fetch-depth: 0 は、Gitの履歴から新規コードを判定するために公式が指定しているものです。sonar.qualitygate.wait=true を付けると、スキャナーがゲートの判定を待ち、不合格ならステップが失敗します。待つ時間は sonar.qualitygate.timeout（既定300秒）で変えられます。

この例は、ブランチ解析のないCommunity Build向けにmainへのpushだけで動かす最小構成です。カバレッジも判定する場合は、スキャン前にテスト実行とカバレッジレポート生成のステップを追加し、使用言語に対応するレポートの取り込み設定を行います。SONAR_HOST_URLにはGitHubホストランナーから到達できるサーバURLを指定してください。手元のDockerをlocalhostで起動しただけでは接続できないため、社内限定のサーバには接続可能なセルフホストランナー等を用意します。プルリクエストごとに判定したい場合は、Developer Edition以上かSonarQube Cloudを使い、pull_request イベントを追加します。さらに、不合格時にマージを禁止するには、GitHubの対象ブランチのルールセットまたはブランチ保護で、品質ゲートを確認するチェックを必須ステータスチェックに指定します。GitHub Actions自体の書き方はGitHub Actionsとはを参照してください。

Jenkinsの設定例

Jenkinsではプラグイン「SonarQube Scanner」（2026年10月時点の最新は2.19.0）を入れ、解析ステージを withSonarQubeEnv で囲み、別ステージの waitForQualityGate でゲートの結果を待ちます。

pipeline {
    agent any
    stages {
        stage('SonarQube analysis') {
            steps {
                withSonarQubeEnv('MySonarQube') {
                    sh 'mvn clean verify org.sonarsource.scanner.maven:sonar-maven-plugin:5.8.0.7211:sonar'
                }
            }
        }
        stage('Quality Gate') {
            steps {
                timeout(time: 1, unit: 'HOURS') {
                    waitForQualityGate abortPipeline: true
                }
            }
        }
    }
}

waitForQualityGate はポーリングせず、SonarQubeからのWebhookで結果を受け取ります。SonarQube側でWebhookの宛先を <JenkinsのURL>/sonarqube-webhook/ に設定してください。設定がないと、待機開始時に解析処理が未完了の場合は完了通知を受け取れず、タイムアウトすることがあります。MySonarQube はJenkinsのグローバル設定で登録したサーバ名に置き換えてください。

既存のパイプラインに品質ゲートを入れる設計や、ブランチ戦略に合わせた運用ルールづくりから外部の手を借りたい場合は、DevOps・CI/CD導入支援で相談を受け付けています。

権限とセキュリティ設定：新規プロジェクトは既定で公開

導入直後に見落としやすいのが公開範囲です。SonarQube Serverは新規プロジェクトを既定で「公開（Public）」として作成します。公開プロジェクトは、インスタンスにログインできる全ユーザーがプロジェクトとソースコードを閲覧できます。ログイン必須の設定（Force user authentication）は既定で有効ですが、無効にすると未ログインの利用者にも公開プロジェクトが見えるようになります。チーム外に見せないコードを扱うなら、最初に「Administration > Projects > Management」で新規プロジェクトの既定を「Private」に変え、ログイン必須の設定は無効にしないでください。

権限は、インスタンス全体に効くグローバル権限と、プロジェクトごとの権限の2層です。

注意したいのはExecute Analysisです。公式は、この権限で「パスワードなどの秘匿された認証情報を含む、解析に必要な設定をすべて取得できる」と説明しています。しかもこの権限は既定で全ユーザーが属する sonar-users グループに付いているので、導入直後にグローバル権限を見直します。CI用のトークンは、グローバルのExecute Analysisを持つ個人ユーザーのトークンではなく、発行したプロジェクトの解析だけができる「プロジェクト解析トークン」を使います。

新規プロジェクトに付く権限は「権限テンプレート（Administration > Security > Permission Templates）」で決まります。プロジェクトキーの正規表現でテンプレートを切り替えられますが、テンプレートを変えても既存プロジェクトには反映されず、一括で再適用する操作が別途必要です。セキュアなコードの書き方そのものはセキュアコーディングとはで扱っています。

SonarQube for IDE（旧SonarLint）との違いと連携

SonarQube for IDEは、VS Code・JetBrains系IDE・Visual Studio・Eclipseなどに入れる無料の拡張機能で、入力中のコードをスペルチェッカーのようにその場で指摘します。SonarQube Server・Cloudはプロジェクト全体を集中して解析し、履歴と品質ゲートを管理するサーバ側の製品です。役割が違うので、どちらか一方を選ぶものではありません。

両者をつなぐのが「コネクテッドモード」です。IDEのプロジェクトをServerやCloudのプロジェクトに紐づけると、チームで決めた品質プロファイル（ルールセット）がIDE側にも適用され、サーバで「誤検知」と判定した指摘はIDEにも表示されなくなります。有償版だけのルールや一部の言語は、コネクテッドモードでないとIDEに表示されません。ServerのEnterprise以上でAI CodeFixを有効にしていれば、VS CodeとIntelliJではIDEの中で修正案を受け取れます。

導入判断：Community Buildで足りる条件と足りない条件

Community Buildで足りるのは、対象言語が上の21言語に収まり、mainブランチの状態を定期的に測れればよい場合です。社内の小さなチームが技術的負債の推移を見る、コードレビューの前に機械的な指摘を片付ける、という使い方ならこれで十分です。レビューとの分担はコードレビューとはで整理しています。

次のどれかに当てはまるなら、Community Buildでは足りません。

• プルリクエストごとに品質ゲートを判定し、不合格ならマージを止めたい（ブランチ・PR解析が必要）
• C・C++・Swift・Objective-Cのコードがある
• SQLインジェクションなどを入力の流れから検出したい
• サーバを自前で運用する人手がない

最後の条件に当てはまるなら、Serverの有償版よりSonarQube Cloudを先に検討してください。5万行までの無料枠で、サーバ運用なしにmainブランチ宛てのPR解析まで試せます（無料プランは組織メンバー5人まで）。依存ライブラリの脆弱性管理が主目的なら、SonarQubeではなくSnykのようなSCAツールが本命です。独自ルールを手軽に書きたい場合はSemgrepも候補になります。

カバレッジ80%の条件が厳しすぎると感じたら、Sonar wayを複製したカスタム品質ゲートで閾値を下げられます（Community Buildでも可能）。ただし、閾値を下げる場合は、対象コードのリスクと必要なテスト範囲を根拠に決めます。不合格を消すことだけを目的に、その都度閾値を下げる運用は避けてください。指標と品質ゲートの組み立て方はコード品質とは、カバレッジの目標値の決め方はテストカバレッジとはを参考にしてください。

よくある質問

SonarQubeの読み方は？

「ソナーキューブ」です。検索では「ソナーキューブ」のほか「sonar qube」「sonarcube」と綴られることもありますが、正式な表記はQubeの「SonarQube」です。

SonarQubeは無料で商用利用できますか？

できます。Community Build本体はLGPL-3.0のオープンソースで、同梱の解析エンジン（アナライザー）は2024年11月29日からSonar独自のSSALv1（Sonar Source-Available License）です。自社のコードを解析する使い方には影響がなく、禁止されているのはSonarQubeと同等の機能を他者に製品・サービスとして提供することなどです。無料で使えるのはmainブランチの解析までで、PR解析や一部の言語は有償版かSonarQube Cloudが必要です。

SonarCloudとSonarQubeの違いは何ですか？

SonarCloudは現在「SonarQube Cloud」という名前のSaaS版で、サーバを自分で運用する必要がありません。SonarQube Server・Community Buildは自社のサーバやクラウドにインストールして使います。対応言語やルールの考え方は共通ですが、無料枠の範囲や使える機能は異なります。

Community EditionとCommunity Buildは別物ですか？

同じ無料版です。2024年12月の24.12から名称がCommunity Buildに変わり、以降はほぼ毎月「26.10」のような番号でリリースされています。

SonarQubeの画面は日本語化できますか？

できます。Community BuildとServerは英語の表示だけを標準で持ち、ほかの言語はコミュニティが保守する言語パックのプラグインで追加する仕組みです（公式の国際化ガイド）。日本語は、管理画面のMarketplaceの「Localization」カテゴリに「SonarQube Japanese Pack」（2026年10月時点の版は2025年10月21日公開の25.5）が登録されており、Server 2025.5以降とCommunity Build 25.5以降が対応範囲です。インストールしてサーバを再起動したあと、ブラウザの表示言語を日本語にすると画面が切り替わります。

関連記事

• 静的解析とは？実行せずに欠陥を見つける仕組みとツールの選び方
• コード品質とは？測る指標と品質ゲートでCIに組み込む手順
• SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説
• CI/CDとは：仕組み・パイプライン構成・GitHub Actionsの設定例と導入判断の基準を解説
• テストカバレッジとは？C0/C1/C2の網羅率と計測ツール・目標設定を実装者向けに解説