yomiyasu（よみやす）

English

これは何？

『yomiyasu（よみやす）』はAIが生成した日本語の不自然な比喩、曖昧な主述関係、不要な装飾を直し、読みやすい文章に整えるスキルです。

主に技術記事、設計書・仕様書、PR説明文、社内レポートなどの実務的な文章を対象として設計されています。

Claude Code、Codex、CursorをはじめとするAIコーディング環境に読み込ませて使用してください。本体を入れられない環境のために、本体を短くした yomiyasu-mini と yomiyasu-pocket も公開しています（本体を入れられない環境では）。

開発の背景、AI生成文の読みにくさ、コーパスを使った検証については、次の解説記事で紹介しています。

• AI-Slopな日本語を構造レベルで読みやすくするSkill『yomiyasu（よみやす）』を作りました（Zenn）

背景と課題

文章を生成するAIは日常的な道具となりました。 一方で、AIで生成された文章には独特のクセが残りやすく、そのままでは実務や技術発信に使いにくい場面が多くあります。

これまでに様々な文体調整プロンプトやスキルが試されてきましたが、依然として「AI特有の読みにくさ」が残るケースが見られます。

従来のアプローチが抱えていた限界は、主に次の4点でした。

1. 禁止語の置き換えにとどまる対処

1. 編集ルールの過剰適用

1. 主述関係の曖昧さと非生物主語

1. 形式の偏重と情報密度の低下

本スキルのアプローチ

元の意味を保ったまま、読み違えやすい箇所や、文の関係を追うのに負担がかかる箇所を直します。自然に読める部分は残します。

7つの変換原則

1. 主述・修飾・条件の点検

1. 文の働きと文体の保持

1. 擬人化の整理

1. 比喩を平易な言葉へ

1. 前置き・否定対比の役割の確認

1. 情報を勝手に足さない

1. 文長・読点・装飾の調整

2.0.0 で加わったこと

このバージョンでは次の5つの手順を加えました。7つ目の原則にある読点とラベルの決まりも、このバージョンで足したものです。

• 書き直す前に、yomiyasu は文書の種類（PR説明、障害報告、メール、エッセイ・小説など13種類）と読者の知識（3段階）を決めます。議事録の箇条書きやメールの挨拶のように、その種類で普通の書き方は直しません。決めきれなければ、種類ごとの決まりを当てずに直します。
• 規則に当たった箇所を直す前に、案と原文を6つの点（何について述べるか、何を認め何を否定するか、誰が誰にするか、範囲と条件、言い切りの強さ、数値・固有名詞・時期）で比べます。1つでも変わるなら原文を残します（言い直しテスト）。
• 利用者が依頼で書き手と読み手の関係（「取引先に送るメールです」など）を伝えると、yomiyasu はその関係で人がふつう書く敬語に直します。書き手が自分でした行為で、ほかの人の行為と読み違えやすい文には、原文にある「私」「弊社」などを主語に補います。
• 原稿に抜けた数値や条件があると、yomiyasu は会話や資料から同じことを述べた文を探し、見つかったときだけ補います。見つからなければ本文はそのままにし、読み手が動けなくなる所だけを元の書き手への問いにします。
• 書き直したあとは、付属の yomiyasu_check.py で lint と diff をまとめて実行し、数値、否定、主語と目的語の入れ替えなどの変化を見直し候補として確かめます。返す直前には、最終稿が検査したものと同じかを記録と照らします。

2.1.0 で加わったこと

語順や省略、助詞の選び方による読み違いと、仕様書や設計文書での許可・能力・保証の言い方のずれを扱う手順と検査を加えました。

• 目的語を書かない他動詞の前に比較や条件の句が挟まり、前のほうにある別の名詞が目的語に読める文は、文脈にある対象を目的語に書くか、動作を名詞にします。決まらなければ書き手に確かめます。漢語を和語の動詞に替えるのは、替えたあとも目的語が追え、意味の幅が同じときだけです。
• 主題の「〜は」「〜では」が後半の節まで掛かって読める文で、主題が部品や処理の名前で、後半に別の名前（設定、マクロ、ファイルなど）を扱う動作が出てくるときは、後半もその主題の話かを文脈から確かめ、決まらなければ主体を足さずに書き手に尋ねます。尋ねる場面をこれより広げると、ほかの文書でも念のための問いが増える恐れがあります。問いが多いと、書き手はそのたびに答えを考えることになり、本当に答えが要る問いがほかの問いに埋もれます。この釣り合いを見て、尋ねる場面をこの形に絞っています。
• 前置きのない「〜で変わったのは、A、B、C。」は、前の文や見出しに前提がなければ、「〜では、A、B、Cが変わった」のように述語まで書いた形に直します。lint には、この形を見直し候補にする規則（cleft_list_ending）を足しました。
• 「〜してよい」（許可）、「〜できる」（能力）、「必ず〜する」「〜を保証する」（保証）を互いに替えません。diff は、許可の言い方が消えた・増えた書き換えと、常体の「保証する」を足した書き換えを --fail-on=meaning-risk で止めます。仕様書や記事など、事実や仕様を述べる7つの文書の種類を指定したときは、「場合がある」を消した言い切りと「必ず」を足した書き換えも止めます。
• 「書き手に確かめたい点」は3点までになりました。3点を埋めるために問いを足さず、答えで本文が変わらない提案は入れません。

