skills/coji__natural-japanese
1
0
Fork 0
mirror of https://github.com/coji/natural-japanese.git synced 2026-09-14 20:07:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

feat: 6軸推敲ルーブリックの導入とREADME刷新 (v1.5.0)

Browse Source 
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
coji
2026-09-04 13:33:47 +09:00
parent 0f1cc1c5a4
commit 01802de30f
9 changed files with 220 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude-plugin/marketplace.json
+1 -1
View File
@@ -8,7 +8,7 @@
"name": "natural-japanese",
"source": "./",
"description": "仕事の日本語文書を読みやすくわかりやすく書く・直すためのスキル。AI臭さの除去を工程の一部として組み込む。",
"version": "1.4.0",
"version": "1.5.0",
"author": {
"name": "coji"
}
.claude-plugin/plugin.json
+1 -1
View File
@@ -1,7 +1,7 @@
{
"name": "natural-japanese",
"description": "仕事の日本語文書を読みやすくわかりやすく書く・直すためのスキル。議事録・調査レポート・社内ガイド・リサーチメモ・スライド構成などのビジネス文書から note・ブログ・エッセイまで。AI臭さの除去を工程の一部として組み込む。",
"version": "1.4.0",
"version": "1.5.0",
"author": {
"name": "coji"
},
README.md
+72 -94
View File
@@ -3,169 +3,147 @@
[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](./LICENSE)
[![GitHub release](https://img.shields.io/github/v/release/coji/natural-japanese)](https://github.com/coji/natural-japanese/releases)
仕事の日本語を、読みやすくわかりやすく書く・直すための [Agent Skill](https://docs.claude.com/en/docs/claude-code/skills) です。議事録・調査レポート・社内ガイド・リサーチメモ・スライド構成といった仕事の文書から、note・ブログ・エッセイまで扱います。
仕事でAIに文章を書かせると、どこか独特の「匂い」が残ります。
AIと文書を作るとき、毎回プロンプトに書いている指示があるはずです。結論から書いて。論旨を明確に。見出しは端的に。専門用語は文中で説明して。このスキルは、そうした指示を「書く前の設計」「書くときの制約」「書いた後の検査」の全工程に組み込みます。AI臭さ（AIっぽい／機械翻訳っぽい）の除去も工程の一部です。
見出しは中身を言わず、どの段落も同じような長さで均等に並び、当たり障りのない結論で安全にまとめられる。あとから手作業で直そうとしても、骨組み全体に手癖が染み込んでいて、結局ゼロから書き直したほうが早いと感じることも少なくありません。
> **English summary:** An Agent Skill for writing clear, readable Japanese work documents — designing the argument before writing, constraining generation with a 12-article style constitution, then mechanically detecting "AI-smelling" patterns via sudachipy morphological analysis and iterating until the text converges.
`natural-japanese` は、仕事の日本語を読みやすく書く・直すための [Agent Skill](https://docs.claude.com/en/docs/claude-code/skills) です。議事録・調査レポート・社内ガイド・企画書・ブログ記事などを対象に、論旨がすっきり通る自然な文章への執筆や推敲を支援します。
## 設計思想
> **English summary:** An Agent Skill for writing clear, readable Japanese work documents. It prevents "AI-smelling" patterns using a style constitution and mechanically detects issues with sudachipy-based linting.
軸は二つあります。
## 設計の考え方
第一に「検出は機械、判断は人間（またはAI）」。AI は自分自身の AI 臭さを認識しにくい、という前提に立つ設計です。修正の前に、まず [`lint.py`](./skills/natural-japanese/scripts/lint.py) が形態素解析（[sudachipy](https://github.com/WorksApplications/sudachi.rs)）で決定的に検出します。
書き上がった文章からAI臭を抜くのは、料理のあとから塩を抜くような難しさがあります。AI自身に「もっと自然にして」と頼んでも、自分の手癖を認識できないため、別の定型句に置き換わるだけになりがちです。
- 禁止語・紋切り型フレーズ（[`forbidden-patterns.md`](./skills/natural-japanese/references/forbidden-patterns.md)）
- 文リズムの単調さ、段落構造の均質さ
- 英語統語の直訳調（無生物主語+他動詞、連体修飾の入れ子など）
そのため、このスキルでは設計を根本から分けています。
何をどう直すかはエージェント（あなた）の判断に委ねます。
### あとから直すより、書く前に防ぐ
第二に「事後修正より生成時制約」。AI臭は個々の語句だけでなく、段落の均質さや論旨の運びといった構造にも染み込むため、書き上がってから消そうとすると書き直しに近い作業になります。だから書く前に読者・主メッセージ・見出しスケルトンを決めます。書くときは「結論から書く」「見出しはメッセージにする」「同じ鋳型を3回繰り返さない」など12箇条の文体憲法（[`writing-constitution.md`](./skills/natural-japanese/references/writing-constitution.md)）を制約として、発生自体を防ぎます。文書タイプ別の型は [`doctypes/`](./skills/natural-japanese/references/doctypes/) にまとめてあります。
書く前に見出しの骨組み（スケルトン）を固め、12箇条の文体憲法を制約として適用します。「結論から書く」「同じ型を繰り返さない」といったルールで縛り、最初から歪みの少ない文章を出力させます。
一方で、語順・読点の位置・一文一義・主語述語の距離といった「そもそも読みにくい」領域では、機械的な閾値化ができないことがコーパス検証でわかっています（[`readability-sweep.md`](./corpus/reports/readability-sweep.md)）。ここは機械に任せず、AI 自身が周回ごとに目視でレビューします。参照するのは一般原則（[`readability-principles.md`](./skills/natural-japanese/references/readability-principles.md)）と悪文パターンカタログ（[`readability-antipatterns.md`](./skills/natural-japanese/references/readability-antipatterns.md)）で、判断の重みづけがジャンルごとにどう違うかは [`genre-notes.md`](./skills/natural-japanese/references/genre-notes.md) にまとめてあります。
### 検出は機械、判断は人間（またはエージェント）
ただし、判定はできなくても「ここを見てください」という指し示しは機械にもできます。それが v1.4.0 で追加した読解負荷レーン（`lint.py --reading-load`）で、使い方は後述します。
それでも混ざる手癖は、形態素解析（[sudachipy](https://github.com/WorksApplications/sudachi.rs)）を使ったスクリプト [`lint.py`](./skills/natural-japanese/scripts/lint.py) で機械的に洗い出します。紋切り型のフレーズ、単調な文リズム、英語の直訳調をルールベースで突きつけます。
## 前提条件
ただし、指摘を機械的に全置換すると文章のニュアンスが失われます。何を直し、文脈上あえて何を残すかは人間やエージェント自身が判断します。
Python スクリプトの実行には [uv](https://docs.astral.sh/uv/) が必要です。
なお、語順や読点の位置といった「そもそも読みにくい」領域は、機械的な判定が難しいことがコーパス検証（180本超の比較分析）で分かっています。こうした箇所はルールカタログに基づく目視レビューや、補助的な読解負荷チェック（`--reading-load`）を組み合わせて丁寧に推敲します。
```bash
brew install uv
```
## 変換の例
Homebrew を使わない場合は [uv 公式のインストールガイド](https://docs.astral.sh/uv/getting-started/installation/) を参照してください。
**Before**
> リモートワークの普及は、働き方に大きな変化をもたらした。重要なのは、通勤時間の削減による生活の質の向上だ。また、オフィスコストの削減という企業側のメリットも見逃せない。このように、リモートワークは労働者と企業の双方にとって恩恵のある働き方だと言えるだろう。
`pip install` や venv の手動セットアップは不要です。依存関係はスクリプト自身に書いてあり、`uv run` が実行時に自動で取ってきます（PEP 723 インラインメタデータ）。
**After**
> リモートワークが広まってから、通勤で潰れていた1時間が自分の時間に戻ってきた人は多いはずだ。企業側もオフィスの家賃を削れる。誰も損をしていないように見える働き方だが、実際にそう言い切れるのかは、もう少し先まで見ないと分からない。
`重要なのは` `このように` `と言えるだろう` といった手癖の定型句を外し、結論を急いで押し付ける構えを、実感と留保のある表現に変えています。その他の例は [`examples.md`](./skills/natural-japanese/references/examples.md) を参照してください。
## インストール
4つの方法がありますが、どれで入れても中身は同じです。ふだんの Claude Code なら 1 が最も簡単です。`/plugin` コマンドで更新まで管理したい場合は 3 を選んでください。
### 1. `npx skills add`（推奨）
```bash
npx skills add coji/natural-japanese
```
`skills/natural-japanese/` を読み取り、`~/.agents/skills/` などエージェントの設定ディレクトリにインストールします。
Claude Code などのエージェント設定ディレクトリにインストールします。
### 2. `npx openskills install`（Claude Code 以外のエージェントでも使う場合）
### 2. `npx openskills install`（Cursor / Windsurf / Codex など）
```bash
npx openskills install coji/natural-japanese
npx openskills sync
```
`AGENTS.md` を経由して Cursor / Windsurf / Aider / Codex など、AGENTS.md を読めるあらゆるエージェントから利用できます。
`AGENTS.md` を経由して各エージェントから利用できるようになります。
### 3. Claude Code plugin marketplace
### 3. Claude Code プラグイン
```
/plugin marketplace add coji/natural-japanese
/plugin install natural-japanese@natural-japanese
```
`.claude-plugin/` のマニフェストを使い、`skills/natural-japanese/` をプラグインとして配布します。
### 4. 手動配置
### 4. GitHub Releases の `.skill`(zip)をダウンロード
[Releases](https://github.com/coji/natural-japanese/releases) から `natural-japanese.skill` をダウンロードして展開し、任意のエージェントのスキルディレクトリに配置してください。
[Releases](https://github.com/coji/natural-japanese/releases) から `natural-japanese.skill` をダウンロードし、エージェントのスキルディレクトリに展開して配置してください。
## 使い方
一例から。AIがよく書くこんな文があるとします。
スキルを導入すると、エージェントへの日常的な依頼の中で自動的に呼び出されます。
> リモートワークの普及は、働き方に大きな変化をもたらした。重要なのは、通勤時間の削減による生活の質の向上だ。また、オフィスコストの削減という企業側のメリットも見逃せない。このように、リモートワークは労働者と企業の双方にとって恩恵のある働き方だと言えるだろう。
- 議事録・レポート・社内ガイド・企画書などの作成や校正
- 「読みやすくして」「結論から書いて」「不自然な表現を直して」といった指示
- AIが書いた下書きの推敲や、AI臭さの診断（スコア測定）
- ブログやエッセイの下書き作成、既存記事のリライト
`lint.py` が `重要なのは` `このように` `と言えるだろう` の3語を検出し、AIが文脈で判断して直すと、こうなります。
指摘を一括置換するのではなく、エージェントが指摘を仕分けし、さらに「6軸推敲ルーブリック（脱AI臭・情報密度・体温など）」で合格基準に達するまで自律的に推敲ループを回します。
> リモートワークが広まってから、通勤で潰れていた1時間が自分の時間に戻ってきた人は多いはずだ。企業側もオフィスの家賃を削れる。誰も損をしていないように見える働き方だが、実際にそう言い切れるのかは、もう少し先まで見ないと分からない。
### 診断コマンド
定型句を外すだけでなく、結論を押し付ける構えを、留保を残す言い方に変えるところまでが仕事です。ほかの事例は [`examples.md`](./skills/natural-japanese/references/examples.md) にあります。
文書を書き換えずに自然度（0〜100）を測定したい場合は、診断コマンドを実行できます。
スキルをインストールした状態で、以下のような場面で自動的に発動します。
```
/natural-japanese score path/to/document.md
```
- 議事録やレポート、企画書といった仕事の文書の作成・校正（文字起こしからの議事録化も含む）
- 「結論から書いて」「論旨を明確に」「見出しを端的に」「専門用語をわかりやすく説明して」といった指示
- 「AIっぽい」「機械翻訳っぽい」「不自然」といった指摘への修正
- AI臭さの診断・採点（書き換えずにスコアと理由だけ欲しいとき）
- 「読みにくい」「何が言いたいか分からない」「一文が長い」「読点の位置がおかしい」といった読みやすさの改善依頼
- note やブログ、エッセイの新規執筆・下書き、既存文章のリライト・推敲
- 文体プロファイル（`style-profile.md`）のセットアップ
## 検査スクリプト単体での利用
診断は `/natural-japanese score <ファイル>` で呼び出せます。自然度スコアは0〜100で、高いほど自然です。
フローは一回検出して終わりではありません。lint の指摘を「直す / 理由を付けて残す」に仕分けし、修正が新しい指摘を生まなくなるまで——つまり収束するまで——ループします。周回ごとの差分は lint の `--baseline` オプションで機械的に追跡できます（解消・新規・継続の分類）。作業中の中間ファイルは完了時にすべて削除され、残るのは完成した文書だけです。
詳しいフローは [`SKILL.md`](./skills/natural-japanese/SKILL.md) を参照してください。
## 検査スクリプト単体の使い方
検査層の3スクリプトは、スキルを介さず単体でも使えます。役割ごとに分かれています。共有基盤の `textcore.py` は3スクリプトが内部で使うだけで、直接実行するものではありません。
### `lint.py` — 疑いの検出
各スクリプトはスキルを介さず単体でも実行できます。実行には [uv](https://docs.astral.sh/uv/) が必要です。依存関係はスクリプト自身に記述されており、`uv run` が実行時に自動で解決します。
```bash
brew install uv
```
```bash
# 疑いのある表現の検出
uv run skills/natural-japanese/scripts/lint.py path/to/draft.md
uv run skills/natural-japanese/scripts/lint.py path/to/draft.md --json
# ジャンル指定（誤検知の抑制）
uv run skills/natural-japanese/scripts/lint.py path/to/draft.md --genre tech
# 読解負荷（一文の長さや読点の偏りなど）のチェック
uv run skills/natural-japanese/scripts/lint.py path/to/draft.md --reading-load
# 構成（見出し・段落先頭文）の抽出
uv run skills/natural-japanese/scripts/outline.py path/to/draft.md
# 専門用語と初出説明の確認
uv run skills/natural-japanese/scripts/terms.py path/to/draft.md
```
ジャンルが明確なら `--genre tech|business|essay` を指定してください。コーパス校正済みの閾値プロファイルに切り替わり、誤検知が減ります。
読みやすさの推敲には `--reading-load` を追加します（opt-in）。一文が長すぎる・埋もれた列挙・二重否定・漢字の連続・「の」の連鎖——この5つを severity info のみで指し示します。指定しない限り出力は従来と変わらず、AI臭さの findings や `--baseline` 差分にも混ざりません。
CI ゲートではなく lint なので、検出件数に関わらず exit code は `0` です。検出結果をどう直すかは書き手（またはAI）の判断に委ねます。exit code が `1` になるのは、ファイル不在・ディレクトリ指定・読み取り不可といった入力エラーのときだけです。
### `outline.py` / `terms.py` — 判断ではなく素材の抽出
findings の代わりに、構造・用語の「素材」だけを機械的に抽出します。どちらも判断はせず抽出のみで、exit code の方針は `lint.py` と同じです。
```bash
uv run skills/natural-japanese/scripts/outline.py path/to/draft.md # 見出し・各段落の先頭文・箇条書きプレースホルダを行番号付きで抽出
uv run skills/natural-japanese/scripts/terms.py path/to/draft.md # カタカナ複合語/ASCII略語/固有名詞らしき語を初出順に抽出（説明マーカーの有無つき）
```
### `semantic.py` — 話題平板性の検出（EXPERIMENTAL・opt-in）
```bash
uv run skills/natural-japanese/scripts/semantic.py path/to/draft.md
```
文埋め込みで、隣接する文の類似度に起伏がない状態（話題の平板さ）を検出します。torch + sentence-transformers に依存し、初回に約1GBのモデルダウンロードを伴う重量級です。そのため `lint.py` には組み込まず、独立の opt-in エントリにしています。
## リポジトリ構成
```
skills/natural-japanese/ # スキル本体（single source of truth）
skills/natural-japanese/ # スキル本体
SKILL.md # スキル定義
references/ # 文体憲法・禁止パターン・チェックリスト・翻訳調ガイド・読みやすさ原則/悪文カタログ/ジャンル差分など
references/doctypes/ # 文書タイプ別の型（議事録・調査レポート・社内ガイド・メモ/DP・スライド）
scripts/ # textcore.py（共有基盤）/ lint.py・outline.py・terms.py（検査層エントリ）/ semantic.py（EXPERIMENTAL・opt-in）/ calibrate.py / fixtures
assets/ # style-profile テンプレート
.claude-plugin/ # Claude Code plugin manifest / marketplace 定義
dev/check-fixtures.sh # fixture 回帰チェック（開発用）
.githooks/pre-commit # lint/fixtures 変更時に fixture 回帰チェックを実行
references/ # 文体憲法・禁止パターン・6軸ルーブリックなど
references/doctypes/ # 文書タイプ別の型（議事録・レポート・ガイドなど）
scripts/ # 検査スクリプト（lint.py, outline.py, terms.py など）
assets/ # テンプレート
```
スキル本体は `skills/natural-japanese/` の1か所だけにあります。
### 開発者向け
### 開発者向け: pre-commit hook の有効化
スクリプトや fixture を変更した際は、fixture 回帰チェックを実行してください。
```bash
git config core.hooksPath .githooks
./dev/check-fixtures.sh
```
`skills/natural-japanese/scripts/` の `lint.py` / `textcore.py` や `fixtures/` を変更した場合は、`./dev/check-fixtures.sh` で期待検出件数（fixture 回帰）を確認してください。該当ファイルが staged されていれば pre-commit hook が自動で実行します。タグ `v*` を push すると GitHub Actions（`.github/workflows/release.yml`）が同じチェックを実行し、`.skill` をビルドして Release に添付します。
## 参考にした資料
このスキルの設計は、次の公開資料に大きく影響を受けています。感謝します。
このスキルの設計にあたり、以下の公開資料やプロジェクトを参考にしています。感謝します。
- [AI臭さを消した日本語執筆エージェントの設計（なつ「いとおり」）](https://note.com/art_reflection/n/n7ffd5ce3320c) — 「AIは自分のAI臭さを認識できない → 機械検出で突きつけ、判断だけを委ねる」という本スキルの核となる考え方、濃淡設計、自己点検ループの元になった記事
- [日本語技術文書の文章規範（k16shikano）](https://gist.github.com/k16shikano/fd287c3133457c4fd8f5601d34aa817d) — 禁止語カタログのうち「LLMっぽい空句」のカテゴリ群（正面から系・空虚な形容・空虚な動詞）の出典
- [meiseki（bamboo-nova）](https://github.com/bamboo-nova/meiseki) — textlint の決定論的検出と LLM の文脈判断を組み合わせる、近い設計思想の日本語明晰化プラグイン。悪文カタログを読解負荷の大きい順に並べる構成の参考。v1.4.0 の読解負荷レーン（`--reading-load`）を作るきっかけにもなった
- [AI臭さを消した日本語執筆エージェントの設計（なつ「いとおり」）](https://note.com/art_reflection/n/n7ffd5ce3320c) — 機械検出と文脈判断の分離、濃淡設計、自己点検ループの着想元
- [日本語技術文書の文章規範（k16shikano）](https://gist.github.com/k16shikano/fd287c3133457c4fd8f5601d34aa817d) — LLM特有の空虚な言い回し（空句）の分類基準
- [meiseki（bamboo-nova）](https://github.com/bamboo-nova/meiseki) — 機械検出とLLM推敲を組み合わせるアプローチや、読解負荷の観点整理
## クレジット
本 README の執筆・推敲: Cursor Agent (Gemini 3.8 Flash High)
## ライセンス
skills/natural-japanese/SKILL.md
+13 -2
View File
@@ -118,9 +118,20 @@ lint は文レベルの表層しか見えない。特に箇条書き主体の議
既存文書のリライトでは、同じ種類の修正（見出しの結論化、箇条書きの地の文化など）を全項目へ一律に当てると、元の文書の自然な濃淡を消してかえってAI臭が増す。価値を足せる箇所だけを選んで直す原則は `references/revision-guide.md` の「改稿を一律に適用しない」を参照。
## 6. 最終パス — 自己点検ループ
## 6. 最終パス — 自己点検ループと評価ハーネス
lint と台帳が収束しても、それは既知のパターンが消えたことしか意味しない。最後に必ず、初見の読者として通読し、声に出して読むつもりでリズムを確かめる。手順は `references/revision-guide.md` の「自己点検ループ」を参照。違和感を見つけたら台帳に起こして5に戻り、なくなったら完了とする。
lint と台帳が収束しても、それは既知の表層パターンが消えたことしか意味しない。ここから先には、lint では拾えない「無菌室のような冷たさ」「ダラダラとした冗長な引き伸ばし」が残りやすい。
フルモード（および重要な文書）では、`references/eval-rubric.md` の **6軸推敲ルーブリック** を用いて客観評価を行う。
1. **脱AI臭・文体の自然さ**: プレゼン的数宣言・共感煽り・翻訳調ダッシュ・決め文がないか
2. **情報密度・簡潔さ（ダラダラ引き伸ばしの排除）**: 読者の時間を奪う不要な前置き・講釈・言い換え水増しを削ぎ落としているか
3. **機能性・走査性**: 欲しい情報に最短で迷わず辿り着けるか
4. **論理の明晰性と納得感**: 因果関係が腑に落ち、実測・具体例で接地しているか
5. **人間味・誠実さ（体温・動機）**: 無菌室病にならず、書き手の実感・問題意識（Why）が宿っているか
6. **自己証明力**: その文書自体が、看板に偽りのない最高のお手本になっているか
**合格基準は全軸90点以上・総合平均92点以上**。未達の軸があればボトルネックを特定して改稿し、合格に達するまでループを回す（手順詳細は `references/eval-rubric.md` および `references/revision-guide.md` を参照）。クイックモードではこの6観点を頭の中で通読点検して終える。違和感を見つけたら直して完了とする。
## 7. 後片付け
skills/natural-japanese/references/eval-rubric.md
+85
View File
@@ -0,0 +1,85 @@
# 6軸推敲ルーブリック（評価・改善ハーネス）
`scripts/lint.py` の指摘が 0 件になった文章は、「露骨な地雷を踏んでいない」状態にすぎない。そこから先には、lint では検知できない「無菌室のような冷たさ」「ダラダラとした冗長な引き伸ばし」「お行儀の良すぎるテンプレ構成」といった、より根深いAI臭が残る。
本ルーブリックは、機械検査を通過した文章に対して客観的な評価を行い、ボトルネックを特定して改稿を繰り返すための**自己点検ハーネス**である。
---
## 合格基準
- **全軸 90 点以上**
- **総合平均 92 点以上**
いずれかの軸が 90 点未満の場合は合格とみなさず、減点理由を解消する改稿を行って再評価する。
---
## 6つの評価軸
### 1. 【脱AI臭・文体の自然さ】（配点: 100）
露骨なLLM構文や手癖が完全に排除され、人間が書いた自然な息づかいになっているか。
- **減点対象**:
- **プレゼン的ナンバリング宣言**: 「軸は2つあります。第一に〜」「ポイントは3点あります」のように、冒頭で数を宣言してからお行儀よく並べる型
- **安易な共感煽り・句点連打**: 「〜があるはずです。結論から書いて。論旨を明確に…」のような、読者の悩みを勝手に代弁して共感を引こうとする演出
- **翻訳調ダッシュ**: 英語の em-dash を直訳した「——つまり〜——」のような挿入句
- **自己啓発的・演出的な決め文**: 「〜ところまでが仕事です」「〜に他なりません」など、キリッとした決め台詞で自己陶酔する文末
- **読者目線の混濁**: 読者向けの文章に「エージェント（あなた）」のようなプロンプト内部指示が漏れ出している状態
### 2. 【情報密度・簡潔さ（ダラダラ引き伸ばしの排除）】（配点: 100）
「読者の時間を奪わない」引き算の美学が徹底されているか。不要な前置きや蛇足の講釈がなく、短くズバッと言い切れているか。
- **減点対象**:
- **ダラダラとした前置き・予告**: 「ここでは〜について詳しく見ていきましょう」「本節では〜について解説します」といった、本題に入る前の無駄な助走
- **誰も聞いていない一般論・歴史の講釈**: 本題の前に「近年、テクノロジーの進化により〜」といった当たり前の大前提を長々と語る
- **言い換えによる水増し**: 1つの言いたいことに対して、表現を変えて同じ内容を2度3度となぞる
- **過剰な親切・蛇足の補足**: 読者が文脈から自明に理解できることまで「なお、これは〜という意味であり…」と手取り足取り説明しすぎる
- **薄い情報密度の箇条書き**: 箇条書きの各項目にダラダラと解説文をぶら下げて縦に引き伸ばす
### 3. 【機能性・走査性】（配点: 100）
読者が知りたい情報（結論、手順、コマンド、要点）に最短で迷わず辿り着けるか。
- **減点対象**:
- 見出しだけを拾い読みしても中身や結論が分からない（ラベル見出しの羅列）
- すぐに使いたいコマンドや設定例が、長い解説文の奥底に埋もれている
- 視線誘導が整理されておらず、どこから読み始めればいいか迷う
### 4. 【論理の明晰性と納得感】（配点: 100）
「なぜそうなのか」という因果関係がすっきりと腹落ちするか。
- **減点対象**:
- 結論だけが唐突に示され、なぜそのアプローチをとるのかの理由が抜けている
- 根拠のない抽象論だけで語られ、実測データ・固有名詞・具体的な比喩による接地がない
- 理由と結論の間に論理の飛躍がある
### 5. 【人間味・誠実さ（体温・動機）】（配点: 100）
無菌室のような無機質さ（綺麗にまとめただけの優等生感）にならず、書き手の生々しい実感や動機（Why）が宿っているか。
- **減点対象**:
- **無菌室病**: 減点されるのを恐れて当たり障りのない言葉だけで塗り固めた、体温ゼロの文章
- **開発動機（Why）の欠如**: 「何に辟易してこれを作ったのか」「どこで実際に困ったのか」という書き手の体温・問題意識が一切見えない
- **均質すぎるです・ます調**: 文末が単調に揃いすぎていて、感情や息継ぎのリズムがない
### 6. 【自己証明力（看板としての説得力）】（配点: 100）
その文章自体が、掲げている看板（自然な日本語、使いやすいツール等）の最高のお手本・説得力になっているか。
- **減点対象**:
- 「自然な文章を書く」と謳っているドキュメント自体が不自然であるような、看板との矛盾
- 読者に「この作者は本当にこの問題の機微を理解しているのか？」と不信感を抱かせる綻び
---
## ハーネスの実行手順
1. **下書き ➔ 機械検査（Phase 1）**:
`lint.py` を実行し、指摘が 0 件になるまで修正する。
2. **6軸ルーブリック採点（Phase 2）**:
本ルーブリックの 6 軸で各 100 点満点で客観採点を行う。
3. **ボトルネックの特定**:
点数が最も低い軸（特に「2. 情報密度」のダラダラ引き伸ばしや、「5. 人間味・体温」の無菌室病が頻出）を特定する。
4. **引き算と体温の注入による改稿**:
- 余計な講釈・前置き・言い換えをバッサリ削る（情報密度の向上）。
- 作り手の生々しい実感や動機を要所に宿らせる（体温の注入）。
5. **再評価と収束**:
全軸 90 点以上、総合平均 92 点以上に達するまでループを回す。
skills/natural-japanese/references/forbidden-patterns.md
+18
View File
@@ -86,6 +86,24 @@
何をどう書いたか・どう言語化したかを示さないまま、作業したことだけを宣言する動詞。「本章ではこの問題を深掘りする」と書いても、深掘りの中身は次の文以降で初めて分かる。宣言を消して、深掘りした内容そのものから書き始める。
## プレゼン的数宣言（箇条書き化への助走）
「理由は3つあります」「軸は2つあります」「ポイントは主に以下の通りです」
これから話す項目の数を冒頭で宣言してから綺麗に並べる型。プレゼンや要約タスクの学習データに大量に含まれるためLLMが極めて好むが、文章として読むと教科書的・テンプレ的で体温が消える。数を先に宣言せず、理由や背景の内容そのものから地続きで語る。
## 演出的な決め文・自己陶酔調
「〜ところまでが仕事です」「〜に他なりません」「これこそが〜の真髄です」「〜と言っても過言ではありません」
キリッとした決め台詞で文末を演出し、自己満足的に話を締めくくる型。文章全体の論証や事実の重みではなく、語り口のカッコよさで読者を圧倒しようとするため、読者には空々しく響きやすい。事実を淡々と述べる（「〜までを扱います」「〜が特徴です」）。
## ダラダラ引き伸ばし・水増し講釈（読者時間の浪費）
「近年、〜の重要性がますます高まっています」「ここでは〜について詳しく見ていきましょう」「つまり、〜ということでもあります」
誰もが知っている当たり前の一般論から入ったり、予告を二重に置いたり、同じ内容を言い換えて文字数を水増しする型。AIが「丁寧に解説しよう」とするあまり情報密度が薄まり、読者に「早く本題に入れ」「長くて読む気が失せる」という強いストレスを与える。不要な前置きや蛇足の講釈は徹底的に削ぎ落とし、最短で本題の核心に入る。
## 拡張リスト（lint未実装、目視で確認したい表現）
「〜と言われています」の伝聞への逃げ、「〜かもしれません」の乱用による曖昧化、「〜していきたいと思います」の意志薄弱な言い切り回避、「様々な」「多様な」で具体を省略する癖、「〜ということです」で終わる伝聞的まとめ、「まさにその通り」の同意演出、「〜ではないかと思います」の二重の曖昧化、「〜という声もあります」の匿名の権威づけ、「今回は〜について紹介します」という予告口調の冒頭、「ぜひ〜してみてください」という締めの定型句
skills/natural-japanese/references/revision-guide.md
+18 -4
View File
@@ -139,18 +139,32 @@ lint の finding は疑いの提示であって指示ではないぶん、「見
これは回数で機械的に打ち切るためのルールではない。「同じ箇所が同じ形で再発する」という状態そのものが、その finding がもう単発修正では扱えないという合図であり、それを検知したら状態を切り替える、という遷移ルールである。
## 自己点検ループ
## 自己点検ループと6軸推敲ハーネス
下書きを直したあと、一度時間を置くか視点を切り替えて読み直す。おすすめの型は「これを他人が読んだら、どこに引っかかるか」を具体的に想像しながら読むことで、次の観点を順に当てる。
下書きを直したあと、一度時間を置くか視点を切り替えて読み直す。lint の指摘が 0 件になった段階は「地雷を踏んでいない」にすぎず、ここから**「無菌室病（綺麗だが誰の実感もこもっていない）」**や**「冗長な引き伸ばし（ダラダラ説明して読む気を削ぐ）」**という一段深いAI臭との戦いが始まる。
1. 冒頭の3段落だけを読んで、結論を先取りしすぎていないか
フルモード（および重要な文書）では、`references/eval-rubric.md` の **6軸推敲ルーブリック** を用いて客観評価を行う。合格ラインは **全軸90点以上・総合平均92点以上**。
特に頻出するボトルネックと対処指針:
- **情報密度の低下（ダラダラ引き伸ばし）**:
AIは「丁寧に説明しよう」とするあまり、不要な前置き（「ここでは〜について詳しく見ていきましょう」）、当たり前の前提講釈、言い換えによる水増しを重ねがちになる。「読者の時間を奪わない」引き算の美学に立ち返り、削っても意味が通る助走や蛇足の解説をバッサリ削る。
- **無菌室病（体温・動機の欠落）**:
減点を恐れて優等生的な一般論だけで塗り固めると、体温ゼロの無機質な文章になる。「何にうんざりしてこれを作ったのか」「どこで実際に困ったのか」という書き手の生々しい実感や動機（Why）を、冒頭や主要な節に最低1箇所は宿らせる。
- **プレゼン的数宣言・演出の残滓**:
「軸は2つあります。第一に〜」というプレゼン的数宣言や、翻訳調ダッシュ（「——つまり〜——」）、自己啓発的決め文（「〜ところまでが仕事です」）が残っていないか点検し、自然な地の文に直す。
自己点検の手順:
1. 冒頭の3段落だけを読んで、結論を先取りしすぎていないか、またダラダラした前置きで読者を待たせていないか
2. 段落ごとの文末を目で追い、同じ形（体言止め・「〜だ」・「〜である」）が連続していないか
3. 声に出して読んだときに息継ぎの位置が不自然でないか（長すぎる一文の兆候）
4. 自分が本当に思ったことと、書かれている内容がずれていないか。借り物の意見に見える箇所はないか
5. business・techの解説・ケーススタディ・レポートでは、固定質問3〜5問への答えがどこで初めて出るか。記事全体の主結論を待たせたまま、書き手の発見順を追わせていないか。特定の節だけに関わる回答が後半にあることは問題にしない
6. 予告・異変・種明かし・回収・決め文だけを抜き出したとき、説明とは別の物語ができていないか。同じ役割の演出が複数あれば、一つを残して減らせないか
7. 6軸ルーブリックで採点し、90点未満の軸があればボトルネックを解消する改稿を行う
このループで気づいた点があれば台帳に新しい行として起こし、lint の再検知ループに戻る。何も引っかからなくなったら、そこがゴールになる。
このループで気づいた点があれば台帳に新しい行として起こし、lint の再検知ループに戻る。全軸90点以上に達し、何も引っかからなくなったら、そこがゴールになる。
## 収束の状態
skills/natural-japanese/references/translationese.md
+9
View File
@@ -78,6 +78,15 @@ it is undoubtedly / nothing but の強調的な断定を直訳的に受け止め
- Before: これは時代の変化の表れに他ならない。
- After: 時代が変わったからこそ、こうなったのだと思う。
## ダッシュ挿入句（英語の em-dash 直訳）
英語の em-dash による補足挿入構文（`— like this —`）を直訳した表現。日本語の文中に「——つまり〜——」や「——これは〜——」のようにダッシュを二重に挟み込むと、日本語本来の語順や息継ぎのリズムが不自然に寸断され、LLM特有の翻訳調が際立つ。通常の括弧（）にするか、接続詞を用いて文を分ける。
- Before: 指摘が出なくなるまで——つまり収束するまで——ループします。
- After: 指摘が出なくなる（収束する）までループします。
- Before: 骨組み全体に手癖が染み込んでいて——結局ゼロから書き直したほうが早い——そう感じた。
- After: 骨組み全体に手癖が染み込んでいて、結局ゼロから書き直したほうが早いと感じた。
## 見分け方のコツ
これらのパターンに共通するのは、「日本語の語順・文法としては成立するが、その言い回しを選ぶ必然性が文脈にない」という点にある。書いた文を読み返すとき、「この言い回しは、他にどんな言い方ができたか」と自問し、他の言い方のほうが自然に思えるなら翻訳調を疑ってよい。
skills/natural-japanese/references/writing-constitution.md
+3 -1
View File
@@ -6,7 +6,7 @@
## 1. 前置きを書かない。結論はタイトルと最初の一文に渡す
「本稿では〜について解説する」「本記事は〜を目的とする」という書き出しは、読み手に何の情報も渡さない。結論はタイトルか冒頭の一文に置き、長い文書ならその直後に要約を続ける。要約に数値が使えるなら、数値をそのまま冒頭に出す。
「本稿では〜について解説する」「本記事は〜を目的とする」という書き出しは、読み手に何の情報も渡さない。結論はタイトルか冒頭の一文に置き、長い文書ならその直後に要約を続ける。要約に数値が使えるなら、数値をそのまま冒頭に出す。また、誰もが知る前提や一般論をダラダラと語る前置きも読者の時間を奪う。蛇足の講釈は削り、最短で本題の核心に入る。
- Before: 「本稿では、AIエージェントの業務適用について、現状の技術水準と限界を踏まえながら論じる。」
- After: 「AIエージェントは、頼んだ仕事をこなせる。次の仕事を見つけるのは、まだ人間だ。」
@@ -56,6 +56,8 @@
書く前の確認は一問一答でよい。段落の主張から固有名詞・数値・実例をすべて抜いても文意が変わらないなら、それはまだ一般論の域を出ていない。実例がすべてだ。抜くと文が成立しなくなる段落だけが、接地できている段落だと判断する。素材が本当に手元にないときは、書き手の推測だけで埋めずに、何を確認すれば書けるかを一言添えて空欄を残す。
数値や固有名詞だけでなく、**書き手自身の生々しい実感や問題意識（Why）** も重要な接地素材である。「何にうんざりしたのか」「どこで実際に困ったのか」という体温が欠けた文章は、事実が揃っていても誰の実感もこもらない「無菌室」になる。冒頭や核となる節には、書き手の実感を最低1箇所は宿らせる。
## 6. 太字は文中の核1箇所だけに使う
文全体の太字化や、絵文字・記号による装飾は使わない。絵文字を使ってよいのは、社内で通用する区分ラベルのようにナビゲーション上の機能を持つ場合だけで、感情の演出には使わない。