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