MENU

GitHub公式ドキュメント更新：markdownlint-cli2-action 23.1.0で確認すべき点

WEBサービス

GitHubの公式ドキュメント更新として「Bump DavidAnson/markdownlint-cli2-action from 23.0.0 to 23.1.0」を見たとき、最初に押さえるべき結論は、GitHub本体の仕様変更ではなく、ドキュメントリポジトリのMarkdown lint用GitHub Actionsを更新する変更だという点です。

影響を確認すべき対象は、GitHub ActionsでDavidAnson/markdownlint-cli2-actionを使っているリポジトリ、Markdownチェックを必須ステータスにしている開発チーム、DependabotによるActions更新を自動化している運用担当者です。特に、フルコミットSHAでアクションを固定している場合は、単なるバージョン番号の更新ではなく「どのSHAに差し替わったか」まで確認する必要があります。

今回のPRは2026年4月29日にdotnet/docsへマージされ、.github/workflows/markdownlint.yml内のDavidAnson/markdownlint-cli2-action参照を23.0.0相当のSHAから23.1.0相当のSHAへ更新しています。変更ファイルは1つで、差分も1行ですが、Markdown品質チェックのCIに関わるため、運用上は「軽微だから即マージ」ではなく、既存のMarkdown lint結果・ブランチ保護・Dependabot運用との整合性を確認してから取り込むのが安全です。(GitHub)

目次

まず結論：今回の更新はMarkdown lint用GitHub Actionsの保守更新

今回のGitHub公式ドキュメント更新で変わったのは、ドキュメント本文の内容やGitHubの利用仕様ではありません。dotnet/docsリポジトリのMarkdown lintワークフローで使われているDavidAnson/markdownlint-cli2-actionが、23.0.0から23.1.0へ更新されました。

公式コミットでは、.github/workflows/markdownlint.ymlの該当行が次のように変更されています。更新前はce4853d...のSHAに# v23.0.0コメントが付いており、更新後は6b51ade...のSHAに# v23.1.0コメントが付いています。設定ファイルとして.markdownlint-cli2.jsoncを使い、対象ファイルは"**/*.md"のままです。(GitHub)

- uses: DavidAnson/markdownlint-cli2-action@6b51ade7a9e4a75a7ad929842dd298a3804ebe8b # v23.1.0
  with:
    config: ".markdownlint-cli2.jsonc"
    globs: "**/*.md"

この差分から分かる実務上のポイントは、次の3つです。

確認項目今回の変更実務で見るべき点
GitHub Actionsの参照先markdownlint-cli2-actionを23.1.0へ更新自社リポジトリでも同じアクションを使っているか確認する
参照方式バージョンタグではなくフルSHAで固定SHA更新時のレビュー手順、承認者、ロールバック手順を確認する
Markdown lint設定configとglobsは変更なし失敗時は設定変更ではなく、アクション側の更新差分を優先して見る

何が変わったか：23.1.0では依存関係の更新が中心

DavidAnson/markdownlint-cli2-actionのリリース情報では、v23.1.0はmarkdownlint-cli2 v0.22.1とmarkdownlint v0.40.0に関する更新として公開されています。一方、直前のv23.0.0もmarkdownlint v0.40.0を含んでいたため、今回の23.0.0から23.1.0への差分は、Markdownルールそのものの大きな追加というより、markdownlint-cli2やActions関連パッケージの保守更新として見るのが現実的です。(GitHub)

package.json上では、v23.0.0からv23.1.0にかけて、主な本番依存関係が次のように変わっています。

パッケージ更新前更新後見るべき影響
markdownlint-cli20.22.00.22.1CLI実行や依存関係更新による出力差分の有無
@actions/core3.0.03.0.1GitHub Actions実行基盤との互換性
runs.usingnode24node2423.0.0から23.1.0ではランタイム指定自体は同じ

markdownlint-cli2の changelog では、0.22.1の内容は「依存関係の更新」とされています。つまり、既存のMarkdownルール設定が大きく変わる更新とは限りません。ただし、依存ライブラリの更新によって、特定のファイルパス、設定ファイル、エッジケースで出力が変わる可能性は残ります。(GitHub)

