noslop

---
name: noslop
description: >-
  日本語の文章 (Markdown・テキスト) から「AI 臭さ」(LLM の文章に特有の定型句・単調な文のリズム・
  見出しと箇条書きだけの体裁) を検出する CLI。日本語の文章を書いた・直した後の見直し、
  AI が書いたような文を自然にしたいとき、推敲・校正・AI っぽさのチェック、改稿の前後の比較
  (数字や固有名詞が消えていないか・同じ直しを一律に当てていないか) の場面で発動。コードに書いた
  日本語のコメント・静的な文字列・JSX/HTML の表示文言 (コードのファイルも直接検査できる) や、gws で
  Google ドキュメント・スプレッドシートに書き込む文章の見直し、noslop のフックが指摘を返した・
  gws の書き込みを止めたときの対応にも使う。
  noslop check --report brief --format toon で直す箇所を少ないトークンで受け取り、
  改稿のルールに従って効果の大きい箇所だけを直す。直した後は noslop diff で 1 回だけ確かめる。
allowed-tools: Bash(noslop:*)
---

# noslop

日本語の文章から、LLM が書いた文章に出やすい癖 (`と言えるでしょう` のような定型句、`〜ではなく〜` の対比の繰り返し、文の長さがそろいすぎたリズム、見出しと太字だけで組んだ構成) を、決まった規則で指さす Linter。**指摘は疑いの提示**で、直すかどうかは文脈で決める。件数を減らすこと自体を目的にしない。

## 使う場面

- 日本語の文章 (README・ブログ・議事録・報告書・技術文書) を書いた、または直した直後の見直し
- 「AI っぽさを抜いて」「自然な日本語に推敲して」と頼まれたとき
- 改稿した結果、数字や固有名詞が消えていないか・同じ直しを全体に一律に当てていないかを確かめるとき
- コードに日本語のコメント・静的な文字列・JSX/HTML の表示文言を書いた・直したとき (`noslop check src/lib.rs` のようにコードのファイルを渡す。コメント/docstring だけに戻すなら `[code] static_text = false`)

英語の文章には使わない (英語の段落は数えない)。

## 手順

1. 直す箇所を受け取る。少ないトークンで受け取るなら TOON、プログラムで扱うなら JSON、人に見せるなら Markdown。

   ```bash
   noslop check --report brief --format toon <FILE>   # 改稿指示 (TOON)
   noslop check --report brief --format json <FILE>   # 改稿指示 (JSON)
   noslop check --format brief <FILE>                 # 改稿指示 (Markdown)
   ```

   技術文書・ビジネス文書・エッセイは `--genre tech|business|essay` を付ける (閾値と、ジャンルの慣習と衝突するルールが変わる)。

2. **改稿のルール (`revisionRules`) に従って直す。** 主張・確信度・数字・固有名詞・引用・想定読者・条件・例外を変えない。原文にない事実・数字・体験を足さない。主体・原因・実装・効果も推測で補わず、材料が足りなければ書き手に確かめる。同じ直しを全箇所に一律に当てず、効果の大きい箇所だけを直す。文脈上必要な箇所は直さずに残してよい (残した理由は報告に書く)。

3. 直した後、**1 回だけ**直す前と比べる。新しく出た指摘・消えた数字や固有名詞・文書全体に一律に当てた直し (読点の一括削除など) が出る。

   ```bash
   noslop diff <直す前> <直した後>
   git show HEAD:<FILE> | noslop diff - <FILE> --stdin-filename <FILE>   # 直前のコミットと比べる
   ```

   確認事項は失敗の判定ではない。消えた事実は、削ってよい情報か書き手に確かめる。再実行はここで打ち切る。

## 文脈を見て直す箇所

機械的な指摘だけでは、意味や用途に合った直し方は決まりません。次の観点も使います。

