AI生成の日本語を構文から直すAgent Skill『yomiyasu』の仕組みと導入判断
『yomiyasu（よみやす）』は、AIが生成した日本語を統語構造のレベルで書き直すAgent Skillです。2026年10月1日に大賀愛一郎氏が公開し、MITライセンスで配布されています。特徴は2点あります。「AI臭い単語」を禁止するのではなく、誰が何をどうしたのかという文の骨格を復元すること。そして、判定を機械化する静的リンターを同梱していることです。導入は1コマンドで終わります。AIに下書きを任せる場面が増え、レビュー負担が読み手に偏っているチームであれば、検討する価値があります。
Agent Skillとしての構成
Agent Skillは、SKILL.mdという指示ファイルを中心に、スクリプトや参照資料をフォルダへまとめた配布形式です。Anthropicの仕様では、起動時に読み込まれるのはYAMLフロントマターのnameとdescriptionだけで、エージェントが関連すると判断したときにSKILL.md本文が読み込まれ、参照資料やスクリプトは必要になった時点で呼ばれます。この段階的開示により、スキルを多数入れてもコンテキストの消費を抑えられます。
yomiyasuもこの構成に沿っています。SKILL.mdが入口となり、references配下に構文変換原則、不自然な語彙のカタログ、用途別の指針を置き、scripts配下に検査スクリプトyomiyasu_lint.pyを同梱しています。呼び出しは「/yomiyasu このPR説明文を読みやすく書き直して」のような明示指定でも、「読みやすくして」という自然な依頼でも機能します。
単語を禁止しても直らない理由
作者はまず、禁止語リスト方式の限界を指摘しています。「手触り」「解像度」を禁止すると、モデルは別の曖昧な語へ言い換えるだけで、文の骨格は変わりません。さらに「人間味のある文章で」と注文すると、今度は「真理」「境地」といった大げさな語彙を持ち出します。
この違和感には定量的な裏づけがあります。2026年9月に公開されたQiita記事70,524件（2019〜2026年）の調査では、1,000字あたりの太字が1.26個から3.83個へ、箇条書きの割合が8.9%から16.4%へ増えていました。語彙では「効く」が出現記事率2.0%から22.3%、「壊れる」が0.8%から13.1%へ伸びています。一方で「〜しましょう」「することが可能です」といった旧来のAIらしい定型句は減っていました。初期の目立つ癖は警戒されて減り、問題がより気づきにくい構文と比喩へ移ったと読めます。
作者はAI臭さの原因を3つに整理しています。第一に、概念や道具を主語にして身体的な比喩動詞を付ける英語直訳型の構文です。第二に、述語を動詞として展開せず、サ変名詞と「の」でつないで体言止めにする過剰圧縮です。第三に、内容の裏づけのない太字や箇条書きと、読者が持っていない誤解を否定してから本題に入る対比表現です。いずれも、誰が何をしたのかという情報が文から抜け落ちる点が共通しています。
7つの原則と変換の手順
yomiyasuは、この3つの症状に対する処方を7つの原則としてまとめています。非生物主語の解体、比喩動詞の具体化、サ変名詞を動詞へ戻す脱圧縮、装飾や箇条書きの平文化、架空の二項対比の排除、文末コロンや絵文字の除去、和文と英数字の間の不自然な半角空白の整理です。あわせて、1文は30〜45字程度、読点は0〜2個、同じ文末を連続させないという基準も設けています。
重要なのは、置換ではなく分解と再構築の手順を踏ませている点です。まず実際に判断し作業している行為者を特定し、次に比喩でぼかされた事象を字義どおりに言語化し、そのうえで主語と目的語と述語を立て直します。たとえば「静かに壊れる」は、エラーログが記録されずに原因特定に時間がかかったといった具体的な経過へ開かれます。局所的な言い換えを指示すると、AIは別の比喩や名詞句へ逃げてしまうという観察が、この設計の背景にあります。
用途別の調整も可能です。プロンプト内で「技術記事向けに」「業務仕様向けに」「エッセイ向けに」と添えるか、ドメイン名としてtech、business、essayを指定します。省略時は入力内容から自動判別されます。仕様書では責任主体と境界条件を明確にし、エッセイでは過度な教訓化を避けるなど、方針が切り替わります。
同梱リンターをどう使うか
yomiyasu_lint.pyは、100点満点からの減点方式で文章を採点します。比喩動詞は1件につき-10点、絵文字や文末コロンなどの記号違反と過剰な太字・否定対比は-5点、名詞の過剰連続や読点過多は-3点です。Python標準ライブラリのみで動き、警告があれば終了コード1を返す厳格モードを備えるため、CIやGitフックへ組み込めます。
検査精度の作り込みも公開されています。単純な単語一致では「お握り」「主導権を握る」「卒倒」「氷を溶かす」といった正当な日本語まで違反になり、境界値テスト48本のうち46本で誤検出が出ました。そこで正規表現に前後の文脈を見る否定先読み・後読みを組み込み、物理的な事物や確立した慣用句を除外した結果、同じコーパスで誤検出が0件になったと報告されています。
設計上の意図として押さえておきたいのは、LLMが自分の文章を甘く採点する傾向への対処として、決定論的な外部検査を置いていることです。裏返せば、リンターの減点項目は作者のコーパスに合わせて較正されたものであり、自社の文章習慣とは必ずしも一致しません。導入する場合は、まず警告を出すだけの運用で既存文書を通し、自社で正当に使っている表現が減点されないかを確認してから厳格モードへ切り替える順序が安全です。MITライセンスなので、除外パターンやチーム固有の辞書を足したフォークを使う選択もできます。
導入手順と、先に知っておくべき制約
導入方法は4つ公開されています。推奨は「npx skills add nanaism/yomiyasu」で、エージェントの設定ディレクトリへ配置されます。CursorやCodexでは「npx openskills install nanaism/yomiyasu」と同期コマンドを使い、AGENTS.md経由で参照されます。Claude Codeではプラグインマーケットプレイスとして追加する方法があり、Releasesからスキルファイルを取得して手動配置することもできます。
注意点として、作者自身が他の日本語校正スキルとの同時有効化を避けるよう求めています。文体調整の指示同士が干渉し、意図しない出力になるおそれがあるためです。すでに類似スキルを入れている環境では、比較する前に一方を無効化してください。
加えて、推敲は事実確認ではありません。原文の数値や制約を損なわず、存在しない主体や仕様を追加しない方針は原則に含まれていますが、障害報告や仕様書では人によるレビューを省けません。もう1点、組織の文書をすべて同じスキルで通すと文体が揃いすぎる副作用もあります。発信者の個性を残したい媒体では、essayドメインを指定するか、適用範囲を限定する判断が要ります。
どの文書から試すか
効果が見込めるのは、読み手が複数いて誤読のコストが高く、かつAIが下書きを作った文書です。PRの説明文、障害報告、仕様書のドラフト、社内周知、技術記事が該当します。逆に、表現が法的・規約的に固定された文書や、作品性を重視する文章では、自動リライトの利得より改変リスクが上回ります。
最初の一歩としては、直近のPR説明文か障害報告を1本リンターに通し、減点の内訳を見ることをおすすめします。そこで指摘された箇所が自分でも読みにくいと感じる箇所と一致するなら、スキルによるリライトを試す価値があります。一致しないなら、まず除外パターンを調整するほうが先です。
AIが下書きを書く時間は短くても、読む側が払う時間は変わりません。yomiyasuは、その負担をどこまで書き手側で引き受けるかを、プロンプトと数値の両方で管理できる形にした実装例です。
