yomiyasu v2.5.0 を公開しました。
lint の直訳語の型1が、定着した言い方に副詞が挟まった文（「テストがまだ通らない」）に出していた誤った指摘を直し、比喩の「効く」の見落としを減らしたバージョンです。
AI の文章によく出る言い回しを見つける規則 ai_phrase と、直訳語の句を足しました。
diff と check には、見出しの形の変化と消えた見出し、読点が増えた推敲を示す節を足しました。
推敲の手順にはコードを説明する文書の擬人化、否定で終わる定義文、漢語の名詞で動作を省いた文、依頼で指定された見出しの形とまとめ、読点を足さない決まりを足しています。
SKILL.md には付属の lint と check の呼び出しだけを許す allowed-tools を入れました。

背景と課題

v2.4.0 の公開のあとに、いくつかの報告と提案をいただきました。

• 技術文書をコードから書かせると、比喩や擬人化が混ざるという感想。「この関数は、呼び出し元の事情を知っています」のような文の擬人化に、lint は何も出していませんでした。
• 直訳語の型1が、「テストが通る」「キャッシュが効く」のような定着した言い方に副詞が挟まると、指摘を出していたこと。
• 比喩の「効く」が、前の行にキャッシュや最適化の語があるだけで見落とされていたこと。
• AI の文章によく出る言い回しの候補（「〜という見立てです」「〜に潜むリスク」「今や〜に欠かせない存在」など）。
• yomiyasu をほかの方法と比べた記事の3点。依頼で見出しの形とまとめを指定しても推敲が直してしまうこと、python3 がない環境で手順のコマンドが動かないこと、承認する人がいない実行で check が許可の確認に止まることです。
• AI の謎な説明文の直し方を書いた記事にある、否定で終わる定義文と、漢語の名詞で動作を省いた文の直し方。

もう1つ、僕自身から、AI の出力と yomiyasu の出力で読点が多すぎるという指摘をしました。人の文章と AI の生成文を比べた測りでは、読点の数より位置に違いがあり、短い主題や主語のあと（約1.7倍）と、短い目的語の「を、」のあと（約3.4倍）に AI の読点が多く出ていました。

v2.5.0 で変わったこと

lint: 誤った指摘と見落とし

• 定着した言い方の助詞と動詞の間に入れてよい副詞を、どの主語の語でも同じ一覧（すべて、まだ、もう、ちゃんと、なかなか、問題なく など20語）にしました。「テストがまだ通らない」「CIがすべて通っている」「キャッシュがちゃんと効いていません」に指摘が出なくなります。機械が主語の型1（「取りこぼした通知は、翌朝の再送ジョブが拾います。」）は残ります。
• 比喩の「効く」の判定で、近くの行のキャッシュや最適化のような語を、文字どおりの効き目の語に数えなくしました。「キャッシュを入れました。ここで効いてくるのが、型の考え方です。」に指摘が出ます。「キャッシュが効いてくると速くなります」のように主語の位置にあるときは、今までどおり出しません。

lint: AI の文章によく出る言い回し

規則 ai_phrase を足しました。指摘は info で、点数、--strict、--fail-on には入りません。当てるのは7つの形で、どれも何が足りない文か（判断した人、潜むものの中身、何が起きるか）を確かめるための指摘です。

• 文末の「〜という見立てです」（同じ文に判断した人がいないとき）
• 「〜に潜むリスク」「問題が潜む」（潜むものがリスク、問題、罠、落とし穴、危険、本質、バグなどのとき）
• 「〜が招く＋名詞」（油断が招く失敗）
• 「今や〜に欠かせない存在」と「欠かせない存在となっています」「欠かせない存在となりつつあります」
• 「〜という挙動を排除する」
• 地の文の文末の「なんよ」
• 「〜して、〜を＋漢語の名詞。」で終わる文（設定を見直して、速度を改善。）

直訳語の型3には「ここで効いてくるのが」「リポジトリレベルの」「その案はテーブルの上にあります」の句を足しました。言い回しごとの確かめる問いは、references/slop-catalog.md の10章にあります。

diff と check: 見出しと読点

• 「見出しの数が変わった」の候補に、消えた見出しの文字（「消えた見出し: まとめ」）を足しました。
• 節「■ 見出しの形が変わった」を足しました。元の見出しが句点で終わる、読点を含む、15字を超えるのどれかで、推敲で書き換えた見出しの元と後を並べます。check は、依頼の文に「見出し」「まとめ」「字数」のような語があるとき、この節を先に出します。
• 節「■ 読点が増えた」を足しました。最終稿の地の文の読点が原文より3個以上多く、1文あたりの読点が0.3個以上増えたときに、読点が増えた文を元の文と並べて示します。
• どちらの節も、意味が変わる恐れの件数と --fail-on の終了コードには入りません。

lint と推敲: 読点

• pause_comma（--doc-type を指定したとき）に、短い目的語の「を、」（設定を、変更したときに）を足しました。並べ、長い目的語、節の目的語、引用、読み物（essay）には出しません。
• 主題のあとに動詞の「〜て」と連体の形の述語、名詞が続き、その名詞を目的語に取る形の読点（「店長は、慌てて逃げた客を追いかけた。」）は、外すと掛かり先が変わるので出さなくなりました。
• SKILL.md に、推敲で文をつないだり言い換えたりして新しく読点を置くのは、残す読点の所だけにする段落と、提出の前に読点の数を原文と比べる手順を足しました。

推敲の手順

• コードやシステムを説明する文書では、働きを受け取るもの、返すもの、呼ぶもので書きます。人の知識や会話、役目にたとえた言い方（知っている、語る、門番、交通整理）は、コードや資料から動作が分かるときだけ書き直し、分からなければ残して尋ねます。設計の用語（責務を持つ、依存する、委譲する など）は残します。
• 「〜ではありません」で終わる定義文は、何であるかを先に書き、誤解を防ぐ否定はそのあとに残します。「分離」「保証」「管理」のような漢語の名詞だけで誰が何をするかを済ませている文は、資料から動作が分かるときだけ、その動作の文にします。どちらも、材料がなければ本文を残して尋ねます。
• 依頼で見出しの形（長さ、言い切り、番号、記号）や、まとめの節・ページを指定されているときは、その形と節を保ちます。
• 初心者向けの口調（子ども向けの語尾や励ましの決まり文句を足さない）と、本文への測定値の詰め込み（表か箇条書きに分けるかを確かめる）の決まりを references に足しました。

スキルの設定と実行するコマンド

• SKILL.md の frontmatter に allowed-tools を入れました。許すのは、付属の lint と check を python3、python、py -3 で呼ぶ6つのルールだけです。Claude Code の文書の説明では、yomiyasu を呼んだターンのあいだ、この呼び出しが確認なしで動きます。
• 検査のスクリプトは python3、python、py -3 の順に試します。どれも動かなければ、目視で点検して not_run reason=no_python と書きます。Windows では py -3 scripts/... で実行してください。

確かめたこと

• 人のニュース記事（livedoor ニュースコーパス、約900万字）で、ai_phrase は32件（「〜して、〜を実施。」の形24件、「〜に潜むリスク」の形7件、「欠かせない存在」1件）、直訳語の新しい句は0件でした。人の記事にもこの形はあるので、指摘は info にとどめています。短い目的語の「を、」の行は、人の記事で1万文あたり0.36行、手元の AI の文章（3つを合わせて約1万文）で4.04行でした。行の数が少ないので、この比は目安です。tests/corpus/human の16本は、種類なしと13の種類のどれでも、lint の指摘が v2.4.0 と同じでした。
• 合成のスライドと記事で、消えた見出し「まとめ」と、形が変わった3か所の見出しが出ました。意味が変わる恐れの件数と終了コードは v2.4.0 と同じでした。tests/corpus の142組で v2.4.0 と比べると、diff の終了コードと状態の行、check の終了コード、1行目、記録の meaning_risk= は、どの組も変わりませんでした。人が読む diff の出力が変わった87組は、どれも新しい節か消えた見出しの文字によるものでした。
• 変えた決まりに当たる合成の下書き6本を、v2.4.0 と v2.5.0 で2回ずつ推敲しました（Claude Code、Claude Opus 5.5）。v2.5.0 は確かめ役の指摘で SKILL.md を直す前と後で2回ずつ推敲しています。依頼した見出しの形とまとめは、どの回も保ちました。コードの擬人化の下書きでは、v2.5.0 はどの回もコードにある動作だけで書き直し、コードにない「門番」は残しました（v2.4.0 は1回書き換えました）。漢語の名詞の下書きで「到達保証ではありません」の意味を狭めて書いた回は、v2.4.0 で2回のうち1回、v2.5.0 で4回のうち1回でした。読点の多い下書き（地の文の読点22個）は、v2.4.0 で6個と8個、v2.5.0 でどの回も8個でした。回数が少ないので、差は傾向として読んでください。
• macOS の Claude Code で、Bash の許可のルールを渡さない claude -p に推敲させると、v2.4.0 は lint の呼び出しが断られて検査が動かず、v2.5.0 は python3 で呼んだファイルを使う形の lint、check の run と verify が断られずに動きました。python のルール、標準入力の形（heredoc）、対話の画面、プラグインで入れたとき、Windows（py -3 と Git Bash）、スキルのフォルダのパスに空白がある環境では確かめていません。Codex（codex-cli 0.164.0）は v2.5.0 の frontmatter を読んで、スキルを一覧に載せました。README の npx skills add の手順で PR のブランチから入れると、Claude Code と Codex のどちらにも v2.5.0 が入り、どちらもスキルを読み込みました。
• 試験一式は macOS の Python 3.14.5 と 3.9.6 で通ります。

