【最新v1.0.8公開】AI-Slopな日本語を構造レベルで読みやすくするSkill『yomiyasu（よみやす）』を作りました

2026/10/07追記

yomiyasuは日々更新を重ねております！

特にv1.0.4以降、「公開当時より格段に読みやすくなった」との声を多数いただいております(大感謝...)！

開発では、下記画像のようなA/Bテストのアプリを作り、どちらの文章のどの部分がどのような理由で読みやすい or どういう違和感があるから読みにくいというのを言語化してフィードバックすることをひたすらに繰り返しています。

最新版にアップデートするコマンドはこちら👇️

npx skills update yomiyasu

リリースの詳細情報はこちら👇️
https://github.com/nanaism/yomiyasu/releases

---

TL;DR

AIが生成した不自然で読みにくい日本語を、自然で読みやすい文章へ書き直すスキル『yomiyasu（よみやす）』を公開しました。

従来のAI生成文対策スキルで一般的だった単語の禁止（ブラックリスト方式）にとどまらず、文の統語構造（誰が・何を・どうしたか）の復元と、比喩動詞の具体化に重点を置いている点が特徴です。

Claude Code、Codex、Cursorなどの主要なAIエージェント環境で、/yomiyasuと呼び出して利用できます。

// 導入コマンド
npx skills add nanaism/yomiyasu

リポジトリはこちらです。
https://github.com/nanaism/yomiyasu

はじめに

AIエージェントが日常の開発環境に定着し、エンジニアが文章を書く環境は大きく変わりました。コードの実装だけでなく、プルリクエストの説明文、仕様書のドラフト、Slackでの周知まで、AIに下書きを任せる場面は珍しくありません。

しかし、生成された日本語を読んだ際に、独特の不自然さや読みにくさに引っかかることはないでしょうか。

不自然な文章の例を挙げます（こうした文章は「AI-Slop」とも呼ばれます）。

非同期処理における最大の落とし穴は、ネットワークの瞬断です。
依存構造は分割できない。動かしながら引き返す。
単にメッセージを流すだけでは、背後でデータが静かに壊れます。前提を、経路が代わりに添えてくれるわけではありません。
そこで地味に効いてくるのが、以下の3つの原則です。

• 冪等性の担保: 重複した処理は黙ってスキップします。
• 安全なリトライ: 指数バックオフを挟むことで、DBの負荷を逃がします。
• DLQへの退避: 破綻したメッセージは隔離し、原因を1つずつ潰していきます。

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

このような文章は、読んでも内容が頭にすんなりと入ってきません。視線が滑り、同じ行を何度も読み返すことになります。
そして「AIが生成した文章だな」と気づいた瞬間、集中が途切れ、文章に対する信頼感が薄れてしまいます。

本稿では、AIがなぜこのような文章を生成してしまうのかという背景を整理し、それを検査・修復するエージェントスキル『yomiyasu』を公開するまでの経緯をまとめます。

「ブラックリスト方式」には効果がない

多くの方が最初に試みるのは、不自然な単語をプロンプトで個別に禁止するブラックリスト方式ではないでしょうか。

プロンプトや指示文に、次のように指定したとします。

「手触り」「解像度」「地味に効く」「〜側に倒す」といったAIらしい表現を使わないでください。

するとAIは、「手触り」を「実態」に、「地味に効く」を「効果を発揮する」に、「〜側に倒す」を「〜の方針に寄せる」へと機械的に言い換え始めます。

しかし、表層の単語だけを個別に置き換えても、文章の骨格や統語構造（文の組み立て）は変わりません。読んだときの不自然さは依然として残ります。

さらに「もっと人間味のある自然な文章で」と注文をつけると、今度は「真理」「境地」「美学」「思想」といった大げさな語彙を持ち出し、求めてもいないエッセイのような文体を生成し始めます。

禁止語をむやみに増やすアプローチは、設計が破綻したプログラムを変数名の一括置換だけで直そうとするようなものです。文の構造そのものが崩れている場合、単語だけを変えても読みにくさの本質は解消されません。

Qiita 7万件のデータから見る、AI普及後の日本語の変化

AI特有の読みにくさは、単なる個人の好みの問題なのでしょうか。

