yomiyasuをClaudeの作文に使うと？v1.1.1の変更点と4通りの比較

yomiyasu（よみやす）は、AIが書いた日本語の不自然な言い回しや飾りを直すAgent Skillです。最新版のv1.1.1が、2026年10月9日に公開されました。10月11日の時点で、GitHubのスターは1,834です。

READMEにある使い方は、書き上がった文章を貼り付けて「読みやすくして」と頼む形です。では、Claudeに文章を書かせる段階でyomiyasuを読ませたら、仕上がりはどう変わるのでしょうか。

この記事では、v1.1.1の変更点と、v1.1.0で気になった点が直ったかをまず確かめます。そのうえで、Claude Opus 5.5に同じメモから文章を書かせ、yomiyasuの使い方を変えた4通りを比べました。インストール方法と、v1.0.0からv1.1.0までの推敲の比較は、前回の記事にまとめています。

v1.1.1の変更点

v1.1.1は、日本時間の10月9日18時48分に公開されました。リリースノートに書かれた変更は、次の7つです。

• ダッシュ：ダッシュや罫線を見直す対象に加え、列挙を「──」で閉じる形も個別に示すようにしました。コードや表、区切り線、出典の表記は残します。
• 用語：「ゲート」「台帳」や、ソフトウェアの「版」「回帰」などを、実際の役割や定着した用語で書く指針を加えました。
• 決まった形の言い回し：決まった形の導入と結び、評価の語だけの短い文、本文を繰り返すだけの「まとめ」を見直す指針を加えました。
• 意味を保つ条件：「AではなくBでもある」の否定と「も」を、一つの文のまま保つ条件を書き足しました。短い「もちろん、」で先回りして認めるだけの文を見直す指針も加わりました。
• 見出しと記号：見出しを短くしても、書き手の評価や態度、見出しの番号は残すようにしました。原文の「■」「・」を、一律にMarkdownの記号へ変えない条件も加わっています。
• 空欄の扱い：提出や共有をする文の空欄は、原文や依頼に値が書かれている場合だけ埋める指針を加えました。
• 検査の速さ：付属のチェック用プログラムの処理を見直しました。特定の負荷をかけた試験では、全文の検査にかかる時間が99.0%短くなったとしています。ふつうの文書では、v1.1.0とほぼ同じ速さです。

AIが読むルールの量も増えました。SKILL.mdと参照ファイルを合わせた大きさは、v1.1.0の約14万6千バイトから、v1.1.1では約17万2千バイトになっています。

v1.1.0で気になった点の再確認

前回の記事では、v1.1.0で気になった点をいくつか挙げました。v1.1.1のSKILL.mdには、そのときの例と同じ語句が、指針の例として入っています。エッセイの「弱みではなく、視点の違いでもある」、見出しにだけあった「思い切って」「意外と効いた」、「3つの工夫」の見出し番号、Slackの告知の「■」です。

そこで、同じ文章をv1.1.0とv1.1.1で3回ずつ直してもらい、結果を比べました。推敲役は前回と同じClaude Sonnet 5.5で、頼み方も前回と同じです。見出しを試す文章は前回のものが残っていなかったため、同じ型の文章を作り直しました。

Slackの告知では、v1.1.0が3回中2回で「■ 導入の目的」を「## 導入の目的」に、「・」の箇条書きを「- 」に変えました。v1.1.1は3回とも、「■」と「・」を原文のまま残しました。変えたのは、絵文字や「！」を外すことと、題名や一部の言い回しを整えることでした。

見出しは、どちらも3回とも「アラート数の削減」のような短い項目名に直しました。違いは、見出しから外した言葉の行き先です。v1.1.1は3回とも「最初に、アラートの数を思い切って減らすことにしました。」のように、「思い切って」と順序を表す言葉を本文に残しました。v1.1.0は3回中2回で、「思い切って」と「次に」「これから」が本文から消えています。「意外と」は、どちらも3回とも本文に残りました。

技術ブログの見出し番号は、どちらも3回中1回で外れました。この点は、今回の3回では変化がありませんでした。

エッセイの「弱みではなく視点の違いでもある」は、今回はv1.1.0でも3回とも保たれました。前回見つけた意味の反転は、毎回起きるものではなかったようです。v1.1.1では、この書き換えをSKILL.mdが例を挙げて禁じています。

4通りの書かせ方

