natural-japanese

natural-japanese

仕事の日本語を、読みやすくわかりやすく書くためのスキル。議事録・調査レポート・社内ガイド・リサーチメモ・スライドといった仕事の文書から、note・ブログ・エッセイまで。AI臭さの除去は工程の一部として組み込まれている。

設計思想

軸は二つ。第一に「検出は機械、判断はAI」。AIは自分の癖を認識しにくいから、疑いの検出は機械が決定的に行い、直すかどうかはAI（あなた）が文脈で判断する。第二に「事後修正より生成時制約」。書いた後にAI臭を消すより、書く前の設計と書くときの制約で発生自体を防ぐほうが効く。工程は「設計 → 執筆 → 検査 → 収束」の順に進む。

実行モード — クイックとフル

同じ工程を、かける手間の異なる2つのモードで回す。所要時間の実測目安——クイックは短い文書（会議メモ程度）で30秒前後、長め（1万字級）でも3分程度。フルは短い文書で7分前後、1万字級で15〜20分。フルを始めるときは、この目安をユーザーに一言伝えてから着手する。

クイック（既定）: 日常の文書はこちら。サブエージェントを使わず、この場で完結させる。追加で読むのは該当する doctype の型1ファイルだけでよい（文体憲法は§2の要約で足りる。他の references は lint の finding が出て判断に迷ったときだけ開く）。設計（§1）は読者・主メッセージ・見出しの確認を頭の中で済ませる。検査は lint を1回と、自分でのスケルトン通読。lint は文書が短くても省略しない（短文では統計系検出器が沈黙するが、禁止語・翻訳調は文1つでも検出される。数秒の保険であり、これを飛ばした時点でクイックの品質保証は成立しない）。収束ループは新規 finding が出なければ1周で切り上げ、最終パスの通読をして終える。スキルによる追加時間は数十秒に収まるはずで、それを超えて references を読み込みはじめたらフルモードの仕事をしている。

フル: ユーザーが「しっかり」「ちゃんと」「時間をかけていい」と言ったとき、対外・経営向けなど失敗コストが高い文書、または長い文書（目安1万字超）のとき。フルと決めたら（またはユーザーがフルを指定したら）、文書が小さくても工程を省略しない。lint に加えて outline / terms も実行し、検査（§4）の三つのレビュー——構造レビュー・読みやすさレビュー・doctype照合——を並列のサブエージェントで必ず行う（各自が所見を返し、判断台帳への統合と「直す/残す」の判断は必ず親が行う。執筆そのものは分割しない——濃淡・比喩の一貫・章間の接続は文書全体を見ないと守れない）。収束は状態条件（§5）を満たすまで回す。「この文書には過剰」と感じても、工程を勝手に間引かず、クイックへの切り替えをユーザーに提案する。なお実測で、思考予算(effort)を低く絞った実行はフルの工程を合理化で削りやすいことが確認されている。effort を選べる環境でフルを実行するなら high を推奨する(クイックは low で十分)。

どちらか迷ったら、まずクイックで仕上げてから「フルで磨き直すこともできる」とユーザーに一言添えるのがよい。

呼び出し方 — write / score / モード指定

スキルがコマンドとして引数つきで呼ばれた場合、次の形を解釈する。

• /natural-japanese [quick|full] <対象> — 書く・直す（既定）。新規作成かリライトかは対象から判断する
• /natural-japanese write [quick|full] <お題や素材> — 新規作成を明示。元の文章がない状態から、§1の設計（読者・主メッセージ・スケルトン・濃淡・素材集め）→§2の執筆→検査→収束の全工程で書き起こす。素材が乏しければ§1-4で先に集めるか、ユーザーに求める
• /natural-japanese score [quick|full|exp] <ファイル> — 診断のみ。文書を書き換えず、自然度スコア（0〜100、高いほど自然=AI臭が薄い）と理由で返す。quick=lint のみ（30秒）、full=構造・読みやすさレビュー込み、exp=semantic.py の深層検出込み（初回約1GBダウンロード）。最初に必ず references/diagnose.md を読む。スコアの算出式・バンド・出力形式の定義がそこにあり、これを読まずに lint findings の転記で返した時点で診断モードの仕事になっていない。診断後にリライトを提案してよいが、頼まれるまで直さない

モード指定がなければ実行モードの基準で自分で選ぶ。自然言語でも同じ（「〇〇について書いて」→ write 相当、「この文章AIっぽい？」「AI臭さを採点して」→ score 相当）。

