# Japanese Prose Revision

> 日本語の説明文・技術原稿を編集者の水準で推敲するための規範。整形、段落と論証の構成、論証の厳密さ、読み手の負荷、視点と語り、演出の抑制、LLMっぽい表現の排除、冗長の削除、見出しの付け方を点検する。「推敲して」「編集者目線で直して」「文章が冗長」「AIっぽい」と依頼されたときに使用する。

- Skill: `redamoon/japanese-prose-revision` (Agent Skill)
- Install (CLI): `npx skillmds@latest add redamoon/japanese-prose-revision`
- Raw SKILL.md: https://api.skillmd.com/api/skills/redamoon/japanese-prose-revision/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: redamoon (https://skillmd.com/u/redamoon)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/redamoon/japanese-prose-revision

---


# 日本語推敲スキル（編集者の規範）

書き上げた日本語の原稿を、編集者が赤入れするのと同じ観点で点検・修正するためのガイドです。プラットフォーム記法（Zenn / はてな / note）ではなく、**文章そのものの質**を対象にします。

## When to Use

- 記事・章・解説文を書き終えて推敲するとき
- 「推敲して」「編集者目線でレビューして」「読みにくいので直して」と依頼されたとき
- 「冗長」「AIっぽい」「中身がない」と指摘された文章を直すとき
- 他人の原稿・生成された下書きに赤入れするとき
- 見出しや段落の切り方を見直すとき

緩急やリズムの設計が問題のときは、`cognitive-rhythm-writing` を併用します。プラットフォーム固有の記法は `zenn-blog-writing` / `hatena-blog-markdown` / `note-book-reading-memo` に従います。

## Instructions

### 使い方の順序

1. まず本文を通読し、**論証の厳密さ**と**冗長の排除**を先に当てる（構造に関わるため）
2. 次に**視点と語り**・**演出の抑制**・**LLMっぽい表現**を当てる（文単位の修正）
3. 最後に**整形**と**見出し**を揃える
4. textlint を使うプロジェクトでは、この推敲のあとに `textlint-blog` を走らせる

### 文体の読み替え（ですます調の記事に当てるとき）

この規範は、である調の技術原稿を前提にしています。ですます調のブログ記事へ当てるときは次のように読み替えます。

- 断定・逡巡の書き分けは維持する。「〜です」「〜でしょう」「〜かもしれません」で同じ機能を出す
- 「イ形容詞＋です」（「難しいです」）の項は、ですます調では避けられない。ただし**文が前後から孤立している兆候**としては有効なので、出てきたら文末だけ直さず前後の流れを見直す
- 「〜してはならない」を避ける項は、ですます調では「〜しないでください」ではなく「〜するわけにはいきません」「〜は避けます」に置き換える

### 整形

- 執筆中は一文ごとに改行し、段落の区切りは空行で示す
- コード、差分、ログ、設定ファイルの断片はコードブロックに入れる
- 用語の由来や定式化の名称など、本筋から一段外れる補足は本文に並べず、脚注（`[^ラベル]`）か括弧に降ろす
- 用語を初めて定義・導入するときは太字にする。すでに導入した語を話題として指すとき、引用、通称には「」を使う（初出の定義は太字、以後の言及は「」）
- ダッシュ（`—` `―` `——`）を日本語の地の文・見出しで使わない
  - 同格・補足の挿入（「A——挿入——B」）は括弧（）にする
  - 言い換え・敷衍（「A——B」）は句点で二文に分けるか、読点でつなぐ
  - 範囲を示す en ダッシュ `–`、英語の複合語（`Curry–Howard` など）、コードブロック、書誌情報は対象外
- 中黒（・）を本文の地の文の並列で使わない（読点でつなぐ）。単一の固有名詞の内部では使ってよい。箇条書きの見出し語や術語の列挙は対象外
- 見出しに「種別──主題」のように区切り線で二要素を詰め込まない。単一の自然な句にする
- 用語とその定義を並べる箇条書きは、区切り線ではなく全角コロンで「**用語**：説明」と書く

### 段落と論証の構成

パラグラフライティングを基本にします。段落は論証の一歩であり、読者は段落単位で論理を追えなければなりません。

