slop-detector

AI の定型文検出

定型文かどうかは、単語の問題ではなく密度の問題です。

「delve」が1つだけなら問題ありません。「tapestry」や「embark」の近くに「delve」が5つあると、それは生成テキストです。このスキルでは、100語あたりの密度、マーカーの集中度、文書の種類に全体的な文体が合っているかを評価します。単語を禁止するのではなく、集中している箇所にフラグを立てます。

使用しない場面

• 置き換え後の文章を書く場合（scribe:doc-generator を使用）
• 特定の文体プロファイルとのずれを確認する場合（scribe:voice-review を使用）

実行ワークフロー

まず検出箇所を特定してから、内容を確認します。

uv run --with pyyaml python scripts/slop_score.py --audit <files>

ファイルまたはディレクトリに対してコマンドを1回実行し、検出箇所ごとにファイル名と行番号を1行で出力して、終了コード0で終了します。data/languages/en.yaml 内のすべてのカテゴリを読み込みます。これには、マージゲートでスコア対象外となるカテゴリも含まれます。negative_definition、 temporal_residue、contrastive_scaffold、over_explanation、 より軽度の擬人化動詞、文書ごとの否定密度の判定が対象です。これらは(low)または(medium)として出力されます。ステップ9の反目標はこれらにも適用されます。表面化するだけにとどめ、自動適用はしません。

.pyファイルのパスは、コードを空白に置き換え、行番号を維持したうえで、コメントとdocstringとして読み取ります。--pythonを指定すると、ディレクトリ全体が対象になります。以下の分類ではコードコメントも対象として明示していますが、収集ツールがコードコメントに対応するまでは、ここにある各カテゴリはMarkdownのみを対象に確認されていました。

以下のステップでは、各カテゴリの意味と書き換え方を説明します。パターンごとに文書を読み直すのではなく、まずスクリプトを実行して、各ステップで参照できる検出箇所を特定してください。

次に対象ファイルを特定し、技術文書、物語文、コードコメントに分類します。この分類は、文脈に応じたスコアリングに反映されます。同じTier 1マーカーでも、マーケティング文書ではAPIリファレンスより低く評価されます。

言語検出

• 機能語の頻度を使って、テキスト内容から言語を自動検出します
• 明示的な--langパラメーターで上書きできます（en、de、fr、es）
• data/languages/{lang}.yamlから言語固有のパターンを読み込みます
• 検出の信頼度が低い場合は、英語にフォールバックします
• 文化的な調整と具体的なパターンセットについては、modules/language-handling.mdを参照してください

スペルの正規化（イギリス英語からアメリカ英語へ）

文書内のスペルは、.slop-config.yaml（spelling: british）または単語ごとの許可リストで例外を指定しない限り、スキャン対象のすべての文書で、デフォルトでイギリス英語からアメリカ英語に変換します。これは定型文のスコアリングとは別の、一貫性を保つための処理です。テスト済みのs​cribe.spelling関数（find_british_spellings、to_american）を使用してください。どちらも大文字・小文字を維持し、コード、インラインコード、URLはスキップします。

読み込み先：@modules/spelling-normalization.md

語彙とフレーズの検出

読み込み先：@modules/vocabulary-patterns.md

マーカーは信頼度に応じて3つのTierに分類されます。Tier 1の単語（「delve」「multifaceted」「leverage」）は、人間が書いたテキストよりもAIのテキストにずっと多く現れます。Tier 2は、文脈に依存する接続表現（「moreover」「subsequently」）が対象です。Tier 3は、内容の薄いフレーズ（「In today's fast-paced world」「cannot be overstated」）が対象です。

