いつもの GitHub の Security タブが見当たらず、戸惑った人も多いはずです。結論から言うと、2026年4月2日付の changelog で Security タブは Security & quality に改名されました。場所が消えたわけではなく、セキュリティアラートとコード品質を同じ入口で扱う方向に整理されたのが今回の本質です。既存の URL や API エンドポイントは変わらないため、自動化やブックマークを慌てて直す必要はありませんが、日々の確認場所や手順書は更新しておいたほうが混乱を防げます。 (The GitHub Blog)
この記事では、GitHub の Security & quality で何が変わるのか、なぜ名前が変わったのか、GitHub Advanced Security を使う管理者やレビュアーがどこを見直すべきかを、実務に寄せて整理します。特に重要なのは、入口は統合されても、ライセンスや権限まで一本化されたわけではないという点です。 (The GitHub Blog)
GitHub の Security タブは何が変わったのか
今回の変更を先に整理すると、見た目以上に意味があります。リポジトリ・組織・Enterprise のトップレベルで Security が Security & quality になり、リポジトリの左サイドバーでも名称が整理されました。一方で、既存 URL、API エンドポイント、基礎データは維持されています。 (The GitHub Blog)
| 項目 | 以前 | 現在 | 実務上の見方 |
|---|---|---|---|
| 上位タブ | Security | Security & quality | セキュリティと品質の入口が一本化された |
| リポジトリ左サイドバー | Vulnerability alerts | Findings | 「脆弱性だけ」ではなく検出事項全体を見る導線に寄った |
| リポジトリ左サイドバー | Policy | Security policy | 脆弱性報告ポリシーを探しやすくなった |
| リポジトリ左サイドバー | 目立たない別導線 | Code quality | 品質の有効化状況や結果へ移動しやすくなった |
| URL / API | 変更がありそうに見える | 変更なし | スクリプトや連携は原則そのまま使える |
この表の変更点と「変わらない点」は、GitHub 公式 changelog の記載を要約したものです。チーム内の手順書で Vulnerability alerts や Policy という旧表現を残したままだと、UI 上で迷う人が出やすくなります。 (The GitHub Blog)
なお、この更新は github.com で提供されており、GitHub Enterprise Server には含まれていません。オンプレミスやハイブリッド運用のチームは、同じ GitHub でも画面名が環境ごとに違う前提でマニュアルを分けておくと安全です。 (The GitHub Blog)
GitHub が Security & quality に変えた狙い
GitHub が changelog で明言している狙いは、コード品質の findings をセキュリティアラートの近くに置き、コード関連の問題を一か所でトリアージしやすくすることです。さらにこのナビゲーション変更は、今後の GitHub Code Quality の一般提供に向けた土台でもあると説明されています。 (The GitHub Blog)
GitHub Code Quality は、プルリクエストとリポジトリスキャンで品質問題を見つけ、Reliability と Maintainability の指標で状態を見せ、組織ダッシュボードや ruleset による品質基準の強制にもつながる機能です。ここまで読むと、Security & quality は単なる改名ではなく、安全性と品質を同じレビュー文脈で扱う入口になった、と捉えると分かりやすいです。 (GitHub Docs)
2026年4月時点の公式 docs では、GitHub Code Quality は public preview で、課金は発生しない一方、Code Quality のスキャンは GitHub Actions minutes を消費します。導入を考える管理者は、名前の統合だけで安心せず、runner 設計と実行コストまで含めて判断したほうが現実的です。 (GitHub Docs)
リポジトリ・組織・Enterprise でどこを見ればいいか
UI が変わったときに一番困るのは、「結局どこを見ればいいのか」が分からなくなることです。主要な導線だけ先に整理すると、次のように考えると迷いにくくなります。 (GitHub Docs)
| レベル | まず開く場所 | 主に見るもの | 補足 |
|---|---|---|---|
| リポジトリ | Security & quality | Dependabot / Secret scanning / Code scanning の alerts、Code quality の findings | Code Quality は Settings > Security > Code quality から有効化 |
| 組織 | Security & quality | Overview を中心とした security overview、Metrics > Code quality の品質分布 | ダッシュボードは閲覧者が見えるリポジトリだけ反映 |
| Enterprise | Security & quality | 組織横断の security overview | Code Quality の利用可否は Policies > Code Quality で制御 |
この表は GitHub Docs の操作手順を、実務で使いやすい形に要約したものです。組織では Metrics > Code quality から、Maintainability と Reliability の分布をバブルチャートとリポジトリ一覧で追えます。セキュリティ側は Overview が主画面で、Detection / Remediation / Prevention を切り替えながら日付やツールで絞り込めます。 (GitHub Docs)
「タブはあるのに見たいデータが見えない」ときは、UI 変更より権限を疑うのが先です。リポジトリの security alerts は write / maintain / admin 権限を持つ人と Organization owner が見られ、追加の閲覧権限も write 権限のある人・チームに対して付与します。組織の security overview では Organization owner や security manager が全体を見やすく、一般メンバーは自分が alerts にアクセスできるリポジトリ分だけが見えます。Code Quality の組織ダッシュボードも、閲覧者が findings を見られるリポジトリだけが表示対象です。Enterprise の overview は enterprise owner や security manager 向けです。 (GitHub Docs)
管理者が押さえるべき影響
管理者にとって一番大きい変化は、Security & quality を単なるアラート置き場ではなく、運用ポリシーと品質ゲートの入口として扱う必要が出てきたことです。特に Enterprise 管理では、Code Quality の可否を Policies > Code Quality で制御でき、以前 Advanced Security policies が握っていた設定は standalone の Code Quality policies に自動適用されます。名称変更後に「なぜこの Organization では Code Quality を使えるのか、使えないのか」を説明できる状態にしておくと、問い合わせ対応がかなり楽になります。 (GitHub Docs)
各リポジトリで Enable code quality が見当たらない場合、Enterprise owner 側で利用が無効化されている可能性があります。また、Repository admin に有効化を任せるかどうかは、Enterprise 側の Repository admin policy でも制御できます。権限設計を曖昧にしたまま運用すると、「タブ名は変わったのに機能が増えない」という誤解が起きやすくなります。 (GitHub Docs)
ここで誤解しやすいのが、同じタブに並んでも契約条件まで同じではないことです。Code Quality は Organization 所有のリポジトリで GitHub Team / Enterprise Cloud から利用でき、Code Security ライセンスは不要です。一方、code scanning や secret scanning などの一部機能は、公開リポジトリでは既定で使えるものがある一方、private / internal リポジトリでは対応する GitHub Advanced Security 製品が必要になります。Security & quality は入口の統合であって、ライセンス境界の統合ではありません。 (GitHub Docs)
もうひとつ実務で効くのが、Code Quality は GitHub Actions が前提で、CodeQL が対応する言語を中心に分析するという点です。タブだけ見て「これで全リポジトリの品質が横並びで見える」と期待すると、対象言語や Actions 設定の違いで差が出ます。結果の出方に差があるときは、まずライセンスより先に Actions の有効化と対応言語 を確認すると切り分けやすいです。 (GitHub Docs)
レビュアーと開発者の見直しポイント
レビュー現場では、「Security タブはあとで見るもの」という感覚を改めたほうがうまく回ります。Code Quality を有効にすると、プルリクエストには github-code-quality[bot] のコメントが付き、可能な場合は Copilot Autofix の提案も表示されます。Security & quality は、マージ後に backlog を眺める場所ではなく、PR の時点で品質を止める仕組みの起点にもなっています。 (GitHub Docs)
リポジトリ側では Code quality の Standard findings で default branch の品質 backlog を確認でき、Maintainability と Reliability の指標を見ながら優先順位を決められます。GitHub Docs は、高 severity の findings から見ること、そして指標を上げるにはその指標に効いている最上位 severity の findings を解消することを勧めています。レビュー前に「どの rule が大量発生しているか」を見ておくと、この PR で直すべきか、別 issue でまとめて返すべきかの判断がしやすくなります。 (GitHub Docs)
ruleset で Require code quality results を入れると、基準に満たない PR はマージできません。便利ですが、GitHub 公式 docs でも、先に CodeQL - Code Quality チェックが PR に正常報告されていることを確認しないと、すべての PR をブロックする恐れがあると案内しています。名称変更をきっかけに品質ゲートを入れるなら、まずは試験用リポジトリで挙動を確認してから本番展開するのが安全です。 (GitHub Docs)
レビュアーなら、最低限この順で見ると迷いにくくなります。
- PR の
ChecksでCodeQL - Code Qualityが正常終了しているか確認する。失敗や未報告のまま ruleset を厳しくすると、レビュー以前にマージ導線が詰まります。 (GitHub Docs) github-code-quality[bot]のコメントが付いている場合は、通常の review comment と同じ感覚で差分に引き戻して確認する。修正案が出ていても、diff の妥当性確認は必須です。 (GitHub Docs)- リポジトリの
Standard findingsを見て、同種の問題が backlog にどれだけ残っているかを把握する。単発修正で終えるか、ルール単位でまとめて改善するかの判断材料になります。 (GitHub Docs)
まずやるべき運用チェックリスト
実務では、次の順で見直すと混乱を減らせます。 (The GitHub Blog)
- 社内手順書、オンボーディング資料、レビュー依頼テンプレートの表記を
SecurityからSecurity & qualityに更新する。URL や API は変わらないので自動化は急ぎで直さなくてよい一方、画面名の放置は問い合わせの原因になります。 (The GitHub Blog) - リポジトリ・組織・Enterprise のどこで何を見るかを 1 枚の運用表にする。特に「リポジトリでは alerts と Code quality」「組織では overview と Metrics」「Enterprise では policies」という役割分担を明文化すると迷いにくくなります。 (GitHub Docs)
- 「見えない」の問い合わせに備えて、権限表を更新する。security alerts と security overview、Code Quality dashboard では見える条件が異なります。 (GitHub Docs)
- Code Quality を使うなら、GitHub Actions の前提、対応言語、Actions minutes の消費、Enterprise の許可ポリシーをまとめて確認する。タブ名だけ変えても、実運用は整いません。 (GitHub Docs)
Require code quality resultsを本番ルールに入れる前に、試験用リポジトリでCodeQL - Code Qualityのチェック報告とブロック動作を確認する。ここを飛ばすと全 PR 停止につながります。 (GitHub Docs)- GitHub Enterprise Server を併用しているなら、クラウド向け資料と GHES 向け資料を分ける。同じ「GitHub」でも今回の改名は共通ではありません。 (The GitHub Blog)
まとめ
今回の変更で覚えておくべきポイントは、実質この3つです。 (The GitHub Blog)
Securityタブは消えたのではなく、Security & qualityに名前が変わった。 (The GitHub Blog)- GitHub はセキュリティアラートとコード品質を、同じトリアージ導線で扱う方向を明確にした。 (The GitHub Blog)
- URL や API は変わらないが、権限設計、運用ポリシー、PR レビュー手順、ruleset は見直したほうがいい。 (The GitHub Blog)
最初の一歩としては、代表的な 1 つのリポジトリ、1 つの組織、必要なら Enterprise 管理画面を開き、Security & quality の中で「誰が何を見るのか」を言語化してみてください。今回の改名は、見た目の話ではなく、品質と安全性を別チームの別作業にしないための再配置として捉えると、運用改善の方向が見えやすくなります。 (The GitHub Blog)
コメント