2.2.0 で加わったこと

推敲しても残りやすい言い方を lint の指摘で見つけ、文脈を見て直す手順を加えました。推敲の結果が変わるバージョンです。

• 直訳語（機械やシステムが人の動作をする言い方、実物の代わりの場所のたとえ、英語を一語ずつ写した句）は、型で拾うのが主です。プロジェクトの語の一覧（.yomiyasu-words/ の allow.txt と flag.txt）の役目は、誤った指摘を外すことと、プロジェクトの事情を足すことです。
• 指摘はどれも info です。指摘が出ただけでは直さず、文脈を見て、誰が何をどうするかを書き直します。指摘の出た語を別の語に差し替えるだけでは済ませません。書き直しに要る名前や動作が原文にないときは、本文を残して書き手に確かめます。
• 指摘を出す型は、直訳語（calque）、見出しと1行目の比喩ラベル（metaphor_label）、「〜と言えるでしょう」（say_hedge）、中身の薄い評価の文（thin_evaluation）、意味の薄いカタカナ語（katakana_term）、キャッチコピーの読点（copy_comma_noun）、主語も目的語もない他動詞の並び（bare_verb_chain）、語の一覧の flag.txt の語（project_term）です。台詞の句点（dialogue_period）は台詞・脚本、一人称と数字（narrative_density）はエッセイを指定したときだけ、文書に1件の指摘として出します。
• 文書の種類に台詞・脚本（script）を足しました。台詞の最後の「。」だけを外し、台詞の口調と言い回しは直しません。

2.3.0 で加わったこと

他動詞の連用形を1語だけ名詞にした語を「の」で受ける形（「結果の確かめ」「二つの案の比べ」）を、lint の指摘（renyo_noun、info）で見つけ、動詞の文か定着した漢語の名詞に直す手順を加えました。日本語では使いにくい形で、漢語を避けて和語で書くと出やすくなります。日本語の連用形名詞についての研究（蔡盛植「日本語動詞連用形への構文論的アプローチ」日本研究 第21集、2014）の線引きで、複合語（資金集め）、複合動詞から来た語（見直し）、「お」を付けた形（お選び）、別の意味で定着した語（住民票の写し）には指摘を出しません。人のニュース記事約900万字では、指摘は0件でした。

2.4.0 で加わったこと

英語の短い術語に漢字1字を当てた名詞（「今回の版」の version、「一覧の頭」の head、「lint の印」の mark）を lint の直訳語の型4（calque、info）で見つけ、その分野で使う呼び名（バージョン、先頭、指摘）に直す手順を加えました。何を指すかが分からないときは、本文を残して書き手に確かめます。出版物の版、記号の印、体の頭には指摘を出しません。人のニュース記事約900万字では、指摘は0件でした。

• 原文にない人や担当を、主語として、または知らせる・頼む相手として足した文は、diff の「原文にない人や担当を足した文」の節に出ます。資料を --material で渡すと、資料にある人や担当は出しません。意味が変わる恐れと --fail-on には数えません。
• yomiyasu の文書と検査の出力の言葉を直しました。検査が出す「印」は「指摘」に（「残した印の語」は「残した指摘の語」）、文の中の語や記号を指す「印」は別の語にしました。「文の種類の印」は「文の種類を表す語」、「引用の印」は「引用の書き方」、「概数・範囲の印」は「概数・範囲を表す語」、「太字の印」は「太字の記号」、「消えた印」「増えた印」は「消えた語」「増えた語」です。「見出しの段」は「見出しのレベル」に、ソフトウェアの「版」は「バージョン」にしました。JSON のキー、規則の名前、状態の値は変えていません。
• スライドの見出しと1行の箇条の、間を作るだけの読点（文頭の「だから、」、長い場面の句、短い主題や主語のあと）を、--doc-type slides のときだけ lint の指摘（slide_comma、info）で示し、推敲で外します。逆接、条件、理由、名詞の並びの読点は残します。
• Codex 向けの入れ方のコマンドを、前のフォルダを消さずに移してから入れ直す形にしました。

