nanaism/yomiyasu

『yomiyasu（よみやす）』は、AIが生成した日本語の不自然な比喩、曖昧な主述関係、不要な装飾を直し、読みやすい文章に整えるスキルです。

主に技術記事、設計書・仕様書、PR説明文、社内レポートなどの実務的な文章を対象として設計されています。

Codex、Claude Code、CursorをはじめとするAIコーディング環境に読み込ませて使用してください。

開発の背景、AI生成文の読みにくさ、コーパスを使った検証については、次の解説記事で紹介しています。

• 解説記事: AI-Slopな日本語を構造レベルで読みやすくするSkill『yomiyasu（よみやす）』を作りました（Zenn）

Built with curiosity at ALGO ARTIS

AIによる文章生成は日常的な道具となりました。 一方で、AIで生成された文章には独特のクセが残りやすく、そのままでは実務や技術発信に使いにくい場面が多くあります。

これまでに様々な文体調整プロンプトやスキルが試みられてきましたが、依然として「AI特有の読みにくさ」が残るケースが見られます。

従来のアプローチが抱えていた限界は、主に次の4点でした。

1. 禁止語の置き換えにとどまる対処 手触りや解像度、泥臭いといった表層の単語を禁止しても、別の曖昧な語へ置き換わるだけで、不自然な文構造そのものは解消されませんでした。
2. 編集ルールの過剰適用 修辞規範を過度に与えると、モデルが指示を過剰に解釈し、かえって不自然な造語や大げさな文体を招いていました。
3. 主述関係の曖昧さと非生物主語 誰が何をどうするのかが省略されたまま、概念や道具が比喩的な動詞（壊れる、倒す、効くなど）と結びつき、読み手側で過剰な文脈補完が必要でした。
4. 形式の偏重と情報密度の低下 太字や箇条書きが増加する一方で、手順やコードの仕組みといった核心部分が抽象化され、文章量に対して実質的な情報が希薄化していました。

元の意味を保ち、読み違いや文の関係を追う負担がある箇所を直します。自然に読める部分は残します。

1. 主述・修飾・条件の点検 主語と述語、修飾語と掛かる先、指示語と指す対象を対応づけます。条件・例外・否定・並列・数量・順序も、書き直す前後で同じように追えるか確かめます。主体や対象を補うのは、原文や提供文脈から確定できる範囲に限ります。
2. 文の働きと文体の保持 文ごとの説明・依頼・助言・予定を区別し、働きに合わない文末だけを直します。完了した変更作業、現在の動作や方針、今後の予定を時制と役割に合わせて書き分け、語尾を散らすこと自体を目的にしません。変更指定がない常体・敬体は保ち、技術記事という分野だけで敬体へ変えません。
3. 擬人化の整理 道具や概念に感情や意志を持たせた表現を直します。道具やシステムの客観的な動作を述べる非生物主語は残します。
4. 比喩を平易な言葉へ 壊れる、倒す、効く、溶かすなどを、元の含みや意味の広さを保って言い換えます。動詞を替えた後も、主体・対象・修飾先を変えず、語順を追いやすくできるか確かめます。
5. 前置き・否定対比の役割の確認 前置きを削るのは、削っても主張や比重が変わらない場合だけです。評価や必要な対比、比較から方針へ移る接続は残します。
6. 情報を勝手に足さない 主張・比重・言い切りの強さ・文の働きを保ち、原文にない主体・原因・条件・数値・感情などを足しません。ルールを「契約」、比較の基準を「正本」と大げさに呼ぶ場合は役割に合う語へ直し、文字どおりの意味や定義済みの専門用語は保ちます。意味を確定できない箇所は、原文にある未確定の状態や既知の動作を本文に残した暫定文とし、推敲理由や確認事項は読者向け本文中ではなく本文の後に添えます。
7. 文長・読点・装飾の調整 平均文長30〜45文字、1文の読点0〜2個を目安にします。読みやすい原文の読点を、数や見た目だけで削りません。不要な文末コロンと、ラベルと値の対応を示すコロンを区別します。過剰な装飾記号を整理し、英単語や数値の前後の空白は元の書式や指定されたスタイルを保ちます。残す太字は表示される形に整えます。

