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 を読み、高負荷箇所を特定する。

textlint の指摘のうちカテゴリ I（文字化け）は A〜H と分けて記録する。 対象は no-nfd・no-invalid-control-character・no-zero-width-spaces・no-hankaku-kana の指摘と、 prh のメッセージに「I 文字化け」を含む指摘（U+FFFD 検出）。 I はリライト対象ではなく、Step 8 で報告してユーザーに対応の要否を確認する。RLS にも数えない（§7）。

対象が Markdown 文書の場合は、同じ一時ファイルに markdownlint も実行し、before の違反一覧を記録する。 これは Markdown 構文のリグレッションガード（書き換えで構文を壊していないことの検証）に使う。

# markdownlint を実行（Skill 同梱の設定を使う。Markdown 構文のリグレッションガード）
npx --min-release-age=7 --yes --package markdownlint-cli@0.49.1 markdownlint --config "<SKILL_DIR>/references/markdownlint.config.jsonc" "<INPUT_MD>"

• textlint 用のマスキング（コードブロック除去等）は適用しない。markdownlint は生の Markdown 構造そのものを検査する。
• 違反があると終了コード 1 を返し、file:line[:column] error MD###/alias 説明 の形式で出力される。 各行の ruleId と行番号を before として記録する。
• npx が失敗した場合（オフライン等）は markdownlint をスキップして続ける（フェイルオープン。textlint と同じ扱い）。

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 が担う。
• Jev による高速判定(任意): node scripts/jev-judge.js --check が exit 0 のとき(TypeSafe API キーが設定済みのとき)、 次の文脈判断を noul 質問としてまとめて jev-judge.js に渡してよい: G(prh 指摘語がこの文脈で実質を持つか)・H(隣接 2 段落が情報量の増えない反復か)・ A(この二重否定は意図的な litotes か)。全問を 1 回の呼び出しにまとめる(バッチは単問と同じ約 250ms)。 採用は noul の確率で判定する: p ≥ 0.8 なら yes、p ≤ 0.2 なら no として採用し、 0.2 < p < 0.8 の判定だけ自分で読んで判断する(2026-10-11 の実測で、この帯なら採用判定の誤りが 0 だったため)。exit 3(キーなし)は本項をスキップ、 exit 2(失敗)は全件を自分で判断する(従来動作)。 ユーザーがキーの設定を求めたときは、この SKILL.md の 3 階層上(プラグインルート)にある scripts/jev-judge.js の絶対パスを解決し、! node "<絶対パス>" --setup の実行を案内する (! のターミナル実行ならキーが会話ログに残らない。1Password 利用者には秘密参照 op://Vault/Item/credential を貼れば平文が残らないことも伝える)。 キーの保存先は ~/.config/meiseki/ でありプラグインの設置場所と無関係のため、 プラグインの更新・再インストールでキー設定は失われない。 Jev へ送信されるのは、判定対象の文・段落の抜粋と質問文である。作業ディレクトリまたは その祖先に .meiseki-no-jev ファイルがある場合、jev-judge.js は何も送信せず exit 3 を返す。 プロジェクトの .meiseki.json でポリシーも設定できる({"jev": {"meiseki": "ask"}} なら、 セッション内で最初に使う前に AskUserQuestion で同意を得て、以後の呼び出しに --consented を付ける。 deny なら本項を黙ってスキップする)。既定は meiseki=allow(キー設定を同意とみなす)。 機密文書を扱うプロジェクトではマーカーまたは deny 設定を案内してよい。Jev を使ったセッションでは、 判定件数・呼び出し合計時間・採用率・自分で判断し直した件数を変更点報告に含める。
• 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 参照）。
• 対象が Markdown 文書の場合は markdownlint も再実行する。判定基準は 「after の違反が、before に存在しない新規違反を含まないこと」。 新規違反は書き換えで構文を壊した箇所なので、修正して再検証する。 before から存在していた違反はここでは直さない（§5「明晰化以外は触らない」原則に従う）。

Step 7. やりすぎチェック（ガードレール照合）

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

Step 8. 本文だけ返す

§2 の方針どおり、標準ではリライト後の本文のみを出力する。 markdownlint が before から検出していた既存違反があるときだけ、本文のあとに 「markdown lint 上の既存指摘」として ruleId と行番号を簡潔に添える（修正はしない）。 カテゴリ I（文字化け）の指摘があるときは、本文のあとに行番号つきで報告し、対応の要否をユーザーに確認する。 制御文字や特殊文字が意図的なケースがあるため、勝手に削除・置換しない。 U+FFFD（�）は元の文字が失われた痕跡なので、推測で復元せず正しい原文の提供を求める。

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

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

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 の総括行（「【テクニカルライティング品質分析】…」で始まるメッセージ）は 個別指摘の集計であり、件数に数えない。
• カテゴリ I（文字化け）は RLS に数えない：no-nfd・no-invalid-control-character・ no-zero-width-spaces・no-hankaku-kana、および prh のメッセージに「I 文字化け」を含む指摘（U+FFFD）。 読解負荷ではなくデータ破損の検出であり、扱いは §4 Step 8 に従う（報告のみ・ユーザー確認）。
• 受け入れ基準：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 設定だけで終わらせない。