Before → After 例

2.0.0 のスキルで AI の文章を推敲した例です。Claude Code（Claude Opus 5.5）に「draft.md を yomiyasu で読みやすくして、結果を out.md に書いてください。」とだけ頼み、1回目の出力をそのまま載せています。

例1: 業務・仕様解説

Before

ここで重要なのは、単なるパーツの共通化ではなく、組織の意思決定OSとしてのガバナンスです。

従来の開発では、画面ごとに手触り感を探りながらパーツを作っていました。しかし、片方だけを見て画面を作ると、もう片方のアクセシビリティが静かに壊れます。そこでデザインシステムという強固な土台を置くことで、開発者の解像度が一段上がります。

デザインシステム導入のメリットは、主に次の3点です。

- 開発速度の加速: コンポーネントを再利用することで、時間を溶かさずに済みます。

- 仕様の収斂: 判断に迷うスタイルは、あらかじめ共通側に倒します。

- アクセシビリティの担保: ガイドラインが規律を要求するため、事故を未然に防ぐことができます。

もちろん、これは「デザイナーが不要になる」ことを意味しません。日々の開発に地味に効いてきます。ぜひ参考にしてみてください！

After

ここでは、単なるパーツの共通化ではなく組織で意思決定をするときの枠組みとしてのガバナンスが重要です。

従来の開発では、画面ごとに操作感を探りながらパーツを作っていました。しかし、片方だけを見て画面を作ると、もう片方のアクセシビリティが気づかないうちに損なわれます。そこでデザインシステムをしっかりした基本として用意すると、開発者の理解が一段深まります。

デザインシステム導入のメリットは主に次の3点です。

- コンポーネントを再利用することで開発が速くなり、時間を無駄にせずに済みます。

- 判断に迷うスタイルはあらかじめ共通のものに統一し、仕様をそろえます。

- ガイドラインが規律を求めるため、アクセシビリティを保ち、事故を未然に防ぐことができます。

もちろん、これは「デザイナーが不要になる」ことを意味しません。日々の開発に目立たないながらも役立ってきます。ぜひ参考にしてみてください。

変更説明

例2: 技術解説

Before

非同期処理における最大の落とし穴は、ネットワークの瞬断です。

依存構造は分割できない。動かしながら引き返す。

単にメッセージを流すだけでは、背後でデータが静かに壊れます。前提を、経路が代わりに添えてくれるわけではありません。

そこで地味に効いてくるのが、以下の3つの原則です。

- 冪等性の担保: 重複した処理は黙ってスキップします。

- 安全なリトライ: 指数バックオフを挟むことで、DBの負荷を逃がします。

- DLQへの退避: 破綻したメッセージは隔離し、原因を1つずつ潰していきます。

デバッグで丸一日時間を溶かさないためにも、この境界線を意識した設計が不可欠です。いかがでしたでしょうか。

After

非同期処理における最大の落とし穴は、ネットワークの瞬断です。

依存構造は分割できない。動かしながら引き返す。

単にメッセージを流すだけでは、気づかないうちにデータがおかしくなります。経路が前提を代わりに添えてくれるわけではありません。

そこで目立たないながらも役立つのが、以下の3つの原則です。

- 冪等性の担保: 重複した処理は表に出さずにスキップします。

- 安全なリトライ: 指数バックオフを挟むことで、DBの負荷を逃がします。

- DLQへの退避: 破綻したメッセージは隔離し、原因を1つずつ取り除いていきます。

デバッグで丸一日を無駄にしないためにも、この境界線を意識した設計が不可欠です。

変更説明

1.1.2 までの README に載せていた After は、原文にない内容（例1の「高品質な行政サービス」、例2の「サーバーの再起動」）を足していました。2.0.0 は原文から決められない所の多くを作り足さずに残すので、After の変化は小さくなっています。ただし例1の意思決定OSは書き手に尋ねずに読みの1つを選んで言い換えています。

インストール

1. npx skills add（推奨）

# 新規インストール
npx skills add nanaism/yomiyasu
最新版へのアップデート
npx skills update yomiyasu

