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

2026/10/29追記（v2.4.0）

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

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

その後、10月16日に公開した v2.0.0 で、yomiyasu の考え方を大きく改めました。
v1.0.0 を公開した直後に、書き直した文で意味が変わっているという指摘をいただいたためです。
v2.0.0 からは「意味を変えないこと」と「原文にない情報を足さないこと」をいちばん大事な決まりにし、原文から読み取れない所は作り足さずに残して、書き手に尋ねるようにしています。

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

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

npx skills update yomiyasu

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

TL;DR

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

従来のAI生成文対策スキルで一般的だった単語の禁止（ブラックリスト方式）にとどまらず、誰が・何を・どうしたか（動作主・対象・述語）の関係と、比喩動詞を直す点が特徴です。v2.0.0 からは意味を変えないことを最優先にし、推敲の前と後を付属の検査で比べています。

Claude Code、Codex、Cursor をはじめとする AI コーディング環境に読み込ませ、「/yomiyasu」や「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は「手触り」を「実態」に、「地味に効く」を「効果を発揮する」に、「〜側に倒す」を「〜の方針に寄せる」へと機械的に言い換え始めます。

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

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

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

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年時点ではむしろ減少していました。

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

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つの要因が、述語を動詞として展開せず、サ変名詞と助詞「の」をつなげて体言止めで終える過剰な圧縮です。

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

誰が・何を・どうするかと、その条件が失われ、名詞だけが過密に詰め込まれます。専門用語が並んでいるため整っているように見えますが、具体的な業務手順としては情報が伝わりません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

検証コーパスで見えた限界

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

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

公開したときは、16本をすべて人が書いた文書として数えていました。そのうち技術メモの8本はコーパスを作るスクリプトの中に書いた例文で、人が書いた文ではありませんでした。コーパスの中で人が書いた文は、作者の記事1本を見出しで8つに分けた抜粋だけです。v2.0.0 の CHANGELOG で訂正しています。いまのコーパスは生の出力を26本、境界値テスト文書を49本に増やした163本です。

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

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

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

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

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

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

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

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

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

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

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

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

Lookaroundによる文脈の限定

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

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

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

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

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

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

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

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

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

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

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

単に問題を指摘するだけでなく、文章を直す手順を定義したエージェントスキルが必要でした。いまの yomiyasu では次の4つの方針を定めています。

1. 意味を変えないことを最優先にする

公開したときの yomiyasu は、文を分解して組み立て直す手順の最初に「実際に判断し作業を行っている主語は誰か」を特定させていました。この手順では原文に書いていない行為者や原因まで補うことがありました。1.1.2 まで README に載せていた書き直しの例にも、原文にない内容を足したものがあります。公開した直後には、書き直した文で意味が変わっているという指摘もいただきました。

v2.0.0 からは書き直す前に、元の文の主張、比重、言い切りの強さ、文の働きの4点を確かめ、書き直したあとも同じに保ちます。主語や対象を補うのは、原文や渡された資料から決まるときだけです。決まらないときは原文を残し、「書き手に確かめたい点」として書き手に尋ねます。

2. 直す前に、案を原文と読み比べる

不自然な型に当たった箇所は、直す前に案を1つ書き、原文と6つの点を読み比べます。何について述べているか、何を認めて何を否定しているか、誰が誰に何をするか、範囲と条件、断定・推量・伝聞の強さ、数値・固有名詞・時期です。1つでも変わるなら案を捨てて原文を残し、通るまで案を作り直すことはしません。

3. 点数を目的にしない

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

同じ理由で、v2.0.0 からは付属のリンターが通常の出力に点数を出さないようにしました。点数が読みやすさの合格点のように見え、点数を上げること自体が目的になりかねないためです。検査は見直し候補を出すだけで、意味が保たれたかどうかや、読みやすいかどうかは判定しません。

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

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

そこで、スキルの指示文（SKILL.md）自身をリンター（yomiyasu_lint.py）で検査し、比喩動詞や不要な記号、過剰な装飾を取り除きました。新しい決まりを足すときも、指示文や README を yomiyasu 自身で推敲しています。

『yomiyasu』完成！

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

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

https://github.com/nanaism/yomiyasu

yomiyasuは元の意味を保ったまま、読み違えやすい箇所や、文の関係を追うのに負担がかかる箇所を直します。自然に読める部分は残します。
v2.4.0 の中核となる原則は、次の7点です。

