話題の日本語推敲スキル「yomiyasu」を中身を読んでから導入した ― NGワードHookとの役割分担まで

私のブログの草稿は Obsidian の Vault の中で Claude Code に書いてもらっています。AIの書いた日本語には独特の言い回しが残るので、2026年8月から、書き込みのたびに「AIっぽいNGワード」を照合する Hook を自作して使ってきました。
そんな中で、AIが生成した日本語を推敲する Agent Skill「yomiyasu(よみやす)」が話題になっていました。良さそうだと思いつつ、他人の作ったスキルをそのまま入れるのは少し怖い。そこで、中身を読んで安全性を確かめ、過去の記事で試してから導入しました。
この記事では導入前に確かめたこと、試した結果、既存の Hook との役割分担をまとめます。
yomiyasu の版や仕様は、執筆時点(2026年10月)のものです。2.0.0 が10月16日、2.0.1 が10月17日に出たばかりで、変更の速いスキルです。
動作環境
| 項目 | 内容 |
|---|---|
| OS | Ubuntu 24.04.5 LTS |
| Claude Code | 2.1.302 |
| Python | 3.12.3 |
| yomiyasu | 2.0.1(コミット 1bc21f9c) |
| 導入先 | ユーザー単位のスキル(~/.claude/skills/yomiyasu) |
yomiyasu とは
ここは README と作者の解説記事からの情報です。
yomiyasu は、AIが生成した日本語の不自然な比喩、曖昧な主述関係、不要な装飾を直すスキルです。対象は技術記事、仕様書、PR説明文、社内レポートなどの実務的な文章で、Claude Code や Codex、Cursor で使えます。ライセンスは MIT です。
README ではこれまでの文体調整のやり方の限界として4点を挙げています。その1つ目が「禁止語の置き換えにとどまる対処」です。禁止語を決めても別の曖昧な語に置き換わるだけで、文の構造は直らない、という指摘です。
READMEを読んで少し苦笑しました。私の自作 Hook はまさにこの禁止語の照合だからです。ただ、Hook には書き込みのたびに自動で走るという強みがあり、捨てる理由にはなりません。この点は後で役割分担として整理します。
yomiyasu の特徴は意味を変えないことを最優先にしている点です。書き直す前に元の文の「主張」「比重」「言い切りの強さ」「文の働き」を確かめ、書き直したあとも同じかを確かめます。2.0.0 からは付属のスクリプトで原文と最終稿を比べ、数値や否定が変わっていないかを検査するようになりました。
導入前に確かめたこと
スキルは AIエージェントに読ませる指示書と、エージェントが実行するスクリプトの組み合わせです。指示書に外部への送信が書かれていたり、スクリプトが勝手に通信したりすれば、Vault の中身が外に出るおそれがあります。そこで、リポジトリを手元に取得し、次の4点を確かめました。
- スクリプトがネットワークに出るか
- どこに何を書き込むか
- 自動で動く仕組み(Hook)を勝手に登録しないか
- 指示書に不審な指示がないか
1. ネットワーク
付属のスクリプトの import を調べました。urllib・requests・socket などの通信用のモジュールはなく、標準ライブラリだけで動きます。subprocess は使っていますが、呼んでいるのは自分の lint と diff のスクリプトでした。
2. 書き込み先
落とし穴は、検査の記録として原文と最終稿の全文が保存されることです。保存先は既定では git の最上位にある .yomiyasu/ です。
yomiyasu は .yomiyasu/ に .gitignore を置くので、git にはコミットされません。ただ、私の Vault は Syncthing で別のPCとも同期しています。このままだと、推敲途中の全文が別のPCにも届きます。
保存先は環境変数 YOMIYASU_STATE_DIR で変えられます。
YOMIYASU_STATE_DIR に ~ を含めると展開されません。スクリプトは作業ディレクトリからの相対パスとして扱うので、~/.cache/yomiyasu と書くと、作業ディレクトリの下に ~ という名前のフォルダができます。絶対パスで書いてください。
3. 自動で動く仕組み
yomiyasu_hook.py という Hook 用のスクリプトが付いています。説明を読むと、利用者が設定ファイルに貼ったときだけ動く任意のもので、インストールで設定を書き換えることはありません。今回は登録しませんでした。
4. 指示書
SKILL.md は362行あり、references/ に文書の種類ごとの指針など約275KB の資料が付いています。URL や認証情報を扱う記述を検索したところ、出てきたのは論文や仕様書の出典と、「認証情報らしいファイル(.env など)は開かない」という指示だけでした。
過去記事に lint をかけてみた
導入する前に、以前公開した記事「コードレビューを通った。それで『合格』なのか?」(約4,000字)の写しに、yomiyasu の lint をかけました。取得したリポジトリのスクリプトを、写しのあるフォルダで実行しています。
python3 scripts/yomiyasu_lint.py --doc-type essay a.md
出力(冒頭):
表現・書式の検査を実行しました。
見直し候補: 14件
この検査では、意味の保持と読者にとっての分かりやすさは判定していません。
文書の種類: エッセイ・小説(essay)、読者: 指定なし。この種類で外す規則はありません。
内訳: error 0件、warn 4件、info 10件
同じ記事に、自作の Hook もかけて比べました。
| yomiyasu の lint | 自作の NGワード Hook | |
|---|---|---|
| 検出数 | 14件(warn 4、info 10) | 2件 |
| 主な内容 | 間を作るだけの読点(info 9件)、「本質的」、「大切なのは」、文末「ます」の3回連続(2か所)、「AではなくB」 | 「AではなくB」の構文、強調語の多用 |
| 候補の書き方 | 直すか残すかの判断基準まで書く | 言い換えの例を示す |
数が多いから優れている、とは考えていません。yomiyasu 自身も「件数は点数ではない」と出力に書いています。違いが出たのは候補の書き方です。たとえば読点の候補には、「読点のあとに別の主語が来る、条件や場面の枠を示す、のどれにも当たらなければ外す。随筆で書き手が間として置いた読点は残してよい」と、残すべき場合まで書かれています。機械的に直すための一覧というより、人やAIが判断するための材料だと感じました。
導入手順
実際に行った手順です。
- リポジトリを取得し、
skills/yomiyasu/を~/.claude/skills/yomiyasuに複製する。取得元のコミットをINSTALLED_FROM.txtに書いておく ~/.claude/settings.jsonに、記録の保存先と、スクリプトの実行許可を足す
{
"env": {
"YOMIYASU_STATE_DIR": "/home/<ユーザー名>/.cache/yomiyasu"
},
"permissions": {
"allow": [
"Bash(python3 /home/<ユーザー名>/.claude/skills/yomiyasu/scripts/yomiyasu_lint.py *)",
"Bash(python3 /home/<ユーザー名>/.claude/skills/yomiyasu/scripts/yomiyasu_check.py *)"
]
}
}
実行許可を足したのは、つまずいたからです。私は Claude Code を自動モードで使っています。導入直後に検査スクリプトを試すと、「外部から取ってきたコードの実行」と判定されて止められました。安全を優先した判定としては筋が通っています。そこで、lint と check の2本だけを、絶対パスを指定して許可しました。
この許可ルールを入れると、スクリプトを差し替えたときも、新しい中身が確認なしで動きます。yomiyasu は更新が速いので、更新するときは差分を読んでから差し替える運用にしています。
設定後に検査を実行すると、記録は ~/.cache/yomiyasu/ に作られ、Vault の中に .yomiyasu/ はできませんでした。
執筆の流れへの組み込み
自作の Hook と yomiyasu は、見ているものが違います。そこで、役割を次のように分けました。
この記事では書いている途中に自動で警告を出す仕組みを見張り、書き終えた原稿を意味を保って直す工程を仕上げと定義します。
| 見張り(自作の NGワード Hook) | 仕上げ(yomiyasu) | |
|---|---|---|
| 動くとき | 草稿を書き込むたびに自動で | 草稿を書き終えたあとに1回 |
| 見るもの | NGワード9種と、太字・接続詞の頻度など4種 | 文の構造、意味の保持、情報の増減 |
| 結果 | 警告だけ(書き込みは止めない) | 推敲した原稿と、変えたところの説明 |
あわせて、見張りの範囲を絞りました。以前は Vault のほぼすべてのノートで警告が出ていましたが、ブログの草稿のフォルダとはてなブログの下書きだけで動くようにしました。調査メモやデイリーノートでまで警告が出ると、かえって作業の妨げになっていたからです。
組み込むときに決めたことは3つあります。
- このブログの書き方は残す: yomiyasu は飾りを減らす方向で直します。一方、このブログでは定義の太字、コールアウト、比較表、執筆時点の注記を意図して使っています。これらは残すよう、推敲のたびに yomiyasu へ伝えます。
- 原稿を増やさない: yomiyasu は既定では、最終稿を原文の隣に別の名前で保存します。草稿のフォルダに原稿が2つ並ぶと紛らわしいので、最終稿は Vault の外で検査まで通し、私が変更点を確認してから元の草稿に反映します。
- 食い違ったときは yomiyasu を優先する: 自作の Hook は「AではなくB」の構文を警告し、肯定文に直すよう求めます。yomiyasu は、誤解を正すなど意味を担っている否定は残します。両方の指摘が食い違ったら、仕上げの判断を優先します。
なお、この記事は yomiyasu を組み込んでから最初に書いた記事です。公開前に yomiyasu で推敲しています。
他人のスキルを入れる前に確かめる4点
今回の確認は、yomiyasu に限らず、外部の Agent Skill を入れるときに使い回せます。
- 通信: スクリプトが通信用のモジュールを使っていないか
- 書き込み先: 何をどこに保存するか。その場所が同期やバックアップの対象になっていないか
- 自動実行: Hook などを勝手に登録しないか
- 実行許可: 許可するなら、パスを絶対パスで固定し、更新のたびに中身を読む
yomiyasu は意味を変えないことを最優先にした、丁寧な作りのスキルだと感じました。自作の Hook の限界を指摘されたような気分にもなりましたが、見張りと仕上げに分けることで、両方を活かせる形に落ち着きました。
実際に使ってみての感想
同じテーマでClaude Codeからの呼び出しでyomiyasuをつかって文を書いてもらうのと、Gemini Flash 3.8 Liteにyomiyasuなしで書いてもらうので、そんなに差はないかな…とも感じています。これは今後の発展に期待しつつ使い比べていくのがよさそうだと思っています。
参考資料
公式(作者による資料)
- nanaism/yomiyasu(GitHub) ― README、CHANGELOG、SKILL.md
- AI-Slopな日本語を構造レベルで読みやすくするSkill『yomiyasu(よみやす)』を作りました(Zenn)