単語	文脈	人間らしい言い換え
delve	「delve into」	掘り下げる、調べる、見る
tapestry	「rich tapestry」	組み合わせ、混在、多様性
realm	「in the realm of」	～で、～の中で、～に関して
embark	「embark on a journey」	始める、取りかかる
beacon	「a beacon of」	例、手本
spearheaded	形式ばった功績の帰属	率いた、始めた
multifaceted	複雑さの説明	複雑な、多様な
comprehensive	範囲の説明	徹底的な、完全な
pivotal	重要性を示す表現	重要な、鍵となる
nuanced	洗練度を示す表現	微妙な差異のある、詳細な
meticulous/meticulously	注意深さを示す表現	注意深い、詳細な
intricate	複雑さを示す表現	詳細な、複雑な
showcasing	見せることを表す動詞	示す、披露する
leveraging	ビジネス用語	利用する
streamline	最適化を表す動詞	簡素化する、改善する

Tier 2：中程度の確度のマーカー（各スコア：2）

一般的ですが、文脈に左右されます：

カテゴリー	単語
接続表現の過剰使用	moreover, furthermore, indeed, notably, subsequently
強調表現の集中	significantly, substantially, fundamentally, profoundly
過度な婉曲表現	potentially, typically, often, might, perhaps
行動表現の誇張	revolutionize, transform, unlock, unleash, elevate
空疎な強調	crucial, vital, essential, paramount

Tier 3：フレーズのパターン（各スコア：2～4）

フレーズ	スコア	問題点
"In today's fast-paced world"	4	内容の薄い書き出し
"It's worth noting that"	3	埋め草
"At its core"	2	位置づけに頼った表現
"Cannot be overstated"	3	空疎な強調
"A testament to"	3	ありきたりな称賛表現
"Navigate the complexities"	4	ビジネス用語
"Unlock the potential"	4	マーケティング用語
"Treasure trove of"	3	使い古された比喩
"Game changer"	3	流行語
"Look no further"	4	売り込み文句
"Nestled in the heart of"	4	旅行記事で使い古された表現
"Embark on a journey"	4	大げさな表現
"Ever-evolving landscape"	4	テクノロジー分野で使い古された表現
"Hustle and bustle"	3	埋め草

ステップ 3：構造パターンの検出

読み込み先：@modules/structural-patterns.md

em ダッシュの過剰使用

Wikipedia、Field Guide、Algorithmic Bridgeで、2026年にAIの特徴として最も頻繁に挙げられているものです。検出は2つのモードで実行します。

監査モード（未知の文章を対象とするフォレンジック分析）：

• 1000語あたり0～1個：通常の人間の範囲
• 2～4個：多めです。使用状況を確認してください
• 5個以上：AIの強い兆候

予防モード（エージェントが生成したばかりのドキュメントを対象とする）：

• 目標はゼロ。em ダッシュはすべて指摘対象です。
• 挿入句にはコンマ、余談には括弧、定義にはコロン、独立した考えにはピリオドを使って置き換えてください。置き換え一覧の全容については、modules/structural-patterns.md § Em Dash Analysisを参照してください。

# Count em dashes in file
grep -o '—' file.md | wc -l

三項並列の検出

AIは頭韻を踏んだ3語の組み合わせを好みます。

• 「fast, efficient, and reliable」
• 「clear, concise, and compelling」
• 「robust, reliable, and resilient」

パターン：音が似た「形容詞、形容詞、and 形容詞」。

リストと文章の比率

箇条書きと段落内の文を数えます。

• 箇条書きが60％超：AIに見られる傾向
• 絵文字で始まる箇条書き：技術文書ではAIの強い兆候

文の長さの均一性

文の長さの標準偏差を測定します。

• 分散が小さい（SD < 5語）：AI特有の単調さ
• 分散が大きい（SD > 10語）：人間らしい変化

段落の対称性

AIは段落の長さが均一な、ブロック状の文章を生成します。 段落の語数が同じくらいに集中しているか確認してください。

ステップ 4：アイデンティティと語り口の漏出の確認（P0）

読み込み：@modules/identity-and-voice-leaks.md

一部のパターンは粗雑な文章ではありません。AI が生成した文章が公開物に漏れ出たことを示す直接的な証拠です。 この分類に該当するものが 1 つでも見つかれば、ほかのスコアに関係なくレビュー不合格となります。

以下を確認します。

