yomiyasu（よみやす）
これは何？
『yomiyasu（よみやす）』は、AIが生成した日本語の不自然さを解消し、人間が読みやすく情報密度の高い日本語へ推敲するためのスキルです。
Codex、Claude Code、CursorをはじめとするAIコーディング環境に読み込ませて使用してください。
開発背景や言語学的病理の分析、複数のコーパスによる検証結果については、以下の解説記事で詳しく紹介しています。
Built with curiosity at ALGO ARTIS
株式会社 ALGO ARTIS は、私たちが社会基盤の最適化に取り組んでいるスタートアップです。
電力・海運・鉄道・化学プラントといった現場では、膨大な制約が絡み合う複雑な運用計画を、今なお熟練者が手作業で組み立てています。
弊社では、そうした高度な現場業務を数理モデル化し、実用的なヒューリスティック最適化アルゴリズムと業務システムを一貫して自社開発しています。
背景と課題
AIによる文章生成は日常的な道具となりました。一方で、生成された文章には独特のクセが残りやすく、そのままでは実務や技術発信に使いにくい場面が多くあります。
これまでに様々な文体調整プロンプトやスキルが試みられてきました。しかし、依然として「AI特有の読みにくさ」が残るケースが見られます。
従来のアプローチが抱えていた限界は、主に次の4点でした。
- 禁止語の置き換えにとどまる対処
手触りや解像度、泥臭いといった表層の単語を禁止しても、別の曖昧な語へ置き換わるだけで、不自然な文構造そのものは解消されませんでした。 - 編集ルールの過剰適用
修辞規範を過度に与えると、モデルが指示を過剰に解釈し、かえって不自然な造語や大げさな文体を招いていました。 - 主述関係の曖昧さと非生物主語
誰が何をどうするのかが省略されたまま、概念や道具が比喩的な動詞（壊れる、倒す、効くなど）と結びつき、読み手側で過剰な文脈補完が必要でした。 - 形式の偏重と情報密度の低下
太字や箇条書きが増加する一方で、手順やコードの仕組みといった核心部分が抽象化され、文章量に対して実質的な情報が希薄化していました。
本スキルのアプローチ
本スキルは、文章の骨格である統語構造を7つの変換原則として体系化し、主要なLLM環境で自然な日本語へ推敲できるように設計しています。
7つの変換原則
- SVOCMの完全復元
動作主（開発者、運用者、システムなど）を明確にし、曖昧な指示代名詞（これ、両者、片方など）を具体的な名詞へ復元しています。文単体で意味が通じる構造を維持しています。 - 動作主と働きかけの明確化
仕様書や案内文において主体を曖昧にせず、読者への要請は「〜してください」、機能説明は「〜できます」と役割を整理しています。 - 非生物主語の解体
概念や道具があたかも意思を持つような表現を排し、人間やシステムの客観的な動作へ書き換えています。 - 比喩動詞の技術的操作化
壊れる、倒す、効く、溶かす、潰すといった比喩表現を、直接的な操作や客観的な状態変化へ置き換えています。 - 不要な前置きと否定対比の肯定化
「重要なのは」といった前置きを省き、二重否定や修辞的対比を簡潔な肯定文へ再編しています。 - 意味保持と不要な情報増補の防止
原文の技術的制約や数値を損なわず、AI特有の免責事項や一般論を削っています。原文に存在しない主体や仕様を勝手に追加せず、客観的事実のみを残しています。 - 呼吸に合った文長と読点・装飾の抑制
平均30〜45文字を目安とし、1文あたりの読点を0〜2個に抑えています。絵文字、文末コロン、過剰な太字や不要な半角空白を排除しています。
変換例と検証データ
オープンライセンス（政府標準利用規約2.0 / CC BY 4.0互換）の公的文書およびOSS設計ノートを題材に、素のLLM出力と本スキルによる推敲出力を比較検証しました。
比較例1: 業務・仕様解説
修正前のAI生成文
ここで重要なのは、単なるパーツの共通化ではなく、組織の意思決定OSとしてのガバナンスです。
従来の開発では、画面ごとに手触り感を探りながらパーツを作っていました。しかし、片方だけを見て画面を作ると、もう片方のアクセシビリティが静かに壊れます。そこでデザインシステムという強固な土台を置くことで、開発者の解像度が一段上がります。
デザインシステム導入のメリットは、主に次の3点です。
- 開発速度の加速: コンポーネントを再利用することで、時間を溶かさずに済みます。
- 仕様の収斂: 判断に迷うスタイルは、あらかじめ共通側に倒します。
- アクセシビリティの担保: ガイドラインが規律を要求するため、事故を未然に防ぐことができます。
もちろん、これは「デザイナーが不要になる」ことを意味しません。日々の開発に地味に効いてきます。ぜひ参考にしてみてください！
本スキル適用後
デザインシステムを導入する目的は、ボタンや入力欄などのUIパーツを一から作成する負担を減らし、画面全体の情報設計に集中することにあります。
各コンポーネントの見た目やアクセシビリティ要件があらかじめ定義されていれば、デザイナーと開発者はコードの記述や画面遷移の実装を円滑に進められます。スタイルの指定に迷った場合でも、定義済みの標準コンポーネントを選択すれば表示の不整合を防ぐことが可能です。
導入によってデザイン作業そのものが不要になるわけではありません。しかし、単純なパーツ作成にかかる工数を削減することで、本来注力すべき使い勝手の検証や品質向上に時間を充てられるようになります。結果として、利用者が迷わず操作できる高品質な行政サービスの提供につながります。
主な改善点
比喩動詞（静かに壊れる、共通側に倒す、地味に効く、時間を溶かす）を直接的な操作や状態変化へ修正しました。また、手触り感、意思決定OS、解像度といった曖昧な流行語を排除し、具体的な作業内容を記述しています。不要な太字や過度な箇条書きを抑え、前後のつながりが自然な地の文へ再構築しました。
比較例2: 技術解説
修正前のAI生成文
非同期処理における最大の落とし穴は、ネットワークの瞬断です。
依存構造は分割できない。動かしながら引き返す。
単にメッセージを流すだけでは、背後でデータが静かに壊れます。前提を、経路が代わりに添えてくれるわけではありません。
そこで地味に効いてくるのが、以下の3つの原則です。
- 冪等性の担保: 重複した処理は黙ってスキップします。
- 安全なリトライ: 指数バックオフを挟むことで、DBの負荷を逃がします。
- DLQへの退避: 破綻したメッセージは隔離し、原因を1つずつ潰していきます。
デバッグで丸一日時間を溶かさないためにも、この境界線を意識した設計が不可欠です。いかがでしたでしょうか。
本スキル適用後
非同期キューを用いたメッセージ処理では、通信の切断やサーバーの再起動によって処理が中断されるおそれがあります。メッセージの二重送信が発生しても不整合を起こさないよう、受信側のプログラムで冪等性を担保する設計が不可欠です。
具体的な対策として、メッセージの固有IDをデータベースに記録し、同一IDをすでに処理済みであれば追加処理を行わずに終了します。外部APIの呼び出しに失敗した場合は、待機時間を徐々に延ばしながら再試行し、規定回数を超えて失敗したデータはデッドレターキュー（DLQ）へ退避して手動調査に回す構成をとります。エラー時の復旧手順をあらかじめ決めておけば、障害発生時にも迅速な原因究明が可能です。
主な改善点
前提を経路が添えるや依存構造は分割できないといった主語のない抽象文を解体し、動作主と対象を明記しました。あわせて黙ってスキップ、潰していく、時間を溶かすを正確な技術用語や操作へ置き換えています。冒頭と末尾にあった不要な煽り文句や定型文（最大の落とし穴、いかがでしたでしょうか）も削除しました。
インストール
1. npx skills add（推奨）
npx skills add nanaism/yomiyasu
Claude Codeなどのエージェント設定ディレクトリへインストールします。
2. npx openskills install（Cursor / Codexなど）
npx openskills install nanaism/yomiyasu
npx openskills sync
AGENTS.mdを経由して各エージェントから利用できるようになります。
3. Claude Code プラグイン
/plugin marketplace add nanaism/yomiyasu
/plugin install yomiyasu@yomiyasu
4. 手動配置
Releasesからyomiyasu.skillをダウンロードし、エージェントのスキルディレクトリに展開して配置してください。
他の日本語校正スキルとの干渉について
文体調整や文章校正を目的とした他のエージェントスキルが同一環境で同時に有効化されている場合、指示同士が干渉し合って意図しない出力になるおそれがあります。本スキルを利用する際は、類似の日本語校正スキルを一時的に無効化して使用してください。
使い方
AIチャットやコーディングエージェントに対して、下書きを貼り付けて次のように指示します。
この文章を読みやすくして。
（ここに修正したい文章を貼り付け）
ドメインの指定
用途に特化した文体へ調整したい場合は、プロンプト内でドメインを指定してください。自然な文章で「技術記事向けに」と添えるか、「ドメイン tech」と明記して指示できます（省略時は入力内容から自動判別されます）。
この文章を技術記事向けに読みやすくして。
（ここに修正したい文章を貼り付け）
- tech（技術記事）
技術ブログやコード解説向け。手順や仕組みを復元し、箇条書きを抑えます。「技術記事向けに」または「ドメイン tech」と指定してください。 - business（業務文書）
仕様書やPR文、提案書向け。比喩表現を排し、境界条件や責任主体を明確にします。「業務仕様向けに」または「ドメイン business」と指定してください。 - essay（エッセイ）
個人ブログやnote向け。大げさな教訓化を避け、素直な感情と実感を大切にします。「エッセイ向けに」または「ドメイン essay」と伝えてください。
付属ツール: yomiyasu_lint.py（AIっぽさ数値化リンター）
文章内のAIっぽさ（不自然な比喩、過剰な太字・箇条書き、絵文字、文末コロン、同一文末の連続など）を数値化して検査できるPythonスクリプトを同梱しています。外部ライブラリへの依存はなく、Python標準ライブラリのみで動作します。
# Markdownファイルを検査
python3 scripts/yomiyasu_lint.py README.md
# 警告があれば終了コード1を返す厳格モード（CIやGitフック用）
python3 scripts/yomiyasu_lint.py article.md --strict
出力例
============================================================
AIっぽさ 検査レポート (スコア: 100/100)
============================================================
・文字数: 1420 | 行数: 85
・太字頻度: 1,000字あたり 1.4 個 (推奨: 2.0以下 / 警告: 3.0超)
・箇条書き比率: 8.2% (推奨: 15%以下 / 警告: 25%超)
------------------------------------------------------------
[PASS] AIっぽさは検出されませんでした。設定された検査ルールによる指摘はありません。
リポジトリ構成
.
├── .claude-plugin/ # Claude Code用プラグイン設定
│ ├── plugin.json
│ └── marketplace.json
├── SKILL.md # スキルエントリポイント
├── README.md # 本ドキュメント
├── scripts/
│ └── yomiyasu_lint.py # 静的検査スクリプト
├── references/
│ ├── gemini-syntax.md # 構文変換原則
│ ├── slop-catalog.md # 不自然な語彙・構文カタログ
│ └── domains/ # ドメイン別指針（tech, business, essay）
└── evals/
└── comparison_benchmark.md # オープンライセンス文章を用いた比較検証データ
謝辞・参考文献
本スキルの開発にあたり、社内でのLLM文章に関する議論から設計の着想を得ました。また、先行調査、コミュニティの知見、学術論文、既存の文体調整ツールから多大な示唆を受けています。ここに深く感謝を申し上げます。各資料から学んだ知見と、本スキルへの反映内容は次の通りです。
1. コミュニティの先行調査
- AI臭い文章とは何なのか（Speaker Deck） — nasuvitz氏
AI特有の読みにくさは単語選び以上に統語構造（SVOCM）の破綻や非生物主語に起因するという指摘を参考にしました。「誰が何をどうした」を1文ごとに完結させる原則の策定に役立てています。 - Qiitaの7万記事を数えてみた話 — 逆瀬川氏
AI普及後に生じた形式のインフレ（太字や箇条書きの急増）と手順の希薄化を定量的に示した調査です。技術記事における太字頻度やリスト比率の制限、手順復元指針の根拠として活用しました。 - Gemini 3.8 Flashこそ日本語執筆の救世主だった（X） — まつにぃ氏（@yugen_matuni）
自然な助詞配置と主述の結びつきを持つ日本語構造に着目する契機となりました。その統語特性を分析し、プロンプト指示として定式化しています。 - AI語に親しむ / AI語を受容する — ktrmnm氏
AI特有の比喩動詞や直訳調の構文パターン分析を参考にしました。比喩動詞の技術的操作化や、不要な否定対比の平文化ルールに反映させています。 - AIの作文はなぜつまらないのか？ / なぜAI臭さを消したいのか？ — laiso氏
過剰な包装紙（前置フィラーや定型クロージング）への批評や、型を押し付けることへの注意点を参照しました。前置きの排除や、生活実感・身体性を残す方針に活かしています。
2. 日本語処理・テキスト平易化に関する学術研究
- 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号
数値上の単純化と、人間にとって自然な