SonarQubeのMCPサーバーをClaude Codeに接続する手順

SonarQube MCP Serverは、SonarSourceが公式に配布するMCP(Model Context Protocol)サーバーです。SonarQube CloudまたはSonarQube ServerのIssue・Security Hotspot・Quality Gate・カバレッジ情報を、Claude Codeから自然文で照会できるようになります。作業ディレクトリ内のファイルをまとめてSonarQubeの解析にかけるanalyze_file_listも備え、コミット前のチェックに使えます。

導入はDockerコンテナ1本の起動で完結し、claude mcp add にDocker実行コマンドを渡すだけです。ただしSonarQube CloudかSonarQube Serverかで必要な環境変数が異なり、トークンの種別を間違えると接続はできてもツールが機能しません。

SonarQube MCPサーバーとは何ができるか

SonarQube MCP Serverは、SonarQubeが持つIssue・Security Hotspot・Quality Gate・カバレッジ・依存関係リスクの各データをMCPツールとして公開するサーバーです。コンテナイメージsonarsource/sonarqube-mcpとしてDocker Hubで配布され、SonarQube CloudとSonarQube Serverの両方に対応します。

単体の静的解析ツールではありません。既存プロジェクトに登録済みのSonarQube解析結果を、Claude Codeのセッション内から検索・参照・更新するためのブリッジです。加えて、作業ディレクトリ内のファイルをその場でSonarQubeのアナライザーにかけるanalyze_file_listのような機能も持ち、コミット前のクイックチェックにも使えます。以前の単一ファイル解析analyze_code_snippetはREADME上でdeprecated扱いとなっており、後継のanalyze_file_listやVortex解析(統合vortexツールセット)への移行が案内されています。

対応言語はJava、Kotlin、Python、Ruby、Go、JavaScript(js/jsx)、TypeScript(ts/tsx)、JSP、PHP、XML、HTML、CSS、CloudFormation、Kubernetes、Terraform、Azure Resource Manager、Ansible、Docker、シークレット検出と幅広く、SonarQube本体が対応する言語の大半をカバーします。

導入前に確認すること — SonarQube CloudかServerか

環境変数の組み合わせが接続先ごとに異なるため、どちらに繋ぐかを最初に決めます。判定は簡単で、SONARQUBE_ORGを渡せばCloud、渡さなければServerとしてstdioモードのサーバーが自動判別します。

SonarQube Serverのトークンは、ユーザートークン以外を渡すと接続自体は成立してもAPI呼び出しが失敗します。プロジェクトトークンを使い回して繋がらないという相談は、この種別違いが原因であることがほとんどです。

Claude Codeへの接続手順(claude mcp add)

コンテナイメージをそのままclaude mcp addのコマンド部分に渡します。トークンをコマンドライン引数に直書きするとshell履歴に残るため、--envフラグで環境変数として渡すのが公式の推奨です。

SonarQube Cloudへの接続:

claude mcp add sonarqube \
  --env SONARQUBE_TOKEN=$SONAR_TOKEN \
  --env SONARQUBE_ORG=$SONAR_ORG \
  -- docker run --init --pull=always -i --rm \
     -e SONARQUBE_TOKEN -e SONARQUBE_ORG \
     sonarsource/sonarqube-mcp

SonarQube Serverへの接続:

claude mcp add sonarqube \
  --env SONARQUBE_TOKEN=$SONAR_USER_TOKEN \
  --env SONARQUBE_URL=$SONAR_URL \
  -- docker run --init --pull=always -i --rm \
     -e SONARQUBE_TOKEN -e SONARQUBE_URL \
     sonarsource/sonarqube-mcp

--より前がclaude mcp add自身のオプション、後ろがコンテナに渡すコマンドです。--pull=alwaysを付けると起動のたびに最新イメージを確認するため、バージョン固定が必要な本番運用以外ではこのままで問題ありません。設定を手で書きたい場合は、SonarQube MCP Server Configuration Generatorが接続先に応じた設定を生成してくれます。

接続後は転送モードにも触れておきます。既定はstdio(ローカルでサブプロセスとして起動)で、Claude Codeのようなローカルクライアントにはこれが推奨です。複数人でリモート共有する場合のみHTTP/HTTPSのStreamable HTTPモードをSONARQUBE_TRANSPORT=httpまたはhttpsで有効にします。個人のClaude Code利用ではstdioのままで足ります。

使えるツールとツールセットの絞り込み

既定で有効なツールセットはanalysis・ide・issues・projects・quality-gates・rules・duplications・measures・security-hotspots・dependency-risks・coverage・cagの12種類です。projectsは常時有効で、他のツールがプロジェクトキーを解決するために必須のため無効化できません。

全ツールを常時ロードするとコンテキスト消費が増えるため、SONARQUBE_TOOLSETS環境変数で必要なものだけに絞り込めます。

書き込み系の操作(Issueのステータス変更など)を止めたい場合はSONARQUBE_READ_ONLY=trueを追加します。この2つのフラグは組み合わせ可能で、閲覧専用のツールセットに絞った上でさらに書き込みを禁止するといった二重の制限もかけられます。

