Skip to content

Yomiyasu

AI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese

Install

$/plugin marketplace add nanaism/yomiyasu

Install command taken from the project's README or registry entry. Always review code before running it.

yomiyasu(よみやす)

これは何?

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

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

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

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

Built with curiosity at ALGO ARTIS

ALGO ARTISについて

株式会社ALGO ARTISは、社会基盤の最適化に取り組むスタートアップです。

電力・海運・化学プラントといった現場では、膨大な制約が絡み合う複雑な運用計画を、今なお熟練者が手作業で組み立てています。

そうした高度な現場業務を数理モデル化し、実用的なヒューリスティック最適化アルゴリズムと業務システムを一貫して開発しています。

最適化技術を用いた社会インフラの変革に興味がある方は、公式ウェブサイトや採用情報をご覧ください。

背景と課題

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

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

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

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

本スキルのアプローチ

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

7つの変換原則

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

Before → After 例

例1: 業務・仕様解説

Before

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

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

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

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

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

After

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

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

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

変更説明

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

例2: 技術解説

Similar plugs

Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local…

Why use many token when few token do trick. Viral skill + proxy for coding agents that cuts 65% of tokens by talking like a caveman.

The 1st Collaborative AI Design Agent Workspace. Local-first and open source. Create prototypes, websites, apps, dashboards, presentations, images, and videos with your team…