- 一つの段落には一つのトピックだけを置く。調査・報告・検証・評価が混ざった長い段落は、一歩ずつの段落に割る
- 段落の最初の文を読めば、その段落が何の話かわかるようにする
- 段落の先頭で、前の段落との論理関係を接続表現で示す（「であれば」「実際」「しかし」「この例自体からも」）
- 新しい概念を導入するとき、いきなり「XはYである」の辞書型断定で始めない。先に導入文で対象を置き、次にその働き・差分を述べ、必要なら三文目で定義を与える
- 論証は一方向に進める。結論を出してから反論を処理し、結論を言い直す構成にしない。反論と疑念の処理を終えてから、結論を一度だけ置く
- 例への弁明（作為的に見える、への先回り）は場面の山場の直後に挟まない。次の節の冒頭でまとめて処理する
- 読者が立てそうな誤った解釈は、明示的に否定してから本当の理由を述べる（「その理由は『〜だから』ではない。〜だからだ」）
- 「AではなくB」と否定するときは、否定の根拠を一文添える。反実仮想（「もしAなら、〜だっただろう」）が使えることが多い
- 譲歩（「確かに〜」）では事実の確認にとどめる。あとで訂正する内容を著者の声で断定すると自己矛盾になる。表面的な診断を一度認めたいときは、読者や通説の声に帰属させる（「〜と要約できてしまうかもしれない」）
- 山場で効かせたい情報（数値、固有の事実）を、その手前の段落で先出ししない
- 否定・限定するときは、否定する命題そのものを「」で正確に書き出す。「何もかもが解決するわけではない」のような漠然とした否定で済ませない
- 「後の章で扱う」のような前方参照は、論証が一段落した位置（段落末・節末）に置く

### 論証の厳密さ

読み手の反論を先回りして、次を点検します。

- 推量・可能性・読者の疑念・反実仮想として書かれている文を、機械的に断定へ変えない
  - 「かもしれない」「だろう」「ようだ」は、**根拠なく主張を弱めている場合だけ**削る
  - 事実未確認の可能性、登場人物の認識、ログからの推定、読者が抱きそうな疑念、反実仮想は、不確実性を保つ
  - 断定に直せるのは、本文内の根拠によって命題が確定している場合に限る
  - 悪い例：「提示し続けているかもしれない」→「提示し続けている」
  - 良い例：「提示し続けている可能性がある」
- 異なるものを「同じ」とまとめない
  - 悪い例：相互依存する三つの未決事項を「同じ決定を別々に下していた」と書く
  - 良い例：「どれも別々の決定であり、しかも互いに依存している」と腑分けする
- 複数の要因がある事象を、単一の原因に還元しない。例が複数種類の問題を含むなら切り分け、どの道具がどれを説明するのか対応づける
- 章・節をまたいで、同じ概念の扱いを一致させる。ある節で「人間が決める」と分類したものを、別の節で「チームで合意する」と書かない
- 因果を主張するときは、その機構（なぜそうなるのか）を一文で示す
  - 悪い例：「手順で分けると変更が全体に波及する」
  - 良い例：「各工程がデータを受け渡すための表現を共有してしまい、その表現を変えると全体に波及する」
- 検出・保証・解決を「必ず」できるかのように書かない。条件付きで正確に述べる（「〜しやすい」「〜できることが多い」「〜が成り立つときに限り」）
- 挙げた例が主張の全体を支えているか確認する。一部しか支えないなら、主張の範囲を例に合わせて狭める
- 「次節で扱う」と前方に逃がした論点は、本当にそこで回収されるか確認する。回収しない伏線を張らない
- 譲歩や限定（「ただし」「とはいえ」）を置いたら、その後で必ず論を進める。逆接で終えて宙吊りにしない
- 節の中心となる語は、その節以前に定義・対象範囲を述べてから使う
- 複数の概念を一つの上位語にまとめるときは、命名の直前に、それらが同じものに帰着すると一文で述べる

### 読み手の負荷

読者の記憶と注意は有限の資源として扱います。