ここからが本題です。Claude Opus 5.5に、8種類の文章のメモを渡して書かせました。営業メール、社内Slackの告知、技術ブログ、提案書、noteのエッセイ、障害報告書、社内向けの手順記事、セミナーの告知です。メモは数字や日付、名前を入れた箇条書きで、私が書きました。

書かせ方は、次の4通りです。

8種類を2回ずつ書かせたので、書かせ方ごとに16本です。採点は、Claude Opus 5.5とGemini 3.8 Flashの2つのAIに任せました。メモと4つの文章を読み比べて4項目を5点満点で採点し、使う順に並べてもらっています。どの文章がどの書かせ方かは伏せ、並び順を変えて2回ずつ採点しました。

採点の結果

1位は、2つのAIが使う順に並べたときに1位にした回数です。追加の指摘は、採点したAIが「メモにない説明や依頼、曜日などが足されている」と書いた回数を数えました。どちらも64回の採点のうちの回数です。

いちばん差が開いたのは、メモの情報の正確さです。yomiyasuを先に読ませた文章は、2つのAIの採点64回すべてで5点でした。ほかの3通りは、どれも3点台です。

ただ、どの書かせ方がいちばん良いかは、採点したAIによって分かれました。Claude Opus 5.5は、一言添えた文章を32回中18回で1位にしています。Gemini 3.8 Flashは、yomiyasuを先に読ませた文章を32回中10回で1位にした一方、順位の平均では素で書かせた文章を最も上に置き、一言添えた文章を最も下に置きました。同じ並び順の採点で2つのAIの1位が一致したのは、32回中13回です。

書く前に読ませた文章

yomiyasuを先に読ませると、Claudeはメモにないことをほとんど書かなくなりました。採点したAIがメモにない内容の追加を指摘したのは、64回のうち2回です。1回は日付に曜日を添えたこと、もう1回は「検索結果をそのまま使っていた」という軽い推測でした。

日付に曜日を添えた文章は、yomiyasuを先に読ませた16本では1本でした。素で書かせた16本では5本、一言添えた16本では4本です。足された曜日はどれも暦どおりで、誤りはありませんでした。

意味の保ち方にも差が出ました。提案書のメモには「いちばんの課題は人手不足ではなく、確認作業が特定の担当者にしかできないこと」と書きました。yomiyasuを先に読ませた文章は、2回ともこの否定をそのまま残しています。一言添えた文章は2回とも「作業量そのものではありません」と、打ち消す対象を作業量に変えました。素で書かせた文章も、2回中1回で同じように変えています。

その代わり、文章は短くなりました。依頼は500字程度でしたが、平均は356字です。社内Slackの告知は268字と273字で、メモの項目を「■」の見出しで並べた事務的な文章になりました。採点したClaude Opus 5.5は、冒頭の挨拶と結びがなく素っ気ないと指摘しています。

エッセイでは、8回の採点すべてで最下位でした。メモにない体験や気持ちを足さないため、メモの項目を順に文にしたような文章になります。結びは2本とも、「これからは、現場の声を開発チームに届けたい。」の一文だけでした。

メモに忠実すぎて不自然になった例もあります。提案書の1本は、「従業員300人の部品メーカーである貴社では、受発注データを手作業で転記しています。」と書き出しました。メモにあった相手の会社の説明を、そのまま相手に向けて書いた形で、2つのAIがどちらも不自然だと指摘しています。

yomiyasuを先に読ませた文章の順位が高かったのは、営業メールと手順記事、障害報告書でした。16回の採点の順位の平均は、営業メールが1.75、手順記事が2.12で、どちらも4通りの中で最も高くなっています。障害報告書は2.0で、書いた後に直した文章の1.75に次ぐ2番目でした。どれも、数字や日付、条件を正確に伝えることが大事な文章です。

一言添えた文章

「AIが書いたように見えない、自然で読みやすい日本語で」と一言添えると、AIっぽさの少なさは4.80点、読みやすさは4.73点で、どちらも4通りで最も高くなりました。その代わり、メモにない内容が増えています。

エッセイでは、「席に戻ってからこっそり手帳に書き出して調べた」「あのページは、今見返すと少し恥ずかしい」のような、メモにない場面や気持ちが入りました。読み物としては自然ですが、一人称のエッセイで、書き手が書いていない体験を足したことになります。

社内Slackの告知には、「届いたら、一度ログインできるかだけ確かめておいてもらえると安心です」という、メモにない依頼が入りました。営業メールでは2回とも、メモの「120時間」を「120時間ほど」とぼかしています。正確さの点は3.30点で、4通りで最も低くなりました。