ここで重要なのは、単なるパーツの共通化ではなく、組織の意思決定OSとしてのガバナンスです。

従来の開発では、画面ごとに手触り感を探りながらパーツを作っていました。しかし、片方だけを見て画面を作ると、もう片方のアクセシビリティが静かに壊れます。そこでデザインシステムという強固な土台を置くことで、開発者の解像度が一段上がります。

デザインシステム導入のメリットは、主に次の3点です。

• 開発速度の加速: コンポーネントを再利用することで、時間を溶かさずに済みます。
• 仕様の収斂: 判断に迷うスタイルは、あらかじめ共通側に倒します。
• アクセシビリティの担保: ガイドラインが規律を要求するため、事故を未然に防ぐことができます。

もちろん、これは「デザイナーが不要になる」ことを意味しません。日々の開発に地味に効いてきます。ぜひ参考にしてみてください！

デザインシステムを導入する目的は、ボタンや入力欄などのUIパーツを一から作成する負担を減らし、画面全体の情報設計に集中することにあります。

各コンポーネントの見た目やアクセシビリティ要件があらかじめ定義されていれば、デザイナーと開発者はコードの記述や画面遷移の実装を円滑に進められます。スタイルの指定に迷った場合でも、定義済みの標準コンポーネントを選択すれば表示の不整合を防ぐことが可能です。

導入によってデザイン作業そのものが不要になるわけではありません。しかし、単純なパーツ作成にかかる工数を削減することで、本来注力すべき使い勝手の検証や品質向上に時間を充てられるようになります。結果として、利用者が迷わず操作できる高品質な行政サービスの提供につながります。

比喩動詞（静かに壊れる、共通側に倒す、地味に効く、時間を溶かす）を直接的な操作や状態変化へ修正しました。また、手触り感、意思決定OS、解像度といった曖昧な流行語を排除し、具体的な作業内容を記述しています。不要な太字や過度な箇条書きを抑え、前後のつながりが自然な地の文へ再構築しました。

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

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

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

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

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

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

非同期キューを用いたメッセージ処理では、通信の切断やサーバーの再起動によって処理が中断されるおそれがあります。メッセージの二重送信が発生しても不整合を起こさないよう、受信側のプログラムで冪等性を担保する設計が不可欠です。

具体的な対策として、メッセージの固有IDをデータベースに記録し、同一IDをすでに処理済みであれば追加処理を行わずに終了します。外部APIの呼び出しに失敗した場合は、待機時間を徐々に延ばしながら再試行し、規定回数を超えて失敗したデータはデッドレターキュー（DLQ）へ退避して手動調査に回す構成をとります。エラー時の復旧手順をあらかじめ決めておけば、障害発生時にも迅速な原因究明が可能です。

前提を経路が添えるや依存構造は分割できないといった主語のない抽象文を解体し、動作主と対象を明記しました。あわせて黙ってスキップ、潰していく、時間を溶かすを正確な技術用語や操作へ置き換えています。冒頭と末尾にあった不要な煽り文句や定型文（最大の落とし穴、いかがでしたでしょうか）も削除しました。

# 新規インストール
npx skills add nanaism/yomiyasu

# 最新版へのアップデート
npx skills update yomiyasu

Claude Codeなどのエージェント設定ディレクトリへインストール・更新します。すでに導入済みの場合は npx skills update yomiyasu で最新版へ更新できます。スキル定義は skills/yomiyasu/SKILL.md の1か所に配置しています。

GitHub CLIの gh skill コマンドからインストールできます。

# 新規インストール
gh skill install nanaism/yomiyasu yomiyasu

# 最新版へのアップデート
gh skill update yomiyasu

導入先のエージェントを指定する場合は、--agent codex や --agent claude-code を追加してください。