v2.4.0 から使っていただいている方へ

推敲の結果と、lint、diff、check の出力が変わります。lint には ai_phrase（info）と直訳語の新しい句（info）の指摘が加わり、--doc-type を指定したときは短い目的語の「を、」の pause_comma（info）が加わります。比喩の「効く」の metaphor_verb（warn）はキャッシュや最適化の語の近くでも出るようになったので、--strict と --fail-on warn の終了コードが変わる文書があります。
rule_penalty_score の計算は変えていませんが、指摘が変わるので点数も変わります。metaphor_verb と、--doc-type を指定したときの短い目的語の「を、」の pause_comma は点数に入るので、点数が下がる文書があります（--doc-type slides では、本文と箇条の行で slide_comma に出ていた「を、」が pause_comma に出ます。見出しの「を、」は今までどおり点数に入らない slide_comma に出ます）。店長の形の読点の候補が出なくなった文書では、点数が上がることがあります。
diff の JSON（check の run の --json の出力と、記録に残る diff の JSON も）の最後に heading_shapes と comma_increase のキーが加わり、structure[] の「見出しの数が変わった」の文に消えた見出しの文字が付くことがあります。lint の JSON の context.words.allow_removed には ai_phrase のキーが加わります。JSON のほかのキーと値の種類、*_FORMAT_VERSION は変えていません。check の run の出力には見出しの形と読点の増加の2つの節と、冒頭の一覧の行が加わります。規則に当たる候補がなく、この2つの節があるときは、1行目の文も変わります。--material の資料に見出しや字数の語があるときは、節の順も変わります。
文章を貼って推敲を頼んだときも、原文と最終稿をファイルに保存してから検査します（v2.4.0 は、返答だけで渡すときは標準入力で検査していました）。ファイルを残したくないときは、保存しないよう頼んでください。
v2.4.0 で残した検査の記録を v2.5.0 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。
変更の細部は CHANGELOG.md にあります。

yomiyasu v2.4.0 を公開しました。
英語の短い術語に漢字1字を当てた名詞（「今回の版」「一覧の頭」「lint の印」）を、lint が直訳語として見つけ、推敲で分野の呼び名（バージョン、先頭、指摘）に直すバージョンです。
diff と check には、原文にない人や担当を主語や知らせる相手に足した文を示す節を足しました。
スライドの見出しと1行の箇条では、間を作るだけの読点を lint が指摘し、推敲で外します。
yomiyasu 自身の文書とスクリプトのコメントも、このバージョンの lint にかけて直しています。

背景と課題

v2.3.0 の論文を教えてくださった方から、yomiyasu を通す前の Claude の文章で、英語の短い術語に漢字1字を当ててそのまま名詞に使う傾向が見えるという分析をいただきました。
version に「版」、head に「頭」、mark に「印」を当てるような使い方です。

v2.3.0 で、この形を含む合成の下書き10本を3回ずつ推敲すると、「段」「窓」「帯」「床」は直りました。「口」「門」「旗」「系」「組」は、何を指すかを書き手に尋ねました。
一方で、「版」（lint の指摘が出ない形）、「印」、「頭」は、のべ45か所のうち19か所を、直しも尋ねもせずに残しました。

もう1つ、v2.3.0 を読んだ方から、品質保証の観点の意見をいただきました。
原文にない担当者や通知先を足した推敲を拾う検査がないこと、規則ごとの改善とは別に文書全体の意味と読みやすさを比べる評価が要ること、README の Codex 向けの入れ方が利用者のフォルダを確かめずに消すことの3点です。
v2.4.0 では、この3点にも手を入れました。

最後に、作者が登壇のスライドの見出しを --doc-type slides で推敲したところ、推敲の前の見出しの読点13個のうち12個が残りました。
yomiyasu は読点を役目（条件、逆接、文頭のつなぎ、場面）ごとに見るので、地の文なら残す読点を、一目で読む見出しでも残していました。手で外すと12個は5個になり、diff の意味が変わる恐れは0件でした。

v2.4.0 で変わったこと

lint: 直訳語の型4

lint の直訳語（calque）に、型4「英語の短い術語に当てた漢字1字の名詞」を足しました。指摘は info なので、終了コードと点数は変わりません。当てるのは次の3語です。

• 「版」: 「今回の版」「直した版」「Python の版」「短い版」「版ごと」のように version の意味で名詞に使う形。「第2版」「吹き替え版」「Mac 版」のような出版物や製品の種類には当てません。
• 「印」: 「lint の印」「推量の印」「行に印をつける」のように、検査や推敲の文で使う形。×印、目印、「印を押す」には当てません。
• 「頭」: 「一覧の頭」「出力の頭」「PR の頭」のような先頭や HEAD の意味の形。「頭が痛い」「曲の頭」には当てません。

ほかの12語（段、窓、帯、系、口、床、穴、枠、箱、旗、門、組）には当てません。v2.3.0 の推敲が直しているか、何を指すかを尋ねているか、人の文章でも定着した使い方が多い語です。

推敲の手順（SKILL.md と references/calques.md）には、型4の語をその分野で定着した呼び名で書くこと、何を指すかが決まらなければ本文を残して尋ねることを足しました。

diff と check: 原文にない人や担当を足した文

書き直した文で、原文にない人や担当（担当者、管理者のような役割の語、部署やチームの語、「〜さん」「〜様」の形の名前、人称の語）を、主語か、知らせる・頼む相手に足した所を、新しい節「■ 原文にない人や担当を足した文」に並べます。

■ 原文にない人や担当を足した文（1件。原文、資料、依頼のどれにもない人や担当なら、原文の書き方に戻す）
- 知らせる・頼む相手に「保守担当者」を足しました（1行目）
  元: 容量が一割を切ったら知らせる。
  後: 容量が一割を切ったら、保守担当者に知らせる。

この節は、意味が変わる恐れの件数と --fail-on の終了コードには入りません。diff の --json には added_actors のキーが加わります。diff に --material を足し、資料にいる人や担当は出さないようにしました。check の run も同じ節を出します。

lint と推敲: スライドの見出しの読点

--doc-type slides のときだけ、見出しと1行の箇条で間を作るだけの読点に、lint が info の指摘（slide_comma）を出します。推敲の手順（references/doc-types/slides.md）にも、外す読点と残す読点を書きました。

• 外す: 文頭のつなぎの語のあと（だから、そこで、結局）、「振り返れば」「数字で言えば」のあと、文頭の長い時や場面の句のあと（その日のうちに）、短い主題や主語のあと（新しい手順では、大事なのは）、目的語の「を」のあと。
• 残す: 逆接（のに、ても、けれども）、条件（なら、たら、〜ときは）、理由や目的（ので、ために、ためには）、名詞の並び、「その夜、」のような短い時の句、主題のあとに別の主語が続く所（会議では、担当者が）、長い行の「〜ではなく、」、外すと読み違える所。

## だから、引き継ぎの資料を先に作った   →  ## だから引き継ぎの資料を先に作った
- その日のうちに、手順書を書き直した   →  - その日のうちに手順書を書き直した
- 急ぎなら、電話で連絡する             →  （残す）

指摘は点数と終了コードに入りません。ほかの種類では出しません。

出力の言葉と、yomiyasu 自身の文章

lint、diff、check の出力の言葉をそろえました。主なものは次のとおりです。

• 「文の種類の印」→「文の種類を表す語」
• 「引用の印」→「引用の書き方」
• 「概数・範囲の印」→「概数・範囲を表す語」
• 「残した印の語」→「残した指摘の語」
• 「見出しの段」→「見出しのレベル」

yomiyasu 自身の文書（SKILL.md、references、README、docs）の型4の語も言い換えました。「印」126か所、「頭」29か所、「版」35か所、「段」7か所です。
そのあと、このバージョンの lint を自分の文書とスクリプトのコメントにかけ、出た指摘を直してまたかける、を新しい指摘が出なくなるまでくり返しました。指摘は482件から284件になりました。残した指摘は、規則の例として引いた語や、決まりの文として正しい言い方で、1件ずつ理由を記録しています。

README の入れ方

Codex 向けの入れ方を、前のフォルダを消さずに .agents/skills の外へ移してから置き換え、取り出しに失敗したら止まる手順にしました。README の手順の文字列をそのまま一時フォルダで動かす試験も足しました。

数字で見る v2.4.0

漢字1字の直訳語を含む合成の下書き10本と実際の下書き2本を、Claude Code（Claude Opus 5.5）で3回ずつ推敲した結果です。

受入評価として、作者が書いていない業務の依頼16本から素の Claude に書かせた下書き16本を、候補を作る前に封をして使いました。
この16本をスキルなし（1回）、v2.3.0（3回）、v2.4.0（3回）で推敲し、どれがどの推敲かを伏せて、Claude Opus 5.5 と Gemini 4 Argon の2つの判定役が原文と読み比べました。

v2.3.0 と v2.4.0 の差は、同じバージョンでも回ごとに動く幅と同じくらいでした。2つを並べて読んだときに v2.4.0 を上にした数は、48組のうち25組（Claude）と27組（Gemini）です。

スライドの読点は、素の Claude に書かせたスライドの下書き12本を、決まりを足す前と後で3回ずつ推敲して比べました。前と後のどちらかを伏せて、Claude Opus 5.5 の判定役にも読み比べてもらっています。

前の diff の意味が変わる恐れ10件は、どれも下書きの前後に付いた依頼者あての注記を推敲で外したもので、スライドの本文では前も後も0件です。v2.4.0 では、この注記を推敲せずに残します。判定役が残すべきとした読点を外した5か所は、外すと掛かり先が変わって読める「既存コードには、触った箇所だけに…」の1文（3回とも）と、「大事なのは、〜より〜」の1文（2回）でした。

