textlint（テキストリント）とは？日本語の文章校正をVS Code・CI・コミット前に回す設定手順【v15.8対応】

textlint（テキストリント）は、Markdownやテキストの文章をルールに沿って機械的に点検するオープンソースのリンターです。ESLintがJavaScriptのコードを点検するのと同じ仕組みを、文章に当てはめたものと考えるとわかりやすいでしょう。本体だけでは何もチェックせず、「ら抜き言葉」「読点の多すぎる文」「表記ゆれ」といったルールを自分で選んで組み合わせます。

この記事では、2026年8月1日公開の textlint 15.8.0 を Node.js 26.5.0 上で実際に動かした出力をもとに、導入から .textlintrc.json の書き方、日本語向けプリセットの選び方、VS Code拡張の設定、コミット前チェック、GitHub ActionsとMCPサーバーへの組み込みまでを順に説明します。2026年11月8日に同じ環境で再実行し、15.8.0が引き続きnpmの最新版であることと、出力が変わっていないことを確認しました。

まとめ：textlintの要点と最初に入れる構成

• textlintはルールを差し込んで使う文章用リンター。本体（15.8.0）は Node.js 20.18.0 以上が必要
• 日本語の技術文書なら textlint-rule-preset-ja-technical-writing（23ルール）と、用語集を当てる textlint-rule-prh の2つから始めるのが定番
• 設定は .textlintrc.json に書く。--init はインストール済みのルールを全部 true で書き出すので、prh のようにオプション必須のルールはそのままだと起動時エラーになる
• 自動修正は --fix。先に --fix --dry-run --format diff で差分を確認できる
• 特定の語やパターンを許可するなら textlint-filter-rule-allowlist、段落単位で外すなら textlint-filter-rule-comments
• VS Code拡張は旧 taichi.vscode-textlint がアーカイブ済み。現在は textlint組織が保守する 3w36zj6.textlint を入れる
• コミット前に止めるなら husky＋lint-staged、PRで止めるなら -f github で注釈を出す。v14.8.0以降は textlint --mcp でAIエージェントから呼べる
• 外部通信を行わないルール・プラグインを選び、ローカルで実行する構成なら、社外へ文章を送らずに校正できる

textlintの仕組みと校正できる範囲

ルール・プリセット・フィルター・プラグインの役割

textlintは、文章をいったん構文木（AST）に変換し、その上でルールを走らせます。設定ファイルに登場する部品は4種類あり、それぞれ担当が違います。

ESLintと同じく、どのルールを入れるかで振る舞いがまったく変わります。「textlintで何ができるか」は、実際には「どのルールを入れたか」で決まります。

標準で読めるファイル形式とHTMLの落とし穴

本体に同梱されているのは Markdown と プレーンテキスト のプラグインだけです。.md と .txt は追加設定なしで検査できます。HTML、LaTeX、Re:VIEW などは textlint-plugin-html（1.0.1）、textlint-plugin-latex2e（1.2.1）、textlint-plugin-review（0.4.1）を別途入れて plugins に登録します。

注意したいのは、対応していない拡張子のファイルを渡すとエラーにならず黙って無視される点です。15.8.0で textlint docs/a.html をプラグイン無しで実行すると、何も出力されず終了コード0で終わりました。同じファイルでも textlint-plugin-html を有効にすると、<p> 内の表記ゆれが検出されます。CIで「通っているのに実はチェックされていない」状態を避けるには、対象の拡張子に合うプラグインが入っているかを最初に確かめてください。

HTMLプラグインは npm install --save-dev textlint-plugin-html で入れ、設定には "plugins": { "html": true } の1行を足します。ただし、Markdownとは扱いが違う点があります。次のHTMLを1.0.1で検査すると、<p> と <pre> の両方で「かも」と「！」が指摘され、4件のエラーになりました。

