Meiseki

meiseki — 日本語明晰化スキル

1. 狙いの宣言

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

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

2. 出力方針

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

3. 対象 / 対象外

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

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

Step 1. 全文を読み、意味を把握する

事実・主張・結論・前提条件を正確に取る。意味を取り違えると明晰化は台無しになる。 特に否定・条件・係り受けの論理構造を頭の中で確定させる。

Step 2. textlint を実行する（決定論層）

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

# 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

• 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 設定だけで終わらせない。