【markdownlint】使い方完全ガイド|VS Code拡張・設定ファイル・CLI&CI自動チェックまで徹底解説

📌 この記事で学べること

  • markdownlintの基本概念: Markdownの構文チェック・静的解析(Linter)を導入するメリットと仕組み
  • VS Codeでの最速導入: 拡張機能のインストール、リアルタイム構文エラー検知、保存時の自動修正(Auto Fix)設定
  • 設定ファイルのカスタマイズ: .markdownlint.json / .markdownlint.yaml の書き方とコピペ用設定テンプレート
  • 頻出ルールと対処法: MD013(行長制限)、MD001(見出し階層)、MD033(インラインHTML)などの調整方法
  • コメントによるルール制御: 行単位・ブロック単位でルールを無効化するコメント記法一覧
  • CLI&CI自動化: markdownlint-cli2 の使い方と GitHub Actions による Pull Request 自動チェック構築手順

Markdown(マークダウン)でドキュメントや記事を執筆していると、「見出しの階層構造がバラバラになっている」「行末に不要な半角スペースが混ざっている」「リストのインデント幅が揃っていない」といった記法の乱れや表記揺れに悩まされることがよくあります。

特に複数人のチーム開発やオープンソースのドキュメント作成では、各自の書き方の癖によってMarkdownの品質に差が生じがちです。

そんな問題を一発で解決してくれるのが、Markdown専用の静的解析ツール「markdownlint」です。markdownlintを導入すれば、Markdownの構文ルール違反をリアルタイムで警告し、簡単なミスならファイルの保存時に一瞬で自動修正(Auto Fix)してくれます。

本記事では、markdownlintの概要からVS Codeでの導入手順、設定ファイルによるルールカスタマイズ、コメント制御、CLIやGitHub Actionsでの自動チェックまで、エンジニアやテクニカルライターの方にもわかりやすく徹底解説します!

📋 目次

  1. markdownlintとは?導入するメリットと仕組み
  2. 【最速】VS Codeでmarkdownlintを使う手順と初期設定
  3. 設定ファイル(.markdownlint.json / yaml)によるルールカスタマイズ
  4. よく引っかかるmarkdownlintの代表的ルール一覧と対処法
  5. 特定行やブロックでルールを無効化するコメント記法
  6. コマンドライン(CLI)での一括チェック&自動修正
  7. GitHub Actions(CI)でMarkdown構文チェックを自動化する手順
  8. markdownlintが動かない・反映されない時のトラブルシューティング
  9. まとめ&Markdown執筆環境を強化するおすすめ関連記事

1. markdownlintとは?導入するメリットと仕組み

markdownlint(マークダウンリント)とは、Markdownファイル(.md)の構文やスタイルガイドラインへの準拠度を静的に解析・検証(Lint)するオープンソースツールです。

JavaScript / TypeScript、Python、Rubyなど様々なプログラミング言語にLinter(ESLint、Flake8、RuboCop等)が存在するように、Markdownにも標準的なフォーマットルールを保つためのLinterとして markdownlint がデファクトスタンダードとして広く採用されています。

Markdown静的解析(Linter)の役割

