コミットメッセージ検証ツール｜Conventional Commits 準拠を 8 規則でチェック

Conventional Commits の書式に沿っているかを 8 つの規則で点検するツールです。件名のフォーマット、長さ、命令形、本文の折り返し、破壊的変更マーカー、フッタ形式までを一画面に並べ、合格・警告・不合格を色分けで示します。

💡 このツールについて

チームで Git を使っていると「コミットメッセージの書き方がバラバラ」という悩みがつきまといます。feat: で始めるのか、件名は何文字までか、本文の前に空行が要るのか——ルールは決めたものの、いざ書くときに守れているか自信が持てない。そんなときに役立つのが、書いたメッセージを貼り付けるだけで規則違反を洗い出すこのツールです。

検証する 8 規則は次のとおりです。R1 件名フォーマット（type(scope): subject）、R2 件名の長さ（50 文字以下推奨・72 文字以下必須）、R3 件名末尾のピリオド禁止、R4 命令形での記述、R5 件名と本文の間の空行、R6 本文各行 72 文字以内、R7 破壊的変更マーカー（! または BREAKING CHANGE:）、R8 フッタのトークン形式（Refs:・Closes #N など）。判定結果はそのまま監査レポートとしてコピーでき、レビューコメントやチーム規約の説明に貼り付けられます。

🧐 よくある質問

Q. Conventional Commits とは何ですか? コミットメッセージに feat: fix: などの「型」を付けて、変更の意図を機械的に読めるようにする書式の取り決めです。CHANGELOG の自動生成やセマンティックバージョニングと相性が良く、OSS でも広く採用されています。

Q. 件名の 50 文字と 72 文字、どちらが正しいのですか? 慣習では「50 文字以下が理想、72 文字を超えると折り返しで見切れる」とされます。本ツールは 50 文字超で警告、72 文字超で不合格として両方を示します。

Q. 日本語のコミットメッセージでも使えますか? 件名長や空行・フッタ形式のチェックは言語を問わず機能します。ただし R4 の命令形判定は英単語の語尾（-ed / -ing）を見るヒューリスティックのため、日本語の件名では警告が出ない点に留意してください。

Q. scope は必須ですか? 必須ではありません。feat: ... のように省略しても R1 は合格します。feat(parser): ... のように括弧で囲んで付けることも可能です。

Q. 破壊的変更はどう書けばよいですか? 件名の型の直後に ! を付ける（feat!:）か、本文に BREAKING CHANGE: 行を入れます。! と BREAKING CHANGE: はどちらか一方だけでも有効で、R7 はどちらの形式が使われたかを示します。

📚 コミットメッセージ規約の豆知識

「件名 50 文字・本文 72 文字」という数字は、Git の標準ツールが端末幅 80 桁を前提に整形してきた歴史に由来します。git log がインデントを加えても折り返さずに収まるよう、本文は 72 桁が目安とされてきました。Conventional Commits はこの古い慣習の上に「型」という構造を載せたもので、人間が読むためのメッセージを機械も読める契約へと変えた点が画期的でした。国内でもセマンティックリリースを導入するチームが増え、コミット規約が単なる作法から自動化の入口へと位置づけが変わっています。