<p>この方法は使えるかもしれない！</p><pre>コード内は対象外かもしれない！</pre>

  1:12  error  弱い表現: "かも" が使われています。  ja-technical-writing/ja-no-weak-phrase
  1:18  error  Disallow to use "！"                 ja-technical-writing/no-exclamation-question-mark
  1:36  error  弱い表現: "かも" が使われています。  ja-technical-writing/ja-no-weak-phrase
  1:42  error  Disallow to use "！"                 ja-technical-writing/no-exclamation-question-mark

Markdownのコードブロックは検査されませんが、HTMLの <pre> の中身は本文と同じく検査されました。コード例を多く含むHTMLを対象にするなら、指摘を後述のフィルターで抑えるか、Markdownの原稿の段階で検査する方が扱いやすくなります。

インストールと.textlintrcの初期設定

Node.jsの要件とプロジェクトへの導入

textlint 15.8.0 の package.json は "node": ">=20.18.0" を指定しています。v15.0.0（2025年6月22日）で全パッケージの要件が Node.js 20系へ引き上げられたため、Node.js 18 の環境では動きません。現行のLTSはNode.js LTSの最新は24、10月28日に26へ昇格｜v22・v24のEOLと確認・固定・移行の手順で確認できます。

インストールはプロジェクトごとのローカル導入が基本です。ルールのバージョンを package.json に記録できます。チームとCIで依存関係をそろえるには、package-lock.json も共有し、npm ci でインストールします。

npm install --save-dev textlint-filter-rule-comments textlint textlint-rule-preset-ja-technical-writing textlint-rule-prh
npx textlint --version   # v15.8.0

グローバル導入（npm install -g）もできますが、ルールも同じくグローバルに入れる必要があり、人によって結果が変わる原因になります。

毎回の対象指定を省くには、package.json の scripts に登録しておくと便利です。globは引用符で囲み、シェルではなくtextlintに展開させます。

"scripts": {
  "lint:text": "textlint \"docs/**/*.md\"",
  "fix:text": "textlint --fix \"docs/**/*.md\""
}

これで npm run lint:text の1コマンドで、手元・CI・後述のコミット前チェックの検査対象をそろえられます。

初期化コマンドで作られる設定とprhの起動時エラー

npx textlint --init は、package.json のdependenciesとdevDependenciesに登録されたルールなどを読み取って .textlintrc.json を作ります。次は、冒頭の導入構成に加えてtextlint-rule-preset-jtf-styleも直接の依存関係として追加した場合の生成例です。ルールとフィルターは true で書き出されます。

{
  "plugins": {},
  "filters": {
    "comments": true
  },
  "rules": {
    "preset-ja-technical-writing": true,
    "preset-jtf-style": true,
    "prh": true
  }
}

このまま検査すると、prhが textlint-rule-prh require Rule Options. というエラーで止まり、1件も検査されません（終了コード1）。prhは用語集ファイルのパスが必須のため、true では動かないからです。2026年11月8日にHTMLプラグインやallowlistフィルター、SmartHRのプリセットも入れた状態で --init を実行し直したときも、plugins に "html": true、filters に "allowlist": true が書き出され、同じprhのエラーで止まりました。--init の後は、オプションが必要なルールを必ず書き換えます。

textlint設定ファイルの対応形式とルール指定

設定ファイルは .textlintrc のほか、.textlintrc.json・.textlintrc.yaml・.textlintrc.yml・.textlintrc.js・.textlintrc.cjs、または package.json の textlint フィールドで読み込まれます。15.8.0の設定ローダーは、設定ファイルがUTF-8でないと textlint configuration file must be encoded in UTF-8 で止まります。Windowsのメモ帳でShift_JIS保存した場合などに当たるので覚えておくとよいでしょう。

プリセットの一部ルールだけを調整するときは、プリセット名の下にルール名を書きます。次の例は、1文の上限を120字に緩め、感嘆符の禁止を外し、弱い表現（「かも」など）をエラーではなく警告に下げる設定です。

