v1.0.2

yomiyasu v1.0.2

v1.0.1への実務フィードバックに基づき、「削るだけでなく不要な情報が足されてしまう問題（足し算スロップ）」の根絶、および「文と文の論理的なつながり・段落構造の整流」を行う大型アップデートです。

---

1. 背景と課題（v1.0.1で浮き彫りになった課題）

v1.0.1の運用において、以下の課題が寄せられました。

1. 不要な情報の増補（足し算スロップ）:
   • 箇条書きを地の文へ統合する際に、原文にない「〜が大切です」「〜する必要があります」「〜ことが挙げられます」といった評価・義務表現を勝手に足してしまう。
   • 非生物主語を直す際に、単なる道具の客観的な説明文まで「〜を使えば〜できます」と条件や可能を足してしまう。
2. 文末の働きの勝手な改変:
   • 元の文が持つ「〜しましょう」「〜してください」「〜します」などの文末の種類を勝手に「〜できます」に変えてしまい、筆者の意図（要請か提案か説明か）が歪む。
3. 文と文のつながり・段落構造の乱れ:
   • つなぎ言葉（ただし、しかし、また、そのため等）の接続先が曖昧なまま放置される。
   • 中身のない予告文（「以下の点があります」等）が残ってしまう。
   • 1つの段落に複数の異なる話題が混ざってしまう。
4. 「壊れる」の過度な狭小化:
   • データやシステムに対する「壊れる」を一律に「整合性が失われる」と置き換えたことで、サービス停止や単なる不具合に対して事実を狭めすぎていた。

---

2. v1.0.2 での主な改善内容

① 文末の働きの完全維持（R1）

「〜しましょう」「〜してください」「〜します」「〜です」の種類を元の文のまま維持します。読者への要請を「〜してください」、機能説明を「〜できます」とする整理は、元の文が依頼か説明か曖昧な場合のみに限定し、勝手な可能化・義務化を防止しました。

② 箇条書き平文化時の足し算禁止（R2）

箇条書きを地の文にする際、元にない評価や義務（〜が大切です、〜する必要があります等）の付加を全面禁止しました。単なる並列項目であれば、箇条書きのまま残すことも許容しています。

③ 非生物主語の「擬人化」限定解体（R3）

道具や概念に感情や意志を持たせている擬人化表現のみを解体対象とし、道具や仕組みの客観的な機能説明（「このツールはログを収集します」等）はそのまま維持します。元にない条件（〜を使えば）や可能（〜できます）の勝手な付加も禁止しました。

④ 「壊れる」の言い換え幅の是正（R6）

データやシステムに対する「壊れる」は、一律に「整合性が失われる」と狭めず、「おかしくなる」「使えなくなる」といった元の文と同等の広さを持つ平易な言葉に改めました（明らかに整合性の文脈であることが明らかな場合のみ専門用語を適用）。

⑤ 段落と文の論理構造の整流（原則13の新設）

• 接続詞・指示語の検証: つなぎ言葉や指示語が前後の文と正しく論理的につながっているかを検証する手順を導入。
• 中身のない予告文の解消: 「注目すべき点があります」などの予告文を中身の文と1文に統合し、予告の重みを述語へ残す。
• 1段落1話題の徹底: 話題の異なる段落同士の安易な統合を防止。

⑥ 差分検査スクリプト（yomiyasu_diff.py）の同梱（R12, R13）

推敲前後のテキストを比較し、言い回しの種類の増減（依頼・義務・評価等）や新しい語の混入、接続関係を機械的に検出するスクリプトを同梱しました（scripts/yomiyasu_diff.py）。推敲プロセスの最後にこのDiff検査を組み込み（Step 4）、勝手な足し算や接続の乱れを防止します。

⑦ 出力フォーマットの刷新（R14）

形式的なひな形を廃止し、実際に変更した箇所と理由のみを報告する4部構成に刷新しました。

• 書き直した本文
• 変えたところ（最大5点、元 → 後と理由）
• 残したAIっぽいところ（意味を担っているため残した表現の確認）
• 書き手に確かめたい点（判断に迷った点のみ最大2点）

⑧ 対象とする文章の明記

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

---

3. インストールとアップデート

新規インストール

npx skills add nanaism/yomiyasu

既存環境のアップデート

