v0.6.0

採点の誤検出を減らし、どのルールにも対応していなかった判定を整理したリリースです。既存のルールIDの削除や意味の変更はありません。ルールを四つ足したため、前の版では出なかった指摘が出ることがあります。

追加

ら抜き言葉、接続詞の重なり、誤字、見えない文字のルール

これまで採点は、どのルールにも対応しない判定の指摘を、ルールIDのない形（rule_idがnull）で出していました。利用者は、その指摘を直すべきかをルール集から判断できませんでした。こうした判定を整理し、意味のあるものを四つのルールにしました。

• GRM-019 ら抜き言葉を使わない（「見れる」→「見られる」）。出典は、第20期国語審議会の審議経過報告です
• GRM-020 同じ接続詞を続けて使わない（「しかし、〜。しかし、〜」）
• NOT-036 誤字と入力の誤りを残さない（「をを」の重なり、IMEの打ち間違い、「適応」と「適用」の取り違え、閉じていない括弧）
• NOT-037 見えない文字と、分解された文字を使わない（ゼロ幅スペース、制御文字、濁点が分かれた仮名）

文体の違う人の文書で測る

誤検出を測る人の文書は、デジタル庁の政策ページだけで、行政の説明文に偏っていました。総務省の令和7年版情報通信白書と、国税庁のタックスアンサーの段落を足しました。node tests/corpus/report.mjsで、出典ごとの誤検出の数も出せます。

変更

• NOT-022とNOT-023：インラインのコード、リンク、「/」の前後のスペースと、片仮名の語の間の全角スペースも指摘するようにしました
• 判定を切ったもの：次の判定は、ほかのルールと逆の決まりだったり、同じ箇所を重ねて指摘したりしていたため、切りました
  • jtf-style/4.1.1（かぎ括弧の中の句点）：NOT-019と逆の決まり
  • jtf-style/4.1.3（和文の「.」）：jtf-style/1.2.1と重なる
  • jtf-style/1.1.5（図表のキャプション）：GRM-017の注記で、判定手段にしないと決めていた
  • max-comma（英文の「,」の数）：和文の読点の数はGRM-018で見る
• GRM-018：ルールの文言に「名詞を並べる読点は数えない」と書きました。判定の数え方に合わせたもので、指摘は変わりません
• AGENTS.md：IssueとPRの「人が書く要約」は、AIが埋めないと書きました

修正

• NOT-035（漢字を7字以上続けない）が、法令、会議、税の名前のような固有名詞を指摘していました。次の形を除くようにしました
  • かぎ括弧の中
  • 「第32次」の後ろ
  • 名前に付く語で終わるもの（「〜検討会」「〜法」「〜税」「〜機構」など）
  • evaluators/allowed-terms.jsonに書いた語。法令の用語（「給与所得控除」）などを書けます
  • デジタル庁の文書での誤検出は28件から6件に、タックスアンサーでは22件から0件に減りました
• NOT-006：常用漢字表の判定データで、「𠮟」「塡」「剝」「頰」の許容字体（「叱」「填」「剥」「頬」）が抜けていました。そのため、「補填」の「填」が表外の字として指摘されていました

測った結果は、対の文265組のうち262組の違反を見つけ、直した文での誤検出は1件です。人が書いた3つの出典188段落での誤検出は、14件です。

v0.5.0

文書種別を四つ足し、機械の採点の見逃しと誤検出を測って直したリリースです。既存のルールの意味を変えたものがあります。

ルールの意味の変更と移行

このリリースで意味が変わったルールは次のとおりです。前の版に合わせて書いた文書で、新しく指摘が出ることがあります。

