de-slopify について
de-slopifyは、編集者や執筆者向けに、よくあるAI文章の癖を見直すスキルです。機械的な置換ではなく、一行ずつ確認し、一般化された表現に置き換わった具体的な情報を戻す方法を示します。
主な機能
- 01詳細版と簡易版のレビュープロンプト
- 02AI文章に多いパターンの一覧
- 03具体的な情報を戻すための指針
- 04手作業による文章レビュー手順
活用シーン
- 01公開前のREADMEの確認
- 02AIで下書きしたドキュメントの編集
- 03一般化や誇張表現の点検
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ dicklesworthstone/ agent_flywheel_clawdbot_skills_and_integrations --skill de-slopifyインストール後、Claude Code で/de-slopifyを入力して読み込まれたか確認します。
同梱ファイルreferences/PATTERNS.md
詳細
De-Slopify — AI 執筆特有の癖を取り除く
核心的な洞察: 正規表現やスクリプトではできません。各行を手作業で体系的に見直す必要があります。スロップには一定の仕組みがあります。文章は具体性が薄れると同時に、大げさになっていきます。珍しい具体的な事実が、重要そうに聞こえる一般的な主張へと均されてしまうのです。つまり、修正は癖を削除するだけでは済みません。スロップによって押しのけられた具体的な詳細を取り戻す必要があります。人間の書き手は、こうした表現の多くを意図的に、控えめに使います。問題なのは個々の表現ではなく、密度の高さと反射的な使用です。
正確なプロンプト — 完全版 De-Slopify
I want you to read through the complete text carefully and look for any telltale
signs of "AI slop" style writing; one big tell is the use of emdash. You should
try to replace this with a semicolon, a comma, or just recast the sentence
accordingly so it sounds good while avoiding emdash. This applies to emdashes
used as prose punctuation only: leave dash/minus characters alone when they are
doing non-prose work, such as in math formulas, code, CLI flags, numeric ranges,
or tables.
Also, you want to avoid certain telltale writing tropes:
- Setup-reversal copy ("Four steps, and only one of them is yours." /
"Everything about billing changed. Your invoice didn't.")
- Negative parallelism ("It's not [just] XYZ, it's ABC")
- Clickbait lead-ins ("Here's why", "Here's the thing")
- AI vocabulary clusters (delve, pivotal, tapestry, intricate, underscores,
seamless, robust, vibrant, leverage) and copula avoidance ("serves as",
"marks a", "boasts" instead of plain "is"/"has")
- Significance inflation ("marks a pivotal moment", trailing "-ing" commentary
clauses like "highlighting its importance")
- Bullet lists of "- **Snappy Label:** text" where prose would read better
- Filler: paragraphs that say in four sentences what fits in one
Basically, anything that sounds like the kind of thing an LLM would write
disproportionately more commonly than a human writer and which sounds
inauthentic/cringe.
And you can't do this sort of thing using regex or a script, you MUST manually
read each line of the text and revise it manually in a systematic, methodical,
diligent way. Use ultrathink.
正確なプロンプト — 簡易版
Review this text and remove AI slop patterns: emdashes used as prose
punctuation (not dashes in math, code, or ranges), setup-reversal copy, "It's not X, it's Y" formulas, "Here's
why" lead-ins, AI vocabulary (delve/pivotal/tapestry/underscores/seamless),
"serves as" instead of "is", trailing "-ing" significance clauses, bold-label
bullet lists, and filler. Recast sentences to sound naturally human; restore
concrete specifics where slop replaced them. Use ultrathink.
すぐに修正すべき、顕著な兆候
| パターン | 例 | 修正方法 |
|---|---|---|
| 前置きを覆す表現(パラプロスドキアン) | 「4つの手順があり、そのうち自分で行うのは1つだけです。」/「何千もの連携機能があり、クリックするのは結局1つだけです。」/「請求に関することはすべて変わりました。請求書は変わりません。」 | ツールの機能を率直に述べます。劇的な展開は不要です。 |
| 否定による対比 | 「単なるリンターではなく、完全なシステムです」/「XではなくY」/「XもYもなく、Zだけ」 | それが何であるかを述べ、藁人形論法のような否定は省きます。 |
| AI らしい語彙の集中 | delve、tapestry、intricate、pivotal、robust、seamless、vibrant、leverage、testament、landscape、spine、seam、smoke-test(複数が一緒に出てくる) | 平易な同義語に置き換えます。目印になるのは語彙の密度です。 |
| コピュラの回避 | 「serves as」「stands as」「marks a」「has」の代わりに「boasts/features/offers」、「holds the distinction of being」 | 「is」/「has」を使います。 |
| 重要性の誇張 | 「marks a pivotal moment」「underscores the importance」、文末に続く「, highlighting...」/「, emphasizing...」/「, ensuring...」節 | 解説を削り、事実は残すか補います。 |
| 「Here's why」系の表現 | 「Here's why it matters:」「Here's the thing」「解決策は?思ったより簡単です。」 | 直接説明するか、削除します。 |
| ダッシュの多用 | 散文の句読点としての —(数学、コード、範囲表記のダッシュは対象外) | コンマ、セミコロン、コロンに置き換えるか、文を分けます。 |
| 太字ラベル付きの箇条書き | - **超高速:** ファイルをミリ秒単位で処理 | 散文にするか、通常の箇条書きにします。 |
| 無理に盛り上げる表現 | 「さっそく見ていきましょう!」、「発表できることを大変うれしく思います」 | すぐに本題に入るか、そのまま発表します。 |
| 反射的な3項並列 | 「高速、効率的、かつ信頼性が高い」/3つ目の項目を「その他のX」で水増しする | 真実で具体的な主張だけを1つか2つ残します。 |
| 中身のないつなぎ | 「テクノロジーが進化し続けるなかで」、「目まぐるしく変化する今日の世界では」、文頭の「さらに、」 | 削除するか、実際のつながりを示す表現に置き換えます。 |
判断が必要な点(密度が高ければ修正し、効果があれば残す)
- 埋め草:内容が1文に収まる段落や、明確な主張がない段落です。短くするか削除します。これがスロップの本質です。
- ありきたりな比喩:「すべての和音は、曲にはまるパズルのピースです」のような、もっともらしくてもよく考えられていない比喩です。削除するか、具体的な表現にします。
- ぼかし表現(「注目すべきなのは……」「覚えておいてください……」):読み手の行動を変える注意点でない限り、削除します。
- 書式のスロップ:強調の意図がない散発的な太字、絵文字の箇条書き(✅🎯🚀)、タイトルケースの見出し、見出しだけのセクション、セクションごとに入る区切り線、散文を表にすること、箇条書きの多用。
- 単調なリズム:すべての文が同じ長さで、時制や視点が不自然に均一です。変化をつけます。
- 優雅な言い換え:重要な用語を同義語に置き換えていくことです。技術文書では同じ用語を繰り返します。
- 出典をぼかした帰属:「専門家は主張しています」、「業界レポートによると」。出典を明記するか、主張を削除します。
- 課題を並べる定型パターン:「Xにもかかわらず、いくつかの課題に直面しています……今後の展望……」。この展開を削り、実際の制約を1つ残します。
偽の手がかり(「修正」しないでください)
- 文法が完璧で誤字がないこと — 人間もスペルチェックを使います
- 短縮形が使われていないこと — ハウススタイルや、英語が母語ではない人の表現かもしれません
- 学術的な語彙だけが使われていること — 一箇所に「ascertain」があっても、AI っぽい文章ではありません。AI 特有の語彙がまとまって使われているかどうかが重要です
- 本文以外でのダッシュ文字 — 数式のマイナス記号、コードや CLI フラグのダッシュ、数値範囲の en ダッシュ、表の構文などが該当します。手がかりになるのは、本文の句読点として使われた em ダッシュだけです
- AI 検出ツールの出力 — こうしたツールは頻繁に誤検出します。どちらの方向にも、人間が判断してレビューしてください
修正前/修正後の例
設定を逆転させる文章:
Before: Ten features. Zero headaches.
After: Includes ten features for managing billing, invoicing, and usage tracking.
em ダッシュ+否定の並列表現:
Before: It's not just a linter—it's a complete code quality system.
After: A code quality system that covers linting, formatting, and CI checks.
「その理由を説明します」:
Before: We chose Rust for this component. Here's why: performance matters.
After: We chose Rust for this component because performance matters.
重要性の誇張(具体的な事実を復元する):
Before: The v2 release marks a pivotal moment, underscoring our commitment to reliability.
After: v2 fixes the three crash bugs reported since March.
コピュラの回避:
Before: The CLI serves as the primary entry point and boasts a robust plugin system.
After: The CLI is the primary entry point and has a plugin system.
不自然な熱意:
Before: Let's dive in! We're excited to help you get up and running.
After: Install the tool and run your first command in under a minute.
ワークフロー
- 全文を一度読み、文体を確認します。宣伝文句のようですか、それとも講義のようですか?
- 一行ずつ確認し、目立つ手がかり(上の表を参照)に印を付けます
- 密度を確認します。判断が必要なパターンは、集中して現れている箇所だけ修正します
- 具体性を確認します。誇張した主張を削った箇所には、具体的な事実を戻します
- 仕上がりを読み直します。有能なエンジニアが説明しているように聞こえるべきで、ブランドの宣伝のようになってはいけません
手作業でのレビューが必要な理由
- 文脈が重要です — em ダッシュや三項表現が適切な場合もあります
- 文の書き換えが必要です — 多くの場合、単語を置き換えるだけでは修正できません
- 具体性を取り戻します — スクリプトは「pivotal」を削除できても、欠けている事実を補うことはできません
- 文体の一貫性を保ちます — 全体を通して一つの語り口を維持する必要があります
不自然さを取り除くタイミング
- README を公開する前
- ドキュメントをリリースする前
- AI を使った執筆セッションの後
- ドキュメントのレビュー中
修正しないもの
- 技術的な正確さ — 文体のために正確さを犠牲にしないでください
- 必要な構成 — 実際の内容を整理する見出しやリストは問題ありません
- 明確な説明 — 丁寧な説明は不自然さではありません。冗長さとは、長々と書いて何も伝えないことです
- コード例 — コードではなく本文に注目してください
- 効果的な表現技法 — 意図的に一度だけ使われ、実際の効果がある表現技法は残してかまいません
参考資料一覧
| トピック | 参考資料 |
|---|---|
| 修正方法を含むパターンの完全な一覧 | PATTERNS.md |
コメント
Markdown 対応