書いた後に直した文章

素で書かせた文章をyomiyasuで直すと、文章はほとんど変わりませんでした。直す前と後の文字の一致度は平均0.98です（1が完全一致）。社内Slackの告知の1本では、変わったのは「新しいツール『精算ナビ』」が「新しい『精算ナビ』」になった1か所だけでした。

付属のチェック用プログラムの点数も、素で書かせた文章の平均96.1点に対し、直した後は95.9点で、ほぼ同じです。Claude Opus 5.5が素で書く文章には、yomiyasuが直す言い回しがもともと少なかった、と考えられます。

素で書かせた文章が足した曜日や説明は、直した後もそのまま残りました。この書かせ方では、直す側はメモを見ていません。どこがメモにない内容なのかを、文章だけからは区別できないためです。

かかった時間と費用

yomiyasuを読ませると、そのぶん読み込む量が増えます。SKILL.mdと参照ファイルを合わせて、1回あたり約5万9千トークンです。

時間と費用は1本あたりの平均で、費用はClaude Codeが表示したAPIの定価での金額です。「書いた後に直す」は直す分だけで、書く分の21秒と0.044ドルは含みません。

yomiyasuを先に読ませたときは、考える量も増えました。考えるのに使った出力は1本あたり平均8,166トークンで、素で書かせたときの1,458トークンの約5.6倍です。Claude Codeを定額のプランで使う場合は、1回ごとの料金はかかりませんが、使える量の上限には早く近づきます。

使い分けの見立て

私の見立てでは、数字や日付、条件を正しく伝えることが大事な文章は、yomiyasuを先に読ませて書かせるのが向いています。営業メールや障害報告書、社内の手順書です。メモにないことを足さないので、確かめる手間が減ります。短くて物足りないところは、自分で書き足せば済みます。

エッセイや告知のように、読み物として肉付けがほしい文章は、素で書かせるか、一言添えて書かせるほうが向いています。ただし、足された体験や依頼、ぼかされた数字は、自分で見つけて消す必要があります。

Claude Opus 5.5が書いた文章を、yomiyasuで後から直す使い方は、今回の結果ではほとんど差が出ませんでした。前回の記事のように、AIっぽい言い回しや飾りの多い文章を直すときのほうが、この使い方は生きると考えています。

Claude Codeでの頼み方

Claude Codeにyomiyasuが入っていれば、「yomiyasuを使って、次のメモをもとに〇〇を書いてください」のように、スキルの名前を出して頼みます。私のClaude Codeで試したところ、名前を出したときはyomiyasuが読み込まれ、名前を出さずに同じ依頼をしたときは読み込まれませんでした（各1回）。yomiyasuは推敲のためのスキルとして説明されているので、書かせるときは名前を出すほうが確実です。

v1.1.1の指針を使うには、入っているyomiyasuを更新します。READMEにある更新の方法は、入れ方ごとに次のとおりです。

• npx skills で入れた場合：npx skills update yomiyasu
• GitHub CLIで入れた場合：gh skill update yomiyasu
• Claude Codeのプラグインで入れた場合：ターミナルで claude plugin marketplace update yomiyasu と claude plugin update yomiyasu@yomiyasu を実行し、Claude Codeを再起動する

試した条件

採点した4項目は、読みやすさ、AIっぽさの少なさ、メモの情報の正確さ、用途に合っているかです。正確さは、メモの情報の抜けや意味の変化、メモにない事実の追加があれば減点するよう頼みました。

この検証の限界

• 8種類の文章を2回ずつ書かせただけなので、文章の種類ごとの結果は2本ずつの比較です。
• 採点は2つのAIによるもので、人による評価ではありません。2つのAIの1位が一致したのは32回中13回で、どの書かせ方が良いかの判断は分かれています。
• 書き手はClaude Opus 5.5だけです。ほかのモデルやeffortの設定では、結果が変わる可能性があります。
• 実際のClaude Codeでは、参照ファイルは必要なときだけ読まれます。今回はすべてを最初から渡しました。
• 「書いた後に直す」では、READMEの使い方に合わせてメモを渡していません。メモも一緒に渡せば、足された内容を消せた可能性がありますが、試していません。
• 名前を出すとyomiyasuが読み込まれるかは、私の環境で1回ずつ試しただけです。

この記事の本文も、yomiyasu v1.1.1のルールに沿って書きました。