# 新規インストールとAGENTS.mdへの反映
npx openskills install nanaism/yomiyasu
npx openskills sync

# 最新版へのアップデートとAGENTS.mdへの反映
npx openskills update yomiyasu
npx openskills sync

AGENTS.mdを経由して各エージェントから利用できるようになります。通常のルート指定で導入した環境はそのまま更新・同期できます。過去にネストされたパスを明示指定してインストールした環境では自動再配置が行われないため、元のインストール先やオプションに合わせて npx openskills install nanaism/yomiyasu を再実行してメタデータを更新したあと、更新や同期を行ってください。

/plugin marketplace add nanaism/yomiyasu
/plugin install yomiyasu@yomiyasu

プラグインマニフェストではスキルの配置先（"skills": "./skills/"）を明示的に指定しています。

導入済みのプラグインを最新版へ更新する場合は、ターミナルで次のコマンドを実行します。

# マーケットプレイスの情報を更新
claude plugin marketplace update yomiyasu

# プラグインを最新版へ更新
claude plugin update yomiyasu@yomiyasu

更新後はClaude Codeを再起動して反映してください。

Claudeのカスタムスキル登録機能（Web版など）には、登録専用のZIPを使ってください。GitHubの「Download ZIP」で取得したリポジトリ全体のZIPには、プラグイン設定や開発用ファイルも含まれ、登録できない場合があります。

登録専用のZIPには、リポジトリルートを起点とする11個のファイル（スキル本体、5つの参照文書、検査スクリプト群、ライセンス）だけを含めています。

1. 専用ZIPのダウンロード
   以下のリンクから、登録専用のZIPファイルをダウンロードします。
   yomiyasu.zip（最新版ダウンロード）
2. そのままアップロード
   ダウンロードした yomiyasu.zip を解凍せず、Claudeのスキル登録画面にそのままアップロードしてください。

他の日本語校正スキルと併用すると、指示が食い違う場合があります。出力が乱れる場合は、類似スキルを一時的に無効にして使用してください。

AIチャットやコーディングエージェントに対して、下書きを貼り付けて次のように指示します。

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

用途に特化した文体へ調整したい場合は、プロンプト内でドメインを指定してください。自然な文章で「技術記事向けに」と添えるか、「ドメイン tech」と明記して指示できます（省略時は入力内容から自動判別されます）。

この文章を技術記事向けに読みやすくして。
（ここに修正したい文章を貼り付け）

• tech（技術記事）
  技術ブログやコード解説向け。手順や仕組みを復元し、箇条書きを抑えます。「技術記事向けに」または「ドメイン tech」と指定してください。
• business（業務文書）
  仕様書やPR文、提案書向け。比喩表現を排し、境界条件や責任主体を明確にします。「業務仕様向けに」または「ドメイン business」と指定してください。
• essay（エッセイ）
  個人ブログやnote向け。大げさな教訓化を避け、素直な感情と実感を大切にします。「エッセイ向けに」または「ドメイン essay」と伝えてください。

推敲だけでなく、AIに文章を書かせる前にyomiyasuを読ませる使い方もあります。ai-garageの検証記事（2026年10月11日、v1.1.1で検証）では、Claude Opus 5.5に8種類のメモから文章を書かせ、書かせ方を4通り比べています。先にyomiyasuを読ませた文章は、メモにない内容を書き足したと指摘された回数が2回で、何も付けずに書かせた場合の60回から大きく減りました。

一方で、文章は平均356字と、依頼した500字程度より短くなりました。読みやすさの評価は4通りの中で最も低く、時間と費用も約4倍かかっています。採点はAIによるもので、文章の種類ごとの本数も少ない、1つの試験の結果です。記事では、この使い方は数字や日付、条件を正確に伝えたい文章（営業メール、障害報告書、手順書など）に向くとしています。エッセイや告知のような読み物には、何も付けずに書かせるか、依頼に一言添えるほうが向くという結論です。エッセイでは、先にyomiyasuを読ませた文章が8回の採点すべてで最下位でした。