{
  "filters": { "comments": true },
  "rules": {
    "preset-ja-technical-writing": {
      "sentence-length": { "max": 120 },
      "no-exclamation-question-mark": false,
      "ja-no-weak-phrase": { "severity": "warning" }
    },
    "prh": { "rulePaths": ["./prh.yml"] }
  }
}

標準のJSONにはコメントを書けませんが、textlintのJSON設定ファイルはコメントに対応しています。別形式を使いたい場合は .textlintrc.js か YAML形式を選びます。JSONとJSONCの違いはJSONにコメントは書ける？コメントアウトできない理由とJSONC・JSON5の書き方・言語別の読み込み実装【2026年版】にまとめています。

CLIの基本的な使い方とエラー出力の読み方

textlintの実行例と診断出力の読み方

次の5行のMarkdownの前に見出し行「# サンプル」と空行を置いたファイルを、プリセットを既定値のまま有効にし、後述の用語集（prh.yml）を当てた設定で検査しました。出力は列揃えを詰め、複数行にわたるメッセージは1行に省略しています。

javascriptでサーバを立てる手順を説明します。
この設定は、ローカル環境で、テスト用に、一時的に、使うためのものです。
ファイルを見れる状態にしておきます。
処理は高速です!
この機能は使えないわけではない。

$ npx textlint docs/sample.md
  3:1   ✓ error  javascript => JavaScript                 prh
  3:12  ✓ error  サーバ => サーバー                         prh
  4:25  error    一つの文で"、"を4つ以上使用しています       ja-technical-writing/max-ten
  5:7   error    ら抜き言葉を使用しています。                ja-technical-writing/no-dropping-the-ra
  6:8   error    Disallow to use "!"                       ja-technical-writing/no-exclamation-question-mark
  7:13  error    一文に二回以上利用されている助詞 "は" がみつかりました。  ja-technical-writing/no-doubled-joshi
  7:14  error    二重否定: 〜ないわけではない                ja-technical-writing/no-double-negative-ja

✖ 7 problems (7 errors, 0 warnings, 0 infos)
✓ 2 fixable problems.

各行は「行:列」「重大度」「メッセージ」「ルール名」の順です。行頭に ✓ が付いたものは自動修正できる指摘で、この例では用語集による置換の2件だけでした。ら抜き言葉や二重否定のように書き直し方が1通りに決まらない指摘は、人が直します。

出力形式は -f（--format）で変えられます。15.8.0の --help が挙げる形式は checkstyle・compact・github・jslint-xml・json・junit・pretty-error・stylish（既定）・table・tap・unix です。

fixオプションとdry-runによる自動修正の確認

--fix はファイルを直接書き換えます。先に差分だけ見たいときは --dry-run と --format diff を組み合わせます。

$ npx textlint --fix --dry-run --format diff docs/sample.md
- javascriptでサーバを立てる手順を説明します。
+ JavaScriptでサーバーを立てる手順を説明します。

✔ Fixed 2 problems

掲載したprhの既定設定では、Markdownのインラインコードとコードブロック内の javascript は置換されません。ただし、通常の本文中にある意図的な表記も用語集に一致すれば置換されます。初回はdry-runで差分を読み、問題なければGitにコミットした状態で --fix を実行すると、git diff で変更内容を確認できます。

終了コードと重大度（severity）の関係

通常の検査では、エラーが1件でもあれば終了コードは1、警告（warning）だけなら0です。上の設定で「これは問題かもしれません。」を検査すると、ja-no-weak-phrase の警告が1件出て終了コード0で終わりました。CIで止めたくないルールは "severity": "warning" に下げる、止めたいルールはerrorのまま残す、という使い分けができます。--quiet を付けると警告は表示されずエラーだけが出ます。

