「この文章を自然な日本語に直して」と大規模言語モデル（LLM）に頼めば、添削結果を得られます。それなら、日本語添削スキルを備えたkotonohaを使う意味は何でしょうか。本記事では、文章の優劣を比べるのではなく、何を根拠に直し、どう確認するかという手順の違いを説明します。

kotonohaはLLMの代わりではありません。LLMによる書き換えに、独立した診断スクリプトと確認手順を組み合わせる仕組み です。

違いは「文章を書く能力」より「添削を確かめる仕組み」

LLMは、文脈を読んで語句を選び、説明の順序や文体を調整できます。kotonohaでも、実際の書き換えはLLMが担います。GiNZAという日本語解析ツールが、文章を完成稿へ自動変換するわけではありません。

kotonohaが加えるのは、見直す候補を探す処理と、修正結果を確認する手順です。

LLM単体の添削
  原文＋指示 → LLMの判断 → 修正文・説明

kotonohaの日本語添削
  原文＋変更禁止の情報
    → GiNZAとルールによる診断
    → LLMが文脈を読み、修正するか残すか判断
    → 修正文を再診断
    → 意味や変更禁止の情報も確認

本記事でいう「LLM単体」は、外部の診断スクリプトを使わず、プロンプトとモデルの応答で添削する構成です。LLM単体でも、変更理由の説明や自己点検は指示できます。そのため、「LLMには確認できず、kotonohaなら確認できる」と単純には分けられません。

主な違いは、確認方法をその場の指示に委ねるか、スキルの手順と実行可能な診断として用意するかです。kotonohaでは、変更禁止の情報を保つことを不変条件とし、以下の確認をスキルの手順として定めています。

比較する点	LLM単体での添削	kotonohaを使う添削
書き換えの担当	LLM	LLM
見直す箇所の抽出	指示とモデルの判断による	GiNZAの解析・ルールによる診断を判断材料に加える
修正理由の確認	LLMに説明を求められる	診断カテゴリーや測定値と、文脈上の判断を分けて確認できる
修正前後の比較	差分や再評価を別途指示する	診断JSONを保存し、新規・継続・解消を比較する
変更禁止の情報	プロンプトで指定できる	ID・数値・コード・義務の強さなどを保つ手順をスキルが定める
終了の判断	指示や利用者の判断による	各指摘への判断、新たな修正対象、不変条件を確認する
準備と実行負荷	プロンプト中心で始められる	スキルと診断用のPython環境が必要になる

ここで比較しているのは仕組みです。特定モデルとの性能比較実験ではなく、kotonohaのほうが必ず自然な文章になると主張するものでもありません。

違い1：「読みやすいと思う」に測定できる根拠を加える

LLMに「この文は読みにくい」と指摘されても、長さが問題なのか、修飾関係なのか、単に文体の好みなのかが曖昧なことがあります。理由を尋ねることはできます。ただし、その説明だけでは、文字数や構文を実際に測ったかは確認できません。

kotonohaのjapanese-proseは、GiNZAで語の分割、品詞、基本形、係り受けを解析します。その結果と、あらかじめ定めたルールを使って、見直す候補を挙げます。

診断の対象	調べること	出力で確認できる根拠の例
長い文	空白を除いた文字数	文字数とジャンル別の閾値
深い係り受け	語どうしの構文上の関係	構文木の深さと閾値
名詞の連続	名詞・固有名詞のトークンが続く数	連続数
文頭の反復	隣り合う文の先頭2トークンの基本形	一致した基本形
定型的な表現	登録した文字列や正規表現との一致	カテゴリーと該当箇所の抜粋

トークンは、解析のために分割した語などの単位です。係り受けは、どの語がどの語に結び付くかという関係を表します。

たとえば、技術文書向けの--genre techでは、110文字を超えた文をwarning、180文字を超えた文をcriticalとします。係り受けでは、各トークンが構文木の根に達するまでの辺を数えます。その最大値が9を超えるとwarningです。

閾値は研究で実証された理解度の境界ではなく、実装で定めた見直し基準です。文の長さ・読点・深さには、列挙と推定した場合に指摘を抑える例外もあります。

測定値があることと、読みやすさを客観的に証明できることは別です。 読解時間や理解度を測っているわけではなく、読みにくさにつながり得る特徴を検出しています。

違い2：検出した表現を、そのまま置き換えない