1. アイデンティティの漏出（「大規模言語モデルとして」「トレーニングの知識期限時点では」「提供できません」など） — 重大度：クリティカル、例外なし。
2. 会話調の語り口の漏出（「お役に立てば幸いです！」「いい質問ですね！」「もちろんです！」など）。トランスクリプトブロックの外にあるものが対象です。
3. 構成についての自己叙述（「このセクションでは、～を取り上げます」「詳しく見ていきましょう」「このガイドを読み終えるころには」など）。
4. 相反するような両論併記（「X にも利点はありますが、課題もあります」など）。
5. 対比表現。節の冒頭または末尾に現れるものが対象です。対比的な否定（「単なる X ではなく Y」「X ではなく Y です」、末尾に置かれる「Y ではなく X です」／「X ではなく Y です」）と、肯定的な対句表現（「X は控えめに、Y は多めに」「ほかが X するところを、私たちは Y します」）の両方が含まれます。最も必要な場合を除き、使用を避けてください。削除しても情報が変わらない場合は残さないでください。末尾に置かれるコピュラ形式（「おもちゃではなく、ツールです」）は、冒頭部分が単なる定義に見えるため、最も見落としやすい表現です。

パターンの全一覧と誤検出に関するガイダンスについては、モジュールを参照してください。

ステップ 4.5：迎合的なパターンの検出

特に会話形式や説明形式のコンテンツで重要です （identity-and-voice-leaks モジュールのクラス 2 を補完します）。

フレーズ	問題点
「喜んでお手伝いします」	へりくだった導入
「いい質問ですね！」	中身のない肯定
「もちろんです！」	過剰な同意
「すばらしいご指摘です」	お世辞
「質問してくださってうれしいです」	埋め草
「まったくそのとおりです」	迎合

これらのフレーズは情報を加えず、生成されたコンテンツであることを示します。

ステップ 4.6：ティア 5／2026 年のパターン（厳格な防止）

2026 年の複数ソースにわたる合意（Wikipedia Signs of AI writing、Algorithmic Bridge 10 Signs、Ignorance.ai Field Guide、Stop-Slop Claude skill、George Kao、ContentBeta、 OliviaCal）では、GPT-5 以降／Claude-4.5 以降の文章に多く見られるいくつかのパターンが特定されています。それぞれの詳細は、@modules/vocabulary-patterns.md（語彙形式）と @modules/structural-patterns.md（構造形式）に記載されています。

パターン	形式	重要な理由
ダッシュの多用	修辞的な間として — を使う	2026 年に最も頻繁に指摘される単一の特徴
「and」の代わりにプラス記号	文章中で「hooks and skills」とする	強い特徴：人間は「and」を使います
空間的な繋辞	「lives in」、「sits at」、「stands as」、「boasts」	無生物の主語に生物が使う動詞を組み合わせる
否定的な並列法（対比的否定）	「Not X but Y」、「No X. No Y. Just Z.」、「No X, no Y, no Z」、「It's not X, it's Y」、「It's X, not Y」、「Y, not X」	論拠のない修辞的なひな型
対比的な並列法（肯定的な対句）	「Less X, more Y」、「Where others X, we Y」、「Humans propose; machines dispose」	人工的な決め台詞。「not」を使わずに同じひな型を使う
前置きの言葉	「Here's the thing,」、「Look,」、「Let that sink in.」	何も伝えない談話標識
3 つの断片的な表現の連続	「Focused. Aligned. Measurable.」	情報を伴わないリズム
重要性を示す表現の集中	「stands as a testament to」、「marks a turning point」	重要性を示さずに重要だと主張する
技術文書におけるスマート引用符	"text" の代わりに "text" ／ "text" を使う	ワープロからの貼り付けの痕跡
セミコロンによる文の接続	「The system is fast; it scales」	独立した 2 つの節を文章中でセミコロンでつなぐ表現。よほど必要でない限り、2 文に分けてください。各項目にコンマを含むリストには該当しません
否定形による代替表現	「never guesses instead of measuring」、「does not retry rather than report」	拒むことによって対象を定義する表現。実際に何をするかを述べてください
ループ／カスケード語彙	「unpack」、「surface」（動詞）、「a quiet shift」	2026 年のシステム理論を気取った表現
誠実さの演出	「to be honest」、「Honestly,」、「An Honest Review」	人工的に作られた信頼感
洗練度を示す表現	「survey the prior art」、「state of the art」、「body of work」	学術的でない文章で厳密さを装う表現
分詞による尾ひれ	「, highlighting」、「, underscoring」、「, paving the way for」	偽の分析を後付けする表現
強調の常套句	「Full stop.」、「Make no mistake」、「Read that again.」	重要性を演出する締めくくり