- 操作や判断の主体、対象、動作が分かるか確かめる。「これ」「両者」「片方」の指すものが曖昧なら、文脈から分かる名詞へ戻す。日本語で自然に省略されている主語まで一律に足さない。
- 読み手への依頼と機能の説明を区別する。誰が操作するかが曖昧な場合だけ書き分け、原文の義務・可能性・確信度を変えない。
- 比喩で書いた失敗・破棄・採否・効果は、何が起きるかを具体化できるか確かめる。原文にない通知の有無、ログ、原因、実装、効果は推測で足さない。「体温」「解像度」などの専門用語や、具体的な実感として必要な比喩は残す。
- 技術文書では操作の手順と結果、業務文書では担当と条件・採否の基準・例外、随筆では書き手の経験や感情を保つ。随筆の小さな出来事を、大きな教訓に書き換えない。
- 補足の括弧は、本文と意味が重なっている場合だけ整理する。略語の定義・単位・条件・例外は残す。和文と英語の間の空白や、文長・読点・装飾の数を一律の目標値へそろえない。

P24 は「地味に効く」の活用形を見直す実験的なルールで、`--experimental` か `--enable-rules P24` で有効にできます。効果が前後に説明されている場合や、書き手の実感として必要な場合は残します。

## フックから指摘が来たとき

noslop のフックは、ファイルを書いた直後・応答を終えたとき (コミットしていない変更)・gws で Google ドキュメントやスプレッドシートに書き込む前に、短い改稿指示を返す。どれも上の手順 2 と同じく、効果の大きい箇所だけを直し、文脈上必要な箇所は理由を報告に書いて残す。

- **gws の書き込みが止められたとき** (「コマンドを止めました。まだ書き込んでいません」): 書き込む文章を直してから、gws のコマンドを打ち直す。直さずに書き込むと決めたら、同じコマンドをそのままもう一度実行する (止めた書き込みと同じものは、止めてから 30 分のあいだ通る)。1 つのコマンドの gws の書き込みを 1 つずつ止めることがあるので、別の書き込みでまた止まったら、同じように判断する。止めた理由と残した判断は、書き手への報告に添える
- **書き込んだ後に届いた指摘** (セル・タイトルのような短い値や、`--dry-run` の値): 書き込みは済んでいる。直すなら、書き込んだ先を改めて更新する。短い値の判定は未校正なので、参考として扱う
- **Stop の指摘が省略されたとき**: 注記のコマンドを、そのまま実行して全件を受け取る。既定の Stop と同じ指摘を JSON で受け取るなら `noslop check --git-diff --no-readability --format json`、改稿指示を TOON で受け取るなら `noslop check --git-diff --no-readability --report brief --format toon --brief-limit unlimited`。フックで読みやすさを含めた場合は `--no-readability` を外し、ジャンル・実験的ルール・設定ファイルの指定も合わせる。パスを省くと作業ツリー全体、明示するとその範囲の変更だけを見る
- **gws や PostToolUse の指摘が省略されたとき**: 同じ指摘の全件を再現するコマンドは案内しない。検査した文章と表示されたルールを見直す。gws の値を改めて検査するなら、その文章自体を個別に検査する。書き込みのコマンドを再実行する必要はない
- **同じ指摘がまた出たとき**: 一度見直して残すと決めた指摘は、直さなくてよい

## 改稿指示の読み方 (TOON)

```toon
files[1]:
  - path: docs/meeting.md
    counts:
      stableSlop: 2
      experimentalSlop: 0
      custom: 0
      readability: 0
    rules[2]{ruleId,ruleName,title,lane,maxSeverity,experimentalOnly,count,omittedCount,why,hint}:
      P01,AI_CONCLUSION,結論の押し付け・まとめ口調,slop,warning,false,1,0,要約の定型として…,定型句を外して言い切るか、結論を支える事実や数値を書いてください
      P03,AI_CONJUNCTION,空疎な接続,slop,info,false,1,0,前の段落で何が述べられたかに…,接続語に頼らず、前の内容の具体的な事実や疑問から次の話へつないでください
    occurrences[2]{ruleId,line,column,message,excerpt}:
      P01,3,35,「と言えるだろう」は結論を定型句で押し付ける締めです,このように、定例会議を減らしたことは…と言えるだろう。
      P03,3,1,「このように」は前の内容を機械的に束ねる接続です…,このように、定例会議を減らしたことは…と言えるだろう。
```