Claude Codeなどのエージェントの設定ディレクトリへ、スキルをインストール・更新します。スキル定義は skills/yomiyasu/SKILL.md の1か所に配置しています。

2. gh skill install

GitHub CLIの gh skill コマンドからインストールできます。

# 新規インストール
gh skill install nanaism/yomiyasu yomiyasu
最新版へのアップデート
gh skill update yomiyasu

導入先のエージェントを指定する場合は、--agent codex や --agent claude-code を追加してください。

3. npx openskills install

# 新規インストールとAGENTS.mdへの反映
npx openskills install nanaism/yomiyasu
npx openskills sync
最新版へのアップデートとAGENTS.mdへの反映
npx openskills update yomiyasu
npx openskills sync

AGENTS.mdを経由して各エージェントから利用できるようになります。過去にネストされたパスを明示してインストールした環境では、スキルが自動では配置し直されません。その場合は、元のインストール先やオプションに合わせて npx openskills install nanaism/yomiyasu を実行し直してから、更新や同期をしてください。

4. Claude Code プラグイン

/plugin marketplace add nanaism/yomiyasu
/plugin install yomiyasu@yomiyasu

Claude Code にプラグインで入れたスキルは yomiyasu:yomiyasu という名前になります。名前で呼ぶときは、スラッシュの補完に出るとおり yomiyasu:yomiyasu と書いてください。yomiyasu とだけ書くと「Unknown skill」になり、スキルを読み込まないまま文章を書いたという報告があります（スキルの名前）。

導入済みのプラグインを最新版へ更新する場合は、ターミナルで次のコマンドを実行します。

# マーケットプレイスの情報を更新
claude plugin marketplace update yomiyasu
プラグインを最新版へ更新
claude plugin update yomiyasu@yomiyasu

更新を反映するには、Claude Codeを再起動してください。

5. ZIPファイルからの登録（Claude.ai Web版など）

Claudeのカスタムスキル登録機能（Web版など）には登録専用のZIPを使ってください。GitHubの「Download ZIP」で取得したリポジトリ全体のZIPにはプラグイン設定や開発用ファイルも含まれ、登録できない場合があります。専用のZIPにはスキル本体、参照文書、検査スクリプト、ライセンスだけを入れています。

1. 以下のリンクから、登録専用のZIPファイルをダウンロードします。

1. ダウンロードした yomiyasu.zip を解凍せず、Claudeのスキル登録画面にそのままアップロードしてください。

6. Codex で使うリポジトリに置く（Codex Cloud など）

Codex は作業するリポジトリの .agents/skills/ の下に置いたスキルを読みます。上の入れ方を使わない場合や Codex Cloud で開く場合は、このリポジトリの skills/yomiyasu/ フォルダを中身ごと、作業するリポジトリの .agents/skills/yomiyasu/ にコピーしてください。作業するリポジトリの直下で、次のコマンドをまとめて貼って実行します。入れ直すときも同じコマンドです。

(
  set -e
  tmp=$(mktemp -d)
  trap 'rm -rf "$tmp"' EXIT
  git clone --depth 1 https://github.com/nanaism/yomiyasu "$tmp/yomiyasu"
  mkdir -p .agents/skills
  if diff -r "$tmp/yomiyasu/skills/yomiyasu" .agents/skills/yomiyasu >/dev/null 2>&1; then
    echo "Already up to date: .agents/skills/yomiyasu"; exit 0
  fi
  if [ -e .agents/skills/yomiyasu ] || [ -L .agents/skills/yomiyasu ]; then
    backup=.agents/yomiyasu.bak-$(date +%Y%m%d-%H%M%S)
    if [ -e "$backup" ]; then echo "$backup already exists. Run this again in a second." >&2; exit 1; fi
    mv .agents/skills/yomiyasu "$backup"
    echo "Moved the previous folder to $backup"
  fi
  cp -R "$tmp/yomiyasu/skills/yomiyasu" .agents/skills/yomiyasu
  echo "Installed .agents/skills/yomiyasu"
)

このコマンドは最新版を一時フォルダに取り出してから .agents/skills/yomiyasu/ にコピーし、最後に一時フォルダを消します。前の .agents/skills/yomiyasu/ があって中身が最新版と違うときは、消さずに .agents/yomiyasu.bak-日付-時刻/ に移してからコピーします。中身が最新版と1字も違わなければ、何も変えません。入れたあとにフォルダの中のファイルが変わったり増えたりしたとき（Finder の .DS_Store など）は、同じバージョンでも移します。取り出しに失敗したときは、前のフォルダをそのままにして止まります。移したフォルダの置き場所は、Codex がスキルを探す .agents/skills/ の外です。新しいバージョンに入れ直すたびに、移したフォルダが1つ増えます。

