Natural Japanese

---
name: natural-japanese
description: 仕事の日本語文書を読みやすくわかりやすく書く・直すためのスキル。議事録（文字起こしからの議事録化を含む）、調査レポート・分析レポート、社内ガイド・マニュアル、リサーチメモ・ディスカッションペーパー・企画書・提案書・報告書・メール、スライド構成案といったビジネス文書の作成・校正、「結論から書いて」「論旨を明確に」「見出しを端的に」「専門用語をわかりやすく説明して」といった指示のいずれでも使用する。AI臭さの除去（「AIっぽい」「AI臭い」「機械翻訳っぽい」「不自然」「もっと自然な日本語に」「機械っぽい」「人間っぽくして」「単調」「〜することができる、と言えるだろう、のような言い回し」といった直接・間接・口語の指摘、AIで書いたと言われた/疑われた）、読みにくい・わかりにくい文章の改善依頼（語順がおかしい、一文が長い、何が言いたいか分からない、読点の位置がおかしい等）、note記事やブログ記事・エッセイの新規執筆（任意のテーマをゼロから書く・書き起こす依頼を含む）、既存文章のリライト・推敲、自分の文体を学ばせたい・プロファイル化したいという要望（過去の文章を読ませて自分らしく書いてほしいという依頼も含む）にも対応する。禁止語の除去、リズムの単調さ・段落構造の均質さ・英語統語の直訳調に加え、語順・読点・一文一義・主語述語の距離といった読みやすさの原則にも対応する。技術文書の章構成やMarkdownフォーマットの整形自体（一文一行化・引用ブロック・脚注記法など）は対象外——それは別スキルの領域であり、本スキルは文章の自然さ・読みやすさ・わかりやすさに特化する。
license: MIT
argument-hint: "[quick|full] [対象ファイルや依頼内容]"
---

# natural-japanese

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

> workhub 移植版の注記: 本スキルは `coji/natural-japanese` から選別移植したもので、スクリプト (`scripts/`) と診断 (score) モードを含まない。検査の主経路は `references/manual-checklist.md` による目視である。references 内に `lint.py` 等への言及が残っている箇所は上流の来歴説明として読み替え、実行手順は本 SKILL.md の記述を優先する。帰属はプラグイン直下の `NOTICE.md` 参照。

## 設計思想

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

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

同じ工程を、かける手間の異なる2つのモードで回す。

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

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

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

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

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

- `/natural-japanese [quick|full] <対象>` — 書く・直す（既定）。新規作成かリライトかは対象から判断する
- `/natural-japanese write [quick|full] <お題や素材>` — **新規作成を明示**。元の文章がない状態から、§1の設計（読者・主メッセージ・スケルトン・濃淡・素材集め）→§2の執筆→検査→収束の全工程で書き起こす。素材が乏しければ§1-4で先に集めるか、ユーザーに求める

モード指定がなければ実行モードの基準で自分で選ぶ。自然言語でも同じ（「〇〇について書いて」→ write 相当）。

## 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) — チェックリスト

`references/manual-checklist.md` を1周させる。禁止語・翻訳調・否定肯定対比の反復・文長の均質さ・体言止め率・段落頭の接続詞率・語彙の使い回し・英語統語の疑いなどを目視で洗い出す。

対象文書のジャンルが明確なら `references/genre-notes.md` を参照し、ジャンルごとの判断基準の差分を織り込む（コーパス校正済みの目安であり、誤検知めいた指摘の取捨に使う）。

収束ループ（§5）では、前周の判断台帳と突き合わせて resolved / new / persisting を仕分ける。台帳への追記は new と persisting が対象になる。

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

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

用語カタログが必要なら: 禁止語 → `references/forbidden-patterns.md`、翻訳調 → `references/translationese.md`。専門用語の初出説明を確認するには、カタカナ複合語・ASCII略語・固有名詞らしき語を手で拾い、初出箇所と説明の有無を一覧にする（説明済みかどうかの判断はAI/人間が行う）。

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

完成した本文から見出しと各段落の先頭文だけを抜き出して読み、次を確かめる:

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

文書タイプが定まっている場合は、doctype の「必須要素」と「AIがやりがちな失敗」も照合する。特に箇条書き主体の議事録・スライドでは表層チェックが素通りしやすいため、構造レビューが主役になる。

### 読みやすさレビュー

語順、読点の位置、一文一義、主語述語の距離、こそあど言葉の多用、冗長表現は、目視判断の領域。`references/readability-principles.md`（一般原則）と `references/readability-antipatterns.md`（悪文パターン27種を読解負荷順に A→J で分類したカタログ）を参照しながら毎周回、目視で判断する。**カタログは前から当てる**——A（否定の入れ子）・B（係り受けの距離）・C（語と語形の重さ）が一文の中で読者に計算を強いる高負荷層で、H・I・J は文書・表記・読者の知識にまたがる層。短さは目的関数にせず、事実保持と主述・係り受けを確認した後の同等候補間でだけタイブレーカーに使う。文の分割や列挙の展開で字数が増えるのは正しい結果であり、不合格の理由にしない。

構造レビュー・読みやすさレビューで見つけた問題も、チェックリストの指摘と同様に判断台帳へ一行として起こす。

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

## 5. 収束

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

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

## 6. 最終パス — 自己点検ループと評価ハーネス

チェックリストと台帳が収束しても、それは既知の表層パターンが消えたことしか意味しない。ここから先には、チェックリストでは拾えない「無菌室のような冷たさ」「ダラダラとした冗長な引き伸ばし」が残りやすい。

フルモード（および重要な文書）では、`references/eval-rubric.md` の **6軸推敲ルーブリック** を用いて客観評価を行う。

1. **脱AI臭・文体の自然さ**: プレゼン的数宣言・共感煽り・翻訳調ダッシュ・決め文がないか
2. **情報密度・簡潔さ（ダラダラ引き伸ばしの排除）**: 読者の時間を奪う不要な前置き・講釈・言い換え水増しを削ぎ落としているか
3. **機能性・走査性**: 欲しい情報に最短で迷わず辿り着けるか
4. **論理の明晰性と納得感**: 因果関係が腑に落ち、実測・具体例で接地しているか
5. **人間味・誠実さ（体温・動機）**: 無菌室病にならず、書き手の実感・問題意識（Why）が宿っているか
6. **自己証明力**: その文書自体が、看板に偽りのない最高のお手本になっているか

**合格基準は全軸90点以上・総合平均92点以上**。未達の軸があればボトルネックを特定して改稿し、合格に達するまでループを回す（手順詳細は `references/eval-rubric.md` および `references/revision-guide.md` を参照）。クイックモードではこの6観点を頭の中で通読点検して終える。違和感を見つけたら直して完了とする。

## 7. 後片付け

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

## 参考例

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