「この文章を自然な日本語に直して」と大規模言語モデル（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による修正文まで同じになるとは限りません。診断の比較可能性と、生成文の再現性は区別します。
ベースラインの照合にも限界があります。カテゴリーと正規化した抜粋で指摘を識別するため、表現が変わると同じ問題でも新規と扱われる場合があります。数字も正規化するので、指摘が継続していることは数値が保存された証拠になりません。
同じ修正文でも、確認できる情報が違う
違いを、短い例で見てみます。次の文を添削対象にします。
この機能においては、設定ファイルを編集することが可能です。
管理者は、更新前に設定ファイルを保存しなくてはならない。
修正案は、たとえば次のようになります。
この機能では、設定ファイルを編集できます。
管理者は、更新前に設定ファイルを保存する必要があります。
この修正案は、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のリンクは、本記事で参照したコミットに固定しています。