防止ルール：エージェント自身が生成したばかりのドキュメントに対してスロップ検出器を実行する場合（/doc-generate、 /doc-polish、/update-readme、/update-docs などから自動的に呼び出されます）、この表の該当箇所はすべて重大なエラーとして扱います。書き込む前に修正してください。置き換え表については、modules/remediation-strategies.md § Tier 5 / 2026 を参照してください。

ステップ 5：スロップ密度スコアを算出する

slop_score = (tier1_count * 3 + tier2_count * 2 + phrase_count * avg_phrase_score) / word_count * 100

スコア	評価	対応
0-1.0	問題なし	対応不要
1.0-2.5	軽微	該当箇所を修正
2.5-5.0	中程度	セクションの書き直しを推奨
5.0+	深刻	ドキュメント全体をレビュー

ステップ 6：ドキュメントの簡潔さをチェックする

読み込む：@modules/document-economy.md および @modules/audience-targeting.md

文単位での簡潔さは必要ですが、それだけでは十分ではありません。 冗長度が 0 のドキュメントでも、長すぎたり、主張がなかったり、肝心のメッセージ以外をすべて繰り返したりして、読者の時間を無駄にすることがあります。

次の 4 項目でドキュメントを評価します（各 0～2 点）。

1. 主張を先に示す：冒頭で唯一の要点を述べていますか？
2. 文の重み：すべての文が主張を支え、例示し、範囲を定め、または繰り返していますか？
3. 繰り返しのルール：主張は繰り返され（望ましい）、周辺的な繰り返しは削られていますか（望ましい）？
4. 対象読者との適合性：対象の階層が明示され、各セクションがその読者に役立っていますか？より上位の読者にしか役立たない内容は削除せず、詳細解説に分けます。

チェック 4 には対象読者の明示が必要です。ドキュメントに記載がない場合は、推測せずに尋ねてください。階層表とソクラテス式の質問集は modules/audience-targeting.md にあります。このモジュールが対象外と明記している創作物では、チェック 4 を省略してください。

文単位の冗長度スコアとドキュメントの簡潔さのスコアを組み合わせます。どちらも基準を満たす必要があります。完全な評価基準、読者の所要時間の予算表、実例については modules/document-economy.md を参照してください。

ステップ 7：ハルシネーションとスタブを一掃する

読み込む：@modules/hallucination-detection.md および @modules/stub-and-deferral.md。

ハルシネーションは冗長さではありません。自信に満ちた言い回しで誤りを述べることです。常に P0 です。

次の項目を確認します。

1. 実在しないコード参照：文章中のバッククォートで囲まれた識別子、関数名、ファイルパスがすべてコードベースに存在すること。
2. 実在しない依存関係：推奨されている pip install / cargo install / npm install がすべて、該当するレジストリで解決できること（スロップスクワッティング対策）。
3. リンク切れの URL：引用されているすべての URL が 200 を返すこと。
4. 作り上げられた設定キー：ドキュメント内の設定キーがすべてコードで読み取られること。
5. 説明のない TODO/FIXME：追跡対象の課題へのリンクを付けるか、削除する必要があります。
6. 曖昧な表現（「現時点では」「動作するはず」「プレースホルダー」「ダミー」）：いずれも先送りされた作業です。
7. スタブ構文（todo!()、unimplemented!()、NotImplementedError）：パブリック API から到達可能な経路にあれば、不具合です。