npx skills update yomiyasu

v1.0.1

yomiyasu v1.0.1

『yomiyasu（よみやす）』は、AIが書いた不自然な日本語を、人間が読みやすく情報密度の高い自然な文章へ推敲する Agent Skill です。

本バージョン（v1.0.1）では、v1.0.0 の公開後に確認された「文の働きやすり替えによる意味の変化」「言い回しの含み（ニュアンス）の欠落」「データに対する比喩動詞（壊れる）の曖昧さや過度な推量への弱まり」を根本から解消するため、指示と例文を全面的に見直しました。

---

1. 改善前の課題と具体的な発生例

文体リンターで100点（指摘ゼロ）が出ている文でも、人の目で見ると「言っていることの意味が変わっている」「AIっぽい比喩が残っている」「勝手に推量に弱められている」という状態が生じていました。主な原因と具体例は次のとおりです。

① データやシステムに対する比喩動詞「壊れる」の曖昧さと推量への弱まり

• 原文: 「単にメッセージを流すだけでは、背後でデータが静かに壊れます。」
• 従来の課題:
  • データは物理的な機械ではないため「データが壊れる」は英語（"silently corrupts"）の直訳やAI特有の曖昧な比喩です。
  • 一方で、書き直し時に「〜整合性が失われるおそれがあります」と勝手に推量に弱めてしまったり、逆に「データが壊れます」をそのまま残してAI臭さが残るという問題がありました。
• 改善策:
  • 時計や機械など物理的な物体や身体（お腹を壊す等）の文字どおりの「壊れる」のみ残し、データやシステムに対しては「データの整合性が失われる」「不整合が生じる」のように客観的・技術的な表現に具体化します。
  • 「壊れます」という言い切りの強さ（断定）は弱めずそのまま維持します。

② 文の働きやすり替えによる意味の変化

• 評価の文が、予定や指示の文に変わる
  • 原文: 「ここで重要なのは、単なるパーツの共通化ではなく、組織の意思決定OSとしてのガバナンスです。」
  • v1.0.0: 「パーツの共通化に加えて、組織の意思決定の仕組みとしてガバナンスを整備します。」
  • 問題: 「何が大事か」を評価している文だったのに、予定やアクションの文（整備します）にすり替わり、「AではなくB」の対比や比重も崩れていました。

③ 比喩や言い回しが持っていた「含み（気持ちや評価の向き）」の欠落

• 原文: 「ここで地味に効いてくるのが、ログの粒度です。」
• v1.0.0: 「この場面では、ログの粒度が役に立ちます。」
• 問題: 「地味に」にあった「目立たないけれど確実に効く」という含みが消え、平らな表現になっていました。「うっかり」の不注意、「ようやく」の待ちくたびれた感じ、「〜てしまった」の後悔なども同様に削ぎ落とされていました。

④ 「静かに」「黙って」を狭い意味に決めつける

• 原文: 「設定を一つ間違えるだけで、ビルドが黙って通ってしまいます。」
• v1.0.0: 「何の通知も出ないまま」「通知なく通ります」
• 問題: 「通知」という仕組みや受け取る人の存在を勝手に前提にしてしまい、翻訳調で意味が狭くなっていました。文脈上通知の有無が明示されていない限り、「気づかないうちに」「知らないうちに」という本来の幅で書く必要があります。

⑤ ふつうの慣用句まで言い換えてしまう

• AIが好む比喩（「倒す」「効く」「溶かす」など）だけでなく、「骨が折れる」「手を焼く」「目から鱗が落ちる」のような、昔から日本語として定着している自然な慣用句までAI臭い比喩と誤認して言い換えてしまい、文章が冗長になっていました。

---

2. v1.0.1 での主な改善内容

1. 「意味の4軸」を最優先ルールとして定義

文の見た目を整える前に、次の4つの軸を原文と必ず一致させるルールを最上位に置きました。

1. 主張（何を言っているか）: 「本質」「核」を勝手に「目的」などにすり替えない。
2. 比重（何を大事とし、何を軽く扱うか）: 「AではなくB」の対比関係と重要度を崩さない。
3. 言い切りの強さ（断定・推量・可能性）: 原文の言い切りの強さを勝手に強めたり弱めたりしない（「壊れる」を「おそれがある」に弱めない）。
4. 文の働き（評価・説明・指示・予定）: 評価の文は評価のまま残し、指示や予定に書き換えない。