測りは5回くり返しました。主題のあとに別の主語が続く読点を推敲が外したこと、残す読点に lint の指摘が出たこと、入れ子の箇条などに指摘が出なかったこと、注記を外していたことを、その都度直してから、最後の木で測り直しています。

確かめたこと

• lint の型4は、人のニュース記事（livedoor ニュースコーパス、約900万字）と tests/corpus の163本で0件でした。Claude に素で書かせた48本では4件で、どれも文書の別の稿（「短い版」「管理職向けの版」など）を指す「版」でした。
• スライドの読点の指摘は、自作の文で、外す読点のある見出しと箇条30行のすべてに出て（短い主語や主題のあとは pause_comma と分け合う）、残す読点のある43行には出ませんでした。作者が登壇の見出しから手で読点を外した例では、外した7行のすべてに出て、外したあとの見出しには出ませんでした。
• 原文にない人や担当の節は、tests/corpus の古い推敲の48組で、2つ以上のモデルが意味が変わったとした、担当者を足した19か所のすべてを示しました。v2.1.3 から v2.4.0 の推敲の出力1,046本では、候補は0本でした。
• v2.3.0 と v2.4.0 の lint、diff、check を同じ4,939件の入力で動かし、終了コードはすべて同じでした。出力が違った1,633件は、どれも上の変更（型4の指摘、スライドの読点の指摘、新しい節と added_actors、出力の言葉）で説明がつきました。Python 3.14.5 と 3.9.6 の出力は4,939件すべて同じです。
• 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,350件ずつ通ります。

v2.3.0 から使っていただいている方へ

推敲の結果と、lint、diff、check の出力が変わります。--doc-type slides の lint には slide_comma（info）の指摘が加わります。lint の終了コード、--strict と --fail-on の判定、rule_penalty_score は変わりません。
diff と check の人が読む出力の言葉が変わり、diff の JSON に added_actors のキーが加わります。JSON のキー、rule、kind、subkind の値と *_FORMAT_VERSION は変えていません。値の文が変わるのは、lint の findings[].message（bold_not_rendered と say_hedge）、diff の structure[]、check の checks[].error と verify の problems[].detail です。
v2.3.0 で残した検査の記録を v2.4.0 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。
変更の細部は CHANGELOG.md にあります。

yomiyasu v2.3.0 を公開しました。
「結果の確かめ」「二つの案の比べ」のように、他動詞を1語だけ名詞にした語を「の」で受ける形に lint が印をつけ、推敲で「結果を確かめる」や「結果の確認」の形に直すバージョンです。
あわせて、同じ段落を120回、240回とつないだ文書と、段落ごとに少し変えた写しをつないだ文書で、diff を v2.2.2 よりもう少し速くしました（30回、60回ではほとんど変わりません）。diff の出力は、版の文字列（tool_version と --version）のほかは変わりません。
v2.1.3 からお使いの方に向けて、v2.2.0 から v2.3.0 までで変わったことを「v2.1.3 からの変化」の節にまとめました。

背景と課題

yomiyasu を使っている方から、日本語の連用形名詞についての研究を教えていただきました（蔡盛植「日本語動詞連用形への構文論的アプローチ —『動詞連用形』と『連用形名詞』との相関関係を中心に—」日本研究 第21集、2014）。
他動詞の連用形を1語だけ名詞にした語（確かめる→確かめ）は、名詞としての自立性が弱く、目的語を「の」で受ける形（「結果の確かめ」）では使いにくい、という研究です。
名詞とくっつけた複合語（資金集め）、複合動詞から来た語（見直し）、漢語の名詞（確認）、「お」を付けた形（お選び）、意味が変わって定着した語（詰めが甘い）は成り立ちます。

測ってみると、この形はふつうの Claude の文章にはほとんど出ませんでした。
出るのは、漢語を避けて和語で書こうとした文です。
yomiyasu 自身の SKILL.md、references、README、docs にも、「の直し」「の確かめ」のような形が51行ありました。

人の記事でも、答え、備え、教え、問い、調べのように名詞として定着した語は、「の」のあとにふつうに出てきます。
v2.2.2 は、この形を直さないことがありました。
この形を含む合成の文書5本を v2.2.2 で3回ずつ推敲すると、狙う形のべ66か所のうち2か所（どちらも「〜の直し」）がそのまま残りました。

v2.3.0 で変わったこと

lint の新しい印 renyo_noun

references/lists/renyo-nouns.txt の48語（確かめ、直し、比べ、測り、補い、決め、選び、集め、そろえ、外し、伏せ など）が「の」のすぐあとに来て、そのあとに助詞か句読点か閉じ括弧か行の終わりが続く所に、1行に1件の印（info）をつけます。
message には当たった言い方（「の確かめ」など）を出し、置き換え先の語は出しません。

次のものには印をつけません。

• 名詞とくっつけた複合語（資金集め、手直し）、複合動詞から来た語（見直し、組み合わせ、洗い出し）、「お」「ご」を付けた形（お選び）
• 動詞に続く形（入れやすい、確かめにくい、決めがたい）と、「生活の足しになる」「試しに」の「に」
• 別の意味で名詞として定着した語（住民票の写し、合格の知らせ、詰めが甘い、法律の定め、警察の調べ、キッチン用の計り など。一覧に入れていません）
• 前に「の」がない形（確かめの道具）と、語のあとに「か」「だ」が続く形（「結果の確かめか」「案の比べだ」）
• カギ括弧と引用符の中、引用、コード、HTML の行、英数字の識別子

印は info なので、lint の終了コード、--strict と --fail-on の判定、rule_penalty_score は変わりません。
プロジェクトで定着している語は、語の一覧の allow.txt に語だけ（確かめ）を書くと外れます。

推敲の手順

SKILL.md「主語と目的語の明確化」に1段落を足しました。
この形は、目的語と動詞の文に戻すか（結果を確かめる）、定着した漢語の名詞にします（結果の確認）。
ほかの和語の連用形名詞に替えるだけでは済ませません。
漢語を和語にひらくときも、この形を作りません。
漢語の名詞に直した所は、diff の「文体の硬化」の候補に出ても戻しません。

SKILL.md、references、README、docs の文からも、この形を直しました。
返答の欄の名前「事実の確かめ」は、出力の形を変えないために残しています。
SKILL.md は 42,982字から 43,378字になりました。既存の規則と見出しは削っていません。

同じ段落を繰り返す長い文書の diff をもう少し速く

推敲の前後で消えた文を、書き直したあとの文と組にする処理を速くしました。
同じ段落を何十回も繰り返す文書では、同じ文が何度も消えます。
v2.2.2 までは、消えた文ごとに書き直したあとの文との近さを数え直していましたが、v2.3.0 では、同じ文（2文字の組の集合が同じ文）については1回だけ数えて使い回します。
組の候補はあとで近さの順に並べ直すので、diff の出力は、tool_version と --version の版のほかは v2.2.2 と1字も変わりません。

数字で見る v2.3.0

推敲の結果です。Claude Code（Claude Opus 5.5）で推敲し、どちらの版かを伏せて、2つの判定役（Claude Opus 5.5）が読み比べました。表の v2.3.0 の数は、開発の途中の候補で測ったものです（合成の5本は最初の候補、開かずにおいた1本は2つ目の候補。最後の版で確かめたことは「確かめたこと」に書きました）。

v2.2.2 も、この形の多くを直していました。v2.3.0 では、残っていた所も直し、残すべき形を誤って直すことが減りました。

diff と check run の時間です（Python 3.14.5、ほかの処理も動いている同じ Mac で、v2.2.2 と v2.3.0 を交互に3回ずつ動かした中央値です）。

繰り返しのない文書の時間は、ほとんど変わりません。

確かめたこと

• 人のニュース記事（livedoor ニュースコーパス、約900万字）、Claude に素で書かせた48本、tests/corpus の163本で、lint の印は0件でした。合成の文84文では、狙う形43文のすべてに印がつき、残す形41文には1件もつきませんでした。
• v2.2.0 と v2.2.1 で確かめたときに使った5本（直訳語の文書4本と tests/corpus の1本）を4回ずつ推敲し、どちらの版かを伏せて読み比べました。直訳語の40か所（4回でのべ160か所）のうち、直したか書き手に尋ねた所は、1つ目の判定で145か所から148か所、2つ目で145か所から146か所でした。残すべき形を誤って直した所は、両方の版で0か所です。意味が変わった所は、1つ目の判定で10か所から11か所、2つ目で8か所から10か所でした。同じ版でも2回ずつの組で数が動き（1つ目の判定で、v2.2.2 は4か所と6か所、v2.3.0 は6か所と5か所）、どちらの版にも同じ種類の変化が出ているので、この差は回ごとの揺れの中にあると見ています。
• 上の推敲は、開発の途中の候補で行いました。そのあと印のつけ方の細部と、SKILL.md と references の文を直したので、最後の版でも合成の文書6本を1回ずつ推敲しました。印のついた19行（当たった言い方は28か所）はすべて書き直され、残すべき形20のうち2つが複合語になりました（境界の値→境界値、接続の上限→接続数の上限。境界値は v2.2.2 の推敲にも出ています）。この回は判定役に読ませず、lint と文字列の照合だけで確かめました。
• v2.2.2 と v2.3.0 の lint、diff、check を同じ4,939件の入力（同じ段落を繰り返す文書を含む）で動かし、版の文字列をそろえて比べました。Python 3.14.5 と 3.9.6 のどちらでも、diff の出力はすべて同じでした。違ったのは check の66件と lint の4件で、どれも新しい印と、件数の行だけの違いです。
• 実際のモデルの推敲など1,415組でも、diff の出力はすべて同じでした。lint の JSON が違った22組は、新しい印と info の件数だけが違いました。
• 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,305件ずつ通ります。

