AIっぽい日本語を読みやすく書き直すスキル「yomiyasu」が、9月30日にGitHubで公開されました。スキルとは、AIに読み込ませる作業手順の指示ファイル一式です。作者が翌10月1日にZennで公開した解説記事には、同日正午の時点ではてなブックマークが235件付きました。当サイトで付属の検査スクリプト(文章を自動で採点するプログラム)を試すと、人の文章とAIの文章の点数はほぼ同じでした。12
この記事でわかること
- 業務文書向けのルールでは、AIに比喩を使わせず、決めた人と条件ごとの対応を書かせます
- 検査スクリプトは「時間を溶かさない」のような否定形を見逃す例があり、100点でも人が読み返す必要があります
- 書き直すのはyomiyasuではなく使っているAIなので、社外秘の情報を入力してよいかは社内規程に沿って判断します
9月30日にオープンソースとして公開
yomiyasuは、ALGO ARTISの大賀愛一郎氏が個人で公開しました。READMEには、所属企業の公式の製品ではないと明記されています。MITライセンスで公開されており、商用利用もできます。1
利用者は、Claude Code・Codex・CursorなどのAIコーディングツール(AIにプログラムを書かせるツール)に読み込ませて使います。下書きを貼って「この文章を読みやすくして」と頼むと、AIがルールに沿って書き直します。13
yomiyasuが書き換える言い回し
単語ではなく文の組み立てを直す
これまでのAIっぽさへの対策は、「解像度」「手触り」のような言葉を使わせない方法が中心でした。作者は、言葉を禁じても別のあいまいな言葉に言い換えられるだけで、文の組み立ては変わらなかったと説明しています。2
yomiyasuを使うと、AIは誰が何をどうしたかを1文ごとに書きます。「静かに壊れる」「共通側に倒す」のような比喩的な言い回しは、何がどうなるかを直接書いた文に書き直します。「重要なのは」で始まる前置きや、「ぜひ〜してみてください」のような締めの呼びかけも削ります。1
業務文書向けの書き換え例
用途は、技術記事・業務文書・エッセイの3つから選べます。業務文書向けを選ぶと、AIは次のように書き換えます。4
| AIの下書きに多い書き方 | yomiyasuの書き換え例 |
|---|---|
| 判断に迷うものは、残さない側に倒す。 | 採否基準を満たさないレコードは、登録対象から除外する。 |
| 議論の解像度を上げる。 | 検討項目のコスト試算と対応期日を具体化する。 |
| 決定された | プロダクトオーナーが決定した |
左の列は、言いたいことの見当はつくものの、何をすればよいかが読み取れない書き方です。右の列には、対象・条件・決めた人が書かれています。「適宜対応する」のような言い方も、条件ごとの対応を書かせます。4
付属の検査スクリプトの点数は当てになるか
検査スクリプトは、太字や箇条書きの多さと、定番の言い回しを調べ、1つ該当するごとに100点から減点します。5
READMEの例文は、書き直すと100点
当サイトでは10月1日時点の版(コミット30ee604)を入手し、検査スクリプトをPython 3.11で動かしました。READMEにある書き直し前の例文2つは、43点と65点でした。書き直し後の文章は、どちらも100点でした。1
作者の検証用の文章では差が出ない
作者は、検証用に160本の文章を集めています。当サイトでは、このうち人が書いた16本と、AIが出力したままの24本を採点しました。平均点は、人の16本が97.4点、AIの24本が97.6点でした。この値は、リポジトリで公開されている作者の測定結果と同じです。6
READMEの例文は、太字や「静かに壊れる」のような定番の表現を詰め込んで作ってあるため、点数が低く出ました。作者の集めた文章では、AIが出力したままでも検査に引っかかる箇所が少なく、点数に差が出ませんでした。SKILL.mdも、検査結果を「機械的な見直し候補」と位置づけています。3
否定形を見逃す例
書き直し前の例文には、「時間を溶かさずに済みます」と「時間を溶かさない」がありました。どちらも検査では指摘されませんでした。検出のルール(正規表現)が「溶かした」「溶かす」などの形だけを対象にしているためです。5
社内文書の下書きにAIを使う会社への影響
例えば、毎月の社内通知や取引先への提案書をAIで下書きしている会社では、「重要なのは」で始まる段落や、誰が決めたのかが書かれていない文が混ざることがあります。そうなると、読む人が要点を探す手間が増えます。yomiyasuを通せば、前置きが減り、誰が何をするかが明記されるはずです。
yomiyasuは、1文の長さの目安を30〜45字としています。文化審議会の建議「公用文作成の考え方」の解説は、適当な長さは一概に決められないとしつつ、50〜60字ほどになったら読みにくくなっていないか意識するとよいとしています。7 社内の文書規程や表記ルールがあれば、それと食い違わないかも見ておきましょう。
書き直させずに、指摘だけをさせる使い方もあります。依頼メールを書き直させず、指摘だけをさせる方法なら、直すかどうかを書いた本人が決められます。当サイトでも、AIが書いた記事を別のAIに校閲させています。
導入の前後に確かめること
| 項目 | 分かっていること |
|---|---|
| 使える環境 | Claude Code・Codex・CursorなどのAIコーディングツール。導入はコマンドかプラグインで行う |
| ほかの校正スキルとの併用 | 同時に有効にすると指示がぶつかるおそれがあり、作者は類似のスキルを一時的に無効にするよう勧めている |
| 書き直しで中身が変わらないか | 原文にない数値や担当者を書き足さない方針。ただし書き直すのは使っているAIで、結果の保証はない |
| 社外秘の情報 | 文章は、使っているAIのサービスで処理される |
使える環境と併用の2点は、導入の前に確かめられます。ChatGPTやGeminiをブラウザのチャット画面だけで使っている職場では、READMEの導入手順はそのまま使えません。1 なお、Googleも9月29日に、GeminiのGemを「スキル」へ移行する方針を発表しています。
書き直しの中身と社外秘の情報の2点は、使い始めてから確かめます。次の順で試すとよいでしょう。
- AIコーディングツールを使っていないなら、READMEの書き換え例を、AIの下書きを手で直すときの目安にします
- 使っているなら、社外秘の情報を含まない社内向けの文書1本で試し、書き直した文を原文と並べて、数字・日付・誰が何をするかが変わっていないかを読みます
- 顧客や取引先の情報が入る文書は、生成AIに入力してよいかを先に確かめておきましょう
出典
- nanaism/yomiyasu(GitHub。README)(参照 2026-10-01)
- 大賀愛一郎「AI-Slopな日本語を構造レベルで読みやすくするSkill『yomiyasu(よみやす)』を作りました」(Zenn・2026年10月1日)(参照 2026-10-01)
- nanaism/yomiyasu「SKILL.md」(スキルの指示書)(参照 2026-10-01)
- nanaism/yomiyasu「業務・仕様・実務ドキュメント向け仕様」(参照 2026-10-01)
- nanaism/yomiyasu「yomiyasu_lint.py」(検査スクリプト)(参照 2026-10-01)
- nanaism/yomiyasu「benchmark_results.json」(検証用の文章160本の測定結果)(参照 2026-10-01)
- 文化審議会「公用文作成の考え方(建議)」(令和4年1月7日)(参照 2026-10-01)