MarkdownはHTMLよりも手軽に記述できる反面、パーサー(変換エンジン)によって解釈の違いが生じやすい記法です。例えば以下のような曖昧さや記述ミスが発生します。

  • 見出し記号(#)の後に半角スペースを入れ忘れている
  • # 見出し1 の直後にいきなり ### 見出し3 を配置して階層(H2)が抜けている
  • 箇条書きリストのインデントが2スペースと4スペースで混在している
  • 行末に意図しない不要な半角スペースやタブが残っている

markdownlintはこれらの問題を事前に検知し、エディタ上で波線(警告)を表示したり、ビルドパイプラインでエラーとして報告してくれます。

チーム開発でmarkdownlintを導入すべき3つのメリット

① ドキュメント品質と表記の完全統一

リポジトリ全体のMarkdown記法が統一され、読みやすく美しいドキュメントを維持できます。静的サイトジェネレーター(MkDocsやDocusaurus)でのビルド崩れも防げます。

② Pull Requestレビューの負荷削減

「インデントを直してください」「見出しレベルが飛んでいます」といった構文・フォーマットの指摘を人間がする必要がなくなり、ドキュメントの内容そのもののレビューに集中できます。

③ 保存時の一括自動修正(Auto Fix)で執筆ストレスゼロ

行末スペースの削除やリスト記号の統一などは、ファイルを保存(Ctrl+S / Cmd+S)した瞬間に自動で整形されるため、執筆速度が格段に上がります。

markdownlintのエコシステム一覧

ツール名 種別・用途 特徴・利用シーン
vscode-markdownlint VS Code拡張機能 エディタ上でリアルタイム警告・クイックフィックス・保存時自動修正を提供。個人利用に最適。
markdownlint-cli CLIコマンド(従来版) Node.jsベースのCLIツール。ターミナルからの実行や従来のCI環境で利用。
markdownlint-cli2 CLIコマンド(高速・推奨版) 並列処理による超高速チェックと柔軟な設定ファイル対応。GitHub Actions等のCIに最も推奨。
markdownlint (コア) Node.jsライブラリ David Anson氏が開発する静的解析エンジンのコアモジュール。

2. 【最速】VS Codeでmarkdownlintを使う手順と初期設定

Visual Studio Code(VS Code)ユーザーであれば、公式拡張機能をインストールするだけで今日からすぐに構文チェックを利用開始できます。

VS Code拡張機能のインストール

  1. VS Codeの左サイドバーにある拡張機能アイコン(または Ctrl+Shift+X / Cmd+Shift+X)をクリックします。
  2. 検索バーに markdownlint と入力します。
  3. 作者が David Ansonmarkdownlint(ID: DavidAnson.vscode-markdownlint)を選択し、「インストール」をクリックします。

💡 インストール直後から動作開始!

インストールが完了した時点で、開いているすべてのMarkdownファイルに対して構文チェックがバックグラウンドで自動実行されます。

リアルタイムでのエラー検知と修正サジェスト

Markdownファイル内でルールに違反した箇所があると、以下のように警告が表示されます。

  • 黄色の波線表示: エラー箇所の文字の下に波線が引かれます。
  • ホバーで詳細説明: 波線部分にマウスカーソルを合わせると、「MD001/heading-increment/header-increment: Heading levels should only increment by one level at a time」のようにルールIDと原因が表示されます。
  • クイックフィックス(電球アイコン): Ctrl+.(Macは Cmd+.)を押すと、ワンクリックで推奨形式に修正できます。
  • 問題パネル(Problems)の一覧表示: Ctrl+Shift+M(Macは Cmd+Shift+M)でワークスペース内のすべての警告を一括確認できます。

保存時に自動修正(Auto Fix)する settings.json の設定

markdownlintの真価を発揮させるには、「ファイルを保存した瞬間に自動で整形・修正する設定」を有効にするのがおすすめです。

VS Codeの設定ファイル(settings.json)に以下の記述を追加してください。

{
  // Markdownファイル保存時に自動修正(Auto Fix)を実行
  "[markdown]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "DavidAnson.vscode-markdownlint",
    "editor.codeActionsOnSave": {
      "source.fixAll.markdownlint": "explicit"
    }
  }
}

⚠️ 注意: Prettierと併用する場合のフォーマッター競合

VS Codeでコード整形ツール「Prettier」を有効にしている場合、editor.defaultFormatteresbenp.prettier-vscode にしつつ、source.fixAll.markdownlint: "explicit" でmarkdownlintの自動修正を同時に適用させる設定が一般的です。

3. 設定ファイル(.markdownlint.json / yaml)によるルールカスタマイズ

デフォルトのmarkdownlintルールは非常に厳格です。例えば「1行80文字を超えてはならない(MD013)」や「HTMLタグを使ってはならない(MD033)」などは、日本語のWeb記事やドキュメント作成では不都合が生じることが多いです。

プロジェクトに合わせたルール設定ファイルを作成することで、特定のルールを無効化したりパラメータを調整できます。

設定ファイルの配置場所と優先順位

設定ファイルはプロジェクトのルートディレクトリに配置します。markdownlintは以下のファイル名に対応しており、上にあるものが優先して読み込まれます。

  1. .markdownlint-cli2.jsonc / .markdownlint-cli2.yaml(cli2専用設定)
  2. .markdownlint.jsonc / .markdownlint.json(JSON形式)
  3. .markdownlint.yaml / .markdownlint.yml(YAML形式)
  4. .markdownlint.cjs / .markdownlint.mjs(JavaScript形式)

