unslop

Unslop

AI らしいパターンを取り除くようにテキストを編集します。

手順

1. 以下のパターンがないか確認します。
2. 書き直します。意味を保ち、意図したトーンに合わせます。
3. 自分で確認します。「AI が生成したと一目でわかるのはどこか」。残っている特徴を修正します。

検出して修正するパターン

ルール番号は、他のスキルから参照される固定 ID です。ルールが削除されても、番号は欠番のままにします。

内容

3. 表面的な -ing 句。 「highlighting...」「ensuring...」「reflecting...」「showcasing...」「fostering...」など。削除するか、信頼できる根拠を加えて詳しく説明します。
4. 曖昧な出典。 「専門家はそう考えています」「業界のレポートによると」「批評家の中にはこう主張する人もいます」など。出典を明記するか、削除します。

言葉遣い

7. AI がよく使う語彙。 Additionally、crucial、delve、enduring、enhance、fostering、garner、interplay、intricate、landscape（抽象的な意味）、pivotal、showcase、tapestry（抽象的な意味）、testament、underscore、vibrant。平易な語に置き換えます。
8. 「is」の凝った言い換え。 「serves as」「stands as」「boasts」「features」など。「is」や「has」と言い切ります。
9. 「X だけでなく Y も」。 要点を直接述べます。
10. 3 つにまとめるルール。 アイデアを無理に 3 つにまとめること。自然な数を使います。
11. 類義語の使い回し。 1 つの段落で protagonist、main character、central figure、hero を使うこと。1 つに決めて繰り返し使います。
12. 不適切な範囲表現。 意味のある尺度ではない X と Y に対して「from X to Y」を使うこと。話題を直接列挙します。

スタイル

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

コミュニケーション上の癖

20. チャットボットらしいフレーズ。 「お役に立てば幸いです！」「何かあればお知らせください」「もちろんです！」「承知しました！」「原因を突き止めました！」など。削除します。
21. へつらうような口調。 「素晴らしい質問です！」「おっしゃるとおりです！」など。直接答えます。

冗長な表現

23. 埋め草のフレーズ。 「In order to」は「To」に、「Due to the fact that」は「Because」に置き換えます。「It is important to note that」は削除します。
24. 過剰な婉曲表現。 「could potentially possibly be argued that it might」は「may」に置き換えます。
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」は「base」に、「Wedge in」は「add」に、「Vector」は「way」や「method」に、「Gold-plating」は「仕事に必要な範囲を超えること」に置き換えます。「Ratchet」は実際の仕組みの名称か「一方向にしか厳しくならない上限」に、「Evacuate」は「move out」に、「Endgame」は「最終段階」に置き換えます。具体的な言葉を選びます。

平易な表現

27. どう感じるかではなく、何をするかを書きます。 「データベースをすぐ使える状態に保つ」「読みやすい SQL」「スキーマに従う型」は、感覚を表しています。仕組みや数値を示す表現に置き換えます。「.toSQL() はデータベースに送信する文字列をそのまま返します」「列の名前を変更するとビルドに失敗します」のように書きます。その文が読者に何をすべきか、何を知るべきかを伝えているかを考え、それを書きます。具体的な指示、事実、数値として言い換えられない場合は削除します。もう一つ確認します。その文が別のプロジェクトのドキュメントにもそのまま載せられるなら、このプロジェクトについて何も述べていません。削除します。
28. 長く複雑な文は短くするか、分割します。 文を理解するために読み返す必要があるなら、二つに分けるか、節を削ります。一文につき一つの考えにします。
29. 能動態を使います。 能動態を優先します。「is/are/was/were + 過去分詞」の形に注意し、動作の主体を明記します。「queries are validated」は「the compiler validates queries」に、「the file is parsed by the loader」は「the loader parses the file」に置き換えます。動作の主体が不明、または本当に重要でない場合に限り、受動態を使ってもかまいません。
30. 副詞を削るか、より力強い動詞を使います。 「runs quickly」は「is fast」または数値に置き換えます。「significantly improves」は測定した差に置き換えます。弱い動詞を補う副詞があるなら、その動詞は適切ではありません。
31. 平易な言葉を選びます。 「utilize」は「use」に、「leverage」は「use」に、「facilitate」は「help」に、「numerous」は「many」に、「in the event that」は「if」に置き換えます。凝った類義語を使っても、たいてい分かりやすくはなりません。
32. 気取った文章を避けます。 文字どおりの表現があるのに比喩や装飾的な表現を使うこと、格言めいた表現（「配線するか削除するか」など）、効果を狙った断片的な文、コードを擬人化する表現（「計画がそれを保持する」など）、比喩的な動詞（「同乗する」「〜の上に立つ」など）、ありきたりな前置きの表現は避けます。「調整する価値のあるダイヤル」は「値を変える価値のあるパラメーター」に置き換えます。言いたいことをそのまま述べます。比喩的な名詞についてはルール 26 を参照してください。
33. 過度に圧縮しないでください。 冠詞を省いたり、動詞のない断片的な文にしたり、記号だけで表したり、読者に解読させるような略語を使ったりすることは避けます。「Parser rejects bad date → exit 2, no write」は「The parser rejects a bad date, exits with code 2, and writes nothing.」に置き換えます。冠詞と動詞を備えた完全な文を書き、矢印や略語は省略せずに表します。