2026/06/06 0:39
従来のコミット形式には、間違ったことに集中させられるリスクがあります
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
本文では、「Conventional Commits」の標準が能動的に有害であると論じ、チームに対してより簡素でスコープ付帯のメッセージを採用するためにこれを放棄するよう促している。このアプローチは、
featfix<type>i2c: virtio: mark device readygit diff<scope>scopedcommits.com本文
「慣用的コミット（Conventional Commits）」の問題点と代替案
はじめに
オープンソースプロジェクトで広く採用されている「慣用的コミット」は、一見すると素晴らしい基準に見えますが、実際には能動的に有害な設計です。この形式は開発者の注意を誤った場所に向けさせ、約束を果たせない構造になっています。
焦点の失敗
「慣用的コミット」は、開発者やユーザーが変更内容を理解しやすくすることを約束していましたが、その約束は完全に破られています。推奨されているフォーマットは以下の通りです。
<type>[optional scope]: <description> [optional body] [optional footer(s)]
ここで最大の欠陥は、「タイプ（type）」を優先させ、「スコープ（scope）」をオプションにしてしまった点にあります。これは完全に逆であり、変更の主題であるスコープこそが最も重要であるべきです。
なぜスコープ > タイプ なのか？
各ステークホルダーにとって、変化の種類よりも変化の領域（スコープ）を知ることが不可欠です。
- コントリビューター
- 特定のコード領域の変更を把握したい（自分の貢献以降の変化を追うため）。
- プロジェクト全体の「慣性」の所在を理解したい場合。
- プルリクエストやリベース時に競合するコミットを探す際、触られた領域が焦点になります。
- デバッガー
- バグが発生したコンポーネントに関連する変更を追跡するためです。
- どのタイプの変化でもバグを誘発し得るため、変化の種類は役に立ちません。
- インシデント対応担当者
- システムダウン時に直前に影響を与えた領域を特定する必要があります。
- 例：
スコープの変更と入出力 API エラーが同時に発生した場合は、それが原因である可能性が高いです。auth
「慣用的コミット」はスコープをオプションにし、「地獄のような」優先順位を逆転させています。主語を持たない文を書くことと同じ不健全さがあります。
タイプは冗長で制限的である
変更のタイプ（
fixfeatrefactor例：空間の浪費と判断の誤り
fix(compiler): prevent namespaced SVG <style> elements from being stripped
このメッセージを見ると、**「これはバグ修正だ」**と瞬時に理解できます。余計なスペースをタイプのために消費する必要はありません。
また、以下の例のように、単一のコミットで複数の性質（バグ修正・リファクタリング・新機能）が混在する場合があります。
refactor(core): Update webmcp support to use document.modelContext
この変更は
webmcp破損した約束
「慣用的コミット」が提唱する主なメリットは以下の通りですが、実際には多くの問題を抱えています。
1. 自動的な CHANGELOG の生成
リリース履歴とコミットログの読者は目的が異なります。
- バージョン履歴（CHANGELOG）: エンドユーザー向け。「何が変わったか（機能）」が重要です。
- コミットログ: 開発者向け。「コードベースがどのように変化するか（技術的ストーリー）」が重要です。
これらを無理に統合しようとするのは中途半端な結果しかもたらしません。
- 複雑な機能の実装: 多くのコミットから成る機能一つを、エンドユーザーには「新機能」として伝え、構築過程を隠す必要があります。「慣用的コミット」はその区別がつきません。
- リバート（Reverts）の問題: 「破壊的変更の取り消し」を、ツールは「新規の破壊的変更」と誤認識し、メジャーバージョンアップを促してしまう可能性があります。
2. 自動的に意味論的なバージョンアップの決定
ツールが自動化することは理論的には良さそうですが、現実には以下の理由で失敗します。
- 判断ミス: 予期せぬ破壊的変化や、後に判明する破壊性により、マイナーアップグレードを間違えてしまう可能性があります。
- 修正主義の歴史観: 後から破壊性がなくなったコミット（リベースなどで修正された場合）も、ツールは誤って「破壊的変更」として処理し、信頼性を低下させます。
3. ビルドプロセスのトリガー
セキュリティパッチやドキュメント修正などのトヨタのようなコミット（例：
docs: fix typos4. 企業環境での困難さ
チケット番号を必須とする監査要件がある場合、スコープフィールドに「チケット番号 #123」を入れるしかありませんが、これは有用なメタデータ（変更の場所）を無駄にしてしまいます。また、デフォルトのタイプセットではプロジェクトの独自性にフィットしないケースが多々あります。
より良い方法
Linux、FreeBSD、Go、NixOS などの成功したオープンソースプロジェクトは、スコープ付きコミットを採用しています。これらは以下の原則に従います：
<スコープ>: <説明>
スコープとは、実際のプロジェクトに関連する領域（サブシステム、パッケージ、マイクロサービスなど）を指します。特定のスコープリストを用意する必要はなく、文脈から自明であるべきです。
プロジェクト別ガイドラインの例
- Linux:
subsystem: description- 例：
i2c: virtio: mark device ready before registering the adapter
- 例：
- FreeBSD:
prefix: Description- 例：
linuxulator: Return EINVAL for invalid inotify flags
- 例：
- Git:
area: description- 例：
gitlab-ci: update macOS image
- 例：
- Go:
package: description- 例：
net/http/cookiejar: add godoc links
- 例：
- Nix:
pkgspkg-name: description- 例：
xwayland: 24.1.11 -> 24.1.12
- 例：
- Node.js:
subsystem: description- 例：
stream: fast-path stateless transform flush results
- 例：
結論
「慣用的コミット」の利点は錯覚であり、業界に具体的な利益をもたらしていません。しかし、AI アシスタントなどのデフォルトとして採用される傾向があり、反パターンを広げる要因となっています。
本稿は、「慣用的コミット」という支配的な基準に対し、スコープを重視したより健全なコミットメッセージのあり方を提言することを目的としています。詳細や議論については後継プロジェクト「scopedcommits.com」へ寄与してください。