redamoon natural-japanese
仕事の日本語を、読みやすくわかりやすく書くためのスキル。議事録・調査レポート・社内ガイド・リサーチメモ・スライドといった仕事の文書を主対象にする。AI臭さの除去は工程の一部として組み込まれている。
出典: coji/natural-japanese（MIT）のフォーク。検出スクリプトを Python(uv/sudachipy) から TypeScript(npx tsx/kuromoji) へ移植し、当リポジトリの流儀に合わせて再構成した。原典の semantic.py（意味的な話題平板さ検出、torch 依存）と calibrate.py（コーパス校正用の開発者ツール）、および corpus/evals は移植対象外（後述の「原典からの変更点」を参照）。
When to Use
- 議事録・調査レポート・社内ガイド・企画書・提案書・報告書・メール・スライド構成案などビジネス文書を書く・直すとき
- 「結論から書いて」「論旨を明確に」「見出しを端的に」「専門用語をわかりやすく」と依頼されたとき
- 「AIっぽい」「不自然」「機械翻訳っぽい」「単調」と文章を指摘されたとき、または既存文章をリライト・推敲するとき
- 書き換えずに「この文章AIが書いた？」「AI臭さを採点して」と診断だけ求められたとき
- 自分の文体を学ばせたい・プロファイル化したいと求められたとき
ブログ記事・技術記事・エッセイの推敲は japanese-prose-revision（編集者水準の推敲規範）と cognitive-rhythm-writing（認知リズム）を優先する。本スキルはビジネス文書を主対象とし、判定の機械化（lint スクリプト）と文書タイプ別の型（doctypes）を備える点が異なる。技術文書の章構成やMarkdownフォーマットの整形自体（一文一行化・引用ブロック・脚注記法など）は対象外。
設計思想
軸は二つ。第一に「検出は機械、判断はAI」。AIは自分の癖を認識しにくいから、疑いの検出は機械が決定的に行い、直すかどうかはAI（あなた）が文脈で判断する。第二に「事後修正より生成時制約」。書いた後にAI臭を消すより、書く前の設計と書くときの制約で発生自体を防ぐほうが効く。工程は「設計 → 執筆 → 検査 → 収束」の順に進む。
実行モード — クイックとフル
同じ工程を、かける手間の異なる2つのモードで回す。フルを始めるときは、クイックより時間がかかる旨をユーザーに一言伝えてから着手する。
クイック（既定）: 日常の文書はこちら。サブエージェントを使わず、この場で完結させる。追加で読むのは該当する doctype の型1ファイルだけでよい（文体憲法は§2の要約で足りる。他の references は lint の finding が出て判断に迷ったときだけ開く）。設計（§1）は読者・主メッセージ・見出しの確認を頭の中で済ませる。検査は lint を1回と、自分でのスケルトン通読。lint は文書が短くても省略しない（短文では統計系検出器が沈黙するが、禁止語・翻訳調は文1つでも検出される。数秒の保険であり、これを飛ばした時点でクイックの品質保証は成立しない）。収束ループは新規 finding が出なければ1周で切り上げ、最終パスの通読をして終える。
フル: ユーザーが「しっかり」「ちゃんと」「時間をかけていい」と言ったとき、対外・経営向けなど失敗コストが高い文書、または長い文書（目安1万字超）のとき。フルと決めたら（またはユーザーがフルを指定したら）、文書が小さくても工程を省略しない。lint に加えて outline / terms も実行し、検査（§4）の三つのレビュー——構造レビュー・読みやすさレビュー・doctype照合——を並列のサブエージェントで必ず行う（各自が所見を返し、判断台帳への統合と「直す/残す」の判断は必ず親が行う。執筆そのものは分割しない——濃淡・比喩の一貫・章間の接続は文書全体を見ないと守れない）。収束は状態条件（§5）を満たすまで回す。「この文書には過剰」と感じても、工程を勝手に間引かず、クイックへの切り替えをユーザーに提案する。
どちらか迷ったら、まずクイックで仕上げてから「フルで磨き直すこともできる」とユーザーに一言添えるのがよい。
呼び出し方 — write / score / モード指定
スキルがコマンドとして引数つきで呼ばれた場合、次の形を解釈する。
/natural-japanese [quick|full] <対象>— 書く・直す（既定）。新規作成かリライトかは対象から判断する/natural-japanese write [quick|full] <お題や素材>— 新規作成を明示。元の文章がない状態から、§1の設計（読者・主メッセージ・スケルトン・濃淡・素材集め）→§2の執筆→検査→収束の全工程で書き起こす。素材が乏しければ§1-4で先に集めるか、ユーザーに求める/natural-japanese score [quick|full] <ファイル>— 診断のみ。文書を書き換えず、自然度スコア（0〜100、高いほど自然=AI臭が薄い）と理由で返す。quick=lint のみ（30秒）、full=構造・読みやすさレビュー込み。最初に必ず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
型に当てはまらない文書はこの節を飛ばしてよい。
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) — 静的検知
npx tsx scripts/lint.ts --json <file>
初回実行時は kuromoji の辞書ロードとパッケージインストールで数秒〜十数秒かかる（scripts/package.json に依存関係をまとめてある）。禁止語・翻訳調・否定肯定対比の反復・文長の均質さ・体言止め率・段落頭の接続詞率・語彙多様性・英語統語の疑いなどを機械的に検出する。検出結果は件数に関わらず exit code 0（lint なので、件数で CI を止めることはしない）。入力エラーのときだけ exit code 1。
対象文書のジャンルが明確なら --genre essay|tech|business を指定する。コーパス校正済みの閾値プロファイルに切り替わり、誤検知が減る。ジャンルごとの判断基準の差分は references/genre-notes.md を参照。
収束ループ（4〜5）では、直前の --json 出力を --baseline に渡すと resolved / new / persisting を自動で仕分けてくれる。Node.js が使えない環境（Claude.ai 等）では references/manual-checklist.md で同じ観点を人手でなぞる。
4. 検査(2) — 判断台帳と二つのレビュー
lint の findings は疑いの提示であり、機械的に全部直せという指示ではない。今回ヒットしたカテゴリの節を references/revision-guide.md で読み直し、文脈に照らして「直す/直さない」を判断する。判断は finding 一つひとつに「直した」か「残す（理由）」かを書き残しながら進める（台帳の形式は同ファイルの「判断台帳」を参照）。
用語カタログが必要なら: 禁止語 → references/forbidden-patterns.md、翻訳調 → references/translationese.md。専門用語が初出で説明されているか確認する材料には npx tsx scripts/terms.ts <file> を使う。カタカナ複合語・ASCII略語・固有名詞らしき語を初出行・出現回数・説明マーカーの有無つきで列挙する（説明済みかどうかは機械が判断せず、AI/人間が行う）。
構造レビュー — スケルトン通読
lint は文レベルの表層しか見えない。特に箇条書き主体の議事録・スライドでは lint がほぼ素通りするため、構造レビューが主役になる。完成した本文から見出しと各段落の先頭文だけを抜き出して読み、次を確かめる（npx tsx scripts/outline.ts <file> で見出し・各段落の先頭文・箇条書きプレースホルダを行番号付きで機械抽出できる）:
- 論旨が通るか（スケルトンだけで話が追えるか）
- 各見出しがメッセージになっているか
- 同じ鋳型の反復がないか（定義文の型、節の内部構成、書き出しの文型）
- 濃淡があるか（全節が同じ厚みになっていないか）
- 結びが So What に接続しているか（レポート系）
- business・techの解説・ケーススタディ・レポートでは、固定質問への主要回答を後半まで待たせていないか。また、事実説明とは別に予告・異変・種明かし・回収を何度も追わせていないか
文書タイプが定まっている場合は、doctype の「必須要素」と「AIがやりがちな失敗」も照合する。
読みやすさレビュー
読解負荷の高い箇所は npx tsx scripts/lint.ts --reading-load <ファイル> で指さしを出せる（一文長・埋もれた列挙・連続漢字・二重否定・「の」連鎖）。これは AI臭さの検出とは別目的の推敲用レーンで、自然度スコアにも --baseline 比較にも入らない。出力は「この文を見ろ」であって「直せ」ではない。指摘は起点として扱い、どう直すかは下記カタログの該当項目で判断する。
語順、読点の位置、一文一義、主語述語の距離、こそあど言葉の多用、冗長表現は、機械的な閾値化ができないと実証済みの判断領域。references/readability-principles.md（一般原則）と references/readability-antipatterns.md（悪文パターン27種を読解負荷順に A→J で分類したカタログ）を参照しながら毎周回、目視で判断する。カタログは前から当てる——A（否定の入れ子）・B（係り受けの距離）・C（語と語形の重さ）が一文の中で読者に計算を強いる高負荷層で、H・I・J は文書・表記・読者の知識にまたがる層。短さは目的関数にせず、事実保持と主述・係り受けを確認した後の同等候補間でだけタイブレーカーに使う。文の分割や列挙の展開で字数が増えるのは正しい結果であり、不合格の理由にしない。
構造レビュー・読みやすさレビューで見つけた問題も、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 を参照。
原典からの変更点
- 検出スクリプトを Python(uv + sudachipy) から TypeScript(
npx tsx+ kuromoji.js) へ書き直した。形態素解析辞書が sudachipy(SudachiDict) から kuromoji(IPADIC) に変わるため、閾値は原典の値をそのまま引き継いでいるが、分かち書きの粒度が異なる分、多少の検出感度の差がありうる scripts/semantic.py（意味的な話題平板さ検出。torch + sentence-transformers 依存、初回1GB級のモデルDL）は移植していない。話題の平板さは目視で判断する（references/revision-guide.md参照）scripts/calibrate.py（コーパス校正用の開発者ツール）とcorpus/以下の評価用データ・レポート一式は、パッケージ配布するスキル本体に含めていない（原典でもskills/natural-japanese/の外側にあり、スキルの実行には不要）--baseline差分比較・--genreプロファイル・--experimentalフラグ・--reading-loadレーンは TypeScript 版でも同様に実装している