発注した業務システムの検収で見るのは、たいてい「仕様どおり動くか」です。画面を開き、データを入れ、想定どおりの結果が返ることを確認して、検収書に印を押す。この方法は、動作については確実に判定できます。
判定できないのは、そのコードが2年後に触れる状態かどうかです。同じ画面、同じ動作を実現するコードでも、次の改修で1日で終わるものと、読み解くだけで1週間かかるものがあります。そして発注側は、その差を見る手段を持っていません。
この差が、いま急速に開きつつあります。AIによるコード生成で、書かれる量が増えたからです。動くコードが速く出てくること自体は良いのですが、レビューの速度は同じようには上がりません。結果として、読まれていないコードの比率が上がる。
GitHub Code Quality が測ろうとしているもの
2026年7月20日、GitHub Code Quality が正式提供（GA）になりました。対象は GitHub Enterprise Cloud と GitHub Team です。パブリックプレビュー段階で1万社を超える企業が使っていたと発表されています。
やっていることは、大きく2つの組み合わせです。
- CodeQL による決定論的な解析 — コードを構文と制御フローのレベルで解析します。同じコードなら常に同じ結果が出ます
- AIによる保守性・信頼性の問題検出 — 決定論的な解析では拾いにくい「読みにくさ」「壊れやすさ」の指摘を出します
そのうえで、Copilot Autofix がプルリクエスト上に修正案を提示します。GA で加わったのは、組織単位での有効化、保守性・信頼性スコアとテストカバレッジのダッシュボード、そして ruleset による品質ゲートです。この最後の「品質ゲート」が、発注する側にとって意味を持つ部分になります。基準を満たさないプルリクエストをマージできない状態にできるからです。
料金は、有効化したリポジトリのアクティブコミッター1人あたり月額10ドル。加えて、AIを使う機能（Copilot コードレビュー、AI補助の検出、Copilot Autofix）は従量課金、決定論的な CodeQL 解析は GitHub Actions の実行時間を消費します。固定費と変動費が混ざる構造なので、見積もり時に人数だけで計算すると足りません。
「スコア8以上」と契約書に書いたときに起きること
ここからが本題です。保守性のスコアが数値で出るなら、それを受け入れ条件にすればいい——と考えるのは自然です。実際、そう書かれた契約は増えています。
しかし、数値を条件にした瞬間、その数値を上げる作業が発生します。そして、保守性スコアを上げる方法は「保守しやすく書き直す」だけではありません。
- 指摘の多い箇所を、解析対象から除外する設定を足す
- 長い関数を、意味のある単位ではなく行数基準で機械的に分割する
- 指摘されない書き方に寄せる（が、読みやすくはならない）
どれも契約違反ではありません。条件を満たしているからです。そして発注側は、スコアが基準を超えていることしか見ていないので、この操作に気づけません。
これは受託側が不誠実だという話ではなく、測る指標を条件にすると、その指標が最適化対象になるという一般的な現象です。テストカバレッジで先に起きたことが、保守性スコアでも起きます。カバレッジ80%を条件にすると、アサーションのないテストが増える——という現象は、多くの現場が通ってきた道です。
数値ではなく、プロセスを条件にする
では、どう書けばいいのか。発注側が指定すべきなのは、結果の数値ではなく、検出の仕組みが回っていることです。
具体的には、次のような形になります。
- 解析が有効になっていること、および解析対象からの除外設定の一覧を提出すること。除外設定を出させるのが要点です。スコアが良くても、対象が絞られていれば意味がありません
- 検出された指摘を、修正・意図的に許容・対応不要のいずれかに分類し、許容したものは理由を残すこと。ゼロにすることを求めない。残っている指摘に説明が付いているほうが、指摘ゼロより信頼できます
- 品質ゲートを設定し、その基準を引き継ぎ時に開示すること。次の会社が引き継いだとき、同じ基準で継続できます
この形にすると、受託側が数値を作りに行く動機が消えます。説明できることが条件なので、書き換えても得をしないからです。
なお、AIの指摘をどこまで真に受けるかは別途決める必要があります。AI補助の検出は、決定論的な解析と違って同じコードでも指摘が揺れることがあります。これを「毎回すべて修正」の対象にすると、終わらない作業が発生します。人が判断する前提で扱うのが現実的です。レビューの運用そのものについてはコードレビューで機能する2種類のコメント、AI生成コードのレビュー体制についてはClaude Code のセキュリティプラグインとAI生成コードのレビューで扱っています。
導入のタイミングを間違えない
もうひとつ実務的な話として、このツールを既存の大きなコードベースに後から入れると、初回で膨大な指摘が出ます。数千件の指摘リストを前にすると、チームは高い確率で無視するようになります。一度「見ないもの」になった通知は、その後どれだけ重要な指摘が出ても読まれません。
現実的な入れ方は、新規に書かれる差分だけを対象にすることです。既存コードの指摘は記録だけして、品質ゲートは新しい変更にのみ適用する。既存部分は、改修が入るタイミングで順次拾っていきます。
既存コードをどこまで直すかの判断軸はAI時代のリファクタリング判断と技術的負債で扱っています。また、テストが「通っている」ことと「意味がある」ことの差はミューテーションテストで成果物のテスト品質を測るのほうが直接的です。カバレッジをダッシュボードで見られるようになると、この差が問題として浮上します。
次にやること
発注側の立場であれば、いま進行中の開発で「除外設定の一覧を見せてください」と聞いてみてください。解析を入れているかどうか、入れているとして何を対象外にしているかが、それだけで分かります。
これから発注する案件であれば、受け入れ条件を書く段階が分かれ目です。数値を書きたくなりますが、「解析が有効であること」「残った指摘に理由が付いていること」「基準を引き継ぎ時に開示すること」の3点のほうが、数値より効きます。書くのは1行増えるだけで、後から効いてきます。
開発の受け入れ条件の設計や、既存システムの引き継ぎやすさの評価を含めて相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。コードベースの規模や体制によって現実的な進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- GitHub Code Quality is now generally available — GitHub Changelog
- GitHub Code Quality generally available July 20, 2026 — GitHub Changelog
- GitHub Code Quality Targets Maintainability as AI-Generated Code Increases — InfoQ
- GitHub Code Quality Moves to General Availability, Bringing New Costs and Capabilities — DevOps.com