文章の表現やMarkdownの太字を検査するPythonスクリプト群（共有モジュール markdown_visibility.py を含む）を同梱しています。外部ライブラリは不要で、Python標準ライブラリだけで動作します。

本ツールは特定の構文を対象とする簡易な検査であり、完全なMarkdownレンダラーではありません。太字が正しく表示されるかは閲覧環境によっても異なります。検出結果は見直し候補であり、検査結果の [PASS] も設定されたルールによる指摘がないことを示すだけです。文章の自然さ、意味の保持、あらゆる環境での完全な表示、誤検知がないことを保証するものではありません。指摘がゼロになるまで機械的に直すのではなく、元の文や文脈と照らし合わせて判断してください。

文章内のAIっぽさ（不自然な比喩動詞、過剰な太字・箇条書き、絵文字、文末コロン、同一文末の連続など）に加え、日本語の括弧や句読点に隣接して表示先の規則により太字として表示されない可能性がある候補（bold_not_rendered）を検査します。複数行にまたがる太字やブロック境界（引用、見出し、リスト、表）も考慮して判定します。すでに適切に表示される場合は変更しません。

このリンターは、推敲で見落としやすい表現を拾うための補助です。文章をAIが書いたかどうかを判定する道具ではありません。同梱の評価用コーパス（tests/corpus/）で測ると、人が書いた文章16本の平均点は98.7点、AIが書いた文章26本の平均点は95.6点でした。中央値はどちらも100点で、100点の文章は人の文章で16本中12本、AIの文章で26本中17本ありました。点数で人の文章とAIの文章をどれだけ見分けられるかを表すAUC（0.5なら偶然と同じ、1.0なら完全に見分けられる）は0.56で、偶然とほとんど変わりません。AIの26本には、AIらしい表現を詰め込んで作った例が2本（50点と78点）入っています。この2本を除き、モデルに書かせた24本だけで測ると、平均点は98.3点、AUCは0.53です。点数が高いことは、人が書いた証拠にはなりません。

# Markdownファイルを検査
python3 scripts/yomiyasu_lint.py README.md

# 警告があれば終了コード1を返す厳格モード（CIやGitフック用）
python3 scripts/yomiyasu_lint.py article.md --strict

# JSON形式で結果を出力
python3 scripts/yomiyasu_lint.py article.md --json

============================================================
AIっぽさ 検査レポート (スコア: 100/100)
============================================================
・文字数: 1420 | 行数: 85
・太字頻度: 1,000字あたり 1.4 個 (推奨: 2.0以下 / 警告: 3.0超)
・箇条書き比率: 8.2% (推奨: 15%以下 / 警告: 25%超)
------------------------------------------------------------
[PASS] 設定された検査ルールによる指摘はありません。

推敲前と推敲後を比較し、語の増減、文末の種類や立場（勧め／決まり／説明）の変化、太字の表示を点検するツールです。意図しない意味の変化を見直すための候補を出しますが、意味が同じかどうかを自動で確定するものではありません。

あわせて、推敲の前後で文を1文ずつ対応させ、文の種類を示す表現が消えたり増えたりした文を示します。対象は、伝聞（「〜とされる」「〜によると」）、推量（「〜らしい」「〜だろう」）、意見（「〜と思う」）、例え（「まるで〜」）、依頼や決まり（「〜してください」「〜べき」）です。文ごとに比べるので、別々の文で1つ消えて1つ増えた場合も示せます。ただし、文の対応は字面の重なりでたどるため、大きく言い換えた文や順番を大きく入れ替えた文では、変化を取りこぼしたり、対応しない文どうしを比べた候補が出たりすることがあります。2つの文を1つにつないだときに、つないだ文の中で表現が別の部分に移った場合も、候補に出ないことがあります。候補に出なかった文も、元の文と読み比べてください。

# 原文と推敲後の差分を検査（文書の立場を指定）
python3 scripts/yomiyasu_diff.py 元の文.md 書き直した文.md --stance=説明