影響を受けるリポジトリの判断基準

今回の更新を見て、自社やチームのGitHub運用に影響があるかどうかは、次の順番で判断すると早いです。

リポジトリの状態影響度対応
DavidAnson/markdownlint-cli2-actionを使っていない低直接対応は不要。ただしActions更新ポリシーの見直し材料にはなる
@v23などタグ参照で使っている中タグ更新により実行内容が変わる可能性があるため、直近のCI結果を確認する
フルSHAでv23.0.0相当を参照している中更新する場合は新SHAへ明示的に差し替える
Markdown lintを必須チェックにしている高更新後にPRがブロックされないか、テストブランチで確認する
DependabotでGitHub Actions更新を有効化している高PR作成、レビュー、auto-merge条件を確認する
self-hosted runnerを使っている中〜高ランナー側で対象のJavaScript actionを実行できる状態か確認する

特に注意したいのは、タグ参照とSHA参照の違いです。GitHubは、サードパーティアクションを使う場合、フルコミットSHAで固定することがイミュータブルな参照として最も安全だと説明しています。タグ参照は便利ですが、タグは移動または削除される可能性があるため、セキュリティ重視の組織ではSHA固定とレビュー運用をセットで考えるべきです。(GitHub Docs)

GitHub Actions利用者が確認すべきチェックリスト

今回のGitHub公式ドキュメント更新を自社リポジトリへ反映する前に、次の項目を確認してください。

チェック項目確認方法判断基準
対象アクションを使っているか.github/workflows内を検索DavidAnson/markdownlint-cli2-actionがあれば対象
参照形式は何か@v23、@v23.1.0、@SHAを確認セキュリティ重視ならフルSHA固定を検討
lint対象ファイルは適切かglobsを確認**/*.mdならサブディレクトリ配下も対象
設定ファイルは存在するかconfigのパスを確認.markdownlint-cli2.jsoncなどが実在すること
更新後にCIが通るかテストブランチで実行Markdown違反が増えないか確認
必須チェックに入っているかbranch protection rulesを確認失敗時にPRマージが止まるか把握
Dependabot運用と整合するか.github/dependabot.ymlを確認GitHub Actions更新の頻度・レビュー担当を確認

リポジトリ内で対象アクションを探すなら、ローカルで次のように検索できます。

grep -R "DavidAnson/markdownlint-cli2-action" .github/workflows

Windows環境でPowerShellを使う場合は、次のコマンドでも確認できます。

Select-String -Path ".github/workflows/*.yml",".github/workflows/*.yaml" -Pattern "DavidAnson/markdownlint-cli2-action"

Dependabot利用時に見るべきポイント

今回のPRはDependabotによって作成され、github_actionsの依存関係更新として扱われています。GitHubの公式ドキュメントでも、GitHub Actions向けのDependabot version updatesを有効にすると、ワークフローファイル内のアクション参照や再利用可能ワークフローの参照を最新に保つためのPRが作成されると説明されています。(GitHub Docs)

自社でも同様の更新を自動化する場合は、.github/dependabot.ymlにGitHub Actions向けの設定があるか確認します。

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

ただし、Dependabot PRを自動マージしている場合は注意が必要です。Markdown lintのような品質チェック系アクションは、アプリケーションコードを直接壊すわけではありませんが、PRの必須チェックを失敗させることがあります。特にドキュメント公開、SDK生成、ナレッジベース更新などと連動しているリポジトリでは、auto-mergeの条件に「該当workflowの成功」「CODEOWNERSレビュー」「リリース前テスト」を含めると安全です。

移行手順：23.1.0へ更新する場合の実務フロー

23.0.0から23.1.0へ更新する場合は、次の流れで進めると失敗を減らせます。

| 手順 | 作業 | 目的 |
| -: | ————————— | ——————- |
| 1 | 対象workflowを特定する | 影響範囲を限定する |
| 2 | 現在の参照先を記録する | ロールバックしやすくする |
| 3 | テストブランチで新SHAまたは新タグへ変更する | 本番PR前にCI影響を見る |
| 4 | Markdown lint結果を比較する | 新規エラーの有無を確認する |
| 5 | 失敗した場合は設定・対象ファイル・依存差分を切り分ける | 原因を誤認しないため |
| 6 | CODEOWNERSまたはCI管理者がレビューする | workflow変更の安全性を担保する |
| 7 | 必要ならDependabot設定を更新する | 今後の更新を継続可能にする |

実際の更新例は、公式コミットと同じくフルSHAで固定するなら次の形です。

- uses: DavidAnson/markdownlint-cli2-action@6b51ade7a9e4a75a7ad929842dd298a3804ebe8b # v23.1.0
  with:
    config: ".markdownlint-cli2.jsonc"
    globs: "**/*.md"