v2.1.3 からの変化

v2.1.3 のあと、v2.2.0、v2.2.1、v2.2.2、v2.3.0 の4つの版を出しました。v2.1.3 と v2.3.0 を並べると、次のとおりです。

時間は、上の「数字で見る v2.3.0」の表とは別の回に、v2.1.3 と v2.3.0 を Python 3.14.5 で交互に3回ずつ動かした中央値です（同じ Mac で測りました）。測った回が違うので、v2.3.0 の時間は上の表と0.02〜0.03秒ずれます。

推敲の結果は、v2.2.0、v2.2.1、v2.3.0 で、それぞれ1つ前の版と比べて測りました。v2.2.2 は推敲の手順も道具の出力も v2.2.1 と同じなので、推敲は測り直していません。v2.1.3 と v2.3.0 の推敲は、じかに比べて測っていません。

• v2.1.3 → v2.2.0: 自作の類例31本と tests/corpus の163本で推敲の前後を比べ、どちらの版かを伏せて読み比べました。Claude Code（Claude Opus 5.5）で推敲すると、直すべき型を直せた件数は125件のうち44件から91件に、残すべき書き方を誤って直した件数は8件から7件になりました。全文を読んで意味が変わったと判定した件数は1件から2件で、増えた1件は、新しい印のない文で「〜のみ」の「のみ」が落ちたものです。Codex（gpt-6-astra）で類例31本を推敲すると、直せた件数は同じ125件のうち39件から88件に、誤って直した件数は16件から7件に、全文を読んで意味が変わった件数は2件から4件になりました。増えた分は、新しい印のない文の揺れと、直訳語の印のついた文を英語の言い方の意味で書き直した境目の1件です。
• v2.2.0 → v2.2.1: 直訳語の自作の類例4本と tests/corpus の1本を Claude Code で推敲し、どちらの版かを伏せて2つの判定役が読み比べました。直したか書き手に尋ねた件数は、同じ40件について、1つ目の判定で34件から35件、2つ目の判定で39件から40件になりました。全文を読んで意味が変わった件数は、1つ目で3件から0件、2つ目で2件から0件です。残すべき書き方を誤って直した件数は、どちらの判定でも0件のままです。
• v2.2.1 → v2.2.2: 推敲の結果は変わりません。変わったのは diff と check run の時間だけです。
• v2.2.2 → v2.3.0: 上の「数字で見る v2.3.0」と「確かめたこと」のとおりです。開発の途中の候補で測ると、「結果の確かめ」のような形を直したか尋ねた所は、のべ66か所のうち64か所から66か所に、残すべき形を誤って直した所は7か所から3か所になりました。直訳語の5本では、直したか尋ねた所がのべ160か所のうち145か所から146〜148か所になり、意味が変わった所は2つの判定で8〜10か所から10〜11か所でした。

v2.1.3 から更新すると、推敲の結果と、lint、diff、check の出力が変わります。lint の終了コード、既存の JSON のキーと値の意味、*_FORMAT_VERSION、既存のコマンドの引数と既定値は変えていません（--words、--no-words と、--doc-type の値 script を足しました）。lint の新しい印は info なので、lint の --strict と --fail-on の判定は変わりません。ただし allow.txt に書いた語は、前からある warn の規則（比喩動詞、直訳の語、決まり文句）の候補からも外れるので、一覧を置いたリポジトリでは、lint の --strict と --fail-on の結果が変わることがあります。diff は、台詞の最後の「。」だけを外したか足した組を問いと平叙の変化に数えなくなったので、この組だけの文書では、diff と check の --fail-on=meaning-risk の終了コードが1から0になります。check の run は、最終稿に直訳語か flag.txt の語の印が残ると「残した印の語」の行と節を出し、--json に kept_marks が付きます（状態、終了コード、--fail-on は変わりません）。lint は、この形があると renyo_noun（info）の印を出し、check の記録の tools に references/lists/renyo-nouns.txt のキーが加わります。v2.1.3 で残した検査の記録を v2.3.0 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。各版の細部は、v2.2.0、v2.2.1、v2.2.2 のリリースノートと CHANGELOG.md にあります。

v2.2.2 から使っていただいている方へ

推敲の結果が変わります。lint は、この形があると renyo_noun（info）の印を出し、見直し候補の件数と JSON の findings が増えます。
lint の終了コード、--strict と --fail-on の判定、rule_penalty_score は変わりません。check の run は lint の結果を含むので、この形があると lint の節に同じ印が出ます。diff の出力は、tool_version と --version の版のほかは変わりません。
既存の JSON のキーと値の意味、*_FORMAT_VERSION、記録の形、コマンドの引数と既定値は変えていません。lint の JSON の context.words.allow_removed に renyo_noun のキーが、check の記録の tools に references/lists/renyo-nouns.txt のキーが加わります。
v2.2.2 で残した検査の記録を v2.3.0 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。
変更の細部は CHANGELOG.md にあります。

yomiyasu v2.2.2 を公開しました。
同じ段落を何十回も繰り返す文書で、推敲のあとに動く差分の検査（diff）が遅くなっていたのを直したバージョンです。
lint、diff、check、フックの出力は、JSON の tool_version と --version が示す版のほかは、v2.2.1 と1文字も変わりません。
v2.1.3 からお使いの方に向けて、v2.2.0、v2.2.1、v2.2.2 で変わったことを「v2.1.3 からの変化」の節にまとめました。

背景と課題

v2.2.1 を作る途中で、同じ形の段落を何十回も並べた文書を検査すると、diff の時間が段落の数の2乗に近い速さで伸びることが分かりました。
1,257字の技術メモを空行で120回つないだ文書（約15万字）では、diff だけで15秒ほどかかります。
check の run も同じ照らし合わせを使うので、同じだけ待つことになります。

原因は、推敲の前と後を照らし合わせる処理にありました。
この処理は、一致を1つ見つけると、その右に残る範囲でまた一致を探します。
同じ段落が続く文書では、次の一致はすぐ次の段落にあるのに、探すたびに残りのすべての段落を調べていました。

v2.2.2 で変わったこと

v2.0.1 から、照らし合わせの処理は、範囲ごとに一致の長さの上限を求めて探しています。
上限と同じ長さを探す段で見つかる一致は、長さがちょうど上限のものだけです。
そこでこの段では、原文の前から見て最初に一致が見つかったところで探すのをやめるようにしました。
あわせて、種で探すどの段でも、一致を伸ばす長さを上限までで止めます。

答えを選ぶ決まり（いちばん長く一致する部分を選び、長さが同じなら前にある部分を選ぶ）は変わらないので、出力も変わりません。

数字で見る v2.2.2

Python 3.14.5 で動かした時間です（ほかの処理も動いている同じ Mac で、v2.2.1 と v2.2.2 を交互に3回ずつ動かした中央値です）。

繰り返しのない文書の時間は、ほとんど変わりません。

確かめたこと

• v2.2.1 と v2.2.2 の lint、diff、check を同じ4,939件の入力（同じ段落を繰り返す文書を含む）で動かし、版の文字列をそろえて比べました。Python 3.14.5 と 3.9.6 のどちらでも、出力と終了コードは4,939件すべて同じでした。
• 実際のモデルの推敲など1,415組で、diff の出力と lint の JSON を、版の文字列をそろえて v2.2.1 と比べ、違いは0組でした。
• 新しい止め方の答えを、Python の標準の照らし合わせ（difflib）の答えと、無作為の入力121,635組で突き合わせ、食い違いはありませんでした。
• 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,291件ずつ通ります。

v2.1.3 からの変化

v2.1.3 のあと、v2.2.0、v2.2.1、v2.2.2 の3つの版を出しました。v2.1.3 と v2.2.2 を並べると、次のとおりです。

時間は、上の「数字で見る v2.2.2」の表とは別の回に、v2.1.3 と v2.2.2 を Python 3.14.5 で交互に3回ずつ動かした中央値です（同じ Mac で測りました）。測った回が違うので、v2.2.2 の時間は上の表と0.01〜0.03秒ずれます。

推敲の結果は、v2.2.0 と v2.2.1 で、それぞれ1つ前の版と比べて測りました。v2.2.2 は推敲の手順も道具の出力も v2.2.1 と同じなので、推敲は測り直していません。v2.1.3 と v2.2.2 をじかに比べた推敲の測りもありません。

• v2.1.3 → v2.2.0: 自作の類例31本と tests/corpus の163本で推敲の前後を比べ、どちらの版かを伏せて読み比べました。Claude Code（Claude Opus 5.5）で推敲すると、直すべき型を直せた件数は125件のうち44件から91件に、残すべき書き方を誤って直した件数は8件から7件になりました。全文を読んで意味が変わったと判定した件数は1件から2件で、増えた1件は、新しい印のない文で「〜のみ」の「のみ」が落ちたものです。Codex（gpt-6-astra）で類例31本を推敲すると、直せた件数は同じ125件のうち39件から88件に、誤って直した件数は16件から7件に、全文を読んで意味が変わった件数は2件から4件になりました。増えた分は、新しい印のない文の揺れと、直訳語の印のついた文を英語の言い方の意味で書き直した境目の1件です。
• v2.2.0 → v2.2.1: 直訳語の自作の類例4本と tests/corpus の1本を Claude Code で推敲し、どちらの版かを伏せて2人が読み比べました。直したか書き手に尋ねた件数は、同じ40件について、1人目の判定で34件から35件、2人目の判定で39件から40件になりました。全文を読んで意味が変わった件数は、1人目で3件から0件、2人目で2件から0件です。残すべき書き方を誤って直した件数は、2人とも0件のままです。
• v2.2.1 → v2.2.2: 推敲の結果は変わりません。変わったのは diff と check run の時間だけです。

