noslop

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

使う場面

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

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

手順

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

   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 回だけ直す前と比べる。新しく出た指摘・消えた数字や固有名詞・文書全体に一律に当てた直し (読点の一括削除など) が出る。

   固有名詞は辞書の品詞で拾う。辞書なしでは、数字・日付・英字の語・4文字以上のカタカナ語・「」『』で囲んだ語・URLを比べる。結果が空でも情報がすべて残っているとは限らないので、原文と改稿も読み比べる。

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

   確認事項は失敗の判定ではない。消えた事実は、削ってよい情報か書き手に確かめる。比較・時制・文の役割や含みを保ったかは、原文と改稿を読んで確かめる。再実行はここで打ち切る。

文脈を見て直す箇所

文書全体の分かりやすさを求められた場合は、noslop review <FILE> --format jsonで18観点の依頼を受け取る。利用者が指定した目的・読者は--purpose・--audienceに渡す。必要情報・既知の用語・書き手の事実をまとめる場合は--profileのJSONを使う。用途を想像して必須項目や事実を増やさない。コメントやセルなど独立した断片には使わない。

自分で依頼の全観点を読み、instructionsに従った結果JSONを作る。判断できない観点もunknownで返す。requiresの目的・読者・必須情報が未指定なら断定しない。必須情報の全IDにcoverageで回答し、presentには引用を付ける。missingは偽の引用を作らずsearched: "full_document"と確認した理由を付ける。型は依頼のresponseSchemaにある。根拠はdocument.blocksのidをblockIdにして、sourceTextから原文を引用する。同じブロックに同じ引用が複数現れるときだけoccurrenceで1始まりの出現順を指定する。バイト位置は計算しない。結果を保存し、同じ原文・目的・読者・プロファイルでnoslop review <FILE> --response <RESULT>を呼んで照合する。MCPならreviewで依頼を受け取り、同じ引数にresponseを追加して照合する。通常のlintと意味の確認候補を分けて報告し、確認候補だけを根拠に事実を補ったり一律に書き換えたりしない。

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

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

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

S11（列挙の予告と項目数の不一致）とS12（Markdown上で本文のない節）は標準の読みやすさのルールで、既定で情報の指摘を出します。S11は直後のリストの直接項目だけを数え、S12は全文が対象のときだけ実行します。意図した空欄や書きかけは残せます。変換した文書では、表示上の本文や見出し階層を確認してください。

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

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)

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 を当てる。引用・会話・箇条書き・コードのコメントやセルなどの独立した断片は比較しない。
• R21 は見出しと短い一文段落で読点を挟む型の反復を数える実験的な情報のルール。--enable-rules R21 で有効にし、[rules.R21] min_count で反復回数を変えられる（既定3回、最小2回）。単発・因果・手順・独立した断片などを除く。作者を見分ける根拠は足りないため、型を直す必要があるかは文脈で判断する。
• 品詞で数えるルール (P15・P16・R18・R20) の辞書は、既定で share ディレクトリに取得した辞書を使い、なければ同梱の IPAdic を使う。辞書は noslop dict download で取得できる (既定で圧縮版を取る)。既存の辞書も毎回取得し直し、検証後に置き換える。失敗した場合は既存の辞書を保つ。CI など別の環境と結果をそろえるときは --dict bundled で固定する。