ルールを使う添削というと、「検出した語句をすべて直す」処理を想像するかもしれません。kotonohaでは、診断結果を受けて、LLMが指摘を文脈で読み直します。

判断は2つです。

判断	意味
`fix`	曖昧さや負荷を減らすため、意味を保って修正する
`keep`	正確さ、分野の慣習、引用、意図的なリズムのために残す

たとえば「〜しなくてはならない」は、二重否定などを検出するルールの対象です。しかし、要件定義書では義務を表す必要があります。

原文：管理者は、更新前に設定ファイルを保存しなくてはならない。

意味を保つ修正例：
管理者は、更新前に設定ファイルを保存する必要があります。

義務を弱めてしまう修正例：
管理者は、更新前に設定ファイルを保存するとよいでしょう。

規範表現の書式が決まっている文書なら、元の表現をkeepとする判断もあります。検出ルールは候補を挙げますが、採否までは決めません。

LLM単体にも、同じように意味を保つ指示は出せます。kotonohaの違いは、検出結果ごとに修正・維持を判断し、不変条件を確認する流れをスキルに組み込んでいることです。

ただし、この手順だけで意味の保存を保証することはできません。数値や義務の強さを変えないようスキルが指示していても、診断CLI（コマンドラインツール）が意味の保存を形式的に証明するわけではありません。差分の確認と内容のレビューは必要です。

違い3：修正文を同じ診断へ戻して比較する

LLM単体でも、「もう一度確認して」と依頼できます。kotonohaでは、それに加えて、同じスクリプトで修正前後を調べます。

診断結果をJSONで保存すると、次の実行でベースラインとして指定できます。

比較結果	意味
`new`	今回新しく現れた指摘
`persisting`	前回から継続している指摘
`resolved_count`	前回の指摘のうち、今回見つからなかったものの件数

たとえば、長文を分割しても、同じ書き出しの文を連続させれば、新しい指摘が出る可能性があります。「元の問題が消えたか」だけでなく、「修正で別の問題を増やしていないか」を確認するためです。

同じ入力、スクリプト、設定、解析モデルと実行環境をそろえるほど、診断結果を比較しやすくなります。一方、LLMによる修正文まで同じになるとは限りません。診断の比較可能性と、生成文の再現性は区別します。

ベースラインの照合にも限界があります。カテゴリーと正規化した抜粋で指摘を識別するため、表現が変わると同じ問題でも新規と扱われる場合があります。数字も正規化するので、指摘が継続していることは数値が保存された証拠になりません。

同じ修正文でも、確認できる情報が違う

違いを、短い例で見てみます。次の文を添削対象にします。

before.md

この機能においては、設定ファイルを編集することが可能です。
管理者は、更新前に設定ファイルを保存しなくてはならない。

修正案は、たとえば次のようになります。

after.md

この機能では、設定ファイルを編集できます。
管理者は、更新前に設定ファイルを保存する必要があります。

この修正案は、LLM単体でも生成し得るものです。本記事では、別のLLMにこの文章を入力した比較試験は行っていません。

kotonohaで注目したいのは、「この修正文を生成できたか」ではなく、診断結果と修正の判断を対応付けられることです。

原文への指摘	診断カテゴリー	この例での判断
においては	`heavy_location_phrase`	「では」に変えても場面を表す意味を保てるため`fix`
することが可能	`indirect_ability`	「できます」に簡潔化できるため`fix`
しなくてはならない	`double_negative`	保存の義務を保つ表現に変えて`fix`

参照実装の--genre techで実測すると、修正前は3件・94点、修正後は0件・100点でした。ベースライン比較は、新規0件、継続0件、解消3件です。

スコアは100点からの減点方式です。

score = max(0, 100 - 10 × critical件数
                   -  4 × warning件数
                   -  1 × info件数)

この例はwarningが1件、infoが2件なので、修正前は6点減点されます。ただし、100点は「登録された診断で指摘がなかった」という意味です。文章の品質が6%改善したことも、LLM単体より優れていることも示しません。

診断例を再現する

この記事の参照実装と実行条件は次のとおりです。