対象ファイルが見つからない場合は終了コード2です。15.8.0で textlint nonexist.md や一致しないglobを渡すと、TextlintFileSearchError: Not found target files. を出して2で終わりました。一方、公式ドキュメントは設定・ルールの読み込み失敗も2としていますが、同じ環境でprhのオプション漏れ、存在しないルール名、壊れたJSONの設定ファイルを試すと、いずれも終了コードは1でした。壊れたJSONでは No rules found, textlint hasn’t done anything と表示されるだけです。CIで終了コード1を「校正エラー」とだけ解釈せず、ログに検査結果が出ているかも確かめてください。

指摘を抑える方法：comments・allowlist・.textlintignore

ルールをまるごと無効にせず、一部の指摘だけを抑える方法は3つあります。抑える範囲で選び分けます。

commentsは冒頭のコマンドで導入済みなので、allowlistは npm install --save-dev textlint-filter-rule-allowlist で追加します。次の設定で、両方のフィルターの効き方を確かめました。allowlistのREADMEによると、allow には文字列のほか、/ で囲んだ正規表現も書けます。正規表現の \d などはJSON文字列の中なので \\d とエスケープします。

{
  "filters": {
    "comments": true,
    "allowlist": { "allow": ["かもしれません"] }
  },
  "rules": { "preset-ja-technical-writing": true }
}

この機能は便利かもしれません。

<!-- textlint-disable -->

この設定は動作するかもしれない！

<!-- textlint-enable -->

この設定は動作するかもしれない。

フィルター無しでは「かも」が3件、「！」が1件指摘されるこの文書で、残った指摘は最終行の「かも」1件だけでした。1行目は「かもしれません」が許可リストに一致したため、コメントで囲んだ段落は弱い表現も感嘆符もまとめて対象外になりました。最終行の「かもしれない」は許可した文字列と一致しないため残ります。コメントの前後には空行を入れます。<!-- textlint-disable ルール名 --> のようにルール名を書くと、そのルールだけを止められます。

allowlistは便利ですが、許可を増やすほどルールが効かなくなります。許可する語はリポジトリで管理し、追加するときにレビューを通すと、抜け道として使われにくくなります。ファイル単位で外すなら、.gitignore と同じ書式の .textlintignore にパスを書きます。

日本語向けルール・プリセットの選び方

日本語の主要ルールは textlint-ja 組織がまとめて保守しています。目的別に選ぶと次のとおりです（バージョンは2026年11月8日時点のnpm latest）。

preset-ja-technical-writingの23ルールと既定値

12.0.2には23のルールが入っています。既定値で効きやすいのは次の数値系のルールで、技術文書としては厳しめに設定されています。

• sentence-length：1文100字まで
• max-comma：1文の「,」は3つまで
• max-ten：1文の読点「、」は3つまで（4つ目で指摘）
• max-kanji-continuous-len：漢字の連続は6字まで
• no-mix-dearu-desumasu：本文は「ですます」、箇条書きは「である」を優先

このほか、ら抜き言葉、二重否定、同じ助詞の連続、半角カナ、不自然なアルファベットの混入、ゼロ幅スペースなどを検出します。既存の大量の文書に後から入れると指摘が数百件出ることがあります。最初は sentence-length と max-kanji-continuous-len を警告に下げ、新規・更新した文書だけerrorで止める段階導入にすると、チームが指摘を無視する状態になりにくくなります。

prhによる社内用語集の適用

textlint-rule-prh は、YAMLの用語集に書いた「正しい表記」と「誤りのパターン」を照合し、置換まで行うルールです。上の実行例の2件の自動修正はこの設定から出ています。

version: 1
rules:
  - expected: JavaScript
    patterns:
      - javascript
      - Javascript
  - expected: サーバー
    pattern: /サーバ(?!ー)/

「サーバ」と「サーバー」のように長音の有無を揃える場合、単純な文字列だと「サーバー」の中の「サーバ」まで一致してしまいます。正規表現の否定先読み (?!ー) で直後に「ー」が無い場合だけに絞るのがポイントです。用語集はリポジトリに置いてレビュー対象にすると、表記ルールの変更履歴が残ります。