コマンドが英語で出す文は、Installed .agents/skills/yomiyasu が入れ終えたこと、Moved the previous folder to … が前のフォルダを移した先、Already up to date: .agents/skills/yomiyasu が中身が最新版と同じで何も変えなかったことを表します。… already exists. Run this again in a second. が出たら、同じ名前の移し先がすでにあるので、1秒おいてからもう一度実行してください。

前のフォルダに戻すときは、入れたフォルダを消して、移したフォルダを元の名前に戻します。20261024-153000 は、移したときに表示された名前に替えてください。

rm -rf .agents/skills/yomiyasu
mv .agents/yomiyasu.bak-20261024-153000 .agents/skills/yomiyasu

移したフォルダは git に入れず、要らなくなったら消してください。

この置き方では Codex がスキルを yomiyasu:yomiyasu という名前で一覧に載せます。呼ぶときは「/yomiyasu」とだけ送るか、依頼の文に「yomiyasu で」と書いてください。一覧の名前どおり $yomiyasu:yomiyasu と書いても呼べます。コピーしたフォルダは自動では新しくなりません。最新にするには、同じコマンドをもう一度実行してください。

スキルのフォルダの中を書き換えたとき

入れたスキルのフォルダの中のファイルを書き換えても、入れ方によっては、更新するとフォルダの中身が入れ替わり、書き換えた所が残りません。プロジェクトに合わせた語や使い方の決まりは、スキルのフォルダの外の .yomiyasu-words/、CLAUDE.md、AGENTS.md に書いてください。

本体を入れられない環境では

SKILL.md の字数やファイルの数に上限がある環境や、スキルを読み込めず指示欄に貼るしかないAIのために、本体を短くしたものを2つ、別のリポジトリで公開しています。本体を読み込める環境では、本体をおすすめします。

• yomiyasu-mini: SKILL.md を18,000字以下にしたスキルです。Microsoft 365 Copilot の宣言型エージェントのように、スキルの大きさに上限がある環境向けです。意味が変わる恐れの検査（本体の diff と同じ結果）を含みます。
• yomiyasu-pocket: AIの指示欄に貼って使う、400〜500字の指示文です。メールの作成画面のAIやチャットのカスタム指示のように、スキルを読み込めない所向けです。スキルの仕組みと検査は使いません。

他の日本語校正スキルとの干渉について

他の日本語校正スキルと併用すると、指示が食い違う場合があります。出力が乱れる場合は、類似スキルを一時的に無効にして使用してください。

使い方

AIチャットやコーディングエージェントに下書きを貼り付けて、次のように指示します。

この文章を yomiyasu で読みやすくして。
（ここに修正したい文章を貼り付け）

このように依頼の文に名前を書いたとき、「/yomiyasu」と送ったとき、「日本語を推敲するスキルを使って」のようにスキルでの推敲をはっきり頼んだときに、yomiyasu が使われます。名前を出さずに「読みやすくして」とだけ頼むと、エージェントは yomiyasu を使わずに直します。

「/yomiyasu」とだけ送ると、yomiyasu は直前の返答でAIが書いた本文か、作業フォルダの直下に1つだけある原稿（.md か .txt）を推敲します。原稿のファイルは書き換えず、最終稿を同じフォルダに別の名前で保存します。

毎回 yomiyasu を使いたいとき

AI が書いたり直したりする日本語をいつも yomiyasu に通したいときは、エージェントが毎回読む指示のファイルに、入れ方ごとに下に示す1行を足してください。1行に書くスキルの名前は入れ方によって yomiyasu と yomiyasu:yomiyasu に分かれます。

Claude Code

npx skills add や gh skill install でスキルとして入れた場合は、スキルの名前が yomiyasu なので、次の1行を書きます。

記事、ドキュメント、PR の説明文、コミットメッセージなどの日本語の文章を書いたり直したりするときは、常に yomiyasu スキルで推敲してください。コードを直したあとの作業の報告には使わなくてかまいません。

プラグインで入れた場合は、スキルの名前が yomiyasu:yomiyasu になるので、1行の中の yomiyasu を yomiyasu:yomiyasu に書き換えてください。

1つのリポジトリだけで使うならそのリポジトリの直下の CLAUDE.md に、すべてのリポジトリで使うなら ~/.claude/CLAUDE.md に書きます。書いたあとに始めた会話から有効になります。