1. 設計 — 書く前に決める

1-1. 読者・目的・文書タイプ

誰が読み、読んだ後に何が起きてほしい文書かを特定する（不明ならユーザーに聞く）。文書タイプが定まったら、対応する型を読む:

• 議事録 → references/doctypes/minutes.md
• 調査レポート・分析レポート → references/doctypes/report.md
• 社内ガイド・マニュアル → references/doctypes/guide.md
• リサーチメモ・ディスカッションペーパー・企画書 → references/doctypes/memo.md
• スライド構成 → references/doctypes/slide.md

型に当てはまらない文書（note・ブログ・エッセイ等）はこの節を飛ばしてよい。

1-2. 主メッセージとスケルトン

本文を書く前に、主メッセージを一文で書く。書けないなら素材不足であり、書き方の問題ではない（→ 1-4）。次に見出しスケルトンを作る。各見出しは「背景」「まとめ」のようなラベルではなく、結論を含むメッセージにする。見出しだけを順に読んで論旨が通ることを確認してから本文に進む。

1-3. 濃淡設計

すべての節を同じ熱量・同じ厚みで書くと、それ自体が「整いすぎた不自然さ」になる。重要な節を厚く、軽い節は正直に軽く、と意図的なムラを設計しておく。手順は references/revision-guide.md の「濃淡設計」を参照。

1-4. 素材集め — 任意、新規執筆時

固有名詞・数値・実例が手元に乏しいまま書き始めると、後段で「一般論しか言えていない」と気づいても直しようがない。推論と検索の往復で素材を集める手順、十分と判断する基準、Web検索不可の環境でのユーザーへの素材提供依頼は references/revision-guide.md の「素材集め」を参照。

1-5. 文体プロファイル — 任意

style-profile.md（プロジェクトルートかユーザー指定の場所）が既にあれば読み込み、視点・語彙・リズムの癖を下敷きにする。なければ汎用モードで進めてよい。ユーザーが「自分の文体を学ばせたい」と求めた場合のみ、assets/style-profile-template.md に沿って過去文章3〜5本から特徴を抽出し、プロファイルを書き出す（断定しすぎず「傾向として」と留保をつける）。ユーザーが具体的な語や組み合わせを「自分は使わない」「不自然」と明示した場合は、一般規則へ拡張せず、出典と適用範囲を添えて同プロファイルの「避ける表現」へ記録する。単語全体を禁止せず、指摘された組み合わせを最小単位にする。

2. 執筆 — 文体憲法の下で書く

references/writing-constitution.md の12箇条を制約として本文を書く。要点だけ挙げると——結論から書き前置きを書かない、見出しはメッセージ、説明は地の文で書き箇条書きは真に並列な圧縮のみ、専門用語は「機能→名前」の順で文中説明、固有名詞・数値で接地、太字は文中の核1箇所、濃淡をつける、同じ鋳型を3回繰り返さない、「〜ではなく」は本当の誤解訂正だけ、限界と推定は明示ラベルで開示、事実と意見を分ける、結びは再統合しレポートは So What まで。

この段階では禁止語やリズムを気にしすぎず、憲法の範囲で内容を出し切ってよい。細部は次の検査工程が拾う。

3. 検査(1) — 静的検知

uv run scripts/lint.py --json <file>

禁止語・翻訳調・否定肯定対比の反復・文長の均質さ・体言止め率・段落頭の接続詞率・語彙多様性・英語統語の疑いなどを機械的に検出する。検出結果は件数に関わらず exit code 0（lint なので、件数で CI を止めることはしない）。入力エラーのときだけ exit code 1。

対象文書のジャンルが明確なら --genre essay|tech|business を指定する。コーパス校正済みの閾値プロファイルに切り替わり、誤検知が減る。ジャンルごとの判断基準の差分は references/genre-notes.md を参照。

収束ループ（4〜5）では、直前の --json 出力を --baseline に渡すと resolved / new / persisting を自動で仕分けてくれる。uv が使えない環境（Claude.ai 等）では references/manual-checklist.md で同じ観点を人手でなぞる。