ルール	変わったこと	移行の方法
NOT-010 送り仮名	本則の形だけでなく、許容の形（「売上」「手続」）も通すようにした。代わりに、一つの文書の中で同じ語の書き方が混ざると指摘する	文書の中で、同じ語の送り仮名をどちらかにそろえる
NOT-013 「万」「億」	「大きな数」を、1万以上の数と決めた	「12,000人」は「1万2,000人」と書く
NOT-011 外来語の長音	告示の用例集にない技術文書の語（「サーバー」「ユーザー」「フォルダー」など33語）も指摘する	語末の長音符号を付ける。語末が「リ」の語（「メモリ」）は対象外
MKD-001 見出し	見出しの末尾に閉じる「#」を付けないと明記した	## 見出し ##を## 見出しにする

ルールも二つ足しました。どちらも機械で判定します。

• GRM-018 一文の読点は3つまでにする
• NOT-035 漢字を7字以上続けない。法令や組織の名前のような固有名詞はそのまま書きます

追加

ハウツー、チュートリアル、リファレンス、解説の種別

手順書や仕様の説明を書く依頼には、目的の違う書き方が一つの文書に混ざりがちでした。Diátaxisの四つの区分に合わせて、ハウツー（how-to）、チュートリアル（tutorial）、リファレンス（reference）、解説（explanation）の種別を足しました。種別ごとに、必須セクションのスキーマとテンプレートがあります。

改善点をためてIssueにするdocs-rules-feedback

スキルを使っていて見つけた誤検出や、ルールでは直せない違反は、その場で報告に書くだけで消えていました。docs-rulesの報告に「改善点の候補」を書くようにし、docs-rules-feedbackのスキルで候補をためておけるようにしました。「改善点をIssueにして」と頼むと、ためた候補をまとめてIssueの下書きにします。claude.ai用のzipには入れていません。

変更

• 採点の速さ：score.mjsに複数の文書を一度に渡せるようにしました。textlintの起動が1回で済みます
• 判定の拡充：次の書き方も、機械で指摘するようにしました
  • 小数点に使った「,」（「1,5秒」）
  • 全角スペースと、読点の後ろのスペース
  • 全角の「；」
  • 「2026.10.23」「2026年05月07日」の形の日付
  • 0で埋めていない時刻（「2026-10-23 9:05」）
  • 空白だけの画像の代替テキスト
  • 「〜だろう」「〜と思われる」
  • 「ないとは言えない」
  • 箇条書の中の敬体の混在
  • 「十」を含む漢数字（「二十人」）
  • 「ゞ」「ヾ」の繰り返し符号
  • 送り仮名の活用した形（「終った」）
• ルールの文言：次のルールに、判断の境目を書き足しました
  • FW-002：「取組を行う」は「取り組む」と書く
  • NOT-008：題名と法令の引用は、元の表記のまま書く
  • GRM-002：本文につながった見出しも、文の長さに数える
  • GRM-003：短い語の列挙は、文の中に書いてよい
• 利用条件：README.mdの利用条件に、テストで使うデジタル庁の政策ページを足しました

修正

機械の採点を、ルールごとの違反した文と直した文の対245組と、デジタル庁の政策ページの99段落で測りました。見つかった誤検出を直しています。

• 「〜を行う」を、FW-002に加えてFW-001（「〜することができる」）でも重ねて指摘していた
• 文末の常体と敬体の混在で、「だ。」と「ください。」を数えていなかった
• 「表示が崩れる不具合が見つかった」のように、別々の述語に掛かる「が」を、助詞の連続として指摘していた
• 「生活に密接に関わる」の「密接に」の「に」を、助詞として数えていた
• 「2025 年度」のように、スペースを挟んだ年号に桁区切りを求めていた

測った結果は、node tests/corpus/report.mjsで表にして出せます。対の文では、245組のうち242組の違反を見つけます。直した文での誤検出は1件です。

v0.4.0

文書種別を三つ足したリリースです。既存のルールIDの削除や意味の変更はありません。

追加

学会論文と学位論文の種別

論文を書く依頼には、共通ルールしか当てられませんでした。そのため、論文に固有の構成や書き方は、利用者が毎回指示する必要がありました。学会論文（journal-paper）と学位論文（thesis）の種別を足しました。

