GitHub Code Qualityの所見の却下・再オープンが監査ログ対象に

何が発表されたか

• GitHub Code Qualityの所見（finding）に対する**手動の却下（dismiss）と再オープン（reopen）**が、OrganizationまたはEnterpriseの監査ログで確認できるようになった。対象はデフォルトブランチのバックログに出る所見およびプルリクエスト上の所見。
• 追加された監査ログイベントは2つ。
  • repo.code_quality_findings_dismissed：バックログの所見を1件以上却下したとき
  • repo.code_quality_findings_reopened：バックログの所見を1件以上再オープンしたとき
• 各イベントには実行者・発生日時・リポジトリ・ルール・対象所見の識別子と件数が記録される。
• 提供状況：GitHub Team と GitHub Enterprise Cloud（データレジデンシー対応のEnterpriseを含む）で一般提供。GitHub Enterprise Server では利用不可。Code Qualityを有効にしているリポジトリは追加設定不要。
• 監査ログでアクション名を絞り込んで閲覧できるほか、Enterprise Cloudでは監査ログAPIからも取得できる。

開発者への影響

AIによるコードレビューやスキャンの所見が増えるほど、「とりあえず却下して先に進む」という運用が発生しやすくなる。この変更は、その却下が誰の判断だったかを後から追えるようにするものだ。

受託開発でありがたいのは、説明責任の線が引けること。納品後に品質上の指摘が出たとき、「この所見はいつ・誰が・どのルールについて却下したか」を監査ログから提示できれば、責任範囲の議論が感情論にならずに済む。逆に、自分たちが安易に却下していれば、それもそのまま残る。

運用に落とすなら、(1) 却下時にコメントで理由を残すルールをチームに敷く、(2) 月次で repo.code_quality_findings_dismissed を集計し、特定ルールが繰り返し却下されていないか確認する（繰り返されるならルール自体の調整を検討）、(3) AIエージェントに却下操作をさせない、または専用アカウントで実行して人の判断と区別できるようにする——このあたりが効く。

Enterprise Serverでは使えない点だけ、オンプレ運用のクライアントに案内する際は注意したい。