『yomiyasu（よみやす）』は、AIが生成した日本語の不自然な比喩、曖昧な主述関係、不要な装飾を直し、読みやすい文章に整えるスキルです。
主に技術記事、設計書・仕様書、PR説明文、社内レポートなどの実務的な文章を対象として設計されています。
Claude Code、Codex、CursorをはじめとするAIコーディング環境に読み込ませて使用してください。
2.0.0 からは、推敲の前と後を比べる検査をまとめて実行し、その記録を残すスクリプト（yomiyasu_check.py）を同梱しています。検査の実行漏れと、数値・否定などの変化を見つけやすくなりました。検査が出すのは見直し候補で、意味が保たれたことや読みやすさの合格を示すものではありません。このバージョンのスキルを実際に動かして確かめたのは、macOS の Claude Code と Codex を対話の画面なしで動かした形だけで、確かめた範囲は限界の節に書いています。
開発の背景、AI生成文の読みにくさ、コーパスを使った検証については、次の解説記事で紹介しています。
Built with curiosity at ALGO ARTIS
ALGO ARTISについて
株式会社ALGO ARTISは、社会基盤の最適化に取り組むスタートアップです。
電力・海運・化学プラントといった現場では、膨大な制約が絡み合う複雑な運用計画を、今なお熟練者が手作業で組み立てています。
そうした高度な現場業務を数理モデル化し、実用的なヒューリスティック最適化アルゴリズムと業務システムを一貫して開発しています。
AIによる文章生成は日常的な道具となりました。 一方で、AIで生成された文章には独特のクセが残りやすく、そのままでは実務や技術発信に使いにくい場面が多くあります。
これまでに様々な文体調整プロンプトやスキルが試みられてきましたが、依然として「AI特有の読みにくさ」が残るケースが見られます。
従来のアプローチが抱えていた限界は、主に次の4点でした。
- 禁止語の置き換えにとどまる対処 手触りや解像度、泥臭いといった表層の単語を禁止しても、別の曖昧な語へ置き換わるだけで、不自然な文構造そのものは解消されませんでした。
- 編集ルールの過剰適用 修辞規範を過度に与えると、モデルが指示を過剰に解釈し、かえって不自然な造語や大げさな文体を招いていました。
- 主述関係の曖昧さと非生物主語 誰が何をどうするのかが省略されたまま、概念や道具が比喩的な動詞（壊れる、倒す、効くなど）と結びつき、読み手側で過剰な文脈補完が必要でした。
- 形式の偏重と情報密度の低下 太字や箇条書きが増加する一方で、手順やコードの仕組みといった核心部分が抽象化され、文章量に対して実質的な情報が希薄化していました。
元の意味を保ち、読み違いや文の関係を追う負担がある箇所を直します。自然に読める部分は残します。
- 主述・修飾・条件の点検 主語と述語、修飾語と掛かる先、指示語と指す対象を対応づけます。条件・例外・否定・並列・数量・順序も、書き直す前後で同じように追えるか確かめます。主体や対象を補うのは、原文や提供文脈から確定できる範囲に限ります。
- 文の働きと文体の保持 文ごとの説明・依頼・助言・予定を区別し、働きに合わない文末だけを直します。完了した変更作業、現在の動作や方針、今後の予定を時制と役割に合わせて書き分け、語尾を散らすこと自体を目的にしません。変更指定がない常体・敬体は保ち、技術記事という分野だけで敬体へ変えません。
- 擬人化の整理 道具や概念に感情や意志を持たせた表現を直します。道具やシステムの客観的な動作を述べる非生物主語は残します。
- 比喩を平易な言葉へ
壊れる、倒す、効く、溶かすなどを、元の含みや意味の広さを保って言い換えます。動詞を替えた後も、主体・対象・修飾先を変えず、語順を追いやすくできるか確かめます。 - 前置き・否定対比の役割の確認 前置きを削るのは、削っても主張や比重が変わらない場合だけです。評価や必要な対比、比較から方針へ移る接続は残します。
- 情報を勝手に足さない 主張・比重・言い切りの強さ・文の働きを保ち、原文にない主体・原因・条件・数値・感情などを足しません。ルールを「契約」、比較の基準を「正本」と大げさに呼ぶ場合は役割に合う語へ直し、文字どおりの意味や定義済みの専門用語は保ちます。意味を確定できない箇所は、原文にある未確定の状態や既知の動作を本文に残した暫定文とし、推敲理由や確認事項は読者向け本文中ではなく本文の後に添えます。
- 文長・読点・装飾の調整 平均文長30〜45文字、1文の読点0〜2個を目安にします。読みやすい原文の読点を、数や見た目だけで削りません。主語の「が」、短い目的語の「を」、主題の「は」「も」「には」「では」「とは」のすぐあとに置いて間を作るだけの読点は、元の文にあっても外し、外すのは読点だけにします。主題のあとに別の動作主が続く所、長い主語や目的語のあと、並べを区切る所、外すと掛かり先が変わる所の読点は残します。不要な文末コロンと、ラベルと値の対応を示すコロンを区別します。箇条書きの頭のラベルとコロンは、値の項目と、物や作業の名前に説明が続く項目では残します。分類の語、出来事を名詞にまとめた語、短い述語のラベルでは、太字とラベルとコロンを外し、説明と合わせて1文にします。過剰な装飾記号を整理し、英単語や数値の前後の空白は元の書式や指定されたスタイルを保ちます。残す太字は表示される形に整えます。
書き直す前に、文書の種類（PR説明、障害報告、エッセイ・小説、紹介記事・宣伝文、メール・チャット、論文・研究レポートなど12種類）と読者の知識（3段階）を決め、種類に合わせて当てない規則を変えます（使い方の節）。
規則に当たった箇所は、直す前に案と原文を6点（何について述べるか、何を認め何を否定するか、誰が誰にするか、範囲と条件、言い切りの強さ、数値・固有名詞・時期）で比べます。1つでも変わるなら原文を残し、完了報告の「残したAIっぽいところ」に書きます（言い直しテスト）。
依頼で書き手と読み手を伝えると（「取引先の担当者に送るメールです」「書き手は新人の私で、上司に出す週報です」）、その関係に合わせて本文を直します。上司と社外の読み手には、依頼の文を尊敬語に（確認してください → ご確認ください）、社外の読み手に向かう書き手の行為を謙譲語に（連絡します → ご連絡いたします）上げ、ほかの人の行為と読み違えうる書き手の行為には、原文にある一人称を主語に補います。伝えないときは、推定しただけで本文を変えません（使い方の節）。
原稿に、比喩や誇張で中身の見えない所や、抜けた数値・条件・主語があるときは、同じことを述べた文を、原文、依頼、資料、この会話の利用者の発言、開いたファイル、コマンドの出力から探します。見つかればその文を根拠に確度を変えずに補い、見つからなければ本文に足さず、読み手が動けない所だけを元の書き手への問いにします。AI が自分で書いた原稿では、読み手が動く値（期限、数量、版、手順の値）と、原因・結果・済んだかどうか・担当を述べた文を、合わせて10個まで同じ材料と照らします（文脈から事実を補うときの節）。
書き直したあとは、付属の yomiyasu_check.py で lint と diff をまとめて実行し、提出の直前に、最終稿が検査したものと同じかを記録と照らします（付属ツールの節）。
次の2つの例はこのバージョンのスキルを Claude Code（Claude Opus 5.5）で1回ずつ動かした最初の出力です。よい回を選び直してはいません。依頼の文は「draft.md を yomiyasu で読みやすくして、結果を out.md に書いてください。」です。Before は 1.1.2 までの README と同じ文で、どちらも AI が書いた文章です（例1はデジタル庁の資料をもとに、例2は AI が書いたとみられる設計メモをもとに書かせたもの。evals/comparison_benchmark.md のセット A と B を短くしたもの）。After は最終稿そのままです。例ごとの最後の行は、スキルの実行とは別に、その最終稿を yomiyasu_check.py の run と verify（--replay 付き）に通し直したときの状態の行です。
SKILL.md の、言い換えるときに原文より強い確度や程度の語を足さないという1文は、前に作った例2が原文にない「確実に」を足していたのを見て書いたもので、「地味に」の含みを「目立たないながらも」のような言い方で表す例を含みます（references/gemini-syntax.md にも同じ言い換えの例があります）。この例2に「確実に」が出ないことは、その1文を例に合わせて書いた結果で、ほかの文章での効き目を示すものではありません。
スキルが推敲の中で残した記録では、2つの例とも、1回目の検査で意味が変わる恐れは0件でした。例1は、1回目の検査のあとに1か所を直して、もう一度検査しています（「組織の意思決定の土台となるガバナンス」を「組織が意思決定をするときのよりどころとなるガバナンス」にした直しで、lint の「土台」、文体の硬化の「の」が続く形、事実の穴の候補に当たった所です）。例2は、検査のあとに本文を直していません。提出前の verify は、2つとも --replay なしでした。
After の変化は、1.1.2 までの README の After より小さくなっています。原文だけでは意味を決められない箇所（例1の「片方」「もう片方」、例2の2行目と「この境界線」）は、説明を作り足さずに残し、書き手に確かめる点として報告しています。例1の2段落目の最後の比喩は「理解が一段深まります」と言い換えたうえで、何についての理解かを確かめる点に入れました。一方、例1の1段落目の「OS」は、確かめる点にせずに読みの1つを選んで言い換えています。原文の最後にあった結びは、例1では「！」ごと残り、例2では定型の結びが消えました。確かめに使った2つのモデルは、どちらの After にも確かな意味の変化を挙げませんでした。詳しくは例について確かめたことに書きました。
ここで重要なのは、単なるパーツの共通化ではなく、組織の意思決定OSとしてのガバナンスです。
従来の開発では、画面ごとに手触り感を探りながらパーツを作っていました。しかし、片方だけを見て画面を作ると、もう片方のアクセシビリティが静かに壊れます。そこでデザインシステムという強固な土台を置くことで、開発者の解像度が一段上がります。
デザインシステム導入のメリットは、主に次の3点です。
- 開発速度の加速: コンポーネントを再利用することで、時間を溶かさずに済みます。
- 仕様の収斂: 判断に迷うスタイルは、あらかじめ共通側に倒します。
- アクセシビリティの担保: ガイドラインが規律を要求するため、事故を未然に防ぐことができます。
もちろん、これは「デザイナーが不要になる」ことを意味しません。日々の開発に地味に効いてきます。ぜひ参考にしてみてください！
ここでは、単なるパーツの共通化ではなく、組織が意思決定をするときのよりどころとなるガバナンスが重要です。
従来の開発では、画面ごとに操作感を探りながらパーツを作っていました。しかし、片方だけを見て画面を作ると、もう片方のアクセシビリティが気づかないうちに損なわれます。そこでデザインシステムというしっかりした基盤を置くことで、開発者の理解が一段深まります。
デザインシステム導入のメリットは主に次の3点です。
- 開発が速くなる: コンポーネントを再利用することで、時間を無駄にせずに済みます。
- 仕様がそろう: 判断に迷うスタイルはあらかじめ共通側に合わせます。
- アクセシビリティが保たれる: ガイドラインが規律を要求するため、事故を未然に防ぐことができます。
もちろん、これは「デザイナーが不要になる」ことを意味しません。日々の開発では、目立たないながらも効果が表れてきます。ぜひ参考にしてみてください！
太字を9か所すべて外しました。1文目は、冒頭の「ここで」を「ここでは」にし、「重要なのは」を文末の「重要です」に移しています。「意思決定OS」は「組織が意思決定をするときのよりどころとなる」にしました。スキルは「OS」はたとえなので、言いたい中身を普通の言葉で書いたと報告しています。比喩は「静かに壊れます」を「気づかないうちに損なわれます」に、「強固な土台」を「しっかりした基盤」に、「解像度が一段上がります」を「理解が一段深まります」に直しました。「手触り感」は「操作感」に、「時間を溶かさずに」は「時間を無駄にせずに」に、「共通側に倒します」は「共通側に合わせます」に、「地味に効いてきます」は「目立たないながらも効果が表れてきます」にしています。「メリットは、主に」と「スタイルは、あらかじめ」の読点は外しました。箇条書きのラベルは太字を外して「開発が速くなる」のような短い述語にし、コロン、項目の数と順番は変えていません。結びの「ぜひ参考にしてみてください！」は「！」ごと残っています。
「単なるパーツの共通化ではなく」は、否定の向きを変えずに残しました。「事故を未然に防ぐことができます」と「ガイドラインが規律を要求するため」も原文のままです。「片方」「もう片方」が何を指すかと、「理解が一段深まります」が何についての理解かは、書き手に確かめる点として報告しました。「意思決定をするときのよりどころ」は「OS」の読みの1つを選んだ言い換えですが、確かめる点には入っていません。lint は箇条書きの比率と「ぜひ〜してみてください」の2件を warn として出し、残した否定対比の1件を info として出します（見直し候補は合わせて3件です）。
yomiyasu-check: executed via=verify run=20261016T022525Z-8c4511dd attempt=1 final=sha256:18f733e08658 mode=rewrite doc_type=article checks=lint,diff meaning_risk=0 replay=ok
非同期処理における最大の落とし穴は、ネットワークの瞬断です。
依存構造は分割できない。動かしながら引き返す。
単にメッセージを流すだけでは、背後でデータが静かに壊れます。前提を、経路が代わりに添えてくれるわけではありません。
そこで地味に効いてくるのが、以下の3つの原則です。
- 冪等性の担保: 重複した処理は黙ってスキップします。
- 安全なリトライ: 指数バックオフを挟むことで、DBの負荷を逃がします。
- DLQへの退避: 破綻したメッセージは隔離し、原因を1つずつ潰していきます。
デバッグで丸一日時間を溶かさないためにも、この境界線を意識した設計が不可欠です。いかがでしたでしょうか。
非同期処理における最大の落とし穴は、ネットワークの瞬断です。
依存構造は分割できない。動かしながら引き返す。
単にメッセージを流すだけでは、知らないうちにデータがおかしくなります。前提を経路が代わりに添えてくれるわけではありません。
そこで目立たないながらも役立ってくるのが、以下の3つの原則です。
- 冪等性の確保: 重複した処理は何も知らせずにスキップします。
- 安全なリトライ: 指数バックオフを挟むことで、DBにかかる負荷を和らげます。
- DLQへの退避: 破綻したメッセージは隔離し、原因を1つずつ取り除いていきます。
デバッグで丸一日を無駄にしないためにも、この境界線を意識した設計が不可欠です。
太字を10か所すべて外しました。2行目の「依存構造は分割できない。動かしながら引き返す。」は、太字を外しただけで、常体のまま残っています。スキルは「引き返す」が何をする動作かが読み取れず、見出しの行か本文の一文かで文体をそろえるかが変わるので、書き手に確かめる点にしたと報告しています。比喩は「背後でデータが静かに壊れます」を「知らないうちにデータがおかしくなります」に、「地味に効いてくる」を「目立たないながらも役立ってくる」に直しました。「黙ってスキップします」は「何も知らせずにスキップします」に、「DBの負荷を逃がします」は「DBにかかる負荷を和らげます」に、「潰していきます」は「取り除いていきます」に、「丸一日時間を溶かさない」は「丸一日を無駄にしない」にしています。結びの「いかがでしたでしょうか。」は消えています。スキルは、内容を持たない決まった締めの言葉として消したと報告しています。
箇条書きは、コロンと順番を残し、ラベルの太字を外しました。ラベルの語を替えたのは、「冪等性の担保」を「冪等性の確保」にした1か所です。「以下の3つ」はそのまま残っています。「前提を、経路が代わりに添えてくれる」は読点を外しただけで、スキルは「前提」が何を指すか決められないので残したと、残したAIっぽいところに書いています。「この境界線」が何を指すかは、書き手に確かめる点として報告しました。lint は2行目の「引き返す」の1件を、比喩動詞の候補として warn で出します。diff は、敬体の文の中に常体の2文があることと、箇条書きの「〜します」の3文を、文末の立場の見直し候補として出します（スキルはこの例を、立場を「勧め」として検査しました）。
yomiyasu-check: executed via=verify run=20261016T022525Z-94ffa1d2 attempt=1 final=sha256:d4cac88fb73d mode=rewrite doc_type=article checks=lint,diff meaning_risk=0 replay=ok
2つの After のどちらにも、主張の逆転はありません。例1の「単なるパーツの共通化ではなく」は否定のまま残り、目的の側に回っていません。原文と After は2つのモデル（Claude と Gemini 4 Argon）にも判定させました。モデルの判定は参考です。
例1は、2つのモデルとも意味を保ったとし、意味が変わった箇所を挙げませんでした。例2は、Gemini 4 Argon が意味を保ったとし、Claude は「少し変わった」として2か所を挙げました。「静かに壊れます」を「おかしくなります」とした箇所は、データ破損の深刻さが弱く読めるかもしれない、「DBの負荷を逃がします」を「負荷を和らげます」とした箇所は、負荷を避けることが軽くすることになり、効き目の捉え方が少しずれるかもしれない、という理由です。確かな意味の変化を挙げたモデルはなく、yomiyasu_check.py の diff も、2つとも意味が変わる恐れを0件としています。勢いについては、例1は結びの「！」が残ったことを2つのモデルとも挙げ、例2は話し言葉の弾みが落ちたものの、技術記事として適切な直しとしています。例2で結びを消したことも、2つのモデルとも適切としています。
1.1.2 までの README に載せていた After は、lint の見直し候補が0件でした。しかし、原文にない内容（例1の「高品質な行政サービス」、例2の「サーバーの再起動」）を足し、例1では否定していた「パーツの共通化」を目的の側に回していました。同じ After を このバージョンの diff に通すと、例1で意味が変わる恐れが3件（否定対比の主張の逆転、消えた数値「3点」、文の種類の印）、例2で1件（消えた数値「3つ」）出ます。「サーバー」「再起動」は「元の文にない語」に出ますが、意味が変わる恐れには出ません。lint の候補が0件でも、意味が保たれたとは限りません。
# 新規インストール
npx skills add nanaism/yomiyasu
# 最新版へのアップデート
npx skills update yomiyasuClaude Codeなどのエージェント設定ディレクトリへインストール・更新します。すでに導入済みの場合は npx skills update yomiyasu で最新版へ更新できます。スキル定義は skills/yomiyasu/SKILL.md の1か所に配置しています。
GitHub CLIの gh skill コマンドからインストールできます。
# 新規インストール
gh skill install nanaism/yomiyasu yomiyasu
# 最新版へのアップデート
gh skill update yomiyasu導入先のエージェントを指定する場合は、--agent codex や --agent claude-code を追加してください。
# 新規インストールとAGENTS.mdへの反映
npx openskills install nanaism/yomiyasu
npx openskills sync
# 最新版へのアップデートとAGENTS.mdへの反映
npx openskills update yomiyasu
npx openskills syncAGENTS.mdを経由して各エージェントから利用できるようになります。通常のルート指定で導入した環境はそのまま更新・同期できます。過去にネストされたパスを明示指定してインストールした環境では自動再配置が行われないため、元のインストール先やオプションに合わせて npx openskills install nanaism/yomiyasu を再実行してメタデータを更新したあと、更新や同期を行ってください。
/plugin marketplace add nanaism/yomiyasu
/plugin install yomiyasu@yomiyasu
プラグインマニフェストではスキルの配置先（"skills": "./skills/"）を明示的に指定しています。
プラグインで入れたスキルは、Claude Code では yomiyasu:yomiyasu（プラグイン名とスキル名）という名前になります。スキルを名前で呼ぶときは、スラッシュの補完に出るとおり yomiyasu:yomiyasu と書いてください。外部の利用者の報告では、素の yomiyasu と書くと「Unknown skill」になり、スキルを読み込まないまま文章を書いていました。npx skills add などでスキルとして入れたときは、素の yomiyasu という名前になるはずですが、確かめていません。確かめたのは、プラグイン（1.0.0）で入れた Claude Code のスキルの一覧に yomiyasu:yomiyasu と出ることだけです。2.0.0 をプラグインとして入れて動かすことと、yomiyasu:yomiyasu と書いて呼んだときに読み込まれること、ほかの入れ方での名前は確かめていません。
導入済みのプラグインを最新版へ更新する場合は、ターミナルで次のコマンドを実行します。
# マーケットプレイスの情報を更新
claude plugin marketplace update yomiyasu
# プラグインを最新版へ更新
claude plugin update yomiyasu@yomiyasu更新後はClaude Codeを再起動して反映してください。
Claudeのカスタムスキル登録機能（Web版など）には、登録専用のZIPを使ってください。GitHubの「Download ZIP」で取得したリポジトリ全体のZIPには、プラグイン設定や開発用ファイルも含まれ、登録できない場合があります。
2.0.0 のリリースに付ける登録専用のZIPには、ZIPの直下を起点とする35個のファイルだけを入れます。スキル本体（SKILL.md）、参照文書（references/ の28ファイル。文書の種類ごとの注意 doc-types/、書き手と読み手との関係の扱い persona.md、検査に使う語の一覧 lists/、検査の出力の見方 review-points.md、事実の確かめの手順 fact-recovery.md などを含む）、検査スクリプト4本（scripts/ の lint、diff、check と共有モジュール）、ライセンス2つです。このバージョンのZIPを Claude.ai に登録して動かすことは、まだ確かめていません。
- 専用ZIPのダウンロード
以下のリンクから、登録専用のZIPファイルをダウンロードします。
yomiyasu.zip（最新版ダウンロード） - そのままアップロード
ダウンロードしたyomiyasu.zipを解凍せず、Claudeのスキル登録画面にそのままアップロードしてください。
Codex は作業するリポジトリの .agents/skills/ の下に置いたスキルを読みます。上の入れ方を使わない場合や、Codex Cloud でリポジトリを開いて使う場合は、このリポジトリの skills/yomiyasu/ フォルダを、中身ごと使うリポジトリの .agents/skills/yomiyasu/ に写してください。
# 使うリポジトリの直下で実行
git clone --depth 1 https://github.com/nanaism/yomiyasu /tmp/yomiyasu
mkdir -p .agents/skills
cp -R /tmp/yomiyasu/skills/yomiyasu .agents/skills/yomiyasuこの置き方では、Codex がスキルを yomiyasu:yomiyasu という名前で一覧に載せます（フォルダの中にプラグインの設定 .claude-plugin があるためです）。名前で呼ぶときは $yomiyasu:yomiyasu と書くか、「/yomiyasu」とだけ送るか、依頼の文に「yomiyasu で」と書いてください。試した Codex では、$yomiyasu と書いた回はスキルの指示が読み込まれませんでした。
このバージョンで確かめたのは、macOS の codex-cli 0.162.1 で、作業場所の .agents/skills/yomiyasu/ に置いたスキルを読んで推敲したことだけです（確かめた範囲）。Codex Cloud、利用者のスキルの置き場所（~/.agents/skills/）に置く形、Windows では確かめていません。写したフォルダは自動では新しくならないので、更新するときは同じ手順で写し直してください。
他の日本語校正スキルと併用すると、指示が食い違う場合があります。出力が乱れる場合は、類似スキルを一時的に無効にして使用してください。
AIチャットやコーディングエージェントに対して、下書きを貼り付けて次のように指示します。
この文章を読みやすくして。
（ここに修正したい文章を貼り付け）
「/yomiyasu」とだけ送ったときは、直前の返答で書いた本文か、作業フォルダの直下に指示のファイル以外の .md か .txt が1つだけあればそれを推敲します。ファイルを選んで推敲したときは、最終稿を同じフォルダにまだない名前で保存し、原文のファイルは書き換えません（作業フォルダに原稿を1つ置いて Codex で試した8本では、1.1.2 は8本とも「文章を貼ってください」と返し、このバージョンは8本とも推敲しました）。
文書の種類と読者は、依頼の中で伝えられます。伝えなければ、スキルが行き先と本文の形から推定します。推定に自信がなく、答えによって直し方が変わり、問い返せる場面では、書き直す前に1回だけ確かめます。本文だけを返す指定、一回きりの実行、ほかのスキルの途中、「質問しないで」と頼まれたときは確かめず、種類を決めないまま、種類ごとの規則を当てずに直します。
この障害報告を、専門知識のない社外の利用者向けに読みやすくして。
（ここに修正したい文章を貼り付け）
種類ごとに、その種類で普通な書き方には当てない規則があります。値は付属ツールの --doc-type と同じです。
| 値 | 種類 | 当てない規則 |
|---|---|---|
| pr | PR説明 | 過剰な箇条書き（変更点、確認したこと） |
| article | 技術記事 | なし |
| incident | 障害報告 | 過剰な箇条書き（時系列）、硬い漢語（発生、復旧などの報告の語） |
| proposal | 提案書 | なし |
| minutes | 議事録 | 過剰な箇条書き（太字のラベルを含む）、同じ文末の連続（〜しました。の連続）、伝聞の「〜とのこと」 |
| manual | マニュアル | 過剰な箇条書き（番号つきの手順） |
| slides | スライド | 過剰な箇条書き（太字のラベルを含む）、数の宣言、繰り返すだけの「まとめ」、体言止めの項目での主語の抜けと文末 |
| essay | エッセイ・小説 | 読み取れる比喩（エッセイでも「効く」の類は直す）、小説のコピー調とダッシュ |
| formal | 公用文、規程、契約書、仕様書 | 硬い漢語（正式な語）、「〜を行う」「〜することができる」の外枠 |
| promo | 紹介記事・宣伝文 | 見出しのキャッチコピー、「！」と絵文字、勢いのある語と強める語 |
| メール・チャット | 宛名、挨拶、結び、署名、クッション言葉の削り、敬語の度合いと口語の書き換え、絵文字の削除 | |
| paper | 論文・研究レポート | ぼかした語の具体化（慎重な言い方）、専門用語と論文調（本研究では）の言い換え、長い文の分割、名詞化の言い換え |
エッセイ・小説では、何を何に例えたかが読み取れる比喩を書き手の個性として残し、主語と述語が成り立たず連想もできない比喩を直します。紹介記事・宣伝文では、「！」（同じ段落に3つ以上あっても）、評価の語を短く重ねる型（安い。うまい。早い。）、同じ褒め言葉の繰り返しを残し、根拠のない誇張は書き換えずに書き手へ根拠を尋ねます。どちらも、書き手の表現を残したときは、そう判断したことを本文とは別に1行で伝えます。
メール・チャットで残すのは、宛名、挨拶、結び、署名、クッション言葉、敬語の度合い、チャットの口語で、直すのは敬語の誤りなどです。論文・研究レポートでは、慎重な言い方を断定に変えず、引用の印、数値、専門用語、「である」調を残します。
読者は3段階です。expert（同じ分野の専門家）には用語を残して説明を足しません。informed（分野は違うが技術に詳しい人）と general（専門知識のない人）では、原文と資料にある説明で言い換えるか添えます。説明が原文と資料にないときは、説明を作らずに語を残し、「ここに説明が必要です」と書き手に返します。見出しと節の数と順は、どの種類と読者でも変えません。
種類を決めないときは、種類ごとの規則を当てず、1.1.2 からある分野別の指針（技術記事 tech、業務文書 business、エッセイ essay）を使います。
書き手の立場と、読み手との関係（上司、同じチーム、取引先、お客さまなど）は、依頼の中で伝えられます。
draft.md を yomiyasu で読みやすくしてください。取引先の購買の担当者に送るメールです。
関係を伝えたときだけ、本文を次のように直します。
- 上司と社外の読み手には、読み手への依頼と読み手の行為を尊敬語に、社外の読み手に向かう書き手の行為を謙譲語に上げます。同じ動詞に「お・ご」を付けた形のほか、その関係で人がふつう書く言い回しも使います（来てください → お越しください、変更があれば言ってください → 変更があればお知らせください）。説明や手順を頼む「教えてください」は、「ご教示ください」か「教えていただけますか」にします。頼む中身、期限、選択肢、頼みの数は変えません。二重敬語と、原文にない「させていただく」は作りません。
- 読み手が社外の特定の相手なら、読み手に向けた言い回しとお詫びの文も、その関係で人がふつう書く形にします（申し訳ありません → 申し訳ございません、もっと → これまで以上に、気をつけます → 努めます）。作業を述べる文（直しました）は丁寧語のままです。
- 書き手が自分でした行為で、主語がなくほかの人の行為と読み違えうる文には、原文にある書き手の一人称（私、弊社など）を主語に補います（3か所まで）。原文に一人称がなければ補いません。
- 書き手の立場で知りえない事情、立場に合わない断定、関係に合わない言い方（お客さま宛ての「僕」など）は、本文を変えずに「書き手に確かめたい点」で知らせます（2点まで）。
- 担当者、説明、挨拶、お詫びは足しません。エッセイと紹介記事・宣伝文では、書き手と読み手を伝えても本文を変えません。敬語を下げるのは、頼まれたときだけです。
伝えないときは、宛名や署名から読み手を推定しても、本文も知らせも変えず、推定した読み手を、変えなかった理由として返答に書くこともしません。確認の記録に、推定した値を1行だけ書きます。
推敲する原稿に、中身や値の書かれていない所があると、スキルは同じことを述べた根拠の文をこの会話と資料から探し、根拠があるときだけ補います。
- 根拠にするのは、原文、依頼、資料、この会話の利用者の発言、この会話で開いたファイル、コマンドの出力（テストの結果、ログ、
git diffなど）です。AI 自身やほかの AI の発言、会話のまとめ、一般の知識、ウェブの内容は使いません。 - 値が合うだけでは補いません。補う値が何の値か（対象、条件、時点）まで根拠の文に書かれているときだけです。「予定」「かもしれない」のような確度は、そのまま書きます。
- 補う・直すは合わせて5件までで、今の文の中で補い、新しい文や段落は作りません。説明、例、効果、原因、気持ちは、材料にあっても足しません。要約や短くする依頼では補いません。
- 原稿の値が利用者の渡した資料と食い違い、資料の値が1つに決まるときは、資料に合わせて直します。会話やファイルの値で直すのは、AI が自分で書いた値で、原稿の値に出典がなく、材料の値が1つに決まるときだけです。
- 読みに行くファイルは原稿か会話に名前の出たものを3つまでで、読むだけです。
.envや秘密鍵のような認証情報らしいファイルは開きません。変更の説明の原稿で、会話に差分がないときだけ、読むだけのgit diffかgit log -p -1を1回動かします。 - 原文が省いたと示している所（詳細は省きます、別途お知らせします）、ぼかした数や時期（一部の利用者、近日中に）、「未定」「調査中」は、補わず、問いもしません（ぼかした語のせいで読み手が誤って読む恐れのあるときだけ、1回問います）。社外向けか分からない文書には、出典があっても、内部のホスト名、メールアドレス、個人の名前、未公開の数値などを入れません。
- 「昨日」「先週」のような相対の日付には、書いた日が確かに分かるときだけ、括弧で日付を添えます（昨日（3月4日））。書いた日が分かるのは、原稿に書いた日の行があるときと、依頼や会話から原稿を今日書いたと分かるときです。今日の日付はホストが知らせる日付を使います。推測では添えず、曜日も足しません。エッセイ・小説と紹介記事・宣伝文では添えません。
- エッセイ・小説、紹介記事・宣伝文、公用文・規程・契約書・仕様書、論文・研究レポートでは、会話やファイルから補いません。本文だけを返す指定、「確かめずに」と頼まれたとき、Python を実行できないときも補いません。
- 根拠がなければ本文を変えず、読み手が動けない所だけを問いにします。問いは3つまでで、元の書き手（人か別の AI）にそのまま貼って渡せる形にし、候補の値は挙げません。答えが来たら、最初の原稿と、前の問いと答えをまとめて渡してください。前の往復を覚えていない呼ばれ方（子エージェントなど）では、そうして渡したときにだけ続きを進められます。
- 補いに使った根拠の文は最終稿と同じフォルダに「最終稿の名前.material.txt」として一字も変えずに写し、
yomiyasu_check.py runに--materialで渡します（資料の出典と事実の穴の候補）。
書き直した本文のあとには「変えたところ」（5点まで）、「残したAIっぽいところ」、「書き手に確かめたい点」（2点まで）、「事実の確かめ」、「確認の記録」が付きます。「事実の確かめ」は材料から補った事実、直した事実、材料と照らした値、確かめられなかった点のどれかがあるときだけ付く節で、補った語句ごとに出典の場所と根拠の文を書き、最後に「元の書き手に渡す問い」をまとめます。確認の記録は実行した検査と、実行しなかった検査とその理由を分けて書き、run の出力の「見直し候補: 原文 N件 → 最終稿 M件」の件数を「（件数は点数ではなく、増減は読みやすさの良し悪しを示さない）」と添えて写し、最後に yomiyasu_check.py の状態の行（yomiyasu-check: で始まる行）を写したものです。Python を実行できない環境では、スキルは検査の代わりに原文と最終稿を読み比べ、状態の行を yomiyasu-check: not_run reason=no_python のように書きます。本文だけを返すよう頼んだときは、確認の記録も説明の欄も、区切りの線のあとの注記も付けません（検査は同じように行います）。
推敲だけでなく、AIに文章を書かせる前にyomiyasuを読ませる使い方もあります。ai-garageの検証記事（2026年10月11日、v1.1.1で検証）では、Claude Opus 5.5に8種類のメモから文章を書かせ、書かせ方を4通り比べています。先にyomiyasuを読ませた文章は、メモにない内容を書き足したと指摘された回数が2回で、何も付けずに書かせた場合の60回から大きく減りました。
一方で、文章は平均356字と、依頼した500字程度より短くなりました。読みやすさの評価は4通りの中で最も低く、時間と費用も約4倍かかっています。採点はAIによるもので、文章の種類ごとの本数も少ない、1つの試験の結果です。記事では、この使い方は数字や日付、条件を正確に伝えたい文章（営業メール、障害報告書、手順書など）に向くとしています。エッセイや告知のような読み物には、何も付けずに書かせるか、依頼に一言添えるほうが向くという結論です。エッセイでは、先にyomiyasuを読ませた文章が8回の採点すべてで最下位でした。
このバージョンのスキルに資料から新しく書かせると、スキルは yomiyasu_check.py run に資料を --material で渡し、最終稿の数値、名前、語、確度の語を資料と照らします。資料にない数値や名前は候補に出ます（新規作成のモード）。
文章の表現と書式を見る yomiyasu_lint.py、推敲の前後を比べる yomiyasu_diff.py、2つをまとめて実行して記録を残す yomiyasu_check.py の3つのスクリプトと、共有モジュール markdown_visibility.py、設定に貼ったときだけ動く任意のフック yomiyasu_hook.py を同梱しています。外部ライブラリは要らず、Python の標準ライブラリだけで動きます。Python 3.8 以上の文法で書いており、自動の試験は macOS の Python 3.9.6 と 3.14.5 で動かしています（3.8 と Windows の実機では確かめていません）。python3 がない環境では python か py -3 で実行してください。
3つのスクリプトが出すのは、見直し候補と変わった箇所です。意味が保たれたかと、読み手にとって分かりやすいかは判定しません。候補が0件でも、意味が同じだという証明にはなりません。本ツールは特定の構文を対象とする簡易な検査であり、完全なMarkdownレンダラーでもありません。候補をなくすことを目的に機械的に直すのではなく、元の文や文脈と照らし合わせて判断してください。
推敲の前と後を比べるときは、lint の点数ではなく yomiyasu_check.py run の出力の頭を見てください。記録の行と「硬化の検査:」などの行のあとに、lint の見直し候補の件数を原文と最終稿で並べた行が出て、そのすぐ下に直した箇所の元と後が並びます。
検査を実行しました（1回目）。下の候補を原文と資料に照らして確かめてください。直すのは1回までです。直したら同じコマンドをもう一度実行し、直さないなら提出の直前に、本文を変えずに verify を1回実行してください。
yomiyasu-check: executed via=run run=20261015T171818Z-53bc8dc2 attempt=1 final=sha256:1154038bb6b0 mode=rewrite checks=lint,diff meaning_risk=0
実行した検査: lint（最終稿）候補0件、diff（原文→最終稿）変更あり 候補2件（うち意味が変わる恐れ0件）
この記録は検査を実行したことを示すだけで、意味が保たれたことや読みやすさの合格を示すものではありません。
記録: …/.yomiyasu/runs/20261015T171818Z-53bc8dc2/attempt-1.json
硬化の検査: 候補なし
勢いの検査: 候補なし
慎重表現の検査: 候補なし
値の検査: 候補なし
見直し候補: 原文 0件 → 最終稿 0件（lint の規則に当たった数で、点数ではありません。増えても減っても読みやすさの良し悪しは示しません）
■ 直した箇所（2か所。元と後）
@ 元3行目 → 後3行目（本文）
元: 週次の集計バッチを、来月から新しいジョブ基盤に移行します。移行によって、これまで手作業だった再実行の手順が不要になり、運…
後: 週次の集計バッチを、来月から新しいジョブ基盤に移します。移したあとは、これまで手作業だった再実行の手順がいらなくなり、運…
@ 元5行目 → 後5行目（本文）
元: **移行の日程**：未定です。
後: 移行の日程はまだ決まっていません。
- 長い所は、変わり始めの少し前からおよそ60字だけを出しています（「…」は省いた所）。省いていない元と後は下の「■ 全文差分」と、記録と同じフォルダの attempt-1.diff.txt にあります。
■ 差分の見直し候補（diff、2件）
■ 言い回しの種類の増減（意味が変わりやすいところ）
- つなぎ: 1 → 0（元: によって／後: なし）
■ 消えた語: 不要、未定、負荷
（このあとに全文差分と、1行目と状態の行がもう一度出ます）
この例では、lint の件数は前後とも0件で、1.1.2 の lint でも前後とも100点です。それでも、元と後を並べると2か所を書き直したことが分かります。1か所目は60字で切れているので、2文目で「負荷が大きく下がる」を「作業が減る」に変えたことは、全文差分か、差分の見直し候補の「消えた語: 負荷」で確かめます。
- 「見直し候補」の件数は、lint の規則に当たった数です。読みやすさの点数ではありません。増えても減っても、読みやすくなったかどうかは示しません。同梱のコーパスの推敲48組（古いバージョンの yomiyasu の指示で作った出力）では、件数が減った組が7組、同じ組が36組、増えた組が5組でした。確かめるときは、直した箇所の元と後を読んでください。
- 原文の件数は、最終稿と同じ
--doc-typeと--readerで原文に lint をかけて数えます。この lint は必要な検査と記録に入れず、--fail-onにも数えません。時間切れなどで数えられなかったときは「原文 数えられず（時間切れ）」と出し、状態は変えません。新規作成では最終稿の件数だけを出し、資料を原文とみなしたときは「資料1（原文とみなした資料） N件 → 最終稿 M件」の形になります。 - 「■ 直した箇所」は、全文差分と同じ組を、文書の初めから10か所まで並べます。長い所は変わり始めの少し前から60字ほどで切るので、1つの段落の中で2つ目の文からあとの変化は見えないことがあります。省いた所と切った所は、下の「■ 全文差分」（記録を残したときは、記録と同じフォルダの
attempt-<n>.diff.txtにも）で省かずに見られます。短い文書では、同じ元と後が「■ 直した箇所」と「■ 全文差分」に2回出ます。 - 全文差分は空行を手がかりに行を組むので、見出しを足すなどで段落の数が変わると、元と後に別の段落が並ぶことがあります。元と後で行の数が違う組があれば、案内の1行にそのことを書きます。そのときは全文差分で前後の組も読んで、どの段落がどこへ移ったかを確かめてください。
- 1.1.2 までの lint が出していた点数をやめた理由は 点数が出なくなった理由 の節に、JSON に残した
rule_penalty_scoreの計算と読み方は rule_penalty_score の式 の節に書いています。合否やしきい値には使わず、CI で止めるときは--fail-onで候補の中身を見てください。 - verify は、記録と合ったときに4行目に「記録の中身: 見直し候補 最終稿 M件、直した箇所 Kか所（原文の件数と元と後は run の出力にあります）」を出します。原文の件数は記録にないので、verify では出しません。
- スキルは完了報告の確認の記録の「見直し候補」の行に、最後の run のこの行の件数を「（件数は点数ではなく、増減は読みやすさの良し悪しを示さない）」と添えて写します。新規作成では最終稿の件数だけです。件数の増減を、読みやすくなった根拠としては書きません。
--jsonでは、run にcandidate_counts（原文と最終稿の件数）とchanged_places（直した箇所の数、出した数、省いた数、切ったかどうか）、verify にfinal_candidate_countとchanged_place_countが付きます。元と後の正確な中身は、今までどおりdiff.full_diff.hunksにあります。
1つの文章について、AIの文章に多い表現（不自然な比喩動詞、決まり文句、過剰な太字・箇条書き、絵文字、文末コロン、同一文末の連続など）と、日本語の括弧や句読点に隣接して表示先の規則により太字として表示されない可能性がある書き方（bold_not_rendered）を検査します。複数行にまたがる太字やブロック境界（引用、見出し、リスト、表）も考慮して判定します。
2.0.0 からは、通常の出力に点数を出しません。出力の1〜3行目は次の3行で、そのあとに見直し候補を行の順に、規則の ID を付けて並べます。
表現・書式の検査を実行しました。
見直し候補: 3件
この検査では、意味の保持と読者にとっての分かりやすさは判定していません。
内訳: error 0件、warn 3件、info 0件
L3 [WARN] metaphor_verb: 比喩動詞「壊れる」が検出されました。…
点数は JSON の rule_penalty_score にだけ残しています。規則に当たった箇所が地の文の量に比べてどれだけ多いかを表した目安で、候補がなければ100、あれば1から99です。文章の品質や読みやすさの点数ではないので、合否には使わないでください。推敲の前後を比べるときは、前後を比べるときは、点数ではなく check を使う の節を見てください。
1.1.2 の lint は、出力の見出しに「スコア: 90/100」のような点数を出していました。2.0.0 では、この点数を通常の出力から外しました。機能を減らしたのではありません。1.1.2 の規則はすべて残り、instruction_residue や pause_comma などの規則も足しました。候補は前と同じように1件ずつ出ます（2.0.0 からは行の順に並べ、規則の ID も付けています）。点数は今も --json の rule_penalty_score で取れます。通常の出力から外した参考値の3行（文字数、太字の頻度、箇条書きの比率）も、JSON の metrics にあります。
点数を外したのは、一つの数字が読みやすさの合格点のように見えてしまうからです。点数は決まった規則に当たった箇所を数えただけで、意味が保たれたかも、読み手に伝わるかも見ていません。それでも、95点が100点に上がると文章が良くなったように見えます。逆に、直す前と後で同じ点数だと、読みやすくなったかどうかが分からなくなります（同梱のコーパスでは、4段落を書き直した組が、1.1.2 の点数で前後とも90点でした）。点数が見えていると、点数を上げるための直しも起きやすいと考えました。
推敲の前と後を比べるときは、yomiyasu_check.py run の出力の「見直し候補: 原文 N件 → 最終稿 M件」の行と「■ 直した箇所」を見て、直した箇所の元と後を読んでください（check で前後を比べる節）。件数が減ったことは、読みやすくなった証拠にはなりません。道具で点数を使うときの読み方は、下の「rule_penalty_score の式」の節に書いています。
2.0.0 で、点数を地の文の長さで割る式に変えました。1.1.2 の score は件数をそのまま100から引いていたので、同じ文章を2回つなげただけで点数が下がり、長い文書はすぐ0になりました。
候補が0件なら100です。候補があれば、地の文1,000字あたりの重みつきの件数 x を求め、100 × 40 ÷ (40 + x) を四捨五入します。候補があるときは1から99の間に収めるので、0にはなりません。
x の数え方は次のとおりです。地の文は、コードの囲み、表、引用、見出し、前置きの設定（frontmatter）、HTML、URL の字を除き、空白も除いた字数です。地の文が1,000字に満たない文書は、1,000字として割ります。行ごとの候補は、error を3、warn を2、info を1として足し、地の文1,000字あたりに直します。ダッシュの3つの規則（dash_decoration、dash_insertion、dash_list_ending）は、候補を1文書3件までしか出しませんが、点数には当たった行をすべて数えます（1行に何か所あっても1件です）。文書全体で1件だけ出る規則は字数で割らず、1,000字の文書で1件当たったのと同じだけ x に足します（excess_bold と excess_list は2、bold_label_list は1）。negative_parallelism_density は、同じ箇所を negative_parallelism の候補で数えているので足しません。
地の文が1,000字以下の文書に候補が1件だけなら、warn で95点、info で98点、error で93点です。x が40（1,000字あたり warn が20件）なら50点です。1件で下がる幅は一定ではありません。候補が多いほど1件の幅は小さくなり、長い文書では1件増えても点数が変わらないことがあります（地の文6万字の文書では、error、warn、info のどれが1件でも99点です）。
地の文が1,000字以上の文書は、同じ文章を何回つなげても、点数はほとんど変わりません（tests/corpus の163本を1・2・4・8回つなぎ、地の文が1,000字以上になった回どうしで比べると、種類なしと12の種類のどれでも差は2点以内でした）。地の文が1,000字に満たない文書は1,000字として割るので、短い文書どうしでは点数は候補の件数だけで決まり、長いほうが低く出やすくなります。同じ短い文書をくり返すと、地の文が1,000字を越えるまでは点数が下がります（tests/corpus の human_oga_01.md は181字で95点、4回つないだ724字で83点、8回つないだ1,448字からは何回つないでも78点です）。
字数で当てるかを決める規則もあります。excess_bold と excess_list は地の文が300字を超える文書だけ、short_summary_heading は2,000字未満の文書だけに出ます。字数が変わると候補そのものが増えたり減ったりするので、点数も動きます（「## まとめ」の見出しが4つある1,044字の文書は91点で、2回つなぐと見出しの候補が出なくなり100点です）。また、候補の密度は文書全体で見るので、長い文書の一部に候補が固まっていても点数にはあまり出ません（warn が20件ある340字の段落は、それだけなら50点、地の文6万字の文書の中に置くと98点です）。どこに何が当たったかは findings で見てください。規則ごとの重みは付けていません。人が書いた文の数が、規則ごとの出やすさを決めるには足りないためです。
--doc-type を付けると、その種類で外す規則と、種類を指定したときだけ当てる規則（pause_comma）で候補が変わるので、同じ文書でも点数が変わります。種類を変えた結果どうしは比べないでください。版をまたいでも比べないでください。1.1.2 の score とは計算が違い、同じ文書でも値が違います。規則を足した版でも値は変わります。yomiyasu_check.py run --json の lint.rule_penalty_score も同じ値です。JSON の値だけからは点数を計算し直せません。地の文の字数は JSON に出しておらず（metrics.char_count は見出しも数えた字数です）、ダッシュの行が4行以上ある文書では findings にない行も数えているためです。
CI や道具で使うときは、点数のしきい値で止めず、--fail-on の終了コードか、JSON の counts（error、warn、info ごとの件数）と candidate_count（全部の件数）を使ってください。rule_penalty_score は、長さの違う文書の候補の多さを大まかに並べたいときの目安です。
# Markdownファイルを検査
python3 scripts/yomiyasu_lint.py article.md
# warn か error の候補があれば終了コード1を返す（CIやGitフック用。--strict と同じ）
python3 scripts/yomiyasu_lint.py article.md --fail-on warn
# 文書の種類と読者を指定
python3 scripts/yomiyasu_lint.py slides.md --doc-type slides --reader general
# JSON形式（形式2）で結果を出力
python3 scripts/yomiyasu_lint.py article.md --json--strictか--fail-onを付けなければ、候補があっても終了コードは0です。CI で使うときは、点数のしきい値で止めず、候補の中身で止めてください（--fail-on warn、太字が表示されない書き方だけなら--fail-on error）。止めずに警告として表示するだけの使い方も勧めます。- 終了コードは、0が検査を最後まで実行して条件に当たらなかったとき、1が
--strictか--fail-onに当たったとき、2が使い方か入力の誤り、3が内部の誤りか、出力先が閉じられて結果を最後まで書けなかったときです。 --doc-typeを付けると、その種類で普通な書き方を拾う規則の候補を外し、外した件数を出します（外した候補の中身は、付けずに実行すると見られます）。--readerは表示と JSON に残すだけで、候補は変えません。- 行頭から書いた
<details>と</details>の組の中にある箇条書きは、箇条書きの比率（excess_list）に数えません。根拠を<details>に畳んだ文書で、過剰な箇条書きの候補が出ないようにするためです。中の箇条書きの行の数は、JSON のmetricsのdetails_list_linesに出ます。 - JSON の
scoreとis_cleanは、rule_penalty_scoreとno_rule_findingsに名前を変えました。rule_penalty_scoreは計算も変えたので、1.1.2 のscoreに使っていたしきい値はそのまま使えません（rule_penalty_score の式）。形式はdata.get("format_version", 1)で見分けられます（CHANGELOG の「互換性のない変更」）。
このリンターは、推敲で見落としやすい表現を拾うための補助です。文章をAIが書いたかどうかを判定する道具ではありません。同梱の評価用コーパス（tests/corpus/）には、モデルに人の文章らしく書かせた例文が8本あり（tests/corpus/human/human_doc_*.md。フォルダの名前は human ですが、人が書いた文ではありません）、8本とも見直し候補は0件でした。候補が少ないことは、人が書いた証拠にはなりません。コーパスの中で人が書いた文章は、作者の記事1本を見出しで8つに分けた抜粋（human_oga_*.md）だけです。量が少ないので、人の文章とAIの文章をどれだけ見分けられるかの数値は載せていません。1.1.2 の README に載せた human の16本の数値の訂正は、CHANGELOG の「訂正」に書いています。
推敲前と推敲後を比べ、変わった箇所をすべて出します（全文差分）。あわせて、意味が変わる恐れのある変化と、語の増減、文末の種類や立場（勧め／決まり／説明）の変化、太字の表示などの見直し候補を出します。
# 原文と推敲後の差分を検査（文書の立場を指定。--stance 説明 とも書けます）
python3 scripts/yomiyasu_diff.py 元の文.md 書き直した文.md --stance=説明
# 数値・否定・入れ替え・文の種類の変化があれば終了コード1を返す
python3 scripts/yomiyasu_diff.py 元の文.md 書き直した文.md --fail-on=meaning-risk
# 文末の種類（敬体・常体・立場）の分布のみを確認
python3 scripts/yomiyasu_diff.py --endings 対象文.md出力の例です（「田中が佐藤を承認した。設定は3日ごとに保存します。」を「佐藤が田中を承認した。設定は30日ごとに保存しません。」にした場合）。
差分の検査を実行しました。
状態: 変更あり（2か所）。見直し候補 3件、うち意味が変わる恐れ 3件
全文差分は変わった箇所を示すだけで、意味が同じだという証明ではありません。この検査では、意味の保持と読者にとっての分かりやすさは判定していません。
■ 意味が変わる恐れ（3件。原文と資料に照らして確かめる）
- 「が」「を」などが入れ替わった（1行目）: 田中 が→を、佐藤 を→が
元: 田中が佐藤を承認した。
後: 佐藤が田中を承認した。
- 数値が変わった（3行目）: 3日 → 30日
元: 設定は3日ごとに保存します。
後: 設定は30日ごとに保存しません。
- 否定の有無が変わった（3行目）: 保存します → 保存しません
元: 設定は3日ごとに保存します。
後: 設定は30日ごとに保存しません。
■ 全文差分（変更 2か所。省略していません）
@ 元1行目 → 後1行目（本文）
元: 田中が佐藤を承認した。
後: 佐藤が田中を承認した。
@ 元3行目 → 後3行目（本文）
元: 設定は3日ごとに保存します。
後: 設定は30日ごとに保存しません。
差: 設定は3{+0+}日ごとに保存しま[-す-]{+せん+}。
状態: 変更あり（2か所）。見直し候補 3件、うち意味が変わる恐れ 3件
- 状態は「変更なし」「変更はあるが、専用の規則に当たる見直し候補はない」「変更あり」の3つです。全文差分の
[-…-]は消えた文字、{+…+}は足した文字です。 - 意味が変わる恐れとして出すのは、数値、否定、主語と目的語の入れ替え（「が」「を」など）、問いと平叙、文の種類の印（伝聞、推量、意見、例え、依頼や決まり）、コード・URL・引用など変えない箇所の変化、引用の印（
[1]、(山田 2020)の形）の変化、否定対比の主張の逆転（「Aではなく」で否定していた A が、推敲後に目的や優先の側に出た）、元にない気持ちの語、確度の変化、かぎかっこの中の言葉の変化、原文の状態の語（未定、未確認、調査中など）が消えた書き換え、原文にない約束・保証・再発防止の誓い・因果の足しです。 --fail-on=meaning-riskで終了コード1になるのは、このうち数値、否定、主語と目的語の入れ替え、文の種類（問いと平叙、文の種類の印）、引用の印の変化、確度を強めた書き換え（かもしれない → 見込み、見込み → 予定、と思われる → 断定など）、原文の状態の語が消えた書き換え（未確認です → 別途確認させていただきます）、原文にない書き手の約束・保証・再発防止の誓いの足しです。コード・URL・引用などの変化、否定対比の主張の逆転、元にない気持ちの語、確度を弱めた書き換え、数えない語だけの確度の変化、予定の言い切り（する予定です → します）、かぎかっこの中の言葉の変化、原文にない因果の足し、書き手の行為と読む印（いたします、今後・改めて、弊社などの主語）のない「〜します」の足し（説明や手順の文かもしれないもの）は、意味が変わる恐れとして出しますが数えません。推量の印が同じ強さの慎重な言い方に替わっただけの文（かもしれません → 恐れがあります、と思われます → 見込みです。同じ節の同じ事柄についての言い換えに限ります）は、意味が変わる恐れの候補に出さず、数えません。「■ 文の種類の印が変わった文」には引き続き出します。付けなければ、候補があっても終了コードは0です。付けたときは、種類を付けなくても、引用の印、統計の値の比較の記号、同じ値の符号が変わった文書で、終了コードが0から1に変わることがあります。依頼や資料に書いてある約束を本文に足したときも、diff は依頼と資料を見られないので、約束の足しとして数えます（check の資料との照合は、数値だけを資料にある値として扱います）。- 推敲で文体が硬くなった箇所（漢字の割合、文の長さ、名詞化の言い回し、漢語の「の」の連続が増えた）と、勢いが落ちた箇所（「！」「？」、絵文字、強める語が減った、見出しが短くなった）は、「■ 文体の硬化」「■ 勢い」の節に見直し候補として出します。この2つは件数と
--fail-onに入れません。文書の種類によっては参考としてだけ出します（硬化は incident、formal、paper、勢いは pr、article、incident、manual、formal、paper）。検査に使う語の一覧はreferences/lists/にあり、足し引きできます。 - 慎重な言い方（と考えられる、可能性がある、示唆する など）が減った文は「■ 慎重な言い方」に、宛名（〇〇様、〇〇さん）とリンクでないメールアドレスの変化は「■ 動かしてはいけない値」に出します。
--doc-type mailのときは、敬語の数と「です・ます」の割合が大きく動いた文書を「■ 敬語の度合い」に出します。常体と敬体の切り替えが3文以上かつ原文のその文体の5割以上なら「■ 文体の切り替え」に出します。原文の多い文体にそろえた場合と、主な文体を変えた場合を分けて示します。この4つは見直し候補で、件数と--fail-onに入れません。同じ文で推量の印が消えたときや確度の強まりの候補が出たときは、慎重な言い方には重ねて出しません。 - 推敲の前後で文を1文ずつ対応させて、文の種類の印が消えたり増えたりした文も示します。文の対応は字面の重なりでたどるため、大きく言い換えた文や順番を大きく入れ替えた文では、変化を取りこぼしたり、対応しない文どうしを比べた候補が出たりすることがあります。候補に出なかった文も、元の文と読み比べてください。
- 終了コードは、0が比べ終わって
--fail-onに当たらなかったとき、1が--fail-on=meaning-riskに当たったとき、2が使い方か入力の誤り、3が内部の誤りです。
最終稿に lint を、原文と最終稿に diff をまとめて実行し、記録を残します。スキルは、書き直しのあとに run を、提出の直前に verify を実行します。
# 推敲: 原文と最終稿を渡す（資料があれば --material 資料 を足す）
python3 scripts/yomiyasu_check.py run --source 原文.md --final 最終稿.md --doc-type article
# 新規作成: 資料と最終稿を渡す（資料との照合と lint）
python3 scripts/yomiyasu_check.py run --material メモ.md --final 最終稿.md
# 推敲で補った値の根拠（抜き書き）を渡し、事実の穴の候補も出す
python3 scripts/yomiyasu_check.py run --source 原文.md --final 最終稿.md --material 最終稿.material.txt --fact-gaps
# 提出の直前に、最終稿が検査したものと同じかを記録と照らす
python3 scripts/yomiyasu_check.py verify --final 最終稿.mdrun の出力では、記録の行と「硬化の検査:」などの行のあとに、見直し候補の件数（原文 → 最終稿）と直した箇所の元と後が出ます（前後を比べるときは、点数ではなく check を使う の節）。
出力の2行目は、次のような状態の行です。完了報告の確認の記録には、この行を写します。
yomiyasu-check: executed via=verify run=20261014T124830Z-6b5d53f8 attempt=1 final=sha256:6aa6ecba24a9 mode=rewrite doc_type=article checks=lint,diff meaning_risk=0 replay=ok
- 返す状態は「検査を実行した」（
executed）で、合格ではありません。run は、検査の一部を実行できなければpartial、使い方の誤りならnot_runを返します。verify は、記録がない（no_record）、検査のあとに最終稿を書き換えた（final_changed）、記録のあとに検査スクリプトや語の一覧が変わった（tool_changed）ときなどに、完了と扱いません。diff を実行していない記録と、別の原稿の記録も、完了と扱いません。書き直す前の文章を資料として渡しても、資料が最終稿とよく似ていれば、run はそれを原文とみなして diff も実行します。 - 記録は、git の最上位（なければ作業ディレクトリ）の
.yomiyasu/に置きます。自分を無視する.gitignoreを作るので、git には出ません。先にできていた.yomiyasu/でも、.gitignoreとstate.jsonがどちらもなければ作ります。場所は--state-dirか環境変数YOMIYASU_STATE_DIRで変えられます。こうして指定したフォルダがすでにあるときは.gitignoreを足さないので、git に入れたくなければ利用者が無視の設定をしてください。記録には原稿の写しが入りますが、外へは送りません。要らなくなれば消してかまいません。 - 記録は実行漏れを見つけるためのもので、改ざんの防止や人の承認の証明にはなりません。同じ権限で原稿と記録の両方を書き換えられる環境では、記録を作り込むこともできます。
verify --replayは記録の写しで lint と diff を動かし直し、結果が記録と同じかを確かめますが、写しと結果を同じように作り込んだ記録は見分けられません。 - 環境変数:
YOMIYASU_STATE_DIRは、--state-dirを省いたときの状態フォルダです（空白だけの値と、展開されずに${が残った値は使いません）。YOMIYASU_SESSIONは、runとstartで--sessionを省いたときのセッションの識別子です（run では記録に入れるだけで、start では登録をそのセッションに結び付けます）。Codex が渡すCODEX_THREAD_IDがあれば、run は記録のhost.codex_thread_idに入れます。記録に入れる値は、空の値と${が残った値を null にします。 --jsonの結果では、出力の「硬化の検査:」「勢いの検査:」「慎重表現の検査:」「値の検査:」「敬語の検査:」の行と同じ文字列が、stiffness_check、tone_check、hedges_check、immutable_check、politeness_checkに入ります（diff を実行しなかったときと、mail でないときのpoliteness_checkは null）。候補があるときだけ出る「文体の検査:」の行には文字列のキーがなく、結果はdiff.registerにあります。- ファイルを作らない対話では、
run --stdinで原文と最終稿を標準入力から渡します。行全体が<<<yomiyasu:original>>>、<<<yomiyasu:material>>>、<<<yomiyasu:final>>>の行で区切ります。資料の区切りには、<<<yomiyasu:material 出典>>>の形で出典を書けます（資料の出典と事実の穴の候補）。この使い方にはシェルが要ります。ファイルを作らない対話や本文だけを返すときも、スキルは返す直前に最終稿だけをverify --final -に渡して照合します。 --fail-on meaning-riskは diff と同じ種類に、資料から書いたときの資料にない数値を加えて数えます。--fail-on warnと--fail-on errorは lint の候補で止めます。どれも、記録を残したうえで終了コード1を返します。- 終了コードは、0が run で条件に当たらなかったとき・verify で記録と合ったとき、1が run で
--fail-onに当たったとき・verify で記録がないか合わないとき、2が使い方か入力の誤り（何も書きません）、3が検査の一部を実行できなかったときか内部の誤りです。
資料のファイル（--material）と --stdin の資料の部分は、<<<yomiyasu:material 出典>>> の行で区切ると、区切りごとに別の資料になります。出典は省いてもよく、200字まで書けます（>>> は含めません）。区切るのは、空白でない最初の行が区切りの行のときだけです。そうでなければ、今までどおりファイル全体が1つの資料です。
<<<yomiyasu:material 出力 git diff（harune/retry.py）>>>
-RETRY_INTERVAL_SECONDS = 1.0
+RETRY_INTERVAL_SECONDS = 0.5
<<<yomiyasu:material 利用者の発言>>>
保存は30日、削除は毎日3時に走ります
- 出典は記録に残りますが、照合しません。出典の中の数は資料の値として照らされません。
<<<yomiyasu:で始まる行が正しい区切りの行でなければ（<<<yomiyasu:materials …>>>のような書き損じ）、何も記録せずに終了コード2で止まり、正しい書き方を出します。書き損じた行が黙って資料の中身になり、出典の数が資料の値として照らされないようにするためです。- 区切りで分けた資料の1つが最終稿と同じ本文のとき、新規作成では今までの資料と同じく終了コード2で止まります。推敲（
--sourceあり）では止まりません。短い原稿を根拠の文どおりに直すと、根拠の文と最終稿が同じになるためです。
次の原稿と最終稿を、上の資料と --fact-gaps を付けて run に通した出力です（途中を省いています）。
（原稿）
## 変更点
再試行の間隔を短くしました。
保存期間を延ばし、古い記録は毎日消します。
今回の変更で、復元の失敗が大幅に減ります。
（最終稿）
## 変更点
再試行の間隔を1秒から0.5秒に短くしました。
保存期間を30日に延ばし、古い記録は毎日3時に消します。
今回の変更で、復元の失敗が大幅に減ります。
検査を実行しました（1回目）。下の候補を原文と資料に照らして確かめてください。直すのは1回までです。直したら同じコマンドをもう一度実行し、直さないなら提出の直前に、本文を変えずに verify を1回実行してください。
yomiyasu-check: executed via=run run=20261015T194529Z-0cf033b8 attempt=1 final=sha256:68ec5305c050 mode=rewrite checks=lint,diff,materials meaning_risk=2
実行した検査: lint（最終稿）候補0件、diff（原文→最終稿）変更あり 候補3件（うち意味が変わる恐れ2件）、資料との照合（資料2件）資料にない数値・名前2件、事実の穴の候補1件
（中略）
■ 意味が変わる恐れ（2件。原文と資料に照らして確かめる）
- 元にない数値（後3行目）: 1秒、0.5秒
元: 再試行の間隔を短くしました。
後: 再試行の間隔を1秒から0.5秒に短くしました。
- 元にない数値（後4行目）: 30日、3時（資料にある値）
元: 保存期間を延ばし、古い記録は毎日消します。
後: 保存期間を30日に延ばし、古い記録は毎日3時に消します。
■ 資料との照合（資料2件）
- 資料に基づく補足の候補: 30日、3時
- 資料に基づく補足の候補（該当行）: 30日（資料2の1行目「保存は30日、削除は毎日3時に走ります」）、3時（資料2の1行目「保存は30日、削除は毎日3時に走ります」）
- 単位のない数とだけ一致（資料にない数値に数えています。根拠の行か読み比べてください）: 1秒（資料1の1行目「-RETRY_INTERVAL_SECONDS = 1.0」）、0.5秒（資料1の2行目「+RETRY_INTERVAL_SECONDS = 0.5」）
- 照らしたのは数値、名前、語、確度の語だけです。主張、条件、担当が資料どおりかは判定していません。資料と読み比べてください。
■ 事実の穴の候補（1件。比喩や程度の語だけで、中身や値が書かれていないかもしれない所です。根拠に中身が書かれているときだけ補い、なければ残すか、書き手への問いにしてください。候補は一部だけです）
- 後5行目（程度の値（何がどれだけ）がない「大幅に」）: 今回の変更で、復元の失敗が大幅に減ります。
- 「資料に基づく補足の候補（該当行）」は、最終稿の値が資料の何行目にあったかです（1つの値に3行まで、行の文は40字まで、値は5つまで）。
- 「単位のない数とだけ一致」は、最終稿の値（0.5秒）と同じ数が、資料の
名前 = 数か名前: 数の形の行にだけあるものです。件数は「資料にない数値」のままで、行を見せるだけです。日付、時刻、パス、版の中の数は見ません。 - 資料の行に「予定」「たぶん」「と思います」などの確度の語があり、最終稿のその値の文にないときは、値を添えて出します（資料「保存期間を30日に延ばす件は、来月からの予定です」、最終稿「保存期間を30日に延ばします。」のとき、
- 資料にあった確度の語が最終稿にない: 予定（30日の文））。 - どの行も、資料のその行に同じ値があることを示すだけです。根拠であることも正しいことも示しません。設定の
retry_wait = 3を回数の「3回」に使うような取り違えも同じ行に出るので、行の名前と最終稿の文を読み比べてください。 - 照合の節に行が足されるだけで、件数、1〜3行目、状態の行、終了コードは変わりません。
- 正しく補った値も原文にない数値なので diff の「意味が変わる恐れ」に出ます（上の2件）。
--fail-on=meaning-riskを付けた run は正しい補いでも終了コード1になります。 --fact-gapsを付けると、最終稿のうち、程度の語だけの文（大幅に、劇的に）、変わる前と後の値がない変化（短くしました、高速化しました）、効果だけの文（信頼性が向上します、改善しました）、中身の見えない比喩（土台づくり、連鎖を断ち切る）を「■ 事実の穴の候補」に10件まで出し、3行目の最後に「、事実の穴の候補N件」を足します。候補があれば、ほかの候補がなくても1行目は「下の候補を原文と資料に照らして確かめてください」になります。--fail-on、状態の行、必要な検査には入れません。候補は一部だけです（限界）。--doc-type essayとpromoでは節を出さず、3行目に「事実の穴の候補（種類 essay では出していません）」のように書きます。formal と paper では、節の見出しの文が「この種類では補わず、必要なら書き手への問いにしてください」になります。- 拾う語の一覧は
references/lists/fact-gaps.txt（「種類正規表現」の行）にあり、足し引きできます。ないときや読めないときは内蔵の一覧で動き、読めなかったときは節の最後にそのことを1行出します。記録のあとで一覧を変えると、--fact-gapsを付けた記録は、ほかの一覧と同じく verify でtool_changedになります。付けなかった記録は、この一覧で結果が変わらないので、変えてもtool_changedになりません。 --jsonと記録にはfact_gaps（件数、種類ごとの件数、20件までの候補）が付きます。付けなかった run では null です。照合の JSON の項目にはfound_in（どの資料にあったか）、evidence（資料の何行目か）、bare_in（単位のない数とだけ一致した行）、values（確度の語に添えた値）が、sourcesにはlabel（出典）が足されます。形式の版は上げていません。
フックは、ホストが決まった時点で動かすコマンドです。yomiyasu_hook.py は、登録した原稿について、検査を実行したか、最終稿が検査記録と同じかを、返答の終わりと投稿の前に確かめます。入れなくても yomiyasu はこれまでどおり使えます。利用者が自分の設定ファイルに貼ったときだけ動き、スキルやプラグインを入れただけでは動きません。
フックは、読みやすさの合格や、意味が保たれたかを判定しません。会話の中の日本語を書き換えたり、登録していない原稿の保存や投稿を止めたりもしません。
対象になるのは、登録した原稿だけです。
- 端末で
python3 -B /path/to/yomiyasu/scripts/yomiyasu_check.py start --source docs/draft.mdを実行します。最終稿を別のファイルに書くときは--final docs/final.mdを足します。 - Claude Code では、プロジェクトに置いたスキルを
/yomiyasu docs/draft.md を読みやすくしてのように呼び、原稿のファイルを書くと、フックが登録します。登録するのは、依頼の文で最初に出てくるファイル1つだけです。2つ以上の原稿は、端末で1つずつstartしてください。 - Codex では、
$yomiyasu:yomiyasu docs/draft.md を読みやすくしてのように依頼の文にスキルの名前を書くと、フックが登録します。$yomiyasuと書いても登録します。登録するのは、Claude Code と同じく最初に出てくるファイル1つだけです。試した置き方では Codex がスキルをyomiyasu:yomiyasuという名前で一覧に載せたので、$yomiyasuと書いた回ではスキルの指示が読み込まれませんでした。
python3 /path/to/yomiyasu/scripts/yomiyasu_hook.py --print-config claude-codeで、このスクリプトの絶対パスを入れた設定の例を出します。設定ファイルには書き込みません。- 出た JSON を、管理したいプロジェクトの
.claude/settings.jsonか.claude/settings.local.jsonに貼ります。~/.claude/settings.jsonに貼るとすべてのプロジェクトで動き、Bash と MCP のツールを呼ぶたびに python が起動します。 - プラグインを更新するとスクリプトのパスが変わります。更新したら、設定の例を出し直して貼り直してください。
Codex では次のように入れます。
python3 /path/to/yomiyasu/scripts/yomiyasu_hook.py --print-config codexで設定の例を出します。- 出た JSON を、管理したいプロジェクトの
.codex/hooks.jsonに置きます。 - Codex は、信頼していない hooks.json を、何も知らせずに飛ばします。試したのは、
codex execに--dangerously-bypass-hook-trustを付けて信頼の確かめを飛ばした形だけです。/hooksで信頼する手順は試していません。 codex execに--ignore-user-configを付けると、プロジェクトの.codex/hooks.jsonも読まれず、フックは1つも動きません（1回確かめました）。
- 返答を終えるたびに、登録した原稿の最終稿が検査記録と合うかを確かめます。合わなければ、理由を渡して作業を続けさせます。続けさせるのは2回まで、登録から30分まで、run は3回までです。超えたら「未確認」として1回知らせ、それ以上は続けさせません。自動で書き直したり投稿したりはしません。上限は
startの--max-stop-blocks、--max-runs、--deadline-minで変えられます。 - Claude Code は、フックが作業を続けさせたときに「Stop hook error occurred」と表示し、投稿を止めたときに「PreToolUse:Bash hook error:」に続けて理由を表示します。どちらも、フックの判断を知らせる表示です。
- Codex の
codex execでは、続けさせる理由が利用者の入力としてエージェントに届きます。投稿を止めたときは「Command blocked by PreToolUse hook:」に続けて理由が出ます。 - 投稿には、
yomiyasu_check.py export --final 最終稿で書き出した写しを使ってください（例gh pr create --body-file <写し>）。写しは.yomiyasu/exports/にでき、検査した最終稿と同じバイト列です。照合が合わないときは写しを作りません。写しができても、合格の判定ではありません。 - 補助として、登録した原稿に関係する
ghの投稿（pr、issue、release の本文と、api の本文の欄）と MCP の投稿で、本文が検査記録と照合できないときは止めます。--body "$(cat 最終稿)"のように本文を取り出せない投稿は、利用者に確かめます（Claude Code の-pでは実行されません）。Codex には利用者に確かめる仕組みがないので、止めます。登録と関係ない投稿は止めません。 yomiyasu_check.py end --source docs/draft.mdで登録を終えられます。セッションが終わったときも終わります。Claude Code の-pでは1回ごとにセッションが終わるので、端末で登録した原稿が効くのは-pの1回分です。--resumeで続けても、前の回の登録は引き継がれません。- 登録のある原稿の run は、上限を超えると検査せずに
unverifiedと終了コード1を返します。登録の無い原稿の run と verify は、フックを入れる前と同じです。 - フックが登録を探す状態フォルダは、
--state-dir、環境変数YOMIYASU_STATE_DIR、ホストが渡す作業ディレクトリの git の最上位（なければ作業ディレクトリ）の.yomiyasu/の順です。Claude Code では、環境変数CLAUDE_PROJECT_DIRのプロジェクトの.yomiyasu/も探します。 - フックとして呼ばれたとき（
--host）は、入力や引数が違っても、登録がなくても、内部の誤りでも、何も出さずに終了コード0で終わります。知らない引数も無視します。ホストの作業を止めないためで、作業を続けさせることと投稿を止めることは、標準出力の JSON で伝えます。--print-configの値がないときと、claude-codeとcodexのほかの値のときだけ、終了コード2で使える値を出します。引数と終了コードはyomiyasu_hook.py --helpにあります。
- フックは補助で、確かめていない原稿の公開を完全には止められません。フックの時間切れや失敗、一覧にないコマンド（
gh以外）、本文を取り出せずパスも書いていない投稿、本文を少し変えた投稿、利用者が自分で行う投稿は止まりません。 - 返答の中だけで推敲し、ファイルに書かなかったときは、フックでは見つけられません。
- Codex の
codex execでは、「未確認」の知らせが利用者に表示されません（JSON の出力で2回、人向けの出力で1回確かめました）。フックは知らせを出していますが、Codex が表示しません。上限で止まったときは、エージェントの完了報告の「実行しなかった検査」を見て、投稿の前にyomiyasu_check.py verifyで確かめてください。 - 試した Codex では、エージェントのコマンドはコード実行のツール（
exec_command）を通り、Bashとしてフックに届きました。ほかの経路でコマンドを実行したときにフックが見るかは、確かめていません。 - 同じプロジェクトで2つのセッションを同時に動かすと、端末で登録した原稿は、先に動いたセッションのものになります。取り違えを避けたいときは、
start --sessionでセッションを指定します。 - 登録、記録、写しは
.yomiyasu/にあり、エージェントと同じ権限で書き換えられます。改ざんの防止や人の承認の証明にはなりません。フックはネットワークを使わず、本文を外へ送りません。フックの出力と登録のファイルにも、本文は入れません。
| ホスト | 版 | 入れ方 | 試したこと |
|---|---|---|---|
| Claude Code | 2.1.296（macOS） | プロジェクトの .claude/settings.json、claude -p、プロジェクトに置いたスキルの /yomiyasu |
端末の start と /yomiyasu での登録、検査のあとの書き換えで続けさせること、上限での未確認、関係ない作業を止めないこと、export の写しでの投稿、照合の合わない投稿を止めること、本文がフックの出力に出ないこと |
| Codex | codex-cli 0.162.1（macOS） | プロジェクトの .codex/hooks.json（--print-config codex の出力そのまま）、codex exec、--dangerously-bypass-hook-trust、サンドボックスは workspace-write、承認は never、作業場所の .agents/skills/ に置いたスキル |
端末の start と $yomiyasu・$yomiyasu:yomiyasu での登録、上限まで続けさせて止まること（「未確認」の知らせは表示されない）、export の写しでの投稿、照合の合わない投稿と本文を取り出せない投稿を止めること、登録と関係ない投稿を止めないこと、セッションの終わりで登録を終えること、空白を含むパスでフックが動くこと、本文がフックの出力に出ないこと |
Codex は、プラグイン、アプリ、メモリ、複数のエージェント、ログインシェル、利用者のルールとスキルを切って試しました。ふだんの設定では、コマンドの形やツールの名前が変わるおそれがあります。
ここにない形は確かめていません。Claude Code の対話モード、Claude Code にプラグインで入れたときの /yomiyasu:yomiyasu、.claude/settings.local.json と ~/.claude/settings.json に置く形、Codex の対話の画面、/hooks での信頼、~/.codex/hooks.json に置く形、会話の途中でエージェントが start したときの結び付け、MCP の投稿（どちらのホストでも）、Windows、Cursor、Claude.ai では試していません。
付属の検査（lint と diff、2つをまとめて実行する check）は、決まった形を拾うものです。意味が保たれたかと読みやすいかは、元の文と読み比べて人が確かめてください。候補が出なくても、変わった箇所は全文差分に出ます。以下は 2.0.0 の時点で分かっている限界で、細かい形は各項目の「細かい形」を開くと読めます。
このバージョンのスキルを実際に動かして確かめたホストは、macOS の Claude Code（2.1.296）と Codex（codex-cli 0.162.1）です。どちらも作業場所にスキルを置き、対話の画面を使わないコマンド（claude -p と codex exec。Codex の2ターンの形では、同じ会話に続きを送る codex exec resume）で動かしました。Claude Code と Codex の対話の画面、Cursor、Claude.ai のZIP、プラグインや skills CLI、openskills で入れた環境では確かめていません。Windows の実機でも確かめていません。任意のフックを試した範囲は、フックの節の試したホストに書いています。
Codex では、4つの呼び方で8本ずつ推敲させました。「/yomiyasu」の行のあとに本文を貼る形、$yomiyasu:yomiyasu に依頼の文を添える形、作業フォルダに原稿を1つ置いて「/yomiyasu」とだけ送る形の3つでは、AI が書いた同じ原稿8本（1本あたり空白を除いて950〜1,335字）を使いました。4つ目は、同じ8つの題で Codex に返答で文章を書かせ、次に「/yomiyasu」とだけ送る形です。32本とも SKILL.md を読んで推敲し、最初の3つの形では8本とも最終稿に検査をかけて記録を残しました（本文を貼る形の2本と $yomiyasu:yomiyasu の形の3本は、記録を作業場所の .yomiyasu/ とは別のフォルダに置きました）。返答で書かせた文章の形で最終稿に検査をかけたのは6本で、6本とも記録を残さない形でした（最初の依頼で、ファイルに保存しないよう頼んだためです）。32本のどれにも、2つのモデル（Claude と Gemini 4 Argon）は確かな意味の変化を挙げていません。意味が変わったかもしれないとした箇所は、Claude が15か所、Gemini 4 Argon が3か所挙げています。このバージョンの Codex の出力が読みやすくなったかは、人がまだ比べていません。
Codex で試した形
| 呼び方 | このバージョン | 1.1.2（別の回） |
|---|---|---|
| 「/yomiyasu」の行のあとに本文を貼る | 8本とも最終稿に検査をかけ、記録を残した | 最終稿に検査をかけたのは6本 |
$yomiyasu:yomiyasu draft.md を読みやすくして、結果を out.md に書いてください。 |
8本とも最終稿に検査をかけ、記録を残した | 最終稿に検査をかけたのは6本 |
| 作業フォルダに原稿を1つ置き、「/yomiyasu」とだけ送る | 8本とも推敲し、8本とも記録を残した。原文のファイルを書き換えた本はない | 8本とも「文章を貼ってください」と返し、推敲しなかった |
| 1ターン目にファイルに保存しないよう頼んで返答で文章を書かせ、2ターン目に「/yomiyasu」とだけ送る | 最終稿に run を通したのは6本（6本とも --no-record）。1本は最終稿とは違う文に lint だけをかけ、1本は検査をしないまま本文を返した |
8本とも検査をしなかった |
- 動かした条件は、codex-cli 0.162.1、モデルは gpt-6-astra（effort max）です。作者のふだんの設定に近づけるため、作者の AGENTS.md（yomiyasu を使うよう書いた行があります）を作業場所に置き、yomiyasu のほかに51件のスキルが見えるようにしました。この行のない環境で同じように SKILL.md を読むかは確かめていません。スキルは作業場所の
.agents/skills/に置きました。2ターンの形は、codex exec resumeで同じ会話に送りました。速い応答のモード（fast）は、本文を貼る形と$yomiyasu:yomiyasuの形で使い、ほかの2つの形では使っていません。 - 1.1.2 の値は、同じ原稿と呼び方（返答で書かせる形は同じ題）を別の回に動かしたもので、fast を使った本と使わなかった本が混じっています。1.1.2 には検査をまとめる run がありません。1.1.2 の SKILL.md は、lint をフルモードの指定かファイルに保存するときに求め、diff を書き直した文ができたときに求めています。
- 原文のまま返した本はありませんでした。変えた字数（原文1,000字あたりの中央値）は、本文を貼る形で86.6字、
$yomiyasu:yomiyasuの形で64.7字、作業フォルダの形で58.8字、返答で書かせた形で138.8字です。 - これより前のバージョン（1.1.2 を含む）では、依頼の文に「yomiyasu で」と書く形と
$yomiyasu:yomiyasuの形などを162本試し、162本ともスキルを読んで、検査が少なくとも1回動きました（最終稿に検査をかけなかった回は、1.1.2 にありました）。 - このバージョンで試していない形: Codex の対話の画面、
$yomiyasuと短い名前で呼ぶ形（フックの試しでは、この名前ではスキルの指示が読み込まれませんでした）、依頼の文に「yomiyasu で」と書く形、作業フォルダに書かせたファイルに「/yomiyasu」とだけ送る形、作業フォルダに原稿が2つ以上ある形、利用者のスキルの置き場所（~/.agents/skills/）に入れる形。
Claude Code では、下の手順の試験と、上の書き直し例、下の小さな比べのほかに、「/yomiyasu」とだけ送る形を今の SKILL.md で試しました。作業フォルダに原稿を1つ置いて8本送ると、8本とも推敲し、最終稿を作業フォルダにまだない名前で保存して、記録の残る検査を通しました。原文のファイルを書き換えた本はありません（名前だけで呼ばれたときの決めを足す前の SKILL.md では、推敲したのが7本、最終稿を作業フォルダに保存したのが6本でした）。Claude Code で試したのは作業フォルダに原稿が1つだけある形で、直前の返答の本文を推敲する形と、原稿が2つ以上あって聞く形は試していません。下の小さな比べの10本を、普通の依頼で今の SKILL.md に2回ずつ推敲させると、2つのモデルが確かな意味の変化を挙げた回はありませんでした。ただ、決めを足す前の SKILL.md の1回と比べると、変えた字数（原文1,000字あたりの10本の平均）は30.6字から46.2字と50.4字に増え、原文のまま返した本は1本から3本と1本になりました。変えた字数の差のほとんどは、1本の原稿（主語と述語のねじれなどを直した）から来ています。比べた相手は1回だけで、ぶれの幅は分かっていません。
手順を飛ばす割合は、yomiyasu を使うよう頼む12の筋書き（PR 作成のスキルとの併用、長い会話、本文だけを返す指定、ファイルを作らない対話など。原稿は合成の PR 説明文）を、ホストと版ごとに71回ずつ組んで動かし、1.1.2 と比べました。提出した最終稿に必要な検査をかけなかった回は、Claude Code では 1.1.2 の60回のうち31回から、2.0.0 の67回のうち0回になりました。Codex では、1.1.2 の68回のうち9回から、2.0.0 の68回のうち4回です（決めた数え方で決まらなかった7回を、人が記録を読んで省略なしと確かめて足した数）。Codex の差は回数が少なく、偶然の幅を除けるほどの差ではありません。測ったのは、名前だけで呼ばれたときの対象の決め方と、検査を run の CLI で動かす決めを SKILL.md に足す前のスキルです。この2つと確度の語の1文、検査のスクリプトの start、export、end とフックは、測ったあとに足しました。検査の動かし方の決めは手順にかかわるので、今のバージョンで同じ割合になるとは言えません。記録で見つけやすくなりましたが、記録があっても手順を飛ばすこと自体は防げません。
手順の試験の細かい形
- 必要な検査は、1.1.2 では lint と diff、2.0.0 では lint、diff、提出の直前の verify です（ファイルを作らない対話では verify を求めず、資料から書く筋書きでは資料を渡した run を求めます）。2.0.0 のほうが求める検査が多い条件です。lint と diff だけで数えると、2.0.0 は Claude Code で65回のうち0回、Codex で65回のうち4回でした。
- 回数は、無効になった回（Claude Code の 1.1.2 で利用の上限に当たった4回など）と、Python が使えない筋書きを除いたものです。数え方で決まらなかった回と、検査が要らなかった回（1.1.2 で本文を変えなかった3回）も分母から外しました。Claude Code の 2.0.0 で決まらなかった1回は、人が記録を読んで省略ではないと確かめました。
- Codex の 2.0.0 は、決めた数え方では61回のうち4回で、7回が決まりませんでした。7回の多くは、最終稿を写すのに cp でなく python を使った回です。人が記録を1回ずつ読み、7回とも省略ではないと確かめました。7回をすべて省略とみなすと68回のうち11回になり、1.1.2 より低いとは言えません。
- 決めた数え方で省略とした Codex の4回のうち3回は、ファイルを作らない対話の筋書きです。Codex が本文のあとに区切りの線と説明を続けて書いたので、決めた数え方では返答の全体が最終稿になりました。記録を読むと、3回とも区切りより前の本文に lint と diff をかけていました。残る1回は、本文だけを返す指定で verify をしなかった回です。記録を人が読んだ数え方では、Codex の 2.0.0 の省略はこの1回だけです。
- Codex の 2.0.0 の Python が使えない筋書きは、1回目を3回試して、3回とも Codex が別の場所の Python を見つけて検査を動かしたので、測れていません（残りの2回は動かしていません）。Python が使えないときに「実行しなかった」と報告するかは、Codex では分かっていません。
- Codex の完了報告で、SKILL.md の決まった形（「### 確認の記録」の見出しと行の名前）を守ったのは65回のうち0回でした。Claude Code は68回とも守りました。報告の中身は、どちらのホストでも実行した検査の範囲を超えていませんでした。
- Claude Code は、1.1.2 を 2.1.289 で、2.0.0 を 2.1.296 で動かしました（モデルは同じで effort high）。差のすべてがスキルの版によるとは言えません。Claude Code の 2.0.0 では、少なくとも5回が前の回の残したファイルに触れました（数えた値は変わりません）。Codex は gpt-6-astra（effort high）を、測定用の設定で動かしました。
- 測ったのは手順の実行だけで、意味が保たれたかと読みやすさは測っていません。3回だけの筋書きは、1回で割合が33%動きます。
意味が変わった箇所を diff がどれだけ拾うかは、少ない数でしか測っていません。tests/corpus の推敲の48組（古いバージョンの yomiyasu の指示で作った推敲の出力）を3つのモデル（Gemini 4 Argon、Gemini 3.8 Flash、Claude。3.8 Flash が判定したのは48組のうち44組）に判定させると、2つ以上のモデルが意味が変わったとした箇所は31か所ありました。そのうち、意味が変わる恐れの候補と重なったのは0か所で、全文差分には28か所が出ます。31か所のうち19か所は、原文にない担当者を主語や通知先に足したもので、今の検査の種類にありません。モデルの判定は参考で、確かめは人が行います。
AI が書いた原稿8本と合成の原稿2本（合計4,546字）を、スキルなし、1.1.2、開発の途中の 2.0.0（以下「途中の版」）の3条件で Claude Code に1回ずつ推敲させた小さな比べでは、2つのモデル（Claude と Gemini 4 Argon）がそろって意味が変わったとした箇所は、3条件とも0件でした。途中の版と 1.1.2 の差は偶然の幅に収まり、モデルの判定からは、どちらが意味を保ちやすいとは言えません。
同じ比べで 1.1.2 と途中の版の本文が違った7組を、作者が版名を隠して読み比べると、好みは 1.1.2 が6組、途中の版が0組、同等が1組でした。そのまま使えるとした出力は、1.1.2 が6組、途中の版が0組です（途中の版は、少し直せば使えるが4組、使えないが3組）。1人が各条件1回の出力を見た小さな比べですが、この比べでは、途中の版の推敲は 1.1.2 より好まれませんでした。上の2つの比べの途中の版は、SKILL.md を今の形に組み直す前のものです。
Codex の出力でも、上の最初の3つの形で使ったのと同じ原稿8本を、1.1.2 と、組み直したあとの SKILL.md（メール・論文の種類と、上に書いた2つの決めと確度の語の1文を足す前）で1回ずつ推敲させ、作者が版名を隠して読み比べました。依頼は「draft.md を yomiyasu で読みやすくして、結果を out.md に書いてください。」です。好みは 1.1.2 が4組、組み直したものが4組、同等が0組でした。答えたのは好みだけで、そのまま使えるかは見ていません。8組のうち6組で画面の左の出力を選んでいて、並びの偏りがあるかもしれません。1人が各条件1回の出力を見た小さな比べです。Claude Code の出力では、組み直したあとの今の SKILL.md の推敲を、まだ人が 1.1.2 と読み比べていません（組み直しの経緯は CHANGELOG の「変更」）。
このバージョンで足した書き直しの規則（詰めた漢語の句をほどく、見出しの括弧を外す、前後から決まる対象を補う、書き手と読み手に合わせた敬語など）は、測るために作った原稿30本（AI が書いた12本と合成の18本）で、1.1.2 と、規則を足す前の版と、同じ回の出力を比べました。Claude Code では2回、Codex では1回ずつ推敲させ、2つのモデル（Claude と Gemini 4 Argon）に判定させています。直すべき所を直した数は、規則を足す前の版より多く、1.1.2 と同じか上回りました（見出しの括弧と「〜について」は Claude Code で 16/16、規則を足す前の版 9/16、1.1.2 10/16）。確かな意味の変化は、どの版とホストでも0か所でした。一方で、直さなくてよかった変更は、Claude Code で 46か所（規則を足す前の版 35、1.1.2 35）、Codex で 44か所（42、41）と多く、前もって決めた目安に届いていません。その多くは、太字のラベルを外して述語にした所、見出しの括弧を外した所、詰めた漢語の句をほどいた所のように、このバージョンで足した直しで、読み手によって好みが分かれます。原稿は作者が測るために作ったもので、作者がまだ読み比べていません。
書き直しの規則を足したときの比べの細かい形
| 見たもの | Claude Code（2回） | Codex（1回） |
|---|---|---|
| 前後から決まる対象の補い（直した数） | 11/14（規則を足す前の版 12/14、1.1.2 11/14） | 6/7（4/7、4/7） |
| 詰めた漢語の句 | 16/16（15/16、16/16） | 8/8（8/8、8/8） |
| 見出しの括弧と「〜について」 | 16/16（9/16、10/16） | 8/8（5/8、6/8） |
| 取引先への依頼の敬語（ペルソナを書いた依頼） | 20/20（9/20、19/20）。2つのモデルがともに自然とした割合 17/20 | 10/10（10/10、10/10）。10/10 |
| 残すべき所を変えた数（文書の題、報告の語、表記など13種類） | 1（規則を足す前の版 r1 5・r2 5、1.1.2 r1 12・r2 15） | 1（8、20） |
| 直さなくてよかった変更 | 46（35、35）。うち読点を外しただけ 5 | 44（42、41）。うち読点を外しただけ 11 |
| 直す所がほとんどない原稿2本で変えた字数（2回の合計） | 11字（3字、23字） | 測っていない |
| 1.1.2 が直してこの版が残した所／この版が直して 1.1.2 が残した所 | 2／7 | 1／0 |
| 確かな意味の変化（2つのモデルのどちらか） | 0（0、0） | 0（0、0） |
- 原稿のうち3本は取引先へのメールで、依頼で書き手と読み手を伝えました。合成の原稿の5本にも、書き手と読み手を書いた依頼を使いました。
- 2つのモデルの判定が割れた所は、直っていない側と、残すべき所を変えた側に数えました。Claude の判定は、同じ問いを聞き直すと86%が同じ答えでした（境目の所で揺れます）。
- Codex は gpt-6-astra、effort max、速い応答のモード（fast）で動かしました。Claude Code は claude-opus-5-5、effort high です。
文脈から事実を補う手順を、モデルに動かして測った結果はまだありません。確かめたのは、合成の文と自動の試験で、check の --fact-gaps、資料の区切りの出典、照合の行が決めたとおりに動くことだけです。
原文にない担当者や動作主を主語や通知先に足した推敲（容量が一割を切ったら知らせる → 容量が一割を切ったら、保守担当者に知らせる）は、全文差分と「元の文にない語」には出ますが、意味が変わる恐れには出ません。上の tests/corpus の古い推敲の出力では、意味が変わった箇所の多くがこの形でした。
ほかに出ない形
できる → している、評価の語（容易）や表題の（下書き）を消した推敲、範囲を言い換えた推敲（一律に → 全部の口に同じ設定で）、する側と受ける側を替えた推敲、「にくい」を否定にした推敲（追いにくくなっています → 追えません）も出ません。
表記だけの違い（漢数字と算用数字、範囲・日付・時刻の書き方など）は候補にしないよう作っていますが、万と億を含む数の換算（一万円 → 1万円）、「.」で区切った日付、時刻の「:00」、「0円 → 無料」などは、値が同じでも候補に出て、--fail-on=meaning-risk に数えます。逆に、範囲の端の値を別の値として書き直した形、平仮名の数（ひとつ、ふたり）を足しただけ・消しただけの書き換え、助数詞の一覧にない語（冊、点、票）の数の変化などは拾えません。
細かい形（正しい推敲にも出る形）
万と億を含む数の換算（一万円 → 1万円）、「.」で区切った日付（2026.10.13 → 2026年10月13日）、時刻の「:00」（9:00 → 9時）、「v2.0 → バージョン2.0」「0円 → 無料」、「一度」と漢数字の並び（一度 → 1度、第三四半期 → 第3四半期、三四人 → 3〜4人）、前に何もない「一時」（一時三十分 → 1時30分。一時的の「一時」と分けられない）、「じゅうぶん」と分けられない「十分」（一回十分です → 1回10分です、八時間十分働いた → 8時間10分働いた）は、値が同じでも候補になります。直前が漢字の漢数字（夜一人で）は数として取らないので、助詞を足しただけ（夜に一人で）でも候補になります。回数を言わなくした書き換え（月一回 → 毎月）、「一人十分の量 → 一人あたり十分な量」、「層を1枚挟む → 層を作って前に置く」は、消えた数値として出ます。数を言わない語を数字で言い直した推敲（一意 → 1つ、倍々 → 2倍ずつ、単体 → 1件ずつ、集約 → 1件にまとめ）と、助数詞だけを替えた推敲（3〜4本 → 3〜4回）も候補になり、--fail-on に数えます。序数の「1つ目 → 最初の」は消えた数値、「一つずつ → 一枚ずつ」は元にない数値になります。同じ単位の数の前後を入れ替えただけの推敲（ひとりで3人分を食べた → 3人分をひとりで食べた）は、並びの候補になります。「ずつ」のあとに動詞がない文は、相手の文のどこかに「複数」「いくつか」があれば、順番に、と言い換えた正しい推敲（質問は一つずつどうぞ → 質問は順番にどうぞ。複数ある方も順番にお願いします）でも消えた数値になります。「一つずつ」の動詞や「一つの」の名詞を言い換えた1つの文では、主題と同じ語を主語にした節（似た質問が複数届いたら一覧にします）、主語のない節（版ごとに別々の名前を付けます）、送り仮名の途中で切れる主語の節（問い合わせが複数重なれば）にある 複数・いくつ・別々 を数えるので、別の物の数を言い換えただけの推敲でも消えた数値になります。数の主張が同じ語（順に）があっても、前から数えていた語（まとめて）が別の述語に付けば、消えた数値になります（ファイルは一つずつ確認する → ファイルを順に見て、結果はまとめて送る）。
細かい形（拾えない形）
範囲の端の値を、同じ文の別の値として書き直した形（3〜5日かかる → 5日で終え、予備に3日をとる）、数量を言っていない漢数字の「一つ」や期間の値を言わなくなった書き換え（今日一日で終える → 今日から数日で終える）、2つの文をまとめたときに組にならなかった文の「一つずつ」の変化、読点を挟まずに別の述語の打ち消しが続く形（一つずつ行う → 並列で行い遅延を出さない）、前に何もない「一時十分に → 一時に」、助数詞の一覧にない語（一人一票 → 一人二票。冊、点も同じ）と「お一人様一つ」の数の変化は、候補に出ません。数量を言っていない「一つ」と同じ扱いなので、「もう1つ」「1つの」を足した・消した書き換えは、数を限る意味でも拾いません（理由がある → もう1つ理由がある、同時に使える端末は1つの端末だけです → 同時に使える端末に制限はありません。「1つの」を含む文を消した推敲も同じです。資料から書いた最終稿の「1つの画面にまとめました」も、資料にない数値にしません）。平仮名の数は相手の文に同じ単位の値がないと比べないので、足しただけ・消しただけの書き換え（会議室はふたつある → 会議室がある）と、「ふたつしか」「ひとりだけ」「ふたりまで」「ふたつずつ」を言い換えた書き換えは拾いません（漢数字なら拾います）。資料から書いたときの照合でも、平仮名の数は資料の値と違っても候補にしません（参考の行に資料の値が出ます）。「に」「で」のすぐあとの「いつつ」は数として取らないので、「箱にいつつ入れる」の数の書き換えも拾いません。文を分けて「複数」「いくつでも」を別の文に置いた推敲（ファイルは一つずつ送ってください → ファイルを送ってください。複数あってもかまいません）と、「一つの」の名詞のある節から離して「別々」を置いた推敲（鍵は一つの金庫にしまう → 鍵は別々の場所にある金庫にしまう）は拾いません。数値の直前の2字とあとの語が同じ入れ替え（上限は10GB、下限は500MB → 上限は500MB、下限は10GB）、直前が読点の数の入れ替え（設計に3日、5時間を試験に充てる → 設計に5時間、3日を試験に充てる）、同じ助詞のあとの「約」の数の入れ替え（設計に約3日、試験に約5時間 → 設計に約5時間、試験に約3日）は、並びの候補にしません。
語ごと言い換えた否定（確認します → 確かめません）は、否定の候補に出ません。文を分け、否定を別の言い方で次の文に移した推敲（…形に変えてから、抜けた通知の調査は発生していません → …ています。この形に変えてから、抜けた通知を調べる事態は起きていません）は、正しい推敲でも否定の候補になり、--fail-on に数えます。
平仮名で始まる語（お知らせ）と漢字1字の語は、否定された語として取りません。見出しや「Aは使わず」の文、一覧にない言い方で A を後ろへ回した推敲などでは、正しい推敲にも候補が出たり、逆転を見逃したりします。否定した側を消しただけの推敲は候補にしません。逆転は --fail-on に数えないので、候補が出たら、A が目的や優先の側に移ったかを読んで決めてください。
細かい形
「お知らせ」のように平仮名で始まる語と、漢字1字の語（人ではなく仕組み）は、否定された語として取りません。「Aも含めて」の形も拾いません。見出しの行と「Aは使わず」「Aはせず」の文では、A を足しただけの書き換え（外部委託はせず、社内で作ることを最優先にします → 社内で作ることを最優先にし、外部委託も使います）と、別の節の語が A を指す書き換え（表計算は使わず → 表計算で入力し、これを最優先の手順にします）を拾いません。一方、一覧にない言い方で A を後ろへ回した推敲（来期に回す、Aに手を付けるのは見送る、Aは優先順位を下げる）は、正しい推敲でも候補に出ることがあります。下げる語は A のすぐあとに続く形だけを見て、「そのあとに回す」は平仮名の書き方だけを見るので、読点を挟んだ形（Aは、その次に見る）や「その後に回す」「次に見る」も、正しい推敲で候補に出ます。別の名詞のあとの「は後に回す」（品質を最優先にして速度は後に回す）の逆転は拾いません。主題の句（最優先は、大事なのは など）のあとに、置き換え先を言わずに A を変える言い方を置いた正しい推敲（## 大事なのは、会議を最小限にして文書で決めること）は、原文で肯定した側の語を使っていても逆転の候補に出ます。重みの語だけの句（まず、第一に など）のあとでも、原文で肯定した側の語を使わずに A を変える・取り除く・調べる言い方（減らす、絞る、洗い出す、時間を測る、A を別のものにする・別のものに変える。## まず、手作業を洗い出す）は、正しい推敲でも候補に出ます。読点を挟んで置き換える言い方（Aを、B に置き換える）も同じです。本文の「Aではなく」の推敲は、重みの語が文のどこにあっても見るので、原文で肯定した側の語を使った正しい推敲（まず、手作業を自動化する）でも候補に出ます。一方、重みの語だけの句のあとで A と B の語を両方使った逆転（## 会議ではなく文書で決める → ## まず、会議で決めて文書で知らせる）は拾いません。B を廃止する・見送る・控える・禁止する・なくす・頼らない、と言う逆転と、B より A を優先する・B を後回しにする、と比べて下げる逆転（## まず、会議を文書より優先する）も拾いません。逆に、置き換え先や A を使う句が一覧にない言い方（試作版を正式版に移行する、クラウドを主にした構成に切り替える）は A を下げた形とみなすので、A を採った推敲を見逃すことがあります。逆転は --fail-on には数えません。
否定した側を消しただけの推敲（AではなくB → B、Aに任せず → 消す）と、「Aにすぎず」の言い換えは、候補にしません（逆転だけを見る検査です）。
依頼を前置きする文を依頼の文にした推敲（お願いしたいことは3点あります → 次の3点をお願いします）と、結果を言う文を義務の文にした推敲（修正につながります → 修正しなければなりません）は、文の種類の候補になり、--fail-on に数えます。
元にない気持ちの語の検査（一覧は references/lists/feelings.txt）は、一覧の語だけを見ます。同じ語が原文のどこかにあれば、別の所に足しても出ません。「売上が前年より落ち込んだ」のように間に語が入る形と、「苦しい言い訳」のような気持ちでない使い方は、候補に出ます。
変わった文が1つだけの文書では、1文の条件に当たらない小さな硬化は出ません。勢いは、評価の語を短く重ねる型を1文にした推敲と、一覧にない褒め言葉の繰り返しを減らした推敲を拾いません。種類を指定しないと、定型の結びを消した推敲のような正しい直しも、勢いの見直し候補になります。
細かい形
promo でも、箇条書きの太字の行（- …）は見出しに数えません。ほかの種類では、番号つき項目の行と太字だけの行も数えません。評価の語を短く重ねる型（安い。うまい。早い。）を1文にした推敲と、強める語の一覧にない褒め言葉（絶品など）の繰り返しをまとめて減らした推敲は拾いません（紹介記事ではどちらも残す決まりなので、読み比べて確かめます）。種類を付けないときは、AIの定型の結び（「いかがでしたか？」「ぜひご活用ください」）を消した推敲や、技術文書の「！」を句点にした推敲のような正しい直しも、見直し候補になります。
慎重な言い方は、一覧（references/lists/hedges.txt）の7つの語と同じ文字の並びだけを見るので、「示唆した」「示唆される」のように形の変わった語が減っても拾いません。引用の印は、数字の角括弧と、著者と年をまとめた括弧の形だけで、本文に著者を書いた形（山田 (2020) によると）の著者の変化と、引用の印を別の文へ動かした推敲は拾いません。英字の著者は年の前に「,」か「et al.」があるものだけを見ます（(Smith 2019) は拾いません。(Windows 2000) のような製品名と年の括弧を引用と取らないためです）。漢字の名前と年の括弧（(東京 1998) など）は引用として見ます。符号は、直前が漢字や片仮名のときは見ません（「10月-12月」の範囲を負の数と取らないためで、「前年比-5%」の符号も見ません）。宛名は行の頭と宛先の欄のものだけを見ます。敬語の度合いは文書全体の割合で比べるので、短いメールでは1文の違いでも候補になり、長い文書では1文の変化を拾いません。「ください」も「くださる」に数えるので、「〜いただけますでしょうか」を「〜してください」にしても候補は出ません。文末の割合は「です・ます」と「だ・である」の文だけで数えるので、チャットの口語（〜かも、〜しときます）を「です・ます」にそろえても候補は出ません。二重敬語を正しく直すと（ご確認させていただきました → 確認いたしました）、敬語の数が減って候補が出ます。mail と paper の推敲の指針（references/doc-types/mail.md、paper.md）は、モデルに推敲させて結果を測っていません。tests/corpus には実際のメールと論文がほとんどなく、正しい推敲の48組で3つの検査の候補が0件だったことから、拾い漏れが少ないとは言えません。
敬語を上げる形は、同じ動詞に「お・ご」を付けた形と、人がふつう書く言い回しのどちらかを選びます。どちらが自然かは文脈で変わり、2つのモデルがそろって自然とはしなかった言い換えも残ります（測った原稿の取引先への依頼で、Claude Code の2回の20か所のうち3か所）。書き手の主語を補う文は、原文に書き手の一人称がある文書だけで、チームや会社の決定とも読める文には補いません。依頼で関係を伝えなかったときは、宛名から社外あてと分かっても敬語を上げません。
どれも語の表と文の組で見るので、表にない言い回しは拾いません。合成の組で確かめると、状態の語が消えた書き換えの9割、原文にない約束・誓いの足しの8割を数えました。原文にない因果の足しは、12組のうち9組で候補が出ました（数えない因果の候補が8組、ほかの数える候補が1組）。
原文にない評価の語（改善、向上、好評、大切）と、一般化・勧めの足し（他の窓口でも同様に、望ましい、とよいでしょう）は、diff では拾いません。語の表で試しましたが、合成の組で評価の足しは14組のうち0組、一般化・勧めの足しは14組のうち6組しか出せず（目安は7割）、配る diff には入れませんでした。表にない形容（分かりやすい、洗練された、盛況、適切、十分に小さい）や、表にない勧めの形（一般的です、どの店舗でも、種類を問わず）が多かったためです。「すべきです」のように文の種類の印（義務）が変わる足しは、文の種類の印の候補として出ることがあります。原文にない良し悪しの判断や勧めを足していないかは、読んで確かめてください（references/review-points.md）。
拾わない形と、正しい推敲にも出る形
- 状態の語: 表にない言い方（「照合はまだです」のように否定の述語のない「まだ」、「本人の確認待ちです」のように表にない名詞につく「待ち」、「未取得」のように表にない「未〜」）は見ません。近い家族の語への言い換え（調査中 → 原因は分かっていません）は、状態が残ったとみなします。表にない「未〜」に言い換えた正しい推敲（承認はまだ受けていない → 承認は未取得です）は、状態が消えたとして数えます。「〜中、」は、同じ節に「は」「が」の主題があるときだけ見ます。
- 約束: 誰の行為かは主語の語でしか見ません。書き手でない人の約束を、主語を書かずに足した推敲は、書き手の約束として出ます。謙譲の形も未来の印も書き手の主語もない「〜します」は、約束でも数えない候補にとどめます（お支払いの期限は1週間延ばします）。組になった原文の文に未来の述語があれば、別の行為の約束でも言い換えとみなして打ち消します（資料を読みます → 資料を破棄します）。済んだ行為を未来の約束にした書き換え（送りました → 送ります）と、他人の行為を書き手の行為にした書き換えは見ません。「伺います」「行います」のように「い」で終わる動詞の「〜ます」は、状態の述語と区別できず、拾いません。依頼や資料に書いてある約束を足したときも数えます。「当方では分かりかねます」「〜をお勧めします」は、約束ではないのに約束として数えます（正しい推敲でも
--fail-onで終了コード1になります）。 - 因果: 原文の1文の「〜し、」「〜て」を「ため」「ので」と語にしただけの形は出しません。「〜をきっかけに」「〜した影響で」「〜した効果で」のような表にないつなぎは出しません。
--fact-gaps の候補は一部だけです。拾うのは、程度の語だけの文、変わる前と後の値がない変化、効果だけの文、中身の見えない比喩の4つで、主語の抜けは拾いません。数値、確度の語、ぼかした語、書き手が省いた印、決意や抱負の結びのある文と、問い、見出し、表、コード、引用も見ません。候補に出なかった所にも、中身の書かれていない所はあります。
候補を測った数
- 一覧を合わせ込むのに使った合成の文では、出てほしい35文のすべてに出て、残す31文には出ませんでした。
- 合わせ込んだあとに書いた合成の文では、出てほしい25文のうち17文に出て、残す21文には出ず、境目の4文のうち2文に出ました。拾えなかった8文は「待ち時間がぐっと減りました」「検索の高速化を実現しました」「費用を抑えました」「安定稼働に大きく貢献します」「挙動を見直しました」「体験を一段と高めます」「開発の道が開けました」「黙って失敗していました」のような文です。
- 評価用に AI に書かせた文のうち、残す例として集めた61文と、tests/corpus の human の16本（作者の記事の抜粋8本と、人の文らしく AI が書いた例文8本）には出ませんでした。tests/corpus は一覧を合わせ込むのに使った群なので、取っておきの結果ではありません。
- 6万字の文書で候補を探す時間は、Python 3.14.5 で約0.03秒、3.9.6 で約0.04秒でした（3回）。
- 照合の「資料に基づく補足の候補」と「単位のない数とだけ一致」は、資料のその行に同じ値があることを示すだけで、根拠であることも正しいことも示しません。設定の
retry_wait = 3を回数の「3回」に使う、失敗した回と成功した回のログの時間を変更の前と後にする、といった取り違えは、道具では止められません。 - 照らすのは数値、名前、語、確度の語だけで、主張、条件、担当が資料どおりかは判定しません。
- 抜き書き（
.material.txt）の中身が、開いたファイルやコマンドの出力と同じかは確かめません。 - 抜き書きも、ほかの資料と同じく記録の
.yomiyasu/inputs/に写しが残ります。残したくないときは--no-recordを付けます。 - 資料のファイルに
<<<yomiyasu:で始まる行があり、正しい資料の区切りの行でなければ、--materialでも終了コード2で止まります。 - スキルが補った事実が正しいか、問いにすべき所を問いにしたかは、道具では判定しません。
lint が箇条書きの比率から外すのは、行頭から書いた <details> と </details> の組の中だけです。
細かい形
行頭から書いた開きと閉じが組になったときだけ見ます。段落の途中に書いた <details>、閉じていない <details>、引用の中の <details>、:::details のような Markdown の拡張の書き方は見ず、中の箇条書きを今までどおり数えます。<details open> も畳んだものと同じに扱います。ライブラリとして lint_text() を呼ぶときは、先頭の BOM を外した文字列を渡してください（BOM が残ると1行目の <details> を見ません。コマンドは BOM を外して読みます）。
本文に <<<yomiyasu: で始まる行がある文書は、--stdin では渡せません（ファイルで渡します）。6万字ほどの文書の全体を書き換えると、run の既定の --timeout（90秒）では diff が終わらず、結果が partial になります（全面書き換えの合成の文書で測ると、--timeout 1500 にして約15分で executed になりました）。小さな修正なら、6万字でも10秒ほどで executed になります。
.
├── .claude-plugin/ # Claude Code用プラグイン設定
│ ├── plugin.json
│ └── marketplace.json
├── README.md # 本ドキュメント
├── CHANGELOG.md # 変更履歴（2.0.0 から）
├── LICENSE # ライセンス（MIT）
├── UNICODE-LICENSE.txt # Unicodeデータの著作権・許諾通知
├── scripts/ # 付属検査ツール群
│ ├── yomiyasu_lint.py # 表現と書式の検査
│ ├── yomiyasu_diff.py # 推敲の前後の比較（全文差分と意味が変わる恐れ）
│ ├── yomiyasu_check.py # lint と diff をまとめて実行し、記録を残す
│ ├── yomiyasu_hook.py # 任意のフック（設定に貼ったときだけ動く）
│ ├── markdown_visibility.py # Markdown構造・表示判定の共有モジュール
│ └── setup_corpus_static.py など # 評価用コーパスを作った開発用のスクリプト
├── references/ # スキル参照ドキュメント
│ ├── gemini-syntax.md # 構文変換原則
│ ├── slop-catalog.md # 不自然な語彙・構文カタログ
│ ├── audience.md など # 種類と読者の決め方、書き手と読み手、出力の見方、言い直しテスト、事実の確かめ
│ ├── doc-types/ # 文書の種類ごとの注意（12種類）
│ ├── domains/ # 分野別指針（tech, business, essay）
│ └── lists/ # 検査に使う語の一覧（名詞化、強める語、気持ちの語、慎重な言い方、事実の穴の候補）
├── skills/ # 配布用スキル（唯一のSKILL.mdと参照文書・検査ツール）
│ └── yomiyasu/
│ ├── SKILL.md
│ ├── references/
│ └── scripts/
├── tests/ # 単体テスト・回帰テストスイート
│ ├── test_*.py # 検査ツールとスキルの文書の試験
│ ├── corpus/ # 評価用コーパス（human/ の扱いは付属ツールの節）
│ └── fixtures/ # 回帰テスト用フィクスチャ
└── evals/ # 評価データ
└── comparison_benchmark.md # 過去の比較検証の記録
開発では、ALGO ARTIS 社内でのLLM文章に関する議論、先行調査、学術論文、既存の文体調整ツールを参考にしました。各資料から学んだ点を紹介します。スキルの具体的な編集ルールや数値の目安は独自に決めたものであり、引用した研究がその効果を保証するものではありません。
- AI臭い文章とは何なのか（Speaker Deck）（nasuvitz氏）
AI特有の読みにくさは単語選び以上に統語構造（SVOCM）の破綻や非生物主語に起因するという指摘を参考にしました。「誰が何をどうした」を1文ごとに完結させる原則の策定に役立てています。 - Qiitaの7万記事を数えてみた話（逆瀬川氏）
AI普及後に生じた形式のインフレ（太字や箇条書きの急増）と手順の希薄化を定量的に示した調査です。技術記事における太字頻度やリスト比率の制限、手順復元指針の根拠として活用しました。 - Gemini 3.8 Flashこそ日本語執筆の救世主だった（X）（まつにぃ氏、@yugen_matuni）
自然な助詞配置と主述の結びつきを持つ日本語構造に着目する契機となりました。その統語特性を分析し、プロンプト指示として定式化しています。 - AI語に親しむ / AI語を受容する（ktrmnm氏）
AI特有の比喩動詞や直訳調の構文パターン分析を参考にしました。比喩動詞の技術的操作化や、不要な否定対比の平文化ルールに反映させています。 - AIの作文はなぜつまらないのか？ / なぜAI臭さを消したいのか？（laiso氏）
過剰な包装紙（前置フィラーや定型クロージング）への批評や、型を押し付けることへの注意点を参照しました。前置きの排除や、生活実感・身体性を残す方針に活かしています。
- Yamashita et al., Evaluation of Document-Level Text Simplification in Japanese, LREC 2026
必要情報、意味保持、文の平易さを分けて評価する設計の参考としました。 - Jeong, Park & Yu, Right at My Level: A Unified Multilingual Framework for Proficiency-Aware Text Simplification, ACL 2026
原文内容の脱落と、根拠のない情報付加を別々に検証するアプローチを参考にしています。 - Ide et al., Towards Automated Lexicography: Generating and Evaluating Definitions for Learner's Dictionaries, 2026
局所的な問題箇所の特定と修正を通じて、文全体の整合性を保つ手法の参考にしました。 - Nohejl et al., A Japanese Dataset and Efficient Multilingual LLM-Based Methods for Lexical Simplification and Lexical Complexity Prediction, 自然言語処理 32巻4号
語の平易化における文法性と意味保持のバランスを検討する基礎としています。 - 八木ほか, 多文化共生を目指した『やさしい日本語』における大規模言語モデルのプロンプトデザインの検証, 人間中心設計 22巻1号
プロンプト内の例示設計とモデルの挙動特性に関する知見を参考にしました。 - Chen, Yue & Davidge, Comparing generative AI with native speakers in terms of request expressions in Japanese, Discover Education 2025
相手との距離感を保ち、主語や敬語を一律に過剰付加しない判断の参考にしています。 - Zaitsu et al., Stylometry can reveal artificial intelligence authorship, but humans struggle, PLOS One 2025
AIらしさの検出と読みにくさの判定を区別して扱う論理的根拠としました。 - 三浦・久保山, 生成AIは文体を均質化するのか？, 人工知能学会 2026 / 林・相澤, LLMによる日本語生成におけるモデル固有表現パターンの分析, 言語処理学会 2026
文体の画一化を避け、書き手らしさや文末の自然な交差を尊重する視点を学びました。 - 李・長谷部, ChatGPTによる日本語ニュースの平易化 生成AIと『やさしい日本語』, 計量国語学 34巻8号
数値上の単純化と、人間にとって自然な編集の差異を踏まえるための指針としています。 - 書式および語彙の偏りに関する研究群（ACL 2025 書式バイアス研究, COLING 2025 語彙偏り研究, Miklian et al. 2026）
強調やリストへの評価偏向、英語直訳思考の影響を理解するための補助資料として活用しました。
- natural-japanese, stop-ai-slop-jp, japanese-tech-writing, cognitive-rhythm-writing, humanizer
読者に応じた編集、専門用語や条件の保持、文の長さや区切り方などを参考にしました。各作者に感謝します。
- 千早耿一郎『悪文の構造 機能的な文章とは』 公開図解と確認した本文を参考に、主語・述語・修飾先などの関係を分析し、書き直した後も照合する点検を加えました。意味保持の既存ルールと組み合わせた独自の指示であり、本書の全手順を再現するものではありません。
- 「AIっぽい文章を直すスキル」に、うちの日記を通したら、ほとんど直されなかった 自然な文を不要に変更しないことと、保存済みサンプルの意味を原文と照合することを、検証項目として見直しました。
- 流行りの「AI日本語推敲スキル」を使う前にやっておきたいこと 説明すると述べた対象や関係が、本文から読み取れるかを確認する観点を参考にしました。
開発者: 大賀 愛一郎（oga_aiichiro）@ALGO ARTIS
宛先: @oga_aiichiro
※ 本スキルおよび本リポジトリは個人の研究・創作物であり、所属企業の公式プロダクトや見解を代表するものではありません。
本リポジトリのコードおよびドキュメントは MIT License のもとで公開しています。同梱しているUnicode由来データの著作権・許諾通知は UNICODE-LICENSE.txt に記載しています。検証や引用に用いた外部資料の権利は各著作者に帰属し、それぞれの利用規約（CC BY 4.0等）に従うものとします。
yomiyasuを記事や動画、SNS、勉強会などで紹介・解説していただけると嬉しいです！ 作者への連絡や許可はいりません。
ただし、yomiyasuは無料で公開しているオープンソースのスキルで、正式な配布元はこのリポジトリだけです。 yomiyasuを紹介・同梱する有料の教材や情報商材、yomiyasuとの関連をうたうトークンや暗号資産に、作者は一切関わっておらず、収益も受け取っていません。
yomiyasuは、多くの先行研究や公開された知見をもとに作っています。 そのため作者は、これまでもこれからも、yomiyasuそのもので利益を得るつもりはありません。
このREADMEは、yomiyasu の指針に沿って書き、付属の yomiyasu_lint.py に通しています（2.0.0 で書き足した文は、スキルの推敲にはかけていません）。