逆瀬川ちゃん氏による2026年9月の調査報告「生成AI以前と以後でエンジニアの文章はどう変わったのか: Qiitaの7万記事を数えてみた話」^[1]は、この疑問に対して客観的な定量的データを示しています。2019年から2026年までのQiita記事70,524件を収集し、AI普及前後での文章構造や語彙の推移を計測した研究です。

この調査結果からは、興味深い実態が浮き彫りになっています。

形式のインフレ

文の平均長（35.4字から39.2字）や文長のばらつき（変動係数）は、AI普及前の自然な推移の範囲内に収まっていました。一方で、記事の組み立て方（装飾や構造）には顕著な変化が生じています。

• 太字の頻度: 1,000字あたり1.26個から3.83個（約3倍）へ急増
• 箇条書きの割合: 8.9%から16.4%（約1.8倍）へ急増
• 地の文の文字数: 幾何平均で976字から1,914字（約2倍）へ倍増
• ダッシュ記号（—）: 1,000字あたり0.043個から0.426個（約10倍）へ急増

内容を深める代わりに見出しや太字、箇条書きで装飾し、一見すると整理されているかのように見せる傾向が数字に現れています。

語彙の変化と初期表現の減少

語彙の出現頻度（対数オッズ比）を比較すると、日常的に感じていた違和感がデータとして裏付けられていました。

語彙・表現	AI以前の出現記事率	2026年の出現記事率	増加率
効く	2.0%	22.3%	約11倍
壊れる	0.8%	13.1%	約16倍
境界	1.0%	12.8%	約13倍
実測	0.1%	9.4%	約94倍
静かに（静かに壊れるなど）	0.1%	4.9%	約49倍
黙って（黙って無視されるなど）	0.1%	3.4%	約34倍
倒す（〜側に倒すなど）	0.2%	1.1%	約5.5倍

興味深いことに、初期のAI生成文で典型的だった「〜しましょう」「することが可能です」「また、」といった表現は、2026年時点ではむしろ減少していました。

初期の定型句が書き手やモデルの側で避けられるようになった結果、作業を比喩で表す動詞や直訳調の言い回しなど、より気づきにくい形へと不自然さが潜り込んだことが分かります。

AI-Slopをもたらす3つの言語学的病理

なぜLLMはこのような文章を出力してしまうのでしょうか。

コーパス分析と先行研究（blader/humanizer^[2]、coji/natural-japanese^[3]、stop-ai-slop-jp^[4]など）の知見を照合すると、問題の根源は次の3点に整理できます。

1. 非生物主語と身体性比喩動詞（直訳調の言い回し）

英語には silently break（静かに壊れる）、silently ignored（黙って無視される）、works for（〜に効く）、land on the safe side（安全側に倒す）、source of truth（信頼できる唯一の情報源）といった慣用表現が数多く存在します。

学術研究においても、公開LLMの学習データが英語に偏っている点^[5]や、多言語モデルが他言語を出力する際にも英語の統語パターンが強く現れる点^[6]、LLMが直接生成した文章が高頻度で翻訳調（translationese）と判定される点^[7]が指摘されています。

逆瀬川ちゃん氏のQiita調査^[1:1]でも考察されている通り、英語圏の技術記事で頻出する比喩表現が、日本語へ変換される過程で直訳調のまま出力されていると考えられます。

この直訳調の表現がもたらす問題は、単なる文体上の違和感にとどまらず、技術文書において情報の欠落を引き起こす点にあります。

本来、システムの挙動や設計判断には「開発者が設定値を誤った」「アクセス急増によりプロセスが停止した」といった具体的な行為者や因果関係が存在します。しかし、概念を主語に据えて比喩動詞で片付けてしまうと、「誰が」「何をした結果として」その現象が起きたのかという主述の関係が文から抜け落ちてしまいます。

因果関係が曖昧になる結果、読み手は「現場で何が起き、誰がどう対処すべきなのか」を行間から補って読まなければならず、余計な負担がかかります。

2. 構文の消失と名詞の過剰な連続（過剰な圧縮）

読解を妨げるもう1つの要因が、述語を動詞として展開せず、サ変名詞と助詞「の」をつなげて体言止めで終える過剰な圧縮です。