もう一つ、scripts/semantic.py という EXPERIMENTAL な意味的検出器がある。文埋め込みで隣接文の類似度の起伏（話題の平板さ）を測るもので、torch + sentence-transformers 依存・初回~1GBのモデルダウンロードを伴う重量級のため lint.py 本体には組み込まず、独立した opt-in エントリにしている。フル工程や環境が許すときだけ uv run scripts/semantic.py --json <file> を追加で回し、findings は lint と同じく判断台帳に載せて扱う。

4. 検査(2) — 判断台帳と二つのレビュー

lint の findings は疑いの提示であり、機械的に全部直せという指示ではない。今回ヒットしたカテゴリの節を references/revision-guide.md で読み直し、文脈に照らして「直す/直さない」を判断する。判断は finding 一つひとつに「直した」か「残す（理由）」かを書き残しながら進める（台帳の形式は同ファイルの「判断台帳」を参照）。

用語カタログが必要なら: 禁止語 → references/forbidden-patterns.md、翻訳調 → references/translationese.md。専門用語が初出で説明されているか確認する材料には uv run scripts/terms.py <file> を使う。カタカナ複合語・ASCII略語・固有名詞らしき語を初出行・出現回数・説明マーカーの有無つきで列挙する（説明済みかどうかは機械が判断せず、AI/人間が行う）。

構造レビュー — スケルトン通読

lint は文レベルの表層しか見えない。特に箇条書き主体の議事録・スライドでは lint がほぼ素通りするため、構造レビューが主役になる。完成した本文から見出しと各段落の先頭文だけを抜き出して読み、次を確かめる（uv run scripts/outline.py <file> で見出し・各段落の先頭文・箇条書きプレースホルダを行番号付きで機械抽出できる）:

1. 論旨が通るか（スケルトンだけで話が追えるか）
2. 各見出しがメッセージになっているか
3. 同じ鋳型の反復がないか（定義文の型、節の内部構成、書き出しの文型）
4. 濃淡があるか（全節が同じ厚みになっていないか）
5. 結びが So What に接続しているか（レポート系）
6. business・techの解説・ケーススタディ・レポートでは、固定質問への主要回答を後半まで待たせていないか。また、事実説明とは別に予告・異変・種明かし・回収を何度も追わせていないか

文書タイプが定まっている場合は、doctype の「必須要素」と「AIがやりがちな失敗」も照合する。

読みやすさレビュー

語順、読点の位置、一文一義、主語述語の距離、こそあど言葉の多用、冗長表現は、機械的な閾値化ができないと実証済みの判断領域。references/readability-principles.md（一般原則）と references/readability-antipatterns.md（悪文パターン24種）を参照しながら毎周回、目視で判断する。短さは目的関数にせず、事実保持と主述・係り受けを確認した後の同等候補間でだけタイブレーカーに使う。

構造レビュー・読みやすさレビューで見つけた問題も、lint の finding と同様に判断台帳へ一行として起こす。

段落が一般論しか言えていない（固有名・数値・実例がない）場合は、書き方でなく素材の問題であることが多い。references/revision-guide.md の「素材不足の分岐」を見て情報収集に戻るべきか判断する。

5. 収束

台帳の「直した」項目を反映したら lint を再実行し、新しい finding が出ていないか確認する。台帳上の全 finding が仕分けられ、修正が新たな finding を生んでいない状態になるまで 3〜4 を繰り返す。同じ finding が2周連続で再発する場合は references/revision-guide.md の「発散ガード」を参照。

既存文書のリライトでは、同じ種類の修正（見出しの結論化、箇条書きの地の文化など）を全項目へ一律に当てると、元の文書の自然な濃淡を消してかえってAI臭が増す。価値を足せる箇所だけを選んで直す原則は references/revision-guide.md の「改稿を一律に適用しない」を参照。

6. 最終パス — 自己点検ループ

lint と台帳が収束しても、それは既知のパターンが消えたことしか意味しない。最後に必ず、初見の読者として通読し、声に出して読むつもりでリズムを確かめる。手順は references/revision-guide.md の「自己点検ループ」を参照。違和感を見つけたら台帳に起こして5に戻り、なくなったら完了とする。

7. 後片付け

完了したら、作業中に作った中間ファイル（台帳・lint の JSON・下書きのバックアップ等）をすべて削除する。ユーザーのプロジェクトに残してよいのは完成した文書と、ユーザーが明示的に望んだ場合の style-profile.md だけ。詳細は references/revision-guide.md の「作業ファイルの扱い」を参照。

参考例

before/after の具体例は references/examples.md を参照。