natural-japanese

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha b721e2a86d02 · 20 Oct 2026Report an issue or request a re-scan

• Publishercoji GitHub userOwner of the repository this skill is read from
• Source foldercoji/natural-japanese/skills/natural-japaneseThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdictb721e2a86d02A new audit runs when the source changes
• Repository statusNot archivedLast push 4 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: 仕事の日本語文書を、自然で読みやすく、わかりやすい日本語で書く・直すためのスキル。議事録、調査レポート、顧客向けのレポート、社内ガイド、技術記事、PR の説明文、リサーチメモ、企画書、メール、スライド構成などの作成や推敲と、note…

---
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つ挙げる。どちらも、言い回しだけを変え、事実と確信の度合いは元のままにしている。

- 元の文:「このツールを使用することで、作業効率を大幅に向上させることができると言えるでしょう。」
- 直した文:「このツールを使うと、作業の効率は大きく上がるだろう。」(「と言えるでしょう」の控えめな推量は「だろう」で残し、「はずだ」のような強い見込みにはしていない)
- 元の文:「この事実は、従来の前提が誤っていたことを示している。」
- 直した文:「この事実から、従来の前提が誤っていたと分かる。」

新しく書くときも同じで、ユーザーから受け取った素材と、自分で調べて出典を示せる事実だけを使う。素材が足りないときは推測で埋めず、何が足りないかをユーザーに伝える。

## 実行モード

同じ工程を、かける手間の違う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. 結論を先に書く。「本稿では〜について解説する」のような前置きは、読み手に何も伝えない。結論はタイトルか最初の一文に置き、長い文書ではその直後に結論と主な数値を数文でまとめる。
2. 見出しには節の結論を書く(§1)。
3. 因果や経緯は地の文で書く。箇条書きにすると、項目どうしの「だから」「しかし」が消え、その関係を読み手が補うことになる。箇条書きは、担当と期日の並んだ宿題の一覧のように、項目が本当に独立して並ぶときに使う。たとえば「・在庫が減った ・通知が出た ・担当が見落とした ・欠品した」の背後に「通知は出たが見落とした」という関係があるなら、「在庫が減って通知は出たが、担当が見落として欠品した」と書く。関係が元の文書や素材にないなら、関係を足さない。
4. 専門用語は、何をするものかを先に説明してから名前を出す。読み手は、知っている現象に結びつけてから名前を受け取るほうが覚えやすい。初出に括弧で短い説明を添えるだけでもよい。
5. 抽象的な主張は、固有名詞・数値・実例で支える。素材がないときは推測で埋めず、何を確かめれば書けるかを書いて空けておく。
6. 太字は、文書全体で本当に目立たせたい箇所だけに使う。段落ごとに太字を置くと、どこも強調に見えなくなる。絵文字や記号でも飾らない。仕事の文書では、飾りは情報を増やさず、読み手の目を散らすだけだからだ。
7. 濃淡をつける(§1)。
8. 同じ型を3回続けない。定義文の型、節の中の組み立て、文の書き出しが3回続いたら、少なくとも1つは変える。最初に選んだ構造を繰り返すほうが書きやすいので、この癖は最後まで残りやすい。変えるときは、文の順序や主語を入れ替える、2文を1文にまとめる、のように内容に合わせて変える。疑問形や体言止めを、型を崩すための手段として入れない。
9. 打ち消し(「〜ではなく〜」「〜ではない。〜だ。」「〜わけではない」)は、読み手が実際に誤解していそうな場面と、事実や注意として要る場面だけで使う。言い換えや強調のために打ち消すと、内容より構文が目立つ。とくに GPT 系のモデルは、誰も言っていない思い込みを先回りして打ち消す文を多く書く(§3)。
10. 確信の度合いは語尾でぼかさず、書き分ける。断定できることは断定し、推定は「〜と推定する」、未確認は【要確認】と書く。「〜と思われます」を全体に散らすと、どこが確かでどこが不確かかが読み手に分からなくなる。
11. 事実と意見を分ける。事実には出典やデータを添え、意見には「筆者は〜と考える」のように話し手を示す。どちらも「〜だ。」で書けてしまうので、文末だけでは区別がつかない。出典を示せない事実は、事実として書かない。
12. 結びでは本文の要約を繰り返さず、要点を1〜2文にまとめる。調査レポートでは、結果から次に何をすべきかを書く。次にすべきことは、素材やユーザーの考えから書く。素材から自分で導いた提案を書くときは、提案であることが分かるように書く(「〜を提案する」)。根拠が支える範囲を超えた提案はしない。ガイドや議事録のように次への導線が別にある文書では、結びの段落自体が要らないこともある。

文の整え方は次のとおり。です・ます体とである体は、文書の中でそろえる。一文に主張は一つにする。一文の長さは50〜60字を目安にするが、主体や語の関係を明示したために長くなった文を、長さだけを理由に削

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

uv run scripts/lint.py --json <file>
uv run scripts/lint.py --reading-load <file>
uv run scripts/newfacts.py <元の文書> <直した文書>
uv run scripts/newfacts.py --git <直した文書>
uv run scripts/lint.py scripts/fixtures/ai-smelly.md --json
uv run scripts/lint.py scripts/fixtures/natural.md --json

git clone https://github.com/coji/natural-japanese
git -C natural-japanese checkout b721e2a86d02

Works in

1. 2026-10-20
   ✓SAFE B 89 / 100

   first audit · source b721e2a86d02

Questions about natural-japanese

• github.com/coji/natural-japanese/tree/main/skills/natural-japane — the audited source at commit b721e2a86d02 and every finding aboveObserved · 20 Oct 2026

Spotted something wrong? Report a correction · Methodology