項目	対象
リポジトリ	nahisaho/kotonoha
パッケージのバージョン	`0.3.0`
参照コミット	`98534e500d32f6aaa994e4296c38224ea47d8aaf`
確認日	2026年10月16日
必要な実行環境	Node.js 18以上、npm、Python 3.10以上、`uv`
実行基盤	Linux、`uv 0.12.23`
宣言されている依存範囲	`ginza>=5.2.0,<5.3`、`ja-ginza>=5.2.0,<5.3`、`spacy>=3.8.0,<4`

作業用ディレクトリで、npmパッケージと同梱スキルをインストールします。

npm install kotonoha
npx kotonoha install
npx kotonoha --version

先ほどの文章をbefore.mdとafter.mdとして保存し、同じディレクトリから実行します。Pythonの依存パッケージは、スクリプト冒頭のメタデータに従ってuvが解決します。

uv run .github/skills/japanese-prose/scripts/lint.py before.md \
  --genre tech --json > prose-baseline.json

uv run .github/skills/japanese-prose/scripts/lint.py after.md \
  --genre tech --baseline prose-baseline.json --json

これらのコマンドが行うのは診断と比較であり、原文は書き換えません。修正・維持の理由も診断CLIが生成するのではなく、スキルに従うLLMや作業者が記録します。

LLM単体のほうが手軽な場面もある

短いメールの言い回しを変える、説明文を柔らかくする、複数の表現案を比べる。こうした用途では、LLMに原文と目的を伝え、出力を自分で確認するだけで足りる場合があります。

kotonohaは、診断の実行や結果の確認が増えるぶん、導入と確認に手間がかかります。GiNZAと解析モデルを使うPython環境も必要です。短文の一度限りの添削で、必ずこの仕組みを使う必要はありません。

一方、次の用途では、診断と判断を分ける価値があります。

用途	kotonohaの手順が役立つ理由
継続的に更新する技術文書	修正前後を同じ設定で比較できる
要件定義書や運用手順	数値・識別子・義務の強さを保つ確認を手順に含められる
複数人でレビューする文書	指摘の根拠と、残した理由を共有しやすい
長文の公開記事	見直す候補を抽出してから、全体を通読できる

japanese-proseのfullモードでは、文章診断に加え、読解負荷診断、見出し・段落冒頭の抽出、用語候補の抽出を行います。通常診断と読解負荷診断には重複があるため、件数や点数は加算しません。

文書全体の構成や必要情報は、別のtech-writerスキルが担当します。文の自然さと、技術文書としての完全性を分けて確認する設計です。

kotonohaを使っても残る限界

診断を追加しても、LLMの判断は必要です。ルールに一致しただけの箇所を、誤って直さないようにするためです。

たとえば「1年間を通じて監視する」の「を通じて」は、登録された診断対象です。しかし、期間を表す意味があるため、単なる冗長表現として削るべきではありません。引用中の定型句や、形式をそろえた手順にも同様の注意が必要です。

また、診断対象は文書全体ではありません。Markdownから本文を抽出する際、見出し・表の行・フェンスで囲まれたコードなどを除外します。本文の診断が100点でも、表の誤記やコード例の問題は別途確認が必要です。

このスコアからは、事実の正しさや論拠の十分さは判断できません。読者が実際に理解できたかも分かりません。文書が長いほど指摘が増えやすく、点数を異なる文書や著者の順位付けに使うのも不適切です。

診断スクリプトはローカルで実行できますが、添削全体がオフラインで完結するとは限りません。本文をLLMに渡す際は、利用する実行環境やモデル提供元の設定で、データの扱いを確認する必要があります。

終了条件も、100点にすることではありません。すべての指摘に判断が付き、新たに修正すべき指摘がなく、変更禁止の情報が保たれていることです。編集と再診断は1回のスキル実行で最大3ラウンドとし、解決しなければ未解決の項目を報告します。

選び方：修正文が欲しいのか、修正を説明・確認する手順も必要か

LLM単体とkotonohaの違いは、「どちらが日本語を知っているか」ではありません。どちらもLLMの文脈理解と生成能力を使います。

修正文を手早く得たいなら、まずはLLM単体で十分な場合があります。修正理由を共有し、同じ基準で繰り返し確認したいなら、kotonohaのように診断とレビューの手順を組み合わせる意味があります。

最終的な文章が同じでも、どこを測り、何を直し、何を意図的に残したかを確認できます。その確認材料を追加することが、kotonohaの日本語添削の特徴です。

実装・仕様へのリンク

以下のkotonohaのリンクは、本記事で参照したコミットに固定しています。