生成AIの文章向けpreset-ai-writing

@textlint-ja/textlint-rule-preset-ai-writing は、生成AIの文章に出やすい書き方を検出するプリセットです。1.7.0（2026年5月13日）は no-ai-list-formatting・no-ai-hype-expressions・no-ai-emphasis-patterns・ai-tech-writing-guideline・no-ai-colon-continuation の5ルールで構成され、textlint 15.1.0以降が必要です。箇条書きで「**高速化**: 処理が速くなります」のように太字とコロンを組み合わせた行を書くと、no-ai-list-formatting が1行ずつ指摘しました。パッケージ名は @textlint-ja スコープ付きで、設定には "@textlint-ja/preset-ai-writing": true と書きます。

企業公開プリセットの採用とSmartHRの既定値

自社の表記ルールを一から作る前に、他社が公開しているプリセットを土台にする方法もあります。SmartHRの textlint-rule-preset-smarthr（1.38.3・2026年11月4日公開）は、GitHubの kufu 組織で公開されています。require して数えると21ルールで、表記ゆれの辞書（dict/prh-idiomatic-usage.yml）と禁止表現の一覧（dict/pattern-rules.yml）を同梱しています。既定値は1文120字まで（preset-ja-technical-writingは100字）、全角文字と半角英数字の間にスペースを入れない（"space": "never"）など、公開文書向けに決められています。末尾に句点の無い行を検査すると、指摘に「理由」「修正」「例」が添えられて表示されました。

ただし、他社の規則は他社の文書のために作られています。preset-ja-technical-writingと同時に有効にすると、同じ観点のルールが二重に指摘することもあります。まず1つのプリセットを入れ、合わない規則を個別に false にしていく方が、指摘の出どころを追いやすくなります。

VS Code拡張機能の設定と旧拡張からの移行

VS Codeで書きながら指摘を見るには拡張機能を入れます。長く使われてきた taichi.vscode-textlint は最終更新が2021年12月のバージョン0.11.0で、GitHubリポジトリもアーカイブされています。現在はtextlint組織が引き継いだ 3w36zj6.textlint（表示名 textlint、0.13.0・2026年7月23日更新）が保守版です。古い記事の手順で旧拡張を入れている場合は、入れ替えてください。

VS Codeで指摘が出るまでの手順は次の4つです。

1. Node.js 20.18.0以上を入れる（node -v で確認）
2. 文書のフォルダで npm install --save-dev textlint textlint-rule-preset-ja-technical-writing を実行する
3. 同じフォルダに .textlintrc.json を置き、"rules": { "preset-ja-technical-writing": true } を書く
4. 拡張機能ビューで「textlint」を検索し、発行元が textlint の 3w36zj6.textlint を入れて、Markdownを保存する

拡張機能は、開いているフォルダの node_modules にあるtextlintを使い、無ければグローバル導入版を探します。拡張機能だけでは校正できず、ローカルまたはグローバルに導入したtextlintと、ルールを有効にした設定が必要です。この記事のローカル構成では、プロジェクトにtextlintと .textlintrc.json が無ければ何も表示されません。主な設定は次のとおりです。

保存時に自動修正したい場合は、settings.json に次を追加します。

{
  "editor.codeActionsOnSave": {
    "source.fixAll.textlint": "explicit"
  }
}

指摘が出ないときは、(1)プロジェクトに textlint がローカル導入されているか、(2)設定ファイルがワークスペースのルートにあるか、(3)出力パネルで「textlint」を選んでエラーが出ていないか、の順に確かめると原因を絞れます。Markdown編集を補助する拡張と併用するなら、Markdown All in Oneの使い方：ショートカット・目次・表整形と安全性の確認も参考になります。

コミット前チェック・GitHub Actions・MCPによる校正の自動化