• 圧縮された文: 「保守性担保機能の形骸化の防止。」
• 本来の文: 「コードの保守性を保つ仕組みが形骸化しないように、定期的なレビューを実施します。」

主語（S）、目的語（O）、動作（V）、条件（M）が失われ、名詞だけが過密に詰め込まれます。専門用語が並んでいるため整っているように見えますが、具体的な業務手順としては情報が伝わりません。

3. 形式の過剰装飾と不要な否定対比

最後に、「〜ではなく、〜である」「単なる〜ではない」という二項対比の多用です。

読者が想定していない前提をあらかじめ否定してから本題に入る構成が多く見られます。論理的には肯定文だけで十分に伝わる内容であるにもかかわらず、演出のための否定文が重なり、読む側の負担を増やしてしまいます。

従来の文章推敲スキルが抱えていた課題

こうした問題を解決するために、先行する複数の執筆支援スキルを調査しました。その結果、既存の手法にはいくつか構造的な課題があることが分かりました。

指示文そのものに比喩動詞が含まれている

既存スキルのルール定義文を精査したところ、禁止対象であるはずの比喩的な動詞が指示文の中で使われていました。

• 「効く」: 調査した5スキルの指示文中で計28回使用
• 「渡す」: 「結論をタイトルに渡す」「名前を渡す」「中心主張を渡す」
• 「倒す」: 「判断を『残す』側に倒す」
• 「着地させる」「宿らせる」「ループを回す」などの表現

LLMは指示文の内容だけでなく、プロンプトの文体そのものを手本として模倣します。ルールで「比喩を避ける」と指示しながら、説明文自体が比喩動詞で書かれていれば、生成される出力にも比喩が混入しやすくなります。

指標のハックによる不自然な短文の混入

文章のリズムを保つ指標として、文長のばらつき（変動係数）を測定する検査ツールがあります。

一部のスキルでは、この検査ツールの警告を回避するために「最も伝えたい文を短くする」という指示を出していました。その結果、次のような短い文が段落の途中に差し込まれるケースが見られました。

「順番が命だ。」
「実例がすべてだ。」
「覚悟がいる。」
「迷ったら読み手基準。」

文脈から浮いた短い決め台詞が唐突に現れ、かえって別の不自然さを生んでいました。指標を満たすこと自体が目的化し、本来の読みやすさが損なわれる「グッドハートの法則」が生じていたと言えます。

また、文章を削る指示に偏っていたため、体言止めや名詞句で過剰に圧縮された文章に対して適用すると、助詞や述語がさらに削ぎ落とされ、より読みにくくなる現象も確認されました。

160本の検証コーパスで見えた限界と設計の修正

表面的な単語の置き換えや自己矛盾したルールを排し、文の構造を整える仕組みを作るため、独自の検証コーパスを構築しました。

• 実務8ジャンル: 技術解説、障害報告書、PR説明文、Slack周知、技術選定メモ、仕様書ドラフト、コードレビュー、開発エッセイ
• 人間が執筆した文書（16本）: 実務記事や公開されているOSSの技術ドキュメント
• 境界値テスト文書（48本）: 日常語や慣用句（「お握り」「主導権を握る」「過労で卒倒」「氷を溶かす」「腹を割る」など）
• LLM生成文書（96本）: 生の出力（24本）、単語禁止プロンプトによる出力（24本）、yomiyasuによる推敲出力（48本）
• 合計: 160本

このコーパスを用いて、機械的な検査スクリプトの開発を進めました。

単純なキーワード一致が引き起こす過剰検出

当初は、問題となる動詞を正規表現で捕捉すれば十分だと想定していました。「壊れる」「倒す」「溶かす」「握る」「割る」といった動詞をリスト化し、検査を実行しました。

しかし、単純な語句の一致では実用的な精度が得られませんでした。

• 「お昼休みにコンビニでお握りを買って食べました。」 → 「握る」を検出
• 「交渉の席では、こちらが主導権を握り続けることが重要です。」 → 「握る」を検出
• 「連日の猛暑が重なり、卒倒してしまいました。」 → 「倒す」を検出
• 「フロントガラスが凍結したため、ぬるま湯をかけて氷を溶かしました。」 → 「溶かす」を検出
• 「お腹を壊してしまいました。」 → 「壊れる」を検出

