はじめに

CI/CDパイプラインに静的解析ツールを組み込むのは、もはや標準的なプラクティスになっています。一方で、AIをコード品質向上にどう組み込むかについては、まだ手探りの部分が多いのではないでしょうか。

「AIにコードレビューをさせる」という使い方がまず思い浮かびますが、実際に試してみると、レビューそのものよりも検出済みの指摘に対する修正作業でAIの価値がより明確に出ることがわかりました。

本記事では、静的解析ツール(SonarQube)で品質チェックを行い、その結果をもとにAI(Claude Code)で修正するという役割分担について整理します。

静的解析ツールの役割:コード品質のチェック

静的解析ツールの本質は、あらかじめ定義されたルールセットに基づく決定論的な検出にあります。同じコードに対しては常に同じ結果を返し、実行速度も速く、CI/CDのゲートとして組み込みやすいという特徴があります。

個人開発中のSpring Bootアプリケーションに SonarQube Cloud を導入したところ、以下の3件の指摘が検出されました。

重大度	指摘内容
High	セキュリティ設定ファイルでCSRF保護が無効化されている
Medium	依存ライブラリのバージョンが固定されていない
Low	Dockerfileでの依存関係検証が行われていない

これらはいずれも「既知のアンチパターンに該当するかどうか」という機械的な判定です。ルールが整備されてさえいれば、レビュー担当者のスキルや疲労度に関係なく一定の品質で検出できます。これが静的解析ツールの最大の強みです。

AIの役割:検出結果をもとにした修正

指摘修正でAIは力を発揮しました。「すでに指摘された問題を、コードベース全体の文脈を踏まえて直す」タスクは、AIにとって取り組みやすい性質を持っているためです。

問題箇所が特定済み:静的解析の指摘によって、修正対象のファイル・行が明確になっているため、AIが探索に時間を使わず修正に集中できます
修正方針の選択肢が絞られる:「CSRFを有効化する」「依存バージョンを固定する」のように、指摘内容自体が修正の方向性を示しているため、AIが的外れな提案をするリスクが下がります
周辺コードへの影響確認と同時に行える:修正対象のファイルだけでなく、関連するテストコードや設定ファイルとの整合性まで含めて、一度に確認・修正できます

実際に、SonarQubeが検出した指摘に対して、Claude Codeで修正案の提示から実装まで行いました。単に該当箇所を書き換えるだけでなく、無効化が意図的な設計判断でないかを確認したうえで、関連するテストへの影響も含めて提案する、という流れが機能しました。

これに対して、AIに「ゼロからレビューして問題を見つけてください」と依頼した場合は、指摘の網羅性や優先度判断にばらつきが出やすく、静的解析ツールほどの一貫性は得られませんでした。

なぜこの役割分担が機能するのか

静的解析とAIそれぞれの得意・不得意を整理すると、次のようになります。

	静的解析ツール	AI
検出の網羅性	高い(ルール化された範囲内)	ばらつきが出やすい
検出の一貫性・再現性	高い	低い
修正案の提示	基本的に行わない(一部ツールはAI連携機能で提示)	文脈を踏まえた提案が可能
周辺コードへの影響確認	行わない	テストや関連ファイルまで含めて確認可能
実行コスト	低い(高速・自動)	相対的に高い

「検出」は一貫性と網羅性が命であり、静的解析ツールが最適です。「修正」は文脈理解と柔軟な提案力が求められる作業であり、AIが強みを発揮します。両者を同じ土俵で比較して「どちらが優れているか」を論じるのではなく、検出フェーズと修正フェーズで担当を分けることが、現実的な組み合わせ方だといえます。

実践的なワークフロー

実務では、以下のような流れで組み込むのが現実的です。

静的解析(CI自動ゲート):プッシュ・PR作成のたびに機械的なルール適合性をチェックし、指摘を一覧化します
AIによる修正案の作成:検出された指摘をAIに渡し、修正方針の提示と実装案の作成を行わせます
人によるレビューとマージ:AIの修正案を人が確認し、意図しない副作用がないかをチェックしたうえで反映します

この流れにより、「問題を見つける」フェーズは静的解析の一貫性に任せ、「問題を直す」フェーズはAIの文脈理解力に任せる、という形で両者の強みを活かせます。

まとめ

静的解析ツールとAIは、同じ「コード品質」というテーマを扱いながらも、向いている作業のフェーズが異なります。

静的解析ツール:ルールに基づく検出。一貫性・網羅性・低コストが強み
AI:検出結果をもとにした修正。文脈理解と柔軟な提案力が強み