1. 主述・修飾・条件の点検: 主語と述語、修飾語と掛かる先、指示語と指す対象を対応づけます。条件・例外・否定・数量・順序も、書き直す前と後で同じように追えるか確かめます。主体や対象を補うのは、原文や資料から決まる範囲だけです。
2. 文の働きと文体の保持: 文ごとに説明・依頼・助言・予定を区別し、働きに合わない文末だけを直します。常体・敬体は、指定がなければ保ちます。
3. 擬人化の整理: 道具や概念に感情や意志を持たせた表現を直します。道具やシステムの動作を客観的に述べる非生物主語は残します。
4. 比喩を平易な言葉へ: 「壊れる」「倒す」「効く」「溶かす」などを、元の含みや意味の広さを保って言い換えます。
5. 前置き・否定対比の役割の確認: 前置きや否定対比を削るのは、削っても主張や比重が変わらないときだけです。
6. 情報を勝手に足さない: 原文にない主体・原因・条件・数値・感情を足しません。読み取れない所は原文の状態のまま残し、確かめたい点を本文のあとに添えます。
7. 文長・読点・装飾の調整: 平均文長30〜45字、1文の読点0〜2個を目安にし、間を作るだけの読点や過剰な装飾記号を整理します。英単語や数値の前後の空白は元の書式を保ち、残す太字は表示される形に整えます。

付属の検査ツール

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

AIには「自分の書いた文章を自分で採点させると甘く評価してしまう」という傾向があります。自己チェックだけでは見落としが生じやすいため、決まった形を拾う検査を Python のスクリプトとして実装しました。どれも Python の標準ライブラリだけで動きます。

• yomiyasu_lint.py: 比喩動詞、決まり文句、過剰な太字や箇条書き、絵文字、文末コロン、表示されない太字、直訳語などを、見直し候補として行ごとに出します。
• yomiyasu_diff.py: 推敲の前と後を比べ、変わった箇所をすべて出します。数値、否定、「が」「を」の入れ替え、文の種類（伝聞、推量、依頼など）が変わった所は、意味が変わる恐れとして先に示します。v2.4.0 からは原文にない人や担当を足した文もまとめて示します。
• yomiyasu_check.py: lint と diff をまとめて実行し、記録を残します。スキルは書き直したあとに run を実行し、返す直前に verify で、最終稿が検査したものと同じかを記録と照らし合わせます。

python3 scripts/yomiyasu_check.py run --source 原文.md --final 最終稿.md
python3 scripts/yomiyasu_check.py verify --final 最終稿.md

検査は見直し候補と変わった箇所を出すだけです。候補が出た所を直すかどうかは、元の文や文脈と照らし合わせて決めます。

実例 Before / After

冒頭に挙げた非同期処理の文章を、v2.0.0 の yomiyasu で推敲した例です。Claude Code（Claude Opus 5.5）に「draft.md を yomiyasu で読みやすくして、結果を out.md に書いてください。」とだけ頼み、1回目の出力をそのまま載せています（README の例と同じものです）。

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

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

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

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

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

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

↓

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

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

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

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

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

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

yomiyasu は太字を外し、比喩の動詞（静かに壊れます、地味に効いてくる、黙ってスキップ、潰していきます、時間を溶かさない）を言い換えました。最後のいかがでしたでしょうかは中身のない決まり文句として消しています。箇条書きは原則の名前に説明が続く形なので、ラベルとコロンを残しました。2行目の依存構造は分割できない。動かしながら引き返す。は何を言っているかが読み取れないので書き換えず、最後の文のこの境界線が何を指すかとあわせて、書き手に尋ねています。

公開したときにこの記事に載せていた After は、「エラーログが記録されず」のように、原文にない内容を足して書き直していました。v2.0.0 からは原文から決められない所を作り足さずに残すので、After の変化は小さくなっています。

インストールと使い方

『yomiyasu』は Claude Code、Codex、Cursor をはじめとする AI コーディング環境に読み込ませて使います。

npx skills add nanaism/yomiyasu

ほかにも gh skill install、Claude Code のプラグイン、Claude.ai に登録する ZIP、Codex のリポジトリの .agents/skills/ に置く方法があります。詳細な手順や最新の仕様については、README をご参照ください。

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

導入後は依頼の文に yomiyasu の名前を書くか、「/yomiyasu」と送って呼び出します。

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

v2.0.2 からは名前を出さずに「読みやすくして」とだけ頼んでも、エージェントは yomiyasu を使いません。AI が書く日本語をいつも yomiyasu に通したいときは、CLAUDE.md や AGENTS.md に、yomiyasu で推敲するよう頼む1行を足してください（README の「毎回 yomiyasu を使いたいとき」に、入れ方ごとの1行を載せています）。

文書の種類や読み手、書き手と読み手の関係を依頼の中で伝えると、それに合わせて直します。

この障害報告を yomiyasu で、専門知識のない社外の利用者向けに読みやすくして。

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

また、本スキルおよび検査スクリプトはMITライセンスで公開しています。
開発チームの方針に合わせてルールを調整したり、固有の表現を追加してフォークしたりすることも可能です。
プロジェクトに合わせた語は、.yomiyasu-words/ の allow.txt（直さない語）と flag.txt（見直す語）にも書けます。
現場の開発プロセスに合わせて活用してください。

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

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

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

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

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

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

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

連絡先

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

https://x.com/oga_aiichiro

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

参考文献