natural-japanese 技能 | PlugMCP
跳到正文 Install The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add coji/natural-japanese --skill natural-japanese -a cursor -y Copy Download skill skills/natural-japanese/SKILL.md on GitHub 仕事の日本語文書を、自然で読みやすく、わかりやすい日本語で書く・直すためのスキル。議事録、調査レポート、顧客向けのレポート、社内ガイド、技術記事、PR の説明文、リサーチメモ、企画書、メール、スライド構成などの作成や推敲と、note やブログ、エッセイの執筆に使う。文字起こしから議事録を作るときにも使う。自然な日本語にしたい、読みやすくしたい、簡潔にしたい、結論から書きたいといった依頼のほか、読みづらい、わかりにくい、何を言っているかわからない、AI っぽい、AI 臭い、英語の直訳っぽい、日本語として不自然、違和感があるといった指摘にも使う。書き換えずに AI らしさを判定・採点してほしいという依頼や、自分の文体を学ばせたいという依頼にも対応する。
Questions
How do I install natural-japanese? Download skills/natural-japanese/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does natural-japanese live? The publisher keeps it at https://github.com/coji/natural-japanese.
Which agents can use natural-japanese? Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository. SKILL.md 简介 常见问题
仕事の日本語文書を、自然で読みやすく、わかりやすい日本語で書く・直すためのスキル。議事録、調査レポート、顧客向けのレポート、社内ガイド、技術記事、PR の説明文、リサーチメモ、企画書、メール、スライド構成などの作成や推敲と、note やブログ、エッセイの執筆に使う。文字起こしから議事録を作るときにも使う。自然な日本語にしたい、読みやすくしたい、簡潔にしたい、結論から書きたいといった依頼のほか、読みづらい、わかりにくい、何を言っているかわからない、AI っぽい、AI 臭い、英語の直訳っぽい、日本語として不自然、違和感があるといった指摘にも使う。書き換えずに AI らしさを判定・採点してほしいという依頼や、自分の文体を学ばせたいという依頼にも対応する。
name: natural-japanese
description: 仕事の日本語文書を、自然で読みやすく、わかりやすい日本語で書く・直すためのスキル。議事録、調査レポート、顧客向けのレポート、社内ガイド、技術記事、PR の説明文、リサーチメモ、企画書、メール、スライド構成などの作成や推敲と、note やブログ、エッセイの執筆に使う。文字起こしから議事録を作るときにも使う。自然な日本語にしたい、読みやすくしたい、簡潔にしたい、結論から書きたいといった依頼のほか、読みづらい、わかりにくい、何を言っているかわからない、AI っぽい、AI 臭い、英語の直訳っぽい、日本語として不自然、違和感があるといった指摘にも使う。書き換えずに AI らしさを判定・採点してほしいという依頼や、自分の文体を学ばせたいという依頼にも対応する。
license: MIT
argument-hint: "[write|score] [quick|full|exp] [対象ファイルや依頼内容]"
natural-japanese
仕事の日本語文書を、読みやすくわかりやすく書く・直すためのスキル。議事録・調査レポート・社内ガイド・リサーチメモ・スライドといった仕事の文書から、note・ブログ・エッセイまでを扱う。AI らしい書き癖を取り除くことも、この工程に含まれる。
疑わしい箇所の検出は scripts/lint.py が機械的に行い、直すかどうかはあなたが文脈を見て決める。AI は自分の書き癖に気づきにくいので、検出を機械に任せている。
いちばん大事な規則:元にない内容を足さない
既存の文書を直すときは、元の文書に書かれていない事実・数値・人名・日付・条件・評価・意見・方針を足さない。直した文書を読んだ人は、そこに書かれていることを書き手が言ったこととして受け取る。足した内容は、たとえ正しくても、書き手が言っていないことを書き手の言葉として広めてしまう。
次の変更も「足す」に当たる。
確信の度合いを変える。「次回また相談する」を「合意した」にする、「かもしれない」を「決めた」にする、逆に断定を推定に弱める
書き手の経験や見解を書き足す。「これには何度も助けられた」「筆者としては〜をすすめる」など
元にない数の枠組みを足す。「理由は3つある」「主に3種類に分けられる」など
元の数値や表の値を書き換える。誤りに見えても書き換えず、ユーザーに伝える
元にない一般論の注意や解説の段落を足す
足してよいのは、元の文書から直接言える補足だけである。略語の正式名称、用語の短い説明、文と文の関係を示す接続の言葉がこれに当たる。
例として、議事録の一文を直す場合を挙げる。
元の文:「佐藤さんが在庫回転率を使う案を出し、鈴木さんも賛成した。最終的にどう決まったかは次回また相談することになった。」
誤った直し方:「在庫回転率に変更する方針で合意した。具体案は田中が7/18までに作る。」(決定・担当・期日が元にない)
よい直し方:「在庫回転率を使う案が佐藤さんから出て、鈴木さんも賛成した。決定は次回に持ち越した。」
内容を変えずに直す例を、ほかに2つ挙げる。どちらも、言い回しだけを変え、事実と確信の度合いは元のままにしている。
plugmcp 把任意工具接入任意智能体。面向非开发者的 MCP 服务器目录；网关承载流量，n8n 承载应用。
PlugMCP, 2026
元の文:「このツールを使用することで、作業効率を大幅に向上させることができると言えるでしょう。」
直した文:「このツールを使うと、作業の効率は大きく上がるだろう。」(「と言えるでしょう」の控えめな推量は「だろう」で残し、「はずだ」のような強い見込みにはしていない)
元の文:「この事実は、従来の前提が誤っていたことを示している。」
直した文:「この事実から、従来の前提が誤っていたと分かる。」
新しく書くときも同じで、ユーザーから受け取った素材と、自分で調べて出典を示せる事実だけを使う。素材が足りないときは推測で埋めず、何が足りないかをユーザーに伝える。
実行モード 同じ工程を、かける手間の違う2つのモードで進める。
クイック(既定)は日常の文書向けで、サブエージェントを使わずにこの場で終える。参照ファイルは、文書タイプが決まったときに references/doctypes/ の1ファイルを読むだけでよい。lint は文書が短くても必ず1回実行する。短い文書では統計を使う検出器は何も出さないが、禁止語と翻訳調は一文でも検出され、実行は数秒で終わるからだ。既存の文書を直すときは、lint の出力の最後にある段落ごとの確かめ(§3)も必ず最後まで書き出す。構造の点検(§5)は、見出しと各段落の先頭文を通して読んで確かめる程度でよい。所要時間の目安は、会議メモ程度で30秒前後、1万字級でも3分程度。
フルは、ユーザーが「しっかり」「時間をかけていい」と言ったとき、対外・経営向けなど誤りの影響が大きい文書、1万字を超える文書に使う。lint に加えて outline.py と terms.py も実行し、§5 の構造と読みやすさの点検をすべて行う。
サブエージェントは、長い文書を分担して読むと速くなる場合にだけ使い、見つかった問題を直すかどうかは自分で決める。執筆そのものは分担しない。濃淡や章どうしのつながりは、文書全体を見ないと保てないためだ。
所要時間の目安は、短い文書で7分前後、1万字級で15〜20分なので、始める前にユーザーに伝える。effort を選べる環境なら high を使う。effort を低くすると、フルの工程を理由をつけて省きやすくなることを実測で確かめている。
どちらにするか迷ったら、クイックで仕上げ、「フルで見直すこともできる」とユーザーに添える。
呼び出し方 スキルが引数つきのコマンドとして呼ばれたら、次のように解釈する。
/natural-japanese [quick|full] <対象>:書く・直す(既定)。新しく書くのか、既存の文書を直すのかは対象から判断する/natural-japanese write [quick|full] <お題や素材>:新しく書く。§1 から順に進める/natural-japanese score [quick|full|exp] <ファイル>:診断だけを行い、文書は書き換えない。最初に references/diagnose.md を読む。スコアの算出式と出力の形式はそこにだけ書いてある。診断のあとでリライトを提案してよいが、頼まれるまで直さない モードの指定がなければ、上の基準で選ぶ。自然な言葉での依頼も同じように扱う(「〇〇について書いて」は write、「この文章 AI っぽい?」は score)。
1. 書く前に決める
読み手と目的 誰が読み、読んだあとに何が起きてほしい文書かを決める。分からなければユーザーに聞く。文書タイプが次のどれかなら、対応するファイルを読む。そこに、その文書タイプの必須要素と、AI がやりがちな失敗がある。
議事録:references/doctypes/minutes.md
調査レポート・分析レポート:references/doctypes/report.md
社内ガイド・マニュアル:references/doctypes/guide.md
リサーチメモ・ディスカッションペーパー・企画書:references/doctypes/memo.md
スライド構成:references/doctypes/slide.md
主メッセージと見出し 本文の前に、主メッセージを一文で書く。書けないなら、素材が足りていない(→素材)。
見出しには、「背景」「まとめ」のようなラベルでなく、その節の結論を書く。見出しだけを順に読んで論旨が通るかを確かめてから本文に進む。結論が条件つきで、見出しに収まらない節では、条件を落とした結論を書かず、話題を示す見出しにする(§3)。ただし、全部の見出しを「名詞: 結論文」の同じ形にそろえない。同じ形が並ぶと、それ自体が機械的に見えるためだ。短い節はラベルのままでよい。見出しで、本文より確信の度合いを上げない。本文が「予定」と書いていることを、見出しで断定しない。読み手は見出しだけを読んで判断することが多いので、見出しの断定は本文の留保より強く伝わる。
濃淡 重要な節は厚く、軽い節は短く書く。どの節も同じ厚み・同じ文型で書くと、内容に軽重があっても読み手には区別がつかない。書く前に論点を並べ、それぞれにどれだけ書く価値があるかを決めておく。
濃淡は分量の差であって、順位づけではない。もともと並列な項目に「最優先・次点・後回し」のような順位や段階を付けない。内容がもともと順序を持っているときだけ、順序を書く。
素材(新しく書くとき) 固有名詞・数値・実例が手元にないまま書くと、一般論だけの段落になる。主張を、固有名詞・数値・具体的な出来事を使わずに説明できてしまうなら、素材が足りていない。
Web 検索が使えるなら、まず仮の主張と根拠を立て、検索で裏づけるか崩してから、主張を組み直す。これを1〜2回行う。使えないなら、ユーザーに具体例・数値・一次情報があるかを聞く。ユーザーに素材がなければ、内容が一般的になることを伝えて進めてよい。
文体プロファイル(任意) style-profile.md(プロジェクトのルートか、ユーザーが指定した場所)があれば読み、視点・語彙・リズムの癖を踏まえて書く。なければ汎用の書き方で進める。ユーザーが「自分の文体を学ばせたい」と求めたときだけ、assets/style-profile-template.md に沿って過去の文章3〜5本から特徴を抜き出し、プロファイルを書き出す。特徴は断定せず「傾向として」と書く。ユーザーが特定の語や組み合わせを「自分は使わない」「不自然」と言ったときは、一般の規則に広げず、出典と適用範囲を添えてプロファイルの「避ける表現」に記録する。単語全体を禁じず、指摘された組み合わせだけを記録する。
2. 書くときの原則 新しく書くときは、次の原則に沿う。既存の文書を直すときは、§3 で直すと決めた箇所に、元の文書にある内容の範囲で当てる。原則を満たすために内容を足してはいけない。たとえば、元の文書に「次にすべきこと」が書かれていないなら、原則12のために書き足さない。とくに、確信の度合い(原則10)と、事実と意見の区別(原則11)は元の文書のとおりに保ち、表し方だけを変える。「〜と思われます」を「〜と推定する」にするのはよいが、断定に変えてはいけない。原則どうしがぶつかったら、読み手の理解を実際に助けるほうを選ぶ。
結論を先に書く。「本稿では〜について解説する」のような前置きは、読み手に何も伝えない。結論はタイトルか最初の一文に置き、長い文書ではその直後に結論と主な数値を数文でまとめる。
見出しには節の結論を書く(§1)。
因果や経緯は地の文で書く。箇条書きにすると、項目どうしの「だから」「しかし」が消え、その関係を読み手が補うことになる。箇条書きは、担当と期日の並んだ宿題の一覧のように、項目が本当に独立して並ぶときに使う。たとえば「・在庫が減った ・通知が出た ・担当が見落とした ・欠品した」の背後に「通知は出たが見落とした」という関係があるなら、「在庫が減って通知は出たが、担当が見落として欠品した」と書く。関係が元の文書や素材にないなら、関係を足さない。
専門用語は、何をするものかを先に説明してから名前を出す。読み手は、知っている現象に結びつけてから名前を受け取るほうが覚えやすい。初出に括弧で短い説明を添えるだけでもよい。
抽象的な主張は、固有名詞・数値・実例で支える。素材がないときは推測で埋めず、何を確かめれば書けるかを書いて空けておく。
太字は、文書全体で本当に目立たせたい箇所だけに使う。段落ごとに太字を置くと、どこも強調に見えなくなる。絵文字や記号でも飾らない。仕事の文書では、飾りは情報を増やさず、読み手の目を散らすだけだからだ。
濃淡をつける(§1)。
同じ型を3回続けない。定義文の型、節の中の組み立て、文の書き出しが3回続いたら、少なくとも1つは変える。最初に選んだ構造を繰り返すほうが書きやすいので、この癖は最後まで残りやすい。変えるときは、文の順序や主語を入れ替える、2文を1文にまとめる、のように内容に合わせて変える。疑問形や体言止めを、型を崩すための手段として入れない。
打ち消し(「〜ではなく〜」「〜ではない。〜だ。」「〜わけではない」)は、読み手が実際に誤解していそうな場面と、事実や注意として要る場面だけで使う。言い換えや強調のために打ち消すと、内容より構文が目立つ。とくに GPT 系のモデルは、誰も言っていない思い込みを先回りして打ち消す文を多く書く(§3)。
確信の度合いは語尾でぼかさず、書き分ける。断定できることは断定し、推定は「〜と推定する」、未確認は【要確認】と書く。「〜と思われます」を全体に散らすと、どこが確かでどこが不確かかが読み手に分からなくなる。
事実と意見を分ける。事実には出典やデータを添え、意見には「筆者は〜と考える」のように話し手を示す。どちらも「〜だ。」で書けてしまうので、文末だけでは区別がつかない。出典を示せない事実は、事実として書かない。
結びでは本文の要約を繰り返さず、要点を1〜2文にまとめる。調査レポートでは、結果から次に何をすべきかを書く。次にすべきことは、素材やユーザーの考えから書く。素材から自分で導いた提案を書くときは、提案であることが分かるように書く(「〜を提案する」)。根拠が支える範囲を超えた提案はしない。ガイドや議事録のように次への導線が別にある文書では、結びの段落自体が要らないこともある。
文の整え方は次のとおり。です・ます体とである体は、文書の中でそろえる。一文に主張は一つにする。一文の長さは50〜60字を目安にするが、主体や語の関係を明示したために長くなった文を、長さだけを理由に削らない。修飾語は長いものを先に、短いものを後に置く。主語と述語はできるだけ近づける。
文書のジャンルによって、原則の当てはめ方を変える。技術文書は一文一義と用語の統一をもっとも厳しく守る。ビジネス文書は結論を冒頭に置く構成を優先する。エッセイは、言い切らずに余韻を残す、結論を後に置く、といった逸脱を書き手の意図として認める。公用文や、専門知識のない一般の読み手に向けた文書は、一文を短くし、外来語と二重否定を避け、主語を明示する。
3. 既存の文書を直すとき 直し方は、文書を人が書いたか AI が書いたかで変えない。文章から見分けるのは難しく、新しいモデルが書いた文書は lint の指摘も少ないためだ。直すものを、いつでも直すもの、理由があるときだけ直すもの、どの文書でもしないもの、の三つに分ける。
いつでも直すもの
演出や誇張の言葉。削るだけで外す(次の項)
lint が指摘した言い回し。直し方は各指摘に書いてある
不要な打ち消し(次の項)
読み手の手間を増やしている箇所。次の5つは、内容を足さずに直せるので直す
冗長な言い回し。情報を増やさずに字数だけを増やしている言い回しを縮める(「〜という形で進めていく予定です」を「〜で進める予定です」にする)
主張が二つ以上入った文。主張ごとに分ける
何の一覧か、何の話かが後になってから分かる列挙や段落。元の文書の言葉で、先に枠を示す(列挙のあとに「〜といった点に注意した。」とあるなら、列挙の前に「注意したのは次の点だ。」と置く)
「〜について」のように、中身が分からない見出し。本文にある言葉で、その節に何が書いてあるかが分かるようにする。全部の見出しを同じ形にはしない
文書の鍵になる用語で、説明がないもの。元の文書から言える範囲で、初出に短い説明を添える(「SLA(サービスの品質を保証する取り決め)」)
読み手が「具体的に何のこと?」と止まる言い回し(次の項)
読み手の手間を増やしている箇所は、lint ではほとんど検出されない。文書を通して読むだけだと「もう読みやすい」と判断して見落とすので、段落ごとに確かめる。lint の出力の最後に「段落ごとの確かめ」として、見出し・箇条書きの1項目・表の1行・地の文の段落が、番号と行番号つきで並ぶ。すべての段落について、上の5種類と、読み手が何のことか取れない言い回し(次の項)に当たるものを「番号: 言い回し → 指しているもの」の形で書き出す。当たるものがない段落は「番号: なし」と書く。最後の段落まで書き出すまで直し始めない。クイックモードでも省かない。書き出した箇所を直し、lint の指摘と同じように、直したか、残したならその理由を記録する(§4)。同じ一覧は uv run scripts/paragraphs.py <file> でも出せる。
見出しや、元の文書にある冒頭の要約を直すときは、本文の条件を落とさない。条件の消えた結論は、元より強い主張になる。本文が「年間契約で、月の利用が100回を超えるユーザーは割引の対象になる」と言っているなら、冒頭を「よく使うユーザーは割引になる」にしない。冒頭の要約には条件も書き、長くなるなら2文に分ける。見出しは短くないと読めないので、条件なしで言える結論だけを見出しにし、条件が込み入った節では「割引の対象」のように話題を示す見出しにとどめる。
これ以外の言い換えはしない。lint が指摘していない言葉を、より自然そうな言葉に置き換えない(「気軽に試せます」を「簡単に試せます」に、「お知らせいたします」を「お知らせします」にしない)。
読み手が何のことか取れない言い回しは、ふだんの言葉に戻す AI の書いた文章には、比喩や言い換えで中身をぼかした言い回しが混ざる。書いた側は正確な中身を持っているのに、ゆるい言葉や英語の直訳で書くので、読み手は元の中身を推測し直すことになる。書いたモデル自身はこれを自然だと感じるので、文書を通して読むだけでは見落とす。技術記事や PR の説明文のように、コードの動きを説明する文章で特に多い。
見つけるときは、段落ごとに区切り、その段落の動詞と名詞をすべて見て、「この語が指している具体的なものを、元の文書やコードにある事実・名前で言えるか」と問う。言えるのに、それより読み方の広い言葉で書いているなら、次のどれかに当たる。当たるものを直す。
中身が見えない言い回し。何がどうなるのかを比喩で言っていて、読み手が「具体的に何のこと?」と止まるもの(「この変更はチームの重心を移す」)。比喩でなくても、意味が取れない言い回しは同じに扱う
すでに名前のあるものの言い直し。コードの動作、列や状態、同じ文書で前に使った語を、読み方が1つに決まらない言葉で呼び直したもの(「支払いの済んでいない注文が宙に浮く」の「宙に浮く」は、支払い待ちのまま残るのか、どこからも参照されなくなるのか決まらない)。同じ文書の中で、一度名前を付けたものを別の言葉で呼ばない。読み手は別のものを指していると受け取る
擬人化。人でないもの(ファイル、データ、市場、仕組みなど)を、人や生き物のように扱う言い方(「設定ファイルが育っていく」「データが語っている」)
英語の言い方の逐語訳。日本語ではふつうそう言わないもの(low-hanging fruit の「低くぶら下がった果実」、break の「既存の利用者を壊す」、source of truth の「真実の源」)。技術者がよく使う言葉でも、英語の言い方を1語ずつ置き換えたものはこれに当たる。素材にふつうの言い方があれば、それを使う
語の組み合わせがずれているもの。名詞と動詞の組み合わせが、ふだんの日本語にない(「期限が終了する」は「期限が切れる」、「リスクを踏む」は「リスクを負う」)。和語を漢語に置き換えたときに起きやすい
エンジニアの話し言葉を、そのまま書き言葉に持ち込んだもの(「ログを吐く」「サーバーが死ぬ」「処理を別のキューに投げる」)。会話では通じても、文書では何をするのかがぼやける。「出力する」「止まる」「渡す」のように、動作をそのまま書く
動作を名詞にまとめて、誰が何をするかが消えたもの(「重複登録が起きうる点の対処」は、何をどう直すのかが分からない。「同じ利用者が二重に登録されないように直す」と書く)
4、5、7は、書いたモデルにも読み直すモデルにも自然に見えるので、読んだ印象では見つからない。次の手を動かす確かめ方で見る。
英語に訳し戻す。漢語の熟語や、ふだんの言葉で技術の動きを言っている箇所は、英語にしてみる。英語の決まった言い方を1語ずつ置き換えた形になっていたら、4に当たる(「一級市民として扱う」は first-class citizen、「優雅な劣化」は graceful degradation、「端のケース」は edge case)。その分野で日本語として定着した訳語(「依存性の注入」など)は除く
名詞の文を動詞の文に書き直してみる。「〜は未着手です」「〜の対応」「〜の検討」のように動作を名詞にまとめた箇所は、誰が何をどうするかの文に書き直す。書き直した文のほうが、何をするのかがはっきりするなら、7に当たる(「権限の整理は未着手です」は「権限を誰に付けるかは、まだ決めていません」と書ける)
名詞と動詞の組み合わせを、ふだんの会話で言うかで確かめる。言わない組み合わせなら5に当たる。和語を漢語に置き換えた箇所(「消える」を「消失する」に、「切れる」を「失効する」に)は特に確かめる
イメージが具体的に浮かび、ふだんの仕事の文章でも使う言い方(「目を通す」「手を打つ」「腰を据える」など)は直さない。定着した慣用句、発言者の言葉の引用、その分野の用語として定着した使い方も直さない。技術の言い方として定着していて、読み方が1つに決まるもの(「キャッシュが効く」)も直さない。ただし、定着しているかは、仕様書やリファレンスのような書き言葉で使うかで決める。エンジニアどうしの会話でよく使うだけでは、定着しているとは見ない。同じ語でも、読み方が決まらない使い方なら直す。同じ文の中に中身が書いてある比喩(「バックアップを毎晩取っているので、データは守られる」)も直さない。1つの段落に違和感のある言い回しが続くと、読み手は「どういうこと?」を積み重ねて読む気をなくすので、1か所だけでなく段落の中のものをまとめて見る。
比喩が言っていた中身を、ふだんの言葉で書く。使ってよいのは、元の文書に書いてあることだけ(「設定ファイルが育っていく」を「設定ファイルに項目が増えていく」にする。「低くぶら下がった果実から取る」を「すぐできるものから手を付ける」にする)
すでに名前のあるものは、その名前で書く。コードの動作なら、何を取り出し、どの列に何を入れ、何を実行しないのかを書く。素材やコードにふつうの言い方があれば、それに戻す
含み(評価の向きや強さ)と意味の広さを変えない。文の種類(事実・意見・提案・仮定・伝聞)と確信の度合いも変えない
硬い漢語に置き換えない。「育っていく」を「拡充される」にすると、別の不自然さになる
AI の書いた比喩は、書いた本人にも中身がないことがある。前後の文脈から読み方が一つに絞れるなら、その読み方で直し、どう読んだかを報告に必ず添える(「『重心を移す』を、前後の担当表から『担当の範囲を変える』と読んで直した。優先順位を変えるという意味なら、そう直す」)。ユーザーは、直した文と添えた読み方を見て、違えば選び直せる
文脈から読み方が絞れないとき(二通り以上が同じくらい成り立つとき)は、直さない。読み方の候補を挙げて、どれにするかをユーザーに聞く
打ち消しは、中身のあるものだけを残す 打ち消しには三つの種類があり、扱いを分ける。lint の negation_repetition と antithesis_repetition が、多用を指摘する。
誰も言っていない思い込みを、先回りして打ち消す文。「〜するだけで自動的に〜わけではない」の形が多い(「ただし、CI を入れれば、自動的にバグがなくなるわけではありません。」)。言いたい中身は次の文にあることが多いので、文ごと削る。削ると次の文がつながらないときは残す
打ち消してから言い直す、「AはBではない。Cだ。」の形。打ち消しの部分を削り、主語を肯定の文につなぐ。新しい言葉は足さない
よい例:「コードレビューは、粗探しの場ではありません。設計の意図をチームで共有する機会です。」を「コードレビューは、設計の意図をチームで共有する機会です。」にする
中身のある打ち消し。あいまいな言葉の意味を絞る(「ここでいう『軽い』は、ファイルの大きさではなく、起動するまでの時間のことだ」)、誤解されやすい事実を示す(「SQLite は、別のプロセスとして動くデータベースサーバーではありません」)、注意として要る(「環境変数に入れたという理由だけで、秘密が守られるわけではありません」)。これらは残す。違いを説明する対比(「ファイル全体を送り直すのではなく、変わった部分だけを送る」)も、削ると説明が成り立たないので残す
演出の言葉は、削るだけで外す AI が書いた文章には、内容を足さずに調子だけを強める言葉がよく混ざる。誇張(「徹底的に」「例外なく」「劇的に」)、場面や体の反応の大げさな描写(「警告音が頭の中で鳴り続ける」「背筋が凍る」)、読み手への呼びかけ(「あなたにも経験がないだろうか」)などである。
これらは、削っても文が同じことを言えるときだけ削る。言い換えたり、別の言葉で補ったりはしない。「圧倒的に多くの利用者」は「多くの利用者」にし、「非常に多くの利用者」にはしない。新しい言葉や文を足すと、そこに別の演出が入りやすいためだ。削ったら、残った文が文法的に成り立つかを確かめ、成り立たないなら削らずに残す。たとえば「〜の放棄に他ならない」から「他ならない」だけを削ると、文が壊れる。事実を含まない感情だけの一文(「……背筋が凍った。」)は、文ごと削ってよい。
よい例:「設定ファイルの書き方を徹底的に解説する。」を「設定ファイルの書き方を解説する。」にする(「徹底的に」を削るだけ)
よい例:「テストのないプロジェクトは、例外なく保守が難しくなる。」を「テストのないプロジェクトは、保守が難しくなる。」にする(「例外なく」を削るだけ)
してはいけない例:「『どの設定が使われているのか』『どこを直せばよいのか』が一切わからない。」を「どの設定が使われているのか。どこを直せばよいのか。手がかりは何もない。」にする。問いを短い文に割り、元にない決め台詞(「手がかりは何もない。」)で締めていて、演出を外すどころか足している
エッセイなど、書き手が語り口を意図していることをユーザーが示しているときは、この直しはしない。
理由があるときだけ直すもの 箇条書きと地の文の入れ替え、段落の組み直し、見出しの数や順序の変更といった構成の直しは、ユーザーが頼んだとき、または直さないと読み手が内容を取り違える・探せないと具体的に言えるときだけ行う。同じ種類の変換を全項目に当てると、元の文書にあった自然な不揃いが消え、かえって機械的に見えるためだ。ブラインド評価では、全部の見出しを結論に書き換えた改稿が、読み手にとっての価値では元の文書に勝ったのに、人間が書いたように見えるかでは負けた。
構成を直すなら、着手前に元の文書の見出しと節を並べ、それぞれを keep か change に分ける。既定は keep。change が全体の3割を超えるなら、その理由を記録する(§4)
見出しを結論に書き換えるのは、開いて中身を探す手間が大きい2〜3か所までにする
箇条書きを地の文に戻すのは、因果や経緯が隠れているものだけにする。助言の一覧や宿題のように、あとから特定の項目を探す箇条書きはそのまま残す
行を並べた書き方を、頼まれずに箇条書きに変えない
文を分けるときは元の文の言葉を使い、文と文のあいだに、元にない接続の言葉(「しかし」「ただ」「その結果」「そこで」「そのため」)を足さない。元の文にあった「〜が」「〜ので」「〜ため」は使ってよい。
どの文書でもしないこと
元にない内容を足す(冒頭の規則)。書き手の見解や方針を書き足すこと、「未定」を断定に変えることも含む。内容のないつなぎの文(「以下で詳しく見ていきます。」)も足さない。元の文書の言葉で次に来るものの枠を示す文は、これに当たらない
元の文書にない要約の節(「この文書の要点」「まとめ」など)を新しく足す。結論や要点がどこにあるかは元の文書の組み立てのとおりにし、冒頭に置いたほうが探しやすいと思ったら、そうすることをユーザーに提案する。列挙の前に一文で枠を示すこと(「いつでも直すもの」)は、これに当たらない
主語のない文に、誰のことかを補う。とくに議事録では、発言や行動の主を取り違えると記録として誤りになる。誰のことか分かりにくい箇所は、補わずにユーザーに伝える
数字を変える。元の文書の数字が食い違っていても(「次の3点」と書いて4つ並べている)、直さずにユーザーに伝える
一般論しか言えていない段落に、自分で具体例や数値を足す。どんな素材があれば具体的にできるかを、ユーザーに伝える
主張・例・根拠・例外・条件を消す。削るのは、情報の増えない繰り返しだけにする。新しい含意(条件や帰結)を持つ文は、似ていても繰り返しではない。迷ったら残す
文書タイプの必須要素が欠けているとき、定型文で埋める。その文書に本当に要るかを考え、要るなら元の文書の中身で書く。中身がなければユーザーに聞く
書き手の癖を均す。話し言葉の引用(「それ先に言ってよ」など)、敬語の度合い(「いたします」「させていただきます」)、絵文字や顔文字、矢印や略記、表記の癖、改行で区切る書き方(行をつないで一文にしない)、節ごとの不揃いは、読解を妨げていない限り残す。こうした痕跡を均すと、誰が書いたのか分からない文書になる
4. lint で機械的に検出する uv run scripts/lint.py --json <file>
禁止語・翻訳調・「〜ではなく」の多用・文の長さの単調さ・体言止めがまったくないこと・語彙の使い回し・英語の構文の直訳などを検出する。文書のジャンルが分かっているなら --genre essay|tech|business を付けると、そのジャンルに合わせた閾値になり、誤検出が減る。
lint の指摘は疑いであって、全部直せという指示ではない。各指摘の説明に、何を疑っているかと直し方が書いてある。文脈に照らして、直すか残すかを決める。迷ったら、その一文を声に出して読み、人が話すときの言い回しに近いかで決める。
指摘ごとに、直したか、残したならその理由を一言で記録しながら進める。理由は「固有名詞の一部」「文脈上必要」「技術用語」「ジャンル上自然」などでよい。理由のない「残す」は、判断していないのと同じなので避ける。記録は応答の中に書けば足りる。ファイルにする場合は §7 に従う。
- [直した] translationese「〜という点で」: 「〜では」に言い換えた
- [残す/固有名詞] forbidden_phrase「多角的」: 製品名「多角的レビュー機能」の一部
uv が使えない環境(Claude.ai など)では、references/manual-checklist.md の手順で同じ観点を目で確かめる。
scripts/semantic.py は、隣り合う文の意味の似かたから話題の平板さを測る実験的な検出器で、任意で使う。初回に約1GBのモデルをダウンロードするので、フルモードで環境が許すときだけ uv run scripts/semantic.py --json <file> を実行し、指摘は lint と同じように扱う。
5. 構造と読みやすさを点検する lint が見るのは文の表面だけである。箇条書きの多い議事録やスライドでは、lint はほとんど何も検出しないので、構成は別に点検する。
構造の点検 見出しと各段落の先頭文だけを順に読み、次を確かめる。uv run scripts/outline.py <file> で、見出し・各段落の先頭文・箇条書きを行番号つきで抜き出せる。
見出しと先頭文だけで論旨が追えるか
各見出しが結論を言っているか
同じ型(定義文の型、節の組み立て、書き出しの文型)が続いていないか
節ごとに濃淡があるか
読み手が知りたい結論を、後半まで待たせていないか。事実の説明とは別に、「思い込み→異変→種明かし→回収」のような筋書きを追わせていないか。経緯そのものが証拠になる障害調査や、発見の過程を書くエッセイでは、時系列を残してよい
結びが次にすべきことにつながっているか(新しく書くレポートの場合。直す場合は、元の文書に書かれているときだけ見る)
文書タイプが決まっていれば、doctypes のファイルにある必須要素と、AI がやりがちな失敗も照らし合わせる。
読みやすさの点検 uv run scripts/lint.py --reading-load <file> で、読みにくそうな箇所(長すぎる文、文に埋もれた列挙、続きすぎる漢字、二重否定、「の」の連続、「〜することができる」)を指し示せる。これは AI らしさの検出とは別の検査で、自然度のスコアにも --baseline の比較にも入らない。指し示された文は、読み手の手間を増やしているなら直す(§3)。
次の順に確かめる。前のものほど、読み手にかかる負担が大きい。
否定と条件の入れ子。二重否定や、入れ子になった条件を素直な形にする。畳んだら、真偽と条件の対応が元の文と同じかを必ず確かめる。「設定が無効でない限り」と「設定が有効なら」は、未設定のときの扱いが違う。書き手が意図して断定を避けている箇所は、意味を変えずに畳めないなら触らない
係り受けの距離。一文に主張が二つ以上あれば分ける。主語と述語が離れてねじれていないか、長い修飾語が先に来ているかを見る。読点は、文の構造の切れ目に打つ。「〜が、〜が、」と続く文は分ける。「これ」「それ」が何を指すか、直前の文から一つに決まるかを見る
語の重さ。漢字が7字以上続くと語の切れ目が見えにくくなるので、ひらがなを交えて開く。「の」が3つ以上続く箇所や、「〜の実現」「〜への寄与」のように動作を名詞にした箇所は、誰が何をするかが見えにくいので、動詞に戻す。受け身が続いて動作主が見えなければ、動作主を出す。読み手によって意味の取り方が変わるカタカナ語は、和語や漢語に言い換える
冗長な言い回し。「〜することができる」は「〜できる」に、「〜という形になる」は「〜になる」にする。情報を増やさずに字数だけを増やしている言い回しなので、削るだけで、足さない
段落。改行のない長い塊はどこで区切って読めばよいか分からず、一文ごとの細切れはつながっている論理を切ってしまうので、どちらも避ける
文に埋もれた列挙。同格の項目が3つ以上あり、一文が長くなっているときだけ、箇条書きに開く。各項目を「太字: 説明」の形にすると、それ自体が AI の書いた文書の典型的な見た目になるので避ける
段落をまたぐ繰り返し。同じことを言い換えて繰り返している段落は、情報が増えない部分だけを削る(§3)
表記ゆれ。同じものは同じ表記にする。uv run scripts/terms.py <file> で、専門用語の初出の位置と説明の有無を一覧にできる
構成と読み手の知識。結論が最後まで出ない構成と、説明のないまま使われる専門用語を直す
短くすること自体は目的にしない。まず、必要な事実が残っているか、主語と述語・修飾語と被修飾語が対応しているかを確かめる。その二つが同じくらいの候補どうしでだけ、短いほうを選ぶ。文を分けたり列挙を開いたりして字数が増えるのは、正しい結果である。
6. 収束と仕上げ 直した箇所を反映したら lint をもう一度実行する。直前の --json 出力を --baseline に渡すと、指摘が resolved・new・persisting に分かれるので、new と persisting だけを見ればよい。すべての指摘が「直した」か「残す(理由)」に分かれ、直したことで新しい指摘が出ていなければ、収束とする。回数は決めず、この状態になったら終える。
同じ指摘が2回続けて再発するなら、言い換えを重ねても収束しない。文や段落の組み立てごと書き直すか、理由をつけて残す。
収束したら、仕上げに、直した文書を元の文書と並べ、元にない事実・数値・評価・方針が入っていないかを確かめる(冒頭の規則)。新しく書いた文書なら、素材にない事実がないかを確かめる。新しく書いた文書でも、書いたモデル自身が自然だと感じる言い回しで中身をぼかしやすい(「三つの論点が浮かび上がる」のように、名詞を主語にして中身を言わない書き方など)。§3「読み手が何のことか取れない言い回しは、ふだんの言葉に戻す」の見つけ方で、段落ごとに確かめて直す。
既存の文書を直したときは、次のコマンドで、直した文書にだけある数値・固有名詞・英字の語を一覧にできる。元の文書が別のファイルとして残っていれば、それと比べる。git で管理しているファイルを直接書き換えたなら、--git を付けると直前のコミットの内容と比べられる。どちらでもなく、git で管理していないファイルを直接書き換えるときだけ、直す前に元の文書を作業用のディレクトリへ写しておく(§7)。
uv run scripts/newfacts.py <元の文書> <直した文書>
uv run scripts/newfacts.py --git <直した文書>
拾った語が元にない事実なら、削るか元の内容に戻す。略語の正式名称のように、元の文書から直接言える補足なら残してよい。このスクリプトが拾えるのは新しく出てきた数値・固有名詞・英字の語だけで、普通の名詞で足した細部、確信の度合いの変化、発言者の入れ替えは拾えない。何も出なくても、自分の目での確認は省かない。
7. 後片付け 作業中に作った中間ファイル(lint の JSON、対応の記録、元の文書の写し、下書きの控えなど)は、対象の文書と同じディレクトリに置かない。環境のスクラッチパッドがあればそこに、なければ mktemp -d で作った一時ディレクトリに置く。完了したら一時ディレクトリごと削除する。作業用のファイルがユーザーのプロジェクトに混ざらないようにするためである。ユーザーのプロジェクトに残すのは、完成した文書と、ユーザーが明示的に望んだ場合の style-profile.md だけである。
How do I install natural-japanese? Download skills/natural-japanese/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does natural-japanese live? The publisher keeps it at https://github.com/coji/natural-japanese.
Which agents can use natural-japanese? Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.