読み取り専用に絞らない場合は、Issueそのものを操作するツールも使えます。change_sonar_issue_statusはIssueをaccept(受け入れ)・falsepositive(誤検知)・reopen(再オープン)のいずれかに変更でき、Security Hotspotもchange_security_hotspot_statusでTO_REVIEWからREVIEWEDへレビュー結果(FIXED/SAFE/ACKNOWLEDGED)付きで移せます。「このプロジェクトの誤検知Issueに理由をつけてまとめて却下して」のような一括処理をエージェントに任せられるのは、書き込み系ツールを有効にしたときだけです。

SonarQube for IDEとの連携

エディタ側でSonarQube for IDE(旧SonarLint)を併用しているなら、SONARQUBE_IDE_PORT(64120〜64130の範囲)を環境変数に追加することでMCPサーバーとブリッジできます。VS Code版のSonarQube for IDEにはワンクリックでポート設定まで済ませるインストールボタンが用意されており、手動でポート番号を調べる手間はかかりません。ブリッジが有効になると、analyze_file_list(作業ディレクトリ内のファイルをまとめて解析)やtoggle_automatic_analysis(保存のたびに自動解析するかどうかの切り替え)も使えるようになります。

Linux上でコンテナとしてMCPサーバーを動かす場合は注意が必要です。コンテナはデフォルトでlocalhost上のSonarQube for IDE組み込みサーバーへ到達できないため、docker runに--network=hostを追加してホストネットワークを共有させます。

Claude Code以外にも、Cursor・VS Code・Windsurf・Zed・GitHub Copilot CLI・Codex CLIなど主要なAIクライアントの多くに公式の設定手順が用意されています。チームでエディタが揃っていない場合でも、同じDockerイメージを使い回して各クライアントの設定ファイルに合わせて書き換えるだけで済みます。

よくあるつまずき

Dockerイメージが古いまま更新されない。dockerはイメージをローカルにキャッシュするため、sonarsource/sonarqube-mcpを一度取得すると自動では更新されません。「ツールが動かない」「機能が足りない」と感じたら、まずdocker pull sonarsource/sonarqube-mcpを実行してからClaude Codeを再起動します。--pull=alwaysをdocker runに付けておけば毎回最新を確認するので、日常利用ではこちらを既定にしておくのが安全です。

巨大ファイルでコンテキストを消費しすぎる。analyze_file_listは既定でファイル全文をエージェントの引数として渡すため、大きなファイルを何本も解析するとコンテキストウィンドウを圧迫します。プロジェクトディレクトリを/app/mcp-workspaceにマウントしておくと、サーバーがファイルをディスクから直接読むモードに切り替わり、ファイル内容がエージェントのコンテキストを通らなくなります。組織がVortex解析に対応していれば、このマウントを条件にrun_advanced_code_analysisも使えるようになります。なお旧来の単一ファイル解析analyze_code_snippetとcagツールセットはREADME上でdeprecated扱いのため、コミット前チェックはanalyze_file_list側の動線に寄せておくのが安全です。

SonarQube Serverのトークン種別違い。前述のとおり、Server接続ではUSERトークンが必須です。プロジェクトトークンやグローバルトークンを渡すと、接続ログ上はエラーが出ないまま個別のAPI呼び出しだけが失敗するため、原因が分かりにくいつまずきです。

バージョン固定の必要がある本番運用。--pull=alwaysは開発環境では便利ですが、CI/CDやチーム共有のサーバーで急に別バージョンへ切り替わると再現性が崩れます。sonarsource/sonarqube-mcpのタグ一覧からsonarsource/sonarqube-mcp:1.19.0.2785のようにバージョンを指定し、--pull=alwaysは外します。

匿名テレメトリと利用データの扱い

SonarQube MCP Serverは既定で匿名の利用状況データをSonarSourceへ送信します。ソースコードやIPアドレスは収集対象に含まれません。送信を止めたい場合はTELEMETRY_DISABLED=trueを環境変数に追加します。ライセンスはSONAR Source-Available License v1.0(SSAL)で、本ドキュメントの用法に従う限り非競合目的の利用として許可されています。

まとめ

SonarQube CloudかServerかで必要な環境変数(SONARQUBE_ORGの有無、トークンの種別)が変わる点さえ押さえれば、接続自体はclaude mcp addにDockerコマンドを渡す1回の操作で終わります。既存のCI/CDにSonarQube解析を組み込み済みのチームなら、Issue・Quality Gate・カバレッジの照会をClaude Codeのセッション内で完結させられる構成です。ツールセットを絞り込まずに使い始めても動きますが、コンテキスト消費が気になってきたらSONARQUBE_TOOLSETSで用途別に削るとよいでしょう。

MCPサーバーの基本設定(スコープ・.mcp.json・OAuth認証)を先に押さえたい場合はClaude Code MCP設定ガイドを、Claude CodeをGitHub ActionsのCI上で動かす前提を整えたい場合はClaude CodeをGitHub Actionsに組み込むを参照してください。