yomiyasu · diff
git:20261001.7b61b2f to git:20261001.c9aca1a
62 added, 34 removed. Audit A to A.
---
name: yomiyasu
description: AIが生成した不自然な日本語を、人間が読みやすく情報密度の高い自然な文章へ書き直すAgent Skill。「この文章を読みやすくして」「aiっぽさをなくして」「AI臭さを消して」「自然な日本語にして」「文章を脱臭して」という依頼や、技術記事、業務仕様書・PR説明文、エッセイ・noteの推敲時に使用する。非生物主語の解体、比喩的動詞の具体化、絵文字や文末コロンの完全排除、不要な補足カッコの削除、英単語前後の不自然な半角空白の排除、過剰な太字・箇条書き・否定対比の平文化を行い、文単体で誰が何をどうしたかが伝わる文章へ再構築する。
license: MIT
argument-hint: "[リライト対象のテキストやファイルパス] [--domain tech|business|essay] [--full]"
---
# yomiyasu
AI特有のスカスカな文体、不自然な比喩、壊れたSVOCM（主述関係）を解体し、人間が引っかかりなく読める自然な日本語へ加工するスキルです。
※ 文体調整や日本語校正を目的とした他のエージェントスキルが同一環境で有効化されている場合、指示同士の干渉によって出力が乱れるおそれがあります。本スキルを使用する際は類似スキルの無効化を検討してください。
---
## 1. コア設計思想
最新の学術研究とQiita 7万件の計量調査を踏まえ、次の原則に基づいて文章を再構築します。
- 本スキルの最優先ルールは「**意味の完全保持（主張・比重・言い切りの強さ・文の働きを変えない）**」です。
- 言っていることは変えずに、AIっぽさ（不自然な比喩、空疎な装飾、歪んだ構文）だけを直します。
+ 本スキルの最優先ルールは「**意味の完全保持（主張・比重・言い切りの強さ・文の働きを変えない）**」と「**不要な情報の不増補（足さない）**」です。
+ 言っていることは変えずに、AIっぽさ（不自然な比喩、空疎な装飾、歪んだ構文、不自然な文のつながり）だけを直します。
### 最優先ルール: 意味の保持
書き直す前に、元の文の以下の4点を確かめ、書き直したあとも必ず同じに保ちます。他の原則は、この4点を変えない範囲でのみ適用します。
1. **主張（何を言っているか）**: 伝えたい要点や論理関係を維持する。「本質」「核」などの論点を「目的」など別の概念にすり替えたり、勝手に動詞を足して論点を変えたりしない。
2. **比重（何を一番大事とし、何を軽く扱っているか）**: 否定していたものを並列（Aに加えてB）にしたり、勝手に順位づけを変えたりしない。
3. **言い切りの強さ（断定・推量・可能性）**: 元の文が言い切っていることは言い切ったまま、推量や可能性で書いていることはその強さのまま書く（「おそれがあります」と弱めたり、「〜と言えるでしょう」を断定に上げたりしない）。
- 4. **文の働き（評価・説明・依頼・予定・感想）**: 評価の文は評価のまま、説明は説明のまま保つ（「〜が大事」「〜の本質は」という評価・性質の文を「〜を目的とする」「〜を高める」という目標・予定の文にしない）。
+ 4. **文の働き（評価・説明・依頼・予定・感想）**: 評価の文は評価のまま、説明は説明のまま保つ（「〜が大事」「〜の本質は」という評価・性質の文を「〜を目的とする」「〜を高める」という目標・予定の文にしない）。文末の働き（「〜しましょう」「〜してください」「〜します」「〜です」）も元の文の種類のまま使います。
+ ### 段落と文の論理構造（つながり）
+ AIが生成した文章は、文同士の接続関係が曖昧であったり、予告だけの空疎な文が挟まったり、段落内に複数の話題が混ざったりしがちです。以下の指針で論理の流れを整えます。
+ 1. **文と文の接続関係の確認**: つなぎの言葉（ただし、しかし、また、そして、つまり、そのため等）、主題の「も」、文頭の指示語（これ、それ、こうした等）は、前後の文と「何と何をつないでいるか」を必ず確かめます。接続の根拠が前後から明確に分かる場合は適切な接続表現に直し、分からない場合は無理に直さず書き手に確認します。「自然に読めるか」という感覚だけで判断せず、論理的な接続先を特定します。
+ 2. **予告だけの文の解消**: 中身を伴わない予告文（「注目すべき点があります」「次の点が挙げられます」等）は、予告が担っていた重み（注目すべき等）を述語に残しながら、続く中身の文と1文にまとめます。1文にまとめると意味が変わる場合は無理にまとめず残します。
+ 3. **1段落1話題の徹底**: 段落は1つの話題で構成します。話題が異なる段落同士を安易にまとめません。逆に、1つの段落に異なる話題が混在している場合は、文の順序を崩さずに段落を適切に分けます。
+ 4. **主述のかみ合わせ**: 主語と述語の対応が崩れている文は、元の文の意図が読み取れる範囲で自然に対応させます。
+
### SVOCMの完全復元
- 単語の言い換えにとどまらず、「誰が・何を・どうした」を明確化します。ただし、元の文や前後から分からない動作主、名詞、行動を勝手に創作して足しません。「これ」「片方」などの指示代名詞を名詞に戻すのは、指す先が文脈から分かるときだけに限定します。
+ 単語の言い換えにとどまらず、「誰が・何を・どうした」を明確化します。ただし、省かれた目的語や対象を補うのは、前後の文にその語が明示されているときだけに限定します。文脈から分からない語を勝手に創作して足しません。「これ」「片方」などの指示代名詞を名詞に戻すのも、指す先が文脈から分かるときだけに限定します。補った語がある場合は、出力で明記します。
### 動作主と働きかけの明確化
- 読者への要請は「〜してください」、機能説明は「〜できます」と役割を整理します。ただし、読者への指示か機能の説明かが元の文から分かるときだけ使い、文の働き（説明や評価）を勝手に依頼や予定に変えません。
+ 文末の働きは原則として元の文のまま維持します。「〜しましょう」「〜してください」「〜します」「〜です」の種類を勝手に変更しません。読者への要請を「〜してください」、機能説明を「〜できます」と整理するルールは、元の文が依頼か説明か曖昧なときだけに適用します。言い切りの説明文を勝手に可能表現（〜できます）に変えません。
### 非生物主語（擬人化）の解体
- 道具や概念に感情や意志を持たせず、客観的な動作に戻します。ただし、元の文にない動作主を勝手に捏造しません。
+ 非生物主語を直すのは、道具や概念に感情や意志を持たせている擬人化表現（「コードが語る」「システムが願う」等）のときだけに限定します。道具や仕組みの働きを客観的に述べている文（「このツールはログを集めます」等）はそのまま残します。直す場合も、元にない条件（「〜を使えば」）や可能（「〜できます」）を足しません。
### 比喩動詞の具体化とふだん使う言葉への変更
- 「倒す」「効く」「溶かす」「潰す」といったAI特有の比喩表現を、ふだん使う言葉や文脈に合った正確な言葉に書き換えます。「発生」「担保」など過度に硬い2字漢語を不要な場面で連発しません（ただし「データの整合性」など技術的な正当な専門用語は無理に排除しません）。
+ 「倒す」「効く」「溶かす」「潰す」といったAI特有の比喩表現を、ふだん使う言葉や文脈に合った言葉に書き換えます。「発生」「担保」など過度に硬い2字漢語を不要な場面で連発しません。
**比喩や言い回しが持っていた「含み（気持ちや評価の向き）」は必ず残します。**
- 含みの例: 「うっかり」の不注意、「ようやく」の待ちくたびれた感じ、「〜てしまった」の後悔、「地味に」の目立たないけれど確かにある感じ。
- 比喩の語は言い換えてかまいません。ただし、その語が伝えていた含みや理由は、別のふだんの言葉で補って言い表します。
- 比喩動詞だけでなく、副詞や前置きの言い回しも同じ扱いにします。
- 「静かに壊れる」のような表現において、データやシステムに対して使われる「壊れる」はAI特有の直訳・比喩です。「データの整合性が失われる」「不整合が生じる」のように客観的・技術的な状態に具体化します（「壊れる」と言い切っている文を「おそれがある」などに弱めず、言い切りの強さは維持します）。また、「静かに」「黙って」のようなぼかしは、「気づかないうちに」「知らないうちに」のように気づけないという幅のまま書きます。「エラーを出さずに」「通知なく」のように仕組みの話として書くのは、元の文や前後から、エラーや通知が出ないことがはっきり分かるときだけに限定します。時計や機械など物理的な物体や、身体（お腹を壊す等）の文字どおりの「壊れる」のみ維持します。
+ データやシステムに対して使われる「壊れる」は、「おかしくなる」「使えなくなる」のように、意味の広さが同じふだんの言葉に改めます。「データの整合性が失われる」「不整合が生じる」と書くのは、元の文や前後から、明らかに整合性の話だと分かるときだけに限定します。時計や機械など物理的な物体や、身体（お腹を壊す等）の文字どおりの「壊れる」はそのまま残します。また、「静かに」「黙って」のようなぼかしは、「気づかないうちに」「知らないうちに」のように気づけないという幅のまま書きます。「エラーを出さずに」「通知なく」のように仕組みの話として書くのは、元の文や前後から、エラーや通知が出ないことがはっきり分かるときだけに限定します。
また、「骨が折れる」「手を焼く」「目から鱗が落ちる」「首を長くして待つ」のような、ふだんの日本語で定着した慣用句は、AIっぽい比喩として扱わずそのまま残します。業務仕様でも、意味を取り違えるおそれがなければ残します。迷ったときの目安は、その言い方を、AIが広まる前の人の文章でもふつうに見かけるかどうかであり、見かけるなら残します。
### セルフラベリングと否定対比の整理
「重要なのは」「大事なのは」が評価そのものを担っているときは、評価を消さずに述語に移して残します（「〜が大事です」「〜が重要です」）。前置きを削ってよいのは、削っても主張が変わらないときだけです。
否定対比（AではなくB）は、否定を外しても主張が変わらないときだけ肯定文にします。Aだと思われがちなところをBだと言い直しているような、意味や比重を担っている否定は、無理に肯定化せず否定のまま残し、言い回しだけを自然にします。否定していたAを「Aに加えてB」と並べたり、「AよりB」と順位づけしたりしません。否定を残すときに、元にない理由の文は足しません。
### 意味保持と情報の不増補（足さない）
元の文や前後から分からない動作主、名詞、行動、原因、条件、数値、例、専門用語は足しません。ぼかした語を、より狭い具体的な事実に勝手に置き換えることもしません。情報が足りず具体的に書けないときは、本文で勝手に補わず、出力の最後に「書き手に確かめたい点」として提示します。
### 呼吸に合った文長と読点の抑制
平均文長を30〜45文字に保ち、1文あたりの読点を0〜2個に抑制してスムーズな読書体験を作ります。
### 装飾記号と不要な空白の完全排除
絵文字、文末コロン、ダッシュ記号（em dash）、情報量の増えない言い換えカッコ、和欧文間の不自然な半角空白を完全に排除します。
---
## 2. 実行手順
- ### Step 1: ドメインとモードの判定
-
- 入力されたテキストや指示文（「技術記事向けに」「ドメイン: tech」など）からドメインを判定します。
-
- - `tech` (技術記事): 技術ブログや設計書。箇条書きを15%以下に抑え、元の文や資料にある情報の範囲で手順を整理します（元にないコマンドやコード片を勝手に作って足しません）。
- - `business` (業務・仕様書): PR説明文や社内レポート。比喩の理由は残しつつ客観的な表現に改め、元の文から分かる範囲で境界条件や責任主体を明記します。
- - `essay` (エッセイ・個人発信): noteや個人雑記。大げさな教訓化を避け、素朴な感情と具体的な体験を残します（元にない五感描写や人物を創作しません）。
+ ### Step 1: 文脈と段落の把握
- 明示的な指定がない場合は、文脈から自動判別します。
+ 書き直す前に、文章全体と段落の流れを確認します。
+ 1. **ドメインの判定**: 入力されたテキストや指示文からドメインを判定します。
+ - `tech` (技術記事): 技術ブログや設計書。箇条書きを15%以下に抑え、元の文や資料にある情報の範囲で手順を整理します。
+ - `business` (業務・仕様書): PR説明文や社内レポート。比喩の理由は残しつつ客観的な表現に改め、元の文から分かる範囲で境界条件や責任主体を明記します。
+ - `essay` (エッセイ・個人発信): noteや個人雑記。大げさな教訓化を避け、素朴な感情と具体的な体験を残します。
+ 2. **段落の話題と文の関係の把握**:
+ - 段落ごとに「何の話をしているか」を1行でつかみます。話題が異なる段落同士はまとめず、話題が混ざっている段落は分割を検討します。
+ - 文ごとに、前の文とどのような関係にあるか（理由、例示、但し書き、言い換え、補足、まとめ等）を確かめます（このメモは出力には出しません）。
+ 3. **意味の4点の確認**: 元の文の「主張」「比重」「言い切りの強さ」「文の働き」を確認します。
### Step 2: 統語変換の実行
`references/gemini-syntax.md` およびドメイン別仕様に従い、以下の手順で変換します。
- **開始前確認**: 書き直す前に、元の文の「主張」「比重」「言い切りの強さ」「文の働き」の4点を確認します。
-
- 1. 元の文から分かる範囲で、動作主（主語）や対象を明確にします（分からない場合は勝手に足しません）。
- 2. 読者への指示か機能説明かが元の文から分かる場合のみ、「〜してください」「〜できます」に整理します（評価や説明の文を依頼や予定に変えません）。
+ 1. 元の文から分かる範囲で、動作主（主語）や対象を明確にします。省かれた目的語や対象を補うのは、前後の文にその語があるときだけに限定します（補った場合は「変えたところ」に出します）。
+ 2. 文末の働きは元の文のまま維持します。「〜しましょう」「〜してください」「〜します」「〜です」の種類を保ちます。「〜してください」「〜できます」への整理は、依頼か説明か曖昧なときだけに行い、言い切りを勝手に「〜できます」に変えません。
3. 指示代名詞（これ、片方など）は、指す先が文脈から分かる場合のみ具体的な名詞に戻します。
- 4. 比喩動詞や言い回しは、熟語を並べるのではなく、ふだん使う言葉や文脈に合った正確な言葉に置き換えます（「うっかり」「ようやく」「〜てしまった」「地味に」など、元の語が持っていた気持ち・評価の向き・含みは別のふだんの言葉で残します。「データが壊れる」など抽象物への「壊れる」は「データの整合性が失われる」「不整合が起きる」のように具体化し、時計や機械など物理的な物体・身体の文字どおりの「壊れる」のみ維持します。「静かに」「黙って」は「気づかないうちに」「知らないうちに」のように気づけない幅のまま直します。「骨が折れる」「手を焼く」など定着した慣用句はそのまま残します）。
+ 4. 比喩動詞や言い回しは、ふだん使う言葉や文脈に合った言葉に置き換えます。データやシステムの「壊れる」は「おかしくなる」「使えなくなる」のように同等の広さの言葉にし、整合性の文脈であることが明らかな場合のみ「整合性が失われる」等とします。「静かに」「黙って」は「気づかないうちに」「知らないうちに」のように気づけない幅のまま直します。定着した慣用句や含みは維持します。
5. 重複する補足カッコを削り、英単語前後の余計な半角空白を除去します。
- 6. 「重要なのは」が評価を担っているときは述語に残し（「〜が大事です」）、否定対比（AではなくB）は意味や比重を担っているなら否定を残したまま言い回しを自然にします（「Aに加えてB」や順位づけに改変しません）。
+ 6. 「重要なのは」が評価を担っているときは述語に残し、否定対比（AではなくB）は意味や比重を担っているなら否定を残したまま表現を整えます。
7. 絵文字、文末コロン、ダッシュ記号を排除します。
- 8. 同一文末が3連続しないようリズムを調整します。
- 9. 無駄な太字を外し、箇条書きを地の文の段落へ統合します。
-
- **終了後確認**: 書き直した文が、開始前に確認した4点（主張・比重・言い切りの強さ・文の働き）と元の語の「含み」を完全に維持しているかを点検します。本文を書くときに実際に迷った点（補いたくなったけれど補わなかった点）があれば、多くても2点までに絞って「書き手に確かめたい点」へ回します（迷った点がなければこの欄ごと省略します）。
+ 8. 文末のリズム調整は、AIっぽさを直すついでに同一文末が3連続した場合にのみ行います。AIっぽさのない自然な文は文末だけを変えません。直す箇所がほとんどない場合は無理に書き換えません。
+ 9. 箇条書きを地の文にするときは、各項目の文末の働きをそのまま使います。「〜が大切です」「〜する必要があります」等の評価や義務の言い回しを足しません。単に項目が並んでいるだけであれば箇条書きのまま残して構いません。
+ 10. つなぎの言葉（ただし、しかし、また、そして、つまり等）、主題の「も」、文頭の指示語は、前後の接続先を確かめ、正しく合致するものに整えます（直した場合は「変えたところ」に出します。判断がつかない場合は無理に直さず「書き手に確かめたい点」に出します）。
+ 11. 中身を伴わない予告文は、予告の重みを述語に残して中身の文と1文に統合します（統合した場合は「変えたところ」に出します。統合すると意味が変わる場合は残して「残したAIっぽいところ」に出します）。
+ 12. 主語と述語がかみ合わない文は、元の意図が分かる範囲で整えます（直した場合は「変えたところ」に出します）。
- ### Step 3: 機械的検査
+ ### Step 3: 静的検査（リンター）
フルモード指定時やファイル保存時は、同梱のリンターを実行して静的検査を行います。
```bash
# スキル配置先（${CLAUDE_SKILL_DIR}等）を基準にスクリプトの絶対パスを解決して実行
python3 <スキル配置ディレクトリ>/scripts/yomiyasu_lint.py <対象ファイル>
```
- 検出結果は機械的な見直し候補の位置づけです。医学の `体温`、画像処理の `解像度`、化学の `触媒` など、文脈上正当な専門用語や事実の記述であれば無理に言い換えず保持してください。また、「大事です」のように評価を担う語や、主張上必要な否定（AではなくB）も、リンターの指摘があっても無理に消さず残してください。修正試行は最大2回とし、警告を消すためだけの過剰な言い換えループを防止します。
+ 検出結果は機械的な見直し候補の位置づけです。文脈上正当な専門用語や事実の記述であれば無理に言い換えず保持してください。また、「大事です」のように評価を担う語や、主張上必要な否定（AではなくB）も、リンターの指摘があっても無理に消さず残してください。修正試行は最大2回とし、警告を消すためだけの過剰な言い換えループを防止します。
+ ### Step 4: 足したもの・削ったものの点検（Diff検査）
+
+ 書き直した文ができたら、元の文と書き直した文を比較し、意図しない情報の増減やつながりの乱れがないかを点検します。
+
+ ```bash
+ # 元の文と書き直した文をファイルに保存して差分スクリプトを実行
+ python3 <スキル配置ディレクトリ>/scripts/yomiyasu_diff.py 元の文.txt 書き直した文.txt
+ ```
+
+ スクリプトが出力した候補を1つずつ確認し、以下を判断します。
+ - 言い回しの種類（依頼・義務・評価・可能等）が増減している場合: 元の文の働きからずれていれば元の表現に戻し、正当な言い換えであれば残して「変えたところ」に記載します。
+ - 元にない語や消えた語: 勝手な情報の付け足しや、必要な前提の脱落がないか確認します。
+ - 箇条書きや段落の変化: 箇条書きを地の文にした際に余計な評価や義務が足されていないか、段落統合によって話題が混ざっていないかを確認します。
+ - つながりの確認箇所: つなぎ言葉や指示語が前後の文と論理的につながっているかを確認します。
+
+ 修正は1回のみ行い、スクリプトの再実行を繰り返す往復は行いません。Pythonが実行できない環境では、上記と同じ観点（言い回しの増減、元にない語、消えた語、段落・箇条書きの変化、接続関係）を目視で点検します。
+
---
## 3. 出力フォーマット
対話リライト時には、以下のフォーマットで提示します。絵文字や不要なカッコは使用しません。
```markdown
- ### 脱臭・リライト結果
+ ### 書き直した本文
（自然な日本語に再構築された本文）
---
- ### 主な改善ポイント
- - 意味の保持: 主張・比重・言い切りの強さ・文の働き・含みを維持
- - （その回に実際に変更した点だけを簡潔に箇条書きで記載）
+ ### 変えたところ
+ - （意味が動きやすい変更、つながりを直したところ、補ったものだけを、最大5点まで記載。1行ずつ「元 → 後」と理由を短く書く。該当がなければ「なし」と1行で記載）
+ - 元の表現 → 書き直し後の表現（変更理由）
- ### 書き手に確かめたい点（※本文を書くときに実際に補うか迷った点がある場合のみ、最大2点まで記載。迷った点がなければこの見出しごと出さない）
- - （補いたくなったけれど補わなかった前提や条件があれば、短く1〜2点だけ記載）
+ ### 残したAIっぽいところ（※意味や重みを担っているため消さずに残した前置きや結びがある場合のみ記載。なければこの見出しごと出さない）
+ - （残した表現と、それを削るかどうか書き手へ確認する問い）
+
+ ### 書き手に確かめたい点（※本文を書くときに判断に迷った点や、前後のつながりが特定できなかった点がある場合のみ、最大2点まで記載。なければこの見出しごと出さない）
+ - （確認したい前提や条件を短く1〜2点記載）
```