エディタの指摘は書き手が見落とせば終わりです。検査を必ず通すには、コミットの時点かPRの時点で機械的に止めます。

huskyとlint-stagedによるコミット前検査

コミットの時点で止めるなら、Gitフックを管理する husky と、ステージしたファイルだけにコマンドを渡す lint-staged を組み合わせます。2026年11月8日時点の最新は husky 9.1.7、lint-staged 17.6.0 です。lint-staged 17.6.0 は package.json で Node.js 22.22.1 以上を要求しているので、textlint本体より要件が高い点に注意してください。

npm install --save-dev husky lint-staged
npx husky init
echo "npx lint-staged" > .husky/pre-commit

husky init は .husky/pre-commit を作り、package.json に "prepare": "husky" を足します。最初の中身は npm test なので、上のように書き換えます。続けて package.json に検査対象を書きます。

"lint-staged": {
  "*.md": "textlint"
}

この構成で、エラーを5件含むMarkdownをコミットすると、lint-stagedが変更を元に戻したうえで textlint の出力を表示し、husky - pre-commit script failed (code 1) でコミットが中止されました。git log にもコミットは増えていません。警告（warning）だけならtextlintは終了コード0を返すので、コミットは通ります。git commit --no-verify で回避できるため、コミット前チェックは書き手の手元の補助と考え、必ず止めたい検査はCIにも入れます。huskyの初期設定は公式の Get startedにまとまっています。コミットメッセージの検査もhuskyで足すなら、Conventional Commitsとは？形式・type一覧とcommitlint・semantic-releaseの設定【v1.0.0】が参考になります。

GitHub ActionsによるPRへの校正結果の注釈表示

PRで必ず検査するなら、CIに入れます。-f github を指定すると、GitHub Actionsのワークフローコマンド形式で出力され、PRの差分画面の該当行に注釈が付きます。file= には実行環境の絶対パスが入ります（下の例では先頭を省略）。

::warning file=…/docs/w.md,line=1,endLine=1,col=6,endColumn=7,title=TextLint [ja-technical-writing/ja-no-weak-phrase]::弱い表現: "かも" が使われています。 | 1:6

ワークフローの最小構成は次のとおりです。globは引用符で囲み、シェルでなくtextlintに展開させます。

name: textlint
on: pull_request
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx textlint -f github "docs/**/*.md"

actions/setup-node の入力とキャッシュの扱いはactions/setup-nodeとは｜v7.1の入力・キャッシュ設定とv4からの移行点で解説しています。大きなドキュメントリポジトリでは --cache を付けると、前回から変わったファイルだけを検査します（キャッシュは既定で .textlintcache に保存）。CIで使う場合は、キャッシュファイルをジョブ間で保存・復元したうえで、ファイルの内容で変更を判定する --cache-strategy content を指定します。既定の metadata（更新日時とサイズで判定）は、公式のCLIドキュメントでCIでは信頼できないとされています。文書の検査をビルドやデプロイの流れに組み込む設計から相談したい場合は、DevOps・CI/CD導入支援も参考にしてください。

MCPサーバー機能によるAIエージェントとの連携

v14.8.0（2025年6月9日）で、textlintをMCP（Model Context Protocol）サーバーとして起動する --mcp が実験的機能として追加されました。15.8.0で起動して tools/list を送ると、次の4つのツールが返りました。

• lintFile／lintText：ファイルまたは文字列を検査
• getLintFixedFileContent／getLintFixedTextContent：自動修正後の内容を返す

修正系のツールは修正後の内容を返すだけで、ファイルは書き換えません。v14.8.1で、AIエージェントがファイルを直接直すと誤解しないよう旧名の fixFile・fixText から改名された経緯があります。v15.2.0以降は --mcp --config .textlintrc.dev.json のように他のオプションと組み合わせられます。Claude CodeなどのMCPクライアントには、コマンド npx textlint --mcp を登録します。生成AIに書かせた下書きを、AI自身にtextlintで点検させて直させる使い方ができます。

