stop-slop-ja

name	stop-slop-ja
description	Remove AI writing patterns and enforce rigorous technical-prose conventions in Japanese. Derived from hardikpandya/stop-slop + k16shikano japanese-tech-writing. NEVER 32 + 論証と構成の規範 + 用語と register の自然さ + クイックチェック 27 + 5 軸スコアリング + 翻訳調 AI 語の検出を含む。Use when drafting, editing, or reviewing Japanese text to eliminate predictable AI tells and tighten argumentation.
metadata	{"trigger":"日本語の記事執筆、技術書・解説文の草稿、ドラフト編集、AI 生成文章のリライト","derived-from":["https://github.com/hardikpandya/stop-slop","https://gist.github.com/k16shikano/fd287c3133457c4fd8f5601d34aa817d"],"language":"日本語","license":"MIT"}

Stop Slop JA

日本語の文章から AI の書き癖を排除し、技術文書としての論証を締める。

二系統の規範を統合する。

• 表現の規範（slop 除去）: hardikpandya/stop-slop（MIT、Hardik Pandya）の日本語派生。本家のコアルール + 5 軸スコアリングを日本語向けに翻案し、日本語固有の AI 癖（口語的並列・〜的の濫用・受動態多用・カタカナ濫用・安直なまとめ・翻訳調 AI 語）を追加した。
• 論証と構成の規範: k16shikano / japanese-tech-writing を統合。パラグラフライティング、論証の厳密さ（推量を断定化しない／単一原因に還元しない／因果は機構を示す）、見出しの付け方、読者への誠実さを規範化した。

前者は「どの語・どの型を消すか」を、後者は「論理にツッコミどころを残さないか」を点検する。記事・X 投稿のような短い文章では前者が中心になり、技術書の章・解説文では後者が効く。

表現の規範（NEVER 32 項目）

必ず削除する 7 項目

1. Throat-Clearing Openers（前置きの咳払い）: 「実は」「ところで」「さて」「結論から言うと」「核心はこうだ」「以下に〜について」「ここで重要なのは」「興味深いことに」は削除し、本文から直接始める

2. Emphasis Crutches（強調の松葉杖）: 「重要なのは」「特筆すべきは」「強調すると」「だからこそ」「ここがポイント」「ここが面白い」は削除する。主張は予告せずそのまま書く（「重要なのは〜である」で前置きしない）。ただし様式の宣言（「標語として言い換えれば」など）は使ってよい

3. Adverbs（副詞の濫用）: 「とても」「まさに」「実は」「実際」「本当に」「結局」「単に」「素直に」「正直」「単純に」「実質的に」「本質的に」「本来」「必然的に」「興味深いことに」「重要なことに」「決定的に」「深く」は全削除を原則とする

4. Meta-Commentary（自己言及メタコメント）: 「ここから〜していきたい」「この節では」「以下で見ていく」「あらかじめ言っておくと」「メッセージは短くまとまる」「結論は単純だ」「言いたいことは 1 つ」、および予告と総括の型（「本章では〜を扱う／探求する」「ここでは〜を見ていく」「まとめると」「要するに」（直前の言い換えだけのとき）「〜に他ならない」）は削除する

5. Lazy Extremes（怠惰な極論）: 「常に」「いつも」「全て」「決して」「すべての」「皆」「誰もが」「絶対に」は具体的な範囲に置換する

6. エムダッシュ（——、—）: AI 生成の典型パターン。挿入句は句点で切る、セパレータは削除 or ｜ に置換、列挙の前置きも句点で切る

