# 変更履歴 yomiyasu のバージョンごとの変更を書きます。1.1.2 以前の変更は、各バージョンの GitHub のリリースノートを見てください。 ## 2.4.0 - 2026-10-25 推敲の結果と、lint、diff、check の出力が変わるバージョンです。英語の短い術語に漢字1字を当てた名詞（「今回の版」「一覧の頭」「lint の印」）を lint の直訳語の型4として見つけ、その分野で定着した呼び名に直す手順を加えました。diff と check には、原文にない人や担当を主語か、知らせる・頼む相手として足した文を示す節を足しました。スライドの見出しと1行の箇条では、間を作るだけの読点を lint が `--doc-type slides` のときだけ指摘し、推敲で外す決まりを足しました。出力の言葉もそろえ、yomiyasu 自身の文書とスクリプトのコメントを、このバージョンの lint にかけて直しました。 ### きっかけ - 2.3.0 の論文を教えてくださった方から、yomiyasu を通す前の Claude の文章で、英語の短い術語に漢字1字を当ててそのまま名詞に使う傾向（version に「版」、head に「頭」、mark に「印」など15語）が見えるという分析をいただきました。2.3.0 の lint が拾うのは「版」の一部だけでした。2.3.0 で、この15語を含む合成の下書き10本を3回ずつ推敲すると、段、窓、帯、床は直り、口、門、旗、系、組は何を指すかを尋ねました。版（印のつかない形）、印、頭は、のべ45か所のうち19か所を、直しも尋ねもせずに残しました。 - 2.3.0 を読んだ方から、工学と品質保証の観点の意見をいただきました。意味が変わった推敲のうち原文にない担当者や通知先を足した形を拾う検査がないこと、規則ごとの改善とは別に文書全体の意味と読みやすさを比べる受入評価が要ること、README の Codex 向けの入れ方が利用者のフォルダを確かめずに消すことの3点です。 - 作者から、yomiyasu 自身の文書の多くの言い方がこのバージョンで直る形になるので、自己回帰的に直すよう頼まれました。 - 作者が登壇のスライドの見出しを `--doc-type slides` で推敲したところ、推敲の前の見出しの読点13個のうち12個が残りました。yomiyasu は読点を役目（条件、逆接、文頭のつなぎ、場面）ごとに見るので、地の文なら残す読点を、一目で読む見出しでも残していました。手で外すと12個が5個になり、diff の意味が変わる恐れは0件でした。references/doc-types/slides.md には読点の決まりがなく、lint の pause_comma は短い主語と主題のあとだけを見ていました。 ### lint - calque に型4「英語の短い術語に当てた漢字1字の名詞」を足しました（info。点数、`--strict`、`--fail-on` には入りません）。当てるのは3語です。 - 「版」: 連体の修飾を受けて名詞として使う形（「今回の版」「直した版」「同じ版」「Python の版」「短い版」）と、「版ごと」「版の文字列」「版を分ける」の形。文に出版物の語（「第2版」「改訂版」「吹き替え版」、新聞、版画 など）があるときと、英数字の名前のあとの版（「Mac 版」「PC 版」）には当てません。同じ行に「版」の translated_term が出ているときは重ねません。 - 「印」: 1字で使う「印」のうち、文に検査や推敲の語（lint、diff、検証、ログ、推敲、出力 など）があるもの（「lint の印」「推量の印」「行に印をつける」）。×印、目印、焼き印、判子（「印を押す」）には当てません。 - 「頭」: 行、一覧、出力、ログ、段落などの「頭」（先頭の意味）と、PR やブランチの「頭」（HEAD）。体や慣用の頭（「頭が痛い」「曲の頭」、頭上）には当てません。 - message は「直訳語（型4: 英語の短い術語に当てた漢字1字の名詞。当たった言い方: 版）の候補です。…」です。語の一覧の `allow.txt` に字（版、印、頭）を書くと外れます。check の「残した指摘の語」には、ほかの直訳語と同じく入ります。 - ほかの12語（段、窓、帯、系、口、床、穴、枠、箱、旗、門、組）には当てません。2.3.0 の推敲が直しているか、何を指すかを尋ねているか、人の文章でも定着した使い方が多い語です。 - 規則 `slide_comma`（info）を足しました。`--doc-type slides` のときだけ、1行で終わる60字以下の見出し、箇条書き、段落の行で、間を作るだけの読点を1行に1件指摘します。行頭の箇条の印（入れ子も）、「・」「①」のような印、【】、「結論：」のようなラベルは外してから文頭を決めます。当てるのは、文頭のつなぎの語（だから、それでも、そこで、結局、まず など）、文頭の決まった「〜ば」（振り返れば、数字で言えば、言われてみれば など）、文頭の6字以上の時や場面の句（その日のうちに、会議が終わるまでに など）、文頭から15字以内の主題（〜では、〜は、〜も）、文頭から10字以内の主語（名詞＋が）、目的語の「を」のあとの読点です。逆接（のに、ても、けれども、ながらも、述語＋が）、条件（なら、たら、「〜ときは」「〜場合は」、「上司に言えば」のような「〜ば」）、理由や目的（ので、ために、ためには、するには）、名詞の並び（A、B、C と「Aを、Bを、」）、「その夜、」のような短い時の句、主題のあとに別の主語が続く所（会議では、担当者が）、主題のあとに並びが続く形（〜のは、A、B、C）、長い主語のあとの読点と、カギ括弧と引用符の中、引用、コード、続きの行がある項目には当てません。主題のあとの主語が「〜がある」「〜がない」「〜が多い」のように、あるかないかや数を言う文の主語のときは、当てます。同じ行に pause_comma が出ていれば、主題と主語の読点を重ねません。点数、`--strict`、`--fail-on` には入りません。 - lint と diff を `-B` なしで動かしても、スキルのフォルダに `__pycache__` を作らないようにしました（check は前から作りません）。 ### diff と check - diff に節「■ 原文にない人や担当を足した文」を足しました。書き直した文で、原文にない人や担当（担当者、管理者のような役割の語、部署やチームの語、「〜さん」「〜様」の形の名前、人称の語）を、主語か、知らせる・頼む相手に足した所を、元の文と後の文を並べて示します。カタカナと和語の言い換え（「アドミン」→「管理者」、「ステークホルダー」→「関係者」など）と、同じ人を指す言い換え（読者と読み手、開発者とエンジニア など）は出しません。 - この節は意味が変わる恐れの件数（meaning_risk_count）、状態の行、`--fail-on` の終了コード、check の記録の meaning_risk= には入りません。--json の最後に新しいキー `added_actors`（候補がなければ `[]`）が加わります。 - diff に `--material 資料` を足しました（何度でも指定できます）。資料にいる人や担当は、この節に出しません。check の run は、資料をすべて diff に渡します。 - check の run の出力にも同じ節が出て、冒頭の一覧に「原文にない人や担当: 後N行目 …」の行が加わります。 - 出力の言葉を変えました。「文の種類の印」は「文の種類を表す語」、「消えた印」「増えた印」は「消えた語」「増えた語」、「引用の印」は「引用の書き方」、「概数・範囲の印」は「概数・範囲を表す語」、「残した印の語」は「残した指摘の語」、「太字の印（**）」は「太字の記号（**）」、「見出しの段」は「見出しのレベル」、「版を表示して終わります」は「バージョンを表示して終わります」になります。 ### 推敲の手順 - SKILL.md Step 2 の直訳語の並びに「英語の短い術語に当てた漢字1字の名詞」を足し、その語を分野で定着した呼び名に替えるのは「別の語に差し替えるだけ」に入らないと書きました。語の例は SKILL.md に入れず、references/calques.md に置きました。 - references/calques.md に型4（1章）、残す形（3章）、書き方（4章。バージョン、先頭、冒頭、指摘 など、分野で定着した呼び名で書き、何を指すか決まらなければ本文を残して尋ねる）と、自作の例の行（5章）を足しました。 - references/review-points.md に、diff の新しい節の見方を足しました（原文、資料、依頼のどれにもいない人や担当なら原文の書き方に戻し、依頼で言われた人なら残す）。 - references/doc-types/slides.md 2章に、見出しと1行の箇条で外す読点と残す読点を足し、4章に自作の例の行を足しました。1章には、スライドの前と後に付いた依頼者あての前置きや注記（仮の値の断り、続けて作れるという申し出など）を推敲せずに残すことを足しました。references/review-points.md と references/audience.md に slide_comma の見方を足しました。SKILL.md は変えていません。 ### yomiyasu 自身の文章（自己回帰） - SKILL.md、references、README、docs で、yomiyasu 自身の言葉づかいの型4の語を言い換えました（「印」126か所、「頭」29か所、「版」35か所、「段」7か所、CLI の出力を引いた所15か所）。「lint の印」は「指摘」に、文の中の語や記号を指す「印」は「文の種類を表す語」「引用の書き方」などに、「頭」は「先頭」「冒頭」に、「版」は「バージョン」に、「見出しの段」は「見出しのレベル」にしました。 - そのあと、このバージョンの lint を yomiyasu 自身の文書と、スクリプトのコメント、docstring、文の形の出力の文字列にかけ、出た指摘を直してからもう一度かける、を新しい指摘が出なくなるまでくり返しました。指摘は482件から284件になりました。スクリプトのコメントなどは315件から125件、文書は167件から159件です。残した指摘は、規則の例として引いた語、決まりの文として正しい「〜します」の続き、意味を担う否定などで、1件ずつ理由を記録しています。直した前後は diff で照らし、意味が変わる恐れが出たのは、意図した直し（例の数や引用の文の言い換え）だけでした。 - 「の」で受けずに単独で使う連用形名詞（並べを区切る所、補いが残れば など）も、SKILL.md、references、README、docs の文から直しました。 - README の Codex 向けの入れ方を、前のフォルダを消さずに `.agents/skills` の外へ移してから置き換え、取り出しに失敗したら止まる手順にしました。手順の文字列をそのまま一時フォルダで動かす試験（tests/test_readme_install.py）を足しました。README から登録用 ZIP のファイルの数を外し、入れたフォルダの中の書き換えは更新で残らないこと、フックの設定は、今の設定を置き換えずに書き加えることを書きました。 - docs/limitations.md の古い数を直しました。tests/corpus の古い推敲の48組で、2つ以上のモデルが意味が変わったとした31か所は、2.3.0 の diff ではすべて全文差分に出て、意味が変わる恐れに同じ文で出たのは2か所でした。31か所のうち19か所（原文にない担当者を足した所）は、このバージョンの新しい節にすべて出ます。 ### 更新するときの注意 - 推敲の結果が変わります。lint の終了コード、`--strict` と `--fail-on` の判定、`rule_penalty_score` は変わりません。lint の見直し候補の件数と JSON の findings には、型4の calque（info）と、`--doc-type slides` のときの slide_comma（info）が加わることがあります。 - diff と check の人が読む出力の言葉が変わります（上の「diff と check」の最後の項）。JSON のキー、rule、kind、subkind、status、code の値と `*_FORMAT_VERSION` は変えていません。値の文が変わるのは、lint の `findings[].message`（bold_not_rendered と say_hedge）、diff の `structure[]`（見出しのレベル）、check の `checks[].error` と verify の `problems[].detail` です。diff の JSON に `added_actors` のキーが加わります。 - 2.3.0 で残した検査の記録を 2.4.0 の `verify` で照らすと、検査のスクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 確かめたこと - lint の型4: 人のニュース記事（livedoor ニュースコーパス、7,367本、約900万字）と tests/corpus の163本で0件でした。Claude に素で書かせた48本では4件で、どれも文書の別の稿（「短い版」「管理職向けの版」など）を指す、version の意味の「版」でした。自作の直訳の文22本のすべてに指摘が出て、残す文33本には1本も出ませんでした。15語の表の試験（語ごとに直訳の文と文字どおりの文を1つずつ）でも、指摘が出たのは版、印、頭の直訳の文だけでした。 - 原文にない人や担当の節: tests/corpus の古い推敲の48組で、2つ以上のモデルが意味が変わったとした、担当者を足した所19か所のうち19か所が出ました（語の一覧はこの48組を見て作ったので、高めに出ます）。推敲の組1,415組で候補が出たのは20組で、どれも原文にない人を足したものでした。2.1.3 から 2.4.0 の推敲の出力1,046本では0本でした。 - 推敲（Claude Code、Claude Opus 5.5）: 漢字1字の直訳語を含む合成の下書き10本と、実際の下書き2本を、2.3.0 と 2.4.0 で3回ずつ推敲しました。版、印、頭を直しも尋ねもせずに残した数は、のべ45か所のうち 2.3.0 で19か所、2.4.0 で0か所でした（7か所は尋ねました）。段、窓、帯、床の直り（のべ27か所）、残すべき形を変えなかったこと（のべ39か所）、diff の意味が変わる恐れの数（4件と4件）は変わりませんでした。図の「箱」は 2.4.0 でも直らなかったので、この語の書き方の1行は入れていません。 - 受入評価: 作者が書いていない業務の依頼16本で、素の Claude（Opus 5.5 と Sonnet 5.5）に下書きを書かせ、候補を作る前に封をしました。この16本をスキルなし（1回）、2.3.0（3回）、2.4.0（3回）で推敲し、どれがどの推敲かを伏せて、Claude Opus 5.5 と Gemini 4 Argon の2つの判定役が原文と読み比べました。2.3.0 と 2.4.0 は、それぞれのべ48本です。 - 意味・責任・条件が変わった所: Claude の判定で14か所から12か所（そのうち読み手の判断が変わりうるものは0か所から1か所）、Gemini の判定で9か所から6か所。 - 新しい誤り: 0か所から1か所と、1か所から0か所。要らない変更: 93か所から90か所と、131か所から132か所。 - 読みやすさの点（5点満点）の合計: 191から190と、199から202。2つを並べて読んだときに 2.4.0 を上にした数: 48組のうち25組と27組。 - 2.3.0 と 2.4.0 の差は、同じバージョンでも回ごとに動く幅と同じくらいです。スキルなし（16本）は、意味が変わった所が28か所と36か所、要らない変更が88か所と132か所でした。 - 1本あたりの費用（API の定価に換算した値の中央値）は、スキルなし $0.11、2.3.0 $0.58、2.4.0 $0.60。時間の中央値は24秒、55秒、58秒でした。 - スライドの見出しの読点: 自作の文で、外す読点のある見出しと箇条30行のすべてに slide_comma か pause_comma が出て、残す読点のある43行には出ませんでした。作者が登壇の見出しから手で読点を外した例では、外した7行のすべてに出て、外したあとの見出しには出ませんでした。素の Claude（Opus 5.5 と Sonnet 5.5）に書かせたスライドの下書き12本を、この決まりを足す前と後で3回ずつ推敲しました（Claude Code、Claude Opus 5.5、依頼は「draft.md はスライドの原稿です。yomiyasu で読みやすくして…」）。 - 見出しと箇条の行の読点は687個から651個に、推敲の後の slide_comma の指摘は29件から2件に減りました。下書きの見出しと箇条にある残す読点（逆接、条件、理由。11か所）を外した所は、のべ33か所のうち0か所と0か所です。 - diff の意味が変わる恐れは10件から0件になりました。前の10件は、どれも下書きの前後に付いた依頼者あての注記（仮の例の断りや、誤記の補足など）を推敲で外したもので、スライドの本文では前も後も0件です。下書きの前後の注記の行（のべ51行）は、前は23行、後は50行がそのまま残りました。 - どれが前でどれが後かを伏せて、Claude Opus 5.5 の判定役が読み比べました。本文の意味が変わったとして反証のあとも残ったのは1か所と0か所（後の1か所は決めきれないとされました）、新しい誤りは0か所と0か所です。残る間を作るだけの読点は79個と46個、スライドとして読みやすいとしたのは36組のうち6組と20組（同じが10組）でした。判定役が残すべきとした読点を外した所は2か所と5か所で、後の5か所は、外すと掛かり先が変わって読める「既存コードには、触った箇所だけに…」の1文（3回とも）と、「大事なのは、〜より〜」の1文（2回）でした。 - 測りは5回くり返しました。1回目に、主題のあとに別の主語が続く読点など4か所を推敲が外したので、slides.md の残す読点を直しました。そのあと、コミットの前に別の確かめ役が見て出した指摘（残す読点への誤った指摘、入れ子の箇条などへの指摘の漏れ、message の当たった言い方の崩れ）と、推敲の後に残った「〜ときは」「〜場合は」と長い主語への指摘を直しました。最後に、推敲が下書きの前後の注記を外していたので、slides.md に注記を残す決まりを足して測り直しています。slides.md に足した例の1つは、測った下書きの1文と同じ形です。 - 出力の答え合わせ: 2.3.0 と 2.4.0 の lint、diff、check の CLI を同じ4,939件の入力で動かし、バージョンの文字列をそろえて比べました（Python 3.14.5 と 3.9.6）。終了コードはすべて同じでした。出力が違った1,633件は、どれも上の変更（型4の指摘とその件数、slide_comma の指摘とその件数、新しい節と added_actors のキー、出力の言葉の言い換え）で説明がつきました。slide_comma を足す前の 2.4.0 の候補と比べて違ったのは、`--doc-type slides` の lint の2件だけでした。Python 3.14.5 と 3.9.6 の出力は4,939件すべて同じでした。 - 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,350件ずつ通りました（どちらも、Linux だけで動かす試験2件を飛ばしています）。tests/test_v240_kanji1.py、tests/test_v240_added_actor.py、tests/test_v240_pycache.py、tests/test_v240_slide_comma.py、tests/test_readme_install.py を足しました。 ### 限界 - slide_comma は、読点の前と後の語の形で拾います。外すと読み違える読点かどうかは見分けないので、推敲で1つずつ確かめます。1行で終わる60字以下の段落の行も見るので、スライドの中の短い地の文の読点にも指摘が出ます。主題のあとの主語は語の形で見分けるので、ひらがなで終わる名前など、形の決まらない主語のあとの読点にも指摘が出ることがあります。主題の「には」のあとに動詞が続き、外すと掛かり先が変わって読める読点（既存のコードには、触った所だけ…）にも指摘が出ます。推敲がそのまま外すことがあります。 - 型4は「版」「印」「頭」の3語だけで、文の条件に合わない使い方（検査の語のない文の「印」など）は拾いません。ほかの漢字1字の直訳（段、窓、帯、系、口、床、穴、枠、箱、旗、門、組）は、推敲の手順に任せています。 - 原文にない人や担当の節は、語の一覧と、主語か相手かの形で拾います。一覧にない役割の名前と、依頼の文にだけ書いてある人は見分けられません（依頼は diff から見えないので、節は「依頼で言われた人なら残す」と書いています）。一般の担い手（開発者、利用者、全員 など）を足した所は、モデルの判定と合う割合が低いので、意味が変わる恐れの件数には入れていません。 ## 2.3.0 - 2026-10-24 推敲の結果が変わるバージョンです。他動詞の連用形を1語だけ名詞にした語を「の」で受ける形（「結果の確かめ」「二つの案の比べ」）を lint の印で見つけ、目的語と動詞の文か、定着した漢語の名詞に直す手順を加えました。あわせて、SKILL.md、references、README、docs の文から、この形を直しました。diff は、同じ段落を120回、240回とつないだ文書と、段落ごとに少し変えた写しをつないだ文書で、2.2.2 よりもう少し速くなりました（30回、60回ではほとんど変わりません。出力は、版の文字列のほかは変わりません）。 ### きっかけ - 日本語の連用形名詞についての研究（蔡盛植「日本語動詞連用形への構文論的アプローチ —『動詞連用形』と『連用形名詞』との相関関係を中心に—」日本研究 第21集、2014）を、yomiyasu を使っている方に教えていただきました。他動詞の連用形を1語だけ名詞にした語は、名詞としての自立性が弱く、目的語を「の」で受ける形では使いにくい。名詞とくっつけた複合語、複合動詞から来た語、漢語の動詞的名詞、「お」を付けた形、意味が変わって定着した語は成り立つ、という内容です。 - 測った結果は次のとおりです。 - Claude（Opus 5.5 と Sonnet 5.5）に、空のフォルダで24種類の日本語の文章を書かせた48本（約10万字）には、この形は0回でした。ふつうは「確認」「比較」のような漢語の名詞を使います。 - 漢語を避けて和語で書いた文（yomiyasu の SKILL.md、references、README、docs、CHANGELOG、引き継ぎの資料と、開発の会話の返答。約138万字）では、「の直し」169回、「の確かめ」135回、「の比べ」76回、「の補い」50回、「の決め」48回、「の測り」37回などが出ていました。 - 人のニュース記事（livedoor ニュースコーパス、7,367本、約900万字）では、これらの語が「の」のあとに来る形は0回でした。答え（66回）、備え（21回）、教え（14回）、問い（13回）、調べ（8回）のように名詞として定着した語は、人もふつうに使います。 - 2.2.2 は、この形を直さないことがありました。この形を含む合成の文書5本を 2.2.2 で3回ずつ推敲すると、狙う形のべ66か所のうち2か所（どちらも「の直し」）が、確かめたい点にも挙がらずにそのまま残りました。 ### lint - 規則 `renyo_noun`（info）を足しました。`references/lists/renyo-nouns.txt` の語（確かめ、直し、比べ、測り、補い、決め、選び、集め、探し、整え、そろえ、外し、戻し、消し、伏せ など48語。「そろえ」と「揃え」のような書き分けは、別々の語として数えています）が「の」のすぐあとに来て、そのあとに助詞（が、を、は、に、で、から、など、だけ など）か、句読点か、閉じ括弧か、行の終わりが続く所に、1行に1件の印をつけます。指示語で受ける形（「その確かめは」）にも当てます。message には当たった言い方（「の確かめ」など）を出し、置き換え先の語は出しません。見出し、表、箇条書きも見ます。当てる文書の種類はすべてです。 - 当てないもの: 名詞とくっつけた複合語（資金集め、手直し）、複合動詞から来た語（見直し、組み合わせ、洗い出し）、「お」「ご」を付けた形（お選び）、動詞に続く形（入れやすい、確かめにくい、決めがたい）、「生活の足しになる」「試しに」の「に」、カギ括弧と引用符の中、引用、コード、英数字の識別子。別の意味で名詞として定着した語（住民票の写し、合格の知らせ、詰めが甘い、法律の定め、顧客の求め、欠勤の届け、相場の上げ、駅までの送り、漢字の書き、情勢の読み、警察の調べ、キッチン用の計り など）は一覧に入れていません。 - 印は `--strict` と `--fail-on` の判定にも、`rule_penalty_score` にも入りません。語の一覧の `allow.txt` に書いた語は、この印からも外れます（1行に1件で語を並べるので、許した語だけを除きます）。 - 一覧がないか読めないときは、yomiyasu_lint.py の中の同じ一覧で動きます。check は一覧のハッシュ（SHA-256）を記録に残し、一覧を変えると `verify` は `tool_changed` になります。 ### 推敲の手順 - SKILL.md「主語と目的語の明確化」に1段落を足しました。この形は目的語と動詞の文に戻すか（結果を確かめる）、定着した漢語の名詞にします（結果の確認）。複合語として定着した語、複合動詞から来た語、「お」を付けた形、別の意味で定着した語は残します。漢語を和語にひらくときも、この形を作りません。references/review-points.md に印の見方を足しました。 - SKILL.md と references の文から、この形を直しました（SKILL.md 12行、references 16行。references の行には、一覧の注記の1行を含みます）。文書の種類の表の項目（「〜の直し」→「〜の修正」）、地の文（「替えるだけの直しはしません」→「替えるだけでは済ませません」）などです。返答の欄の名前「事実の確かめ」は、出力の形を変えないために残し、references では名前として「」でくくりました。README と docs の文も同じように直しました（README 4行、docs 19行）。合わせて51行で、lint の印がつかない所（「何の直しか」のように「か」が続く形、コードの囲みの中、HTML の行）を手で直した3行を含みます。 - 漢語の名詞にする直しが、lint の印の語を別の語に差し替えるだけの書き換えに入らないことを SKILL.md に書き、diff の文体の硬化の候補に出てもこの形に戻さないことを、SKILL.md と references/review-points.md に書きました。 - SKILL.md は 42,982字から 43,378字になりました。既存の規則と見出しは削っていません。 ### 更新するときの注意 - 推敲の結果が変わります。lint の終了コード、`--strict` と `--fail-on` の判定、`rule_penalty_score` は変わりません。lint の見直し候補の件数と JSON の findings には、この形があると `renyo_noun`（info）が加わります。 - lint の JSON の `context.words.allow_removed` に `renyo_noun` のキーが加わります（語の一覧を使うとき）。check の記録の `tools` に `references/lists/renyo-nouns.txt` のキーが加わります。既存のキーと値の意味、`*_FORMAT_VERSION` は変えていません。 - 2.2.2 で残した検査の記録を 2.3.0 の `verify` で照らすと、検査のスクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### diff - 消えた文を、書き直したあとの文と組にする処理を速くしました。同じ段落を何十回も繰り返す文書では同じ文が何度も消えますが、2.2.2 までは、消えた文ごとに、書き直したあとの文との近さを数え直していました。今は、消えた文の2文字の組の集合ごとに1回だけ数えて使い回します。組の候補はあとで近さの順に並べ直すので、出力は 2.2.2 と1字も変わりません（`tool_version` と `--version` の版を除く）。check の run も同じ処理を使います。 - 時間は次のとおりです（Python 3.14.5、macOS、ほかの処理も動いている同じ機械で、版ごとに交互に3回ずつ動かした中央値）。 | 文書 | 2.2.2 | 2.3.0 | |---|---|---| | 1,257字の技術メモを空行でつないだ文書（120回、約15万字）の diff の CLI（`--json`） | 1.71秒 | 1.62秒 | | 同じ（240回、約30万字） | 3.76秒 | 3.39秒 | | 同じ文書の check run（`--no-record`、120回） | 1.97秒 | 1.86秒 | | 同じ（240回） | 4.01秒 | 3.64秒 | | 段落ごとに少し変えた写しを120回つないだ文書の diff の CLI | 2.31秒 | 1.66秒 | | 繰り返しのない37万字の文書の diff の CLI | 1.67秒 | 1.66秒 | | 推敲の出力48組を9回つないだ文書の diff の CLI | 2.36秒 | 2.35秒 | 30回と60回では、diff が0.49秒から0.48秒、0.89秒から0.87秒で、ほとんど変わりません。2.1.3 と 2.3.0 を同じように交互に3回ずつ動かすと、120回の文書の diff は15.47秒から1.59秒、check run は15.77秒から1.84秒、繰り返しのない37万字の文書の diff は1.64秒から1.63秒でした（上の表とは別の回なので、2.3.0 の時間が0.02〜0.03秒ずれます）。 ### 確かめたこと - lint の印は、次のように確かめました。 - 人のニュース記事（livedoor ニュースコーパス、7,367本、約900万字）、Claude に素で書かせた48本（約10万字）、tests/corpus の163本（約5万字）で、印は0件でした。途中の候補では、livedoor で誤った印が2件出たので（「キッチン用の計り」「力の入れやすい」）、「計り」「量り」を一覧から外し、語のあとに続く字を絞りました。 - 合成の文84文（狙う形43文、残す形41文）で、狙う形のすべてに印がつき、残す形には1件もつきませんでした。 - 印の多い文書（18.5万字、印5,000件）を2倍ずつ大きくすると、lint の CLI の時間は0.17秒、0.26秒、0.46秒、0.87秒で、文書の長さに比例しました。100万字のニュース記事の lint は、2.2.2 と同じ0.69秒です。 - 推敲は Claude Code（Claude Opus 5.5）で行い、どちらの版かを伏せて、2つの判定役（Claude Opus 5.5）が読み比べました。 - この形を含む合成の文書5本（狙う形22か所）を3回ずつ推敲すると、のべ66か所のうち、直したか書き手に尋ねた所は、2.2.2 で64か所、2.3.0 で66か所でした。残すべき形を誤って直した所は7か所から3か所に減りました。意味が変わった所は、1つ目の判定で0か所のまま、2つ目の判定で1か所から0か所です。 - 推敲の手順を作るあいだ開かずにおいた合成の文書1本（狙う形5か所）は、3回とも、両方の版で5か所すべてを直しました（のべ15か所）。 - 2.2.0 と 2.2.1 で確かめたときに使った5本（直訳語の文書4本と tests/corpus の1本）を4回ずつ推敲すると、直訳語の40か所（4回でのべ160か所）のうち、直したか尋ねた所は、1つ目の判定で145か所から148か所、2つ目で145か所から146か所でした。残すべき形を誤って直した所は、両方の版で0か所です。判定役が「推敲で「の」のあとに連用形名詞を置く形を新しく作った」と数えた所は、どちらの判定でも2か所から0か所でした。2.2.2 は4回とも、原文の見出し「注文データの受け口」を「注文データの受け取り」（3回）か「注文データの受け付け」（1回）に替えていて、判定役はそのうち2回ずつを数えました。どちらも複合動詞から来た語で、印をつける形ではありません。 - 同じ5本で、意味が変わった所は、1つ目の判定で10か所から11か所、2つ目で8か所から10か所に増えました。同じ版でも2回ずつの組で数が動き（1つ目の判定で、2.2.2 は4か所と6か所、2.3.0 は6か所と5か所）、どちらの版にも同じ種類の変化が出ているので、この差は回ごとの揺れの中にあると見ています。 - 上の推敲は、開発の途中の候補で行いました（合成の5本は最初の候補、ほかは2つ目の候補）。そのあと、印のつけ方の細部と、SKILL.md と references の文を直しました。最後の版でも、合成の5本と開かずにおいた1本を1回ずつ推敲し、印のついた19行（当たった言い方は28か所）は、すべて書き直されました。残すべき形20のうち2つは複合語になりました（境界の値→境界値、接続の上限→接続数の上限。境界値は 2.2.2 の推敲にも出ています）。この回は判定役に読ませず、lint と文字列の照合だけで確かめました。 - 出力は、次のように前の版と突き合わせました。 - 2.2.2 と 2.3.0 の lint、diff、check の CLI を、同じ4,939件の入力（同じ段落を繰り返す文書を含む）で動かし、版の文字列をそろえて比べました（Python 3.14.5 と 3.9.6）。diff の2,136件はすべて同じでした。違ったのは check の66件と lint の4件で、どれも renyo_noun の印と、件数の行だけの違いでした。 - 実際のモデルの推敲など1,415組では、diff の出力はすべて同じでした。lint の JSON が違った22組は、ほかの候補、点数、warn と error の件数が同じで、renyo_noun の印と info の件数だけが違いました（Python 3.14.5 と 3.9.6）。 - 消えた文を組にする処理の新しい書き方を、前の書き方を写した参照の関数と無作為の1,800組で突き合わせ、食い違いはありませんでした（tests/test_v230_pair_gone.py にも同じ形の突き合わせを入れました）。 - 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,305件ずつ通りました（どちらも、Linux だけで動かす試験2件を飛ばしています）。tests/test_v230_renyo_noun.py と tests/test_v230_pair_gone.py を足しました。 ### 限界 - 「直しは1回までです」のように「の」なしで単独で使う形と、「確かめの道具」のように前に「の」がなく、あとに「の」で名詞を続ける形には、印をつけません（前に「の」がある「結果の確かめの道具」には印がつきます）。語のあとに「か」や「だ」が続く形（「結果の確かめか」「案の比べだ」）と、HTML の行（`` など）にも、印をつけません。一覧にない語にも印をつけません。 - 一覧の語でも、分野によっては別の意味で定着しています（仕立ての「直し」など）。印は info なので、文脈を見て残してください。プロジェクトで定着している語は `allow.txt` に書けば外れます。 - ふつうの Claude の文章にはこの形がほとんど出ないので、ふつうのAIの下書きを推敲するときの効き目は小さいと見ています。効くのは、漢語を避けて和語で書いた文と、漢語を和語にひらく書き換えです。 ## 2.2.2 - 2026-10-23 同じ段落を何十回も繰り返す文書で、diff を速くしたバージョンです。lint、diff、check、フックの出力は 2.2.1 と1字も変わりません（`tool_version` と `--version` の版だけが 2.2.2 になります）。 ### 変更 - diff: 同じ段落を何十回も繰り返す文書で、推敲の前と後を照らし合わせる処理が、段落の数の2乗に近く遅くなっていたのを直しました。一致の右に残る範囲で一致を探すたびに、残りのすべての段落を調べていたためです。2.0.1 から、範囲ごとに一致の長さの上限を求めて探しており、上限と同じ長さを探す段で見つかる一致は、長さが上限ちょうどのものだけです。今はこの段で、原文の前から見て最初に一致が見つかったところで探すのをやめます。種で探すどの段でも、一致を伸ばす長さは上限までで止めます。difflib と同じ答え（いちばん長い一致で、同じ長さなら原文で前のもの、それも同じなら最終稿で前のもの）は変わりません。check の run も同じ照合を使うので、同じように速くなります。 - 時間は次のとおりです（Python 3.14.5、macOS、ほかの処理も動いている同じ機械で、2.2.1 と 2.2.2 を交互に3回ずつ動かした中央値）。 | 文書 | 2.2.1 | 2.2.2 | |---|---|---| | 1,257字の技術メモを空行でつないだ文書（30回）の diff の CLI（`--json`） | 0.90秒 | 0.47秒 | | 同じ（60回） | 5.30秒 | 0.87秒 | | 同じ（120回、約15万字） | 15.49秒 | 1.68秒 | | 同じ文書の check run（`--no-record`、120回） | 15.85秒 | 1.95秒 | | 段落ごとに少し変えた写しを120回つないだ文書の diff の CLI | 14.25秒 | 2.27秒 | | 繰り返しのない37万字の文書の diff の CLI | 1.66秒 | 1.66秒 | | 推敲の出力48組を9回つないだ文書の diff の CLI | 2.40秒 | 2.35秒 | check run は、30回で1.14秒から0.72秒、60回で5.55秒から1.11秒になりました。答え合わせの1,415組を、1つのプロセスの中で 2.2.1 と 2.2.2 の diff に1回ずつ交互にかけた時間の合計は、6.48秒から6.33秒で、2割と10ミリ秒を超えて遅くなった組はありません。 ### 更新するときの注意 - 既存の JSON のキーと値の意味、`*_FORMAT_VERSION`、記録の形、コマンドの引数と既定値、状態の行の形は変えていません。 - 2.2.1 で残した検査の記録を 2.2.2 の `verify` で照らすと、検査スクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 確かめたこと - 2.2.1 と 2.2.2 の lint、diff、check の CLI を同じ4,939件の入力（同じ段落を繰り返す文書を含む）で動かし、版の文字列をそろえて比べました（Python 3.14.5 と 3.9.6）。標準出力、標準エラー、終了コードは4,939件すべて同じでした。 - 実際のモデルの推敲など1,415組で、diff のテキストと JSON（文書の種類なし・article・mail・pr・essay）と lint の JSON を、版の文字列をそろえて 2.2.1 と比べ、Python 3.14.5 と 3.9.6 のどちらでも違いは0組でした。 - 新しい照合を、difflib と無作為の入力（同じ段落の繰り返しを含む）で突き合わせ、121,635組で食い違いはありませんでした。 - 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,291件ずつ通りました（どちらも、Linux だけで動かす試験2件を飛ばしています）。`tests/test_v201_fast_match.py` に、繰り返しの段落の組を difflib と突き合わせる試験と、200段落の組で伸ばす種の数が限られることを見る試験を足しました。 ## 2.2.1 - 2026-10-23 2.2.0 の直訳語の印と書き直し方の抜けを直したバージョンです。2.2.0 を、手順を直すときに見ていない新しい文書で確かめたところ、次の3つが見つかりました。 - 技術の文書で、同じ文に技術の語がない「入口」（「外部から届く要求は、ひとつの入口に集めています。」）と、前に来る語が一覧にない「全〇〇に響く」（「全運転手に響きます。」）に、直訳語の印がつきませんでした。 - 「全クライアントに響きます」のような印のついた文を、「影響します」「負荷が及びます」のような意味の広い語に替えるだけで、後ろの文に書いてある中身（画面の表示が遅くなる、など）を使わない推敲がありました。 - 見出しの印のついた語（語の一覧の flag.txt の語を含む）を、本文の題目を並べただけの項目名に替え、元の見出しが言っていた目的が落ちる推敲がありました。 あわせて、印のついた語を残したときに、書き手に尋ねずに理由だけを書いて済ませる推敲が続いたので、check が残した印の語を知らせるようにしました。 ### lint - 技術の文書では、同じ文に技術の語がなくても、入口より前に要求や呼び出しの主題（要求は、呼び出しは）がある文の、それを集めたり通したりする形の「入口」「出口」（要求は、どれもこの入口を通ります、外部から届く要求は、ひとつの入口に集めています）に `calque` の印をつけます。技術の文書かどうかは、直訳語の判定に使う技術の語のうち、画面、通知、フォームのような案内や行事の文書にも出る語を除いた語が5種類以上あるかで決めます。 - この新しい印は、入口と出口の前の語が実物の場所の語（駐車場、学校、北側、団地 など）のときと、入口の前で人が待つ形（入口の前でお待ちください）、入口の前の物（入口の前のインターホン）、人を呼ぶ文や人の要求の文（来客の呼び出しがあったら、組合の要求を受けて）には、つけません。 - 同じ文に技術の語がある入口と出口は、2.2.0 のとおりに見ます。ただし、サーバールーム、サーバー室、データセンターのような機械を置く部屋の入口と出口には、実物の場所として印をつけなくなりました（2.2.0 では、名前の中の技術の語で印がついていました）。 - 技術の文書で、機械やシステムの語（貸出機、券売機のような機械の名前を含む）がある文の「全〇〇に響く」（全運転手に響きます、全店舗に響く可能性があります）に `calque` の印をつけます。音や言葉の名詞が続く形（全社員に響く言葉、全館に響くチャイム）、響き渡る、響くほど、響くように、音や言葉が主語の文（警報が鳴り、全フロアに響きます）、全身の響き、安全性や全然の「全」には、印をつけません。前からある語の一覧の形（全クライアントに響く、全費用に響く）と、ほかの句（全3ターン の「ターン」など）は、2.2.0 のとおりに見ます。 - 型3の句と入口の判定は、文ごとに決まる値を1文につき1回だけ求めます。とても長い1文の文書でも、2.2.0 と同じくらいの時間で終わります。 - 印は info のままです。lint の終了コード、`--strict` と `--fail-on` の判定、`rule_penalty_score` は変わりません。tests/corpus の文書と自作の類例の194本と、手元の実際の文書1,116本では、2.2.0 と比べて印は1つも変わりませんでした。 ### check - 最終稿に直訳語（`calque`）と語の一覧（`project_term`）の印が残っていると、run は頭の一覧のあとに「残した印の語: 要求（語の一覧。L9、L25）、…」の行を、「■ 意味が変わる恐れ」のあとに「■ 残した印の語」の節を出します。節には、書き直すか、名前や動作、その動作をする人がどこにも書いていなければ「書き手に確かめたい点」で尋ねるか、定着した言い方や文字どおりの意味で残すなら理由を「残したAIっぽいところ」に書くか、の見分け方を書きます。問いの3点の上限と、本文だけを返す指定のときの扱いも書きます。verify も、記録と合ったときに同じ語を5行目に出します。 - 同じ語に直訳語と語の一覧の両方の印があれば、語の一覧として1つにまとめて出します（定着していても残さない決まりが先です）。 - `--json` の run と verify と、記録の lint の要約に `kept_marks` が付きます。形式の版は上げていません。 - 語は lint の候補から取り、lint を流し直しません。run の中では1回だけ数え、行は集合で持つので、手間は候補の数に比例して増えるだけです（30万字の箇条書きでも 2.2.0 と同じ時間でした）。`--replay` なしの verify は記録を読むだけです。 - この行と節は、尋ねたかどうかを check が確かめるものではありません。状態、終了コード、`--fail-on` の判定は変わりません。印が残っていない最終稿の出力は、2.2.0 と同じです。 ### 推敲の手順（references/calques.md、SKILL.md） - 印のついた語を、何が起きるかを言わない意味の広い語（影響する、及ぶ、支障が出る、関わる、左右する）に替えるだけにしないこと、後ろの文に何がどうなるかが書いてあればその中身で書くこと、広い語の句を中身と並べて残さないことを書きました。 - 見出しに印のついた語があるときは、本文の語で項目名を作り、元の見出しが言っていた目的を項目名に残すことを書きました。 - 書き直しに使う名前と動作に、その動作をする人を足しました。原文、依頼、提供資料、文脈のどれにも書いていなければ、本文を残して尋ねます。印のついた語と後ろの文とで呼び名がそろわず、同じものを指すか分からないときも、本文を残して尋ねます。 - 語の一覧の flag.txt の語は、替える名前がどこにもなければ、「〜もの」のような広い言い方に替えず、本文を残して尋ねることを書きました。 - SKILL.md の Step 5 に、check の「残した印の語」を見て、尋ねるか残す理由を書くことを書きました（42,853字から42,982字）。references/review-points.md に、その節の見方を足しました。 - 合成の例: 入口が何を指すかを書いた文がない場合の扱いを、本文を残して尋ねる形に直し、「全店舗に響く」の例を2つ（中身が後ろの文にある場合と、ない場合）足しました。 ### 確かめたこと - 試験一式: macOS の Python 3.14.5 と 3.9.6 で2,289件ずつ通ります（Linux だけで動かす2件を飛ばします）。新しい試験は `tests/test_v221_*.py` です。 - CLI の前後の比べ: 2.2.0 と同じ4,875件で比べました。Python 3.14.5 と 3.9.6 のどちらでも、lint の2,088件と diff の2,088件は同じでした。違いの352件はすべて check で、「残した印の語」の行、節、`kept_marks` を除くと同じになります。 - 直訳語の対応表の17行の検査: 対応表の場面に似せて書いた自作の文書 A、D〜H（D は 2.2.0 の確かめに使った文書、E〜H は直す途中で書き足した文書）を、Claude Code（claude-opus-5-5、effort high）で3回ずつ、Codex（gpt-6-astra、effort high、普通の速さ）で A、D、G、H を3回ずつ推敲し、どちらの道具かを伏せて読み比べました。H は最後の直しの前に書き、2.2.1 の最後の版で初めて推敲しました。17行が「直した後」と同じ中身になったか、文書に名前がないものを尋ねたかを見て、外れたのは G の Claude Code の1回の1行だけでした（「要求」の替える呼び名を尋ねた形で、判定者も解釈が分かれるとした）。E と F の Codex は、途中の版で測り、外れはありませんでした。 - 推敲の前後の比べ（Claude Code）: 直訳語の自作の類例4本と tests/corpus の1本を 2.2.0 と 2.2.1 で推敲し、どちらの版かを伏せて読み比べました（返答の「書き手に確かめたい点」も読みました）。直したか尋ねた件数は40件のうち、2人の判定でそれぞれ34件から35件、39件から40件でした。意味が変わった件数は、diff の候補で1件のまま、全文を読んでそれぞれ3件から0件、2件から0件で、残すべき書き方を誤って直した件数は0件のままでした。 ## 2.2.0 - 2026-10-23 推敲の結果が変わるバージョンです。推敲しても残りやすい言い方を lint の印で見つけ、文脈を見て直す手順を足しました。直訳語、見出しと1行目の比喩ラベル、「〜と言えるでしょう」、中身の薄い評価の文、意味の薄いカタカナ語、台詞の句点、読み物の一人称と数字、キャッチコピーの読点、主語も目的語もない他動詞の並びです。 - 直訳語は、型で拾うのが主です。プロジェクトの語の一覧（`.yomiyasu-words/` の `allow.txt` と `flag.txt`）の役目は、誤った印を外すことと、プロジェクトの事情を足すことです。 - 印はどれも info です。印に当たっただけでは直さず、文脈を見て、誰が何をどうするかを書き直します。印のついた語を別の語に差し替えるだけの直しはしません。書き直しに要る名前や動作が原文にないときは、本文を残して書き手に確かめます。 lint の終了コード、既存の JSON のキー、`*_FORMAT_VERSION`、引数の既定値は変えていません。新しい印は info なので、`--strict` と `--fail-on` の判定にも、`rule_penalty_score` にも入りません。 ### 推敲の手順に足したこと - SKILL.md Step 2 に、lint の印の扱いと、直訳語の2つの問い（その分野の人が自分で書くときに使う呼び名か、英語に戻すと一語ずつ英語の言い方に対応するか）を足しました。型と書き直しの例は新しい `references/calques.md` に、印ごとの見方は `references/review-points.md` にあります。calques.md には、印のついた語の中身を後ろの文が書いていればその中身で書き直すこと（まとめるときは「だけ」などの範囲の語を落とさない）、英語を一語ずつ写した句は英語の言い方（「足すものがない」は add value、「〜ときに効くのは」は what matters）の意味で書き直すことを、合成の例と一緒に書きました。 - Step 1 に、語の一覧を読み、allow.txt の語は直さず、flag.txt の語は直訳語と同じ問いで確かめることを足しました。flag.txt の語は、そのプロジェクトで見直すと決めた語なので、組み込みの一覧で残す言い方（依存先など）や辞書の訳語の名詞（要求、承認など）でも、定着していることを理由に残さず、文として書き直すか、名前が分からなければ尋ねます。Step 5 に、最終稿に残った info の印（毎回同じ語につく印）を一つずつ確かめ、直訳語と語の一覧の印が残っていればその文を Step 2 の問いで読み直すことを足しました。 - 「案内用の見出し」に、本文に出てこない一語の比喩の見出しは本文の語で項目名を作ること、文書の題は変えず読めなければ尋ねることを足しました。「コピー調の抑制」に、キャッチコピーの読点と、当たり前の性質を目立たせる一句の2行を足しました。「主語と目的語の明確化」に、他動詞を読点で並べて止める文も同じ直し方をする1文を足しました。 - slop-catalog.md の6章「文末の付け足し」に「と言えるでしょう」の直し方（推量の「でしょう」を残して「と言える」だけを外す）を、5章に評価を言い直すだけの文、意味の薄いカタカナ語、見出しの比喩ラベルを、9章にキャッチコピーの読点と他動詞の並びを足しました。doc-types/essay.md に一人称と数字の読み物の扱いを足しました。 - SKILL.md は 41,445字から 42,853字になりました。既存の規則と見出しは削っていません。 ### lint: 新しい規則（どれも info） | 規則 | 見る型 | 当てる種類 | |---|---|---| | `calque` | 直訳語（型1: 機械やシステムが人の動作をする言い方、型2: 実物の名前の代わりの場所のたとえ、型3: 英語を一語ずつ写した句）。1行に1件で、message に型の番号と当たった言い方 | すべて | | `metaphor_label` | 見出しと文書の1行目の、本文に出てこない一語の比喩 | essay、promo、script を除く | | `say_hedge` | 文末の「と言えるでしょう」 | すべて | | `thin_evaluation` | 名詞がもともと持つ評価を述語で言い直すだけの文（`references/lists/thin-evaluation.txt`） | すべて | | `katakana_term` | 意味の薄くなりやすいカタカナ語（`references/lists/katakana-terms.txt`） | すべて | | `dialogue_period` | 台詞の最後の句点の割合（文書に1件） | script だけ | | `narrative_density` | 一人称が少なく、数字と箇条書きが多い読み物（文書に1件） | essay だけ | | `copy_comma_noun` | 修飾語と名詞のあいだに読点を打ち、短い名詞で止める形 | すべて（promo は文書の2回目から） | | `bare_verb_chain` | 主語も目的語もない他動詞を読点で並べて止める文 | essay、promo、script、slides を除く | | `project_term` | 語の一覧の flag.txt の語。message にその行の語 | すべて | - コードの中、引用、URL、カギ括弧と引用符の中、英数字の識別子は見ません。定着した言い方（テストが通る、キャッシュが効く、依存先など）は組み込みの一覧で外し、一覧は試験で守っています。 - `--doc-type` を指定したときの `context.skipped_by_doc_type` に、essay、promo、script、slides で外す新しい規則の名前が加わります（人が読む出力の4行目も同じ）。 - 4と5の値は、台詞が10個以上で、最後の字が「。」の台詞が5割以上（`dialogue_period`）、地の文が1,000字以上で、一人称が千字あたり1.0未満、数字と箇条書きの項目が千字あたり8以上（`narrative_density`）です。出発点の値のまま決めました。自作の類例では、AI の書き方の台本は「。」で終わる台詞が85〜93%、人の書き方の台本と境目の台本は0%と46%でした。AI の書き方の体験記は一人称が千字あたり0で、数字と箇条書きが千字あたり60以上、人の書き方のエッセイは一人称が6.1以上で、数字と箇条書きが3.4以下でした。tests/corpus には、台詞が10個以上の文書（いちばん多い文書でも12個で「。」は0個）と、地の文が1,000字以上の文書がなく、どちらの印も0件でした。 - 指示書の範囲7（「〜できる仕組み。」のように、何も説明しないで「仕組み」で終える文）の規則 `empty_shikumi` と推敲の手順は、入れませんでした。推敲の前後の比べ（下の「確かめたこと」）で、3回の測りのどれでも直せた文がなく（自作の類例の5文）、2回の測りで、前後の文が仕組みを説明している残すべき文を書き換えたためです。「仕組み」の扱いは、2.1.3 までと同じく SKILL.md「内容に合わない大げさな名詞の整理」に従います。 ### 文書の種類 script - 文書の種類に台詞・脚本（`script`。漫画のネーム、シナリオ、台本）を足しました。lint、diff、check の `--doc-type` に渡せます。指定しないときの動きと、既存の12の値は変えていません。 - 推敲では台詞の最後の「。」だけを外し、台詞の中の文と文の間の「。」、ト書きと地の文の「。」は残します。依頼で句点を打つ書き方を指定されたときは外しません。台詞の口調、言い回し、短い文の重ねは直しません（`references/doc-types/script.md`）。lint では fragment_run、sentence_end_repetition、metaphor_label、bare_verb_chain を外します。 ### プロジェクトの語の一覧 - git の最上位（git の外では作業ディレクトリ）の `.yomiyasu-words/` に置いた `allow.txt` と `flag.txt` を、lint、diff、check が同じ順で探して読みます。`--words フォルダ` で場所を指定でき、`--no-words` で読みません。フックは自分では探さず、受けた `--words` か `--no-words` を、案内する `yomiyasu_check.py run` のコマンドに付けます。1行に1語の UTF-8 で、`#` で始まる行と空の行は読み飛ばし、BOM と CRLF も読めます。UTF-8 でないファイルと1万行を超えるファイルは、ファイルの名前と行番号を出して終了コード2で止めます（フックは止めず、`hook-errors.log` に残します）。 - allow.txt の語は、calque、metaphor_label、katakana_term、project_term と、既存の metaphor_verb、translated_term、slop_vocabulary の候補から外し、外した件数を出します。1行に1件で行の語を並べる calque、katakana_term、project_term は、許した語だけを除き、ほかの語が残れば候補を残します。flag.txt の語には `project_term` の印をつけます。 - 一覧を使ったときだけ、JSON の `context` に `words` を足します（`path`、`allow_lines`、`flag_lines`、`allow_sha256`、`flag_sha256`。lint ではさらに `allow_removed`）。check の記録の `options` にも同じ値を残し、`verify --replay` は記録の一覧で lint と diff をやり直します。一覧がないときの出力は、新しい規則の候補のほかは 2.1.3 と同じです。 ### diff - 台詞の最後の「。」（閉じかぎかっこの前の句点）だけを外したか足した組（「見たのか。」→「見たのか」）は、問いと平叙の変化に数えなくなりました。台詞・脚本の推敲で出る誤った候補です。どの文書の種類でも同じで、この組だけの文書では `--fail-on=meaning-risk` の終了コードが1から0になります。 ### 変わらないもの - lint の終了コード、既存の JSON のキーと値の意味、`*_FORMAT_VERSION`、コマンドの引数と既定値、ファイルの場所、スキルの名前。 - 2.1.3 で残した検査の記録を 2.2.0 の `verify` で照らすと、検査スクリプトと一覧が変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 確かめたこと - 試験一式: macOS の Python 3.14.5 と 3.9.6 で2,262件ずつ通ります（Linux だけで動かす2件を飛ばします）。新しい試験は `tests/test_v220_*.py` です。 - CLI の前後の比べ: tests/corpus の163文書と300組に、2.2.0 の規則と script と語の一覧の入力を足した4,875件で、2.1.3 と比べました。Python 3.14.5 と 3.9.6 のどちらでも、違いの1,128件はすべて、新しい規則の候補と種類の表（770件）、新しい規則で候補が0件から1件以上になった件（22件）、script（336件。2.1.3 では使えない値）によるものです。diff の2,088件は同じでした。 - 推敲の前後の比べ（Claude Code、claude-opus-5-5、effort high）: 自作の類例31本（新しい型と、直さない文を混ぜた文書）と tests/corpus の163本を、2.1.3 と 2.2.0 で推敲し、どちらの版かを伏せて読み比べました。直すべき型を直せた件数は125件のうち44件から91件、残すべき書き方を誤って直した件数は8件から7件、意味が変わった件数は diff の候補で7件から8件、全文を読んで1件から2件でした。増えた分は、新しい印のない文で「〜のみ」の「のみ」が落ちた1件と、意味の変わらない書き換えが diff の候補に出た件です。 - 推敲の前後の比べ（Codex、gpt-6-astra、effort high）: 自作の類例31本で、直せた件数は39件から88件、誤って直した件数は16件から7件、意味が変わった件数は diff の候補で4件から3件、全文を読んで2件から4件でした。増えた分は、新しい印のない文の揺れ（どこからの帰りかを足した、など）と、英語の言い方の意味で書き直した境目の1件です。 - 直訳語は、推敲しても残る言い方を集めた対応表の場面に似せた自作の文書でも確かめました（表の文はリポジトリに入れていません）。表の17の言い方のうち、既定で12に印がつき、flag.txt に5語を書くと17すべてにつきます。flag.txt に5語を書いた状態で推敲すると、Claude Code はどの回も、表の「直した後」と同じ中身に直したか、文書に名前のないものを書き手に尋ねました。Codex も16の言い方では同じでしたが、承認の言い方は、誰が承認するかが文書で決まる場合にだけ直り、決まらない文書では3回のうち2回、尋ねずに別の言い方に書き換えました。2.1.3 では、同じ文書で直ったのは Claude Code で2〜4、Codex で9でした。 - lint の時間は、1回の CLI で約14ミリ秒（約23%）増えました。新しい規則は、数字や英数字の長い並びのある行でも遅くなりません（試験で守っています）。 ## 2.1.3 - 2026-10-22 Windows で見つかった不具合を直すバージョンです。推敲の結果は 2.1.2 と変わりません。macOS と Linux では、lint、diff、check、フックの出力も 2.1.2 と同じです。Windows で yomiyasu_check.py やフックを使っている方は更新してください。 ### 直したこと - check: 状態フォルダの中の名前があるのに、フォルダかどうかを確かめられないとき（Windows で、ほかの OS ユーザーが作った `.yomiyasu/` の一覧や属性の読み取りを拒まれたとき）、`run` は記録を書けなかった理由に「既に存在するファイルを作成することはできません」と出し、2.1.2 で足した、状態フォルダをユーザーごとに分ける案内を出していませんでした（#41）。今は、名前を確かめられない理由が書き込みの拒否と同じ PermissionError のときは、`run` の1行目と `start` に同じ案内を出します。名前がファイルとして見えるときは、今までどおりです。 - lint、diff、check、フック: Windows では、標準出力と標準エラーに書いた改行が CRLF になり、check の記録の `.txt` と CLI の出力が一致しませんでした（#42）。今は、どの OS でも改行を LF で書きます。macOS と Linux の出力は変わりません。 - lint、diff、check: Windows で出力先（パイプの読む側）が先に閉じると、内部エラーとして Python の例外の表示（traceback）を出し、出力が小さいときは終了コードが120になっていました（#42）。今は macOS や Linux と同じく「出力先が閉じられたため、結果を最後まで書けませんでした。」と出し、終了コード3で終わります。 - check、フック: Windows で `start`、`run`、`end`、フックを並行に動かしたとき、ほかのプロセスが消している途中のロックのファイルで内部エラー（PermissionError）になることがありました（#42）。また、`--max-runs` を越えて検査を実行することがありました。入れ替えている途中の登録や記録を読めずに飛ばしたためと考えています。今は Windows のときだけ、消している途中のロックは使用中とみなして今までと同じ締切（`start`、`run`、`end` は12秒、フックは2秒）まで待ち直し、入れ替えている途中の登録や記録は少し待ってから読み直します（読み直しで待つ時間は1つのプロセスで合計1秒まで）。macOS と Linux の動きは変わりません。 - 試験と CI: CI で Windows（windows-latest、Python 3.12）でも試験一式を流すようにしました。試験が子に渡す入力と書くファイルを改行を変えないバイト列にし、POSIX の権限ビットの確かめは POSIX だけで行い、Windows では時間の上限を機械の速さに合わせて延ばす形にしました（macOS と Linux の上限は 2.1.2 と同じ）。Windows の既定のロケールで日本語を読み違えないよう、試験のファイルを読む所にもエンコーディングを書きました（#42）。 ### 更新するときの注意 - 既存の JSON のキーと値の意味、`*_FORMAT_VERSION`、記録の形、コマンドの引数と既定値、状態の行の形は変えていません。 - 2.1.2 で残した検査の記録を 2.1.3 の `verify` で照らすと、検査スクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 確かめたこと - 試験一式は、macOS の Python 3.14.5 と 3.9.6 で2,107件ずつ通りました（どちらも、Linux だけで動かす試験2件を飛ばしています）。CI では Linux（3.9 と 3.14）と Windows（windows-latest、Python 3.12.10）で流し、Windows では2,090件が通りました（19件は、POSIX だけの試験や、`sh` や `/dev/stdin` がない環境で飛ばす試験です）。新しい試験は `tests/test_v213_hidden_state.py`、`tests/test_v213_tools.py`、`tests/test_v213_tests.py` です。#41 の状態は `os.mkdir`、`os.path.isdir`、`os.lstat` を差し替えて再現しました。Windows の改行、閉じた出力先、ロックと記録の読み直しは、Windows の CI のほか、macOS でも子プロセスの改行の変換と `os.name` を差し替えて確かめています。 - 2.1.2 と 2.1.3 の lint、diff、check の CLI を同じ4,099件の入力で動かし、版の文字列をそろえて比べました（Python 3.14.5 と 3.9.6）。標準出力、標準エラー、終了コードは4,099件すべて同じでした。 ## 2.1.2 - 2026-10-22 Windows で状態フォルダに書き込めないときの不具合と、全角の小数点を含む文で diff が止まる不具合を直すバージョンです。推敲の結果は 2.1.1 と変わりません。lint、diff、check の出力も、全角の小数点を含む文と、状態フォルダに書けないときのほかは 2.1.1 と同じです。Windows で yomiyasu_check.py やフックを使っている方と、全角の数字を使う文書を検査している方は更新してください。 ### 直したこと - check: Windows で状態フォルダ（`.yomiyasu/` や `--state-dir` のフォルダ）に書き込めないと、`run` が何も出力せずに CPU を使い続け、終わらなくなっていました（#37）。Python 3.12 までの Windows の tempfile は、書き込みを拒まれたのを同じ名前のフォルダがあるためと読み、一時ファイルの名前を約21億回まで試し続けるためです。今は tempfile の名前を試す関数を使わず、名前を試すのを100回までにした関数で一時ファイルと一時フォルダを作ります。書き込みを拒まれたときに次の名前を試すのは、その名前が本当にフォルダのときだけです。`run` はすぐに記録を残さずに `reason=not_writable` で終わります。記録を残せないときに写しを置く一時フォルダも、同じく名前を試すのを100回までにしました。この一時フォルダの写しを消せなかったときは、その場所を標準エラーに1行で知らせます（結果の出力と終了コードは変えません）。 - check: 状態フォルダは、作った OS ユーザーだけが読み書きできるフォルダにしています（POSIX では 0o700。Windows でも、Python の版によっては作ったユーザーと管理者だけのフォルダになります）。そのため、同じリポジトリをほかの OS ユーザー（Codex のサンドボックスなど）が先に使っていると、記録を残せませんでした（#38）。原稿の写しを守るため、この作りは変えていません。代わりに、状態フォルダへの書き込みを拒まれたときは、ほかの OS ユーザーが作った状態フォルダかもしれないことと、`--state-dir` か `YOMIYASU_STATE_DIR` で自分が書ける場所を指定することを、`run` の1行目に出すようにしました。README と docs/tools.md にも、ユーザーごとに別の状態フォルダを指定するよう書きました。 - check: 状態フォルダに書けないとき、`start` は内部エラーとして Python の例外の表示（traceback）を出していました。今は、終了コードは今までどおり3のまま、書けなかった理由と上の案内を出して終わります。同じ原稿の `start` がほかで動いていてロックを待ちきれなかったときは、今までどおり内部エラーです。 - check: 記録を書けなかった理由に、一時ファイルの名前（`.tmp-…`）ではなく、書けなかったフォルダを示すようにしました。 - diff: 全角の小数点を含む文（「値は３．５％だった。」など）を書き換えた組で、2.1.1 で足した数の概数・範囲の印の検査が `AttributeError` になり、終了コード3で止まっていました（#40）。全角の「．」は文の区切りにも読まれるので、数の終わりが文の範囲を越えていたためです。今は、数を含む文の終わり（次の句点か改行）までを範囲にして読みます。あわせて、「３．５％程度 → ３．５％」のように全角の小数点の数のあとの印が消えた書き換えも、半角の小数点と同じように意味が変わる恐れとして出します（2.1.1 では止まらない組でも、この印の変化を見逃していました）。 - check: 上の組では、check run も diff を実行できずに `partial`（終了コード3）になっていました。今は最後まで検査して終わります。 ### 変わらないもの - 既存の JSON のキーと値の意味、`*_FORMAT_VERSION`、記録の形、コマンドの引数と既定値、状態の行の形は変えていません。状態フォルダと記録のファイルの権限も 2.1.1 と同じです。 - 2.1.1 で残した検査の記録を 2.1.2 の `verify` で照らすと、検査スクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 確かめたこと - 試験一式は Python 3.14.5 と 3.9.6 で2,050件ずつ通りました（どちらも、Linux だけで動かす試験2件を飛ばしています）。新しい試験は `tests/test_v212_state_not_writable.py` と `tests/test_v212_fullwidth_decimal.py` です。Windows の tempfile が名前を試し続ける動きは、`os.open` と「名前がフォルダか」の判定を差し替えて再現し、100回で止まることと、`run` がすぐに `reason=not_writable` で終わることを確かめました。書き込みの権限を外した状態フォルダでの `run` と `start` も確かめています。既存の試験1件（書けないときの1行目の文を固定していたもの）は、新しい案内の文に合わせました。全角の小数点の組は、数の印を半角の小数点の組と同じように読むことを確かめました。実際のモデルの推敲の出力を中心に重複を除いた1,715組（tests/corpus の48組を含む）と tests/corpus の48組では、種類なしと formal の両方で diff の結果が 2.1.1 と同じでした（全角の小数点を含む組はありませんでした）。 - 2.1.1 と 2.1.2 の lint、diff、check の CLI を同じ4,099件の入力で動かし、版の文字列をそろえて比べました（Python 3.14.5）。標準出力、標準エラー、終了コードは4,099件すべて同じでした。 ## 2.1.1 - 2026-10-21 不具合を直すバージョンです。推敲の結果は 2.1.0 と変わりません（SKILL.md は版の行だけ、references は何も変えていません）。急いで更新しなくてもかまいません。ただし、投稿の本文に壊れた文字が1つあるとフックが何も確かめずに通してしまう不具合（#28）を直したので、フックを使っている方は更新してください。 lint、diff、check、フックの出力は、下の直しに当たるところだけ変わります。ファイルとフォルダの場所と名前、参照ファイルの節の見出し、既存の JSON のキーと値の意味、`*_FORMAT_VERSION` の値、記録の形、コマンドの引数と既定値、check の状態の行（`yomiyasu-check: executed ...`）の形と位置は変えていません。 ### 直したこと - フック: PreToolUse の投稿の本文の欄（`body`、`text`、`content`、`description`、`message`、`notes` と、`gh` の `--body` などの値）のどれかに、対になっていないサロゲート（JSON の `\ud800` など）があると、2.1.0 のフックは判定を出さずに終わっていました（標準出力は空、終了コード0で、ホストは許可とみなします）。同じ投稿のほかの欄に止めるべき本文があっても止めませんでした。今は、ほかの欄の本文をいつもどおり確かめ、止めるべきなら止めます。壊れた欄そのものは、登録した原稿と照合できない本文として扱います。`gh` の `--body-file`、`-F`、`gh api` の `-F body=@` に渡すファイルの名前と、`/yomiyasu` の依頼の文の語に、ファイルの名前にできない文字があるときも同じで、その1件だけを飛ばし、ほかの本文はいつもどおり確かめ、ほかのファイルは登録します。`hook-errors.log` に `UnicodeEncodeError` も残りません。（#28） - diff: 「AまたはBのどちらかを選ぶ必要がある。」を「AとBの両方を選ぶ必要がある。」に書き換えるように、どれか一つを選ぶ言い方（または、もしくは、あるいは、どちらか、いずれか、AかB など）と全部を含む言い方（両方、双方、どちらも、いずれも、すべて、AもBも など）が、原文の文と書き直した文の対応する範囲で入れ替わったら、意味が変わる恐れとして出し、`--fail-on=meaning-risk` に数えるようにしました。逆向き（全部 → どれか一つ）も出します。「AもBも」「AにもBにも」「二つとも」も全部を含む言い方として見ます（「A、B、Cをすべて提出する」のような副詞の「すべて」は見ません）。同じ側の中の言い換え（または → か、どちらか → いずれか、両方 → どちらも）、どれを選んでもよい言い方への言い換え（AまたはB → AでもBでも、どちらでも）、選ぶものとは別の名詞に掛かる「すべての〜」（全項目 → すべての項目）、問いの「か」（設定が有効か管理者に確認する）では出しません。（#34） - diff: 関連や相関を述べた原文の文（関連がある、相関がある、関係がある、結びついている など）に、原文になかった因果の言い方（因果関係、原因、引き起こす、〜によって生じる、〜のせいで など）を足した書き換えを、意味が変わる恐れとして出し、`--fail-on=meaning-risk` に数えるようにしました。「〜によって増加した」「〜につながった」「〜のおかげで」「〜の結果、」「〜を招く」も因果の言い方として見ます。関連を述べた文のすぐあとに因果を述べた文を足した書き換えも出します。原文にもともと因果の言い方（〜による、影響する、〜のため、理由 など）がある文、原文に関連や相関の言い方がない文、関連を打ち消した文（関係はありません、相関は見られなかった）、名詞を修飾する関連の語（関係のある部署、関連性の高い記事、相関係数）、「関連」→「関係」のような言い換えでは出しません。 - diff: 数に付いた概数や範囲の印が消えたか増えた書き換えを、意味が変わる恐れとして出し、`--fail-on=meaning-risk` に数えるようにしました。「影響を受けた利用者は約120人です。」→「影響を受けた利用者は120人です。」のように、概数が確定した数に変わる書き換えです。2.1.0 では見直し候補が0件で、全文差分にしか出ませんでした。 - 見る印は、数の前の「約、およそ、概ね、ほぼ、推定」（「利用者約120人」のように名詞のすぐあとの「約」も見ます）と、数の後ろの「ほど、程度、前後、くらい、位、ごろ、弱、強、余り、近く、足らず、かそこら、以上、以降、超、以下、以内、以前、未満、を超える、を下回る」です。「5分弱かかる」「10月中旬ごろ」「15時半ごろ」も見ます。 - 印が消えたとき、増えたとき、以上と超、以下と未満、以上と以下が入れ替わったときに出します。 - 同じ種類の印への言い換え（約120人 → 120人ほど、約1万5000人 → 1万5000人ほど、3日以内 → 3日のうちに、100人未満 → 100人に満たない）、表記だけの違い（一万円 → 1万円、1,000 → 1000、全角の数字 → 半角）、印ではない語（契約3件、部品が3個余る、震度5弱、ベスト4強、3位）では出しません。 - check: UTF-8 として読めないバイトを含むファイル名（`bad-\xff.md` など）の原稿を、`start` で登録できるようにしました。2.1.0 では、ファイルがあるのに引数の誤り（終了コード2）になっていました。フック（`/yomiyasu` のあとにその名前）からも登録します。2.1.0 は黙って登録せず、`hook-errors.log` にだけ残していました。start、run、verify、フックは、同じ名前で同じ登録を見つけます。フックの登録の知らせでは、読めないバイトを `\udcff` のようなエスケープで書きます。（#29） - check: `run --stdin` で、改行が CR（`\r`）だけの入力も区切りの行で分けるようにしました。同じ中身をファイルで渡したときと同じ結果（状態、候補の数、記録の改行の種類 `cr`）になります。LF と CRLF の入力の結果は 2.1.0 と同じです。行の途中に CR が1つだけある入力も、ファイルで渡したときと同じく、そこで行が分かれます。（#30） - diff: 見出しの変化を「構造」の見直し候補に出すようにしました。対象は、見出しの数が変わったとき、太字の行や本文の行を見出しにしたとき、見出しを本文の行にしたとき、見出しの段を変えたとき（`###` → `####` など）です。2.1.0 では全文差分に「本文 → 見出し」「見出しの段 3 → 4」と注記が付くだけで、見直し候補は0件でした。今は、どの行がどう変わったかを元と後の行番号で示します（例: 太字の行を見出しにした（元3行目「**前提条件**」→ 後3行目「#### 前提条件」））。同じ位置の見出しの段と名前を一緒に変えたとき（`## 前提` → `### 準備するもの`）も段の変化として出し、setext の下線（`---`、`===`）の行だけを足したときや消したときも、どの行かを挙げます。見直し候補なので、意味が変わる恐れには数えず、diff と check の `--fail-on` の終了コードも変えません。 - lint: 文字どおりの語に出ていた警告を3つ直しました。規則の名前、警告文、slop-catalog.md の見出しは変えていません。 - slop_vocabulary: 「真理値」「真理表」のような論理の用語と、「安全装置」「制御装置」「レーザー装置」「X線装置」のように機器の名前になる「装置」に、AI頻出語彙「真理」「装置」の警告を出さなくなりました。「この装置は、毎朝自動で起動します。」のように、すぐあとに電源や起動など機器の操作が続く「装置」にも出しません。「人生の真理」「〜をつなぐ装置」「増幅装置」「思考装置」「舞台装置」には今までどおり出します。（#31） - metaphor_verb: 「ボタンを押した瞬間に、画面が真っ白になる。」「保存せずに終了した瞬間に、編集内容は失われます。」のように時刻をそのまま表す「〜した瞬間に」に、英語直訳の警告を出さなくなりました。「〜を優先した瞬間に、品質は下がる」のように一般論の前置きや抽象的な主語が続く形、「手にした瞬間」の形、「〜した瞬間だった」で結ぶ形（「〜のは、〜した瞬間だった」のように時刻を答える文を除きます）、「〜した瞬間、世界が変わった」のように大げさな結果が続く形には、今までどおり出します。（#32） - translated_term: 「この辞書の次の版では」のように、同じ文の中で「版」より前に出版物の語（辞書、書籍、本、本書、文庫、全集、冊子、写真集、増刷、改訂、第2版 など）があるときは、英語の直訳「版」の警告を出さなくなりました。「辞書型」「ユーザー辞書」「初版リリース」のようにソフトウェアの複合語の一部になっているときと、ソフトウェアの文脈の「この版では」「次の版で」には、今までどおり出します。（#33） - lint: 文末を見る規則が、文の終わりの後ろの飾りで外れていたのを直しました。「それが真理と言っても過言ではありません 🚀」「いかがでしたか‼️」「見ていきましょう↓」のように、文末の後ろに絵文字、☆♪ のような記号、空白、矢印、波線（〜）、文全体を囲んだかっこ、対のない閉じかぎや閉じ引用符があっても、ない文と同じように候補を出します。読み飛ばす絵文字は emoji_prohibited と同じ表から作るので、emoji_prohibited が絵文字として出す字はどれも読み飛ばします。対象は meta_filler、negative_parallelism、short_mochiron、cleft_list_ending、instruction_residue、short_summary_heading、dash_list_ending、metaphor_verb の「〜した瞬間だった」、sentence_end_repetition です。句点の代わりに絵文字を置いて同じ行で次の文を続けた形（「いかがでしたか😊 次回もお楽しみに！」）は、文末の型を見る meta_filler、negative_parallelism の「Aじゃない、Bです」、instruction_residue、sentence_end_repetition で、絵文字の所で文が切れるとみます。絵文字そのものは、これまでどおり emoji_prohibited で別に出します。対になったかぎの中の語（「いかがでしたか」のような言及）と、名詞のあとのかっこ書き（目次の副題など）は、今までどおり候補にしません。後ろに絵文字がある問い（「これで動きますか🤔」）を問いとして読むので、次の「もちろん、〜。」に short_mochiron を出さなくなりました。 - lint: 比喩動詞「効く」の過剰使用（metaphor_verb）が、「地味に」などの副詞がなくても、「この工夫は後から効いてきます」「設定の見直しが効いた」のような、何がどう良くなるかを書かない比喩の「効く」を拾うようになりました。薬やサプリの飲み方、冷房や暖房、ブレーキ、わさびや辛さ、圧縮や最適化のような文字どおりの「効く」と、「融通が効く」のような慣用句では出しません。前の数行に「服用」「エアコン」などの語があるときや、同じ文に「30分ほどで」のような時間が書いてあるときも出しません（2.1.0 で出ていた「この薬はよく効く。」の警告も出なくなります）。 - check: `run` の出力の頭の数行だけを読んでも、どの行のどの規則に当たったかが分かるようにしました。候補があるときは、3行目（実行した検査の要約）のすぐあとに、候補の短い一覧（「diff の候補: 後3行目 number、後5行目 promise_review、元の文にない語（ほか4件）」のような1行）と、「候補の中身は下の節にあります。出力を切らずに読んでください。」の1行を出します。行番号のある候補を行の順に並べ、検査ごとに3件までを挙げて、残りは「ほかN件」と書きます。資料との照合の候補が節の見直しの行だけのときは、件数でなく名前（資料に基づく補足など）を挙げます。候補がないときは何も足しません。1行目の案内、2行目の状態の行、3行目は変わりません。候補があるときは、そのあとの行が2行ずつ下がります（「記録: 」の行は5行目から7行目になります）。記録のパスを読む仕組みは、行の位置ではなく「記録: 」で始まる行で探してください。`--json`、記録のファイル、`verify` の出力は変わりません。 ### 終了コードが変わる場合 - diff と check の `--fail-on=meaning-risk` で、上の3つの意味の型（どれか一つと全部の入れ替え、関連から因果への強まり、数の概数や範囲の印の増減）に当たる組は、終了コードが0から1に変わります。 - `run --stdin` に CR だけの改行の入力を渡したときは、2.1.0 の終了コード2（区切りの誤り）が、検査を実行した結果の終了コード（0、`--fail-on` に当たれば1）に変わります。 - `start` に UTF-8 として読めない名前の原稿を渡したときは、2.1.0 の終了コード2が0に変わります。 - 見出しの変化の候補は、どの `--fail-on` の終了コードも変えません。 ### 足した JSON の値 既存のキーと値の意味、`*_FORMAT_VERSION` は変えていません。 - diff の `meaning_risks[].kind` に `"number_qualifier"`（`subkind` は `"lost"`、`"added"`、`"changed"`）を足しました。`--fail-on=meaning-risk` に数えます。`detail` は `old_number`、`new_number`（万・億と単位を含む、書かれた形の数）、`from`、`to`（印の種類の名前の並び。`approx`、`lower_in`、`lower_ex`、`upper_in`、`upper_ex`、`bound_verb`）、`old_markers`、`new_markers` です。 - diff の `meaning_risks[].kind` に `"choice"`（`subkind` は `"one_to_all"` と `"all_to_one"`）と `"causality"`（`subkind` は `"relation_to_cause"`）を足しました。どちらも `--fail-on=meaning-risk` に数えます。`detail` は `from`、`to`、`old_hits`（原文の範囲の言い方）、`new_hits`（書き直した範囲の言い方）です。 - diff の `structure`（文字列の並び）に、見出しの変化の文を足します。キーは増やしていません。この文の数だけ `candidate_count` が増え、`status` が `changed_without_candidates` から `has_candidates` に替わる組があります。check の記録の diff の要約の `candidate_count` も同じです。 - diff のモジュールに、印の表 `LOGIC_MARKERS` を足しました。`FAIL_ON_KINDS` の末尾に `"choice"`、`"causality"`、`"number_qualifier"` が加わります（先頭の並びはそのままです）。 ### 更新するときの注意 - 2.1.0 で残した検査の記録を 2.1.1 の `verify` で照らすと、検査スクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 - SKILL.md は41,445字のままです。スキルの指示の字数に上限があるサービス（Microsoft 365 Copilot の Agent Builder は30,000字まで）には、そのままでは入りません（[docs/limitations.md](docs/limitations.md)）。（#35） ### 確かめたこと - 試験一式は Python 3.14.5 で2,030件（subtest 8,571件）、3.9.6 で2,030件が通りました（どちらも、下の Linux だけで動かす試験2件を飛ばしています）。新しい試験は `tests/test_v211_textsafety.py`、`test_v211_difflogic.py`、`test_v211_approx.py`、`test_v211_diffstructure.py`、`test_v211_lint.py`、`test_v211_sentence_end.py`、`test_v211_kiku.py`、`test_v211_checkhead.py` です。UTF-8 として読めないファイル名の実際のファイルを使う試験は、その名前を作れない macOS と Windows では飛ばし、Linux で動かします。 - 2.1.0 と 2.1.1 の lint、diff、check の CLI を同じ4,099件の入力で動かし、版の文字列をそろえて比べました（Python 3.14.5）。入力は 2.1.0 のときと同じく、tests/corpus の163文書（lint）と、tests/corpus の48組と実際の推敲の出力などから選んだ300組（diff と check）です。 - 終了コードと標準エラーの違いは0件で、lint の1,312件はすべて同じでした。 - 標準出力が違った385件のうち336件は check run の人が読む出力で、候補の短い一覧と案内の2行が加わったものです（このうち7件には、下の見出しの変化の候補も加わっています）。 - 残りの49件は、7組で見出しの変化が構造の候補に出たものです（diff の42件と、check run --json の7件）。3組は太字の行を見出しにした推敲（tests/corpus の2組を含む）、4組は見出しを足した推敲でした。 - 選ぶ範囲、因果、数の印の新しい候補と、lint の直しで変わった出力は、この入力では0件でした。 - 新しい候補の件数は、tests/corpus の48組と、実際のモデルの推敲の出力を中心に重複を除いた1,715組（tests/corpus の48組を含む）で、文書の種類なしと formal の両方を数えました。 - 選ぶ範囲、因果、数の印の新しい候補は、どちらでも0件でした。この組には、関連を述べた文も、選ぶ範囲や数の印を変えた範囲もなかったので、拾えることは合成の組で確かめています。数の印が付いた数を含む組は252組あり、どれにも候補は出ていません。 - 見出しの変化の候補は、tests/corpus の48組で2組（見出しの数2件、太字の行を見出しにした2件）、1,715組で0件（見出しのない文書）でした。見出しを含む別の1,367組では26組に出て、出た文をすべて読み、誤った候補は0件でした。 - lint の直し（#31〜#33、文末の飾り、比喩の「効く」）は、tests/corpus の163文書と最終稿1,706本（重複を除く）で、文書の種類なし、article、mail、promo のどれでも、消えた候補も増えた候補も0件でした。 - 速さは、新しい検査の分だけ少し伸びました。tests/corpus の推敲48組を10回つないだ21万字の文書で、diff は2.41秒が2.62秒に、最終稿の lint は0.12秒が0.14秒になりました（CPU 時間、3回の最小。Python 3.14.5）。 ## 2.1.0 - 2026-10-20 推敲の結果が変わるバージョンです。読みやすくしても意味と文の働きを変えない、という軸はそのままに、これまでの手順と検査では十分に扱えていなかった2種類のずれを扱うようにしました。1つは、語順や省略、助詞による読み違いです（目的語の抜け、主題の「は」「では」の掛かる範囲、前置きのない強調の形）。もう1つは、仕様書や設計文書での許可・能力・保証の言い方のずれです。あわせて、「書き手に確かめたい点」の上限を2点から3点にしました。 lint、diff、check の出力も、新しい規則に当たる文では変わります。CI などで `--fail-on=meaning-risk` を使っている場合は、許可の言い方が消えた・増えた書き換え、原文にない常体の「保証する」や「〜ことはない」を足した書き換え、下の7種類の `--doc-type` を指定したときの確度の強まりで、終了コードが1になることがあります。既存の JSON のキー、コマンドの引数と既定値、ファイルの場所、スキルの名前は変えていません（足した値は下に書きます）。 ### 推敲の手順に足したこと - 目的語を書かない他動詞の前に、比較や条件などの句が挟まっている文の扱いを足しました（SKILL.md「主語と目的語の明確化」）。前のほうにある別の名詞が目的語に読めてしまう形です（「設定の一覧を渡して比べさせると、Aは残りの2つの案より多く削った。」は、「設定の一覧」を削ったとも読めます）。対象が原文・依頼・資料・文脈に書いてあれば、その語を目的語に書きます。書いていなければ動作を名詞にして主語に立て（「〜を行う」にはしません）、それでも決まらなければ「書き手に確かめたい点」に出します。補うのは対象と関係が明示されているときだけ、推測で作らない、という決まりは変えていません。 - 漢語や名詞の形を和語の動詞に替える直しは、替えたあとも目的語が文の中で追え、意味の幅が同じときだけにしました（「確認する」を「見る」にするような、幅の広がる言い換えはしません）。和語に寄せる規則そのものは外さず、slop-catalog.md、rephrase-test.md、gemini-syntax.md、domains/tech.md に同じ条件を足しました。 - 主題の「〜は」「〜では」が文末まで掛かって読まれることの扱いを足しました（SKILL.md「主語と目的語の明確化」）。対象は、主題のあとに「〜ため、」「〜て、」などで節が続く文です。主題が部品や処理の名前で、後半に別の名前（設定、マクロ、ファイル、ライブラリなど）を扱う動作が出てくるときは、後半もその主題の中の話かを確かめます（「ParserではJSONの深さを10までに抑えるため、MAX_DEPTHを定義して再帰を打ち切ります。」の後半は、Parser の中の処理か、ビルドの設定の話かが文だけでは決まりません）。確かめられなければ主体や場所を足さずに文を残し、どの主題の話かを「書き手に確かめたい点」に出します。問いを出す場面は、この形（主題が部品や処理の名前で、後半に別の名前を扱う動作が出てくる文）に絞っています。問いを出す条件を広げれば、読み違えやすい文を確かめ損ねることは減る見込みですが、ほかの文書でも念のための問いが増える恐れがあります。問いが増えると、書き手はそのたびに答えを考えなければならず、本文を確定するのに本当に要る問いがほかの問いに埋もれます。上限の3点が念のための問いで埋まれば、要る問いが「ほかに N か所」に回ることもあります。そのため、確かめ損ねを減らすことと問いの数との釣り合いを見て、ここで止めています。 - 「〜で変わったのは、A、B、C。」のように、「〜のは、」のあとに名詞を並べて文を終える強調の形の扱いを足しました（SKILL.md「コピー調の抑制」）。前の文や見出しに前提がなければ、「〜では、A、B、Cが変わった」のように「のは」の前の動詞を述語に戻します。前提が直前にあるとき、見出し、結び、スライドの箇条で強調として選んでいるときは残します。 - 言い切りの強さに、許可（〜してよい）、能力・権限（〜できる）、義務（〜しなければならない）、保証（必ず〜する、〜を保証する）の言い方を含めました。仕様書や設計文書では、これらを互いに替えたり、「〜場合がある」を消して言い切ったり、説明に「必ず」「保証する」を足したりしません。Step 4 の点検、review-points.md、doc-types/formal.md にも書きました。 - 「書き手に確かめたい点」の上限を2点から3点にしました（SKILL.md の暫定文と出力の雛形、docs/usage.md）。多いときに選ぶ順（読み違えると働きが変わる所、読み手が動く値や手順が決まらない所、語の指す先、出典や用途の順）を書き、選ばなかった所があるときは「- ほかに N か所」と1行添えます。3点を埋めるために問いを足さないこと、答えで本文の語句が変わらない問い（書き足しや言い方をそろえることの提案）は入れないことも書きました。「ここに説明が必要です」（3点まで）、ペルソナの知らせ（2点まで）、材料と違う値（2点まで）などのほかの上限は変えていません。 ### diff: 許可・能力・保証の言い方の変化 - 原文の各文と、書き直した文の対応する範囲（文を分けた・つないだときは1つの範囲）で、許可と能力の言い方を比べるようにしました。 - 許可の言い方（してよい、してもよい、しても構わない、しても差し支えない、すれば結構です など）が消えたか増えた書き換えは、意味が変わる恐れ（kind `modality`）として出し、`--fail-on=meaning-risk` に数えます。どの文書の種類でも数えます。「この値は管理者だけが変更してよい」→「変更できる」、「この値は管理者が変更してもよい」→「変更する」などです。 - 能力の言い方（できる、可能だ）が消えた書き換えは、見直し候補（kind `modality_review`）として出し、数えません。能力の言い換えには正しい直しが多いためです。能力が増えただけの書き換えと、「できない」などの打ち消しの能力だけが消えた書き換えは出しません。 - 同じ働きの言い方の中での言い換え（することができる → できる、してもよい → してよい、なくてよい → 不要）は出しません。依頼や決まりの印が動いた文（許可 → 義務など）は、今までどおり文の種類の印の候補だけを出します。 - 保証の型に、常体の「保証する」「保証される」「保証している」と「担保する」を足しました。敬体の「保証します」と同じく、原文にない保証の足しとして数えます。 - 書き直した文が「〜ことはない」を足して、否定の数が原文の文より増えたときは、原文の述語の言い換えとはみなさず、原文にない保証として数えるようにしました（「〜事態を防げる。」→「〜処理を止めることはない。」など）。 - `--doc-type` が pr、article、incident、proposal、manual、formal、paper（事実や仕様を述べる種類）のときは、「場合がある」「ことがある」を消して言い切った書き換えと、断定に「必ず」「確実に」などを足した書き換えを `--fail-on=meaning-risk` に数えるようにしました。原文の文に義務の語（しなければならない、必須 など）があるときの「必ず」と、「まれに」「一部」などの頻度の語に替えた書き換えは数えません。ほかの種類と種類なしでは、今までどおり見直し候補にとどめます（確度のこの数え方は、種類なしの終了コードを変えません。許可の比べは、種類なしでも数えます）。 - 1文を2文に分けたときも確度を比べるようにしました。原文の文から分けたとみなせる隣の文（2文字の組の半分以上が原文の文にある文）の「必ず」なども比べます。 - check は `--doc-type` を diff に渡すので、check の意味が変わる恐れと終了コードも同じように変わります。 - 足した JSON の値（既存のキーは変えていません） - `meaning_risks[].kind` の `"modality"`（数える）と `"modality_review"`（数えない）。`subkind` は `"permission_lost"`、`"permission_added"`、`"ability_lost"`。`detail` は `lost`、`added`（`[{kind, hits}]`）、`from`、`to`。 - 確度の `detail.steps[]` の `"counted_by": "doc_type"`（文書の種類によって数えた段にだけ付きます）。 - 公開の関数 `meaning_risks()` のキーワード引数 `doc_type`（既定は `None`）。type_changes を渡したときは、許可・能力の比べも含めて diff() の `meaning_risks` と同じものを返します。 - 人が読む出力では、「許可の言い方が消えた」「原文にない許可の言い方」「能力の言い方が消えた」の行を「■ 意味が変わる恐れ」に出します。`--doc-type` か `--reader` を指定したときの種類の行の後半は「候補の見つけ方は種類と読者によらず同じです。」に替わり、上の7種類ではそのあとに「この種類では、…も --fail-on に数えます。」が続きます。 ### lint: 前置きなしの強調構文 - 規則 `cleft_list_ending`（info）を足しました。「〜(連体形)のは、」のあとに名詞を読点で3つ以上（「と・や・および」を交えるなら2つ以上）並べ、述語を書かずに終える文に出します（「今回の改修で増えたのは、画面、帳票、通知。」）。「〜など。」「〜の3つ。」で終わる文にも出します。 - 出さない文: 述語まで書いた文（「理由は、AとBです。」）、「重要なのは、」などの前置きの型（meta_filler が出ます）、「〜のみ。」、ダッシュで終わる文、改行で折り返して次の行に述語がある文、引用・見出し・表・コードの中。直前の文が問いの文と、直前の文に「のは」の前の動詞の漢字が1字でもある文も、前提が書いてあるとみて出しません。 - info なので `--strict` と `--fail-on` には効きません。`--doc-type slides` では外します（slides では、`context.skipped_by_doc_type` に規則の名前が1つ加わります）。新しい欄は足していません。 ### 変わらないもの - 既存の JSON のキー、コマンドの引数と既定値、ファイルの場所、スキルの名前（Claude Code のプラグインと Codex では `yomiyasu:yomiyasu`、`npx skills add` などで Claude Code に入れたときは `yomiyasu`）。 - 2.0.2 で残した検査の記録を 2.1.0 の `verify` で照らすと、検査スクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 確かめたこと - 試験一式は Python 3.14.5 で1,814件（subtest 7,133件）、3.9.6 で1,814件が通りました。新しい試験は `tests/test_v210_modality.py`（許可・能力・保証を言い換えた例と、検出すべき例、検出してはいけない例）と `tests/test_v210_cleft_list_ending.py` です。 - 2.0.2 と 2.1.0 の lint、diff、check の CLI を同じ4,099件の入力で動かし、版の文字列をそろえて比べました（Python 3.14.5）。入力は tests/corpus の163文書（lint は種類なしと article、mail、promo の、通常の出力と `--json`）と、tests/corpus の48組と実際の推敲の出力などから選んだ300組（diff と check）です。 - 終了コードと標準エラーの違いは0件で、lint の1,312件は版の番号を除いてすべて同じでした。 - 標準出力が違った386件のうち342件は、`diff --doc-type article` の種類の行の文が替わったものです。 - 残りの44件は、次の3つの書き換えが出たものです（同じ文を含む組が重なっているため、件数が多く見えます）。 - 「〜事態を防げる。」→「〜処理を止めることはない。」: 原文にない保証として数えます。能力を言い切りの保証に強めた書き換えで、正しい指摘と見ています。 - 「担当できるまでになっている」→「担当している」: 能力の言い方が消えた、として出します（数えません）。正しい指摘と見ています。 - 手順の文の「〜を押します。」→「必ず〜を押します。」: article で数える確度として出します。手順を義務に強めた書き換えですが、原文の別の所に同じ作業を求める文があるので、正しい指摘とも誤検知とも決めかねる候補（境目）と見ています。 - 新しい警告の件数を数えました。 - lint の `cleft_list_ending` は、tests/corpus の human（16本）、yomiyasu_rewritten（48本）、raw_ai、blacklist_ai、edge_cases のどれでも0件でした。 - diff で新しく出た候補は、tests/corpus の48組では2通り（上の保証と能力）でした。実際のモデルの推敲の出力を中心に重複を除いた1,715組（tests/corpus の48組を含む。種類なしと formal）では7通りでした。内訳は正しい指摘5通り、境目2通りで、誤検知と見たものはありません。許可の候補は0件で、種類なしで終了コードが変わった組もありませんでした。 - 37.7万字の文書の diff は、2.0.2 の1.41秒が 2.1.0 で1.44秒に、崩れた太字を1段落に5,000組並べた文書の lint は、0.209秒が0.217秒になりました（CLI の壁時計、5回の最小、Python 3.14.5）。 - 推敲の振る舞いを、変えた規則に当たる短い合成の文書4本で測りました。macOS の Claude Code 2.1.296（Claude Opus 5.5、effort high、`claude -p`）と codex-cli 0.162.1（gpt-6-astra、effort high、fast、`codex exec`）で3回ずつ推敲させ、測る前に決めておいた振る舞いになった回を数えました。 | 文書 | 2.0.2 | 2.1.0 | |---|---|---| | 挟まった句のあとで目的語が抜ける文 | 0/6 | 6/6 | | 前提のない「〜のは、A、B、C。」 | 0/6 | 6/6 | | 前提のある「〜のは、A、B、C。」（残すべき文） | 6/6 | 6/6 | | 主題の「では」が別の処理の話まで掛かって読める文 | 0/6 | 5/6 | 表の数は、決めておいた振る舞いになった回数と、試した回数（2つのホストで3回ずつ）です。目的語の文は、前の文にある対象を目的語に書くか、動作を名詞にするか、書き手に確かめた回、前提のない文は述語の形に直した回、残すべき文は残した回、主題の文は後半の主体を書かずに書き手に確かめた回を数えました。目的語の抜けと主題の範囲の規則には、測った文書と同じ形の短い合成の例を入れています。測ったのは、規則に入れた例と同じ形の文です。 - tests/corpus/raw_ai の26本を両方のホストで1回ずつ推敲させ、「書き手に確かめたい点」を出した文書の数と項目の合計を比べました。Claude Code は 2.0.2 で9本・13項目、2.1.0 で12本・16項目、Codex は 2.0.2 で1本・1項目、2.1.0 で2本・2項目でした。3点まで出たのは、2.1.0 の Claude Code の1本です。 ### 限界 - 目的語の抜けと主題の掛かる範囲は、手順だけで扱い、lint と diff の検査にはしていません。係り受けと動詞の格の型の解析が要るうえ、日本語では省略が普通で、tests/corpus に目当ての形がなく、粗い正規表現では誤検知だけが出たためです。 - diff の許可の比べは、名詞のあとの「〜で構わない」「〜で差し支えない」「〜でよい」（「提出はPDFで構いません。」など）と、空白を挟んだ「〜 でも構わない」を拾いません。 - diff の許可・能力の比べは、原文の各文と書き直した文の範囲を字面の重なりでたどります。文の順を大きく入れ替えると、対応しない文どうしを比べた候補が出ることがあります（文の種類の印の比べと同じ限界です）。 - 能力の言い方が消えたことは数えないので、ほかの印が変わらない書き換え（「明日お届けできます。」→「明日お届けいたします。」）は、`--fail-on` では止まりません（見直し候補には出ます）。 - 確度を文書の種類で数えるのは、diff か check に `--doc-type` で7種類のどれかを渡したときだけです（スキルが SKILL.md の手順で種類を決めて check に渡したときも含みます）。種類なしでは 2.0.2 と同じです。 - `cleft_list_ending` の前提の見分けは、直前の文が問いか、直前の文に「のは」の前の動詞の漢字が1字でもあるかだけで見ています。漢字が1字重なるだけでも前提ありとみるので、前提のない文でも出ないことがあります。同じ動詞の強調の形が2つ続くと、2つ目は出しません。 ## 2.0.2 - 2026-10-19 推敲の結果は 2.0.1 と同じです。スキルの書き直し方は変えておらず、lint、diff、check の出力も変わりません（違うのは版の番号と、`~` で始まる状態フォルダを指定したときの記録の場所です）。このバージョンでは長い段落の太字の検査を速くし、状態フォルダの `~` の扱いを直し、プラグインの設定ファイルの重複を整理しました。この直しで、1つの段落に崩れた太字が多く、2.0.1 では check run が時間切れになっていた文書も、最後まで検査できます。 もう1つ、このバージョンから yomiyasu は名前を出して頼んだときだけ使われます。これまでどおり毎回使いたい場合は、次の節の1行を CLAUDE.md などに足してください。ほかの点は急いで更新しなくて大丈夫です。 ### yomiyasu が使われる場面が変わりました yomiyasu が使われるのは「/yomiyasu」と送ったとき、「この文章を yomiyasu で推敲して」のように依頼の文に名前を書いたとき、「日本語を推敲するスキルを使って」のようにスキルでの推敲をはっきり頼んだときです。名前を出さずに日本語の文章を書かせる作業や、コード、設定、ドキュメントを直す作業では使われません。2.0.1 までは「この文章を読みやすくして」のような名前のない依頼でも使われていましたが、2.0.2 からはこうした依頼にも名前が要ります。 これまでのように、AI が書いたり直したりする日本語をいつも yomiyasu に通したい場合は、指示のファイルに次の1行を足してください。Claude Code ではプロジェクトの `CLAUDE.md` か `~/.claude/CLAUDE.md` に書きます。Codex ではリポジトリの `AGENTS.md` か `~/.codex/AGENTS.md` に書きます。 ```text 記事、ドキュメント、PR の説明文、コミットメッセージなどの日本語の文章を書いたり直したりするときは、常に yomiyasu スキルで推敲してください。コードを直したあとの作業の報告には使わなくてかまいません。 ``` 1行の中のスキルの名前は入れ方に合わせてください。`yomiyasu` のまま書くのは、Claude Code に `npx skills add`、`gh skill install`、`npx openskills install` でスキルとして入れた場合です。Claude Code にプラグインで入れた場合、Codex に `npx skills add` か `gh skill install` で入れた場合、Codex で使うリポジトリの `.agents/skills/` に置いた場合は、`yomiyasu` を `yomiyasu:yomiyasu` に書き換えてください。 openskills で入れたスキルを `AGENTS.md` から読むエージェントでも、スキルの名前は `yomiyasu` です。README にある `npx openskills read yomiyasu` を添えた1行を、`AGENTS.md` の `` の外に書いてください。2.0.2 に更新したら、`npx openskills update yomiyasu` のあとに `npx openskills sync` も実行してください。sync するまで `AGENTS.md` のスキルの description は 2.0.1 のままです。 Claude.ai の指示（設定の「Instructions for Claude」とプロジェクトの指示）に書く例も含めて、入れ方ごとの1行は README の「[毎回 yomiyasu を使いたいとき](./README.md#毎回-yomiyasu-を使いたいとき)」にあります。 変えたのは SKILL.md の前置きの `description` だけです。スキルの名前と呼び方（「/yomiyasu」、`$yomiyasu:yomiyasu`、依頼の文に「yomiyasu で」と書く）は変わりません。スキルが選ばれたあとの書き直し方と、スクリプトの出力も 2.0.1 と同じです。README と docs/usage.md の依頼の例にも名前を入れ、「この文章を yomiyasu で読みやすくして。」の形にしました。 名前を出した依頼、名前を出さない作業、名前を出さずに推敲を頼む依頼を用意して、2.0.1 と 2.0.2 のスキルの description で選ばれ方を比べました。 | 依頼 | Claude Code 2.0.1 | Claude Code 2.0.2 | Codex 2.0.1 | Codex 2.0.2 | |---|---|---|---|---| | 名前を出した依頼（「/yomiyasu」、`$yomiyasu:yomiyasu`、「yomiyasu で」など） | 66/66 | 66/66 | 24/24 | 24/24 | | 名前を出さない作業（記事、翻訳、コミットメッセージ、PR の説明文、コードの修正、設定の変更など12種類） | 10/72 | 0/72 | 27/36 | 0/36 | | 名前を出さずに推敲を頼む依頼（「読みやすくして」「AIっぽさをなくして」「仕様書を見直して」） | 18/18 | 0/18 | 9/9 | 0/9 | 表の数は yomiyasu が使われた回数と試した回数です。Claude Code（2.1.296、Claude Opus 5.5、effort high）ではプロジェクトに置いたスキルとプラグインの2つの入れ方で、依頼ごとに3回ずつ試しました。名前を出した依頼は11種類で、「日本語を推敲するスキルを使って」のように名前を出さずにスキルでの推敲をはっきり頼む依頼を1種類含みます（Codex の8種類も同じです）。名前を出さない作業で 2.0.1 が yomiyasu を使ったのはブログの記事、技術記事、社内レポートを書かせた回だけで、72回のうち10回でした。 Codex（codex-cli 0.162.1、gpt-6-astra、effort high、fast）では、作業するリポジトリの `.agents/skills/` に置いたスキルで、名前を出した依頼8種類、名前を出さない作業12種類、名前を出さずに推敲を頼む依頼3種類を3回ずつ試しました。Codex で名前を出さない作業のうち 2.0.1 が毎回 yomiyasu を使ったのは、README の節の追加、ブログの記事、翻訳、コミットメッセージ、CHANGELOG、PR の説明文、技術記事、仕様書の更新、社内レポートの9種類で、コードの修正、設定の変更、変数の名前の変更では使いませんでした。 上の1行を足すと、名前を出さない作業のうち文章を書く作業で yomiyasu が使われ、コードや設定だけを直す作業では使われませんでした。Claude Code では README の節、ブログの記事、翻訳、コミットメッセージ、CHANGELOG、PR の説明文、技術記事、社内レポートを書かせた回と、名前を出さずに推敲を頼んだ回で毎回使われ、Python のバグの修正と設定の変更では使われませんでした（2つの入れ方を合わせて6回ずつ）。Codex では README の節、ブログの記事、コミットメッセージを書かせた回と、名前を出さずに推敲を頼んだ回で3回とも使われ、Python のバグの修正、設定の変更、変数の名前の変更では3回とも使われませんでした。Codex で試したこの7種類を、仕上げた 2.0.2 のファイル一式を入れた Claude Code でも2つの入れ方で2回ずつ試すと、同じ結果になりました。 ### 変更 - 1つの段落に、表示されない太字（`bold_not_rendered`）が多くある文書で、lint の時間が崩れの数のおよそ2乗で増えていたのを直しました。直し方の案を1つ試すたびに段落全体を解析し直していたためです。2.0.2 の lint は案が動かす数文字の前後だけを見て、段落全体を解析し直したときと同じ答えになると言える場合に限り、元の解析の結果から案の良し悪しを決めます。言えない場合は今までどおり解析し直します。元の解析の結果を引くための表は、段落の中で確かめる案が多く残っているときだけ作ります。diff も書き直した文の太字の検査に同じ処理の写しを持っていて、check run の中で時間切れになるおそれがあったので、同じように直しました。 - `これは **「重要」**です。` を1段落に並べた文書で、lint の CLI にかかった時間は次のとおりです（Python 3.14.5、macOS、同じ機械で測った値。2.0.1 は3回、2.0.2 は5回の中央値）。 | 1段落の組数 | 2.0.1 | 2.0.2 | |---:|---:|---:| | 1,000 | 3.65秒 | 0.10秒 | | 2,000 | 15.4秒 | 0.14秒 | | 3,000 | 33.1秒 | 0.17秒 | | 5,000 | 92.3秒 | 0.24秒 | diff と check run も同じ文書で測りました（書き直した文がこの文書で、原文は短い文。3回の中央値）。diff は1,000組で3.09秒が0.19秒、3,000組で28.3秒が0.32秒に、check run は1,000組で3.41秒が0.41秒、3,000組で29.3秒が0.54秒になりました。崩れのない5千字、5万字、20万字の文書と、崩れた太字が段落ごとに1組ずつの文書では、lint の時間は 2.0.1 とほぼ同じでした（差は4%未満）。 - lint の試験 `tests/test_lint_performance_regressions.py` に4件足し、diff の試験 `tests/test_v202_diff_bold_performance.py`（4件）を新しく作りました。解析した字数と `**` の前後を調べた回数が組の数に比例すること（組の数を2倍にして3倍未満）、元の解析から決めた案が案ごとに段落全体を解析し直したときと同じになること、表を作るのは確かめる案が段落に多く残るときだけであることを見ます。 - `--state-dir` と環境変数 `YOMIYASU_STATE_DIR` の値の頭にある `~` を、ホームフォルダに置き換えるようにしました。これまでは `~` を置き換えなかったので、`YOMIYASU_STATE_DIR="~/yomiyasu-state"` のように引用符で囲んだ値や、エージェントの設定ファイルに書いた値では、作業ディレクトリの下に `~` という名前のフォルダを作り、そこに記録を置いていました。 - 置き換えるのは値が `~` だけのときと、`~/` で始まるとき（Windows では `~\` も）だけです。動きが変わるのはこの形の値だけで、絶対パスと、この形でない相対パスは 2.0.1 と同じに扱います。`~user/...` や `~x` のような値と、途中に `~` がある値も、これまでどおり作業ディレクトリからのパスです。空白だけの値と、展開されずに `${` が残った環境変数を使わないことも変わりません。 - check の run、verify、start、export、end と任意のフック（`yomiyasu_hook.py`）は、同じ決まりで置き換えます。展開されずに届いた `~/...` と、シェルが展開したホームフォルダの絶対パスは、同じフォルダになります。 - `~` だけを指定すると、ホームフォルダそのものが状態フォルダになり、`index/` や `runs/` などのフォルダがホームフォルダの直下にできます。ホームフォルダはすでにあるフォルダなので、`.gitignore` と `state.json` は作りません。ふつうは `~/.yomiyasu` のように、ホームフォルダの下のフォルダを指定してください。 - フックを使っている場合は、2.0.2 に更新したあとに `yomiyasu_hook.py --print-config` で設定の例を出し直し、貼り直してください。2.0.1 のフックと 2.0.2 の check を組み合わせると、`~` で始まる値のときに2つが別のフォルダを見て、フックが check の記録を見つけられません。プラグインで入れた場合は、更新でスクリプトのパスも変わります。 - ホームフォルダが分からない環境ではこれまでどおり値をそのまま使います。`HOME` がなく利用者の情報からも決まらないときと、`HOME` が空か `/` だけのときがこれに当たります。 - 2.0.1 までに作業ディレクトリの下にできた `~` フォルダの記録は、新しい場所へ移しません。この記録は 2.0.2 の verify では見つからないので、run をもう一度実行してください。要らなくなった `~` フォルダを消すときは、`rm -r ./~` のように `./` を付けてください。`./` を付けずに `rm -r ~` と打つと、シェルが `~` をホームフォルダに置き換えるので、ホームフォルダを消してしまいます。 - 試験に `tests/test_v202_state_dir_home.py`（16件）を足しました。check とフックが同じ値から同じフォルダを選ぶこと、フックが登録した原稿を check が見つけ、check が登録した原稿をフックが見つけること、`~` の決まりに当たらない値と、ホームフォルダが分からない環境の値が 2.0.1 と同じに扱われることを見ます。 - プラグインの設定ファイルの重複を整理しました。Claude Code のプラグインの設定がリポジトリの直下と `skills/yomiyasu/.claude-plugin/` の2か所にあったので、`skills/yomiyasu/.claude-plugin/` の2つのファイル（`plugin.json` と `marketplace.json`）を消しました。 - Codex で使うリポジトリに `skills/yomiyasu/` を写して置く形では、スキルの名前はこれまでどおり `yomiyasu:yomiyasu` です。名前を決めていた設定は Codex が読む `skills/yomiyasu/.codex-plugin/plugin.json` に移しました。このファイルには名前だけを書き、版の番号は書きません。 - スキルのフォルダを Claude Code の `~/.claude/skills/` などに入れても、スキルを1つも持たない `yomiyasu@skills-dir` というプラグインが登録されることはなくなりました。2.0.1 ではフォルダの中の `.claude-plugin/plugin.json` から、このプラグインが `claude plugin list` に載っていました。スキルそのものの読み込みは 2.0.1 と同じです。 - Claude Code のプラグイン（`/plugin marketplace add nanaism/yomiyasu`）、`npx skills add`、`gh skill install`、`npx openskills install`、登録用の ZIP は、2.0.1 と同じように使えます。ZIP に入れるファイルは 2.0.1 と同じ名前の35個で、`.codex-plugin` は含めません。 - README の lint の節と docs/tools.md に、lint の `--json` を 1.1.2 までのキーの名前（`score`、`is_clean`）で読んでいるスクリプトへの案内を足しました。2.0.0 からの名前（`rule_penalty_score`、`no_rule_findings`）と、`format_version` で形式を見分ける jq の例を載せています。JSON の出力は変えていません。 - diff の時間を測る試験（`tests/test_v200_diff_full.py` の `TestPerformance` と `TestPerformanceEdges`）を、機械の速さで結果が変わりにくい形にしました。8コアの Linux ではコードを変えていない状態でも、数値を1万個含む1行を消す試験が3.0秒の上限を超えて失敗することがありました。 - 同じ形で4分の1の大きさの文書も同じ子プロセスで測り、時間の伸びが8倍未満であることを見ます。大きさに比例する処理なら約4倍、大きさの2乗で伸びる処理なら約16倍になるので、2乗で伸びる悪化は今までどおり見つかります。 - 秒数の上限は 2.0.1 と同じです。同じ子プロセスで決まった量の計算（基準の処理）も測り、その機械が作者の機械より遅いときだけ、遅い比の分だけ上限を延ばします。時間は CPU 時間で測り、最大5回の最も速い値を使います。子プロセスの打ち切りは30秒から60秒にしました。 - diff の数値の比べは値ごとにその行の文を前から順に見ていたので、1行の文の数と値の数の積で時間が伸びていました。文の位置を二分探索で引く形に直しました。全文差分の部品をつなぐ所でも、長い行で部品を1つつなぐたびに行の全体を写し直していたのを、まとめて1回でつなぐ形にしました。どちらも出力は同じです。数値を1万個含む6万字の1行を「なし。」にする diff の CLI は1.54秒が0.37秒に、4万個含む27万字の1行では20.4秒が1.27秒になりました（Python 3.14.5、macOS。1万個は3回の中央値、4万個は1回）。この直しで、上の試験のうち伸びを見られなかった3つ（数値を1万個含む1行を消す試験と、「。」のない6万字の1行を全面に書き換える2つの試験）も、伸びを見るようにしました。 - 英語の短い紹介 `README.en.md` を足し、README の頭からリンクしました。yomiyasu が日本語の文章を推敲するスキルであることと、入れ方、使い方、付属ツール、限界、ライセンスを書いています。くわしい説明は今までどおり日本語の README と docs/ にあります。 - GitHub Actions の CI（`.github/workflows/ci.yml`）を足しました。Ubuntu の Python 3.9 と 3.14 でテスト一式を動かし、`scripts/` と `skills/yomiyasu/scripts/`、`references/` と `skills/yomiyasu/references/` が同じかを確かめます。 - README のポスターの画像を 2.0.2 のものに替えました。 ### 変わらないもの - diff、lint、check の出力、オプション、終了コード、JSON の形は 2.0.1 と同じです。JSON の `tool_version` と `--version` の版だけが 2.0.2 になります。`--state-dir` と `YOMIYASU_STATE_DIR` に `~` だけの値か `~/` で始まる値を渡したときは、記録を置くフォルダと、出力に出る記録の場所が変わります。1つの段落に崩れた太字が多く、2.0.1 では lint か diff が `--timeout` の秒数を超えて run が `partial` になっていた文書では、2.0.2 の run は時間内に検査を終えるので、run の結果も変わります。 - SKILL.md の本文と references は変えていません。変えたのは SKILL.md の前置きの `description` と版の番号だけです。 - 2.0.1 で残した検査の記録を 2.0.2 の `verify` で照らすと、検査スクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 確かめたこと - v2.0.1 と同じ出力を出す基準のコミット（main の 84e1f5b）と 2.0.2 を同じ入力で動かし、標準出力、標準エラー、終了コードをバイト単位で比べて、出力が変わらないことを確かめました。版の文字列（2.0.1 と 2.0.2）だけは同じ文字に置き換えて比べています。Python の版を書いていない所は、Python 3.14.5 で比べました。 - `tests/corpus` の全ファイル164件で lint を8通り、corpus の推敲の48組と答え合わせの組から選んだ300組で diff を6通りと check run を2通り動かし、空のファイルや UTF-8 でないファイルなどの合成の入力と合わせた4,156件が、すべて一致しました。 - 崩れた太字を多く含む合成の文書など2,635本で lint の CLI を動かした15,795回が一致しました（7万字を超える合成の文書5本は3通り、ほかは6通りの引数で動かしました）。同じプロセスで動かした98,000本（文書の種類3通り）と、短い形を総当たりにした559,682本でも lint の出力が一致し、元の解析から決めた答えはどの案でも段落全体を解析し直した答えと同じでした。 - 崩れた太字を多く含む合成の文書22,000本で、diff の太字の直しを確かめました。文書は書き直した文と原文の両方に使いました。太字の検査、`--endings`、diff の JSON と通常の出力（種類なしと article）が一致し、元の解析から決めた案の判定289,840回は、案ごとに解析し直した答えと同じでした。CLI では corpus の48組と合成の404組で、diff の2,260回と check run の404回が一致しました。 - corpus の48組（原文と最終稿を入れ替えた向きも）と、1行に文と数値の多い合成の2,000組（9万字まで）で diff の数値の比べと部品のつなぎの直しを確かめ、diff の JSON と通常の出力、`full_diff()`、`meaning_risks()` が一致しました。このとき文の位置を引いた800万回あまりと、順の崩れた範囲を含む無作為の27万回でも、二分探索の答えは前から順に見る形と同じでした。 - 実際のモデルの推敲など答え合わせの1,415組で、diff のテキストと JSON（種類なし、article、mail、pr、essay）と lint の JSON が一致しました（版の番号を上げる前のファイルで比べました）。 - `~` を置き換えない値で状態フォルダの指定のしかたを変えた35通りでは、check とフックを合わせて715回のコマンドの標準出力、標準エラー、終了コードと、作られるファイルとフォルダの場所が 2.0.1 と同じでした。`HOME` が空の環境で `~/` で始まる値を渡す形も同じでした。`tests/corpus` の lint、diff、check run の806回も同じでした（Python 3.14.5 と 3.9.6 のそれぞれで比べました）。 - 表を作る条件を絞ったあとの形でも、`tests/corpus` の全文書、推敲の組、崩れた太字を含む合成の文書などで lint、diff、check の CLI を動かした5,734件が、Python 3.14.5 と 3.9.6 のそれぞれで基準のコミットと一致しました。同じプロセスで動かした合成の文書（3.14.5 で110万本あまり、3.9.6 で70万本あまり）でも、太字の検査の答えに違いはありませんでした。 - 試験一式は Python 3.14.5 で1,778件（subtest 6,641件）、3.9.6 で1,778件が通りました。 - 入れ方は macOS で確かめました。設定を分けた空の場所に、手元のリポジトリの写しから入れています。Claude Code 2.1.296 のプラグイン（`claude plugin marketplace add` と `claude plugin install`）ではプラグインのスキルが1つ読み込まれました。skills CLI 1.7.2、gh 2.100.0 の `gh skill install --from-local`、openskills 1.5.0 でもスキルが入りました。codex-cli 0.162.1 で `.agents/skills/yomiyasu/` に置いたスキルが `yomiyasu:yomiyasu` の名前でモデルに渡る一覧に載ることも、`codex debug prompt-input` で確かめました。 - 登録用の ZIP を作り、35個のファイルが入り、`.codex-plugin` と `.claude-plugin` が入らないことと、展開した中身で lint、diff、check が動くことを確かめました。 - 公開したあと、GitHub の nanaism/yomiyasu からも入れて確かめました。 - Claude Code のプラグイン（`claude plugin marketplace add nanaism/yomiyasu` と `claude plugin install yomiyasu@yomiyasu`）、`npx skills add nanaism/yomiyasu`、`gh skill install nanaism/yomiyasu yomiyasu`、`npx openskills install nanaism/yomiyasu` のどれでも 2.0.2 のスキルが入りました。 - Claude Code は、プラグイン、`npx skills add`、`gh skill install` のどれで入れたスキルも読み込みました。`npx skills add` は、既定のシンボリックリンクで置く形と `--copy` で写す形の両方で試しました。 - openskills では `AGENTS.md` に yomiyasu の項目が書かれ、`npx openskills read yomiyasu` で 2.0.2 のスキルを読めました。 - Codex は、`npx skills add` と `gh skill install` で入れたスキルと、README の手順で `.agents/skills/` に写したスキルを、`yomiyasu:yomiyasu` の名前でモデルに渡る一覧に載せました。 - リリースの `yomiyasu.zip` をダウンロードすると、上で作った登録用の ZIP と同じものでした（sha256 が一致）。 ### 限界 - 選ばれ方は対話を使わないコマンド（`claude -p` と `codex exec`）でだけ測りました。対話の画面、`~/.claude/CLAUDE.md` と `~/.codex/AGENTS.md` に1行を書く形、Claude.ai の指示に書く形、Cursor では、選ばれ方も1行が効くかも確かめていません。 - `~user/...` の形はホームフォルダに置き換えません。`~\` で始まる値を置き換えることは、Windows のパスをまねた試験で確かめただけで、実機では動かしていません。 - 太字のすぐあとに URL が続く崩れを含む段落では、lint が 2.0.1 より13〜17%遅くなることがあります。URL が続く崩れを3組か4組ずつ含む段落と、直せる崩れ2組と URL が続く崩れ2組を含む段落を並べた合成の文書で測りました（同じプロセスで lint を動かした CPU 時間。URL が続く崩れを3組ずつ含む段落を2,000並べた19万字の文書では0.47秒が0.55秒）。直し方の案を元の解析から決めるための表を作っても、URL が続く組では表から案を決められず、段落全体を解析し直すためです。直せる崩れを2組か3組ずつ含む段落と、URL が続く崩れが2組だけの段落では、差は5%未満でした。 - 崩れた太字と同じ段落に `<` や `
`、閉じていないリンク、太字に続く URL があると、lint と diff の太字の検査は 2.0.1 と同じく崩れの数の2乗で伸びます（同じプロセスで lint を動かした CPU 時間で、1段落に1,000組で約3秒、どの組にも URL が続く形では約11秒）。 - 2.0.1 の限界に書いた diff の遅い形のうち、同じ形の文が並ぶ文書の全面書き換えで文の数の2乗で伸びる所は、2.0.2 でも変えていません。同じ限界に書いた、句点のない長い1行（20万字ほど）が既定の90秒を超えることがある形は、2.0.2 では測り直していません。 - Python 3.8 そのものでは動かしていません（3.8 の文法で書いたことを確かめ、3.9.6 と 3.14.5 で試験を流しました）。 ## 2.0.1 - 2026-10-17 このバージョンでは、diff の計算を速くしました。出力は 2.0.0 と1字も変わりません。長い文書で diff が check run の既定の時間（90秒）を超え、検査が partial で終わっていたのを直すためです。 ### 変更 - 推敲の前と後を1文字ずつ照らし合わせる処理（`_rule_candidates` の文書全体の照合と、`_char_segments` の照合）を、difflib と同じ答えを少ない計算で求める照合に替えました。 - difflib の答えは、いちばん長い一致で、同じ長さなら原文で前のもの、それも同じなら最終稿で前のものです。この決まりから、一致の左に残る範囲では一致の長さが k−1 以下、右に残る範囲では k 以下だと分かります（k は見つけた一致の長さ）。新しい照合はこの上限を使い、上限の長さちょうどの一致を部分文字列の表で探す、種（短い部分文字列）で長い一致を探す、接尾辞オートマトン、長さの二分探索、difflib と同じ DP のうち、範囲に合う手で同じ答えを求めます。どの手も同じ値を求めるので、手の選び方と定数は時間だけを変えます。 - 文字列どうしでないとき、捨てる要素（isjunk と autojunk の popular）があるとき、範囲の引数が範囲の外か int でないときは、今までどおり difflib で求めます。 - 照合を速くしたあとに文書の大きさの2乗で効いていた処理（`_widen_to_sentences`、`_pair_gone_sentences`、`_ending_changes_from_units`、`_Masker.mask`）を、同じ結果になる形に書き直しました。長い文どうしの似かたを求める所（両方の字数の積が160,000を超えるとき）も、新しい照合を使います。 - diff の CLI の時間は次のとおりです（Python 3.14.5、macOS、同じ機械で測った値）。 | 文書 | 2.0.0 | 2.0.1 | |---|---|---| | 37万字の文書（55か所の直し） | 371.7秒 | 1.4秒 | | 似た段落を全部書き直した合成の文書（3万字） | 155.4秒 | 0.54秒 | | 似た段落を全部書き直した合成の文書（6万字） | 894.5秒 | 1.2秒 | | 推敲の出力48組を9回つないだ文書（19万字） | 124.2秒 | 2.2秒 | 2.0.1 は3回の最小、2.0.0 は1回です。37万字の文書の check run は、2.0.0 では既定の90秒で diff が時間切れになり partial でしたが、2.0.1 では1.6秒で executed になります。答え合わせの1,415組をまとめて検査する CPU 時間の合計は、48.7秒から33.3秒になりました。 - 出力が変わらないことは、次のように確かめました。 - 実際のモデルの推敲など1,415組で、diff のテキストと JSON（文書の種類なし・article・mail・pr・essay）と lint の JSON を 2.0.0 と比べ、Python 3.14.5 と 3.9.6 のどちらでも違いは0組でした。 - 新しい照合を、difflib と無作為の入力（字の種類の少ない文字列、同じ段落の繰り返し、同じ長さの一致が並ぶ形など）で突き合わせ、合わせて40万組以上で食い違いはありませんでした。 - 37万字の文書（55か所の直し）の diff の出力は、2.0.0 と1字も変わりません。 - 試験に `tests/test_v201_fast_match.py`（27件）を足しました。difflib との突き合わせ、difflib に任せる入力、3万字の全面書き換え、書き直した4つの処理の新旧の比べを見ます。 - 大きな文書では、使うメモリが2割ほど増えます（37万字の組で、最大 108MB から 131MB）。 ### 変わらないもの - diff、lint、check の出力、オプション、終了コード、JSON の形は 2.0.0 と同じです。JSON の `tool_version` と `--version` の版だけが 2.0.1 になります。 - 2.0.0 で残した検査の記録を 2.0.1 の `verify` で照らすと、検査スクリプトが変わったので `tool_changed` になります。もう一度 `run` を実行してください。 ### 限界 - 同じ形の文が並ぶ文書の全体を書き換えると、書き直した文と元の文の組を比べる所（`_ending_changes_from_units`）が文の数の2乗で伸びます。25万字の合成の文書で約10秒、49万字で約34秒です。70万字を超える全面書き換えでは、check run の既定の90秒を超えることがあります。 - 句点のない長い1行（20万字ほど）は、まだ check run の既定の90秒を超えることがあります（2.0.0 からある処理です。10万字の1行は約90秒から約14秒になりました）。 - Python 3.8 そのものでは動かしていません（3.8 の文法で書いたことを確かめ、3.9.6、3.10、3.14.5 で試験を流しました）。 ## 2.0.0 - 2026-10-16 このバージョンでは、検査を実行したかと、検査した原稿と最終稿が同じかを、記録で確かめられるようにしました。lint の点数は通常の出力から外し、diff は変わった箇所をすべて示すようにしました。diff は、推敲で起きやすい4つの変化（否定対比の主張の逆転、元にない気持ちの語、文体の硬化、勢いの喪失）も候補として出します。どの検査の結果も見直し候補です。意味が保たれたことや、読みやすさの合格を示すものではありません。 ### 互換性のない変更 | 対象 | 1.1.2 まで | 2.0.0 | |---|---|---| | lint の JSON | `score`、`is_clean` | `rule_penalty_score`、`no_rule_findings` に名前を変えました。前の名前は残していません。`rule_penalty_score` は計算も変えました（次の行）。`format`、`format_version`（2）、`tool_version`、`candidate_count`、`counts`、`not_judged`、`context` を足しました。形式は `data.get("format_version", 1)` で見分けられます | | lint の点数（JSON の `rule_penalty_score`。`yomiyasu_check.py run --json` の `lint.rule_penalty_score` も同じ値） | `score` は100から、warn と error を1件5点、info を1件2点引き、0で止めました。同じ文章を2回つなげると下がり、長い文書はすぐ0になりました | 規則に当たった候補の重み（error 3、warn 2、info 1）を地の文1,000字あたりに直した x から、100 × 40 ÷ (40 + x) を四捨五入し、候補があるときは1〜99に収めます。地の文は、コード、表、引用、前置きの設定、見出し、URL を除いた字数で、1,000字に満たない文書は1,000字として割ります。excess_bold と excess_list は1件で x に2、bold_label_list は1を足し（1,000字の文書で1件と同じ）、negative_parallelism_density は数えません。ダッシュの規則は、候補に出さない4行目からも、当たった行をすべて数えます。候補0件は100のままです。地の文1,000字以下の文書に候補が1件だけなら、warn 95、info 98 で前と同じで、error は93です。候補が2〜3件の短い文書では、前との差は3点以内です（warn 2件 90 → 91、info 2件 96 → 95、error 3件 85 → 82）。warn の多い文書（warn 7件 65 → 74）と長い文書は、前より高くなります。ダッシュの行が多い文書は前より低くなります（ダッシュの行が20行ある210字の文書は、前の85に対して50）。1.1.2 の `score` とは比べないでください。`--doc-type` で候補が変わると点数も変わります。`format_version` は2のままです | | lint の通常の出力 | 点数の見出し、`[PASS]`、`[NOTICE]`、参考値の3行（文字数、太字の頻度、箇条書きの比率） | どれも出しません。1〜3行目は、検査を実行したこと、見直し候補の件数、意味の保持と読者にとっての分かりやすさは判定していないこと。候補は行の順に、規則の ID を付けて並べます（JSON の `findings` の順は変えていません）。参考値は JSON の `metrics` に残しています | | lint の終了コード | 内部の誤りでも1 | 1は `--strict` か `--fail-on` に当たったときだけです。内部の誤りと、出力先が閉じられて結果を最後まで書けなかったときは3です | | lint の入力 | `-` をファイル名として扱いました。BOM 付きのファイルで、先頭の設定（frontmatter）を見落とすことがありました。標準入力だけ CRLF が残りました。空の文字列のパスでは標準入力を読みました | `-` は標準入力です。ファイルも標準入力も、BOM を外し、改行を LF にそろえてから読みます。空の文字列のパスは終了コード2です | | lint の `
` | `
` の中の箇条書きも、箇条書きの比率（excess_list）に数えました | 行頭から書いた `
` と `
` が組になったときは、その間の箇条書きを比率に数えません（根拠を `
` に畳んだ文書で過剰な箇条書きが出るという、外部の利用者の指摘から入れました）。この組がある文書だけ、JSON の `metrics` に `details_list_lines`（中の箇条書きの行の数）が足され、`list_lines` は `
` の外の箇条書きの数になります（`list_lines` と `details_list_lines` を足すと前の `list_lines`）。`list_ratio` の分母は、空でない行の数から `
` の中の箇条書きの行を引いた数です。中に箇条書きを多く畳んでも、外の箇条書きの比率は薄まりません。分母から引くのは中の箇条書きの行だけなので、比率が 1.1.2 より上がることはありません。`total_lines` は今までどおり、全体の空でない行の数です。地の文の量の門（字数が300字を超える文書だけ箇条書きの比率を見る）でも、中の箇条書きの行の字数を数えません。外の地の文が短く、根拠の箇条書きを畳んだ文書で、畳んだ字数で門を通って excess_list が出ないためです（
を外した同じ文書と同じ扱いになります）。中に箇条書きがあれば、excess_list の候補に「リスト行: 外の数 / 全非空行: 比率の分母（
の中の箇条書きN行は数えていません）」を示します。excess_list が出なくなった文書では、`--strict` と `--fail-on warn` の終了コードが1から0になります。`
` のない文書の出力は変わりません | | lint の候補（`--doc-type` を付けないとき） | 本文に残った AI への指示と、「〜と言っても過言ではありません」の型は拾いませんでした | `instruction_residue`（info）と、`meta_filler` の「過言」の型（warn）の候補が、種類を付けなくても出ます（追加の項）。「過言」の文だけの文書では、`--strict` と `--fail-on warn` の終了コードが0から1になります。`instruction_residue` は info なので、終了コードは変わりません。tests/corpus の163本では、どちらの候補も0件でした | | diff の JSON | 9つのキー | 9つのキーの名前と中身は変えていません。`format`、`format_version`（2）、`tool_version`、`status`、`changed`、`candidate_count`、`meaning_risk_count`、`fail_on_meaning_risk_count`、`not_judged`、`context`、`meaning_risks`、`full_diff`、`stiffness`、`tone`、`feeling`、`hedges`、`immutable`、`politeness`、`register` を足しました。`meaning_risks` の要素の `kind` は `number`、`negation`、`swap`、`sentence_type`、`protected`、`citation`、`contrast_reversal`、`feeling`、`certainty`、`certainty_review`、`quote`、`state`、`promise`、`promise_review`、`claim`（`subkind` は `causal` だけ）のどれかです | | diff の通常の出力 | 候補がないと「（候補なし）」とだけ出しました | 状態を「変更なし」「変更はあるが、専用の規則に当たる見直し候補はない」「変更あり」の3つに分けて出します。意味が変わる恐れの節と、全文差分を出します。全文差分は意味が同じだという証明ではないことを、出力に書いています。文体の硬化と勢いの候補があるときは「■ 文体の硬化」「■ 勢い」の節を出し、そのうち見直し候補があれば、状態の行の末尾に「（文体の硬化と勢いの見直し候補 N件は下の節）」を添えます（最後の状態の行では「上の節」） | | diff の引数と終了コード | 3つ目の引数、知らないオプション、知らない `--stance` の値、`--endings` と `--json` の組を、黙って無視しました。使い方の誤りは1でした。`-h` はファイル名として扱いました | これらは使い方の誤りとして終了コード2です。`--stance 値` と `--stance=値` の両方を受けます。`-h` はヘルプを出して0です。`-` は標準入力です（2つのうち1つだけ）。内部の誤りは3です | | diff と check の `--fail-on=meaning-risk` | ありませんでした（`--fail-on` は、このバージョンで足しました） | 数値、否定、主語と目的語の入れ替え、文の種類の変化のほかに、引用の印の変化、確度を強めた書き換え、原文の状態の語が消えた書き換え、原文にない書き手の約束・保証・再発防止の誓いの足しがあると、終了コード1になります（check は、新規作成で資料にない数値も）。CI に入れるときは、この8つのどれでも止まります。数えない候補（変えない箇所の変化、否定対比の主張の逆転、元にない気持ちの語、確度を弱めた書き換え、かぎかっこの中の言葉の変化、因果の足しなど）と、数え方の細部は docs/tools.md の diff の節にあります | | diff の入力 | BOM と改行コードの違いを、本文の違いとして扱いました | コマンドから使うときは、BOM を外し、改行を LF にそろえてから比べます。違いは全文差分の注記に出します。BOM と改行コードだけが違うときも、状態は「変更なし」ではなく「変更はあるが、専用の規則に当たる見直し候補はない」で、「改行コード・BOM・末尾の改行だけが違う」と添えます（JSON の `changed` は true）。API の `diff()` は、渡された文字列をそのまま使います | | 3つのコマンドの引数 | lint はオプションの省略形（`--str` など）を受けました | lint、diff、yomiyasu_check.py は省略形を受けません。「-」で始まるファイル名は使い方の誤り（終了コード2）です | ### 追加 - `scripts/yomiyasu_check.py` を足しました。`run` は、最終稿に lint、原文と最終稿に diff（資料から新しく書いたときは資料との照合）をまとめて実行し、原稿・資料・最終稿のハッシュ、スキルと検査のバージョン、各検査の結果を記録に残します。`verify` は、提出の直前に最終稿のハッシュを記録と照らします。diff を実行していない記録、検査のあとに書き換えた最終稿、別の原稿の記録は、完了と扱いません。 - run の出力は、diff を実行したとき、記録の行のあとに「硬化の検査: …」「勢いの検査: …」の2行を出します。値は「候補なし」「候補1件」、参考だけなら「参考1件」、両方あれば「候補2件、参考1件」の形です。`--json` の `stiffness_check` と `tone_check` も同じ文字列で、diff を実行しなかったときは null です。lint、diff、資料との照合の候補が0件でも、文体の硬化と勢いの見直し候補があれば、1行目で「その節を原文と照らし」と案内します。 - run の出力に、lint の見直し候補の件数を原文と最終稿で並べた行（「見直し候補: 原文 N件 → 最終稿 M件」）と、「■ 直した箇所（Kか所。元と後）」の節を足しました。1.1.2 までは、推敲の前後を lint の点数で比べる使い方が多かったため、点数の代わりに件数と、直した箇所の元と後を先に見せます。行は記録の行と「硬化の検査:」などの行のあとに置き、件数は点数ではなく、増えても減っても読みやすさの良し悪しを示さないと添えます。原文の件数は、最終稿と同じ `--doc-type` と `--reader` で原文に lint をかけて数えます（必要な検査と記録には入れず、`--fail-on` にも数えず、数えられなくても状態を変えません）。直した箇所は、全文差分と同じ組を初めから10か所まで、長い所は変わり始めの少し前から60字ほどで切って出し、省いた所と切った所は全文差分で見られます。元と後で行の数が違う組があれば、別の段落どうしが並ぶことがあると案内に書きます。今までの節は順も中身も変えずにそのあとに置き、1〜5行目、状態の行、記録、終了コードは変えていません。新規作成では最終稿の件数だけを出し、資料を原文とみなしたときはその資料の件数と並べます。verify は、記録と合ったときに「記録の中身: 見直し候補 最終稿 M件、直した箇所 Kか所」の1行を足します。`--json` には、run に `candidate_counts` と `changed_places`、verify に `final_candidate_count` と `changed_place_count` を足しました（既存のキーは変えていません）。6万字ほどの合成の文書2つ（同梱のコーパスの推敲の組をつないだもの。直した所が20か所のものと564か所のもの）で、run の時間は3回の中央値で 2.77秒 → 2.83秒、8.74秒 → 8.60秒でした（「限界」に書いた、全体を書き換えて既定の90秒で partial になる文書とは別の文書です）。 - 記録は、git の最上位（なければ作業ディレクトリ）の `.yomiyasu/` に置きます（自分を無視する `.gitignore` を作ります。`--state-dir` か環境変数 `YOMIYASU_STATE_DIR` で場所を変えられます）。記録には原稿の写しが入り、外へは送りません。同じ権限で原稿と記録の両方を書き換えられる環境では、記録は実行漏れを見つけるためのもので、改ざんの防止や人の承認の証明にはなりません。 - 記録の `tools` には、検査スクリプトのほかに、`references/lists/` の4つの一覧のハッシュも残します（一覧がある置き方のときだけ。`version` は null。`--fact-gaps` を付けた run では `fact-gaps.txt` も足して5つ）。記録のあとで一覧を変えると、verify と `verify --replay` は `tool_changed` を返し、1行目で変わった一覧の名前を言います。記録の diff の `summary` には、文体の硬化と勢いの候補の数、そのうち見直し候補の数、level を残します（`stiffness_candidate_count`、`stiffness_review_count`、`stiffness_level`、`tone_candidate_count`、`tone_review_count`、`tone_level`）。 - ファイルを作らない対話のための `run --stdin` を足しました（区切りの行で原文と最終稿を渡します）。区切りの行は一字一句決まったとおりに書きます。`<<>>` のような書き損じ）があれば、行番号と行を示して終了コード2で止めます。 - 資料から新しく書いたときでも、資料の1つが最終稿とよく似ていれば、run はそれを原文とみなして diff も実行します。書き直す前の文章を資料として渡すと diff を飛ばせてしまうためです。 - verify に、照らす記録を絞る `--source`（記録の原文もこのファイルか）、`--run-id`（この実行の記録だけ）、`--since`（この時刻より前の記録を使わない）と、記録の写しで lint と diff を動かし直す `--replay` を足しました。run には `--run-id`、`--new-run`、`--timeout`、`--no-record`、`--session`（記録に入れるセッションの識別子。省くと環境変数 `YOMIYASU_SESSION`）があります。 - diff に全文差分と、意味が変わる恐れ（数値、否定、主語と目的語の入れ替え、問いと平叙、文の種類の印、コード・URL・引用など変えない箇所の変化、否定対比の主張の逆転、元にない気持ちの語）を足しました。 - 数値は、表記だけの違い（漢数字と算用数字、範囲・日付・時刻の書き方、数と単位の間の空白、3桁区切り）を候補にしません。漢数字は、頻度の年・月・週・日（年二回）、漢数字に続いた時・時間・週間・分・人・名・回・件・個・枚（十時三十分、一時間三十分、一人一回）、時刻を言う語（午前九時、朝九時）、元号（令和七年）のあとでも数として取ります。算用数字にしただけの書き換え（年二回 → 年2回）は候補にせず、値が変われば（年二回 → 年一回）候補にします。単位の付け外し（3回 → 3）、日付の月と日や時刻の時と分の入れ替え（10:15 → 15時10分）、範囲の端の消えた書き換え（3〜5日 → 3日）も候補にします。候補には、値が書かれている文の行を示します。 - 数量を言っていない「一つ」（一つの、一つずつ、もう一つ、一つも〜ない、一つひとつ）は、漢数字、算用数字、平仮名のどれで書いても（一つの、1つの、ひとつの）、それだけでは候補にしません。期間の全体を言う漢数字の値（今日一日、去年一年、日一日と）と慣用句の数（二分する、十二分に）も同じです。「一つのみ」「1つのみ」と、算用数字の期間の値（今日1日）は、数として数えます。ただし「一つずつ」は、組になった相手の文（2つの文をまとめたり分けたりしたときは隣の文も）に「まとめて」と同じ組の語（まとめて、一斉に、一気に、いっぺんに、同時に、並列、並行、一括、一度に）が新しく出れば候補にします。同じ組の語どうしの言い換え（まとめて → 一斉に）は候補にしません。語ごとの数で比べるので、元の文の別の節に「まとめて」があっても、推敲で足した「同時に」は候補にします。「一つずつ」の「複数」「いくつでも」と「一つの」の「別々」は、その動詞や名詞のすぐ前（複数でも選べる、別々のファイル）か「一つの」の名詞のすぐあと（窓口を別々にする）に出たときと、推敲後も1つの文のときは動詞や名詞のある節に出たときに数えます。「ずつ」「の」のあとに動詞や名詞がない文（質問は一つずつどうぞ → 質問はいくつでもどうぞ）と、推敲後も1つの文でその動詞や名詞を言い換えた文（質問は一つずつ受け付けます → 質問は複数でも構いません／ログと設定は一つのファイルに書く → ログと設定は別々に書く）では、相手の文のどこに出ても数えます。ただし、言い換えた1つの文では、数の主張が同じ語（「一つずつ」は 順に、順番に、個別に、一件ずつ。「一つの」は 同じ、同一、単一。打ち消したものと「手順に」の「順に」は除きます）があるとき、「一つずつ」の「複数の〜」「いくつかの〜」の〜が元の文にない名詞のとき（ファイルは一つずつ確認する → ファイルを見て、複数の誤りを探す）、元の文の主題と違う主語の節にあるとき（申請は一つずつ審査し、何人かの担当者が確かめます → 申請は逐一見て、複数の担当者が確かめます）は数えません。主語が違っても、その節に主題の語が出れば数えます（申請は一つずつ審査します → 担当者は複数の申請を見ます）。前から数えていた語（「一つずつ」の まとめて など、「一つの」の 複数、上限なし など）は、数の主張が同じ語があっても数えます。「一つの」は、ほかに「複数」「無制限」「上限なし」などと、名詞のすぐ前の「すべての」「各」「〜ごとの」が新しく出れば候補にします（一つずつ → まとめて、一つの → 複数の）。打ち消した語（並列にせず、複数のファイルに分けない）、別の述語にかかる語、名詞や動詞のすぐ前の「同じ」「順に」は、数の主張を変えていないとみなします。 - 平仮名の数（ひとつ〜ここのつ、ひとり、ふたり）も値として取ります。数量を主張しない値として扱い、相手の文に同じ単位の値があるときだけ比べます。そのため「1つ → ひとつ」「一人 → ひとり」「ふたり → 二人」は候補にせず、「ひとつ → ふたつ」「3人 → ひとり」は候補にします。「ひとつのみ」は数として数えます。数でない語（ひとつまみ、ひとりでに、ひとり言、家にいつつ）と「とお」は取りません。資料から書いたときの照合でも、資料の「ふたり」と最終稿の「二人」は同じ値として照らします。 - 数値の並びは、値と単位の組が元と後で同じで並びだけが変わったとき、同じ単位の数どうしの前後が入れ替わったか（部屋にふたり、廊下に3人 → 部屋に3人、廊下にふたり）、同じ語句に付く値が2つ以上の語句で入れ替わったとき（設計は3日、試験は2人 → 設計は2人、試験は3日）に候補にします。言い回しを変えて単位の違う数を入れ替えた推敲（まず設計に3日、次に試験に5時間 → 設計に5時間、試験に3日）も、数のすぐ前の2字と値の組が入れ替われば候補にします。数のすぐ前の 約、計、合計、最大、最小、最短、最長、およそ は飛ばして比べます。語順を変えただけの推敲（ひとりで2時間歩いた → 2時間、ひとりで歩いた／会議は3回、2時間ずつ行う → 会議は2時間ずつ、3回行う／移行は約2週間、検証で約3日 → 検証は約3日、移行で約2週間）は候補にしません。 - diff に、推敲で起きやすい4つの変化の検査を足しました。 - 否定対比の主張の逆転（`meaning_risks` の kind `contrast_reversal`）: 原文で「Aではなく」「Aは使わず」「Aはせず」などと否定していた A が、推敲後に「目的」「優先」「まず」などの語と同じ文で否定なしに出たときと、「AだけでなくB」「Aに加えてB」「AとB」のように B と並べて肯定されたときに出します。見出しと表の中も見ます。見出しの行と「Aは使わず」「Aはせず」の文では、「目的」などの語が A を肯定した節か、そのすぐ前の主題の句（最優先は、）か、重みの語だけの句（まず、第一に、何よりも、最優先で など。## まず、手作業で回す）にあるときだけ出します。重みの語だけの句から重みを取ったときは、原文で肯定した側（AではなくBの B）の語が同じ節の A より後ろに否定なしで出れば、A を下げた推敲とみなして出しません（## 手作業ではなく自動化で回す → ## まず、手作業の手順を自動化する）。ただし、B のすぐあとが「も」のとき（自動化も試す）、B を退ける言い方のとき（自動化を中止する、減らす、省く、捨てる、やめる）、B を置き換えられる側にしたとき（外部のツールは使わず、社内のツールで回す → まず、外部のツールで社内のツールを置き換える）は出します。否定された語には、見た目、使い方、締め切り、問い合わせのように送り仮名が間に入る語と、「高い品質」の「品質」のように前に語が付いた名詞も取り、候補には送り仮名まで示します。A を後ろへ回した形（Aは後に回す、Aは見送り、Aは減らす、Aの代わりに）、A のすぐあとに下げる語を置いた形（Aはその次、Aは二番手、Aは二番目、Aは脇に置く、Aは脇役、Aは添え物、Aはおまけ、Aはどうでもいい、Aはそのあとに回す）、A を別のものに置き換えた形（Aを B に置き換える・切り替える・移す・移行する・乗り換える・置換する・入れ替える・差し替える・変更する・改める・転換する、Aを B で置き換える。「Aは」「Aも」で始まる同じ形も）と、2つを比べた・確かめた形（AとBを比べた、AとBを確認した）では出しません。ただし、下げる語の前が別の名詞で終わるとき（品質を最優先にして速度はその次にする）は、下げたのは A ではないので候補にします。置き換え先が A を前に出す先のとき（本番、有効、先頭、既定 など。新機能を本番に移す）と、A を使う句のとき（クラウドを使う構成に移行する、手作業を中心にした運用へ切り替える）も、A を採った推敲として候補にします。「Bを A に置き換える」も候補です。 - 元にない気持ちの語（kind `feeling`）: 原文のどこにもない気持ちの語（ほっと、うれしい、安心など）を推敲で足したときに出します。「心配はありません」「条件を満足する」「売上が落ち込む」のような気持ちでない使い方は除きます。原文に「ありがとう」「すみません」などがあれば、「感謝」「申し訳」は原文にある気持ちとみなします。 - 文体の硬化（JSON の `stiffness`、「■ 文体の硬化」の節）: 推敲で、漢字の割合、平均の文の長さ、名詞化の言い回し、漢語が「の」で3つ以上続く形が増えた文と、文書全体を出します。コード、URL、表、見出しは数えません。文書全体の候補は、変わった文の組が2つ以上あるときだけ出します。補足のカッコを外して語を並べ直しただけの「の」の連続は出しません。 - 勢いの喪失（JSON の `tone`、「■ 勢い」の節）: 「！」「？」、絵文字、強める語（本当に、ぜひ、最強など）が減った行と、見出しの字数の合計が原文の7割未満になったときに出します。同じ段落に「！」が3つ以上あっても、減らせば候補です。間接の問い（「〜かとの質問」「〜かどうか」）にした文の「？」の減りと、見出しの中の絵文字の字数は数えません。長い行は、減った印のまわりだけを前後に並べます（1つの候補で5か所まで）。 - diff に、確度・かぎかっこ・文体の切り替えの検査を足しました。 - 確度: 確度の語を「可能性 < 見込み・推量 < 予定 < 断定 < 確実」の強さで比べ、組になった文ごとに強さの変化を出します。可能性や見込み・推量の主な慎重な語が消えた、またはより強い語に替わった書き換え（「検証する見込みです」→「検証する予定です」、「と思われます」→断定、「示唆する」→「示す」）は、意味が変わる恐れ `certainty`（`strengthened`）として `--fail-on=meaning-risk` に数えます。確度を弱めた書き換え、「ことがある」「傾向」「検討」など数えない語だけの変化、「確実に」「必ず」を足した・消した変化、予定の言い切り（「見直す予定です」→「見直します」）は `certainty_review` として出し、数えません。「予定」「見込み」は述語として確かさを言うときだけを見て、予定表や見込み客のような名詞は見ません。同じ強さの言い換え（「かもしれません」→「可能性があります」、「見込みです」→「そうです」「と期待しています」）は出しません。問いの文は比べません。確度を否定する形（予定はない、可能性は低い）は、両側で同じなら外してほかの語を比べます。推量の印が同じ強さの慎重な言い方に替わっただけの文（かもしれません → 恐れがあります、と思われます → 見込みです）は、意味が変わる恐れの候補から外し、`--fail-on` に数えないようにしました。外すのは、同じ節の同じ事柄について、主な慎重な語に言い換えたときだけです。述語の肯定と否定が替わった文、「とは限らない」や条件の形（恐れがあれば）にした文、慎重さを別の節や文へ移した文、同じ文のほかの慎重な語が消えた文、「ことがある」「検討」など数えない語や「らしい」との言い換えは、今までどおり候補にして数えます。「■ 文の種類の印が変わった文」と既存9キーは変わりません。推量の語がより強い語に替わった文（かもしれない → 見込み）は、同じ文に確度の強まりの候補が出ればそちらに任せ、出なければ印の候補を残します。それ以外の推量・意見の印が同じ向きに変わった文は、印の候補に任せ、確度の候補を重ねません。慎重な言い方・状態・約束の候補を重ねない判定には、外した印も使います。 - かぎかっこ: 地の文の「」『』の中の言葉が変わった・なくなった箇所を、意味が変わる恐れ `quote`（`changed`、`lost`）として出します。数えません。推敲後の対応する文の近くだけと照らすので、文書のほかの所に同じ言葉があっても、この文で「はい」が「いいえ」になれば出ます。かっこの中に句点のある会話（「うん。そう。」）も1つのかっことして見ます。空白や全角・半角、感嘆符、省略記号など書き方だけの違い、かっこを外しただけの変化、同じかっこを別の所へ動かしただけの変化は出しません。 - 文体の切り替え: 常体から敬体（または逆）に変わった文が3文以上で、原文のその文体の文の5割以上を占めるとき、新しい節「■ 文体の切り替え」（JSON の最後のキー `register`）に見直し候補を1件出します。check の run の `--json` には、ほかの検査の `stiffness_check` などと違って文字列のキーを足さず、結果は `diff.register` にあります。いくつかの文を1文に合わせて文体を変えたときも数えます。原文の主な文体を変えた形（`switched`）と、原文の揺れを多いほうにそろえた形（`unified`）を分けて書きます。引用ブロックと会話の行は数えず、「下さい」は「ください」と同じに読みます。`--doc-type mail` で敬語の度合いの割合の候補が出たときは、そちらに任せます。この節は状態の候補数と `--fail-on` に数えません。check の run は、この候補があるときだけ「文体の検査: 候補N件」の行を出します。 - 既存の9つのキー、既存の候補の並びと中身、`--fail-on` を付けないときの終了コードは変わりません。新しい候補が出ない文書では、人が読む出力も変わりません。`--fail-on=meaning-risk` を付けたときは、確度を強めた書き換えのある文書で、終了コードが0から1に変わることがあります。 - diff に、推敲で中身を足す・状態を消す書き換えの検査を足しました。 - 状態の語: 原文が「未定」「未確認」「不明」「調査中」「検討中」「保留」「回答を待っています」「まだ〜ていない」「予定はありません」「目処が立っていない」のように、まだ決まっていない・分かっていない・済んでいないと伝えていた語が、推敲後の対応する文で同じ状態の言い方に言い換えられずに消えた箇所を、意味が変わる恐れ `state`（`lost`）として出し、`--fail-on=meaning-risk` に数えます（「未確認です」→「別途確認させていただきます」、「未定です」→「来週中にお届けします」、「未確認です」→「影響はありません」）。同じ途中の状態の言い換え（「調査中です」→「調査しています」、「未定です」→「決まっておりません」、「承認待ちです」→「承認をお待ちしております」）は出しません。条件の中の語（未定の場合は）、時を言う「作業中は」、状態そのものを打ち消す言い方（未確認の項目はありません）、人を見送る「見送り」は見ません。別の項目の状態の語（「会場は未定です」）や、済んだと言い切った文の否定（「特定済みですが、解決は困難です」）では、残ったとみなしません。 - 約束: 推敲後に足された、原文にない書き手の約束（〜いたします、改めてご連絡します、こちらで用意します）、保証（追加の費用はかかりません、これまでの料金のままご利用いただけます、変えない）、再発防止の誓い（再発防止に努めます、今後このようなことがないよう確認を徹底いたします）を、意味が変わる恐れ `promise`（`added`、`guarantee`、`prevention`）として出し、`--fail-on=meaning-risk` に数えます。原文にある約束の敬語を上げただけ（送ります → お送りいたします、出すね → 提出いたします）、読み手への依頼の敬語、あいさつの定型、名乗りの文（以下のとおりご報告いたします）は出しません。再発防止の語は、書き手がこれから取り組む述語があるときだけ誓いとみなします（「再発防止策は実施済みです」は出しません）。謙譲の形、未来の印（今後、改めて、明日）、書き手の主語（弊社、私）のどれもない普通の「〜します」（疲労を軽減します、停止時間を短縮します）は、説明や手順の文かもしれないので `promise_review` として出し、数えません。 - 因果: 原文の別々の文を「〜した結果」「〜ことで」「につながった」でつないだ箇所、原文にない原因や効き目を足した箇所、原文の「〜時に」「〜際に」を「〜により」「〜ことで」と原因の言い方にした箇所を、意味が変わる恐れ `claim`（`causal`）として出します。数えません。原文の1文の「〜し、」「〜て」を「ため」と語にしただけの形と、「調べた結果、分かった」のような経緯は出しません。 - 同じ変化に数える候補を重ねないように、否定の候補、確度の強まり、文の種類の印（推量の印が足された文、依頼が書き手の行為に替わった文）が同じ文に出たときは、そちらに任せます。状態の語と同じ文の確度の見直し候補は、状態の候補にまとめます。 - 既存の9つのキー、既存の候補の並びと中身、`--fail-on` を付けないときの終了コードは変わりません。新しい候補が出ない文書では、人が読む出力も変わりません。`--fail-on=meaning-risk` を付けたときは、状態の語が消えた文書と、原文にない約束・保証・誓いを足した文書で、終了コードが0から1に変わることがあります。 - 語の表で見る検査なので、表にない言い回しは拾いません。原文にない評価の語と一般化・勧めの足しは、diff では拾いません。語の表で試しましたが、合成の組で評価の足しは14組のうち0組、一般化・勧めの足しは14組のうち6組しか出せなかったためです（docs/limitations.md）。 - 否定対比の主張の逆転と元にない気持ちの語は「■ 意味が変わる恐れ」に出し、`meaning_risk_count` と状態の行の件数（diff の「うち意味が変わる恐れ K件」、yomiyasu_check.py の `meaning_risk=`）に入れます。`--fail-on=meaning-risk` には数えません。文体の硬化と勢いは見直し候補で、`candidate_count`、`status`、`--fail-on` に入れません。 - 文体の硬化と勢いの候補には、文書の種類によって参考（JSON の level が `info`、節の見出しは「参考 N件」）として出すものがあります。硬化は incident、formal、paper のとき、勢いは pr、article、incident、manual、formal、paper のとき、すべての候補を参考にします。ほかの種類でも、勢いの絵文字の候補は promo と mail を除いて、見出しの候補は promo、minutes、mail を除いて参考にします。種類を付けないとき、promo、mail は、どれも見直し候補（`review`）です。promo では、番号つき項目の行と太字だけの行も勢いの見出しに数えます。 - 検査に使う語の一覧を `references/lists/` に置きました（名詞化の言い回し `nominalization.txt`、強める語 `intensifiers.txt`、気持ちの語 `feelings.txt`、慎重な言い方 `hedges.txt`）。語を足し引きでき、BOM つきでも読みます。気持ちの語の一覧には、原文にあればその気持ちを原文にあるとみなす言い方を3つ目の欄に書けます。一覧がない置き方では内蔵の一覧で動き、JSON の `list` が `builtin` になります。一覧があるのに読めないときも内蔵の一覧で動き、節の見出しを「（一覧の注意）」にして理由を1行出します（JSON の `list_problem`）。 - `--fail-on` を足しました。diff と yomiyasu_check.py の `--fail-on=meaning-risk` は、数値、否定、主語と目的語の入れ替え、文の種類の変化、引用の印の変化、確度を強めた書き換え、原文の状態の語が消えた書き換え、原文にない書き手の約束・保証・再発防止の誓いの足し（と、資料から書いたときの資料にない数値）があるときだけ終了コード1を返します（確度、状態の語、約束は上の項）。コード・URL・引用など変えない箇所の変化、資料にない名前、否定対比の主張の逆転、元にない気持ちの語は、意味が変わる恐れとして出しますが数えません（JSON の `fail_on_meaning_risk_count` に入らず、`meaning_risk_count` には入ります）。ヘルプにも書いています。lint の `--fail-on` は warn と error を受けます。 - lint に2つの規則を足しました。 - `instruction_residue`（info）: 書き手が AI に出した指示や除外の判断が本文に残った文（「今回は一般論ではなく、自分の体験に絞って紹介します。」「この記事では〇〇は扱いません。」「前向きなトーンで、今回の障害を振り返ります。」「本稿では、結論だけを800字程度で簡潔にお伝えします。」など）を出します。書く行為の予告と、書き方・字数・範囲の条件が同じ文にあるときだけです。マニュアルや論文で読者のために扱う範囲を示す文、すぐあとに参照先（別の記事、付録、後述など）がある範囲の文、かぎかっこと引用の中は出しません。意図を断定できないので info です。 - `meta_filler` の「〜と言っても過言ではありません」（warn）: 「〜といっても過言ではない」「過言じゃない」「言い過ぎではない」と、文末に「でしょう」「かもしれません」「と思います」などが付いた形も出します。かぎかっこと引用の中、表現そのものを話題にした文は出しません。直しは、事実を淡々と書くことです。数値などの裏付けがあって誇張でない事実は残してかまいません（候補には出ます）。 - どちらも新しい候補が足されるだけで、ほかの規則の候補と metrics は変わりません。`--fail-on` を付けないときの終了コードも変わりません。「過言」の文だけの文書では、`--strict` と `--fail-on=warn` の終了コードが0から1になります。新しい候補が出た文書では `rule_penalty_score` が下がります（地の文1,000字以下で、ほかに候補がない文書なら、info 1件で2点）。tests/corpus の163本では、2つの規則の候補は0件でした。 - 限界: 「〜を中心にお話しします」「〜の話はしません」のように言い方が離れた指示は出しません。「ここでは、Linux に限定して説明します。」のような読者のための範囲の文にも出ることがあります。段落をまたいで遠く離れたかぎかっこの組の間や、リンクの文字の中の文には出ません。 - lint に、種類を指定したときだけ当てる規則 `pause_comma`（info）を足しました。短い主語や主題（「は」「が」「も」「には」「では」「からは」「については」など）のすぐあとに、読み分けの役目のない読点がある行を1行に1件出し、拾った句を3つまで示します（「回覧板は、木曜の朝に回します。」の「回覧板は、」）。直し方は読点だけを外すことです。 - 当てるのは、`--doc-type` に promo 以外の11種類を指定したときだけです。種類を指定しないときと promo では、出力も終了コードも変わりません。lint の `--help` の種類の一覧に1行足しました。 - 次の読点は拾いません。15字を超える句のあと、10字を超える節を含む句のあと、読点のあとに別の主語が来る所（会議では、担当者が説明しました）、条件・場面・時の枠（〜場合は、〜ときは、〜するには、〜したのちには）、並べ（東京も、大阪も、／平日と祝日は、／切符、地図、雨具は、）、分裂文（最初に手をつけたのは、）、文頭の接続と手紙の定型（では、具体的には、このたびは、皆様には、ますます〜）、逆接と譲歩（〜ですが、〜ても、）、引用・かっこ・コードの中、人と指示語の主題（僕は、私は、それは、）、外すと同じ字が続く所（妹は、はじめての〜）です。見出し、表、引用、コードの行は見ません。段落と箇条書きの項目の中の改行はつないで読みます。 - 種類を指定したときは、`rule_penalty_score` が下がり（地の文1,000字以下で、ほかに候補がない文書なら1件で2点）、yomiyasu_check.py の run では、候補がこの規則だけでも1行目が「下の候補を原文と資料に照らして確かめてください」になります。info なので、`--strict` と `--fail-on` の終了コードは変わりません。ほかの規則の候補と metrics も変わりません。tests/corpus の163本に article を指定すると、49本に60行の候補が出ます（raw_ai 6行、blacklist_ai 11行、edge_cases 3行、yomiyasu_rewritten 39行、human 1行）。 - 限界: 業務文の「私は、」のような人の主題と、15字を超える長い名詞の主題は拾いません。外すと掛かり先が変わる読点（店長は、慌てて逃げた客を追いかけた）、主題のすぐあとに並べが続く形（作業内容は、A、B、Cです）、小説の人物の名前の主題（太郎は、）は、候補に出ることがあります。句点がなくかなで終わる段落の最後の文は、あとが見えないので拾いません。 - references/slop-catalog.md に「9. 間を作るだけの読点」を足し、references/audience.md に、この規則を種類を指定したときだけ出すことを1行足しました。 - 3つのコマンドに `--version` を足しました。 - 文書の種類（`--doc-type`）と読者（`--reader`）を、lint、diff、yomiyasu_check.py の run に足しました。種類を指定すると、lint はその種類で普通な書き方を拾う規則の候補を外し、外した件数を出します（紹介記事・宣伝文 promo では、絵文字の `emoji_prohibited` と、評価の語を短く重ねる型の `fragment_run`）。diff の意味が変わる恐れと規則の見直し候補、資料との照合は、種類と読者で変わりません。文体の硬化と勢いの検査は、種類によって候補を参考としてだけ出し、promo では勢いの見出しの数え方が変わります（上の項）。値は JSON の `context`、記録の `options`、状態の行の `doc_type=` と `reader=` に残ります。 - 文書の種類に、メール・チャット（`mail`）と論文・研究レポート（`paper`）を足し、12種類にしました（lint、diff、yomiyasu_check.py の run の `--doc-type`）。mail では、lint が絵文字の `emoji_prohibited` と、`meta_filler` のうち返信と結びの5つの型（`ご質問ありがとうございます` `必要なら次に〜します` `いかがでしたでしょうか` `ぜひ〜してみてください` `参考になれば幸いです` など）の候補を外します。diff の勢いの候補は、絵文字と見出しも見直し候補のまま出します。paper では、lint の規則を外さず、diff の文体の硬化と勢いの候補をすべて参考にします。スキルは、mail では宛名、挨拶、結び、署名、クッション言葉、敬語の度合い、チャットの口語を残し、paper では慎重な言い方、引用の印と数値、専門用語、「である」調、条件と結果をまとめた長い文を残します（`references/doc-types/mail.md`、`paper.md`）。 - diff に、3つの検査を足しました。どれも見直し候補で、点数と `candidate_count` には入れません。JSON には `hedges`、`immutable`、`politeness` のキーを足しました（既存のキーの名前と中身は変えていません）。人が読む出力では「■ 慎重な言い方」「■ 動かしてはいけない値」「■ 敬語の度合い」の節に出します。run は、記録の行のあとに「慎重表現の検査」「値の検査」（mail では「敬語の検査」も）の行を出し、`--json` の `hedges_check`、`immutable_check`、`politeness_check` と、記録の `summary` にも件数を残します。 - 慎重な言い方の減り（種類によらず）: 一覧（`references/lists/hedges.txt`。と考えられる、と思われる、可能性がある、示唆する、推測される、の範囲では、かもしれない）の語が減った文を、前後を並べて出します。同じ文で文の種類の印の推量が消えたときは、その候補に任せて重ねて出しません。`--fail-on` には数えません。 - 動かしてはいけない値（種類によらず）: 引用の印（`[1]`、`[1, 3]`、`(山田 2020)`、`(Smith et al., 2019)` の形）が消えた、増えた、変わった箇所を、意味が変わる恐れ（kind `citation`）に出し、`--fail-on=meaning-risk` に数えます。番号や年だけの変化と、数字を含む印を消した・足した箇所は、同じ行に今までの数値の候補が出ていればそれに任せ、重ねません。括弧の全角と半角、空白、区切りの記号のような書き方だけの違いは候補にしません。全文差分で変わっていない行の値は比べず、同じ値が文書に何度もあっても、変えた行の値を候補にします。行の頭や宛先の欄の宛名（〇〇様、〇〇さん）と、リンクでないメールアドレスの変化は `immutable` に出し、`--fail-on` には数えません。数値の候補には、空白を挟んだ単位、同じ値の符号、統計の値の比較の記号の変化を足しました（数値の候補として `--fail-on=meaning-risk` に数えます）。run の「値の検査」の行は、`immutable` の候補に加えて、この検査で意味が変わる恐れに入れた候補（引用の印と数値）も「意味が変わる恐れ N件」として数えます（JSON の `immutable.meaning_risk_count`）。 - 敬語の度合い（mail のときだけ）: 1文あたりの敬語の数（いただく、くださる、申し上げる、存じます、させていただく）と、文末の「です・ます」の割合（「だ・である」との比）を推敲の前後で比べ、どちらかが20ポイント以上動いたら候補にします。 - tests/corpus の136組では、新しい候補は引用の印が2件（2組、1.5%）で、慎重な言い方と、宛名・メールアドレスは0件でした。全組を mail と指定すると、敬語の度合いの候補が9件（8組、5.9%）出ました。11件とも、引用の印や敬語の数と割合が実際に変わった組でした。正しい推敲の48組では、3つの検査とも0件（0%）でした。tests/corpus には実際のメールと論文がほとんどないので、拾い漏れの少なさはこの数からは言えません。 - 種類を付けないときと、mail と paper 以外の種類を付けたときは、既存の候補、metrics、既存のキー、lint の結果は変わりません。tests/corpus では、引用の印の候補が足された2組で、状態の行の件数が1件ずつ増えます。`--fail-on` を付けないときの終了コードは変わりません。`--fail-on=meaning-risk` を付けたときは、種類を付けなくても、引用の印、統計の値の比較の記号、同じ値の符号が変わった文書で、終了コードが0から1に変わることがあります（tests/corpus の136組では、終了コードが変わった組はありませんでした）。6万字ほどの文書の diff の時間は、変更の前の1.04〜1.06倍でした。 - references に、文書の種類ごとの注意（`references/doc-types/`）、種類と読者の決め方（`audience.md`）、検査の出力の見方（`review-points.md`）、言い直しテスト（`rephrase-test.md`）を足しました。 - 書き手と読み手（ペルソナ）を依頼で言われたときの直し方を、`references/persona.md` に足しました。上司と社外の読み手には、読み手への依頼を尊敬語に、社外の読み手に向かう書き手の行為を謙譲語に上げます。形は、同じ動詞に「お・ご」を付けた形のほか、その関係で人がふつう書く言い回しも使います（変更があれば言ってください → 変更があればお知らせください）。頼む中身、期限、選択肢は変えません。説明や手順を頼む「教えてください」は「お教えください」にせず、「ご教示ください」か「教えていただけますか」にします。書き手が自分でした行為で、ほかの人の行為と読み違えうる文には、原文にある書き手の一人称を主語に補います（3か所まで）。書き手と読み手を言われないときは、推定しただけで本文を変えず、推定した読み手を、変えなかった理由として返答に書くこともしません。メール（`doc-types/mail.md`）と `review-points.md` の「敬語を原文に戻す」指示は、関係を言われて上げた所には当てません。 - 推敲する原稿の中身や値の書かれていない所を、この会話と資料にある根拠の文で補う手順を SKILL.md に足し、細部を `references/fact-recovery.md` と `references/fact-recovery-details.md` に置きました。根拠にするのは、原文、依頼、資料、この会話の利用者の発言、開いたファイル、コマンドの出力で、AI 自身やほかの AI の発言、会話のまとめ、一般の知識は使いません。同じことを述べた根拠の文があるときだけ、確度を変えずに今の文の中で補い（補う・直すは合わせて5件まで）、なければ読み手が動けない所だけを、元の書き手にそのまま渡せる問い（3つまで）にします。AI が自分で書いた原稿では、読み手が動く値と、原因・結果・済んだかどうか・担当を述べた文を、合わせて10個まで材料と照らします。補った事実の出典と問いは、完了報告の新しい節「事実の確かめ」に書きます。補いに使った根拠の文は最終稿と同じフォルダの「最終稿の名前.material.txt」に一字も変えずに写し、check の run に `--material` で渡します。 - 種類がエッセイ・小説、紹介記事・宣伝文、公用文・規程・契約書・仕様書、論文・研究レポートのとき、本文だけを返す指定、「確かめずに」と頼まれたとき、Python を実行できないときは、会話やファイルから補いません。`references/doc-types/` の essay、formal、paper、promo にこの扱いを、mail に社外の宛先のときの扱いを、1行ずつ足しました。 - 開くファイルは原稿か会話に名前の出たものを3つまでで、読むだけです。認証情報らしいファイルは開きません。社外向けか分からない文書には、出典があっても、内部のホスト名や個人の情報などを入れません。 - 「/yomiyasu」と名前だけで呼ばれて作業フォルダから推敲する原稿を選ぶとき、yomiyasu が作った抜き書き（`.material.txt`）を候補から除きます。 - `yomiyasu_check.py run` に `--fact-gaps` を足しました（ファイルと `--stdin` の両方）。付けたときだけ、最終稿のうち、程度の語だけの文（大幅に）、変わる前と後の値がない変化（短くしました）、効果だけの文（信頼性が向上します）、中身の見えない比喩（土台づくり）を「■ 事実の穴の候補」の節に10件まで出し、3行目の最後に「、事実の穴の候補N件」を足します。候補は一部だけです。`--fail-on`、状態の行、必要な検査には入れません。候補があれば、ほかの候補がなくても1行目は「下の候補を原文と資料に照らして確かめてください」になります。`--doc-type essay` と `promo` では節を出さず、3行目に「事実の穴の候補（種類 essay では出していません）」のように書きます。formal と paper では節の見出しの文を「この種類では補わず、必要なら書き手への問いにしてください」にします。一覧は `references/lists/fact-gaps.txt`（「種類正規表現」の行）で、ないときや読めないときは内蔵の一覧で動き、読めなかったときは節の最後にそのことを1行出します。 - `--json` と記録の最後に `fact_gaps`（件数、種類ごとの件数、20件までの候補）を足しました。付けなかった run でも、キーは null で付きます。記録の `options` に `fact_gaps` を、付けた run の記録の `tools` に一覧のハッシュを足しました。`verify --replay` は、候補も記録の写しから作り直して照らします。記録のあとで一覧を変えると、付けた run の記録は、ほかの一覧と同じく verify で `tool_changed` になります。付けなかった run の記録は変わりません。 - 付けないときは、この節も3行目の足しも出ません。 - `--material` の中身と `run --stdin` の資料の部分で、`<<>>` の行（出典は省いてよく、200字まで）で資料を区切れるようにしました。空白でない最初の行が区切りの行のときだけ、区切りごとに別の資料にします。出典は記録の `inputs.materials[].label` と照合の JSON の `sources[].label` に残し、照合しません。`<<` を含む文書の箇条書きの数え方と、その excess_list に添える注記は除きます。上の互換性のない変更の表）。足した2つの規則（追加の項）は、新しい候補を足すだけです。 ### 訂正 - 1.1.2 の README とリリースノートで、lint の点数について「人が書いた文章16本の平均点は98.7点」「AUC は0.56（作った例を除くと0.53）」と書きました。この16本のうち8本（`tests/corpus/human/human_doc_*.md`）は、`scripts/setup_corpus_static.py` の中に書いた人の文章らしい例文で、人が書いた文ではありませんでした。AUC 0.56 は、AIの例文8本を人の文として数えた値です。コーパスの中で人が書いた文は、作者の記事1本を見出しで8つに分けた抜粋（`human_oga_*.md`）だけです。1人の書き手の8本なので、数え直した値は一般の値として載せません。点数で人の文章とAIの文章を見分けられないことと、点数が高いことは人が書いた証拠にならないことは変わりません。README の該当する段落と、`setup_corpus_static.py`・`benchmark_corpus.py` の説明を直しました。 - `evals/comparison_benchmark.md` のセット B で「人間が書いた元文章」としていた分散キューの設計メモも、作者が書いた覚えのない文で、AI が書いたものとみられます。見出しと表の列の名前を直しました。 - README からリンクしている解説記事（Zenn）にも、人が書いた文書を16本とした同じ数が載っています。正しい数は、この訂正のとおりです。 ### 限界（検査で拾えない形と、正しい推敲にも出る形） 細かい形と例は、README の「限界」の節に移しました（今は docs/limitations.md にあります）。種類ごとの要点は次のとおりです。候補に出なくても、変わった箇所は全文差分に出ます。 - 意味が変わる恐れに出ない形: 原文にない担当者や動作主を主語や通知先に足した推敲は、全文差分と「元の文にない語」には出ますが、意味が変わる恐れには出ません。 - 数値: 万と億を含む数の換算、「.」で区切った日付、時刻の「:00」などは、値が同じでも候補に出て、--fail-on に数えます。範囲の端の値の書き直し、平仮名の数を足しただけ・消しただけの書き換え、助数詞の一覧にない語の数の変化などは拾いません。 - 否定: 語ごと言い換えた否定は拾いません。文を分けて否定を次の文に移した正しい推敲は、否定の候補になります。 - 否定対比の主張の逆転: 平仮名で始まる語と漢字1字の語は、否定された語として取りません。見出しや「Aは使わず」の文、一覧にない言い方では、正しい推敲にも候補が出たり、逆転を見逃したりします。--fail-on には数えません。 - 文の種類の印: 依頼を前置きする文を依頼の文にした推敲と、結果を言う文を義務の文にした推敲は、正しくても候補になり、--fail-on に数えます。推量と意見の入れ替え（と考えられます → と考えています）、2つの慎重な言い方を1つにまとめた推敲（可能性があると考えられます → 可能性が考えられます）、表にない慎重な言い方への言い換え（かもしれません → リスクが考えられます）も、候補として数えます。逆に、推量の言い方を同じ強さの言い方に替えた文で、同時にほかの所の事柄が変わっても（本番の実測 → 本番相当の実測）、文の種類の印の候補には出ません。「可能性がある → 可能性も否定できない」「ようだ → と推測される」「と思われる → 想定です」も同じ強さと読みます。肯定と否定の違いは節の中の否定の形の数で見るので、否定の形を含む語への言い換え（枯渇を招く恐れがあります → 足りなくなるかもしれません）は、同じ強さでも候補に残ります。 - 元にない気持ちの語: 一覧の語だけを見ます。 - 文体の硬化と勢い: 変わった文が1つだけの文書では、小さな硬化は出ません。勢いは、評価の語を短く重ねる型を1文にした推敲と、一覧にない褒め言葉の繰り返しを減らした推敲を拾いません。 - 慎重な言い方、引用の印、宛名、敬語の度合い: 慎重な言い方は一覧の7つの語と同じ文字の並びだけを見ます（一覧に足せます）。「示唆した」「示唆される」のように形の変わった語が減っても拾いません。引用の印は、数字の角括弧と、著者と年をまとめた括弧の形だけを見ます。英字の著者は年の前に「,」か「et al.」があるものだけで、(Smith 2019) は拾いません（(Windows 2000) のような製品名と年の括弧を引用と取らないため）。漢字の名前と年の括弧は、(東京 1998) のような引用でないものも引用として見ます。本文に著者を書いた形（山田 (2020) によると）の著者の変化と、引用の印を別の文へ動かした推敲は拾いません。符号は直前が漢字や片仮名のときは見ないので、「前年比-5%」の符号の変化は拾いません（「10月-12月」の範囲を負の数と取らないため）。宛名は行の頭と宛先の欄のものだけで、本文の「田中さんは」は見ません。敬語の度合いは文書全体の割合で比べるので、短いメールでは1文の違いで候補になり、長い文書では1文の変化を拾いません。「ください」も「くださる」に数えるので、「〜いただけますでしょうか」を「〜してください」にしても候補は出ません。文末の割合は「です・ます」と「だ・である」の文だけで数えるので、チャットの口語（〜かも、〜しときます）を「です・ます」にそろえても候補は出ません。二重敬語を正しく直すと（ご確認させていただきました → 確認いたしました）、敬語の数が減って候補が出ます。20ポイントのしきい値は、実際のメールで測って決め直していません。二重敬語の誤り（ご確認させていただきました）は検査では拾わず、スキルが直します。種類を推定するのはスキルで、道具は推定しません。mail と paper の推敲の指針は、モデルに推敲させて結果を測っていません（tests/corpus で測ったのは道具の候補の数だけです）。 - lint の `
`: 行頭から書いた開きと閉じの組だけを見ます。 - 事実の補いと照合: `--fact-gaps` の候補は一部だけです（合わせ込んだあとに書いた合成の文で、出てほしい25文のうち17文）。照合の「資料に基づく補足の候補」と「単位のない数とだけ一致」は、資料に同じ値があることを示すだけで、根拠であることも正しいことも示さず、値の取り違えは止められません。抜き書きの中身がファイルや出力と同じかは確かめません。正しい補いでも、diff の意味が変わる恐れに出て、`--fail-on=meaning-risk` で終了コード1になります。 - yomiyasu_check.py: 本文に `<<