v2.1.3 から更新すると、推敲の結果と、lint、diff、check の出力が変わります。
lint の終了コード、既存の JSON のキーと値の意味、*_FORMAT_VERSION、既存のコマンドの引数と既定値は変えていません（--words、--no-words と、--doc-type の値 script を足しました）。
lint の新しい印は info なので、lint の --strict と --fail-on の判定は変わりません。

ただし allow.txt に書いた語は、前からある warn の規則（比喩動詞、直訳の語、決まり文句）の候補からも外れるので、一覧を置いたリポジトリでは、lint の --strict と --fail-on の結果が変わることがあります。
diff は、台詞の最後の「。」だけを外したか足した組を問いと平叙の変化に数えなくなったので、この組だけの文書では、diff と check の --fail-on=meaning-risk の終了コードが1から0になります。

check の run は、最終稿に直訳語か flag.txt の語の印が残ると「残した印の語」の行と節を出し、--json に kept_marks が付きます（状態、終了コード、--fail-on は変わりません）。

v2.1.3 で残した検査の記録を v2.2.2 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。
もう一度 run を実行してください。各版の細部は、v2.2.0 と v2.2.1 のリリースノートと CHANGELOG.md にあります。

v2.2.1 から使っていただいている方へ

推敲の手順と、lint、diff、check、フックの出力は変わりません。変わるのは、JSON の tool_version と --version が示す版だけです。
既存の JSON のキー、*_FORMAT_VERSION、記録の形、コマンドの引数と既定値は変えていません。
v2.2.1 で残した検査の記録を v2.2.2 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。

変更の細部は CHANGELOG.md にあります。

yomiyasu v2.2.1 を公開しました。
v2.2.0 で足した直訳語の印と書き直し方の抜けを直したバージョンです。あわせて、推敲のあとに残した印の語を、検査の道具（check）が知らせるようにしました。

背景と課題

v2.2.0 では、推敲しても残る言い方を集めた対応表をもとに、直訳語の印と書き直し方を足しました。
公開のあとで、手順を直すときに使っていない新しい文書で、対応表の言い方が直るかを確かめ直したところ、次の3つが見つかりました。

• 技術の文書の「外部から届く要求は、ひとつの入口に集めています。」のように、同じ文に技術の語がない「入口」に、直訳語の印がつきませんでした。「全運転手に響きます。」のような「全〇〇に響く」にも、印がつきませんでした。
• 「全クライアントに響きます」を「影響します」「支障が出ます」に替えるだけで、後ろの文に書いてある中身（画面の表示が遅くなる、など）を使わない推敲がありました。
• 見出しの印のついた語を、本文の題目を並べただけの名前に替え、元の見出しが言っていた目的が落ちる推敲がありました。

直す途中では、印のついた語を残すときに、書き手に尋ねずに「原文の表現を残しました」と書くだけで済ませる推敲も続きました。

v2.2.1 で変わったこと

印のつけ方

技術の文書では、同じ文に技術の語がなくても、「要求は、どれもこの入口を通ります」のように要求や呼び出しが主題の文の「入口」「出口」と、機械やシステムの語がある文の「全〇〇に響く」に、直訳語の印をつけます。
実物の場所の入口（駐車場の出口、北側の入口）、人が待つ形（入口の前でお待ちください）、文字どおりの音や言葉の響き（警報が全フロアに響きます、全社員に響く言葉）には、印をつけません。

v2.2.0 からある印の当て方は変えていません。
サーバールームやデータセンターのような機械を置く部屋の入口だけ、実物の場所として印をつけなくなりました。
手元の実際の文書1,116本と、同梱の文書と自作の類例の194本では、v2.2.0 と比べて印は1つも変わりませんでした。

残した印の語を check が知らせる

推敲の最後に check を実行したとき、最終稿に直訳語と語の一覧の印が残っていれば、「残した印の語: 要求（語の一覧。L9、L25）」のように、語と行を出します。
あわせて、残すなら書き手に尋ねるか、残す理由を書くかの見分け方を節に書きます。
書き直しに使う名前や動作、その動作をする人が、原文、依頼、資料、会話のどれにも書いていなければ、本文を残して「書き手に確かめたい点」で尋ねます。
その分野で定着した言い方や、文字どおりの意味で使っている語は、理由を「残したAIっぽいところ」に書いて残します。

提出の直前の verify も、同じ語をもう一度出します。
この知らせは、尋ねたかどうかまでは確かめません。状態、終了コード、--fail-on の判定は変わりません。
語は lint の結果から取り、lint を流し直さないので、check の時間はほとんど変わりません。

書き直し方

印のついた語を、何が起きるかを言わない意味の広い語（影響する、及ぶ、支障が出る など）に替えるだけにしないことと、後ろの文に何が起きるかが書いてあれば、その中身で書くことを、手順に書きました。
見出しでは、元の見出しが言っていた目的（料金を見積もる前に確かめる点 など）を項目名に残します。
印のついた語と後ろの文で呼び名がそろわず、同じものを指すか分からないときは、本文を残して尋ねます。

確かめたこと

• 対応表の17の言い方を含む自作の文書6本（1本は最後の直しの前に書き、最後の版で初めて推敲しました）を、Claude Code で3回ずつ、Codex で4本を3回ずつ推敲し、どちらの道具かを伏せて読み比べました。表の直したあとと同じ中身になったか、文書に名前がないものを書き手に尋ねたかを見て、外れたのは Claude Code の1回の1か所だけでした（替える呼び名を尋ねた形で、判定でも解釈が分かれました）。
• 推敲の前後の比べ: 直訳語の自作の類例4本と同梱の文書1本を v2.2.0 と v2.2.1 で推敲し、どちらの版かを伏せて読み比べました。直したか尋ねた件数は、40件のうち2人の判定でそれぞれ34件から35件、39件から40件でした。全文を読んで意味が変わった件数は、それぞれ3件から0件、2件から0件で、残すべき書き方を誤って直した件数は0件のままでした。
• 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,289件ずつ通ります。CLI の出力の比べ（4,875件）では、lint と diff は v2.2.0 と同じで、check の違いはすべて「残した印の語」の行と節によるものです。

詳しくは CHANGELOG をご覧ください。

yomiyasu v2.2.0 を公開しました。
推敲しても残りやすい言い方を lint の印で見つけ、文脈を見て直す手順を加えたバージョンです。推敲の結果が変わります。
あわせて、文書の種類に台詞・脚本（script）を足しました。プロジェクトごとに、直さない語と見直す語を書いておく一覧（.yomiyasu-words/）も使えるようになりました。

背景と課題

v2.1.x を使っている方から、yomiyasu で推敲しても残る言い方の報告をいくつもいただきました。
ある方は、AI が書いた技術資料の言い方と、人が直した言い方を並べた表を公開してくださいました。
表に並んでいた言い方の多くは、次の3つの型です。機械やシステムが人の動作をする言い方、実物の名前の代わりに場所のたとえを使う名詞、英語を一語ずつ写した句です。
どれも見た目はふつうの日本語なので、書いたモデルが読み返しても気づきにくく、v2.1.x の lint の候補にも出ませんでした。

たとえば「取りこぼした通知は、翌朝の再送ジョブが拾います。」は、ジョブが通知を「拾う」という言い方で、ジョブが実際に何をするのか（もう一度送るのか、一覧に足すのか）が文からは決まりません。
「新しい鍵に替えると、古い鍵の失効が効きます。」は、英語の take effect を写した言い方です。

公開された紹介記事でも、yomiyasu で直したお知らせ文に、「〜と言えるでしょう」と、名詞がもともと持つ評価を言い直すだけの中身の薄い文（「本体の質感も上質です。」のような文）が残り、意味の薄いカタカナ語を直し損ねた回もありました。
ほかに、AI の文章によく出る型として、次の報告をいただきました。

• 見出しや文書の1行目に、本文に出てこない一語の比喩を置く形
• 漫画や脚本の台詞を、ほとんど「。」で終える形
• 体験記なのに一人称がほとんど出ず、数字や箇条書きばかりが多い読み物
• 「新しい、出会い。」のように、修飾語と名詞のあいだに読点を打って短い名詞で止めるキャッチコピー
• 「測る、比べる、選ぶ。」のように、主語も目的語もない他動詞を読点で並べて止める文

別の方からはプロジェクトで使う語を検査に足したり外したりしたいという要望をいただきました。

v2.2.0 で変わったこと

印をつけて、文脈を見て書き直す

lint に、上の型と語の一覧のために、印をつける規則を10個加えました。表の3つの型（型1〜型3）はまとめて直訳語（calque）として印をつけます。ほかの印は、見出しと文書の1行目の比喩ラベル（metaphor_label）、「〜と言えるでしょう」（say_hedge）、中身の薄い評価の文（thin_evaluation）、意味の薄いカタカナ語（katakana_term）、キャッチコピーの読点（copy_comma_noun）、主語も目的語もない他動詞の並び（bare_verb_chain）です。台詞の句点（dialogue_period）、読み物の一人称と数字（narrative_density）、語の一覧の flag.txt の語（project_term）の印は、下の節で説明します。印はどれも info で、lint の終了コード、--strict と --fail-on の判定、rule_penalty_score は変わりません。

