unslop

Unslop

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. 三つ並べるルール。 アイデアを無理に三つのまとまりにしないでください。自然な数にします。
11. 類義語の使い回し。 同じ段落で protagonist、main character、central figure、hero と言い換え続けないでください。一つを選び、繰り返し使います。
12. 意味のない範囲表現。 意味のある尺度上にない X と Y を「X から Y まで」と表現しないでください。項目を直接列挙します。

スタイル

13. ダッシュの多用。 ダッシュは使わないでください。句点か読点のみを使います（括弧、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、wedge in（追加する）、vector（方法）、locus、vantage、nexus、名詞としての primitive、比喩としての harness、「API surface」のような surface、bedrock、比喩としての scaffolding、modality、paradigm、gold-plating（必要以上に作り込むこと）、比喩としての ratchet（実際の仕組みの名称、または一方向にしか厳しくならない制限）、コードの移動を指す evacuate（移動する）、endgame（最終段階）、north star、flywheel などです。技術的に聞こえても、より平易で具体的な言葉に置き換えられることがほとんどです。具体的な言葉を選んでください。

平易な表現

27. 感想ではなく、何をするかを書きます。 「データベースをすぐ使える状態に保つ」「読みやすい SQL」「スキーマに従う型」は、感覚を表しています。仕組みや数値を示す表現に直します。たとえば、「.toSQL() はデータベースに送信される文字列をそのまま返します」「列の名前を変更するとビルドに失敗します」とします。その文が読者に何をすべきか、何を知るべきかを伝えているかを確認し、それを書きます。具体的な指示、事実、数値として言い換えられない場合は削除します。もう一つ確認します。その文を別のプロジェクトのドキュメントにそのまま載せられるなら、このプロジェクトについて何も伝えていません。削除します。
28. 長く複雑な文は短くするか、分割します。 文を理解するために読み返す必要があるなら、二つに分けるか、節を削ります。一文につき一つの考えを述べます。
29. 能動態を使います。 できるだけ能動態にします。「be動詞＋過去分詞」の形を見つけたら、動作主を明示します。「クエリが検証されます」は「コンパイラーがクエリを検証します」に、「ファイルはローダーによって解析されます」は「ローダーがファイルを解析します」に直します。動作主が不明な場合や、本当に重要でない場合に限り、受動態を使ってもかまいません。
30. 副詞を削るか、より明確な動詞を使います。 「すばやく実行します」は「高速です」または具体的な数値に、「大幅に改善します」は測定された差分に直します。弱い動詞を補う副詞があるなら、その動詞が適切ではありません。
31. 平易な言葉を選びます。 「利用する」「活用する」は「使う」、「促進する」は「助ける」、「多数の」は「多くの」、「その場合には」は「もし」に置き換えます。凝った類義語が明確さを高めることは、ほとんどありません。
32. 気取った文章は避けます。 文字どおりの表現があるのに、比喩や華美な表現を使うことです。格言風の表現（「つなぐか、削除するか」）、効果を狙った断片的な文、コードの擬人化（「その計画が保持する」）、比喩的な動詞（「付いて回る」「土台となる」）、定型的な前置きなどが該当します。「調整する価値のあるダイヤル」は「値を変える価値のあるパラメーター」とします。意図をそのまま書きます。比喩的な名詞についてはルール26を参照してください。
33. 過度な圧縮は避けます。 冠詞の省略、動詞のない断片的な文、記号だけの表現、読者が読むのではなく解読しなければならない略語を避けます。「パーサーが不正な日付を拒否 → 終了コード2、書き込みなし」は、「パーサーは不正な日付を拒否し、終了コード2で終了して、何も書き込みません」とします。冠詞と動詞を含む完全な文を書き、矢印や略語は省略せずに表記します。