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

   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 を当てる。引用・会話・箇条書き・コードのコメントやセルなどの独立した断片は比較しない。
• 品詞で数えるルール (P15・P16・R18・R20) の辞書は、既定で share ディレクトリに取得した辞書を使い、なければ同梱の IPAdic を使う。辞書は noslop dict download で取得できる (既定で圧縮版を取る)。既存の辞書も毎回取得し直し、検証後に置き換える。失敗した場合は既存の辞書を保つ。CI など別の環境と結果をそろえるときは --dict bundled で固定する。