- 後で参照しない固有名（ファイル名、関数名、識別子）を出さない。「仕様書」「金額計算のユーティリティ」で済ませる
- 抽象的な言い回しの指す内容が文脈から一意に決まらないときは、丸括弧の同格挿入でその場で特定し、読者に前を読み返させない
- 新しい例を追加して保持すべき文脈が増えるときは、前の例と何が違うのか、なぜもう一つ必要なのかを前置きする
- 章冒頭・節の導入に、これから扱う内容と関係しない詳細を詰め込まない
- 例の節では、**その節の問い・帰結に関係しない**詳細だけを省く。議論に必要な具体は残す。省略の典型は、装飾的な精度（時刻、HTTP ステータス、カバレッジ率）や、後で参照しない固有名

### 視点と語り

- 結果の羅列や受動態（「特定され、判明した」）ではなく、行為者を主語にした動作の連なり（「リポジトリを調査して特定した」）で書く
- 「入社2年目のエンジニアが」のような架空の人物設定を無意味に冠しない
- 論証の中で読者を「あなた」と呼ばず、役割名（「開発者」「読者」）で書く。二人称は場面への導入（「〜としよう」）や結びなど、限られた要所にとどめる
- 対象を指す語は具体的に選ぶ。「AI」「ツール」のような広い語でぼかさない
- 術語を導入したら以後はその語で通す。「文脈」「ツール」のような曖昧語に後退しない
- 術語・訳語は、その分野で慣用されている語を選ぶ（プッシュ通知は「配送」ではなく「配信」）。意味の近い漢語を一般語の感覚で充てない
- 人物そのものに言及するときは原綴りで書く（Lehman、Bainbridge）。ただし定着したカタカナ通称があるときはそれを使う
- 術語の響きを持つ語を、術語でない場面に流用しない。「届くまでの流れ」のように普通の言い方で書く
- 「難しいです」「多いです」のようなイ形容詞＋ですは、**文が前後から孤立している兆候**として扱う（ですます調の記事では文末だけでなく前後の流れごと見直す）

### 演出の抑制

修辞は全面禁止ではなく、効果を生む箇所でだけ使います。

- 溜め（「ここには〜が潜んでいる」）や修辞疑問は、緊張が議論に効く要所に限る。説明で足りる箇所ではそのまま述べる
- 短い決め台詞を独立した段落にする演出を多用しない。段落内の短い体言止めは場面の山場に限る
- 本文中の太字強調を多用しない。誤読を防ぐ否定や節の帰結など、論理の要所に限り、一節に一、二箇所まで
- 「〜してはならない」という命令調より、「〜するわけにはいかない」のように作業者の判断として書く
- 転回点を過剰に劇的にしない。事実を述べる一文で足りる場合が多い
- 帰結の列挙によって事故や危険を煽らない
- 「重要なのは〜である」のような前置きで主張を予告しない。主張をそのまま書く
- 「AではなくBだった」という対句の決め台詞を多用しない
- 慣用表現をひねった言い回し（「知識を体に入れる」）や、指す内容が一意に決まらない比喩を使わない。平易な動詞でそのまま言う（「身につく」）

### LLM っぽい表現の禁止

論点を増やさず「ちゃんと書いている感」だけを付ける型を使いません。

| 分類 | 使わない表現 |
|------|--------------|
| 予告と総括 | 「重要なのは〜である」「本章では〜を扱う／探求する」「ここでは〜について見ていく」「まとめると」「要するに」（直前の言い換えだけのとき）、「〜に他ならない」 |
| 正面から系 | 「正面から扱う」「正面から回収する」「正面から向き合う」（中身の代わりに姿勢だけを宣言する） |
| 空虚な形容 | 「不可欠」「核心的」「鍵となる」「根本的な」「多角的」「包括的」「総合的」 |
| 誇張と絶対化 | 「革命的」「驚異的」「完璧な」「圧倒的」（事実や数値で述べるべきところを形容で押し切る） |
| 空虚な動詞 | 「掘り下げる」「深掘りする」「言語化する」「触れる」「言及する」 |
| 接続の型 | 「〜において」「〜という側面から」「〜の観点から」（新情報なし）、「さらに」「また」「加えて」の連打 |
| 弱い緩和と称賛 | 「〜と言えるだろう」（根拠なく弱めるとき）、「非常に」「極めて」「大いに」 |