印は「直す合図」ではなく、文脈を読み直すための候補です。推敲では、印のついた文で誰が何をどうするかを原文と前後の文から確かめ、その関係が読める文に書き直します。印のついた語を別の語に差し替えるだけの直しはしません。書き直しに使う名前や動作が原文にないときは、本文を残して書き手に確かめます。

直訳語の印がついた語では、推敲で次の2つを確かめます。その分野の人が仕様や手順書に書くときに選ぶ呼び名か。英語に戻すと一語ずつ英語の言い方に対応するか。テストが通る、キャッシュが効く、パッケージの依存先のような定着した言い方は残し、lint も印をつけません。直訳語の印の message には型の番号と当たった言い方を出します（置き換え先の語は出しません）。印のついた語の中身は前後の文、とくにすぐ後ろの文に書いてあることが多いので、その中身を主語や目的語にして書き直します。上の通知の例なら、前の文に「送信に失敗した通知は一覧に残す」とあれば、「送信に失敗して一覧に残った通知は、翌朝の再送ジョブがもう一度送ります。」とします。通知の扱いがどこにも書いていなければ、本文を残して尋ねます。

「〜と言えるでしょう」は推量の「でしょう」を残し、「と言える」だけを外します。区分に当たるかを判断する文のように、印のつかない「と言えるでしょう」は直しません。

台詞・脚本と読み物

文書の種類に台詞・脚本（script。漫画のネーム、シナリオ、台本）を加えました。lint、diff、check の --doc-type に渡せます。

script を指定したとき、lint は、台詞が10個以上あり、最後の字が「。」の台詞が5割以上なら、文書全体に1件の印（dialogue_period）をつけます。推敲ではこの印がついた台本だけ、台詞の最後の「。」を外します。台詞の中の文と文の間の「。」、ト書きと地の文の「。」は残し、台詞の口調、言い回し、短い文の重ねは直しません。印のつかない台本と、依頼で句点を打つ書き方を指定された台本は、句点を外しません。

エッセイ（essay）を指定したとき、lint は、一人称が少なく、数字と箇条書きが多い読み物なら、文書全体に1件の印（narrative_density）をつけます。推敲では、流れだけを並べた箇条書きを地の文に戻します。一人称と体験は足さず、数字も消しません。

diff は台詞の最後の「。」だけを外したか足した組（「見たのか。」→「見たのか」）を、問いと平叙の変化に数えなくなりました。どの種類でも同じです。

プロジェクトの語の一覧

git の最上位に .yomiyasu-words/ を置き、allow.txt（直さない語）と flag.txt（印をつけて見直す語）に1行に1語ずつ書くと、lint、diff、check が同じ一覧を読みます。フックは、受けた --words か --no-words を、案内する check のコマンドに付けます。

allow.txt の語は、2.2.0 で足した直訳語などの印と、前からある比喩動詞（metaphor_verb）、英語を辞書的な漢語にした語（translated_term）、決まり文句（slop_vocabulary）の候補から外れます。flag.txt の語には project_term の印がつきます。推敲では flag.txt の語をそのプロジェクトで見直すと決めた語として扱い、定着した言い方でも残さず、前後の文から指すものを確かめて書き直します。指すものが分からなければ、書き手に尋ねます。

--words で一覧の場所を指定でき、--no-words を付けると読みません。リポジトリに入れてチームで共有する前提のファイルです。

入れなかったもの

「〜できる仕組み。」のように、何も説明しないで「仕組み」で終える文の規則は入れませんでした。試しに入れた手順では、推敲の前後の比べで直せた文がなく、前後の文で仕組みを説明している、残すべき文まで書き換えたためです。

確かめたこと

推敲の前後の比べは自作の類例31本（新しい型と、直さない文を混ぜた文書）と tests/corpus の163本で行いました。2.1.3 と 2.2.0 で推敲し、どちらの版かを伏せて読み比べています。

Claude Code（Claude Opus 5.5）で推敲すると、直すべき型を直せた件数は125件のうち44件から91件に、残すべき書き方を誤って直した件数は8件から7件になりました。全文を読んで意味が変わったと判定した件数は1件から2件で、増えた1件は、新しい印のない文で「〜のみ」の「のみ」が落ちたものです。

Codex（gpt-6-astra）で自作の類例31本を推敲すると、直せた件数は同じ125件のうち39件から88件に、誤って直した件数は16件から7件になりました。全文を読んで意味が変わった件数は2件から4件で、増えた分は、新しい印のない文の揺れと、直訳語の印のついた文を英語の言い方の意味で書き直した境目の1件でした。

背景で触れた表の場面に似せて自作した文書でも確かめました（表の文はリポジトリに入れていません）。表の17の言い方のうち、既定で12に印がつき、flag.txt に5語を書くと17すべてにつきます。残りの5つは辞書の訳語を当てた名詞や定着した言い方で、既定では印をつけません。flag.txt に5語を書いた状態で推敲すると、Claude Code はどの回も、表の「直した後」と同じ中身に直したか、文書に名前のないものを書き手に尋ねました。Codex も16の言い方では同じでしたが、承認の言い方は、誰が承認するかが文書で決まる場合にだけ直り、決まらない文書では3回のうち2回、尋ねずに別の言い方に書き換えました。2.1.3 では、同じ文書で直ったのは一部でした。

試験一式は macOS、Linux、Windows で通ります。lint、diff、check の出力の違いは、新しい規則、文書の種類 script、語の一覧で説明がつくものだけです。

2.1.3 から使っていただいている方へ

推敲の結果が変わります。lint の終了コード、既存の JSON のキーと値の意味、*_FORMAT_VERSION、既存のコマンドの引数と既定値、ファイルの場所は変えていません（--words、--no-words と、--doc-type の値 script を足しました）。lint の新しい印は info なので、lint の --strict と --fail-on の判定は変わりません。ただし allow.txt に書いた語は、前からある warn の規則（比喩動詞、直訳の語、決まり文句）の候補からも外れるので、一覧を置いたリポジトリでは、lint の --strict と --fail-on の結果が変わることがあります。diff と check の --fail-on=meaning-risk では、台詞の最後の「。」だけを外したか足した組だけの文書で、終了コードが1から0になります。lint の時間は1回あたり十数ミリ秒増えます。2.1.3 で残した検査の記録を 2.2.0 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。変更の細部は CHANGELOG.md にあります。

yomiyasu v2.1.3 を公開しました。
Windows で見つかった不具合を直したバージョンです。
推敲の結果は 2.1.2 と同じで、macOS と Linux では lint、diff、check、フックの出力も変わりません。
Windows で yomiyasu_check.py やフックを使っている方は更新してください。

背景と課題

v2.1.2 を公開したあと、Windows で yomiyasu を使っている方から、原因の場所まで調べた報告を2件いただきました。

1件目は、v2.1.2 で足した状態フォルダの案内が出ないことがある問題です（#41）。ほかの OS ユーザーが作った .yomiyasu/ で、.gitignore は見えるのに、inputs がフォルダかどうかを確かめられない（属性の読み取りを拒まれる）と、os.mkdir は「既に存在する」と答えます。v2.1.2 はこの答えをそのまま記録を書けなかった理由に出したので、書き込みを拒まれたときの案内（--state-dir か YOMIYASU_STATE_DIR でユーザーごとに分ける）が出ませんでした。

2件目は、Windows で試験一式を流すと、2,052件のうち85件が落ちるという報告です（#42）。多くは、試験が出力の改行を LF と決め、POSIX の権限ビットを見ていたためでした。yomiyasu の側の不具合も3つありました。標準出力と標準エラーの改行が CRLF になり、check の記録の .txt と CLI の出力が一致しないこと。出力先のパイプが先に閉じると、内部エラーとして Python の例外の表示（traceback）を出し、終了コードが120になることがあること。start、run、フックを並行に動かすと、消している途中のロックで内部エラーになったり、--max-runs を越えて検査を実行したりすることがあることです。

v2.1.3 で変わったこと

状態フォルダの中の名前を確かめられないときも案内を出す

状態フォルダの中の名前があるのにフォルダかどうかを確かめられず、確かめようとすると書き込みの拒否と同じ PermissionError になるときは、書き込みの拒否として扱います。run の1行目と start に、2.1.2 で足した、状態フォルダをユーザーごとに分ける案内を出します。名前がファイルとして見えるときは、今までどおりです。

改行はどの OS でも LF に

lint、diff、check、フックは、標準出力と標準エラーに改行を LF で書くようにしました。Windows でも、check の記録の .json と .txt が CLI の出力とそろいます。macOS と Linux では、書く中身は変わりません。

閉じた出力先と並行実行

Windows で出力先が先に閉じたときは、macOS や Linux と同じく「出力先が閉じられたため、結果を最後まで書けませんでした。」と出し、終了コード3で終わります。並行に動かしたときは、Windows のときだけ、ほかのプロセスが消している途中のロックは使用中とみなして今までと同じ締切（start、run、end は12秒、フックは2秒）まで待ち直し、入れ替えている途中の登録や記録は少し待ってから読み直します。ずっと読めないファイルが並んでもフックや一覧が長く止まらないよう、読み直しで待つ時間は1つのプロセスで合計1秒までにしました。

Windows の CI

CI で、Windows（windows-latest、Python 3.12）でも試験一式を流すようにしました。試験の側も、子に渡す入力と書くファイルを改行を変えないバイト列にし、POSIX の権限ビットの確かめは POSIX だけで行い、Windows では時間の上限を機械の速さに合わせて延ばす形にしました。

2.1.2 から使っていただいている方へ

推敲の結果は変わりません。macOS と Linux では、lint、diff、check、フックの出力も 2.1.2 と同じです。既存の JSON のキー、*_FORMAT_VERSION、記録の形、コマンドの引数と既定値は変えていません。2.1.2 で残した検査の記録を 2.1.3 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。変更の細部は CHANGELOG.md にあります。