この1行があると、名前を出さずに記事や PR の説明文、コミットメッセージ、翻訳を書かせたときも、エージェントは yomiyasu で推敲します。コードを直したあとの作業の報告まで推敲させたいときは、「日本語の文章を書いたり直したりするときは、常に yomiyasu スキルで推敲してください。」とだけ書きます。プラグインで入れた場合は、こちらも yomiyasu を yomiyasu:yomiyasu に書き換えてください。

Codex

npx skills add や gh skill install で入れた場合も、作業するリポジトリの .agents/skills/ に置いた場合も、スキルの名前は yomiyasu:yomiyasu です。スキルのフォルダに Codex 用のプラグインの設定 .codex-plugin/plugin.json が入っているためです。次の1行を書きます。

記事、ドキュメント、PR の説明文、コミットメッセージなどの日本語の文章を書いたり直したりするときは、常に yomiyasu:yomiyasu スキルで推敲してください。コードを直したあとの作業の報告には使わなくてかまいません。

1つのリポジトリだけで使うならそのリポジトリの直下の AGENTS.md に、すべてのリポジトリで使うなら ~/.codex/AGENTS.md（CODEX_HOME を設定しているときはその場所の AGENTS.md）に書きます。書いたあとに始めた会話から有効になります。

コードや設定を直したあとの報告まで推敲させたいときは、「日本語の文章を書いたり直したりするときは、常に yomiyasu:yomiyasu スキルで推敲してください。」とだけ書きます。この書き方にすると、Codex は変数の名前を変えるだけの作業でも、最後の報告を書く前に yomiyasu を読みます。

npx openskills install で入れたとき

openskills はスキルの一覧を AGENTS.md に書き込み、エージェントは npx openskills read yomiyasu でスキルを読みます。この入れ方でのスキルの名前は yomiyasu です。npx openskills sync は AGENTS.md の から までを書き直すので、1行はその外に書いてください。

記事、ドキュメント、PR の説明文、コミットメッセージなどの日本語の文章を書いたり直したりするときは、常に yomiyasu スキルで推敲してください（npx openskills read yomiyasu で読み込みます）。コードを直したあとの作業の報告には使わなくてかまいません。

更新したら、npx openskills update yomiyasu のあとに npx openskills sync も実行してください。スキルの description は sync のときに AGENTS.md に写されるので、sync するまで、エージェントは更新する前の description をもとに yomiyasu を使うかどうかを決めます。

openskills は既定でスキルをプロジェクトの .claude/skills/ に置くので、Claude Code はこのスキルを yomiyasu という名前で直接読みます。この場合は Claude Code の節の1行を、そのまま CLAUDE.md に書いてください。

Claude.ai

ZIP で登録したスキルの名前は yomiyasu です。すべての会話で使うなら設定（Settings）の「Instructions for Claude」に、1つのプロジェクトだけで使うならそのプロジェクトの指示（project instructions）に、次の1行を書きます。どちらの置き場所も Claude のヘルプの Understanding Claude's personalization features に書かれています。

日本語の文章を書いたり直したりするときは、常に yomiyasu スキルで推敲してください。

文書の種類と読者

文書の種類と読者は依頼の中で伝えられます。伝えなければ、スキルが本文の形から推定します。

この障害報告を yomiyasu で、専門知識のない社外の利用者向けに読みやすくして。
（ここに修正したい文章を貼り付け）

その種類で普通の書き方（表の右の列）は直しません。値は付属ツールの --doc-type に渡すものと同じです。

| 値 | 種類 | 直さない書き方の例 | |---|---|---| | pr | PR説明 | 変更点の箇条書き | | article | 技術記事 | なし | | incident | 障害報告 | 時系列の箇条書き、発生・復旧などの報告の語 | | proposal | 提案書 | なし | | minutes | 議事録 | 箇条書き、「〜しました。」の連続、「〜とのこと」 | | manual | マニュアル | 番号つきの手順 | | slides | スライド | 箇条書き、体言止めの項目、箇条の「〜のは、A、B、C」 | | essay | エッセイ・小説 | 読み取れる比喩 | | formal | 公用文、規程、契約書、仕様書 | 正式な語としての漢語、「〜を行う」 | | promo | 紹介記事・宣伝文 | 見出しのキャッチコピー、「！」、絵文字 | | mail | メール・チャット | 宛名、挨拶、結び、署名、クッション言葉 | | paper | 論文・研究レポート | 慎重な言い方、専門用語、「である」調 | | script | 台詞・脚本 | 台詞の口調と言い回し、台詞の中の文と文の間の「。」、ト書き |

