unslop

Unslop

テキストから AI らしい表現を取り除き、人間らしい語り口を加えます。

手順

1. 以下のパターンがないか確認します。
2. 意味を保ち、意図したトーンに合わせて書き直します。
3. 魂を込めます（次のセクションを参照）。
4. 最後に自分で確認します。「これが明らかに AI 生成だとわかるのはなぜか？」残っている特徴を修正します。

魂を込める

パターンを取り除くのは、作業の半分にすぎません。無機質で個性のない文章も、同じくらいすぐに見抜かれます。

• 自分の意見を持ちましょう。 事実をただ中立的に並べるのではなく、事実に対して反応します。
• 文章に緩急をつけましょう。 短い文を書いたら、今度はゆったりとした長い文を書きます。変化をつけましょう。
• 複雑さを認めましょう。 「印象的ですが、どこか不安にもなります」は「印象的です」よりも伝わります。
• 合うときは「私」を使いましょう。 一人称を使っても、プロらしさは損なわれません。
• 少しの粗さは残しましょう。 完璧な構成は機械が作ったように見えます。
• 具体的に書きましょう。 「これは懸念されます」ではなく、「エージェントが午前3時にひたすら動き続けているのは、どこか不穏です」と書きます。

見つけて修正するパターン

内容

1. 大げさな表現。 「重要な転機」「〜の証し」「進化する状況」「〜への道を開く」「消えることのない足跡」「深く根ざした」などです。大げさな表現を削り、実際に起きたことを書きます。
2. 名前の羅列。 文脈もなくメディアを列挙することです。一つ選び、何が報じられたのかを書きます。
3. 表面的な -ing 句。 「〜を強調し」「〜を確実にし」「〜を反映し」「〜を披露し」「〜を促進し」などです。削除するか、実際の出典に基づいて詳しく説明します。
4. 宣伝文句。 「ひっそりと佇む」「活気に満ちた」「息をのむような」「画期的な」「名高い」「見事な」「必見の」などです。中立的な説明に置き換えます。
5. 曖昧な出典。 「専門家は信じています」「業界レポートによると」「一部の批評家は主張しています」などです。出典を明示するか、削除します。
6. 型どおりの課題表現。 「課題はあるものの、繁栄を続けています」などです。具体的な事実に置き換えます。

言葉遣い

7. AI らしい語彙。 さらに、重要な、深く掘り下げる、長続きする、強化する、促進する、獲得する、相互作用、複雑な、状況（抽象的な意味）、極めて重要な、披露する、織物（抽象的な意味）、証し、強調する、活気に満ちた、などです。平易な言葉に置き換えます。
8. 「です」を飾り立てた表現。 「〜として機能する」「〜として存在する」「〜を誇る」「〜を備える」などです。単に「です」または「あります」と書きます。
9. 「X だけでなく、Y も」。 伝えたいことを直接書きます。
10. 3 つ並べる癖。 アイデアを無理に 3 つ組にします。自然な数を使います。
11. 同義語の使い回し。 一つの段落で、主人公、主役、中心人物、ヒーローを使い分けることです。一つ選び、繰り返し使います。
12. 意味のない範囲表現。 X と Y が意味のある尺度上にないのに「X から Y まで」とすることです。話題をそのまま列挙します。

スタイル

13. em ダッシュの多用。 em ダッシュと en ダッシュは使わず、代わりにハイフンを使うことも避けます。文を区切りたいときは、文を終えるか、コンマを使います。括弧は本当に補足が必要な場合なら構いませんが、ダッシュをすべて括弧内の節に置き換えると、別の癖が生まれます。
14. コロンの多用。 リストや例の前でコロンを使うのは問題ありません。文の途中でつなぎとして使うのは避けます。「従来型の自動化から移行するなら：イベントハンドラーを登録する代わりに、条件を記述します」のようなコロンは不要です。比較の枠組みに頼らず、伝えたいことが伝わるように書き直します。「スケジューラーをいつ実行するかは、平易な英語で記述するのが最適です」とすれば、同じ意味を不自然な句読点なしで伝えられます。
15. 太字の多用。 固有名詞や略語すべてを太字にしないでください。
16. 見出しを埋め込んだリスト。 太字のラベルとコロンで、その行の内容を言い換えるパターンです。「パフォーマンス： パフォーマンスが向上しました……」のような書き方です。文章に直します。項目名を示す太字の導入句がピリオドで終わり、その後に新しい詳細が続く形（「TypeScript でのスキーマ。 テーブルは一つのファイルにあります。」）は問題ありません。
17. タイトルケースの見出し。 文頭のみ大文字にします。
18. 飾りの絵文字。 見出しや箇条書きから削除します。
19. カールした引用符。 まっすぐな引用符に置き換えます。