• 必須セクション：要旨から参考文献までをそろえました。学位論文は目次から始まります
• 論文に固有の制約：「文書全体の制約」に書きました。対象は、常体にそろえること、本文で箇条書を使わないこと、図表の見出しの位置、数値と単位の書き方、参考文献の書き方です
• 「論文」とだけ言われたとき：学位の申請に使うと分かれば学位論文、そうでなければ学会論文として書きます

UI文言の種別

AIに画面を実装させると、タイトルや説明文が機能の説明になりがちで、利用者が何をできるかの視点で書かれませんでした。UI文言（ui-text）の種別を足し、画面と要素ごとに文言を並べた文言表を出せるようにしました。

• ルール：UI-001〜UI-013を足しました。エラー、空の状態、ボタン、プレースホルダー、文字数の上限、機能の説明の言い回しを扱います
• 要素ごとの文体と句点：ラベルとボタンは体言止めにし、メッセージは敬体にするなど、要素の種類ごとに決めました
• 機械の判定：score.mjsに--type ui-textを渡すと、文言表の一部のルールを機械で判定します。対象は、上限の字数、機能の説明の言い回し、汎用のエラーの文言などです。問いの形のラベルに付けた「？」は、違反にしません

変更

• 採点：score.mjsは、--typeを渡すと、その種別のスキーマに書いたルールも読むようになりました。種別ごとの判定はevaluators/schema-checks/に置きます
• AI評価：「文書全体の制約」も評価し、種別ごとの例外に従うようにしました
• MKD-010の出典：デジタル庁デザインシステムを加えました。ルールの意味は変わっていません
• 利用条件：README.mdの利用条件の表に、デジタル庁デザインシステムとGOV.UK（Open Government Licence v3.0）を足しました

v0.3.0

採点の誤検出と、claude.aiで使うときの不具合を直したリリースです。ルールの追加と、ルールIDの削除や意味の変更はありません。

追加

claude.ai用のzipをリリースに添付

claude.aiでスキルを使うには、リポジトリからzipを手で作ってアップロードする必要がありました。このリリースから、docs-rules-v0.3.0.zipを添付します。リリースのページからzipを取得し、そのままアップロードできます。

機械で判定しない部分を採点結果に表示

一部だけ機械で判定するルールは、機械で判定しない部分があっても、採点結果では合格に見えていました（文末の「した」と「しました」の混在など）。採点結果のskipped_rulesに、機械で判定しない部分と、その部分をAI評価で扱うことを出すようにしました。「いる」「なる」の仮名書きや、見出しどうしの文体のように、機械とAIのどちらも判定していなかった部分も、AI評価に回しました。

論文とUI文言の調査結果

論文とWebの画面の文言を、文書種別に足す準備をしました。一次資料の採否とルールの候補を、references/paper-sources.mdとreferences/ui-text-sources.mdに書いています。文書種別とルールはまだ足していません。

変更

採点のコマンドの書き方

SKILL.mdの採点のコマンドは、スキルのディレクトリに移ってから実行する前提でした。利用者のプロジェクトで作業しているときに、score.mjsが見つからずに失敗することがありました。コマンドをスキルのディレクトリの絶対パスで書く形に変え、どこからでも実行できるようにしました。

修正

• claude.aiにzipでアップロードすると、採点の設定ファイル（.textlintrc.jsonと.markdownlint-cli2.jsonc）が落ち、採点が設定なしで動いていました。設定ファイルの名前を「.」で始まらない名前に変えました
• 電話番号の「09012345678」を「90億1,234万5,678」に直すなど、番号を数量として直す候補を返していました。0で始まる数と、「番号」「〒」などの後ろの数は直さないようにしました
• 文書のパスにディレクトリを渡すと、例外で落ちて「違反あり」と同じ終了コードになっていました。値のない--typeは、エラーにならないまま照合が飛んでいました。どちらも引数の誤り（終了コード2）として扱います
• 字下げしたコードブロックの中の<!--を、消し忘れた案内のコメントとして指摘していました
• 採点の部品の古い版を消す処理が、並行して動いている別の版のスキルの部品を消すおそれがありました。7日より長く使っていない版だけを消すようにしました