# 文末の種類（敬体・常体・立場）の分布のみを確認
python3 scripts/yomiyasu_diff.py --endings 対象文.md

.
├── .claude-plugin/                   # Claude Code用プラグイン設定
│   ├── plugin.json
│   └── marketplace.json
├── README.md                         # 本ドキュメント
├── LICENSE                           # ライセンス（MIT）
├── UNICODE-LICENSE.txt               # Unicodeデータの著作権・許諾通知
├── scripts/                          # 付属検査ツール群
│   ├── yomiyasu_lint.py             # 静的検査スクリプト（AIっぽさ・太字構文検査）
│   ├── yomiyasu_diff.py             # 差分検査スクリプト（推敲前後の意味・文末比較）
│   └── markdown_visibility.py       # Markdown構造・表示判定の共有モジュール
├── references/                       # スキル参照ドキュメント
│   ├── gemini-syntax.md              # 構文変換原則
│   ├── slop-catalog.md               # 不自然な語彙・構文カタログ
│   └── domains/                      # ドメイン別指針（tech, business, essay）
├── skills/                           # 配布用スキル（唯一のSKILL.mdと参照文書・検査ツール）
│   └── yomiyasu/
│       ├── SKILL.md
│       ├── references/
│       └── scripts/
├── tests/                            # 単体テスト・回帰テストスイート
│   ├── test_bold_multiline.py        # 複数行太字・境界検査テストスイート
│   └── fixtures/                     # 回帰テスト用フィクスチャ（50ケース）
└── evals/                            # 評価データ
    └── comparison_benchmark.md       # オープンライセンス文章を用いた比較検証データ

開発では、ALGO ARTIS 社内でのLLM文章に関する議論、先行調査、学術論文、既存の文体調整ツールを参考にしました。各資料から学んだ点を紹介します。スキルの具体的な編集ルールや数値の目安は独自に決めたものであり、引用した研究がその効果を保証するものではありません。

• AI臭い文章とは何なのか（Speaker Deck） — nasuvitz氏
  AI特有の読みにくさは単語選び以上に統語構造（SVOCM）の破綻や非生物主語に起因するという指摘を参考にしました。「誰が何をどうした」を1文ごとに完結させる原則の策定に役立てています。
• Qiitaの7万記事を数えてみた話 — 逆瀬川氏
  AI普及後に生じた形式のインフレ（太字や箇条書きの急増）と手順の希薄化を定量的に示した調査です。技術記事における太字頻度やリスト比率の制限、手順復元指針の根拠として活用しました。
• Gemini 3.8 Flashこそ日本語執筆の救世主だった（X） — まつにぃ氏（@yugen_matuni）
  自然な助詞配置と主述の結びつきを持つ日本語構造に着目する契機となりました。その統語特性を分析し、プロンプト指示として定式化しています。
• AI語に親しむ / AI語を受容する — ktrmnm氏
  AI特有の比喩動詞や直訳調の構文パターン分析を参考にしました。比喩動詞の技術的操作化や、不要な否定対比の平文化ルールに反映させています。
• AIの作文はなぜつまらないのか？ / なぜAI臭さを消したいのか？ — laiso氏
  過剰な包装紙（前置フィラーや定型クロージング）への批評や、型を押し付けることへの注意点を参照しました。前置きの排除や、生活実感・身体性を残す方針に活かしています。

• Yamashita et al., Evaluation of Document-Level Text Simplification in Japanese, LREC 2026
  必要情報、意味保持、文の平易さを分けて評価する設計の参考としました。
• Jeong, Park & Yu, Right at My Level: A Unified Multilingual Framework for Proficiency-Aware Text Simplification, ACL 2026
  原文内容の脱落と、根拠のない情報付加を別々に検証するアプローチを参考にしています。
• Ide et al., Towards Automated Lexicography: Generating and Evaluating Definitions for Learner's Dictionaries, 2026
  局所的な問題箇所の特定と修正を通じて、文全体の整合性を保つ手法の参考にしました。