コミュニケーション上の表現

20. チャットボットらしい表現。 「お役に立てば幸いです！」「何かあればお知らせください……」「もちろんです！」「承知しました！」「決定的な証拠が見つかりました！」は削除します。
21. 情報不足に関する免責表現。 「具体的な詳細は限られていますが……」は、情報源を探すか削除します。
22. へつらう口調。 「素晴らしい質問です！まったくそのとおりです！」ではなく、質問に直接答えます。

冗長な表現

23. 冗長な言い回し。 「〜するために」は「〜する」にします。「〜という事実により」は「〜なので」にします。「注意すべき重要な点は」は削除します。
24. 過剰な曖昧表現。 「そうである可能性もあり得ると主張できるかもしれません」は「〜かもしれません」にします。
25. 一般論で締めくくる表現。 「将来は明るいでしょう」ではなく、具体的な計画や事実を示します。

専門用語

26. 抽象的な比喩表現の名詞。 substrate、wedge、vector、locus、vantage、nexus、primitive（名詞）、harness（比喩）、surface（「API surface」のような使い方）、bedrock、scaffolding（比喩）、modality、paradigm、gold-plating、ratchet（比喩）、evacuate（コードの移動を表す場合）、endgame、north star、flywheel。技術的に聞こえますが、たいていもっと平易で具体的な言葉に置き換えられます。「substrate」は「基盤」に、「wedge in」は「追加する」に、「vector」は「方法」に、「gold-plating」は「必要以上の機能」にします。「ratchet」は仕組みの実際の名称か「締め付けるだけの制限」に、「evacuate」は「移動する」に、「endgame」は「最終段階」にします。具体的な言葉を選びます。

平易な表現

27. どう感じるかではなく、何をするかを説明します。 「データベースがすぐ近くにある」「読みやすいSQL」「スキーマに沿った型」は、感覚を表しています。仕組みや数値を示す表現に直します。「.toSQL()は、データベースに送信する文字列をそのまま返します」「列名を変更するとビルドに失敗します」のようにします。その文から読者が何をすべきか、何を知るべきかを確認してから書きます。具体的な指示、事実、数値として言い換えられない文は削除します。もう一つ確認します。その文が別のプロジェクトのドキュメントにもそのまま使えるなら、このプロジェクトについて何も伝えていません。削除します。
28. 長く複雑な文は短くするか、分割します。 文の意味を理解するために読み返す必要があるなら、二つに分けるか、節を削ります。一文につき一つの内容にします。
29. 能動態を使います。 受動態より能動態を優先します。「is／are／was／were ＋ 過去分詞」を見つけて、動作主を明示します。「クエリが検証される」は「コンパイラーがクエリを検証する」に、「ファイルはローダーによって解析される」は「ローダーがファイルを解析する」にします。動作主が不明な場合や、本当に重要でない場合に限り、受動態を使います。
30. 副詞を削るか、より強い動詞に置き換えます。 「すばやく実行する」は「高速に実行する」か具体的な数値にします。「大幅に改善する」は測定した差分にします。弱い動詞を補う副詞が必要なら、その動詞が適切ではありません。
31. 平易な言葉を優先します。 「utilize」は「使う」、「leverage」は「活用する」、「facilitate」は「助ける」、「numerous」は「多くの」、「in the event that」は「〜の場合」にします。凝った同義語を使っても、明確になることはほとんどありません。

関連スキル

• code-comments - コード内でも同じ考え方を適用します。行の内容を言い換えただけのコメントは削除し、理由を説明するコメントは残します。
• リポジトリの CLAUDE.md / AGENTS.md - 言語、口調、用語に関するプロジェクトのルールです。このガイドの既定値より優先されます。