.markdownlint.json の基本構造とコピペ用テンプレ

プロジェクトのルートに .markdownlint.json を作成し、以下の設定をコピペして利用するのが最も実用的でおすすめです。

{
  "default": true,

  // MD013: 1行の文字数制限(日本語執筆では改行しないことが多いため無効化)
  "MD013": false,

  // MD033: インラインHTMLの許可(装飾タグやdetailsタグを許可)
  "MD033": {
    "allowed_elements": [
      "div", "span", "p", "br", "hr",
      "details", "summary",
      "kbd", "sub", "sup", "b", "i", "u",
      "table", "thead", "tbody", "tr", "th", "td",
      "img", "a"
    ]
  },

  // MD024: 同名見出しの重複(セクションが異なれば同じ見出し名を許可)
  "MD024": {
    "siblings_only": true
  },

  // MD007: リストのインデント幅(スペース2つに統一)
  "MD007": {
    "indent": 2
  },

  // MD029: 番号付きリストの連番形式(1. 2. 3. 順の連番を強制)
  "MD029": {
    "style": "ordered"
  },

  // MD041: ファイル先頭にH1見出しを強制するルール(Front Matter等を使う場合は無効化)
  "MD041": false
}

.markdownlint.yaml(YAML形式)での書き方

YAML形式が好まれるプロジェクトでは、.markdownlint.yaml として以下のように記述します。

default: true

# 1行の文字数制限を無効化
MD013: false

# インラインHTMLの一部要素を許可
MD033:
  allowed_elements:
    - div
    - span
    - details
    - summary
    - br
    - img

# 同一親見出し配下のみ重複チェック
MD024:
  siblings_only: true

# リストのインデント幅を2スペースに設定
MD007:
  indent: 2

# ファイル先頭のH1強制を無効化
MD041: false

無視するファイル・フォルダの指定(.markdownlintignore)

node_modules や自動生成されたドキュメント、外部ライブラリのMarkdownをチェック対象から除外したい場合は、プロジェクトルートに .markdownlintignore ファイルを作成します。(.gitignore と同じ構文です)

# 依存パッケージとビルド出力
node_modules/
dist/
build/
.site/

# 自動生成ドキュメント
docs/generated/
CHANGELOG.md

4. よく引っかかるmarkdownlintの代表的ルール一覧と対処法

markdownlintには50種類以上の組み込みルールが存在します。ここでは、執筆中に最も頻繁に遭遇する重要ルールとその意味・修正方法を解説します。

主要ルール早見表(ルールID一覧)