ここで重要なのは、コメントの# v23.1.0だけを書き換えても実行されるアクションは変わらないという点です。GitHub Actionsが参照するのは@の後ろにあるタグまたはSHAです。フルSHA運用では、コメントは人間向けのメモとして扱い、実際のSHAとコメントが一致しているかレビューで確認してください。

CIで失敗しやすいポイント

globsの対象範囲が広く、想定外のMarkdownまで検査される

公式コミットではglobs: "**/*.md"が使われています。この指定は、リポジトリ配下のMarkdownファイルを広く対象にします。READMEだけを検査したいリポジトリでは便利ですが、古いドキュメント、サンプル、生成ファイル、外部由来のMarkdownまで対象になると、更新後にlintエラーが増えることがあります。

除外したいファイルがある場合は、.markdownlint-cli2.jsonc側で無視設定を使うか、workflow側のglobsを見直します。生成ファイルを手動修正で直すと、次回生成時に差分が戻ることがあるため、生成元テンプレート側を修正するか、対象外にする判断が必要です。

fix: trueを安易にCIへ入れる

markdownlint-cli2-actionには、修正可能な問題を自動修正するfix入力があります。READMEでもfix: trueの例が示されていますが、通常のPRチェックに入れる場合は慎重に扱うべきです。自動修正が作業ツリーに差分を生むと、その差分をどうコミットするか、誰がレビューするかという別の運用課題が出ます。(GitHub)

おすすめは、通常のPRチェックではfixを使わず、開発者のローカル実行や専用の修正ワークフローに分けることです。

「GitHubの障害」ではなく「lint基準の差分」を疑う

更新直後にMarkdown lintが失敗すると、GitHub Actions側の問題に見えることがあります。しかし今回のようなアクション更新では、まず次を確認してください。

  • 失敗したファイルは更新前から存在していたか
  • エラーになったルールIDは何か
  • .markdownlint-cli2.jsoncの設定で意図的に許可・禁止しているか
  • markdownlint-cli2の更新で出力形式や依存処理が変わっていないか
  • 旧SHAに戻すと同じファイルが通るか

旧SHAに戻して通るなら、アクション更新による影響の可能性があります。旧SHAでも失敗するなら、直近のMarkdown変更や設定変更が原因の可能性が高いです。

セキュリティ面で確認すべきこと

GitHub Actionsのサードパーティアクションは、便利な一方でサプライチェーンリスクを伴います。GitHubのセキュア利用ガイドでは、サードパーティアクションが侵害された場合、リポジトリのシークレットやGITHUB_TOKENに影響する可能性があるため、フルコミットSHAでの固定、ソースコード監査、信頼できる作者かどうかの確認が推奨されています。(GitHub Docs)

今回の更新を機に、次の運用を見直すと効果的です。

見直し項目推奨アクション
サードパーティアクションの参照重要リポジトリではフルSHA固定を基本にする
workflow変更のレビュー.github/workflowsをCODEOWNERS対象にする
Dependabot PR自動マージ前にCI成功とレビュー条件を必須化する
許可するActions組織・リポジトリ設定で利用可能なアクションを制限する
ロールバック更新前SHAをPR本文やレビューコメントに残す