読者の知識は3段階です。同じ分野の専門家（expert）には用語を残し、分野は違うが技術に詳しい人（informed）か専門知識のない人（general）を指定したときだけ、原文と資料にある説明で言い換えるか、説明を添えます。説明がどこにもない語には説明を作らず、書き手に確かめたい点として返します。

書き手と読み手

書き手の立場と読み手との関係（上司、同じチーム、取引先、お客さまなど）を依頼の中で伝えると、yomiyasu はその関係に合わせて本文を直します。

draft.md を yomiyasu で読みやすくしてください。取引先の購買の担当者に送るメールです。

上司や社外の相手への依頼は「ご確認ください」「お知らせください」のように、その関係で人がふつう書く敬語にします。書き手が自分でした行為で、ほかの人の行為と読み違えやすい文には、原文にある「私」「弊社」などを主語に補います（原文に一人称がなければ補いません）。頼む中身、期限、選択肢は変えず、担当者やお詫びの文も足しません。関係を伝えなければ、本文の敬語は変えません。

文脈から事実を補う

原稿に抜けた数値や条件があると、yomiyasu は原文、依頼、渡された資料、利用者の発言、開いたファイル、コマンドの出力から、同じことを述べた文を探します。根拠の文が見つかったときだけ確度を変えずに補い、見つからなければ本文はそのままにして、読み手が動けなくなる所だけを元の書き手への問いにします。AI 自身の発言や一般の知識は根拠にしません。

書いた日が確かに分かれば、「昨日」のような言い方に括弧で日付を添えます（昨日（10月15日））。

完了報告

yomiyasu は推敲した本文のあとに、変えたところと確認の記録を付けます。「残したAIっぽいところ」「書き手に確かめたい点」「事実の確かめ」が付くのは、書くことがあるときだけです。確認の記録には実行した検査と、yomiyasu_check.py の状態の行（yomiyasu-check: で始まる行）を写します。本文だけを返すよう頼めば、説明の欄は省きます（検査は同じように行います）。

書く前に読ませる使い方

推敲だけでなく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つの試験の結果です。記事では、この使い方は数字や日付、条件を正確に伝えたい文章（営業メール、障害報告書、手順書など）に向くとしています。エッセイや告知のような読み物には何も付けずに書かせるか、依頼に一言添えるほうが向くという結論です。

2.0.0 で資料から新しく書かせると、yomiyasu は付属の検査で最終稿の数値や名前を資料と照らし合わせ、資料にないものを見直し候補として出します。2.0.2 からは名前を出さずに書かせると yomiyasu は使われません。資料から書かせるときも「notes.md をもとに記事を書いて、最後に yomiyasu で推敲して」のように、依頼に名前を入れてください。

種類ごとの決まり、敬語の上げ方、事実を補う決まり、完了報告の欄の詳しい説明は docs/usage.md にまとめています。

付属ツール

文章の表現と書式を見る yomiyasu_lint.py、推敲の前後を比べる yomiyasu_diff.py、2つをまとめて実行して記録を残す yomiyasu_check.py を同梱しています。設定に貼ったときだけ動く任意のフック yomiyasu_hook.py もあります。どれも外部ライブラリは要らず、Python の標準ライブラリだけで動きます（テストは Python 3.9 と 3.14 で実行しています）。

検査は見直し候補と変わった箇所を出すだけで、意味が保たれたかどうかや、読みやすいかどうかは判定しません。候補が出た所を直すかどうかは、元の文や文脈と照らし合わせて決めてください。

1. yomiyasu_lint.py（表現と書式の検査）

1つの文章について、不自然な比喩動詞、決まり文句、過剰な太字や箇条書き、絵文字、文末コロン、表示されない太字などを、見直し候補として行ごとに出します。2.0.0 からは通常の出力に点数を出しません。点数が読みやすさの合格点のように見えてしまうためです（点数が出なくなった理由）。

# Markdownファイルを検査
python3 scripts/yomiyasu_lint.py article.md
warn か error の候補があれば終了コード1を返す（CIやGitフック用）
python3 scripts/yomiyasu_lint.py article.md --fail-on warn
文書の種類を指定（その種類で普通の書き方を候補から外す）
python3 scripts/yomiyasu_lint.py minutes.md --doc-type minutes
JSON形式で結果を出力
python3 scripts/yomiyasu_lint.py article.md --json