yomiyasu v2.1.2 を公開しました。Windows で状態フォルダに書き込めないときの不具合を2つと、全角の小数点を含む文で diff が止まる不具合を直したバージョンです。推敲の結果は 2.1.1 と同じで、lint、diff、check の出力も、全角の小数点を含む文と状態フォルダに書けないときのほかは変わりません。Windows で yomiyasu_check.py やフックを使っている方と、全角の数字を使う文書を検査している方は更新してください。

背景と課題

v2.1.1 を公開した翌日、原因の場所と直し方の案まで書いた報告を3件いただきました。2件は Windows で yomiyasu を使っている方からで、もう1件は v2.1.1 で足した検査の不具合です。

1件目は、状態フォルダ（.yomiyasu/）に書き込めないと、yomiyasu_check.py run が何も出力せずに CPU を使い続け、終わらなくなる問題です（#37）。Python 3.12 までの Windows の tempfile は、書き込みを拒まれたのを「同じ名前のフォルダがあるため」と読み、一時ファイルの名前を約21億回まで試し続けます。報告では、1時間半たっても終わりませんでした。

2件目は、書き込めなくなる理由のほうです（#38）。yomiyasu は原稿の写しを守るため、状態フォルダを作った OS ユーザーだけが読み書きできるフォルダにしています。Windows でも、Python の版によっては同じように作ったユーザーと管理者だけのフォルダになります。そのため、同じリポジトリを Codex のサンドボックスのような別の OS ユーザーが先に使うと、普段のユーザーは記録を残せませんでした。

3件目は、全角の小数点を含む文（「値は３．５％だった。」など）を書き換えた組で、yomiyasu_diff.py が内部エラーで止まる問題です（#40）。v2.1.1 で足した、数の概数・範囲の印の検査で起きていました。全角の「．」は文の区切りにも読まれるので、「３．５％」とひとまとまりで読んだ数の終わりが、文の範囲を越えていたためです。

v2.1.2 で変わったこと

書けないときは、すぐに終わる

check は、tempfile の名前を試す関数を使わず、名前を試すのを100回までにした関数で一時ファイルと一時フォルダを作るようにしました。書き込みを拒まれたときに次の名前を試すのは、その名前が本当にフォルダのときだけです。状態フォルダに書けないとき、run はすぐに記録を残さずに reason=not_writable で終わります。start も、Python の例外の表示ではなく、書けなかった理由と案内を出して終わります。

状態フォルダはユーザーごとに分ける

原稿の写しが入るので、状態フォルダを作った人だけのフォルダにする作りは変えていません。代わりに、状態フォルダへの書き込みを拒まれたときは、ほかの OS ユーザーが作った状態フォルダかもしれないことと、--state-dir か YOMIYASU_STATE_DIR で自分が書ける場所を指定することを案内するようにしました。同じリポジトリをほかの OS ユーザーと使うときは、ユーザーごとに YOMIYASU_STATE_DIR で別の状態フォルダを指定してください。README と docs/tools.md にも書きました。

全角の小数点でも、数の印を読む

数が文の範囲を越えるときは、数を含む文の終わり（次の句点か改行）までを範囲にして、数のあとの印を読むようにしました。止まらなくなっただけでなく、「３．５％程度 → ３．５％」のように全角の小数点の数のあとの印が消えた書き換えも、半角の小数点と同じように意味が変わる恐れとして出します。この組では check run も、diff を実行できずに partial で終わっていましたが、今は最後まで検査します。

2.1.1 から使っていただいている方へ

推敲の結果は変わりません。lint、diff、check の出力も、全角の小数点を含む文と、状態フォルダに書けないときの run の1行目、start の標準エラーの文のほかは 2.1.1 と同じです。既存の JSON のキー、*_FORMAT_VERSION、記録の形、コマンドの引数と既定値は変えていません。2.1.1 で残した検査の記録を 2.1.2 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。変更の細部は CHANGELOG.md にあります。

yomiyasu v2.1.1 を公開しました。
推敲の結果は 2.1.0 と同じで、lint、diff、check、フックの見落としと誤検知を直したバージョンです。
投稿の本文に壊れた文字が1つあるだけでフックが何も確かめずに通してしまう不具合を直したので、フックを使っている方は更新してください。
ほかの方は、急いで更新しなくてもかまいません。

背景と課題

v2.1.0 を公開した日のうちに、多くの方が yomiyasu を自分の環境に取り込んでくださいました。そのなかで、yomiyasu のファイルを直接読む外の仕組みがあることも分かりました。参照ファイルの節の見出しを CI で参照している文書スキルや、起動のたびに SKILL.md と検査のスクリプトを取りに行くアプリ、検査の記録を読む作業手順です。どれも、v2.1.0 のファイルの場所、見出し、出力の形をそのまま頼りにしています。

同じ日に、再現の手順と原因の場所まで書いた不具合報告を7件いただきました（#28〜#34）。重いのは2件です。1件は、投稿の本文に壊れた文字が1つ混ざるとフック全体が判定を出さずに終わり、止めるべき本文まで通してしまう問題（#28）。もう1件は、「AまたはBのどちらか」を「AとBの両方」に書き換えて真偽が逆になっても、diff が意味の変わる恐れを0件と出す問題（#34）です。検査が黙って素通りしたり、意味の反転を見逃したりすると、「意味を変えずに読みやすくする」という yomiyasu の約束が成り立ちません。

ほかにも、ソースを読んで試した解説記事から2件、推敲した返信に残った文から1件、検査の見落としが見つかりました。「約120人」を「120人」に直しても diff が何も言わないこと、文末の後ろに絵文字があるだけで lint が定型の締めを拾えないこと、何がどう良くなるのかを書かない比喩の「効く」を lint が拾わないことです。

v2.1.1 では、これらをすべて直しました。外の仕組みが頼っているファイルの場所、見出し、出力の形は変えていません。

v2.1.1 で変わったこと

壊れた文字があっても、フックは止めるべき本文を止める

投稿の本文の欄（body、description など）のどれかに、対になっていないサロゲート（JSON の \ud800 など）があると、2.1.0 のフックは判定を出さずに終わっていました。ホストはこれを許可とみなすので、同じ投稿のほかの欄に止めるべき本文があっても通っていました（#28）。今は、ほかの欄をいつもどおり確かめて止め、壊れた欄だけを照合できない本文として扱います。見直しの中で、gh の --body-file や -F に渡すファイルの名前に同じ文字があると、同じように素通りすることも分かったので、あわせて直しました。

意味の反転と強まりを見逃さない

diff は、次の3つの書き換えを意味が変わる恐れとして出し、--fail-on=meaning-risk に数えるようになりました。

• どれか一つを選ぶ言い方と全部を含む言い方の入れ替え（「AまたはBのどちらか」→「AとBの両方」、またはその逆。#34）
• 関連や相関を述べた文に、原文になかった因果の言い方を足した書き換え（「関連がある」→「因果関係がある」「〜が原因である」）
• 数に付いた概数や範囲の印の増減（「約120人」→「120人」、「3日以内」→「3日」、「以上」↔「超」）

どれも、同じ意味の言い換えは意味が変わる恐れに数えません。「または」を「か」に、「約120人」を「120人ほど」に、「100人未満」を「100人に満たない」にしても数えず、「関係のある部署」「相関係数」のように名詞として使う語や、「契約」「震度5弱」のように印に見えて印でない語でも出しません。

見出しの変化を見直し候補に出す

推敲で太字の行が #### の見出しに変わっても、2.1.0 の diff は見直し候補に出していませんでした。SKILL.md は「見出しと節の数と順は変えない」と決めているので、この変化は確かめるべき所です。今は、見出しの数が変わったとき、太字の行や本文の行を見出しにしたとき、見出しを本文に戻したとき、見出しの段を変えたときに、どの行がどう変わったかを「構造」の見直し候補として出します。意味が変わる恐れには数えないので、--fail-on の終了コードは変わりません。

lint の誤った警告と見落としを直す

推敲のときモデルは lint の候補を読むので、文字どおりの語に毎回警告が出ると、候補そのものが信用されなくなります。「真理値」「安全装置」、時刻を表す「ボタンを押した瞬間に」、「この辞書の次の版では」に出ていた警告をやめました（#31〜#33）。「人生の真理」のような比喩や、ソフトウェアの「次の版で」には今までどおり出します。

逆に、拾うべきなのに拾えていなかった形も直しました。「それが真理と言っても過言ではありません 🚀」のように文末の後ろに絵文字や記号が付くと、文末を見る規則が外れていました。今は飾りを読み飛ばして同じように候補を出します。比喩の「効く」も、「地味に」などの副詞がなくても拾うようにしました（「この工夫は後から効いてきます」）。薬や冷房、調味料のような文字どおりの「効く」では出しません。

run の出力の頭だけで、候補の場所が分かる

エージェントが yomiyasu_check.py run の出力を頭の数行だけ読むと、候補の中身の節が落ちて、候補を読まないまま推敲を終えることがありました。今は候補があるとき、3行目のすぐあとに、どの行のどの規則かの短い一覧と、「候補の中身は下の節にあります。出力を切らずに読んでください。」の1行を出します。2行目の状態の行は変えていません。

そのほかの直し

• UTF-8 として読めないファイル名の原稿を、start とフックで登録できるようにしました（#29）。
• run --stdin で、改行が CR だけの入力も、ファイルで渡したときと同じように扱います（#30）。
• SKILL.md は削っていません。41,445字あるので、スキルの指示の字数に上限があるサービス（Microsoft 365 Copilot の Agent Builder は30,000字まで）には、そのままでは入りません。このことを docs/limitations.md に書きました（#35）。