検出コマンドと重大度マトリクスについては各モジュールを参照してください。

ステップ 8：根拠に基づく主張（README と公開ドキュメント）

読み込む：@modules/evidence-backed-claims.md

品質に関するすべての主張には、同じリポジトリ内の根拠が必要です。根拠がなければ、その主張を削除してください。

「本番環境対応」「高速」「メモリ安全」「スケーラブル」などの主張について、それに対応する根拠（CI ワークフロー、ベンチマークディレクトリ、監査マーカーなど）が実際に存在するか確認します。このモジュールには、主張と必要な根拠を対応させた完全な表と、言語別の検出コマンドが記載されています。

このステップは、クレート／ライブラリ／プロジェクトの README に最も効果があります。機能一覧が流行語だらけになることは、AI 生成で最もよくある失敗パターンです。

ステップ 9：アンチゴールを適用する（安全性チェック）

読み込む：@modules/anti-goals.md

過度な冗長さの削減にも、固有の失敗パターンがあります。

前のステップで見つかった修正を適用する前に、それが次のアンチゴールに反しないことを確認してください。

1. unsafe、ロック、またはコントラクトを含むコード上の安全性コメント（// SAFETY:、// INVARIANT: など）を削除しないでください。
2. 明示的にメジャーバージョンを上げる決定がなされていない限り、公開エラーのバリアントを統合しないでください。
3. 型付きエラーをボックス化されたエラーや動的エラーに「単純化」しないでください。
4. 短くても、ドメイン固有の名前を持つ関数をインライン化しないでください。
5. 生成コード、ベンダーコード、過去の変更履歴には手を加えないでください。
6. confidence: low の指摘を自動適用しないでください。人が判断できるように提示してください。

判断に迷った場合は、その箇所を指摘したままにし、削除しないでください。

マルチパスによる完全なクリーンアップワークフロー

プロジェクト全体を体系的にクリーンアップするには、マルチパスの ワークフローを順番に実行します。10 パスの方法論と順序の根拠については、 @modules/cleanup-workflow.md を参照してください。概要：

パス	対象
0	クリーンアップ前のスイープ：シークレット、エージェント設定
1	表層的なリントの基準：フォーマッターとリンター
2	幻覚とスタブ（モジュール：hallucination、stub-and-deferral）
3	アイデンティティと文体の漏出
4	コメントのスロップ（翻訳、マーケティング、バナー、先送り）
5	散文のスロップ（語彙、構造、文書の簡潔さ、エビデンスに基づく主張）
6	コードのイディオム（言語固有のプラグインに委任）
7	アーキテクチャ（判断の比重が大きい項目。アンチゴールを参照）
8	テスト（同語反復、モック、スナップショット）
9	README と公開ドキュメント
10	ガードレールの確立（CI、リント、憲章）

基本ルール：1 コミットにつき 1 パス。書き換えより削除を優先します。確信度の低い修正を黙って適用してはいけません。パスで何も見つからなければ終了します。

実証的なベースライン（深刻度の根拠を示す際に引用）

深刻度の重み付けの根拠となる、2025-Q1 2026 の調査ベースラインについては、@modules/empirical-baseline.md を 読み込んでください。主な数値：

• AI による PR は、人間のみで作成された PR と比べて、問題全体が 1.7 倍、ロジック／正確性の問題が 1.75 倍、XSS が 2.74 倍、過剰な I/O が約 8 倍発生します（CodeRabbit、2025 年 12 月）。
• 検出された AI 生成コードの問題の 92～96％は、正確性ではなく保守性（「コードスメル」）に関するものです（Sonar、2025 年第 4 四半期）。
• モデル固有の傾向：GPT は捏造し、Claude は省略します。それに応じて監査を調整してください。

レビューで指摘事項の深刻度に異議が唱えられた場合、権威を根拠に断言するのではなく、このモジュールを引用してください。

ステップ 10：レポートの生成

