GitHubの「Disable commit comments on the user level」は、個人アカウントが所有するリポジトリで、コミットコメントを既定で有効にするか無効にするかをユーザー単位で選べるようになった変更です。複数の個人リポジトリを持つ開発者は、リポジトリごとに設定を変えなくても、コミットコメントの扱いをまとめて管理できます。対象は「個人アカウント所有のリポジトリ」であり、すでにリポジトリ単位で明示的な設定がある場合は、その設定が優先されます。(The GitHub Blog)
特に確認すべきなのは、コメント投稿フォームの表示、インラインのコメント導線、REST API・GraphQL API経由のコメント作成、既存コメントの扱いです。コードレビューや運用連絡をコミットコメントに依存しているチームは、設定変更前に使い方を棚卸ししておく必要があります。
GitHubの「Disable commit comments on the user level」とは
「Disable commit comments on the user level」は、GitHubで個人アカウントが所有するリポジトリに対して、コミットコメントの既定状態をユーザー単位で設定できるようにする機能です。
GitHubの公式Changelogでは、2026年5月8日の改善として公開されています。新たにユーザー単位のリポジトリ設定に「Commit comments」セクションが追加され、以下の2つから選べるようになりました。(The GitHub Blog)
| 設定 | 意味 | 向いているケース |
|---|---|---|
| Enabled by default | 対象リポジトリでコミットコメントを既定で有効にする | OSSや個人開発で、コミット単位のフィードバックを受け付けたい場合 |
| Disabled by default | 対象リポジトリでコミットコメントを既定で無効にする | 古いコミットへの不要なコメント、ノイズ、API経由の投稿を減らしたい場合 |
ここで重要なのは、すべてのリポジトリを強制的に上書きする設定ではないことです。ユーザー単位の既定値は、個人アカウントが所有し、かつリポジトリ単位の明示的な設定がないリポジトリに適用されます。すでに個別リポジトリで設定している場合、そのリポジトリの設定は維持されます。(The GitHub Blog)
何が変わるのか
今回の変更で変わるのは、コミットコメントを「個別リポジトリごと」ではなく「ユーザー単位の既定値」として管理できる点です。
これまでは、個人アカウント配下に複数のリポジトリがある場合、コミットコメントの設定をリポジトリごとに確認・変更する必要がありました。2026年3月には、リポジトリ管理者が個別リポジトリで「Allow comments on individual commits」を無効化できる機能が追加されています。(The GitHub Blog)
今回のユーザー単位設定により、個人アカウントのリポジトリ全体に対して「基本方針」を持たせられるようになりました。たとえば、個人で多数の検証用リポジトリや過去プロジェクトを管理している場合、コミットコメントを既定で無効にしておき、必要なリポジトリだけ個別に有効化する運用がしやすくなります。
変更前後の違い
| 観点 | 変更前 | 変更後 |
|---|---|---|
| 設定単位 | 主にリポジトリ単位 | ユーザー単位の既定値を設定可能 |
| 対象 | 個別リポジトリ | 個人アカウント所有のリポジトリ |
| 既存の個別設定 | リポジトリ側で管理 | 明示的な個別設定は維持される |
| API経由のコメント作成 | リポジトリ設定に従う | 無効設定を継承したリポジトリでは作成がブロックされる |
| 既存コメント | 表示・編集・削除が可能 | 無効化後も表示・編集・削除は可能 |
コミットコメントを無効にすると、新しいコメント作成の入口は閉じられますが、過去に作成されたコメントが消えるわけではありません。この点は、監査や履歴確認の観点で重要です。(The GitHub Blog)
対象になるリポジトリと対象外になりやすいケース
この機能の対象は、個人アカウントが所有するリポジトリです。組織アカウントのリポジトリについては、別途、Organization単位でコミットコメントを無効化する設定が2026年4月23日に公開されています。(The GitHub Blog)
| リポジトリの種類 | 今回のユーザー単位設定の対象 | 補足 |
|---|---|---|
| 個人アカウント所有のリポジトリ | 対象 | 明示的なリポジトリ設定がない場合、ユーザー単位の既定値を継承 |
| 個人アカウント所有で個別設定済みのリポジトリ | 既定値の上書き対象外 | 個別リポジトリの設定が維持される |
| Organization所有のリポジトリ | 今回の主対象ではない | Organization単位の設定を確認 |
| フォーク、アーカイブ、古い検証用リポジトリ | 所有者と設定状態による | コメント受付の必要性を個別に確認 |
実務では、「自分のアカウントにあるすべてのリポジトリが即座に同じ状態になる」と考えると誤解が起きます。まずは、どのリポジトリが個人所有で、どのリポジトリに明示的な設定があるのかを確認するのが安全です。
無効化すると何が起きるのか
リポジトリが「Disabled by default」を継承した場合、コミットページ上のコメント投稿フォーム、インラインdiff上のコメント導線、インラインスレッドへの返信導線が非表示になります。また、REST APIとGraphQL APIを使ったコミットコメントの作成もブロックされます。一方で、既存のコミットコメントは引き続き表示・編集・削除できます。(The GitHub Blog)
| 影響箇所 | 無効化後の状態 | 確認すべきこと |
|---|---|---|
| コミットページのコメントフォーム | 非表示 | コミット単位で質問を受ける運用がないか |
| インラインdiff上のコメント導線 | 非表示 | ファイル差分上で補足コメントを使っていないか |
| インラインスレッド返信 | 非表示 | 過去の運用で返信が必要なケースがないか |
| REST API・GraphQL APIによる作成 | ブロック | Bot、GitHub Apps、社内ツールがコメント作成していないか |
| 既存のコミットコメント | 表示・編集・削除可能 | 過去の議論や監査ログとして参照できるか |
ここで混同しやすいのが、コミットコメントとプルリクエストのレビューコメントです。GitHub Docsでは、コミットコメントは特定のコミットに付くコメントとして説明されています。一方、プルリクエストのレビューコメントは、プルリクエストレビュー中のdiffの一部に付くコメントであり、コミットコメントやIssueコメントとは別のものです。(GitHub Docs)
つまり、コミットコメントを無効にしても、通常のプルリクエストレビュー全体を止める設定とは限りません。ただし、チーム内で「コミットページに直接コメントする」運用をしている場合は影響します。
管理者・開発者が確認すべき設定ポイント
個人アカウント配下のリポジトリを棚卸しする
まず、自分の個人アカウントにあるリポジトリを次の観点で分類します。
| 分類 | 判断基準 | 推奨設定の考え方 |
|---|---|---|
| 公開OSS・ライブラリ | 外部ユーザーからのフィードバックを受けたい | 有効のままにするか、IssueやPull Requestへ誘導する導線を整える |
| 検証用・学習用リポジトリ | コメントを受け付ける必要が少ない | 無効化を検討 |
| 古いプロジェクト | メンテナンス終了、更新予定が少ない | ノイズ防止のため無効化を検討 |
| ドキュメント・サンプルコード | コミット単位の補足指摘が役立つ場合がある | 用途に応じて個別に判断 |
| Bot連携があるリポジトリ | APIでコメントを作成している可能性がある | 事前にツール側の挙動を確認 |
単純に「全部無効」にすると、外部コントリビューターからの指摘や、特定コミットに対する技術的な補足が受け取りにくくなることがあります。逆に、すべて有効のままだと、古いコミットへの不要なコメントや自動投稿の管理負荷が残ります。
リポジトリ単位の明示的な設定を確認する
今回のユーザー単位設定は、明示的なリポジトリ単位設定がないリポジトリに適用されます。すでに個別リポジトリで「Allow comments on individual commits」を変更している場合、その設定は後からユーザー単位の既定値を変えても維持されます。(The GitHub Blog)
確認時は、次のように考えると整理しやすくなります。
| 状態 | ユーザー単位の既定値を変えた時の挙動 |
|---|---|
| リポジトリ単位で明示的に有効 | 有効のまま |
| リポジトリ単位で明示的に無効 | 無効のまま |
| リポジトリ単位の明示設定なし | ユーザー単位の既定値を継承 |
特に注意したいのは、「ユーザー単位で無効にしたのに、一部リポジトリではコメントできる」ケースです。これは不具合ではなく、そのリポジトリに明示的な設定が残っている可能性があります。
APIやBotがコミットコメントを作成していないか確認する
GitHubのREST APIには、コミットコメントの作成・編集・表示に関するエンドポイントがあります。コミットコメントは特定のコミットに付くコメントで、REST API経由でも扱えます。(GitHub Docs)
無効化されたリポジトリでは、REST APIとGraphQL APIによるコミットコメント作成がブロックされます。(The GitHub Blog) そのため、次のような仕組みがある場合は事前確認が必要です。
- CIの結果をコミットコメントとして投稿している
- 独自Botがコミット単位で警告やメモを残している
- 社内ツールがAPI経由でコミットにレビュー補足を投稿している
- GitHub Appsが古いコミットに追記コメントを作成している
コミットコメントが作成できなくなると、単にコメントが表示されないだけでなく、ツール側でエラー処理が必要になる場合があります。運用中のBotやスクリプトがある場合は、投稿先をIssue、Pull Requestコメント、Checks、Status、Actionsのログなどに変更できないか検討しましょう。
設定変更前に確認したいチェックリスト
ユーザー単位で「Disabled by default」を選ぶ前に、次の項目を確認しておくと失敗を防ぎやすくなります。
| 確認項目 | 確認する理由 | 対応例 |
|---|---|---|
| コミットコメントを使っているリポジトリがあるか | 必要な議論の入口を閉じないため | 必要なリポジトリだけ個別に有効化 |
| BotやAPI連携があるか | コメント作成がブロックされる可能性があるため | 投稿先やエラー処理を見直す |
| 古いコメントを参照する必要があるか | 無効化後も既存コメントは残るが、運用確認が必要 | 参照ルールをチームに共有 |
| 外部コントリビューターがいるか | コメント導線が変わると問い合わせ先が分かりにくくなるため | READMEやCONTRIBUTINGに連絡先を明記 |
| Organization所有リポジトリと混在していないか | 設定の適用単位が異なるため | 個人所有とOrganization所有を分けて確認 |
このチェックで重要なのは、設定そのものよりも「コメントをどこで受けるか」を決めることです。コミットコメントを無効にするなら、Issue、Pull Request、Discussionなど、代わりのフィードバック窓口を明確にしておくと混乱を減らせます。
実務でおすすめの運用パターン
個人開発者は「既定で無効、必要なリポジトリだけ有効」が扱いやすい
個人アカウントに多数のリポジトリがある場合、すべてのコミットにコメント受付口を残す必要はあまりありません。検証用、学習用、古いサンプル、メンテナンス終了済みのリポジトリでは、コミットコメントを既定で無効にする方が管理しやすいでしょう。
一方、外部からの指摘を受けたいOSSや、教育用にコミット単位の質問を受け付けたいリポジトリでは、個別に「Allow comments on individual commits」を有効にしておくのが現実的です。
チーム利用では「PRレビューに集約」する方が混乱しにくい
チーム開発では、コミットコメントよりもPull Requestレビューに議論を集約した方が、レビュー履歴や承認フローを追いやすくなります。
コミットコメントは、特定のコミットに対してピンポイントで意見を残せる一方、後からSquash mergeやRebaseを行う運用では、議論の文脈が追いにくくなることがあります。プルリクエスト中心の開発フローなら、コミットコメントを無効にし、レビューコメントやIssueに寄せる方が運用は安定します。
OSSでは無効化前に問い合わせ導線を整える
公開リポジトリでは、コミットコメントを無効にすること自体は問題ありません。ただし、利用者が「どこに質問すればよいか」を見失うと、IssueやPull Request以外の場所で問い合わせが分散しやすくなります。
無効化する場合は、READMEやCONTRIBUTINGに次のような案内を置くと実用的です。
不具合報告や質問は、コミットコメントではなくIssueからお願いします。
コード変更に関する提案はPull Requestを作成してください。このように入口を明示しておくと、コミットコメントを閉じても開発者体験を大きく損ないにくくなります。
設定変更の進め方
実際に展開する場合は、一気に変更するよりも、次の順序で進めると安全です。
| 手順 | 作業内容 | ポイント |
|---|---|---|
| 1 | 個人アカウント所有リポジトリを確認 | Organization所有リポジトリと分けて見る |
| 2 | コミットコメントを使っているリポジトリを洗い出す | 古いコメント、Bot投稿、外部コメントを確認 |
| 3 | ユーザー単位の既定値を決める | 基本方針を「有効」か「無効」にする |
| 4 | 例外リポジトリを個別設定する | 必要なリポジトリだけ上書き |
| 5 | API連携やBotの動作を確認 | コメント作成が失敗した時の処理を確認 |
| 6 | READMEや運用ルールを更新 | コメント先をIssueやPull Requestに誘導 |
この機能は、コミットコメントを「使うか使わないか」だけの設定ではありません。個人アカウント配下のリポジトリで、フィードバックの入口をどう設計するかを見直すきっかけになります。
失敗しやすいポイント
Pull Requestのレビューコメントまで無効になると誤解する
コミットコメントとPull Requestレビューコメントは別物です。GitHub Docsでも、Pull RequestレビューコメントはPRレビュー中のdiffに対するコメントであり、コミットコメントやIssueコメントとは異なるものとして説明されています。(GitHub Docs)
コミットコメントを無効にしても、チームのレビュー運用全体がそのまま止まるとは限りません。ただし、コミットページを使って補足レビューをしている場合は影響があります。
既存コメントが削除されると思い込む
無効化しても、既存のコミットコメントは表示・編集・削除できます。(The GitHub Blog) 過去のコメントが消えるわけではないため、履歴確認や監査のためにコメントを残している場合でも、無効化そのものが直ちに履歴喪失につながるわけではありません。
ただし、新しいコメント作成はできなくなるため、過去コメントへの追加返信や補足説明が必要な運用では注意が必要です。
個別リポジトリ設定との優先関係を見落とす
ユーザー単位の既定値を変えても、すでに明示的なリポジトリ単位設定がある場合は、その設定が維持されます。(The GitHub Blog)
「既定で無効にしたはずなのに、このリポジトリではコメントできる」という場合は、まず個別リポジトリの設定を確認しましょう。逆に、特定のリポジトリだけコメントを受け付けたい場合は、個別設定で上書きできます。
API連携のエラー処理を確認しない
REST APIやGraphQL APIからのコミットコメント作成は、無効化されたリポジトリではブロックされます。(The GitHub Blog)
Botや自動化ツールがコミットコメント作成を前提にしていると、通知が出ない、処理が途中で止まる、ログだけにエラーが残るといった問題が起こる可能性があります。特にCIや品質チェックの結果をコメントとして投稿している場合は、ChecksやPull Requestコメントなど、別の通知方法を検討してください。
Organization単位の設定との違い
GitHubでは、2026年4月23日にOrganization単位でコミットコメントを無効化できる機能も公開されています。Organization ownersは、OrganizationのSettingsからRepository、General、Commit commentsの順に進み、「Disabled by default」を選べると説明されています。(The GitHub Blog)
今回のユーザー単位設定とは、適用対象が異なります。
| 設定単位 | 対象 | 主な利用者 |
|---|---|---|
| リポジトリ単位 | 個別リポジトリ | リポジトリ管理者 |
| Organization単位 | Organization配下のリポジトリ | Organization owners |
| ユーザー単位 | 個人アカウント所有のリポジトリ | 個人開発者、個人アカウントで複数リポジトリを管理するユーザー |
会社やチームで使っているリポジトリがOrganization所有であれば、ユーザー単位の設定だけを見ても不十分です。Organization側の方針と、個別リポジトリの例外設定もあわせて確認しましょう。
どの設定を選ぶべきか
迷った場合は、次の基準で判断すると実務に落とし込みやすくなります。
| 状況 | おすすめの考え方 |
|---|---|
| 個人リポジトリが多く、古いものも多い | ユーザー単位で「Disabled by default」を検討 |
| OSSで外部からの指摘を広く受けたい | 「Enabled by default」または対象リポジトリだけ有効 |
| PRレビュー中心の開発をしている | コミットコメントは無効化し、PRレビューに集約 |
| Botがコミットコメントを投稿している | 無効化前に投稿先とエラー処理を確認 |
| Organizationリポジトリを管理している | Organization単位の設定も確認 |
基本的には、「コミットコメントを使う明確な理由があるリポジトリだけ有効にする」運用が扱いやすいです。コメントの入口を減らすことで、レビュー、質問、不具合報告をIssueやPull Requestに集約しやすくなります。
まとめ：まずは個人リポジトリとAPI連携を確認する
GitHubの「Disable commit comments on the user level」は、個人アカウント所有リポジトリのコミットコメントを、ユーザー単位の既定値として管理できるようにする変更です。個別リポジトリに明示的な設定がある場合はその設定が維持され、無効化を継承したリポジトリではコメントフォームやインラインコメント導線が非表示になり、API経由の新規作成もブロックされます。既存コメントは引き続き表示・編集・削除できます。(The GitHub Blog)
次に取るべき行動は、個人アカウント配下のリポジトリを棚卸しし、コミットコメントを本当に使っているリポジトリを見分けることです。そのうえで、既定では無効にするのか、有効のままにするのかを決め、例外だけリポジトリ単位で調整しましょう。BotやAPI連携がある場合は、設定変更前にコメント作成の失敗時の挙動まで確認しておくと安全です。
コメント