2. データ・抽象物への「壊れる」の客観化・技術用語化

• 時計や機械など物理的な物体や身体の文字どおりの「壊れる」は維持します。
• 一方、データ・キャッシュ・設計・ビルド等に対する「壊れる」はAI直訳・比喩として、「データの整合性が失われる」「不整合が生じる」「破綻する」など客観的・技術的な表現に具体化します（「データの整合性」のような正当な専門用語は無理に排除しません）。

3. 「含み」を残し、ふだん使う言葉で補う

比喩動詞の言い換え時、その語が持っていた気持ちや評価の向き（地味に、うっかり、ようやく等）は、削ぎ落とさずふだん使う日常の言葉で補って言い表す方針に改めました。

4. 「気づけない幅」を保った自然な表現への修正

「静かに」「黙って」は、仕組みを勝手に想定した「通知なく」ではなく、「気づかないうちに」「知らないうちに」と認知の幅のまま書くように統一しました（エラーや通知の有無が文脈上明らかな場合を除く）。

5. 定着した慣用句の判定ルールの追加

「その言い方を、AIが広まる前の人間の文章でもふつうに見かけるかどうか」を基準とし、自然な慣用句（骨が折れる、手を焼く等）はそのまま残すようにしました。

6. 「書き手に確かめたい点」の出力条件を整理

推敲時に実際に補うか迷った点（勝手な補足を避けた点）のみ最大2点に絞り、迷いがなければ項目ごと省略して出力が冗長にならないようにしました。

---

3. 具体的な改善例（Before / After）

原文（Before）	改善前（課題あり）	v1.0.1 での出力（改善後）	改善のポイント
単にメッセージを流すだけでは、背後でデータが静かに壊れます。	メッセージを送信するだけでは、エラーが出ないままデータの整合性が失われるおそれがあります。	単にメッセージを送るだけでは、気づかないうちに裏でデータの整合性が失われます。	データに対する比喩動詞「壊れる」を「データの整合性が失われます」と客観的な技術状態に具体化。言い切りの強さ（断定）を弱めずに維持し、「静かに」のぼかしも「気づかないうちに」と自然に表現。
ここで重要なのは、単なるパーツの共通化ではなく、組織の意思決定OSとしてのガバナンスです。	パーツの共通化に加えて、組織の意思決定の仕組みとしてガバナンスを整備します。	単なるパーツの共通化そのものではなく、組織の意思決定の基盤となるガバナンスが重要です。	「〜が重要です」という評価文の働きを維持し、「AではなくB」の比重と対比構造を保持。
ここで地味に効いてくるのが、ログの粒度です。	この工夫をしておくと、後々の運用で役に立ちます。	この場面では、ログの粒度が目立たないながらも確かに役立ちます。	「地味に」が持っていた「目立たないけれど確実にある」という含みを落とさず表現。
設定を一つ間違えるだけで、ビルドが黙って通ってしまいます。	設定を1つ間違えるだけで、何の通知も出ないままビルドが通ってしまいます。	設定を1つ間違えるだけで、気づかないうちにビルドが通ってしまいます。	「通知」という仕組みを勝手に前提にせず、「気づかないうちに」という自然な日本語で記述。

---

4. 検証結果（7文でのブラインドテスト）

独立した日本語編集者エージェントにより、意味の変化や「含み」の脱落を厳しく検証しました。

検証項目	評価	判定詳細
「意味が変わっている」判定	0件（0/7文）	主張・比重・言い切りの強さ・文の働きがすべて完全に一致
AIっぽさの脱臭	100% 合格（7/7文）	比喩動詞、未定義造語、不要な前置き、装飾をすべて解消
技術的表現の客観化	合格	「データが壊れる」等の安易なAI比喩を「データの整合性が失われる」と正確に記述
言い切りの強さの維持	100% 一致	断定を勝手に推量や可能性（おそれがある等）に弱めない

「AI特有の不自然な言い回しや曖昧な比喩を解消しながら、元の文が伝えたかった意味や技術的な正確さを1ミリも損なわない」という品質を実現しました。

v1.0.0

Initial release of yomiyasu