# Meiseki

> 日本語の文章を「一読で意味が取れる」状態に明晰化するスキル。 「わかりやすく直して」「読みやすくして」「読みにくいので整えて」「AIっぽさを消して」 「ドキュメントを推敲して」「冗長な日本語を削って」「文章を明晰化して」などで発動する。 対象は技術記事・README・設計書・社内ドキュメント・ブログの説明文など説明的な日本語の本文。 対象外はコード本体・SNS の短文・小説や詩などの創作・法務／医療／論文の厳密文。 二重否定・長い連体修飾・「の」の連鎖・過剰な名詞化・冗長表現・埋もれた列挙、 さらに「重要なのは〜」「掘り下げる」などの LLM 定型句や、段落レベルの言い換え反復といった 「日本語ネイティブでも読解負荷の高い構文」を削ぎ落とすことが目的。 声・立場・個性は足さず、明晰さ（明晰＝澄んで分かること）だけを目的とする。

- Skill: `bamboo-nova/meiseki` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add bamboo-nova/meiseki`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bamboo-nova/meiseki/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: bamboo-nova (https://skillmd.com/u/bamboo-nova)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bamboo-nova/meiseki

---


# meiseki — 日本語明晰化スキル

## 1. 狙いの宣言

文章の読みにくさは、難しい**語彙**ではなく**構文**から生まれる。二重否定、長い連体修飾、
「の」の連鎖、過剰な名詞化、冗長な言い回し、一文に埋もれた列挙——これらは語の置換では消えない。
このスキルの目的は **明晰さ（clarity）= 内容を知らない読者が一度読んで正しく理解できること** だけである。

「自然さ」「AI 検出の回避」「文章の上手さ」は目的ではない。明晰さだけに振る。

## 2. 出力方針

- **標準の出力はリライト後の本文のみ。** 分析・講評・「ここを直しました」という解説は付けない。
- ユーザーが「どこを直したか教えて」「変更点を出して」と**明示したときだけ**、本文に続けて変更点を簡潔に添える。
- ユーザーが読解負荷スコアを求めたときは、本文のあとに before→after のスコアを示す（§7 参照）。

## 3. 対象 / 対象外

- **対象**：技術記事・README・設計書・社内ドキュメント・ブログの説明文など、説明的な日本語の本文。
- **対象外**：コード本体（コメント含む厳密な記述）・SNS の短文・小説や詩などの創作・法務／医療／論文の厳密文。
- **混在文書**：対象部分だけを直し、対象外（コードブロック・引用・厳密文）は原文のまま残す。

## 4. ワークフロー（この順序で行う）

### Step 1. 全文を読み、意味を把握する
事実・主張・結論・前提条件を正確に取る。**意味を取り違えると明晰化は台無しになる。**
特に否定・条件・係り受けの論理構造を頭の中で確定させる。

### Step 2. textlint を実行する（決定論層）
原稿を任意の一時ファイル（拡張子は `.md`）に書き出し、Node.js 同梱の `npx` 経由で textlint を実行して JSON を読む。

```bash
# textlint を JSON フォーマットで実行（Skill 同梱の設定を使う）
npx --min-release-age=7 --yes --package textlint@14.8.4 --package textlint-rule-preset-ja-technical-writing@10.0.2 --package textlint-rule-preset-ai-writing@1.1.0 --package textlint-rule-prh@6.1.0 textlint -c "<SKILL_DIR>/references/textlint.config.json" -f json "<INPUT_MD>"
```

- `<SKILL_DIR>` はこの `SKILL.md` があるディレクトリの実パスに置き換える。
- `<INPUT_MD>` は原稿を書き出した一時 Markdown ファイルの実パスに置き換える。
- `textlint` は指摘があると終了コード 1 を返す。その場合も stdout の JSON を読み、処理は続ける。
- 出力 JSON の各 `messages[]` から `ruleId`（例 `preset-ja-technical-writing/no-double-negative-ja`）と
  `line` / `column` を読み、高負荷箇所を特定する。

### Step 3. 読解負荷スコア(before) を算出する
§7 の式で before スコアを出す。`no-double-negative-ja`（A）の件数は特に記録しておく。

### Step 4. patterns.md の A→H に沿ってリライトする
`references/patterns.md` を参照し、**優先度 A→H の順**で直す。

- **A（否定・条件の入れ子）が最優先。** 二重否定は最初に畳む。
- textlint が拾った箇所（A 二重否定 / B 一文長・読点 / C 連続漢字・冗長 / D 接続詞重複・弱い表現・冗長助動詞
  （`ai-tech-writing-guideline`） / E 絵文字箇条書き・過剰太字（`ai-writing/*`） / G 定型句（`prh`）・誇張語
  （`no-ai-hype-expressions`））はその指摘を起点に直す。
- **G の prh 指摘は削除確定ではない。** 語が文脈で実質を持つ場合（本当に多角的な比較をした直後の
  「多角的」など）は残す。文脈判断は LLM が担う。
- **textlint が拾えない構文は LLM 側で判断する**：B 長い連体修飾、C「の」連鎖の深さ・一般の名詞化、
  E 散文に戻すかの判断・見出しの過剰構造化・コロン接続、F 埋もれた列挙の箇条書き化、G 辞書外の定型句、
  H 段落レベルの言い換え反復・再要約。
  ここが meiseki の独自価値であり、textlint 設定だけでは到達できない。

### Step 5. 意味の検算（最重要のガード）
- **二重否定を肯定へ畳むときは、論理（真偽値）が反転していないか必ず確認する。**
  例：「負荷の増大を招かないとは言えません」＝「負荷が増えることがある」（肯定）。
  これを「負荷が増えない」にしたら**誤訳**であり不合格。
- 条件・例外・数値の関係が原文と一致しているかを確認する。
- **G（定型句）を削ったとき、主張の強さが原文より強くも弱くもなっていないか確認する。**
  強調語を削っても、主張の向きと述語の中身は保つ。
- **H（段落冗長）で削った文が、情報量ゼロの反復だったか一文ずつ確認する。**
  新しい含意・条件・例外を持つ文を消していたら復元する。迷ったら残す。

### Step 6. textlint を再実行し、before→after を検算する
リライト後の本文を再び Step 2 の手順で textlint にかけ、§7 のスコア(after) を出す。
- **after < before** になっていなければ直し残しがある。指摘の残った箇所に戻る。
- **A（二重否定）は原則 0 件**にする。意図的な litotes だけ例外として残す（§5 参照）。

### Step 7. やりすぎチェック（ガードレール照合）
§5 のガードレールに 1 つずつ照らし、過剰な書き換え・声の注入・トーン破壊がないか点検する。
特に「元から読みやすい文を均質に作り替えていないか」「F で太字＋コロンの定型に寄っていないか」
「G で実質を持つ語まで機械的に削っていないか」「H で情報を持つ文を反復と誤認して消していないか」。

### Step 8. 本文だけ返す
§2 の方針どおり、標準ではリライト後の本文のみを出力する。

## 5. ガードレール（やってはいけないこと）

- **意味・事実・主張・結論を変えない。** 言い換えても結論の向き・強さを保つ。
- **新しい情報・根拠・例を足さない。** 原文にない事実を補完しない。
- **声・立場・個性を足さない。** 一般論を「自分は」という意見に書き換えない／立場を言い切らせない／
  語り口を強めない。`ja-no-weak-phrase` の指摘は「曖昧で意味が取りにくいときだけ外す」用途に限り、
  立場を強める方向には使わない。（これが声を注入する `stop-ai-slop-jp` 系との決定的な差分。）
- **技術的精度を落とさない。** 易しくすると意味が変わる箇所は、語の置換ではなく**文の分割**で対処する。
  専門用語・API 名・関数名・数値・固有名詞・引用・コードは原文のまま。
- **意図的なニュアンス（litotes）は尊重する。** 控えめな肯定の含意が本質的な箇所は、安全に畳めなければ触らない。
- **元から読みやすい文は触らない。** すべてを均質に整えると無機質な「エディタ感」が出る。
- **トーンを保つ。** 常体／敬体、ブログ／技術文の質感を維持する。文体を勝手に統一しない。
- **接続詞は「重複して機械的に見えるもの」だけ削る。** 論理に必要な接続詞は残す。
  リズムを作る接続表現（「しかし一方で」など）は冗長と見なさない。
- **定型句（G）は「空虚なもの」だけ削る。** 文脈で実質を持つ語（実際に複数の観点を挙げた直後の
  「多角的」、実質のある要約を導く「要するに」など）は残す。prh の指摘は起点であって命令ではない。
  `no-ai-hype-expressions`（誇張語）の指摘も同じ扱いとする。実測や比較が本文にあり語が実質を
  持つ場合（実測値を伴う「大幅に」など）は残す。
- **段落の反復（H）は「情報量が増えない繰り返し」だけ削る。** 主張・例・根拠・例外は
  ひとつも消さない。段落分割で文の順序・論理の流れは変えない。

## 6. 最終判断基準

> **内容を知らない読者が、一度読んで正しく理解できるか。**

通読して一度で意味の取れない文が残っていれば、A→F のどれかが残っている。
逆に、読んで引っかからない文はいじらない。

## 7. 読解負荷スコア（RLS）の定義

textlint の指摘件数をカテゴリ別に重みづけし、本文の文数で正規化する。**低いほど読みやすい。**

```
RLS = Σ(カテゴリ件数 × 重み) ÷ 本文の文数 × 100
```

| meiseki カテゴリ | textlint ルール | 重み |
|---|---|---|
| A 否定の入れ子（最優先） | `no-double-negative-ja` | 3 |
| B 距離・長さ | `sentence-length`, `max-ten`, `no-doubled-conjunctive-particle-ga` | 2 |
| C 漢語・名詞化 | `max-kanji-continuous-len`, `ja-no-redundant-expression` | 2 |
| D 冗長・空虚 | `ja-no-redundant-expression`, `no-doubled-conjunction`, `ja-no-weak-phrase`, `ai-writing/ai-tech-writing-guideline` | 1 |
| E 体裁 | `ai-writing/no-ai-list-formatting`, `ai-writing/no-ai-emphasis-patterns`（＋LLM 判断） | 1 |
| F 構造化（列挙） | （LLM 判断） | 1 |
| G 定型句 | `prh`（同梱辞書 `prh-llm-phrases.yml`）, `ai-writing/no-ai-hype-expressions` | 1 |
| H 段落冗長 | （LLM 判断） | 1 |

- C と D は `ja-no-redundant-expression` を共有する。二重計上を避けるため、当該指摘は **D に寄せて 1 回だけ**数える
  （`max-kanji-continuous-len` は C 固有として数える）。
- G は `ruleId` が `prh` の指摘を数える。「〜の観点から」系（D2 と同根）と接続詞連打
  （`no-doubled-conjunction`）は D に寄せ、G と二重計上しない。
- `ai-writing/*` の指摘は次のとおり数える（二重計上の防止）:
  - 同一箇所（行と列が一致）を `prh` と `no-ai-hype-expressions` が両方拾ったら **G に 1 回だけ**。
  - 同一箇所を `ja-no-redundant-expression` と `ai-tech-writing-guideline` が両方拾ったら **D に 1 回だけ**。
  - `ai-tech-writing-guideline` の総括行（「【テクニカルライティング品質分析】…」で始まるメッセージ）は
    個別指摘の集計であり、**件数に数えない**。
- **受け入れ基準：after < before を必須**、かつ **A（二重否定）は原則 0 件**。
- 重み（特に A=3 の比率）・一文長(90字)・F の扱いは、実ドキュメントで較正して調整してよい。

## 8. textlint が拾える / 拾えないもの

- **textlint で決定論的に取れる**：A 二重否定、B 一文長・読点・逆接「が」連続、C 連続漢字・「することができる」、
  D 冗長・接続詞重複・弱い表現、E 絵文字箇条書き・リスト内の過剰太字（`ai-writing/no-ai-list-formatting`,
  `ai-writing/no-ai-emphasis-patterns`）、G 辞書収録の定型句（`prh`。「〜に他ならない」「重要なのは」
  「掘り下げる」等）と誇張語（`ai-writing/no-ai-hype-expressions`。「革命的」「ゲームチェンジャー」等）。
  - A の注意：`no-double-negative-ja` は分離型（「〜ないとは言えない」「〜は否定できない」「〜なくはない」
    「〜ないわけがない」）と丁寧形（「〜ないわけではありません」等）を拾わない。これらは同梱 prh 辞書の
    「A1 補完」セクションが検出する（`ruleId` は `prh` になるが、リライトは A の基準＝真偽を反転させずに
    肯定へ畳む＝で行う）。
- **textlint では取れない（LLM が担う）**：B 長い連体修飾、C「の」連鎖の深さ・一般の名詞化、
  E 散文に戻すかの判断・見出しの過剰構造化・英語的コロン接続（`no-ai-colon-continuation` は
  preset-ai-writing@1.1.0 に未収録）、F 列挙の箇条書き化、G 辞書外の定型句と「削るか残すか」の文脈判断、
  H 段落レベルの言い換え反復・再要約。

この「取れない部分」が meiseki の独自価値。textlint 設定だけで終わらせない。