Qodanaは、JetBrains社が開発した静的解析ツールです。
IntelliJ IDEAやWebStormが内蔵する解析エンジンをそのままCI/CDやコマンドラインから動かせるようにしたのが最大の特徴で、「IDE上で見える警告」と「CIで出る警告」が完全に一致します。
SonarQubeやESLintを併用していた頃に何度も悩まされた「IDEとCIで指摘がズレる」問題は、Qodanaに切り替えてから一度も起きていません。
この記事を読み終えると、Dockerが入った環境で docker run 1コマンドからQodanaを実行し、qodana.yamlで除外設定を最小構成に整え、GitHub Actionsへ組み込むまでの流れを一通り掴めます。
さらに、既存プロジェクトに導入するときの「警告爆発問題」をBaseline機能で回避する実践Tipsも紹介します。
かつての私は「静的解析なんてうるさいだけだ」と感じていましたが、Qodanaを導入してからはレビューでの指摘事項が激減し、本質的な設計議論に時間を使えるようになりました。
これから紹介する手順は、実際に複数プロジェクトで運用してきた構成を最小単位に削ぎ落としたものです。
※本記事はQodana 2026.2系（2026年7月リリース）および Qodana Cloud（2026年8月時点）の仕様をもとに記載しています。プラン構成・価格は変更される場合があるため、最新情報はJetBrains公式ページをご確認ください。この記事でわかること
- QodanaとSonarQube・ESLintの違いと、選ぶ基準
- Docker 1コマンドでQodanaを動かす最小手順
- qodana.yamlの最低限テンプレートと除外設定の考え方
- GitHub ActionsでQodanaを自動実行するサンプルワークフロー
- 既存コードに大量の警告が出たときのBaseline運用
導入までの流れをステップで見ると、以下の4段階です。
step
1Dockerでローカル実行する
step
2qodana.yamlを作成する
step
3GitHub Actionsに組み込む
step
4Baselineで既存の指摘を棚上げする
PARTS LIST ／目次
Qodanaとは何かを最短で理解する
Qodanaとは、JetBrains社が提供する静的解析プラットフォームで、IntelliJ IDEAやWebStormが内蔵する解析エンジンをCI/CDやコマンドラインから実行できるようにしたツールです。SonarQubeやESLintと違い、IDE上の指摘とCI上の指摘が完全に一致する点が最大の特徴です。
qodana.yamlルール・除外設定静的解析とは何をしてくれる仕組みなのか
静的解析は、プログラムを実際に動かすことなく、ソースコードの「形」を調べて問題を見つける仕組みです。
スペルミスのような単純なものから、メモリリークの可能性、デッドコード（どこからも呼ばれていないコード）、さらにはセキュリティ上の脆弱性まで、多角的にチェックしてくれます。
私はこれを「コードの健康診断」だと捉えています。
人間が目視で確認するとどうしても見落としが発生しますが、解析ツールは24時間365日、一切の妥協なくコードを精査し続けます。
実行前にエラーの種を摘み取ることができるため、本番環境で障害が起きてから青ざめるリスクを大幅に減らしてくれます。
Qodanaが他の静的解析ツールと違う点
Qodanaが他のツール、例えばESLintやSonarQubeなどと決定的に違うのは、JetBrainsのIDEと「完全に同じロジック」で動く点です。
多くの静的解析ツールは、IDEの指摘内容とツール側の指摘内容が微妙に異なり、開発者が混乱することがよくあります。
しかし、Qodanaなら「手元のIntelliJで見えている警告」と「CIで出る警告」が完全に一致します。
この一貫性が、開発者のストレスを劇的に減らしてくれます。
また、Dockerベースで動くため、複雑な環境構築を必要とせず、どんなプロジェクトにもすぐ導入できる点も大きな強みです。
選び方の目安としては、JetBrains IDE をチームで使っているなら Qodana が一択です。
多言語の大規模プロジェクトで品質ゲートを厳格に運用したいなら SonarQube、JS/TS 単体プロジェクトなら ESLint で十分という棲み分けになります。
Qodanaの料金プラン｜Community/Ultimate/Ultimate Plusの違い
結論から言うと、個人開発やOSSならCommunityプラン（無料）で十分です。Qodanaは「Community」「Ultimate」「Ultimate Plus」の3つのプランに分かれており、加えて結果可視化サービス「Qodana Cloud」が用意されています。最初の検証段階ではCommunityプランで十分なケースがほとんどです。
- Community: 無料。Java / Kotlin / PHP / Python など主要言語のリンター利用が可能。OSS や個人開発はこれで開始できる。
- Ultimate: 有料（目安 契約者数×月額6ドル・最低3契約者〜、2026年8月時点の複数販売代理店の掲載額より）。タイムトラベル解析や、より多くのインスペクションが解放。
- Ultimate Plus: 有料（目安 契約者数×月額15ドル〜）。ライセンス監査、SSOに加え、OWASP Top 10に対応したtaint解析（Java/Kotlin/PHP/Python対象）やポスト量子暗号インスペクションなど、2026.2で強化されたセキュリティ機能が使える。エンタープライズ向け。
- Qodana Cloud: 解析結果を保存・履歴比較するクラウド側サービス。商用利用も小規模なら無料枠あり。
JetBrainsの公式ドキュメント（2026年8月時点で公開中）で最新の価格と内訳が確認できるため、本格導入前に必ずチェックしてください。
私の体感では、まずCommunityで運用を回し、Ultimateの機能（タイムトラベル解析など）が必要になった段階で課金検討するのが無駄のない進め方です。
最初は Community で運用を回し、「この機能が無いと困る」が明確になってから上位プランに上げる順序がコスト効率上ベストです。
Qodanaで解決できる開発上の悩み
開発をしていると、どうしても避けられない「心理的摩擦」があります。その多くは、コードの書き方や品質に対する認識のズレから生まれます。
私は、Qodanaを入れることでこれらの摩擦が激減し、チームの雰囲気が良くなるのを何度も見てきました。
ツールが「正解」を提示してくれることで、感情的な議論が不要になるからです。
レビューで毎回指摘されるコード品質の問題
プルリクエストを出すたびに「インデントがずれている」「変数の命名が分かりにくい」「このメソッドは長すぎる」といった指摘を受けるのは、正直言って疲れます。
指摘する側も、重箱の隅をつつくような真似はしたくないはずです。
Qodanaを導入すれば、こうした「基本的なミス」はレビューに回る前にすべて自動で検知されます。
指摘事項がゼロの状態でレビューを依頼できるようになるため、レビュアーはロジックの本質的な部分に集中できます。
指摘の中身も「インデント」「未使用変数」「命名」といった機械的なものが消え、設計やAPI境界の議論に時間を使えるようになっています。
チーム内でコーディングルールが揃わない問題
複数人で開発していると、人によって書き方のクセが出るのは当然です。
しかし、それが積もり積もると、プロジェクト全体のコードがバラバラになり、メンテナンス性が著しく低下します。
ルールをドキュメントにまとめても、全員がそれを暗記して守るのは不可能です。
Qodanaは、設定ファイルを1つ用意するだけで、チーム全員に同じ「解析の物差し」を強制できます。
誰が書いても一定以上の品質が担保される仕組みができあがります。
新しく入ったメンバーも、Qodanaの指摘に従うだけでチームの作法を学べるため、教育コストの削減にもつながります。
Qodanaを使う前に知っておくべき前提知識
Qodanaは強力ですが、魔法の杖ではありません。
導入する前に、自分のプロジェクトで使えるのか、どのような形態で運用するのかを把握しておく必要があります。
ここを疎かにすると、せっかく導入しても「使いにくい」と感じてしまうかもしれません。
Qodanaの対応言語・IDE・CI環境一覧（Java/Kotlin/Python/JS対応）
Qodanaは、Java、Kotlin、PHP、Python、JavaScript、TypeScript、Go、C#など、主要なプログラミング言語のほとんどをカバーしています。
基本的にはJetBrainsがサポートしている言語であれば、Qodanaでも解析できると考えて間違いありません。
また、GitHub Actions、GitLab CI/CD、Jenkins、Azure DevOpsといった主要なCIツールとの連携をJetBrainsが公式にサポートしています。
IDEについては、やはりJetBrains製ツールとの相性が抜群ですが、VS Codeを使っている開発者がいるプロジェクトでも、CI上でQodanaを回すことで品質の底上げが可能です。
ローカル実行とCI実行の考え方の違い
Qodanaには「自分のPCで動かす（ローカル実行）」と「サーバーで自動で動かす（CI実行）」の2通りの使い方があります。
私の推奨は、この2つを組み合わせるハイブリッド運用です。
ローカル実行は、コードをコミットする前に自分でサッと確認するために使います。一方でCI実行は、チームの最終防衛ラインとして機能します。
ローカルで忘れてしまった指摘をCIで捕まえることで、汚れたコードがメインブランチに混入するのを100%防ぐことができます。
この「二段構え」の体制を作ることが、品質維持の鍵となります。
Qodanaで静的解析を実行する基本手順
それでは、実際にQodanaを動かす流れを見ていきましょう。難しそうに感じるかもしれませんが、基本は驚くほどシンプルです。
Dockerさえインストールされていれば、コマンドを1つ叩くだけで解析が始まります。
最小構成でQodanaを動かす流れ
まずは、プロジェクトのルートディレクトリで以下のコマンドを実行してみてください。Qodana導入の第一歩です。
docker run --rm -it \
-v <プロジェクトのパス>:/data/project \
-p 8080:8080 \
jetbrains/qodana-<言語名> --show-reportこのコマンドを打つと、Qodanaがプロジェクト内のファイルをスキャンし始めます。解析が終わると、ブラウザで詳細なレポートが見られるようになります。
たったこれだけで、数千件におよぶチェック項目が走り、あなたのコードの弱点が暴き出されます。
初めて実行したときは、あまりの指摘の多さに絶望するかもしれませんが、それは伸び代がある証拠なので安心してください。
初回スキャンはlinterイメージのpullを含めるため、数分かかる場合があります。
CI環境（GitHub Actions ubuntu-latest）ではDockerレイヤーキャッシュを効かせても初回5分前後は見ておくと、パイプライン設計時のタイムアウト設定で慌てずに済みます。
解析結果はどこに、どう表示されるのか
解析が終わると、デフォルトでは http://localhost:8080 でリッチなUIのレポートが表示されます（バージョンによってはブラウザが自動で開かないため、URLが表示されたら手動でアクセスしてください）。
このレポートの出来がよく、どのファイルのどの行に問題があるのかが直感的に分かります。
単にエラー箇所を示すだけでなく、「なぜこれが問題なのか」「どう直すべきか」という修正案までセットで提示してくれます。
Qodana Cloudというクラウドサービスを使えば、過去の解析結果との比較や、プロジェクト全体の品質推移をグラフで可視化することも可能です。
Qodana CLIでローカルインストールする方法
Dockerを使わず、ホストマシンに直接コマンドを入れたい場合はQodana CLI（qodana コマンド）が使えます。
macOSなら Homebrew で一発です。
brew install jetbrains/utils/qodana
qodana scanCLI経由でもバックエンドではDockerコンテナが起動する仕組みは同じですが、コマンドが短くなり、CI設定ファイルの記述もシンプルになります。
個人的には、ローカルで頻繁に実行するなら CLI、CI専用なら公式アクション（後述）という使い分けが手間なく回ります。
IntelliJ IDEAプラグインとしてQodanaを使う方法
CIに組み込む前に、まずIDE単体で挙動を確認したい場合は「Qodana」公式プラグインをIntelliJ IDEAやWebStormにインストールする方法もあります。
Settings → Plugins → Marketplace で「Qodana」を検索してインストールするだけで、エディタ上でCIと同じ指摘をリアルタイムに確認できます。
私はまずこのプラグインで「どのくらい警告が出るか」の肌感を掴んでから、Docker/CLIでのCI組み込みに進むという順序を勧めています。
いきなりCIに入れて大量の指摘に面食らうより、IDE上で少しずつ慣らしておく方が心理的なハードルが下がります。
qodana.yamlの役割と最低限の設定ポイント
Qodanaの挙動をカスタマイズするには、プロジェクトのルートに qodana.yaml という設定ファイルを作成します。
これがないとQodanaは「標準設定」で動きますが、自分のプロジェクトに合わせて微調整することで、より実用的なツールに進化します。
設定ファイルで何が制御できるのか
qodana.yaml では、主に以下の項目をコントロールできます。
- 解析対象から除外するディレクトリ（サードパーティ製のライブラリなど）
- 無視する警告の種類（特定のルールがプロジェクトに合わない場合）
- 解析の厳格さ（エラーとして扱うか、警告として扱うか）
私は、最初はあまり細かく設定しすぎないことを勧めています。
まずはデフォルトで動かし、どうしてもノイズになる項目が出てきたときに、1つずつ設定ファイルに書き足していくのが効率的です。
初心者が最初に触るべき設定項目
最低限、これだけは書いておくと良いという設定例を紹介します。
version: "1.0"
linter: jetbrains/qodana-js:latest
exclude:
- name: All
paths:
- node_modules
- distビルド済みのファイルやライブラリが含まれるディレクトリを除外する設定は必須です。
これを行わないと、自分が書いたわけではないコードの修正を求められ、解析時間も無駄に長くなってしまいます。
まずは「自分たちが書いたコードだけを評価する」設定から始めましょう。
なお、Qodana 2026.2からは codeCoverageLocations パラメータが追加され、カバレッジレポートの置き場所をqodana.yaml側で明示できるようになりました。
プルリクエスト上で未カバー行がハイライト表示される機能もこのバージョンから強化されているため、カバレッジ計測をすでに導入しているプロジェクトなら合わせて設定しておくと恩恵が大きいです。
CIにQodanaを組み込む具体的な方法
ローカルで動かせるようになったら、次はCI（継続的インテグレーション）への組み込みです。ここがQodanaの真骨頂。
開発者が意識しなくても、プルリクエストのたびに自動でチェックが走る仕組みを作ります。
GitHub ActionsでQodanaを自動実行する設定
GitHubを使っているなら、公式が提供している qodana-action を使うのが最も簡単です。
.github/workflows/qodana.yml というファイルを作成し、以下の内容を記述します。
name: Qodana
on:
pull_request:
push:
branches:
- main
jobs:
qodana:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: 'Qodana Scan'
uses: JetBrains/[email protected]
env:
QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}バージョンタグ（@v2026.1）は本記事執筆時点（2026年8月）の目安です。
JetBrainsは年2回ペースでメジャーバージョンを更新しているため、導入時は qodana-actionのリリースページ で最新タグを確認してから固定することをおすすめします。
これで、コードをプッシュするたびにQodanaが走り、解析結果がGitHubの「Checks」タブに表示されるようになります。
不合格ならマージできないように制限をかけることもできるため、コードの品質を強制的に一定レベル以上に保つことができます。
CIに入れることで得られる実務的なメリット
最大のメリットは、「品質への責任」をツールに押し付けられることです。
人間が「ここ直して」と言うと角が立つことがありますが、ツールが「ここダメだよ」と言う分には誰も怒りません。
また、CIで解析結果が蓄積されることで、「最近バグが増えてきたな」「コードが複雑になってきたな」といった傾向を客観的なデータで把握できるようになります。
主観に頼らない意思決定ができるようになるため、エンジニアリングマネージャーにとって心強い武器になります。
Qodana Cloud で解析結果を可視化する
ローカルやCIで解析した結果は、デフォルトでは実行ごとに使い捨てになります。
長期運用で「品質が改善しているか」を客観的に確認したい場合は、結果の保存先として Qodana Cloud を併用するのが効果的です。
Qodana Cloud に解析結果をアップロードすると、プロジェクト単位でダッシュボードが生成され、Error / Warning の推移、コードカバレッジ、ホットスポットファイルがグラフで把握できます。
CI設定で QODANA_TOKEN を発行して環境変数に渡すだけで連携が始まるため、追加のサーバー構築は不要です。
個人プロジェクトでも、月次で品質グラフを眺めるとリファクタのモチベーションが続きます。
チーム運用ではスプリントレビューに数値を持ち込めるため、感覚論ではなくデータで品質改善を語れるようになります。
Qodanaの解析結果をどう読み、どう活かすか
ツールを導入した後に多くの人が直面するのが、「指摘が多すぎてどこから手をつければいいか分からない」という問題です。
すべての警告をゼロにするのは理想ですが、現実的ではありません。ここでは、効率的な向き合い方を説明します。
警告レベルと重要度の考え方
Qodanaには「Error（エラー）」「Warning（警告）」「Weak Warning（弱い警告）」「Information（情報）」という4つのレベルがあります。
- Error: 直ちに修正すべき致命的な問題（実行エラーの可能性が高い）
- Warning: 放置すると問題が起きる可能性が高いもの
- Weak Warning: コードの読みやすさやベストプラクティスに関するもの
- Information: 統計的な情報やヒント
私は、まず「Error」をゼロにすることを絶対条件にしています。次に「Warning」を優先します。
なかでもセキュリティ関連やバグ直結のものは即修正対象です。Weak Warning以下は、余裕があるときに少しずつ改善する程度で構いません。
すべて直すべきか判断するための基準
結論から言うと、すべての警告を直す必要はありません。 完璧主義に陥ると、開発の手が止まってしまうからです。
修正するかどうかの判断基準は「その修正が将来の自分たちを助けるか」です。例えば、1回限りの使い捨てスクリプトなら、多少汚くても動けば問題ありません。
一方で、今後何年もメンテナンスし続けるコアなロジックであれば、たとえ「Weak Warning」であっても徹底的に綺麗にする価値があります。
プロジェクトのフェーズやコードの重要度に応じて、柔軟に判断しましょう。
Qodana導入でつまずきやすいポイントと対処法
どんなに優れたツールでも、導入時には必ず壁にぶつかります。特に既存の大きなプロジェクトに導入する場合、最初のハードルはかなり高いです。
私の経験から、よくある失敗パターンとその乗り越え方をお伝えします。
警告が多すぎて現実的に直せない場合
古いプロジェクトに初めてQodanaをかけると、数千〜数万件の指摘が出ることがあります。
指摘の量に圧倒されて「やっぱり導入はやめよう」と諦めてしまうのは、かなりもったいないです。
そんなときは、Qodanaの「Baseline（ベースライン）」機能を使いましょう。
これは、現時点での指摘をすべて「既知の問題」として記録し、次回の解析からは「新しく増えた指摘」だけを通知してくれる機能です。
過去の借金は一旦棚上げして、まずは「これ以上コードを汚さない」ことから始める。これが、現実的で賢い戦略です。
baseline.json を .gitignore に入れたままだと、CIで比較が働きません。リポジトリにコミットしておきます。Baseline導入時にありがちな失敗があります。
生成した baseline.json を .gitignore に入れたままCIに乗せると、CI上でベースラインが存在せず、既存の指摘との比較が意図どおりに働きません。baseline.json はリポジトリにコミットしておきます。
Baselineファイルは必ずリポジトリにコミットし、CI側では新規生成せず既存ファイルを読み込ませる設定になっているか確認してください。
地味ですが、ここを飛ばすと「導入したのに全く機能していない」状態に気づかず放置することになります。
Docker実行で起きやすいエラーと対処（OOM・パーミッション）
Qodanaの初回実行で詰まりやすいのが、Dockerコンテナのメモリ不足とボリュームのパーミッションエラーです。
私自身、いずれも初回セットアップで一度はぶつかりました。
- OOM (Out Of Memory): 大規模プロジェクトでJVMが落ちるケース。Docker Desktop のメモリ割当を 4GB → 8GB に引き上げ、
-e _JAVA_OPTIONS="-Xmx6g"を追加する。 - パーミッションエラー: Linux 環境で
Permission deniedが出るときは、-u $(id -u):$(id -g)を渡してホスト側UIDで実行するか、/data/cacheを別ボリュームに切り出す。 - 言語Linterのpullが遅い: 初回は数百MBのイメージを取得するため数分〜10分待つ。CI環境では Docker レイヤーキャッシュを有効化しておく。
これらは Qodana 固有というより Docker 運用全般のトピックですが、最初の3回くらいまでは必ず誰かが踏むので、チームに導入する前に手順書としてREADMEに残しておくとスムーズです。
毎回このエラーで詰まるので、READMEに残す価値ありますね。
はい、初回セットアップの一次対応はチームの誰か一人が調べれば十分です。
既存コードが大量にあるプロジェクトでの考え方
既存コードを一度に直そうとするのは無謀です。私は「キャンプ場ルール（来たときよりも美しく）」を推奨しています。
新しく機能を追加したり、バグを修正したりするためにそのファイルを触る際、ついでにQodanaが指摘している箇所も数個直す。
これをチーム全員で繰り返せば、半年後には見違えるほど綺麗なコードベースになります。一気にやろうとせず、日々のルーチンに組み込むことが成功の秘訣です。
Qodanaはどんな人・チームに向いているか
最後に、Qodanaがどのような場面で最も価値を発揮するのかをまとめます。
私は、今の時代にエンジニアリングをするなら、どんな規模であっても静的解析は必須だと考えています。
個人開発で使う場合の価値
個人開発では、自分が書いたコードをレビューしてくれる相手がいません。そのため、いつの間にか「動けばいい」という雑なコードが増えがちです。
数ヶ月後にそのコードを読み直して、「何だこれ……」と絶望した経験はありませんか？
Qodanaは、あなたにとっての「もう一人の自分」であり「厳格なメンター」になります。
一人で開発していても、Qodanaが横にいてくれるだけで、プロフェッショナルな品質を維持し続けることができます。
将来、そのプロジェクトを誰かに引き継いだり、オープンソースとして公開したりするときに、恥ずかしくないコードを残せるのは大きなメリットです。
チーム開発で真価を発揮する理由
チーム開発において、Qodanaは「共通言語」になります。コードの良し悪しを個人の好みではなく、客観的な指標で議論できるようになるからです。
特に、メンバーの技術レベルにバラつきがあるチームほど、Qodanaの効果は絶大です。
シニアエンジニアは細かい指摘から解放され、ジュニアエンジニアはツールからリアルタイムでフィードバックをもらって成長できます。
ツールを介して品質への意識が統一されることで、チーム全体の生産性と信頼関係が向上します。
私は、Qodanaを導入したことで、コードを書く喜びを再発見できました。
機械的なチェックを自動化し、自分の頭をより本質的な課題に使えるようになったからです。
もしあなたが、日々のレビューやコードの乱れに悩んでいるなら、ぜひ一度Qodanaを試してみてください。
最初は面倒に感じるかもしれませんが、1ヶ月後には「なぜもっと早く使わなかったのか」と思っているはずです。
Qodanaに関するよくある質問
Qodana導入前によく聞かれる疑問をまとめました。気になるところだけ拾い読みしてもらえれば大丈夫です。
Q1. Qodanaは無料で使えますか？
A1. はい、Communityプランは無料です。Java・Kotlin・PHP・Pythonなど主要言語の標準的なリンター機能が使え、個人開発やOSSであればこれだけで十分運用できます。タイムトラベル解析やライセンス監査などの高度な機能が必要になった段階でUltimate以上を検討すれば十分です。
Q2. SonarQubeとどちらを選ぶべきですか？
A2. チームがJetBrains製IDE（IntelliJ IDEA・WebStorm等）を使っているならQodanaが一択です。IDE上の警告とCI上の警告が完全に一致するため、指摘のズレによる混乱がありません。多言語の大規模プロジェクトで品質ゲートを厳格に運用したい場合はSonarQube、JS/TS単体プロジェクトならESLintで十分です。
Q3. 既存の大きなプロジェクトに導入すると警告が大量に出て困りませんか？
A3. 出ます。ただしBaseline機能を使えば、導入時点の指摘を「既知の問題」として記録し、次回以降は新規に増えた指摘だけを通知させられます。過去の負債は棚上げし、まず「これ以上コードを汚さない」運用から始めるのが現実的です。
Q4. Dockerを使わずにQodanaを実行できますか？
A4. できます。Qodana CLI（brew install jetbrains/utils/qodana など）を使えばコマンド1つでスキャンでき、内部的にはDockerコンテナが起動しますが、意識する必要はありません。IDE単体で試したい場合はQodana公式プラグインをIntelliJ IDEAやWebStormにインストールする方法もあります。
| REV. | DATE | 内容 |
|---|---|---|
| 4 | 2026-10-16 | 図解を描き直し（図面のデザインにそろえた） |
| 3 | 2026-08-29 | 2026年8月時点の情報で全体を見直し |
| 2 | 2026-04-26 | 2026年4月時点の情報で全体を見直し |
| 1 | 2026-02-04 | 初版 |