TL;DR 概要
- このガイドでは、Claude CodeをSonarQube MCPサーバーを介してSonarQube Cloudに接続し、自律的なコードレビューのワークフローを構築する方法を示します。これにより、AIエージェントがコードの作成、スキャン、自己修正を単一の自動ループで実行できるようになります。
- Claude Opus 4.6は、MCPツールを使用してSonarQube Cloudからリアルタイムの品質ゲートステータスと問題データを取得し、検出されたセキュリティ脆弱性（高深刻度のS3バケット所有権問題を含む）や低テストカバレッジを自律的に修正します。
- 安全ガードレールには、エージェントがコミットする前にすべてのコードをSonarQubeスキャナーで確認するよう強制するCLAUDE.mdの指示と、制御不能な自動化を防ぐためのClaudeの
--max-turnsフラグとフックシステムが含まれています。 - その結果、AIエージェントは単にコードを書くだけでなく、エンジニアリング標準に対して自律的に責任を負い、すべての修正が品質ゲートを通過することを確認してからコードをプッシュします。
Claude Opus 4.6がリリースされたばかりで、私たちは公式に超高速コーディングの時代に突入しました。これらの驚異的なツールは、さらに驚異的な速度でコードを生成することができます。
しかし、この能力には欠点もあります。AIツールには盲点があるため、速度は品質を意味しません。セキュリティ脆弱性を導入したり、非推奨のライブラリを使用したり、技術的には動作するが6か月後には保守が困難になるロジックを書くことがあります。注意しないと、ソフトウェア開発者として、行ごとに読み、レビューし、ソフトウェアバグを修正し、モデルに何が間違っていたかを説明する「清掃員」のような役割を果たすことになります。
しかし、より良い方法があります！このループを閉じることが可能です。ClaudeにSonarQube Cloudへの直接アクセスを与えれば、コードレビューと自己修正が可能になります。コードを書き、スキャンし、セキュリティホールを発見し、修正し、クリーンな結果を提供できます。
このワークフローは次のように設計します：
- エージェントがローカルでコードを生成します。
- エージェントが
sonar-scannerバイナリをトリガーしてスナップショットをアップロードします。 - SonarQube Cloudがコードレビューを行い、非同期で分析を処理します。
- エージェントがSonarQube MCPサーバーに問い合わせて特定のエラーを取得します。
- エージェントが自律的にコードをリファクタリングし、品質ゲートを通過するまで続けます。
1. 前提条件
続けるためには、いくつかの基本的な設定が必要です。
- SonarScanner CLI: コードを分析用にパッケージ化するエンジン。
- クイックチェック:
sonar-scanner -vを実行します。（Javaランタイムがインストールされていることを確認してください）。 - SonarQube MCPサーバー: ClaudeがSonarQubeとの連携を可能にするブリッジ。
- セットアップガイド: 公式SonarQube MCPドキュメント
注意: 手動JSON設定を使用することをお勧めします。
- Claude Code: インストールされ、認証済み
2. プロジェクト設定
プロジェクト構造をスキャナーに毎回説明する手間を省くために、プロジェクトのルートにsonar-project.propertiesファイルをドロップします。
ファイルを作成し、以下を貼り付けます：
sonar.projectKey=YOUR_PROJECT_KEY
sonar.organization=YOUR_ORG_KEY
sonar.sources=.
sonar.sourceEncoding=UTF-8
sonar.exclusions=**/node_modules/**,**/dist/**,**/.git/**,**/venv/**
sonar.qualitygate.wait=true3. 行動の強制
品質を必須とするようClaudeに指示する必要があります。これを行うには、ルートディレクトリにCLAUDE.mdファイルを作成します。
1. You MUST verify All generated code before asking me to push.
2. To verify code, run the `sonar-scanner` command.
3. When running the scanner, use the `SONAR_TOKEN`, which I will have exported in the session.
4. After scanning, use your MCP tools to check the Quality Gate status or read the scanner output to identify issues.
5. If SonarQube reports bugs or smells, fix them immediately and re-scan. If low test coverage is causing a failed quality gate, you MUST treat this as a blocking issue requiring code generation (Unit Tests).
Only recommend pushing when the Quality Gate PASSES.4. 実際に見てみる（楽しい部分）
設定が完了したので、実際の実行を見てみましょう。ClaudeにCSVをAWS S3にアップロードするPythonスクリプトを生成するよう依頼します。これは、隠れたセキュリティリスクを含むことがよくあります。
プロンプト: セッションでトークンを安全に渡してから、プロンプトを与えます（コマンドの前にスペースを追加すると、一部のシェルで履歴に残らないようにするため推奨されます）。環境変数としてトークンを設定している場合、これを行う必要はありません。sonar-scannerバイナリは自動的にSONAR_TOKENを探します。
export SONAR_TOKEN=your_token_value
claude
コンテキストチェック: Claudeは賢く、正しいプロジェクトを参照していることを確認します。MCPツールを使用してアカウントを検索します。
脆弱性: ここが面白いところです。Claudeはコードを書き、スキャナーを実行し、SonarQube Cloudがいくつかの条件に失敗したことを検出しました。これにはテストカバレッジと高深刻度の問題が含まれます。具体的には、ルールS7608: S3操作はバケット所有権を確認する必要があります。
これを手動でコーディングしていたら、そのパラメータを見逃していたかもしれません。しかし、ここでClaude Opus 4.6が本当に輝きます。ルールを深く掘り下げて分析し、なぜ失敗したのかを正確に理解します。
修正: Claudeはツールの出力からドキュメントを読み、ExpectedBucketOwnerパラメータが必要であることを認識し、自律的に修正を適用します。Opus 4.6は、この多段階の推論に特に優れており、エラーログとドキュメントを容易に結びつけることができます。
結果: 最後に、検証スキャンを実行します。コードはクリーンで、セキュリティの脆弱性が修正され、テストが追加され、品質ゲートが通過しました。
ループの強化: イテレーションキャップとガードレール
この記事を公開した後、読者からこのワークフローを使用してエージェントが40分間の修正と破損を繰り返すサイクルに陥ったという報告がありました。彼らの診断は「SonarQubeのルールが互いに矛盾している」というものでした。それは対処すべき実際の問題ですが、診断は間違っています。
SonarQubeのルールはソースコードを独立して分析します。それぞれがASTとセマンティックモデルを独自に評価し、他のルールの出力に依存しません。
実際に起こることはもっと微妙です。エージェントは部分的な修正で一つの問題を解決し、偶然に新しい違反を導入します。Javaのような言語では、認知的複雑性を減らすためにメソッドを抽出すること（S3776）が理論的には「メソッドが多すぎる」というルール（S1448）に抵触する可能性がありますが、S1448のデフォルトのしきい値は35メソッドです。そして、PythonではS1448が適用されないため、エージェントのメソッド抽出が他の場所で新しい複雑さを引き起こすリスクがあります。いずれにせよ、ルールは互いに矛盾していません。エージェントは個々のエラーメッセージに対処するだけの、いわばモグラたたきをしているだけで、全体的にリファクタリングしていません。
それに「すぐに修正して再スキャンする」という元の指示（上限なし）を組み合わせると、エージェントはあなたがそれを停止させるか、コンテキストを失うまでループし続けます。
修正は簡単です。反復回数の上限（イテレーションキャップ）と、「停止して報告する」というフォールバック設定をCLAUDE.mdに追加します。
1. You MUST verify all generated code before asking me to push.
2. To verify code, run the `sonar-scanner` command.
3. When running the scanner, use the `SONAR_TOKEN`, which I will have exported in the session.
4. After scanning, use your MCP tools to check the Quality Gate status or read the scanner output to identify issues.
5. If SonarQube reports bugs or smells, fix them and re-scan. You may attempt a maximum of 3 fix-scan cycles.
6. If issues persist after 3 cycles, stop and report the remaining issues to me with your analysis of why they’re recurring. Do not keep looping.
7. When fixing issues, refactor holistically — don’t fix rules one at a time in isolation. Consider how your fix affects the broader class and module design.
8. If low test coverage is causing a failed quality gate, you MUST treat this as a blocking issue requiring code generation (unit tests).
9. Only recommend pushing when the Quality Gate PASSES.主な変更点: 修正-スキャンサイクルの上限を3回に設定（ルール5）、無限ループせずに停止して報告する明示的な指示（ルール6）、ルールを個別に修正するのではなく全体的にリファクタリングするガイダンス（ルール7）。最後のポイントが最も重要です。複雑性警告を修正する際にクラス全体の設計を考慮するエージェントは、プロセス中に意図せず「神クラス」（God Class）を作成してしまうことを防ぎます。
追加の安全策として、Claude Codeはさらに2つのガードレールを提供します。--max-turnsフラグは、印刷モード（-p）で実行する際のエージェントのターン数を制限します。また、フックシステムを使用すると、PreToolUseのようなライフサイクルイベントにシェルコマンドを接続し、N回の呼び出し後にスキャナーをブロックするサーキットブレーカー（安全装置）を構築できます。sonar-scannerの実行回数をカウントするには、Bashツールとの照合によりコマンド内容を確認し、MCPからの問題取得呼び出しをカウントするには、MCPツール名に直接照合させます。
以上です。Claude Opus 4.6の推論の深さとSonarQubeの厳格なコードレビューと検証を組み合わせることで、コードを書くだけでなく、エンジニアリング標準に対し自律的に責任を負うAIエージェントが実現します。