日常的な会話やおにぎり、ビジネスの慣用表現、物理的な融解、身体の不調に至るまで、自然な日本語の多くが違反として判定されました。境界値テストの48本中46本（95.8%）で誤検出が生じ、人間が書いた技術文書でも14件の警告が出ました。

文脈を考慮しない単語マッチの限界

誤検出ログを精査したところ、正規表現が動詞の前後の結合関係を捉えられていないことが原因でした。

AI特有の不自然さは、抽象概念を主語にして身体性比喩動詞を結合させる点にあります。動詞そのもの（壊れる、倒す、溶かす、握る）自体が問題なのではありません。自然な文章では、動詞と結びつく対象が明確に分かれていました。

• 物理的な実体や身体の文脈: 「時計が壊れる」「お腹を壊す」「氷を溶かす」「手でお握りを握る」
• 確立された日本語の慣用句: 「主導権を握る」「過労で卒倒する」

単純な正規表現では、結合している対象が物理的なものか熟語かを識別できず、動詞の文字列だけを見て一律に違反と判定してしまいます。

課題は単語を一律に禁止することではなく、直前に身体や物理物質が来ている正当な結合を除外し、概念や方針に結びついている比喩動詞だけをいかに識別するかという点にありました。

Lookaroundによる文脈の限定

前後の文脈（否定先読み・後読み）を組み込んだ正規表現パターンへ改修を行いました。

# 「握る」: お握り、主導権、ぎゅっと握る等の日常語・慣用句を除外
(?<!お)(?<!権を)(?<!っと)(?<!く)握(?:る|り(?!飯)|っ|ら|れ)

# 「倒す」: 卒倒、圧倒、転倒などの漢字熟語を除外
(?<![打卒圧転])(?<!打ち)倒(?:す|し|さ)

# 「溶かす」: 氷、雪、熱による物理的融解を除外
(?<![氷雪熱])溶(?:かす|かし|かさ)

# 「壊れる」: お腹、胃、身体、機械などの物理的破損を除外
(?<![胃腹体機])壊(?:れる|れ|れず)

この改修を160本のコーパスに適用した結果、境界値テストおよび人間執筆文書における日常語・慣用句への誤検出を大幅に抑制できました。

コーパス種別	ファイル数	単純一致の誤検出	Lookaround改修後	誤検出の抑制率
境界値テスト（日常語・正当な慣用句）	48本	46件	0件	100.0%
人間執筆（実務記事・OSSドキュメント）	16本	14件	0件	100.0%

これにより、正当な日本語への誤検出を抑えながら、比喩動詞を捕捉できる検査スクリプトの基礎が整いました。

エージェントスキルの設計方針

静的リンターによって問題箇所を検知できるようになりましたが、別の課題が生じました。

リンターが「比喩動詞が使われています」「否定対比があります」と指摘しても、具体的にどう書き直せばよいかという方針がなければ、AIは別の不自然な言い換えを繰り返してしまう点です。

たとえば、「キューの順序性が静かに壊れます」という文に対して「比喩動詞を使わずに直して」と指示すると、AIは「キューの順序性が黙って失われます」や「キューの順序性の破綻が発生します」といった、別の比喩や過剰に圧縮された名詞句へと置き換えてしまいます。

単に問題を指摘するだけでなく、文章の構造を整える手順を定義したエージェントスキルが必要でした。そこで、以下の3つの方針を定めました。

1. 単語の置換ではなく「解体と再構築」を行う

単語の言い換えを指示するのではなく、文を構成する意味要素を一度分解し、順序立てて組み立て直す手順をプロンプトに組み込みました。

1. 行為者の特定: その事象において、実際に判断し作業を行っている主語は誰か（例: メッセージを処理するプロセスや、システムを運用する開発者）。
2. 事実への還元: 比喩動詞でぼかされていた事象を言語化する（例: 「静かに壊れる」を、エラーを出さずにデータの不整合が生じる、など前後の文脈に即した表現にする）。
3. 主述関係の復元: 行為者を主語に据え、目的語と述語動詞を補って文を再構成する。
4. 装飾や記号の平文化: 必要性の薄い太字、文を分断している箇条書き、不要な否定対比を地の文へ統合する。