GitHub Docsのスタイルガイドでも、ドキュメント内でサードパーティアクションを使うコード例では、バージョン番号やブランチではなくフルコミットSHAへ固定する方針が示されています。今回のdotnet/docs側の変更も、この考え方と整合する形でSHAを差し替える更新です。(GitHub Docs)

管理者・アーキテクト向けの判断ポイント

開発者個人にとっては「CIのMarkdownチェックが通るか」が主な関心ですが、cloud admins、solution architects、technical decision makersにとっては、もう少し広い観点で見る必要があります。

組織のActions更新ポリシーに合っているか

Dependabotが作るPRをどこまで自動化するかは、組織のリスク許容度によって変わります。ドキュメント専用リポジトリなら自動マージしやすい一方、製品リリースや公開サイト生成に直結するリポジトリでは、軽微なlint更新でも承認フローを残すべきです。

self-hosted runnerの保守体制は十分か

markdownlint-cli2-actionのv23.0.0およびv23.1.0ではruns.using: node24が指定されています。23.0.0から23.1.0への更新だけならランタイム指定は変わりませんが、より古いバージョンから上げる場合は、self-hosted runner側のGitHub Actions runnerや実行環境が対応しているか確認してください。(GitHub)

必須チェックの設計が過剰になっていないか

Markdown lintを必須チェックにすること自体は有効です。ただし、古いドキュメントが多いリポジトリでは、全ファイルを一度に厳格化すると開発速度が落ちます。新規・変更ファイルのみを対象にするワークフローや、段階的にルールを有効化する運用も検討しましょう。

よくある疑問

23.1.0へすぐ更新すべき？

23.0.0を使っていてCIが安定しているなら、まずテストブランチで23.1.0を試し、Markdown lintの結果が変わらないことを確認してから更新するのが安全です。今回の差分は保守更新寄りですが、必須チェックに組み込まれている場合は、PRマージを止める可能性があります。

Markdownのルールが増えた？

今回の23.0.0から23.1.0への更新だけを見る限り、markdownlint自体はv0.40.0のままです。markdownlint-cli2は0.22.0から0.22.1へ上がっており、changelog上は依存関係更新が中心です。そのため、ルール追加と断定するより、CLIや依存関係更新による差分がないかを見るのが適切です。(GitHub)

GitHubのサービス仕様が変わった？

今回の更新は、GitHub.com全体の仕様変更ではありません。dotnet/docsリポジトリ内のGitHub Actionsワークフローで利用するアクション参照の更新です。検索時に「GitHub documentation update」と表示されていても、実務上は「ドキュメントCIの依存関係更新」と捉えると判断しやすくなります。

タグ参照とSHA参照のどちらがよい？

利便性を優先するなら@v23のようなタグ参照は扱いやすいです。一方、セキュリティや再現性を重視するなら、フルコミットSHAで固定し、Dependabotや手動レビューで定期的に更新する運用が向いています。重要な本番リポジトリ、公開ドキュメント、規制対応が必要な組織では、SHA固定を基本にする方が監査しやすくなります。

次に取るべき行動

今回のGitHub公式ドキュメント更新を見たら、まず自社リポジトリでDavidAnson/markdownlint-cli2-actionを使っているか検索してください。使っていない場合は直接対応不要です。使っている場合は、参照形式がタグかSHAかを確認し、テストブランチで23.1.0相当へ更新してCI結果を比較します。

特に、Markdown lintを必須チェックにしているリポジトリでは、更新前後のエラー件数、対象ファイル、ルールIDを確認してからマージすることが重要です。Dependabotを利用している場合は、GitHub Actions更新PRのレビュー担当、auto-merge条件、ロールバック手順も合わせて見直しましょう。

小さな1行差分でも、CI/CDの品質ゲートに関わる変更は運用影響を持ちます。今回の更新は、GitHub Actionsの依存関係を安全に保つだけでなく、Markdown品質チェック、サードパーティアクションのSHA固定、Dependabot運用を点検するよい機会です。

WEBサービス
CI/CD GitHub Actions Dependabot markdownlint

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次