textlintが効かない場面と導入判断

textlintが確実に拾えるのは、表記・文長・助詞の連続・用語の揺れなど、形で判定できる誤りです。本記事で設定したプリセットと用語集では、次の問題は検出対象外です。

• 事実の誤り（バージョン番号や手順が古い、数値が違う）
• 論理の飛躍や説明の順序の悪さ
• 読者に対して前提知識が足りない、あるいは冗長すぎる
• 用語集に無い新しい表記ゆれ

上の実行例でも「処理は高速です!」に対して指摘されたのは感嘆符だけで、「高速」の根拠が無いことは検出されていません。textlintは人のレビューを置き換えるものではなく、レビュアーが表記の指摘に時間を使わず、内容の確認に集中するための前処理として位置づけるのが妥当です。レビュー観点の整理はコードレビューとは？目的・観点・進め方と実装現場の運用設計を解説が参考になります。

導入を見送ってよいのは、文書が年に数本しか更新されない場合や、書き手が1人で表記ルールを自分で守れている場合です。ルールの選定と用語集の保守には継続的な手間がかかり、指摘が多すぎて無視されるようになると逆効果です。複数人がMarkdownで書き、PRでレビューする運用なら、CIで止める価値は十分あります。外部通信を行わないルール・プラグインを使い、ローカルで実行する構成なら、クラウド型の校正ツールを使えない現場でも導入候補になります。

よくある質問

textlint（テキストリント）とは何ですか？

文章をルールに沿って自動で点検するオープンソースのリンターです。読み方は「テキストリント」。ESLintの文章版にあたり、ルールやプリセットを追加して、ら抜き言葉・長すぎる文・表記ゆれなどを検出します。

textlintをVS Codeで使うにはどうすればよいですか？

プロジェクトにtextlintとルールをnpmでインストールし、.textlintrc.json を置いたうえで、拡張機能 3w36zj6.textlint を入れます。旧 taichi.vscode-textlint はアーカイブ済みなので使いません。

Wordの文書をtextlintで校正できますか？

.docxを直接読むプラグインは標準にありません。テキストやMarkdownに書き出してから検査します。Word上で完結させたい場合は、Word標準の「スペルチェックと文章校正」を使う方が手軽です。

社外に文章を送らずに校正できますか？

できます。textlint本体は手元のNode.jsで動き、本体が文章を外部サーバーへ送ることはありません。ただし、オフラインで使えるかは採用するルール・プラグインに依存します。閉じたネットワークでは、外部通信を必要としない構成を選び、必要なパッケージと辞書を事前に配置してください。

コミットする前にtextlintで自動チェックできますか？

できます。husky でpre-commitフックに npx lint-staged を登録し、lint-stagedの設定で "*.md": "textlint" を指定すると、ステージしたMarkdownにエラーがあればコミットが止まります。--no-verify で回避できるため、必ず止めたい場合はCIでも検査します。

特定の段落やファイルだけtextlintの対象から外せますか？

語やパターン単位なら textlint-filter-rule-allowlist の allow に書きます。段落単位なら textlint-filter-rule-comments を有効にして <!-- textlint-disable --> で検査を停止し、対象段落の後に <!-- textlint-enable --> を置いて再開します。コメントの前後には空行を入れます。ファイル単位なら .textlintignore にパスを書きます。

関連記事

• Markdown All in Oneの使い方：ショートカット・目次・表整形と安全性の確認
• Zenn CLIの使い方｜インストールから記事作成・GitHub連携での公開まで【0.5.13対応】
• ESLintをVSCodeで使う設定手順｜ESLint 10のflat configと保存時の自動修正【10.13対応】
• OxlintとESLintの違いとは？読み方・速度実測・移行手順とBiomeとの比較【1.88対応】
• Stylelintとは？v17の変更点・導入手順・設定とCSSネスト対応【17.16対応】