# commitlint とは？

> commitlint は、コミットメッセージを設定された規約に照らしてチェックし、合意されたフォーマットに従わないコミットを拒否するツールです。

Source: https://latchkey.dev/ja/learn/ci-glossary/commitlint-definition  
Updated: 2026-06-26

## なぜ重要か

コミットメッセージを読み取るリリース自動化は、それらのメッセージが規約に従っている場合にのみ機能します。commitlint はそれをコミット時点で強制するため、履歴がパース可能なまま保たれます。ローカルのhookとCIのチェックの両方として実行することで、違反がmainブランチに到達する前に検出できます。

## Where this shows up in a real pipeline

A definition is only useful if you can recognise the thing in your own logs. In practice this concept surfaces when a job behaves differently between a local run and a runner, which is where most CI debugging starts.

- Compare a local run against a CI run of the same command before assuming a tool is at fault.
- Runner environments differ in shell, PATH, TTY availability, available memory, and disk. Most CI-only behaviour traces to one of those five.
- Pin tool versions so an environment difference cannot be introduced by an unrelated update.

## FAQ

### What is What is commitlint??

commitlint is a linter that validates commit messages against rules, typically a conventional commit format, and fails when a message does not conform. It runs as a hook locally or as a check in CI. It enforces the structured commit messages that automated versioning and changelogs depend on.

### Why does What is commitlint? matter in CI/CD?

Release automation that reads commit messages only works if those messages follow the convention. commitlint enforces that at commit time, so the history stays parseable. Running it both as a local hook and a CI check catches violations before they reach the main branch.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt