GitHubは2026年10月13日付で、コードの品質に関する指摘を扱うCode Qualityの監査ログ拡充を発表しました。指摘を手動で却下したり、再開したりした記録を、組織や企業の監査ログで確認できます。情シスや開発管理者は、指摘の件数だけでなく、その扱いを変更した依頼者や対象も追えるようになります。
却下・再開の依頼者と対象を記録
Code Qualityの指摘は、リポジトリ、つまりコードの保管場所のデフォルトブランチのバックログや、プルリクエストに現れます。バックログは未対応の指摘の一覧、プルリクエストはコード変更を提案する仕組みです。
今回追加された監査イベントは、1件以上のバックログの指摘を手動で却下、または再開した操作を記録します。却下にはrepo.code_quality_findings_dismissed、再開にはrepo.code_quality_findings_reopenedというアクション名を使います。
各イベントには、依頼者、日時、リポジトリ、ルール、対象指摘の識別子と件数が記録されます。監査ログは、このアクション名で絞り込めます。ある指摘の扱いが変わった際に、対象と操作の記録を照合する材料になります。
ただし、操作の記録と、その判断が妥当だったかの確認は別です。開発側が持つ判断の説明と、ログにある対象指摘を突き合わせる運用にすると、レビューで何を確認すべきかが明確になります。
対象プランでは一般提供、追加設定は不要
改善機能はGitHub TeamとGitHub Enterprise Cloudで一般提供されています。データレジデンシー、つまりデータの保存場所に関する仕組みを利用する企業も対象です。GitHub Enterprise Serverには提供されません。
Code Qualityを有効化済みのリポジトリでは、今回の機能のために追加設定をする必要はありません。一方、記録を見るには、組織または企業の監査ログへのアクセス権が必要です。機能が対象でも、確認を担当する人に閲覧権限があるかは別に点検する必要があります。
GitHub Enterprise Cloudでは、システムから情報を取得する監査ログAPIでも新イベントを取得できます。画面で確認する運用だけでなく、既存のログ取得処理に組み込む際の確認対象にもなります。
日本での提供は発表には書かれていません。
影響する会社・しない会社
- 影響する: GitHub TeamまたはGitHub Enterprise Cloudで、Code Qualityを有効化したリポジトリを運用する会社です。指摘の手動却下・再開を監査ログで確認する対象になります。
- 影響する: GitHub Enterprise Cloudで監査ログAPIを利用する会社です。新しいアクション名を、取得後の抽出や確認の対象にするか検討できます。データレジデンシーを利用する企業も提供対象に含まれます。
- 影響しない: GitHub Enterprise Serverを利用する会社です。今回の改善機能は提供されません。
- 影響しない: Code Qualityを利用していない会社は、今回追加された指摘の監査記録を確認する直接の対象ではありません。導入する場合の条件は、別途確認が必要です。
情シスが今日やること
- 開発管理者に対象を確認します。 今日の確認で、利用しているプランと、Code Qualityを有効化しているリポジトリを整理します。Team、Enterprise Cloud、Enterprise Serverを分け、今回の確認対象を決めます。
- 監査ログの閲覧権限を確認します。 組織または企業の監査ログを開ける担当者を確認します。情シスが閲覧できない場合は、アクセス権を持つ管理者に、以降の確認を依頼します。発表には管理画面の詳しい操作経路は書かれていません。
- 監査ログを2つのアクション名で絞り込みます。 却下と再開の記録があれば、依頼者、日時、リポジトリ、ルール、対象指摘の識別子と件数を確認します。次回の品質レビューまでに、開発管理者と照合する項目を決めます。
- API利用とレビュー手順を担当者に共有します。 Enterprise Cloudで監査ログAPIを使っている場合は、ログ取得の担当者に新イベントを伝えます。開発管理者には、指摘の判断を確認する際に監査ログも参照する手順を提案します。追加設定の有無ではなく、誰が記録を確認するかを決めることが今回の実務上のポイントです。