- 先頭に `revisionRules` (改稿のルール) と `editorialQuestions` (ルールでは拾えない観点の問い) がある。
- `rules` はファイルごとの指摘のあったルールで、**優先して見る順** (AI 臭さ → 独自ルール → 読みやすさ、校正済み → 実験的、重大度の高い順) に並ぶ。`why` はなぜ疑わしいか、`hint` は直し方の方向。`lane` が `readability` のものは読みやすさの指摘で、優先度は低い。
- `occurrences` は該当箇所で、`ruleId` で `rules` を参照する。行・列は 1 始まり (列は文字数)。`excerpt` は指摘を含む文の抜粋 (文書全体の集計に基づく指摘は `null`)。1 ルールあたり `--brief-limit` 件 (既定 5。`unlimited` で全件) まで載り、残りの件数は `rules` の `omittedCount`。
- 指摘がなければ `files` は空で、`note` に断り書きが入る。指摘がないことは、内容の正しさの保証ではない。

## そのほかのコマンド

| やりたいこと | コマンド |
|---|---|
| ルールの詳細 (何を見るか・なぜ問題か・直し方・例・根拠) | `noslop explain <ID>` (例: `noslop explain P01`) |
| ルールの一覧 | `noslop rules` |
| 全指摘のレポート (抑制した指摘・位置・metrics・fingerprint を含む) | `noslop check --format json <FILE>` (TOON なら `--format toon`) |
| 標準入力の文章を検査する | `pbpaste \| noslop check - --stdin-filename draft.md --report brief --format toon` |
| コミットしていない変更に重なる指摘を全件受け取る | `noslop check --git-diff --report brief --format toon --brief-limit unlimited` |
| ディレクトリをまとめて検査する | `noslop check docs --report brief --format toon` |

## 注意

- 指摘の件数を減らすこと自体を目的にしない。件数は見直す箇所の量で、文章の出来を表す点数ではない。直すか残すかは 1 件ずつ文脈で決める。
- 書き手が今後も残すと決めた箇所だけに抑制コメントを書く (`<!-- noslop-disable-next-line P01 -- 理由 -->`。コードでは、コメントの中身全体を `// noslop-disable-next-line P01 -- 理由` の形にする)。指摘を消すために足さない。
- 実験的なルール (`experimentalOnly: true`、`--experimental` で有効) は未校正。校正済みの指摘を優先する。
- 設定は、ユーザーの設定 (`~/.config/noslop/config.toml`) に、カレントから親へたどって見つけたプロジェクトの `noslop.toml` を重ねて読む (`--no-config` でどちらも読まない)。ユーザーの設定のひな形は `noslop init --user` で作れる。
- 文書全体の文体を比べる R20 は実験的なルール。`--enable-rules R20` または設定で有効にすると、地の文のです・ます調と言い切りの文末を示す。既存ファイルの部分差分では判定自体を実行しない。新規ファイルなど全文が差分の場合は実行する。改稿比較の `diff` は改稿前が空の場合に限り、改稿後に R20 を当てる。引用・会話・箇条書き・コードのコメントやセルなどの独立した断片は比較しない。
- 品詞で数えるルール (P15・P16・R18・R20) の辞書は、既定で share ディレクトリに取得した辞書を使い、なければ同梱の IPAdic を使う。辞書は `noslop dict download` で取得できる (既定で圧縮版を取る)。既存の辞書も毎回取得し直し、検証後に置き換える。失敗した場合は既存の辞書を保つ。CI など別の環境と結果をそろえるときは `--dict bundled` で固定する。