レビュアーが個別に承認または却下できるよう、指摘事項ごとの出力には、 @modules/structured-finding-output.md で定義された標準の構造化形式を使用してください。各指摘には file、line、category、severity、 confidence、evidence、rationale、fix、および （確信度が高い場合は）diff が含まれます。自動適用ポリシーは 確信度によって決まります。confidence: low は決して自動適用しないでください。

サマリーレポートの形式（人間が読みやすい形式）：

## Slop Detection Report: [filename]

**Overall Score**: X.X / 10 (Rating)
**Word Count**: N words
**Markers Found**: N total

### CRITICAL (P0, must resolve before merge)
- Line 8: "As a large language model". IDENTITY LEAK
- Line 47: References `Client.connect_with_timeout(...)` —
  HALLUCINATION (method does not exist; closest match is
  `Client.connect`)
- Line 102: "production-ready" claim with no CI workflow
 . UNVERIFIED CLAIM

### High-Confidence Markers (vocabulary)
- Line 23: "delve into" -> consider: "explore"
- Line 45: "rich tapestry" -> consider: "variety"

### Structural Issues
- Em dash density: 8/1000 words (HIGH)
- Bullet ratio: 72% (ELEVATED)
- Sentence length SD: 3.2 words (LOW VARIANCE)

### Phrase Patterns
- Line 12: "In today's fast-paced world" (vapid opener)
- Line 89: "cannot be overstated" (empty emphasis)
- Line 134: "Let's dive into" (self-narration of structure)

### Tier 5 / 2026 Patterns
- Line 19: "The skill lives in `plugins/scribe/`" → "is in"
  (spatial copula, inanimate subject)
- Line 27: "hooks + skills" → "hooks and skills" (plus-sign
  conjunction in prose)
- Line 34: "It's not a tool, it's a transformation" →
  rewrite positively (negative parallelism / contrastive
  negation)
- Line 38: "Less config, more code" → state plainly
  (contrastive parallelism; keep only if load-bearing)
- Line 56: "Here's the thing," → delete (throat-clearing
  opener)
- Line 78: "Focused. Aligned. Measurable." → "Focused,
  aligned, and measurable." (three-fragment burst)
- Line 91: 3 smart quotes outside code blocks (Word-processor
  paste signature)

### Stub & Deferral
- Line 56: bare `// TODO: handle expired tokens` (no
  tracked issue link)
- Line 71: "for now, we recommend" (deferral language)

### Document Economy Score: X / 6
- Thesis-first: 1/2 (thesis present but buried in para 3)
- Sentence weight: 1/2 (~65% of sentences earn weight)
- Repetition: 2/2 (thesis echoed; ambient repetition cut)

### Recommendations
1. **CRITICAL**: delete line 8 identity leak before merge
2. **CRITICAL**: replace `Client.connect_with_timeout`
   with `Client.connect(opts)` and update example
3. **CRITICAL**: either add CI + version >= 1.0 to back
   "production-ready", or delete the claim
4. Replace [specific word] with [alternative]
5. Convert bullet list at line 34-56 to prose
6. Hoist the thesis (line 47) into the lead paragraph
7. Link bare TODOs to tracked issues or delete code path

### Confidence-low findings (require human decision)
- Line 89: bullet count of 8 may be appropriate for this
  enumeration; do not auto-flatten
- Line 156: `Manager` suffix may be domain-meaningful;
  verify before renaming

anti-goals.md に従い、confidence: low の指摘は別のセクションにまとめて提示してください。黙って適用してはいけません。

モジュールリファレンス

• ナラティブ特有のスロップマーカーについては modules/fiction-patterns.md を参照してください
• 修正案については modules/remediation-strategies.md を参照してください

修正との連携

検出後、Skill(scribe:doc-generator) を --remediate フラグ付きで呼び出して修正を適用するか、レポートをガイドとして手動で編集してください。

終了条件

• 対象ファイルをすべてスキャンしている
• 密度スコアを算出している
• 行を特定した具体的な修正を含むレポートを生成している
• 深刻度の高い項目に、すぐに対応が必要なものとしてフラグを付けている