名前だけでは、送信したアカウントは分かりません
説明用の架空例として、社内リポジトリ（ソースコードを保管・管理する場所）で決済処理を変更したコミット（変更内容などを記録する単位）を調べる場面を考えます。作成者の欄には、信頼する担当者の名前とメールがあります。それでも、その担当者のアカウントでGitHubへ送られたとは限りません。名前だけを見て調査を進めると、変更を送信したアカウントを取り違えるおそれがあります。
コミットは、Git（ソースコードの変更履歴を管理するシステム）で、変更内容や作者などを記録する単位です。GitHubへ変更を送る操作をプッシュと呼びます。コミットにはauthorとcommitterという名義があり、名前・メール・日時などが記録されます1。本稿でいうpusherは、プッシュした認証アカウントです。
| 項目 | 記録する役割 | その情報だけでは分からないこと |
|---|---|---|
| author | 変更の作者として記録された名義1 | 誰の認証でプッシュされたか |
| committer | コミットを作成した者として記録された名義1 | 誰の認証でプッシュされたか |
| pusher | プッシュした認証アカウント | 持ち主本人の操作や、コードの正しさ |
authorとcommitterの名前・メールは、Gitを操作するソフトウェア側で指定します。Gitの名前設定は認証に影響しません2。GitHubも、リポジトリへの書き込み権限を持つ側が、任意の名前とメールを設定できると説明しています。発表では、侵害されたアカウントから信頼された保守担当者の名義で変更を送ると、レビューや監査を混乱させるリスクを挙げています3。
署名と操作の記録で確かめられること
既存の仕組みでも、変更の由来や送信時の活動を調べられます。コミット署名（コミットに付ける電子署名）のVerified表示は、署名が検証されたことを示す情報です。署名者を示す情報と、コミットを送信したpusherは、確認する対象が異なります4。署名付きの変更を別のアカウントが送る共同作業も考えられるため、署名と送信の記録を分けて読みます。
GitHubの既存API（プログラムから情報を扱う窓口）にも、authorとcommitterの情報があります5。既存のpusher項目には、プッシュ操作の単位で送信主体を示すものがあります6。今回のコミット単位の記録とは、API上の項目を区別して確認します。
GitHub Enterprise Cloud（企業向けクラウド版）には監査ログがあります。監査ログは、誰がいつ何をしたかを記録します。git.pushはプッシュのイベントです。このイベントから、送信主体、リポジトリ、時刻などを確認できます。このイベントは監査ログのWeb画面ではなく、APIやエクスポートなどで参照します7。プッシュの操作について、送信主体を調べる既存の手段です。
標準監査ログのGitイベントの保持期間は7日です8。公式の監査文書は、期限前の外部保存や、継続的なログ転送も案内しています。外部の保存期間は、そのシステムの方針によります。既存ログの保全で必要な調査に対応できる運用もあります。
認証アカウントをコミットごとに記録する
GitHubは2026年10月12日、Push attribution（コミットごとに送信アカウントを記録する機能）を発表しました9。公式発表では、各コミットをプッシュした認証済みユーザを、author・committerの名義とは独立して永続記録すると説明しています。記録するpusherを、名義と並べて画面とAPIに表示します10。
発表の図は、プルリクエスト（変更の取り込みを提案し、レビューを受ける仕組み）のCommitsタブでコミット名義とpusherを別に表示する例です11。コミットを確認する際、名義に加えて、どの認証アカウントから送られたかを判断材料にできます。
今回追加されるのは、コミットと結び付いた認証アカウントの記録です。署名検証、操作を調べる監査ログ、変更内容を審査するレビューは、それぞれ役割があります。これらの記録と内容審査を、用途に応じて併せて使います。
一致ルールはcommitterのメールを比べる
ルールセットは、リポジトリに適用する条件のまとまりです。今回の新しい条件の名称は「Committer must match pusher」です。有効にすると、committerのメールとpusherの確認済みメールアドレスを照合します。どの確認済みアドレスにも一致しない場合、GitHubはプッシュを拒否します12。
発表で明示されているのは、このメール照合です。authorについての別の条件や、表示名どうしの比較は、今回の発表には記載がありません。この公表条件から、次の架空例を考えられます。
Aの変更をBが取り込み、authorがA、committerがBになったとします。Bがプッシュし、committerのメールがBの確認済みメールに一致すれば、比べるメールは一致します。authorの名義と、照合するメールの値を分けて考える例です。
一方、BのコミットをCが代理でプッシュし、committerのメールがCの確認済みメールのどれにも一致しなければ、公表された拒否条件に当てはまります。これらは条件を理解するための例で、プレビュー環境で実際に動作を確かめたものではありません。他のルールや、自動化に固有の扱いまで判定した例ではありません。
照合するメールが一致していても、作者名義の正しさやコードの安全性を検査したことにはなりません。名前・メールの情報と、変更の内容は別々に確かめます。
利用条件を確認し、内容の審査と併用する
発表時点の提供対象はGitHub Enterprise顧客向けの限定公開プレビューです。参加希望者は、担当のアカウントチームに連絡してアクセスを申請します13。
今回の発表本文には、追加料金、一般提供の時期、過去のコミット履歴への記録補完の説明がありません。APIでの表示は説明されていますが、具体的なフィールド名や呼び出し方も発表本文からは確認できません。利用できる範囲と費用は、参加窓口へ確認する事項です。
代理でプッシュした場合の記録や、自動化での認証主体の扱いは、今回の発表では詳しく説明されていません。bot（自動処理用アカウント）やGitHub App（GitHub連携用アプリ）を使う運用も、参加窓口で確認する対象です。新条件に免除設定が適用されるかも、参加窓口に確認します。
本稿の運用提案として、不審なコミットを調べる際は、次のように記録を照合します。
- 名義とpusherを比べ、想定した共同作業や送信経路と合っているかを調べます。
- 送信時点の権限、署名の検証記録、レビューで確認した変更内容を併せて確認します。
- 一致ルールを導入する前に、代理プッシュや自動化の名義・認証設定を洗い出し、参加窓口と検証する範囲を決めます。
既存のレビュー制御では、最新のレビュー対象のプッシュを、プッシュした者以外が承認する設定があります。変更内容（差分）が変わった場合に、以前の承認を無効にする設定もあります14。この内容審査とpusher記録を併用する方法を検討できます。
発表本文では、アカウントの持ち主本人が操作したか、認証情報（パスワードやトークンなど）が侵害されていたかを確認する方法は説明されていません。認証できたアカウントからの変更でも、内容に誤りや悪意がある可能性は残ります。pusherは送信主体を調べる材料として使い、コードの確認はレビューや検査で続けます。
後輩送信アカウントが分かれば、変更内容も信用してよいのでしょうか。
先輩記録が答えるのは送信の主体だよ。内容の確認は続け、名義、認証、署名、レビューが何を確かめたかを分けて読むんだ。