ルールID ルール名称 自動修正 内容と推奨される対応
MD001 heading-increment ❌ 手動 見出しレベルの飛び(H1の次にH3等)を禁止。階層順(H1→H2→H3)に修正する。
MD004 ul-style ✅ 自動 箇条書き記号(- / * / +)の統一。
MD009 no-trailing-spaces ✅ 自動 行末の不要な半角スペースを禁止・自動削除。
MD013 line-length ❌ 手動 1行の文字数制限(デフォルト80文字)。設定で無効化推奨。
MD022 blanks-around-headings ✅ 自動 見出しの前後に空行を入れることを要求。
MD024 no-duplicate-heading ❌ 手動 同一文書内で全く同じ見出しテキストを禁止。siblings_only: true で緩和可能。
MD025 single-title ❌ 手動 ファイル内にH1見出し(# タイトル)が複数あると警告。H1は1つのみにする。
MD031 blanks-around-fences ✅ 自動 コードブロック(```)の前後に空行を要求。
MD033 no-inline-html ❌ 手動 生のHTMLタグ記述を禁止。設定で許可タグを指定するか無効化。
MD040 fenced-code-language ❌ 手動 コードブロックに言語名(```bash```json 等)の明記を要求。
MD041 first-line-heading ❌ 手動 ファイルの1行目がトップレベル見出し(H1)であることを要求。

MD001: Heading levels should only increment by one level at a time

見出しの階層が1段階ずつ増えていない場合に発生します。SEO的にも文書構造的にもNGとされるパターンです。

❌ NGな書き方(H1からいきなりH3へジャンプ)

# 記事タイトル(H1)
### サブセクション(H3) ← MD001エラー!

⭕ 正しい書き方(順序通りに階層化)

# 記事タイトル(H1)
## メインセクション(H2)
### サブセクション(H3)

MD009: Trailing spaces(行末スペース)

行の末尾に不要なスペースが存在すると警告されます。Markdownでは「末尾の半角スペース2個=強制改行」という仕様がありますが、意図しないゴミスペースが混ざることが多いため、markdownlintは警告を出します。

VS Codeで自動修正を有効にしておけば、ファイルを保存するだけで自動的に末尾スペースが削除されます。

MD013: Line length(1行文字数制限)の無効化・緩和

デフォルトでは1行80文字(全角で約40文字)を超えるとエラーになります。英語の文章では段落ごとに細かく改行する習慣がありますが、日本語の執筆環境では文章が長くなることが自然であるため、"MD013": false で無効化するのが一般的です。

MD024: Multiple headings with the same content(同名見出し)

同一ドキュメント内に同じ見出し名が複数あると警告されます。例えば各章ごとに「まとめ」「使い方」といった同名見出しを付けたい場合は、設定ファイルで "siblings_only": true を指定すると、同じ親見出し(兄弟関係)の直下でなければ同名見出しが許可されます。

MD033: Inline HTML(HTMLタグの直接記述許可)

Markdown内で <div><details><img><br> などのHTMLタグを書くと発生します。リッチな表現のためにHTMLを併用したい場合は、設定ファイルの allowed_elements で使用したいタグ名をホワイトリスト登録するか、"MD033": false で完全に解除します。

MD041: First line in a file should be a top-level heading

ファイルの1行目が # タイトル から始まっていないと警告されます。JekyllやHugo、Docusaurusなどの静的サイトジェネレーターでファイルの先頭にFront Matter(YAMLヘッダー ---)を記述する場合に引っかかりやすいため、そのような環境では無効化("MD041": false)します。

5. 特定行やブロックでルールを無効化するコメント記法

「全体の設定ファイルではルールを有効にしておきたいが、この特定の箇所だけは例外的にルールを無視したい」という場合、Markdownファイル内に特殊なHTMLコメントを記述することで局所的にLinterの挙動を制御できます。

次の1行だけ無効化(disable-next-line)

コメントの直後にある「次の1行」だけ特定のルールを無効化します。最も安全で利用頻度の高い書き方です。


この行だけHTMLタグの警告を無視
非常に長いURLを含むリンク

ブロック区間のみ無効化(disable 〜 enable)

複数行にわたる特定のセクションのみルールを無効化し、終わったら再度有効化します。


長いテキストを含む表組みブロック

ファイル全体で無効化(disable-file)

ファイルの先頭に記述することで、そのファイル全体で特定ルール(または全ルール)を無効化します。


# このファイル全体でMD033とMD041のチェックをスキップ

コメント制御記法チートシート

コメント構文 対象範囲 説明・用途
<!-- markdownlint-disable-next-line MD033 --> 次の1行のみ 指定ルールの警告を1行だけスキップ。
<!-- markdownlint-disable MD013 --> コメント以降すべて 以降の行で指定ルールを無効化。
<!-- markdownlint-enable MD013 --> コメント以降すべて 無効化していた指定ルールを再開。
<!-- markdownlint-disable-file --> ファイル全体 ファイル全体の全ルールチェックを完全スキップ。
<!-- markdownlint-capture --> / <!-- markdownlint-restore --> ブロック間 現在のルール設定状態を保存し、後から元に戻す。

6. コマンドライン(CLI)での一括チェック&自動修正

プロジェクト内のすべてのMarkdownファイルを一括でチェックしたり、コミット前フック(lint-staged / Husky)に組み込む場合はCLIツールを使用します。

markdownlint-cli と markdownlint-cli2 の違い

現在CLIツールには2種類存在しますが、結論から言うと「markdownlint-cli2」の利用を強く推奨します。

  • markdownlint-cli: 従来からある標準CLI。直列処理のためファイル数が多いと低速。
  • markdownlint-cli2: 後発のモダンCLI。非同期並列処理により圧倒的に高速で、設定ファイルの自動検索やGitignore連携が強化されています。

npx でインストール不要の即時実行

Node.jsがインストールされている環境であれば、npx コマンドを使ってパッケージのインストールなしで即座にチェックを実行できます。

# カレントディレクトリ配下のすべてのMarkdownファイルをチェック
npx markdownlint-cli2 "**/*.md" "#node_modules"

# 特定のフォルダ(docs配下)のみチェック
npx markdownlint-cli2 "docs/**/*.md"

一括自動修正コマンド(–fix)の実行

ルール違反のうち自動修正(Auto Fix)が可能な項目を一発で一括整形するには、--fix 引数を付与して実行します。

# プロジェクト内の全Markdownファイルを一括自動修正
npx markdownlint-cli2 --fix "**/*.md" "#node_modules"

package.jsonscripts に登録しておくと、開発メンバー全員が同じコマンドで実行できるため便利です。

{
  "scripts": {
    "lint:md": "markdownlint-cli2 \"**/*.md\" \"#node_modules\"",
    "lint:md:fix": "markdownlint-cli2 --fix \"**/*.md\" \"#node_modules\""
  },
  "devDependencies": {
    "markdownlint-cli2": "^0.17.0"
  }
}

7. GitHub Actions(CI)でMarkdown構文チェックを自動化する手順

GitHub上でチーム開発を行う場合、GitHub Actionsのワークフローを作成しておけば、Pull Request(PR)が作成された際に自動でMarkdownの構文チェックが走り、ルール違反を検知できます。

ワークフローファイル(.github/workflows/markdownlint.yml)の作成

リポジトリの .github/workflows/markdownlint.yml に以下のワークフロー定義を作成します。

name: Markdown Lint

on:
  push:
    branches: [ main, master ]
  pull_request:
    branches: [ main, master ]

jobs:
  markdownlint:
    name: Runner / markdownlint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run markdownlint-cli2 action
        uses: DavidAnson/markdownlint-cli2-action@v19
        with:
          globs: |
            **/*.md
            !node_modules/**
            !.site/**

Pull Request時の自動チェックとレビュー効率化

このワークフローを導入すると、以下の効果が得られます。

  • CIステータスバッジの表示: PR画面でLinterチェックが成功したか(緑チェック)失敗したか(赤バツ)が一目でわかる
  • 違反箇所のインライン注釈: GitHubのファイル変更(Files Changed)画面上に、markdownlintのエラー行が自動でアノテーション表示される
  • マージブロック設定: 「Linterがパスしないとマージできない」ブランチ保護ルール(Branch Protection Rule)を設定可能

8. markdownlintが動かない・反映されない時のトラブルシューティング

🛠️ よくある原因と解決チェックリスト

  • Q1. .markdownlint.json を編集したのに設定が反映されない
    👉 VS Codeのコマンドパレット(Ctrl+Shift+P / Cmd+Shift+P)から「Developer: Reload Window(ウィンドウの再読み込み)」を実行してください。設定ファイルがキャッシュされている場合があります。また、JSONファイル内のカンマ抜けや構文エラーがないか確認してください。
  • Q2. ファイル保存時の自動修正(Auto Fix)が効かない
    👉 VS Codeの settings.json"editor.codeActionsOnSave": { "source.fixAll.markdownlint": "explicit" } が正しく設定されているか確認してください。また、すべてのルールが自動修正に対応しているわけではありません(MD001やMD024などは手動修正が必要です)。
  • Q3. 他の拡張機能(PrettierやMarkdown All in One)と挙動がおかしくなる
    👉 フォーマッターが二重で競合している可能性があります。settings.json"[markdown]" スコープで editor.defaultFormatter をどちらか一方に指定してください。
  • Q4. 特定のフォルダだけチェックから除外したい
    👉 .markdownlintignore ファイルに除外パス(例: docs/vendor/**)を記述してください。

9. まとめ&Markdown執筆環境を強化するおすすめ関連記事

markdownlintは、個人でのドキュメント作成から大規模チームでのWeb開発・CIパイプラインまで、Markdownの品質を自動で担保してくれる必須の静的解析ツールです。

📝 markdownlint活用の重要ポイントまとめ

  • VS Code拡張機能を導入し、保存時自動修正(Auto Fix)を有効化して執筆効率を最大化する
  • プロジェクトルートに .markdownlint.json を作成し、日本語執筆に不要なMD013(行長制限)等をカスタマイズする
  • 例外的な箇所は <!-- markdownlint-disable-next-line --> コメントで安全にスキップする
  • CIやコマンドラインには高速な markdownlint-cli2 を採用し、チーム全体のドキュメント品質を自動統一する

📚 あわせて読みたい!Markdownおすすめ関連記事

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です