2. 指標ハックを防ぐための情報密度の設計

既存のスキルに見られた「最も言いたい文を極端に短くする」といった指示を避けました。そうした指示は「順番が命だ」「覚悟がいる」といった不自然な短文を生み出す原因になるためです。

短文を無理に差し込まず、名詞の連続を動詞述語に戻し、同一の文末が続かないように整えることで、過不足のない情報密度を目指しました。

3. 指示文自体の表現の適正化

前述の通り、既存スキルの多くは指示文自体が比喩動詞で書かれていました。LLMはプロンプトの文体を手本として模倣するため、指示文が不自然であれば出力にも影響します。

そこで、スキルの指示文（SKILL.md）自身をリンター（yomiyasu_lint.py）で検査し、比喩動詞や不要な記号、過剰な装飾、英単語前後の不自然な半角空白を排除しました。指示文自体が自然な日本語の規範となる状態を整えています。

『yomiyasu』完成！

こうした検証を経て、ルールとして体系化したのが日本語推敲スキル『yomiyasu（よみやす）』です。

使ってくれる方が「読みやす！」と喜んでくださるといいなと思い、こう命名しました。

https://github.com/nanaism/yomiyasu

yomiyasuは、文の背後にある「誰が、何を、どうしたのか」という関係を抽出し、読み手にとって負荷の少ない日本語へ再構築します。
中核となる原則は以下の7点です。

1. 非生物主語の解消: 道具や概念を主語にせず、実際に作業を行う人間やチームを行為者として主語に据えます。
2. 比喩動詞の具体化: 「壊れる」「倒す」「溶かす」「効く」といった比喩を、前後の文脈に即した具体的な処置や事象へ改めます。
3. 名詞の連続の動詞化: 「〜の実施の検討」のような名詞の連続を解き、助詞を補って動詞述語の文に戻します。
4. 過剰な装飾の平文化: 必要性の薄い太字装飾を外し、因果関係を分断している箇条書きを地の文へ統合します。
5. 不要な否定対比の排除: 読者が誤解していない「AではなくB」を削り、肯定的事実（B）を直接記述します。
6. 不要な記号の排除: 文末の全角コロン（：）や装飾的な絵文字を取り除きます。
7. タイポグラフィの正常化: 日本語と英単語・半角数字の間に機械的に挿入されがちな不要な半角空白を排除します。また、太字がMarkdown上で正しく表示されるよう、括弧や句読点との接合関係を整えます。

静的リンターによる機械的な検証

『yomiyasu』のもう一つの特徴は、スキルの指示文（SKILL.md）だけでなく、静的解析スクリプト（yomiyasu_lint.py）を同梱している点です。

AIには「自分の書いた文章を自分で採点させると甘く評価してしまう」という傾向があります。自己チェックだけでは見落としが生じやすいため、コーパス検証から得られた正規表現群をPythonスクリプトとして実装しました。

python3 scripts/yomiyasu_lint.py path/to/document.md

スクリプトは減点方式で文章を検査します。

• 比喩動詞（「壊れる」「倒す」「溶かす」など）: 1件につき−10点
• 記号の違反（絵文字、文末コロン、不自然な半角空白）: 1件につき−5点
• 形式の過剰装飾（過剰な太字、否定対比）: 1件につき−5点
• 表示されない太字構文（bold_not_rendered）: 警告および修正案の提示
• 名詞の過剰な連続、読点の多用: 1件につき−3点

このスクリプトを実行し、指摘が解消されるまで検証を繰り返すことで、プロンプトの出力のばらつきを抑え、安定した品質を確保できます。

実例 Before / After

「デザインシステムの運用指針」を例に挙げます。

Before
ボタンやフォームのコンポーネント設計において、柔軟性を共通側に倒しすぎると、エッジケース対応で局所的な秩序が静かに壊れます。
手触り感のある運用を回すためにも、境界線をどこに引くかが地味に効いてきます。

↓

After
ボタンやフォームの共通部品を過剰に共通化すると、例外的な画面要件に対応できなくなり、各画面で個別の上書きや分岐処理が増加します。
運用の破綻を防ぐには、どの変更を共通部品に取り込み、どの変更を画面側の個別実装にとどめるか、具体的な判断基準を定めておく必要があります。