v0.2.0

採点の部品の入れ方を変え、利用者の手元で動くコードの安全性を上げたリリースです。ルールと文書種別はv0.1.0から変わっていません。

変更

採点の部品を、固定した版で入れてから動かすようにしました

v0.1.0の採点（evaluators/score.mjs）は、textlintとmarkdownlint-cli2をnpxで取得していました。この方法では、直接の版は固定できても、依存の依存は取得した時点の最新の版になります。依存のどれかが乗っ取られた版を出していると、それがスキルを使った人の手元で動く危険がありました。

v0.2.0では、package-lock.jsonで依存の依存まで版を固定し、初回の採点でnpm ciを使って入れます。インストール時のスクリプトは動かしません。入れる場所は利用者のキャッシュで、macOSでは~/Library/Caches/docs-rulesです。ほかのOSの場所と、場所の変え方は、evaluators/README.mdの「パッケージの入れ方」を参照してください。

• 採点にはNode.js 18以上に加えてnpmが要ります。ない環境では、これまでどおり機械の採点を飛ばし、AIの点検だけで仕上げます
• 2回目からは入れたものを使うため、npxのときより速く動きます
• ロックファイルが変わると、自動で入れ直します

リポジトリの開発の仕組み

• PRとmainへのpushで、テストとプラグインの検証をGitHub Actionsで動かすようにしました
• GitHub Actionsのアクションを、タグではなくコミットのSHAで固定しました
• Dependabotで、採点の部品とアクションの版、既知の脆弱性を確かめるようにしました
• リポジトリ自身の文書を採点するテストで、誤検出を外す条件を狭め、外しすぎていないことを確かめるテストを足しました

修正

• Windowsで、文書のファイル名に「&」などの記号が含まれていると、その後ろがコマンドとして動く問題を直しました。採点の部品をシェルを通さずに起動します
• README.mdの手動配置の手順に、~/.claude/skills/を作る1行を足しました

v0.1.0

最初のリリースです。1.0.0までは、マイナーの変更にもルールIDの削除や意味の変更を含めることがあります（README.mdの「バージョン管理」）。

追加

日本語の文書を共通のルールで書くスキル

Claude Codeに日本語の文書を頼むと、表記や文体が文書ごとに揺れ、そのたびに人の手で直していました。docs-rulesを入れると、Claude Codeは書く前に共通のルールと文書種別ごとの構成を読み、それに沿って書きます。

ルールは87件あり、禁止語、文法、表記、構成、Markdown記法、アクセシビリティにわたります。どのルールにも出典を付けています。主な出典は『公用文作成の考え方』（文化審議会建議）、『JTF日本語標準スタイルガイド』第4.0版、常用漢字表などの内閣告示です。

文書種別：セッションログと提案書

文書の種類によって、書くべき項目と順序は違います。セッションログ（session-log）と提案書（proposal）は、必須セクションと見出しの型を決めてあり、書き漏れを防げます。どちらにも当たらない文書には、共通のルールだけを当てます。

書いた後の点検と書き直し

ルールを読んで書いても、守れていない箇所は残ります。書き終えた文書は、次の順に点検してから出します。

• 機械で判定できる47件のルールは、evaluators/score.mjsが採点します（textlintとmarkdownlintを使います）
• 文脈を読まないと判定できないルールと、文書種別ごとの書き方は、AIが決まった手順で評価します
• 見つかった違反は該当箇所だけを書き直し、最大3回まで繰り返します。直せなかった違反は、文書とは別に報告します

Node.jsがない環境でも、機械の採点を飛ばしてAIの評価だけで使えます。

インストール

入れ方は3通りあります。

• ~/.claude/skills/への手動での配置
• npx skills add knk1313/docs-rules
• Claude Codeのプラグイン（/plugin install docs-rules@docs-rules）

手順はREADME.mdの「インストール」を参照してください。