yomiyasu
AIが生成した日本語の推敲に使うスキル。「この文章を読みやすくして」「AIっぽさをなくして」「自然な日本語にして」「文章を脱臭して」といった依頼や、技術記事、仕様書、PR説明文、社内レポート、エッセイ・noteの文章を見直すときに使用する。意味と条件を保ち、不自然な比喩、曖昧な主述関係、不要な装飾やコピー調を整える。
Install / Use
npx skills add nanaism/yomiyasu --skill yomiyasuInstalls into whichever agent you are using.
SKILL.md
Installable skill definition
Quality Score
Category
Development & EngineeringSupported Platforms
Tags
Our assessment of yomiyasu
yomiyasu scores 92/100 on our quality scale, 970th of 4,601 Development & Engineering skills we index (top 22%).
Its SKILL.md is 26 KB long, well organised into 29 sections with 3 code examples: a thorough specification that gives an agent plenty to work with.
With 1,589 GitHub stars, it is one of the more widely adopted skills in the catalogue.
Maintenance, license and trust
- The repository was last updated 6 days ago, so yomiyasu is actively maintained.
- It is released under the MIT license, a permissive license that allows use, modification and commercial use with attribution.
- Its trust signals score 100/100, with no cautions. These come from repository metadata, not a code audit — read the skill file before letting an agent act on it.
Safety scan
No issues foundOur scan of the whole file found no instruction hijacking, hidden characters, credential access, data exfiltration or destructive commands.
Automated pattern scan on 2026-10-12. It catches known dangerous patterns, not every risk — read a skill before letting an agent act on it.
yomiyasu compared with similar skills
All 4 of these similar skills score higher than yomiyasu; compare them before choosing.
| Skill | Score | Stars | Updated | Format |
|---|---|---|---|---|
| yomiyasu (this skill)by nanaism | 92 | 1.6k | 6d ago | SKILL.md |
| ai-job-searchby MadsLorentzen | 100 | 46.3k | 4d ago | CLAUDE.md |
| claude-howtoby luongnv89 | 100 | 41.8k | 1d ago | CLAUDE.md |
| algorithmic-artby anthropics | 100 | 177.9k | 20d ago | SKILL.md |
| pptxby anthropics | 100 | 177.9k | 20d ago | SKILL.md |
Frequently asked questions
- How do I install yomiyasu?
- Run
npx skills add nanaism/yomiyasu --skill yomiyasu. The install tabs above show the steps for each supported agent. - Which AI agents does yomiyasu work with?
- It is written for Universal, as a SKILL.md file. Other agents that read the same format can often use it too.
- Is yomiyasu safe to use?
- Our scan of the whole file found no instruction hijacking, hidden characters, credential access, data exfiltration or destructive commands. It is MIT-licensed and scores 100/100 on trust signals. Skills are instructions an agent will follow, so read the file before installing it and do not approve commands you do not understand.
- Is yomiyasu still maintained?
- The repository was last updated 6 days ago, so yomiyasu is actively maintained.
Skill content
View source on GitHubname: yomiyasu description: AIが生成した日本語の推敲に使うスキル。「この文章を読みやすくして」「AIっぽさをなくして」「自然な日本語にして」「文章を脱臭して」といった依頼や、技術記事、仕様書、PR説明文、社内レポート、エッセイ・noteの文章を見直すときに使用する。意味と条件を保ち、不自然な比喩、曖昧な主述関係、不要な装飾やコピー調を整える。 license: MIT
yomiyasu
AIが生成した文章の不自然な比喩、曖昧な主述関係、偏った構文を直し、読みやすく自然な日本語に整えるスキルです。
他の日本語校正スキルと併用すると、指示が食い違う場合があります。出力が乱れる場合は、類似スキルを無効にして使うことを検討してください。
1. 基本原則
「意味の保持(主張・比重・言い切りの強さ・文の働きを変えないこと)」と「情報の不増補(勝手に足さないこと)」を最優先にします。 元の文章が伝える内容は変えず、不自然な比喩、余計な装飾、主述の不一致、文のつながり、立場に合わない文末を直します。
最優先ルール: 意味の保持
書き直す前に元の文の次の4点を確かめ、書き直したあとも必ず同じに保ちます。他の原則は、この4点を変えない範囲でのみ適用します。
- 主張(何を言っているか): 伝えたい要点や論理関係を維持します。「本質」「核」などの論点を「目的」など別の概念にすり替えたり、勝手に動詞を足して論点を変えたりしません。
- 比重(何を一番大事とし、何を軽く扱っているか): 否定していたものを並列(Aに加えてB)にしたり、勝手に順位づけを変えたりしません。比較や最上級は、何を比べているかも保ちます。重要度の評価を、頻度や見落としやすさの評価に変えません。何の比較か分からなければ原表現を残します。
- 言い切りの強さ(断定・推量・可能性): 元の文が言い切っていることは言い切ったまま、推量や可能性で書いていることはその強さのまま書きます(「おそれがあります」と弱めたり、「〜と言えるでしょう」を断定に強めたりしません)。
- 文の働き(評価・説明・依頼・予定・感想): 評価の文は評価のまま、説明は説明のまま保ちます(「〜が大事」「〜の本質は」という評価・性質の文を「〜を目的とする」「〜を高める」という目標・予定の文に変えません)。実施済みの変更、現在の動作・方針、今後の予定を時制と役割に合わせて書き分け、完了した変更を予定のような表現にしません。文末は、文書の目的を手がかりに、各文・各節の動作主と働きに合う形を選びます。常体・敬体の選択とは分けて判断します(詳細は「文書の立場と文末」を参照してください)。
「文の働き」は、文の種類として確かめます。書き直す前に、各文が「事実」「意見・評価」「依頼・決まり」「例え・比喩」「皮肉・冗談・反語」「仮定・予測」「引用・伝聞」のどれにあたるかを内部メモに記録し、書き直したあとで種類が変わっていないかを読み比べます。伝聞(「〜とされる」「〜らしい」)を断定にする、意見(「〜と思う」)を事実として言い切る、依頼を説明に変える、例え(「まるで戦場のようだ」)を「戦場だ」と言い切る、反語をただの疑問にする、仮定を予定にする、といった書き換えはしません。種類は、その文が何を述べているかで決めます。「休日を溶かした」のように比喩動詞を含む文は、事実の文として扱います。皮肉や反語は、文脈から確定できるときだけその種類とします。 文を分けたりつないだりするときは、元の各文の種類を、書き直した文のどこかで保ちます。種類を決めきれない文は、無理に一つに決めず、候補を残したまま扱います。種類が変わった文は元の種類に戻し、元の種類のままでは直せない場合は、元の文を残して「書き手に確かめたい点」に出します。小説や人文系の文章で、書き手がわざと複数の読みを残している箇所は、一つの読みに決めて直しません。書き手の決意や抱負を述べる結びも、書き手の意思を伝える文として内容を残し、大げさな語だけを直します。種類の記録は内部メモであり、出力には出しません。
文書の立場と文末
日本語は主語を省くことが多く、文末の形が「誰が動くのか」「決まりなのか、勧めなのか、説明なのか」を伝えます。文末を選ぶ前に、「誰が、誰に、何のために、いつのこととして書くか」を手がかりとして、まず文書全体で読み手に知らせる主たる用件を確かめ、その用件を果たすために各段落で伝える内容を決めます。これらを機械的に本文へ明記するのではなく、文末や語調を選ぶ基準とします。文書や段落の目的をそろえることと、すべての文末を同じ種類にすることは別です。助言を含む文書でも、事実や道具の動作を説明する文は説明のまま残します。 変更内容の報告を求められた場合は、提供された事実をもとに「どの指針・設定・実装を、どう改めたか」を、書き手の改定行為として述語まで書きます。「指針を改定しました」と一般的に宣言した後に方針宣言を並べただけでは、報告できたとはみなしません。変更したと分かる内容だけを改定として報告し、現在の動作・仕様・方針しか分からない記述を今回導入・変更・維持した事実へ勝手に変えません。改定前の内容が未提供なら前後比較や追加、改善幅を作らず、現在の動作や方針を補足する場合も、何の現在の状態を説明しているか、既知の改定とどういう関係なのかが読み手に伝わるように書き分けます。 現在の推敲方針や設定済みの指示を補足するときは、書き手の作業予定に見える「〜します」ではなく、誰の現行方針かを確かめた上で「〜するようにしています」「〜する方針です」「〜するよう指示しています」など、主体と状態が読める形にします。ただし「ようにしています」を万能語尾にせず、システムの実動作(「返します」)、利用可能な機能(「できます」)、手順書、読み手への依頼(「してください」)、将来計画(「予定です」)はそれぞれ適切な表現を保ちます。現在の方針を今回新設・変更・維持したという履歴や確実な実行性能、未知の原因・主体は作りません。関係が不明なら因果を作らず、完了した変更を予定のような「〜します」にしたり、現在の実動作や仕様説明をすべて過去形に揃えたりもしません。 常体・敬体は、変更の指定がない限り原文を保ちます。技術記事という分野だけを理由に敬体へ変えません。混在を直す場合も、文の働きとは別に文体を選びます。 文脈が明確でない場合は余計な内容を書き足さず、明確な場合は読み手が理解できるように説明します。読者の理解に必要な定義、識別子、値と状態の対応が依頼や文脈で提供されている場合は、説明に活かします。何の文章かが分かりにくいときは、提供された用途や読み手を、短い見出しや冒頭の説明で示します。分からない主体・意図・条件は推測で補いません。
- 立場は次の3つのどれかです。
- 勧め: 読み手に勧める・頼む文書(心得、助言、呼びかけ)。動作をするのは読み手です。
- 決まり: 決まり・手順を伝える文書(運用ルール、手順書、お知らせ、仕様)。動作をするのは手順に従う読み手、または方針を決めた書き手です。
- 説明: 事実・結果・考えを伝える文書(技術の説明、報告、体験)。
- 立場は、上の手がかりほど優先して決めます。
- 依頼にある行き先と読み手(「社内ブログ向け」「上長への報告」「チームの運用ルールとして」など)。「技術記事向け」「業務仕様向け」「エッセイ向け」のような分野の名前だけでは、立場を決めません。同じ分野の中に、決まり・報告・勧めの文書があるためです。
- 本文の手がかり(「私は」「当チームでは」などの主語、宛名・署名・日付、見出し)。
- 決まりと読む手がかりがないことだけでは、勧めとも決めません。助言・決まり・予定・説明のどれかを確定できないときは、文末で勝手に決めず、「情報が足りない場合の暫定文」に従います。
- 文末や語尾を見直すのは、次のときです。
- 文末によって動作主、時制、文の働きが意図とずれて読めるとき(助言が予定の表現になっている、完了した変更報告が予定の「〜します」になっている等)。
- 指定された文体へ変えるときや、箇条書きを地の文に書き直すとき(文末の形を選び直しても、各文の働きは保ちます)。
- 依頼にある行き先や読み手と、文末の立場が合わないとき。
- 地の文の「です・ます」と「だ・である」が意図なく混在するとき。
- 立場や時制が適切でも、類似した変更動詞や同じ文末が続いて単調で読みにくいとき(この場合は立場・働き・時制を保ったまま、語順や文のまとめ方を工夫して言い回しを整えます。語尾を散らす目的で文の働きや時制を変えたり、自然な文末を無理に変えたりはしません)。 文末が文書の中でそろい、動作をする人と文の働きが依頼や本文の手がかりに合っているときは、文末を変えません。文末がそろっていることだけでは、立場が適切だとは判断しません。実際の処理や操作を「〜します」で説明し、最後の1文だけを「〜しましょう」で結ぶ形は、混ざっているとみなしません。原則や大事な点を述べる文と、行動を示す文も、それぞれの働きに合っていれば残します。
- 立場・働き・時制を直すときは、合わない文末だけを直します。
- 読み手への助言を、書き手の予定のような「〜します」「〜しておきます」で書いているときは、動作主と助言の働きが伝わる形に直します。敬体への指定がなければ、助言を表す自然な常体も保ちます。「まず」「次に」「最後に」は順序を示す語であり、動作主や文の働きを決める語ではありません。設計上の助言と、構成された道具の実際の動作が一文にある場合も、節ごとに区別します。
- 決まりの文書で、「〜しましょう」「〜ことが重要です」が決まりそのものを書いているときは、「〜します」にそろえます。決まりの理由や前提を述べる文と、「〜してください」はそのまま残します。
- 説明の文書で、書き手の側の予定や行動(「来月から担当を2人に増やします」)や、実施済みの変更(「方針を変更しました」)はそのまま残します。完了した変更を予定のような文にしません。
- 地の文の「です・ます」と「だ・である」が意図なく混在するときは、依頼と原文を手がかりにそろえます。常体を敬体にする指定があっても、助言・決まり・予定・説明の働きを変えません。
- 同じ立場の中の強さの違い(「〜しましょう」と「〜してください」、「〜が大切です」と「〜しましょう」)は変えません。強さを引き上げません(勧めを「〜しなければなりません」に変えないなど)。ただし、相手との関係や書き手の希望が分かる依頼では、内容・条件・期限を保って語調を整えます。希望された「〜してもらえると助かります」などを依頼の表現として選ぶことと、元にない具体的な便益・感情・感謝を足すことは分けます。依頼の定型を一律に追加したり削ったりしません。期限を任意にせず、安全手順や決まりの必須の指示は弱めません。「ください」自体を一律に命令口調とはみなしません。
- 文末をそろえるためだけに主語は足しません。主述の対応を直すために補う場合は、「主語と目的語の明確化」に従い、原文や前後に根拠がある語だけを使います。
- 文末をそろえたときは、『変えたところ』に1行でまとめ、理由も短く書きます(例: 残しておきます・共有します → 残しておきましょう・共有しましょう)。
- 次のときは、「書き手に確かめたい点」に、もう一方の立場で書くときの文末を1行で示します(例: 「チームの決まりとして書く場合は、『〜しましょう』を『〜します』にそろえます」)。
- 手がかりから立場を決めきれず、文末を変えると働きが変わり得るとき。
- 依頼の分野や行き先と、本文の中身が食い違うとき(「業務仕様向け」なのに、本文は読み手への心得を並べているなど)。 文末を1つも変えなかったときは、もう一方の立場の文末は書きません(ほかに確かめたい点があれば通常どおり提示します)。
- 文同士をつなげて「〜しましょう」の数を減らすことはしません。項目同士を1文にまとめると、主題や理由の掛かる範囲と、項目同士の比重が変わるためです。地の文でもともと「〜しましょう」が続いている場合はそのままとし、働きの違う文末(「〜してください」など)に変えて散らしません。
- 独立した変更点、手順、担当と結果の対応など、並列関係が明確で読みやすい箇条書きは、AI調に見えるという印象や比率の数値だけで無理に地の文へ戻さず残します。箇条書きを地の文にすると同じ文末が単調に続くような場合も、箇条書きのまま残します。
- 書き直しで新たに同じ呼びかけを増やした場合は、助言として扱った文・節の根拠と、文体を変える必要性を見直します。語尾の数だけを減らすために、義務・可能・評価へ置き換えません。
- 依頼か説明か決まらない場合は、その働きを未確定のまま扱い、「情報が足りない場合の暫定文」に従います。分からないことを理由に「〜してください」や「〜できます」へ決めません。言い切りの説明文を勝手に可能表現(〜できます)に変えません。
段落と文の論理構造(つながり)
AIが生成した文章は、文同士の接続関係が曖昧であったり、予告だけの空疎な文が挟まったり、段落内に複数の話題が混ざったりしがちです。以下の指針で論理の流れを整えます。
- 文と文の接続関係の確認: つなぎ言葉(ただし、しかし、また、そして、つまり、そのため等)、主題の「も」、文頭の指示語(これ、それ、こうした等)は、前後の文と「何と何をつないでいるか」を必ず確かめます。接続の根拠が前後から明確に分かる場合は適切な接続表現に直し、分からない場合は無理に直さず書き手に確認します。「自然に読めるか」という感覚だけで判断せず、論理的な接続先を特定します。
- 予告だけの文の解消: 中身を伴わない予告文(「注目すべき点があります」「次の点が挙げられます」等)は、予告が担っていた重み(注目すべき等)を述語に残しながら、続く中身の文と1文にまとめます。1文にまとめると意味が変わる場合は無理にまとめず残します。「重要なポイントは3つです」「以下の3つの観点から説明します」のような数の宣言も、宣言した数と続く項目の数が合っている場合に限り、同じ基準で続く中身の文と1文にまとめます。ただし、長い説明で項目数の予告が読み手の案内になっている場合は残します。数が合わない場合は、宣言の数も項目も変えずに「書き手に確かめたい点」に出します。宣言の数にそろえるために項目を足したり削ったりしません。
- 1段落1話題の徹底: 段落は1つの話題で構成します。話題が異なる段落同士を安易にまとめません。逆に、1つの段落に異なる話題が混在している場合は、文の順序を崩さずに段落を適切に分けます。
- 主述のかみ合わせ: 主語と述語の対応が崩れている文は、元の文の意図が読み取れる範囲で自然に対応させます。
- 修飾・条件・並列の関係: 修飾語の掛かる先、条件・例外・否定・限定・数量が掛かる動作や判断を確かめます。並列した各項目が共通する述語につながるかも確認します。
- 名詞の連続と長い節: 名詞が続いたり、主語と述語の間に長い節が入ったりして、動作や判断の関係を追いにくくなっていないか確かめます。
- 操作と結果の対応: 注意事項で複数の操作と結果が並ぶときは、どの操作で何が残る・変わるかを読み手が区別できるか確かめます。対応を追いにくければ、必要な用語を残して、操作ごとに文や行を分けます。結果を表す語そのものの意味が確定しない場合は、配置だけで解決したことにせず、書き手に確認します。
同じ段落で一つの問題を説明した後、その対策を述べる文でも同じ問題を長く言い直している場合は、「この問題を防げます」のように、明確な指示語で受けます。原文にある反復だけでなく、書き直しで新たに重複した説明も整理します。複数の問題や条件の切替で、どの対象かを追うために必要な再掲は保ちます。 本文で言い終えた内容を「まとめると」「結局のところ」「要するに」などで同じ強さのまま言い直すだけの締めの文や段落は削ります。短い文書の最後で本文を繰り返すだけの「まとめ」見出しと段落も同じです。新しい情報や条件、結論の絞り込みを加えている場合と、長い文書や発表で要約の役割を担う場合は残します。削る前に、その箇所にしかない数値・条件・例外がないかを確かめ、あれば削らずに残すか、同じ意味で本文へ移します。削った場合は「変えたところ」に出します。 改行は、話題や説明の段階が切り替わり、分けると読みやすくなる箇所で、意味のまとまりごとに使います。出来事、現在の状態、今後の予定のように、報告の説明段階が切り替わる箇所でも、分けると読みやすければ改行を使います。新たに本文の行を分けるときは改行1つを基本とし、読みやすさを理由に空行を一律に増やしません。時制が変わるたびに機械的に改行したり、常に三段構成にしたりせず、条件と結果、理由と結論、操作の順序を読み違える位置では分けません。元からある意図的な段落分けや、見出し・箇条書き・コードなどの書式上の区切りは保ちます。Markdownの改行指定と通常の行分けを取り違えず、句点ごとに機械的に改行せず、元から自然な短い段落や改行は保ちます。
読み違い、または関係を追う負担がある箇所を具体的に特定できた場合に、修飾語の移動、名詞を動作として書くこと、接続や読点の整理、文の分割を検討します。変更は問題箇所の近くに絞り、元から自然で関係が追える箇所は残します。原文と提供文脈から関係を確定できない場合は、その関係を勝手に決めて直さず、「書き手に確かめたい点」へ出します。文を切る・つなぐ・語順を変えるときも、条件・否定・因果・時系列・比重が掛かる範囲を保ちます。筆者が情報を見聞きした日時と、出来事そのものが起きた日時は区別します。述語ごとに誰の動作や報告かを対応づけ、見聞きした日時を出来事の日時へ移したり、現在の報告や伝聞を過去の発言へ勝手に変えたりしません。引用や予定、日時が指定されていない出来事も、意味や時制を保って書き分けます。原文の各主張の動作主・述語・対象、時、条件、文の働きは本文で追えるように保ちます。提供文脈にある別の事実(聞き取った経験など)を書いたことだけで元の主張を保ったとみなさず、既知の関係を別の観察・経験・予定へ置き換えて消さないようにします。
接続を削る・変えるときは、必要な箇所だけ内部メモで「結論(比較, 方針)」「順序(A, B)」「条件(C, 動作)」のように関係を並べ、修正後も同じ対応を追えるか確かめます。不明な関係は「?」とし、因果や判断条件を作って埋めません。この表記は抜けを見つける補助であり、意味の等価性の証明ではありません。メモは出力に加えません。 構造を直す箇所では、原文を述語を中心とする短い語句に分け、主語・対象・扱いと、修飾語や指示語の係り先を対応づけます。書き直した文にも同じ点検を行い、語句が対応するだけでなく、関係が保たれるかを比べます。名詞に掛かる語を動作に掛かる語へ移す場合は、元と同じ意味と確認できる根拠が必要です。例えば「独立した展示」を「独立して担当する」へ変えると、展示の性質が担当者の行為へ移ります。文書の話題からそう読めそうというだけでは確定しません。不明な係り先は候補や「?」のまま残します。 助詞や修飾の位置を変えたり、名詞を動作として書いたり、述語を補ったりするときは、語が既出かだけでなく、対象と扱い、実行と待機の主体、修飾先が元と同じかを確かめます。原文が複数の読みを許す場合は、自然に言い換えるためだけに一つの読みへ決めません。関係が未確定なら本文で確定させず、何が不明かを書き手に確認します。
主語と目的語の明確化
単語の言い換えにとどまらず、「誰が・何を・どうした」を明確にします。原文や提供文脈から分かる主体を必要な位置で示し、誰の行為かを確かめます。ただし、元にない担当者を創作したり、自然なシステム動作まで人間の行為へ変えたりはしません。省かれた目的語や対象を補うのは、原文・依頼・提供資料に対象と関係が明示されているときだけに限定します。推測で創作したり、近くにある名詞というだけで対象を選んだりはしません。「これ」「片方」などの指示代名詞を名詞に戻すのも、指す先が文脈から分かるときだけに限定します。何を指すか追う必要がある名詞は、「もの」などへ不用意にぼかしません。助詞や使役を変えたときも、誰が何をどうするかの対応を確かめます。補った語がある場合は、出力の「変えたところ」に明記します。 複数の述語で動作主が変わる文は、述語ごとに「動作(主体, 対象)」を確かめます。原文や提供文脈で分かる動作主が切り替わる箇所は、その主体を明記します。例えば「上長が差し戻した場合、システムが通知します」と書き、差し戻す人と通知する主体を区別します。使役は「誰が・何に・何をさせるか」を区別します。長い節を読み戻らないと対象を追えない場合は、対象の再掲や節の分割を検討します。不明な主体や対象は作りません。 主述や使役の対応だけを直す場合は、まず原文の動詞を保ち、確定した主語・相手・対象を明記する案を検討します。動詞自体が不自然でなければ、対象を補うだけで伝わる文を別の長い構文へ組み替えません。比喩など動詞を直す理由がある場合も、元の動作と関係を保ちます。 動作を名詞にして「〜を行う」と書くより、対象と動詞を直接つなぐ方が自然な箇所は、「値を代入する」「変更内容を共有する」のように書きます。何を扱うかが分かる対象を落としたり、動作を別の動作へ変えたりしません。失敗時に値を代入しない処理を「falseを代入する」と変えるような、実際の条件や動作の改変は避けます。 処理や選別の対象を「もの」「それら」で省いている場合は、指す対象が原文や提供文脈から確定し、前の文から拾い直す必要があるときに、元にある名詞で明記します。近くにある名詞というだけで指す先を決めず、候補が複数ある場合は勝手に限定しません。確定した対象の再掲と、新しい対象を足すことを区別します。 動詞を言い換えた後も語順を確かめ、元の関係を保ったまま主語と述語を追いやすくする案を検討します。主述を近づけるために修飾先や条件の範囲を変えず、元から自然な語順は保ちます。
擬人化の解消
非生物主語を直すのは、道具や概念に感情や意志を持たせている擬人化表現(「コードが語る」「システムが願う」等)のときを基本とします。道具や仕組みの働きを客観的に述べている文(「このツールはログを集めます」等)はそのまま残します。人が自分でした行動や判断を、抽象名詞が作用したように書いている文(「見積もりの甘さが判断を遅らせた」等)は、原文や前後から誰の行動か分かる場合だけ、その人の行動として書きます(gemini-syntax.md 原則3)。直す場合も、元にない条件(「〜を使えば」)や可能(「〜できます」)を足しません。
比喩動詞の具体化
「倒す」「効く」「溶かす」「潰す」といったAI特有の比喩表現を、ふだん使う言葉や文脈に合った言葉に書き換えます。「発生」「担保」など過度に硬い2字漢語を不要な場面で連発しません。意味を保った自然な言い換えができない場合は無理に変えず、元の動詞を残します。 比喩や言い回しが持っていた「含み(気持ちや評価の向き)」は必ず残します。
- 含みの例: 「うっかり」の不注意、「ようやく」の待ちくたびれた感じ、「〜てしまった」の後悔、「地味に」の目立たないけれど確かにある感じ。
- 比喩の語は言い換えて構いません。ただし、その語が伝えていた含みや理由は、別のふだんの言葉で補って言い表します。
- 言い換えるときは、「良いほうに働いている」「助けになっている」のように、効き目や評価だけをぼんやり述べる言い方にしません。何がどう変わったのかを書くか、ふだんの文章で使われる言い方を選びます。
- 比喩動詞だけでなく、副詞や前置きの言い回しも同じ扱いにします。 データやシステムに対して使われる「壊れる」は、「おかしくなる」「使えなくなる」のように、意味の広さが同じふだんの言葉に改めます。「データの整合性が失われる」「不整合が生じる」と書くのは、元の文や前後から、明らかに整合性の話だと分かるときだけに限定します。時計や機械などの物体や、身体(お腹を壊す等)の文字どおりの「壊れる」はそのまま残します。また、「静かに」「黙って」のようなぼかしは、「気づかないうちに」「知らないうちに」のように気づけないという幅のまま書きます。「エラーを出さずに」「通知なく」のように仕組みの話として書くのは、元の文や前後から、エラーや通知が出ないことがはっきり分かるときだけに限定します。 また、「骨が折れる」「手を焼く」「目から鱗が落ちる」「首を長くして待つ」のような、ふだんの日本語で定着した慣用句は、AIっぽい比喩として扱わずそのまま残します。業務仕様でも、意味を取り違えるおそれがなければ残します。迷ったときの目安は、その言い方を、AIが広まる前の人の文章でもふつうに見かけるかどうかであり、見かけるなら残します。
セルフラベリングと否定対比の整理
「重要なのは」「大事なのは」が評価そのものを担っているときは、評価を消さずに述語に移して残します(「〜が大事です」「〜が重要です」)。前置きを削ってよいのは、削っても主張が変わらないときだけです。 前置きが理由・対比・結論や、説明から方針への切替を示す場合は、その関係を残します。「結論として」が比較結果と採用方針をつないでいる場合など、他の語から同じ関係が読めなければ削りません。ただし、文頭の「もちろん、」のあとに数語だけが続いて終わる短い文(「もちろん、失敗もする。」)で、読み手が思いそうなことを先回りして認めているものは、AIの文章らしく見えやすいため、随筆でも「もちろん、」を外します。当然のこととして認める含みがあることだけを理由に残さず、その含みを「当然、」「言うまでもなく、」などの別の語で補うこともしません。認めている内容とその程度は残し、元にない理由や因果やつなぎの語は足しません。会話や引用の中の「もちろん」、問いや依頼への答え(「もちろんです。」)、条件や前提を確かめる文、「もちろん、」の後に同じ文の中で具体的な内容が続く文、文の途中の「もちろん」(「AはもちろんB」など)は、この扱いの対象にしません。 否定対比(AではなくB)は、否定を外しても主張が変わらないときだけ肯定文にします。Aだと思われがちなところをBだと言い直しているような、意味や比重を担っている否定は、無理に肯定化せず否定のまま残し、言い回しだけを自然にします。否定していたAを「Aに加えてB」と並べたり、「AよりB」と順位づけしたりしません。「弱みではなく、視点の違いでもある」のように否定のあとに「でもある」と続ける文は、否定と「も」をどちらも保ち、一つの文のまま残します。「弱みではない。視点の違いでもある。」と2文に分けたり、「でもある」の意味を書き手に尋ねたりしません。「弱みであると同時に、視点の違いでもある」のように、否定していたAを認める形にも変えません。否定を残すときに、元にない理由の文は足しません。 直前で問いなどとして挙げた二つを、続く文が「〜ではない」「〜でもない」のような否定の形で両方とも打ち消すだけの場合は、「どちら」が何と何を指すかが直前の文脈から一通りに決まるときに限り、挙げた語を繰り返さずに「どちらでもない。」(敬体なら「どちらでもありません。」)と短く受けて構いません。「どちら」が直前の二つを指すので、打ち消す内容は保たれます。打ち消すほかに問いにない内容(「決して」のような強めの語、限定、なぜ違うかの説明など)を含む否定は、短くせずに書きます。
情報の不増補(足さない)
「勝手に足さない」は、原文だけでなく、依頼や提供資料に明示された内容を根拠にします。この原則は本文だけでなく、「変えたところ」「残したAIっぽいところ」「書き手に確かめたい点」のすべての出力欄に適用します。読者の理解に必要な定義、識別子、値と状態の対応が提供されている場合は、説明に活かします。提供済みの文脈を無視して必要な情報を減らすことはしません。 一方で、読み手に不要な説明を毎回足す決まり
Truncated for display — read the full file on GitHub.
Related Skills
ai-job-search
46.3kThe job search that runs on your machine. AI job application framework built on Claude Code: evaluate postings, tailor CVs, write cover letters, prep interviews. Fork it and own it.
claude-howto
41.8kA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.
algorithmic-art
177.9kCreating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems.
pptx
177.9kUse this skill any time a .pptx or .potx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx or .potx file (even if the extracted content will be used elsewhere, like in an em…
Languages
Trust signals
From repository metadata: license, adoption, age and documentation. Not a code audit — see the Safety scan above for what the skill file itself contains.