抽象的な比喩が、具体的な処置へと書き直されていることが分かります。

次に、「非同期ワーカーの障害報告」の例です。

Before
非同期キューの詰まりに起因するメッセージ処理遅延の発生。
例外発生時にリトライ機構が黙って無視される設定になっていたため、調査に時間を溶かす結果となりました。

↓

After
非同期キューの滞留により、メッセージの処理に遅延が生じました。
例外発生時のリトライ処理が無効化されていたため、エラーログが記録されず、原因の特定に時間を要しました。

比喩や名詞化によって曖昧になっていた因果関係が、一読して把握できるようになっています。

インストールと使い方

『yomiyasu』は、Claude Code、Codex、Cursorなどの主要なエージェント環境に導入できます。

npx skills add nanaism/yomiyasu

詳細な手順や最新の仕様については、READMEをご参照ください。

https://github.com/nanaism/yomiyasu/blob/main/README.md

導入後は、エージェントに対して通常通り指示を出すだけで動作します。

/yomiyasu このPR説明文を読みやすく書き直して

読みやすくして

文章の推敲だけでなく、新規の文書作成時にも『yomiyasu』のルールに沿って執筆させることができます。

また、本スキルおよび検査スクリプトはMITライセンスで公開しています。開発チームの方針に合わせてルールを調整したり、固有の表現を追加してフォークしたりすることも可能です。現場の開発プロセスに合わせて活用してください。

おわりに：読み手の負担を減らすための姿勢

AIによって、誰もが長文を一瞬で出力できる時代になりました。

しかし、書くコストが0に近づいたからこそ、「その文章を読む相手がどれだけの時間と認知リソースを払うのか」という問題がかつてないほど浮き彫りになっています。

中身の薄い文章を装飾で飾り立てたり、比喩的な動詞でお茶を濁したりすることは、読み手に文脈の穴埋めを強いる行為に他なりません。

誰が、何を、どうしたのか。
事実は何で、判断の根拠はどこにあるのか。

文章を書くときに生じる本来の思考の摩擦を、AIに丸投げして消し去ってはなりません。
読み手が最もスムーズに理解できるように言葉を尽くすこと。
それが、AI時代においてエンジニアが発信を続けるための誠実さではないでしょうか。

このスキルが、開発の現場から不自然な日本語のストレスを減らし、クリアなコミュニケーションを取り戻す一助となれば幸いです。

連絡先

ご意見やご感想がありましたら、X（旧Twitter）までご連絡ください！

https://x.com/oga_aiichiro

なお、この記事自身も『yomiyasu』を用いて推敲されています。

参考文献

脚注

1. 逆瀬川ちゃん. 「生成AI以前と以後でエンジニアの文章はどう変わったのか: Qiitaの7万記事を数えてみた話」 (2026年9月). https://nyosegawa.com/posts/qiita-writing-before-after-ai/

2. blader. "humanizer: Detect and remove AI-generated text patterns." GitHub repository. https://github.com/blader/humanizer

3. coji. "natural-japanese: Japanese writing style guide and linter for AI." GitHub repository. https://github.com/coji/natural-japanese

4. Daichi Nagashima (iKora128). "stop-ai-slop-jp: Remove AI-specific writing style in Japanese." GitHub repository. https://github.com/iKora128/stop-ai-slop-jp

5. 高瀬翔, 本多右京. 「英語中心の大規模言語モデル開発からの脱却に向けて」言語処理学会第32回年次大会 (NLP2026), C7-23. arXiv:2605.15613. https://arxiv.org/abs/2605.15613

6. Yanzhu Guo, Simone Conia, Zelin Zhou, Min Li, Saloni Potdar, Henry Xiao. "Do Large Language Models have an English 'Accent'? Evaluating and Improving the Naturalness of Multilingual LLMs." Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (ACL 2025), pp. 3823–3838. https://aclanthology.org/2025.acl-long.193/

7. Maria Valentini, Téa Wright, Julisa Granados, Eliana Colunga, Katharina von der Wense. "An Investigation of Translationese in the Generations of Multilingual Large Language Models." Conference on Language Modeling (COLM 2026). https://arxiv.org/abs/2608.17399