• Nohejl et al., A Japanese Dataset and Efficient Multilingual LLM-Based Methods for Lexical Simplification and Lexical Complexity Prediction, 自然言語処理 32巻4号
  語の平易化における文法性と意味保持のバランスを検討する基礎としています。
• 八木ほか, 多文化共生を目指した『やさしい日本語』における大規模言語モデルのプロンプトデザインの検証, 人間中心設計 22巻1号
  プロンプト内の例示設計とモデルの挙動特性に関する知見を参考にしました。
• Chen, Yue & Davidge, Comparing generative AI with native speakers in terms of request expressions in Japanese, Discover Education 2025
  相手との距離感を保ち、主語や敬語を一律に過剰付加しない判断の参考にしています。
• Zaitsu et al., Stylometry can reveal artificial intelligence authorship, but humans struggle, PLOS One 2025
  AIらしさの検出と読みにくさの判定を区別して扱う論理的根拠としました。
• 三浦・久保山, 生成AIは文体を均質化するのか？, 人工知能学会 2026 / 林・相澤, LLMによる日本語生成におけるモデル固有表現パターンの分析, 言語処理学会 2026
  文体の画一化を避け、書き手らしさや文末の自然な交差を尊重する視点を学びました。
• 李・長谷部, ChatGPTによる日本語ニュースの平易化―生成AIと『やさしい日本語』―, 計量国語学 34巻8号
  数値上の単純化と、人間にとって自然な編集の差異を踏まえるための指針としています。
• 書式および語彙の偏りに関する研究群（ACL 2025 書式バイアス研究, COLING 2025 語彙偏り研究, Miklian et al. 2026）
  強調やリストへの評価偏向、英語直訳思考の影響を理解するための補助資料として活用しました。

• natural-japanese, stop-ai-slop-jp, japanese-tech-writing, cognitive-rhythm-writing, humanizer
  読者に応じた編集、専門用語や条件の保持、文の長さや区切り方などを参考にしました。各作者に感謝します。

• 千早耿一郎『悪文の構造――機能的な文章とは』 公開図解と確認した本文を参考に、主語・述語・修飾先などの関係を分析し、書き直した後も照合する点検を加えました。意味保持の既存ルールと組み合わせた独自の指示であり、本書の全手順を再現するものではありません。

• 「AIっぽい文章を直すスキル」に、うちの日記を通したら、ほとんど直されなかった 自然な文を不要に変更しないことと、保存済みサンプルの意味を原文と照合することを、検証項目として見直しました。
• 流行りの「AI日本語推敲スキル」を使う前にやっておきたいこと 説明すると述べた対象や関係が、本文から読み取れるかを確認する観点を参考にしました。

開発者: 大賀 愛一郎（oga_aiichiro）@ALGO ARTIS
宛先: @oga_aiichiro

※ 本スキルおよび本リポジトリは個人の研究・創作物であり、所属企業の公式プロダクトや見解を代表するものではありません。

本リポジトリのコードおよびドキュメントは MIT License のもとで公開しています。同梱しているUnicode由来データの著作権・許諾通知は UNICODE-LICENSE.txt に記載しています。検証や引用に用いた外部資料の権利は各著作者に帰属し、それぞれの利用規約（CC BY 4.0等）に従うものとします。

yomiyasuを記事や動画、SNS、勉強会などで紹介・解説していただけると嬉しいです！ 作者への連絡や許可はいりません。

ただし、yomiyasuは無料で公開しているオープンソースのスキルで、正式な配布元はこのリポジトリだけです。 yomiyasuを紹介・同梱する有料の教材や情報商材、yomiyasuとの関連をうたうトークンや暗号資産に、作者は一切関わっておらず、収益も受け取っていません。

yomiyasuは、多くの先行研究や公開された知見をもとに作っています。 そのため作者は、これまでもこれからも、yomiyasuそのもので利益を得るつもりはありません。

このREADMEは、『yomiyasu』を用いて推敲されています。