- 悪い例：「本章では、〇〇の理論を正面から扱う」「多角的に分析すると、重要なのは〜である」
- 良い例：「本章では、〇〇の理論を扱う」「評価の核心は、正しさを誰が知っているかにある」

自分の議論の術語として使う分には問題ありません。空虚な装飾として使うのが問題です。

### 冗長の排除

- 同じ主張を言い換えて繰り返さない。一つの主張は一度だけ書く
- 隣接する節が同じことを別の角度で述べているなら、片方に吸収して一つの節にまとめる
- 場面を描写した直後に、その内容を要約し直さない。意味づけの一文だけを置く
- 同じ論理的役割を持つ並列の事実は、文を分けて重ねず一文にまとめる
- 読者が自力で補える中間段階の説明は書かない
- 数文にわたる議論を一文に圧縮できるなら、圧縮した一文だけを残す
- 接続や評価のためだけの文（「それ自体はよいことである」）を置かない
- 想像上の読者との問答を修辞として使わない。読者の反応を演じて応答する形（「〜と感じたかもしれない。そのとおりである」）も避け、譲歩は地の文で簡潔に行う
- 読者が抱きそうな発想を、メタな枠取り（「ここまでの話には自然な続きがある」）で紹介しない。その発想自体を直接書く。読者の疑問なら疑問文のまま書いてよい
- 「本書もそれを否定しない」のような著者の立場の弁明を書かない。事実の記述だけを置く
- 本文でまだ導入していない概念や文書名を、先回りして持ち出さない
- ためらいのある弱い述語で済ませない。本文内の根拠で確定していることは具体的に言い切る。ただし不確実性・仮定・読者の疑念を表す弱い述語は保持する
- リズムを作るための接続表現（「しかし一方で」）は冗長と見なさない

### 見出しの付け方

- その節が答える問い、または扱う対象を指す句にする
- 作業の手順だけを述べる見出し（「例に戻す」「〜を読み直す」）や、情報量のない見出しにしない
- 見出しを、節の結論を言い切る「セリフ」にしない。見出しの時点で読者がオチを知る状態を避ける
- 節で扱っている対象を指す名詞句でもよい
- 疑問形か断定形かは問わない。問うのは、扱う対象や読者の持つ問いを指しているかである

### 読者への誠実さ

- 例が作為的に見えうる場合、それを隠さない。読者の疑念を先回りして認め、現実にあり得る根拠を短く添える
- その根拠は、著者の断定（「十分あり得る状況だ」）ではなく、読者自身の経験に訴える一般的事実に求める（「この症状は珍しくないだろう」）
- 確認していないことを、確認したかのように滑らかに書かない

## 推敲チェックリスト

### 論証

- [ ] 推量として書くべき文を断定に変えていないか
- [ ] 別のものを一括りにしていないか、単一原因に還元していないか
- [ ] 因果を主張した箇所に機構の説明があるか
- [ ] 前方参照した論点は回収されているか
- [ ] 章・節をまたいで概念の扱いが一致しているか

### 文

- [ ] LLM っぽい表現の表に載る語が残っていないか
- [ ] 太字強調が一節に一、二箇所を超えていないか
- [ ] ダッシュ・中黒を日本語の地の文で使っていないか
- [ ] 受動態と結果の羅列を、行為者主語の文に直せないか
- [ ] 後で参照しない固有名が残っていないか

### 構成

- [ ] 一段落に一トピックか
- [ ] 段落の先頭で前段落との論理関係が示されているか
- [ ] 隣接する節で役割が重複していないか
- [ ] 見出しが扱う対象・問いを特定しているか

## 出典

この規範は k16shikano 氏の公開スキルを土台に、当リポジトリの用途（ブログ・技術ドキュメント）へ再構成したものです。

- [日本語技術文書の文章規範](https://gist.github.com/k16shikano/fd287c3133457c4fd8f5601d34aa817d)（The Unlicense）
- [認知リズムを生むための日本語ライティング規範](https://gist.github.com/k16shikano/eb2929f13ed19c97188393d297be8432) → 当リポジトリでは `cognitive-rhythm-writing` に対応