2.0.0 で --json の点数のキーを score から rule_penalty_score に、候補の有無のキーを is_clean から no_rule_findings に変えました。前の名前のキーは残していないので、jq .score のように前の名前で読むと null になります。rule_penalty_score は計算も変えたので、score に使っていたしきい値はそのまま使えません。どちらの形式の JSON かは format_version で見分けられます（2.0.0 からは2で、1.1.2 までの JSON にはこのキーがありません）。jq での読み替えの例は JSON を前のキーの名前で読んでいたとき にあります。

プロジェクトの語の一覧

git の最上位（git の外では作業ディレクトリ）に .yomiyasu-words/ を置き、allow.txt（直さない語）と flag.txt（指摘を出して見直す語）に1行に1語ずつ書くと、lint、diff、check、フックが同じ一覧を読みます。# で始まる行と空の行は読み飛ばします。allow.txt の語は、直訳語などの指摘と、比喩動詞、直訳の語、決まり文句の候補から外れ、外した件数が出力と JSON（context.words）に出ます。flag.txt の語には project_term の指摘が出ます。リポジトリに入れてチームで共有する前提のファイルで、状態フォルダ .yomiyasu/ とは別の場所に置きます。--words フォルダ で場所を指定でき、--no-words を付けると読みません。詳しくは docs/tools.md にあります。

出力例

表現・書式の検査を実行しました。
見直し候補: 1件
この検査では、意味の保持と読者にとっての分かりやすさは判定していません。
内訳: error 0件、warn 1件、info 0件
L1 [WARN] metaphor_verb: 比喩動詞「壊れる」が検出されました。不自然な比喩動詞であれば、ふだん使う動詞や客観的な表現に書き直してください。ただし、文字どおりの動作や状態変化を表している場合は無理に言い換える必要はありません。
  > 単にメッセージを流すだけでは、背後でデータが静かに壊れます。

2. yomiyasu_diff.py（推敲の前後の比較）

推敲の前と後を比べ、変わった箇所をすべて出します。数値、否定、「が」「を」の入れ替え、文の種類（伝聞、推量、依頼など）が変わった所は、意味が変わる恐れとして先に示します。原文にない人や担当を、主語として、または知らせる・頼む相手として足した文も、別の節にまとめて示します（2.4.0 から）。

# 原文と推敲後を比べる
python3 scripts/yomiyasu_diff.py 元の文.md 書き直した文.md
数値・否定・入れ替え・文の種類の変化があれば終了コード1を返す
python3 scripts/yomiyasu_diff.py 元の文.md 書き直した文.md --fail-on=meaning-risk

出力例

「田中が佐藤を承認した。」と「設定は3日ごとに保存します。」の2つの段落を、「佐藤が田中を承認した。」と「設定は30日ごとに保存しません。」に書き換えると、次のように出ます。

差分の検査を実行しました。
状態: 変更あり（2か所）。見直し候補 3件、うち意味が変わる恐れ 3件
全文差分は変わった箇所を示すだけで、意味が同じだという証明ではありません。この検査では、意味の保持と読者にとっての分かりやすさは判定していません。
■ 意味が変わる恐れ（3件。原文と資料に照らして確かめる）
「が」「を」などが入れ替わった（1行目）: 田中 が→を、佐藤 を→が
  元: 田中が佐藤を承認した。
  後: 佐藤が田中を承認した。
数値が変わった（3行目）: 3日 → 30日
  元: 設定は3日ごとに保存します。
  後: 設定は30日ごとに保存しません。
否定の有無が変わった（3行目）: 保存します → 保存しません
  元: 設定は3日ごとに保存します。
  後: 設定は30日ごとに保存しません。
（このあとに全文差分が続きます）

3. yomiyasu_check.py（検査をまとめて実行して記録を残す）

最終稿に lint を、原文と最終稿に diff をまとめて実行し、記録を残します。スキルは書き直したあとに run を実行し、返す直前に verify で、最終稿が検査したものと同じかを記録と照らし合わせます。

# 原文と最終稿を検査する（資料があれば --material 資料 を足す）
python3 scripts/yomiyasu_check.py run --source 原文.md --final 最終稿.md --doc-type article
返す直前に、最終稿が検査したものと同じかを記録と照らす
python3 scripts/yomiyasu_check.py verify --final 最終稿.md

推敲の前と後を比べるときは、run の出力の「見直し候補: 原文 N件 → 最終稿 M件」の行と、そのすぐ下の「■ 直した箇所」に並ぶ元と後を読んでください。候補があるときは、出力の4行目に候補の短

... (README truncated for length)