数字で見る v2.1.1

書き換えの組を diff に --fail-on=meaning-risk を付けてかけた結果です。「止まる」は終了コードが1になること、「候補」は見直し候補に出るが終了コードは0のことです。

lint の結果です。

新しい候補が誤って出ないかは、実際のモデルの推敲の出力を中心に重複を除いた1,715組と tests/corpus で確かめました。意味の3つの型の新しい候補は0件で、lint の直しで増えた候補と消えた候補もありません。2.1.0 と 2.1.1 の CLI を同じ4,099件の入力で動かすと、終了コードと標準エラーの違いは0件です。標準出力の違い385件は、どれも run の頭に足した2行か見出しの候補で説明がつきます。速さは新しい検査の分だけ少し伸び、21万字の文書の diff は2.41秒から2.62秒になりました。

2.1.0 から使っていただいている方へ

推敲の結果は変わりません。lint、diff、check の出力は、上の直しに当たるところだけ変わります。

CI などで --fail-on=meaning-risk を使っている場合は、意味の3つの型に当たる書き換えで、終了コードが1になることがあります。見出しの候補は、どの --fail-on の終了コードも変えません。

check run の人が読む出力は、候補があると4行目と5行目に2行が加わり、そのあとの行が2行ずつ下がります。記録のパスを読む仕組みは、行の位置ではなく「記録: 」で始まる行で探してください。--json、記録のファイル、2行目の状態の行は変わりません。

既存の JSON のキー、*_FORMAT_VERSION、コマンドの引数と既定値、ファイルの場所、参照ファイルの見出しは変えていません。meaning_risks[].kind には choice、causality、number_qualifier が加わります。2.1.0 で残した検査の記録を 2.1.1 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。変更の細部は CHANGELOG.md にあります。

yomiyasu v2.1.0 を公開しました。
読みやすくしても意味と文の働きを変えないという軸はそのままに、これまでの手順と検査では十分に扱えていなかった2種類のずれを扱えるようにしました。
語順や省略による読み違いと、仕様書での「〜してよい」「〜できる」「必ず〜する」の取り違えです。短い例文の文書で測ると、v2.0.2 では6回中0回だった振る舞いが、v2.1.0 では6回中5〜6回になりました。
v2.0.2 の diff が素通りさせていた「してよい」→「できる」のような書き換えも、--fail-on=meaning-risk で止まります。
あわせて、「書き手に確かめたい点」の上限を3点にしました。

背景と課題

v2.0.2 までの yomiyasu は、推敲したあとに数値や否定、主語と目的語の入れ替え、文の種類の変化を検査していました。ただ、利用者の方からいただいた2つの報告で、この検査をすり抜けるずれがあると分かりました。

1つ目は、語順や省略、助詞の選び方による読み違いです。yomiyasu で推敲した記事に、次の3つの形の文が残っているという指摘をいただきました。動詞の目的語が抜けて何の話か決まらない文、主題の「では」が文末まで掛かって別の部分の話まで含んで読める文、前置きなしに「〜したのは、A、B、C。」と並べた文です。どの文も lint の候補は0件で、diff にもこうしたずれを見る仕組みはありませんでした。

たとえば「設定の一覧を渡して比べさせると、Aは残りの2つの案より多く削った。」は、何を削ったのかが書いてありません。間に「残りの2つの案より」が挟まるので、前に出た「設定の一覧」を削ったようにも読めます。

2つ目は、許可・能力・保証の言い方のずれです。別の方が v2.0.2 で設計文書をまとめて推敲したところ、lint、diff、最終稿の照合はすべて通りました。ところが別のモデルで見直すと、「〜してよい」（許可）を「〜できる」（能力）に変えた所と、説明を保証に強めた所が見つかったそうです。仕様書では、この違いがそのまま仕様の違いになります。検査を全部通ったのに仕様が変わっていた、というのが報告の要点でした。

v2.1.0 で変わったこと

抜けた目的語を文の中で追えるようにする

目的語を書かない他動詞の前に句が挟まった文では、文脈にある対象を目的語に書くか、動作を名詞にして主語に立てます。上の例なら、前の段落に削った対象が書いてあればその語を目的語に書き、書いていなければ「Aの削った量は、残りの2つの案より多かった。」のようにします。どちらでも決まらなければ、本文はそのままにして書き手に確かめます。推測で対象を作らないという決まりは変えていません。

yomiyasu は硬い漢語を和語の短い言い回しに替えます。ただ、「書き換える」「整える」のような意味の広い和語の動詞は、目的語がないと何をしたのかが決まりにくくなります。そこで、漢語を和語の動詞に替えるのは、替えたあとも目的語が追えて、意味の幅が同じときだけにしました。

主題がどこまで掛かるかを確かめる

「ParserではJSONの深さを10までに抑えるため、MAX_DEPTHを定義して再帰を打ち切ります。」の後半は、Parser の中の処理なのか、ビルドの設定の話なのかが、文だけでは決まりません。こうした文では、主体を推測で書き足さずに、後半がどの主題の話かを書き手に尋ねます。

尋ねる場面は、主題が部品や処理の名前で、後半に別の名前を扱う動作が出てくる文に絞りました。これより広げれば、読み違えやすい文を確かめ損ねることは減る見込みです。ただ、読み違えの恐れが小さい文書でも、念のための問いが増える恐れがあります。問いが多いと、書き手は1つずつ答えを考えなければならず、本文を確定するのに本当に要る問いがほかの問いに埋もれてしまいます。上限の3点が念のための問いで埋まれば、要る問いが「ほかに N か所」に回ることもあります。この釣り合いを見て、尋ねる場面をこの形にとどめています。

前置きのない強調の形を直す

「〜で変わったのは、A、B、C。」は、何かが変わったことを読み手がもう知っているときの書き方です。前の文や見出しにその前提がなければ、「〜では、A、B、Cが変わった」のように述語まで書きます。前提が書いてあるときや、見出し、結び、スライドの箇条では残します。lint にも、この形を見直し候補（info）にする規則を足しました。

許可と保証の言い方の変化を止める

diff が、許可の言い方（してよい、しても構わない など）が消えた書き換えと増えた書き換えを、意味が変わる恐れとして止めるようになりました。「この値は管理者だけが変更してよい」を「変更できる」に変えると、v2.0.2 では意味が変わる恐れに出ず、終了コードも0でした。v2.1.0 では --fail-on=meaning-risk で止まります。原文にない常体の「〜を保証する」を足した書き換えも、敬体の「保証します」と同じように止めます。事実や仕様を述べる文書の種類（pr、article、incident、proposal、manual、formal、paper）を指定したときは、「場合がある」を消した言い切りと、「必ず」を足した書き換えも止めます。

能力の言い方（できる）が消えた書き換えは、止めずに見直し候補として示します。能力の言い換えには正しい直しが多いためです。「〜することができる」を「〜できる」に、「〜してもよい」を「〜してよい」にするような、同じ言い方の中の言い換えは止めません。実際のモデルの推敲の出力を中心とした1,715組に diff をかけたところ、新しく出た候補は7通りで、5通りは正しい指摘、2通りは判断の分かれる候補でした。誤検知と見たものはありません。

書き手に確かめたい点は3点まで

この版では、目的語や主題の掛かる範囲が原文から決まらないときに書き手に確かめるので、確かめたい点が増えることがあります。そこで上限を2点から3点にし、多いときに選ぶ順を決めました。3点を埋めるために問いを足すことはしません。答えで本文が変わらない提案も入れません。

数字で見る v2.1.0

変えた規則に当たる短い例文の文書を4本用意し、Claude Code（Claude Opus 5.5）と Codex（gpt-6-astra）に3回ずつ推敲させました。数えたのは、測る前に決めた振る舞いになった回です。目的語の文では目的語を書くか動作を名詞にするか書き手に尋ねた回、前提のない文では述語まで書いた回、前提のある文では残した回、主題の文では主体を足さずに書き手に尋ねた回を数えました。例文は、規則に入れた例と同じ形の短い文書です。

許可・能力・保証の言い方を変えた1文どうしを、--fail-on=meaning-risk を付けて diff にかけた結果です。「出ない」は意味が変わる恐れに出ないこと、「数えない候補」は意味が変わる恐れには出るが終了コードは0のこと、「止まる」は終了コードが1になることです。

検査の速さは v2.0.2 とほぼ同じです。37.7万字の文書の diff は1.41秒が1.44秒になりました。

v2.0.2 から使っていただいている方へ

推敲の結果が変わります。lint と diff も、新しい規則に当たる文では候補が増えます。lint の新しい規則は見直し候補（info）なので、--strict と --fail-on には効きません。

CI などで --fail-on=meaning-risk を使っている場合は、許可の言い方を変えた書き換えと、原文にない「保証する」「〜ことはない」を足した書き換えで、終了コードが1になることがあります。--doc-type に pr、article、incident、proposal、manual、formal、paper を付けているときは、「場合がある」を消した言い切りと「必ず」の足しでも1になります。

スキルから使うときは、スキルが文書の種類を決められたときにそれを check に渡すので、何もしなくてかまいません。lint、diff、check を自分で動かして仕様書や設計文書を検査するときは、--doc-type formal などの種類を付けてください。

既存の JSON のキー、オプション、ファイルの場所、スキルの名前は変わりません。meaning_risks[].kind には modality と modality_review が加わります。v2.0.2 で残した検査の記録を v2.1.0 の verify で照らすと、検査のスクリプトが変わったので tool_changed になります。もう一度 run を実行してください。足したキーと値など、変更の細部は CHANGELOG.md にあります。