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

   固有名詞は辞書の品詞で拾う。辞書なしでは、数字・日付・英字の語・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 は「地味に効く」の活用形を見直すルールです。効果が前後に説明されている場合や、書き手の実感として必要な場合は残します。

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 を外し、ジャンル・設定ファイルの指定も合わせる。パスを省くと作業ツリー全体、明示するとその範囲の変更だけを見る
• 弱い手掛かりの指摘が件数だけで届いたとき: フックは、重大度が情報で手掛かりが弱い指摘を 1 件ずつ返さず、件数だけを添える。人の文章にも同じくらいかそれ以上に出る指摘なので、先に 1 件ずつ届いた指摘を見る。中身を確かめるなら、添えられた案内に従って全件を受け取る
• gws や PostToolUse の指摘が省略されたとき: 同じ指摘の全件を再現するコマンドは案内しない。検査した文章と表示されたルールを見直す。gws の値を改めて検査するなら、その文章自体を個別に検査する。書き込みのコマンドを再実行する必要はない
• 同じ指摘がまた出たとき: 一度見直して残すと決めた指摘は、直さなくてよい

改稿指示の読み方 (TOON)

files[1]:
  - path: docs/meeting.md
    counts:
      slop: 2
      custom: 0
      readability: 0
    rules[2]{ruleId,ruleName,title,lane,maxSeverity,signal,count,omittedCount,why,hint}:
      P01,AI_CONCLUSION,結論の押し付け・まとめ口調,slop,warning,strong,1,0,要約の定型として…,定型句を外して言い切るか、結論を支える事実や数値を書いてください
      P08,EMPTY_ADJECTIVE,空虚な形容,slop,info,moderate,1,0,「多角的に分析した」と書いても…,何がどう重要・網羅的なのか、観点や根拠そのものを書いてください
    occurrences[2]{ruleId,line,column,signal,message,excerpt}:
      P01,3,30,strong,「と言えるだろう」は結論を定型句で押し付ける締めです,定例会議を減らしたことは…と言えるだろう。
      P08,3,21,moderate,「不可欠」は中身を説明せずに重みだけを足す形容です,定例会議を減らしたことは…と言えるだろう。

• 先頭に revisionRules (改稿のルール) と editorialQuestions (ルールでは拾えない観点の問い) がある。
• rules はファイルごとの指摘のあったルールで、優先して見る順 (AI 臭さ → 独自ルール → 読みやすさ、重大度の高い順、同じ重大度なら手掛かりの強い順、件数の多い順) に並ぶ。why はなぜ疑わしいか、hint は直し方の方向。lane が readability のものは読みやすさの指摘で、優先度は低い。
• signal は AI 臭さの指摘の手掛かりの強さ (strong・moderate・weak)。その指摘が、生成文に特徴的な傾向の手掛かりとしてどれだけ強いかを示す。強いものは人の文書にほとんど出ず、弱いものは人の文書にも同じくらいかそれ以上に出る。文章が生成された確率や直す必要の大きさは表さないので、直す優先度は重大度で決め、同じ重大度なら強い手掛かりの指摘から見る。読みやすさと独自ルールの指摘は null。rules の signal は、そのルールで最も重い指摘のうち、最も強いもの。
• occurrences は該当箇所で、ruleId で rules を参照する。行・列は 1 始まり (列は文字数)。excerpt は指摘を含む文の抜粋 (文書全体の集計に基づく指摘は null)。1 ルールあたり --brief-limit 件 (既定 5。unlimited で全件) まで載り、残りの件数は rules の omittedCount。
• 指摘がなければ files は空で、note に断り書きが入る。指摘がないことは、内容の正しさの保証ではない。

そのほかのコマンド

注意

• 指摘の件数を減らすこと自体を目的にしない。件数は見直す箇所の量で、文章の出来を表す点数ではない。直すか残すかは 1 件ずつ文脈で決める。
• 書き手が今後も残すと決めた箇所だけに抑制コメントを書く (<!-- noslop-disable-next-line P01 -- 理由 -->。コードでは、コメントの中身全体を // noslop-disable-next-line P01 -- 理由 の形にする)。指摘を消すために足さない。
• 弱い手掛かりの指摘 (signal: weak。人の文章にも同じくらいかそれ以上に出る語句など) は、文脈上必要なら直さずに残してよい。同じ重大度の中では、強い手掛かりの指摘から見る。
• 設定は、ユーザーの設定 (~/.config/noslop/config.toml) に、カレントから親へたどって見つけたプロジェクトの noslop.toml を重ねて読む (--no-config でどちらも読まない)。ユーザーの設定のひな形は noslop init --user で作れる。
• 文書全体の文体を比べる R20 (読みやすさのルール) は、地の文のです・ます調と言い切りの文末が混ざっていることを示す。既存ファイルの部分差分では判定自体を実行しない。新規ファイルなど全文が差分の場合は実行する。改稿比較の diff は改稿前が空の場合に限り、改稿後に R20 を当てる。引用・会話・箇条書き・コードのコメントやセルなどの独立した断片は比較しない。
• R21 は見出しと短い一文段落で読点を挟む型の反復を数える情報のルール。[rules.R21] min_count で反復回数を変えられる（既定3回、最小2回）。単発・因果・手順・独立した断片などを除く。作者を見分ける根拠は足りないため、型を直す必要があるかは文脈で判断する。
• 品詞で数えるルール (P15・P16・R18・R20) の辞書は、既定で share ディレクトリに取得した辞書を使い、なければ同梱の IPAdic を使う。辞書は noslop dict download で取得できる (既定で圧縮版を取る)。既存の辞書も毎回取得し直し、検証後に置き換える。失敗した場合は既存の辞書を保つ。CI など別の環境と結果をそろえるときは --dict bundled で固定する。