7. インラインバッククォート (code): note.com 非対応。コードブロック (```) かカギ括弧「」に置換

書き換える 6 項目

8. Binary Contrasts（二項対立形式）: 「X ではない、Y だ」「X ではなく Y」「これは X ではなく Y にある」型は telegraphed reversal として禁止。Y を直接述べる

   • 例: 「重要なのは技術ではない。人間関係だ」→「重要なのは人間関係だ」

9. Negative Listing（否定の列挙）: 「X ではない。Y でもない。Z だ」型の dramatic buildup は禁止。Z を直接述べる

10. False Agency（無生物主語＋人間動詞）: 「議論が深まる」「市場が報いる」「データが教える」「文化が変わる」「決断が生まれる」「会話が動き出す」は禁止。誰がやったかを名指しする

    • 例: 「議論が深まった」→「チームは A について議論を重ねた」

11. Dramatic Fragmentation（演出的断片化）: 「〜。それだけだ。これがすべてだ」「〜。そう。〜」型は禁止。完全な文で書く

12. Vague Declaratives（曖昧な断定）: 「本質的に重要だ」「構造的な問題」「示唆は深い」「実装上の課題」型は禁止。具体的な内容を述べるか、その文を削除する

13. Narrator-from-a-distance（傍観者視点）: 「誰も意図しなかった」「人は〜する傾向にある」「私たちは〜しがちだ」型は禁止。読者をその場に置く

    • 例: 「人々は〜する傾向にある」→「あなたが〜する場面では」
    • ※ 技術文書では「あなた」ではなく役割名・具体的な行為者を先に試す（#26 の register 注記を参照）

構造ルール 6 項目

14. Rhetorical Setups（修辞的お膳立て）: 「もし〜だとしたら？」「考えてみてほしい」「ここで言いたいのは」「そしてそれでいい」は禁止。直接ポイントを述べる

15. Wh-スターター（疑問詞先頭）: 「〜とは何か」「〜について」「なぜ〜なのか」「どうして〜なのか」「いかに〜か」型のセクション内冒頭は restructure する。主語または動詞から始める（タイトルは別）

16. 〜的の濫用: 「構造的」「本質的」「根本的」「表面的」「実用的」は 1 段落 3 件以上ある場合に削減する

17. 〜という / することができる / することが重要だ: 冗長化の典型。「AI というツール」→「AI」、「することができる」→「できる」、「重要だ」で言い切る

18. 口語的並列「ひとつめ / ふたつめ / みっつめ / よっつめ」: 字面が古風で並列の連続性が弱く、読者に違和感を与える。代わりに「第 1 に、〜」「第 2 に、〜」「第 3 に、〜」「第 4 に、〜」型を使うか、番号箇条書きに変換する

19. 安直なまとめ表現: 章末・記事末の以下の類型は禁止

    • 陳腐な比喩: 「両輪」「両翼」「2 本の柱」「2 本立て」「2 枚の翼」「車の両輪」
    • 偶然の必然化（収束クリシェ）: 「揃った」「出揃った」「出そろった」「同じ日に揃った」「同じ週に並んだ／重なった」「同時に動いた週」「期せずして」「奇しくも」。別々の出来事を「同じ週に偶然そろった」と束ねて演出しない（根拠: W27 で「AI の進歩と力学が同じ週に出そろった」がユーザー差し戻し）
    • 過剰意味付け: 「象徴する」「物語る」「示唆する」「映し出す」「浮き彫りにする」
    • メタコメント型まとめ: 「メッセージは短くまとまる」「結論は単純だ」「言いたいことは 1 つ」

    許容: 「受動的締め（〜が問われている / 試されている / 求められている）」と「時代論評（AI 時代の〜 / 〜時代の〜）」は記事の主題を読者に投げ返す機能として有効。誤検出回避のため許容する。

    正しい締め方: 数字を最後の一語にする / 断定で終わる / 観察事実だけ並べて自家評価を加えない / 読者の意思決定材料を残す

20. 翻訳調（translationese）: 英語からの直訳に読める箇所は自然な日本語に置き換える。これは語リストの暗記ではなく、原理での判定で行う（直訳調は無限に新パターンが生まれるため、列挙では追いつかない）。判定シグナルは 4 つ:

    • S1 英語動詞の逐語置換: expose→露出する / ship→出荷する / seed→種付け / land→着地する。日本語ネイティブが同じ状況で自然に選ぶ動詞に直す（備える / 提供する / セットする / 届く）
    • S2 英語形容詞の直訳: hard cap→硬い上限 / live→生きている / rich→豊かな。日本語の慣用にある組み合わせに直す（厳格な上限 / 動的な / 情報量の多い）
    • S3 英語構文のなぞり: "X is nothing but Y"→「X に過ぎない」/ "It's worth noting"→「注目に値する」。日本語として書き起こす構文に直す
    • S4 英語慣用句の逐語訳: "at the end of the day"→「一日の終わりに」/ "moving forward"→「前進して」。意味で訳す（結局 / 今後）
    • 漢語熟語結合の濫用（S2 の一種）: 中心命題 / 具体手順 / 位置付け / 接続する / 体系化 / 構造化された / 方向性 → 軸 / 進め方 / 〜にあたる / つながる / まとめる / 整った / 向き

    判定方法: 上記は例示であり判定基準そのものではない。実際の検出は LLM judge（references/translationese-judge.md のルーブリック）で「この文は英語の直訳に読めるか」を文ごとに判定する。

    過剰検出に注意: 素の LLM judge は「効く / 消える / 賭けだ / 生き延びる」のような完全に自然な日本語まで英語に逆翻訳して flag する（false positive 多発）。そのため 敵対的セカンドパス（critic が「これは自然な日本語だ」と弁護し、生き延びた候補のみ採用）で precision を回復する。スクリプト実装は scripts/judge-translationese.mjs（2 段構成、provider 切替式）。

    根拠: 2026-05-27 Varick 記事で「中心命題」が、05-28 Mem0 記事で「硬い上限 / 露出する / 出荷する / 着地する」がユーザー差し戻しを受けた。語リストへの追加では「次の直訳語」が漏れ続けるため、原理ベースの LLM judge + 敵対的検証へ移行（2026-05-30）。素の 1 パスは記事 1 本で 76 件の false positive を出したが、敵対的 2 パスで 6 件の真の検出に収束した。

整形・視点の規範 7 項目（k16shikano japanese-tech-writing 由来）

21. 正面から系の宣言: 「正面から扱う」「正面から回収する」「正面から見る／書く／立てる」は禁止。中身の代わりに姿勢だけを宣言している。何をどう扱うかを直接書く

    • 例: 「本章では、〇〇の理論を正面から扱う」→「本章では、〇〇の理論を扱う」

22. 空虚な形容・動詞・接続: 中身を説明せず強調・装飾だけする語を削除する

    • 空虚な形容: 「不可欠」「核心的」「鍵となる」「根本的な」「多角的」「包括的」「総合的」
    • 空虚な動詞: 「掘り下げる」「深掘りする」「言語化する」「触れる」「言及する」（一段落で済ませるだけのとき）
    • 接続の型: 「〜において」「〜という側面から」「〜の観点から」（新情報なし）、「さらに」「また」「加えて」の連打

23. 中黒（・）の並列（register-aware）: 技術書の原稿では日本語の並列に中黒を使わず、読点でつなぐか箇条書きにする。単一の固有名詞の内部（「クリーン・アーキテクチャ」等）は対象外。register 注記: note 記事・ブログ・X 投稿では中黒並列は確立した表記スタイルなので許容する（「判断・調整・承認」等）。この register ではレビュー補助にとどめ、4 語以上の長い連鎖や読みにくい箇所だけ読点・箇条書きに整える

24. 見出しの区切り線・二要素詰め込み: 見出し・コラム見出しに罫線（─）やダッシュ類で「種別──主題」「主題──概念」を詰め込まない。見出しは単一の自然な句にする。用語とその定義を並べる箇条書きは、区切り線ではなく全角コロンで「用語：説明」と書く

25. 一文一行（整形）: 原稿本文は一文ごとに改行する。段落の区切りは空行で示す。本筋から一段外れる補足は本文に並べず脚注（[^ラベル]）に降ろす。用語を初めて定義・導入するときはその語を太字にし、以後の言及・引用・通称は「」を使う

26. 架空人物・二人称・人名表記: 「入社2年目のエンジニアが」のような無意味な人物設定を冠さない。論証の中で読者を「あなた」と呼ばず役割名（「開発者」「読者」）で書く。二人称は場面導入（「〜としよう」）や章・本の結びなど要所にとどめる。人物そのものに言及するときは原綴り（Lehman、Bainbridge）で書く。ただし定着したカタカナ通称があるときはそれを使う

    • register 注記: 本家 stop-slop の False Agency 修正は「あなたを主語に」を勧めるが、技術文書ではこの規範（役割名）を優先する。X 投稿のような口語の短文では「あなた」を使ってよい

27. 術語の一貫（曖昧語に後退しない）: 章・節で術語（契約、不変条件、ハーネス等）を導入したら、以後はその語で通す。「文脈」「ツール」「AI」のような曖昧語に後退しない（定式化する前の導入語として使うのはよい）。対象を指す語は具体的に選び、「AI」「ツール」でぼかさない。術語の響きを持つ語を術語でない場面に流用しない

用語と register の自然さ 4 項目（2026-06 W26 校正リトロ由来）

28. 用語の説明は言い換えを優先し、括弧説明は最小限にする: 真に難解な語は、括弧で補うより平易な言い換えに直す（「重み」→「学習済みモデル本体」）。一般語（半導体・API・SDK 等）や、直後の文で意味が分かる語には括弧説明を付けない。1 段落に括弧説明を 3 件以上詰め込まない。説明過剰は削る。根拠: W26 で「重み」が説明不足で不可読、「オントロジー」「半導体（AI の計算に使う高性能チップ）」が説明過剰で削除された

29. 製品名・固有名は英語表記で統一する（カタカナ化しない）: Genie（×ジーニー）、Codex、Databricks。同一記事内で表記を揃える。業界で定着したカタカナ（スキル・エージェント等の一般概念）は対象外。根拠: W26 で見出しの「ジーニー」が本文の「Genie」と不一致

30. 比喩・言い回しの直訳を避ける: 英語の比喩をそのまま訳さない（living graph →×「生きたグラフ」→○「絶えず更新されるグラフ」）。定着した訳語（moat →「堀」等）は可。これは翻訳調 judge（語レベル）では拾えないため人手で見る。根拠: W26 で「生きたグラフ」が翻訳調 judge を通過したまま残った

31. 硬い書き言葉（book-ish）を register に合わせて平易にする: 記事・note では、書き言葉に寄りすぎた語を口語的に直す。通底する→共通する／一貫して流れる、降りてくる→使えるようになる、〜へ移る→〜へ動く・移っていく、価格→値段、中身が強い→性能が高い。抽象概念に器物接尾辞を付けた造語（検証器→検証の仕組み／検証する側）も「器」のガジェット感が出るため避ける。技術書原稿ではこの限りでない（register-aware）。これも禁止語リストにないため judge・grep を通過しやすい。根拠: W27 で「検証器」がユーザー差し戻し

構成オープナーの規範 1 項目（2026-06 W27 校正リトロ由来）

32. 前振り型オープナー（中身の前に「N 個出た」と宣言しない）: 章や段落を「今週は、〜が〜の形で 2 つ出た」「〜には 2 つの動きがあった」のような件数予告で始めない。読者は中身の前に要約を渡されると醒める。章は具体的な事実から書き始める（「今週、Oracle が約 2 万 1 千人を減らした」）。関連して、宙に浮く列挙ラベル「ひとつは、」「もうひとつは、」（→ NEVER 18）や「大きな一手があった」のような空の前置きも避ける。根拠: W27 で「今週は、AI と仕事の関係が、数字の形で 2 つ出た」「今週、米中の AI をめぐる綱引きが、2 つの形で表に出た」がユーザー差し戻し

クイックチェックリスト（27 項目、機械実行）

リライト完了後、機械的にスキャンする。1 つでもヒットしたら該当箇所を修正してから次のステップへ進む。

1. 副詞（とても / まさに / 実は / 実際 等）が残っていないか
2. 受動態（〜される / 〜られる / 〜となる）が濫用されていないか
3. 無生物主語＋人間動詞（議論が深まる / 市場が報いる 等）が残っていないか
4. Wh-スターター（〜とは何か / なぜ〜なのか）でセクションが始まっていないか
5. 前置きの咳払い（実は / ところで / さて / 結論から言うと）が残っていないか
6. 二項対立（X ではなく Y / X じゃなくて Y）が残っていないか
7. 3 連続の同じ長さの文がないか
8. 段落末が必ず punchy な一行で終わっていないか
9. エムダッシュ（——、—）が残っていないか
10. 曖昧な断定（本質的に重要だ / 構造的な問題 / 示唆は深い）が残っていないか
11. 傍観者視点（誰も意図しなかった / 人々は〜する傾向にある）が残っていないか
12. メタコメント（ここから〜していきたい / この節では〜）が残っていないか
13. 「〜的」「〜という」「することができる」「することが重要だ」が濫用されていないか
14. カタカナ語の濫用（エンゲージメント / インサイト / コミットメント 等）がないか
15. 口語的並列「ひとつめ / ふたつめ / みっつめ / よっつめ」が残っていないか
16. 安直なまとめ表現・収束クリシェ（両輪 / 揃った / 出そろった / 同じ週に並んだ・重なった / 象徴する / 物語る / メタコメント型）が残っていないか
17. 翻訳調（translationese）が残っていないか — grep ではなく LLM judge（敵対的 2 段） で検出する: node scripts/judge-translationese.mjs <file>。S1 動詞逐語置換 / S2 形容詞直訳 / S3 構文なぞり / S4 慣用句逐語訳の原理で判定し、critic パスで自然な日本語を棄却して precision を保つ。verdict が "needs_revision" なら high の flag を全て修正して再 judge
18. 正面から系（正面から扱う / 回収する / 見る）・空虚な形容（不可欠 / 核心的 / 多角的 / 包括的）・空虚な動詞（掘り下げる / 言語化する）が残っていないか
19. 中黒（・）の並列（固有名詞内部を除く）。技術書原稿では読点・箇条書きに、note 記事/X 投稿では許容（レビュー補助のみ）。見出しに区切り線で二要素を詰め込んでいないか
20. 推量・可能性・読者の疑念・反実仮想を、機械的に断定へ変えていないか（論証）。「かもしれない / だろう / ようだ」を、本文内の根拠で確定していないのに削っていないか
21. 別物を「同じ」とまとめていないか／複数の要因を単一の原因に還元していないか（論証）
22. 因果を主張する箇所に、その機構（なぜそうなるのか）が一文添えられているか。「必ず検出できる」「保証される」のような認識論的な無条件断定を書いていないか（論証）。手順・規約の命令文「必ず〜する」は対象外
23. 見出しが内容を特定する句になっているか（作業手順だけの見出し・結論を言い切る「セリフ」になっていないか）
24. 専門用語に過剰な括弧説明がないか。真に難解な語は括弧でなく言い換えたか（重み→学習済みモデル本体）。一般語・直後で分かる語に説明を付けていないか（用語のさじ加減）
25. 製品名・固有名を英語表記で統一したか（Genie / Codex 等・カタカナ化していないか）
26. 比喩の直訳（生きたグラフ 等）や硬い書き言葉（通底 / 降りてくる / 価格 / 〜に移る）が残っていないか（register。grep ではなく目視）
27. 前振り型オープナー（今週は、〜が〜の形で N 個出た / 大きな一手があった / 行頭の「ひとつは、」「もうひとつは、」）で章・段落を始めていないか。具体の事実から書き始めたか

→ 18-19・27 は表現レベル、20-23 は論証レベル、24-26 は用語と register の点検。論証の詳細は references/argumentation.md を参照する。

スコアリング（5 軸）

リライト後のテキストを各軸 1-10 でレートする。合計が 35/50 未満なら書き直す。

軸	問い
Directness（直接性）	断定しているか、告知に留まっていないか
Rhythm（律動）	文の長さに変化があるか、メトロノーム的でないか
Trust（信頼）	読者の知性を尊重しているか、過剰説明していないか
Authenticity（自然さ）	人間が書いたと感じるか、AI 的か
Density（密度）	削れる箇所はないか、密度が高いか

35/50 未満: 再リライト

スコアリングは表現の質を測る。論証の質は次節の必須チェックで別に点検する（スコアでは代替しない）。

論証と構成の規範（必須チェック）

表現を整えても論理にツッコミどころが残れば技術文書として失格になる。書き上げたら、読み手の反論を先回りして次を点検する。スコアではなく pass/fail で見る。詳細と Before/After は references/argumentation.md。

論証の厳密さ

• 推量を断定化しない: 「かもしれない」「だろう」「ようだ」は、根拠なく主張を弱めている場合だけ削る。事実未確認の可能性、作中人物の認識、ログからの推定、読者が抱きそうな疑念、反実仮想を表すなら、その不確実性を保つ。断定に直せるのは本文内の根拠で命題が確定している場合に限る
• 別物を「同じ」とまとめない: 区別すべき対象（別々の決定、別々の原因、種類の違う問題）を一括りの言葉でくくらない。腑分けする
• 単一原因に還元しない: 複数の要因がある事象を一つの原因に押し込めない。例が複数種類の問題を含むなら、それぞれを切り分け、どの道具がどれを説明するのか対応づける
• 因果は機構を示す: 「A だと B になる」とだけ書いて理由を省略しない。なぜそうなるのかを一文添える
• 「必ず」と書かない（認識論的断定に限る）: 検出・保証・解決を無条件にできるかのように書かない。条件付きで述べる（「〜しやすい」「〜できることが多い」「〜が成り立つときに限り」）。対象は認識論的な主張（「必ず検出できる」「品質は保証される」「すべて解決する」）に限る。手順・規約の命令文（「実行時は必ず dotenvx を前置する」のような must-do）は対象外
• 概念の扱いを全体で揃える: 章・節をまたいで、同じ概念の分類・定義・用語の地位を一致させる
• 例が主張を支えるか確認: 挙げた例が主張の全体を支えていなければ、主張の範囲を例に合わせて狭める。前方参照（「次節で扱う」）は本当に回収する

段落と論証の構成（パラグラフライティング）

• 一つの段落には一つのトピックだけを置く。段落の最初の文を読めば何の話かわかるようにする
• 段落の先頭で、前の段落との論理関係を接続表現で明示する（「であれば」「実際」「しかし」）
• 論証は一方向に進める。結論を出してから反論を処理し、結論を言い直す構成にしない。反論と疑念を処理してから結論を一度だけ置く
• 読者が立てそうな誤った解釈は、明示的に否定してから本当の理由を述べる（「その理由は『〜だから』ではない。〜だからだ」）
• 「A ではなく B」と否定するときは、否定の根拠を一文添える（反実仮想が使えることが多い）。根拠なしの対句は本家ルール（二項対立の禁止）どおり Y を直接述べる
• 譲歩（「確かに〜」）では事実の確認にとどめる。あとで訂正する内容を著者の声で断定しない

読み手の負荷の管理

• 後で参照しない固有名（ファイル名、関数名、識別子）を出さない。「仕様書」「金額計算のユーティリティ」で済ませる
• エージェント報告の装飾的精度（時刻、HTTP ステータス、カバレッジ率）など、議論に関係しない過剰な詳細を omit する。議論に必要な具体は残す
• 抽象的な言い回しの指す内容が一意に決まらないときは、その場で丸括弧の同格挿入で特定し、読者に前を読み返させない

※ 本家ルールの「具体的な数字・固有名で曖昧さを消す」とは別軸。主張の山場で効く具体は出すが、後で参照しない装飾的な固有名・精度は落とす。

見出しの付け方

• 見出しはその節が答える問い、または扱う対象を指す句にする。作業手順だけの見出し（「例に戻す」「〜を読み直す」）にしない
• 見出しを、節の結論を言い切る「セリフ」にしない（見出しの時点で読者がオチを知る状態を避ける）
• 疑問形か対象を指す名詞句かは、本文のトーンに合うほうを選ぶ

読者への誠実さ

• 例が作為的に見えうるなら隠さない。読者の疑念を先回りして認め、現実に十分あり得る根拠を短く添える
• その根拠は著者の断定ではなく、読者自身の経験に訴える一般的事実・通説に求める（「この症状は珍しくないだろう」）
• 確認していないことを、確認したかのように滑らかに書かない

詳細リファレンス

• references/phrases.md — 削除すべきフレーズの全リスト
• references/structures.md — 避けるべき構造パターン
• references/argumentation.md — 論証と構成の規範（パラグラフライティング・論証の厳密さ・見出し・誠実さ）
• references/examples.md — Before/After 変換例
• references/translationese-judge.md — 翻訳調 LLM judge ルーブリック

派生元

• hardikpandya/stop-slop（MIT、Hardik Pandya）— 表現の規範
• k16shikano / japanese-tech-writing — 論証と構成の規範

ライセンス

MIT