こんにちは、dz_こと大平かづみです。
この記事は、オルターブース アドベントカレンダー 23日目の記事です。
GitHub Universe 2025で発表された「Code Quality」。実際のところ、どんな解析をしてくれるのか、聞いただけではわからなかったので確認してみました。
Code Qualityは、コードベースを、信頼性を高く、維持しやすく支援してくれるもの（次の引用より）で、「Standard findings」と「AI findings」という二つの観点で解析が実施されます。このうち、Standard findingsはCodeQLによって解析されています。
GitHub Code Quality helps you ensure your codebase is reliable, maintainable, and efficient.
お？CodeQLは、GitHub製の静的解析エンジンで、GitHubのセキュリティ機能であるCode scanningで利用されているものです。
Code QualityのStandard findingsは、Code scanningの代替になるのか？別物なのか？気になりますね。この記事では、実際にCode QualityとCode scanningを実行し、コードリーディングもして挙動を追ってみます。
なお、本記事で扱うCode scanningは、Default setupで実行した結果を参考にしています。また、確認の範囲を狭めるために、JavaScriptにフォーカスして確認しました。
Code QualityのStandard findingsとCode scanningの結果を比較してみる
まず、Code QualityのStandard findingsとCode scanningの結果の画面を見比べてみます。どちらも同じリポジトリに適用した結果ですが、検出件数も検出内容も異なることがわかります。
この時点でわかるのは、どちらもCodeQLで解析しているのに、同じ結果にならないということです。つまり、検出に使われるクエリが異なるはずです。次に、どういう仕組みでクエリが選定されているのか、ワークフローの実行ログとコードを追ってみます。
Code QualityとCode scanning（Default setup）のワークフローを比較してみる
まずは、それぞれを実行してみて、ワークフローの差分を確認してみます。
どちらもCodeQLで解析を行うので、はじめにgithub/codeql-action/initアクションを実行して環境を構成しています。ここに違いがありました。（それぞれ、ワークフローのJavaScriptに対する実行ログから抜粋）
Code Quality
Run github/codeql-action/init@v4
with:
analysis-kinds: code-quality
languages: javascript-typescript
build-mode: none
dependency-caching: true
config: default-setup:
org:
model-packs: [ ]
Code scanning（Default setup）
Run github/codeql-action/init@v4
with:
analysis-kinds: code-scanning
languages: javascript-typescript
build-mode: none
dependency-caching: true
queries: security-extended
config: default-setup:
org:
model-packs: [ ]
違いは、以下の2点です。
analysis-kindsの値が異なる- Code Quality:
code-quality - Code scanningのDefault setup:
code-scanning
- Code Quality:
queriesの指定が異なる- Code Quality: 指定なし
- Code scanningのDefault setup:
security-extended
github/codeql-action/initアクションとCodeQLのコードを追ってみる
それでは、github/codeql-action/initアクションのパラメーターanalysis-kindsに注目してみましょう。
まず、github/codeql-actionアクション一式のリポジトリgithub/codeql-actionで、github/codeql-action/initアクションの定義ファイル（init/action.yml）を確認します。すると、analysis-kindsは内部的なパラメーターで、code-scanning（デフォルト）やcode-qualityの値を指定できるようです。
続いて、analysis-kindsにcode-qualityを指定した場合の処理をコードで追い、次のような挙動が確認できました。
- 最終的に、
<language>-code-quality.qlsという名前のクエリ スイートを利用する - パラメーター
queriesで追加のクエリが指定されてても無視する（※ もともと指定されていないが、指定しても無視されることがわかった）
<language>-code-quality.qlsに注目してみます。.qlsというファイルは、CodeQLのクエリ スイートを定義します。<language>-code-quality.qlsは、CodeQLのリポジトリgithub/codeqlの<language>/ql/src/codeql-suitesディレクトリの下にあります。JavaScriptの場合、javascript/ql/src/codeql-suites/javascript-code-quality.qlsが該当します。
javascript-code-quality.qls
- queries: . - apply: code-quality-selectors.yml from: codeql/suite-helpers
他の言語の<language>-code-quality.qlsも同様の記述です。さらに、applyに指定されているcode-quality-selectors.ymlも確認します。実態は、misc/suite-helpers/code-quality-selectors.ymlが該当します。見てみましょう。
code-quality-selectors.yml
- description: Selectors for selecting the Code-Quality-relevant queries for a language
- include:
kind:
- problem
- path-problem
precision:
- high
- very-high
tags contain:
- quality
ここでやっと正体が見えてきました。code-quality-selectors.ymlでは、次の条件に該当するクエリを選択するように記述されています。
- クエリの
tagsに、qualityが含まれている - クエリの
kindが、problemまたはpath-problemである - クエリの
precisionが、highまたはvery-highである
CodeQLのデフォルトのクエリは、github/codeqlリポジトリの<language>/ql/src/配下に格納されています。JavaScriptの場合、javascript/ql/src/です。この配下のクエリで、該当するメタデータを持つファイルを抽出してみると、98件ありました（GitHub Copilotに依頼するとスクリプトを作って抽出してくれました）。
実は、（ここまでコードを追ってきましたが、）GitHub DocsにCode Qualityで該当するクエリ一覧が掲載されています。数件、実際のクエリと見比べたところ、一致していることを確認できました（ときどき、ドキュメントの記載が現状とずれていることがあるため念のため確認）。
もう少しコードを深追いしてみる
もう少し深追いしてみると、このコミット 0c31838で、タグにqualityが適用されたようです。目視での確認ではありますが、もともとmaintainabilityやreliabilityなどのタグがつけられたクエリからピックアップされているようです（全件ではない）。
なお、Code scanning（Default setup）では、security-extended-selectors.ymlで定義された条件のクエリが選択されるようで、次のような条件が記載されています。これは、code-quality-selectors.ymlで選択されるクエリとは重ならないようです（タグにqualityとsecurityが両方含まれれば該当するが、目視で確認したところ見つかりませんでした）。
- タグに
securityが含まれている - クエリの
kindが、diagnosticかmetricsである - （他の条件もあるが割愛）
まとめ
実際の実行結果とコードの追跡から、Code QualityのStandard findingsは、Code scanningの代替ではなく、異なる目的のための解析であることがわかりました。Code Qualityは継続的な品質維持、Code scanningは主にセキュリティ対策というそれぞれの目的のため、どちらも有用ということです。
- Code QualityのStandard findingsで検出されるものは、Code scanning（Default setup）で検出されるものとは異なる
- Code Qualityでは、
maintainabilityやreliabilityに関連するクエリが選択されている
Code Qualityは、解析実行時に使用されるGitHub Actionsの実行時間分のみ料金が発生します（※）が、まだパブリック プレビューでその間は料金はかかりません。ぜひ今のうちに試してみてくださいね。
（※GitHub Actionsはリポジトリの可視性やプランによって無料枠あり。また、GitHub ActionsのGitHub-hosted runnersは、値下げが発表されている。）
また、Code scanningは、パブリック リポジトリに対しては無料で利用できます。プライベート（またはインターナル） リポジトリの場合は、GitHub Advanced Securityの一つ「GitHub Code Security」のライセンスが必要です。GitHub Advanced Securityは料金体系が分割され、導入しやすくなりました。こちらもぜひご検討ください。
Epilogue
余談、今回の調査では、最初は手軽にGitHub.comのCopilot Chatを使ってコードリーディングをしていましたが、会話とコードを行ったり来たりするのが大変だったので、GitHub Codespacesを立ち上げVS CodeのCopilot Chatに切り替えました。Codespacesはリポジトリを起点に起動できるため、2つのリポジトリに対するGitHub Copilotとの会話も混線しません。また、Codespacesなら、コードをローカルと切り離した環境で実行できて安全ですし、どの端末からでも同じ環境にアクセスできるし、非常に有用です。子育ての合間に作業する際にもすぐに開発環境を立ち上げることができ、助かりました！また、GitHub CopilotのAgentモードに条件に該当するクエリファイルの抽出を頼むと、スクリプトを書いて実行してくれ、短時間で結果がわかったのも地味にありがたかったです。GitHub Copilot×GitHub Codespacesの組み合わせもぜひお試しください！
サービス一覧 www.alterbooth.com www.alterbooth.com cloudpointer.tech
