AIの本文がWeb小説で読まれにくい理由
私はWeb小説を書いています。Claude Code や Codex に本文を頼むと、文章としては整っているのに、Web小説としては読まれにくい本文が返ってくることがあります。
朝日で目を覚ます冒頭や「彼は嬉しかった」で終わる段落、「こうして一日が終わった」という章の締め。
書き手の目で見ると、どれも読者に次の話を開いてもらえない書き方です。
プロンプトで毎回注意しても、話数が進むと元に戻りがちです。
困るのは文体の癖だけではありません。
一人称の主人公が相手の内心を言い当てたり、口調サンプルにない話し方をキャラが始めたりと、作品の中で決めた約束も崩れていきます。
AIに足りないのは文章力より、視点や口調や結末といった作品ごとの約束を最後まで守る力だと私は考えています。
その約束を設計ファイルとスキルに移したのが light-novel です。
本文を丸ごと任せるより、プロットと口調を固める相談と、書いた本文の違反探しに向けて作りました。
インストールと頼む順番
npx skills add SilentMalachite/light-novel-skill
エージェントを指定するときは -a claude-code、-a codex、-a grok のどれかを付けます。全プロジェクトで使うなら -g です。
このコマンドで入るのはスキル本体だけです。
エージェントが毎回読む CLAUDE.md（Codex と Grok Build は AGENTS.md）は、このリポジトリにあるものを、使うプロジェクトの直下へコピーしてください。
既にあるなら末尾に追記します。CLAUDE.md はスキルの場所を .claude/skills/light-novel/ として書いているので、-g で入れたときは ~/.claude/skills/light-novel/ に読み替えます。
使い始めの流れは次の4段階です。
- 「コンビニでバイトしてる元魔王が主人公のラノベを書いて」のように頼む。作品フォルダに
plot.mdとcharacters.mdの雛形が置かれ、質問が返る - 質問に答えて、ログライン、視点、結末、キャラの口調を固める
- 「plot.md の第1話、1場面目を書いて」と、話と場面を指定して本文を頼む
- 「第1話を推敲して」「第1話をレビューして」「AI臭くないかチェックして」のどれかを頼む
AIが書きがちな癖を1ファイルに集めると、こうなる
リポジトリにはテスト用に、AIが書きがちな癖を詰め込んだ本文を置いています。冒頭を抜粋します。
朝の光がカーテンの隙間から差し込み、俺は目を覚ました。
窓の外には雲ひとつない青空が広がっていた。まるで今日という日を祝福しているかのようだった。
「おはよう。今日もいい天気だね。」
幼なじみのユイが言った。俺は息を呑んだ。彼女の笑顔は、まるで太陽のような輝きを放っていた。
俺は嬉しかった。
（中略）
こうして、俺たちの新しい一日が終わった。
日本語としての誤りはありません。気になるのは最初の文と最後の文です。
最初の文は天気と目覚めで始まっていて、誰の話で、主人公に何が欠けているのかが見えません。
スマホで縦に読むWeb小説では、ここで読み続けるかが決まりがちです。
最後の文は、その日の出来事を要約して締めています。章末で話を閉じると、読者が次の話を開く理由がなくなります。
比べるために、同じテスト用にチェックを通る側の本文も置いています。こちらはコンビニで働く元魔王の話です。
「レジ、もう一台開けて」
店長の声に、俺はバックヤードから飛び出した。
夕方六時のコンビニは戦場だ。弁当の棚は半分空いて、レジ前には五人並んでいる。
最後は、カウンターに残ったレシートの裏に知らない文字が書いてある場面で切れます。最初の3行で場所と主人公の立場が分かり、最後に未解決が1つ残ります。
本文より先に、ログライン・視点・結末・口調を固定する
スキルの中心にあるのは「設計ファイルが正本で、本文はその実装」という考え方です。チャットの履歴は流れて消えるので、正本にはなりません。
スキルは本文を書く前に、作品フォルダへ plot.md と characters.md を置き、この2ファイルを正本にします。最初の依頼では雛形を置き、依頼文から分かる項目だけを埋めて、残りを最大3つの質問にして止まります。この回に本文は書きません。
答えると、plot.md の先頭が次のように固まります。
- ログライン: 角を隠してコンビニで働く元魔王が、正体を知る勇者の末裔に追われながら、店と居場所を守る話。
- 視点: 一人称
- 一人称: 俺
- 結末: 魔王の名を捨て、店長代理として店に残る。勇者とは客と店員のまま決着する。
結末がないまま書くと、中盤が設定説明で膨らみます。だから結末も本文より先に決めさせます。
characters.md には、キャラごとに役割、欠落、行動原理、一人称、語尾、禁止語、口調サンプル3つを書きます。サンプルはこのくらいの短さで足ります。
主人公: 「……別に、構わないけど」
ヒロイン: 「構わない、じゃなくて。ちゃんと見てよ」
敵: 「見る必要はない。終わるだけだ」
口調サンプルがないキャラのセリフは書かせません。
話者タグ（「と、アヤが言った」）を外しても誰の発言か分かること、というルールも置きました。
AIに任せると、どのキャラも同じ丁寧さで話しがちなので、ここは強めに縛りました。
頼まれていないことはさせない
AIに1場面を頼むと、気を利かせて次の場面まで書いたり、新キャラを足したり、最後に「いかがでしょうか。続きも書けます」と付けたりします。
頼んでいない本文は、書き手が読む手間を増やすだけです。既出の設定を上書きされると、正本と食い違って後で直す羽目になります。
依頼の種類ごとに、やることとやらないことを決めました。
| 種別 | やること | やらないこと |
|---|---|---|
| 構築 | ログライン、結末、キャラ口調、話ビート、場面カード | 本文、世界設定の百科 |
| 執筆 | 指定した場面か章の本文 | 前後の章の先書き、新キャラの追加 |
| 推敲 | 視点漏れ、説明、AI調、口調の最小修正。レビューと文体チェックは書き換えずに違反を返す | 筋の勝手な改変、文体の盛り直し |
執筆を頼まれても、先に場面カードを埋めます。
- 視点人物:
- 場所・時刻:
- 目的（視点人物がこの場で欲しいもの）:
- 入口の圧:
- 障害:
- 結果（成功 / 失敗 / 代償）:
- 状態変化（情報・関係・身体のどれが変わったか）:
- 出口の未解決:
- 守る既出事実:
入口の圧は、場面が始まった時点で視点人物を押している状況です。
出口の未解決は、場面の終わりに残す問いです。空欄があるうちは本文を書かないので、心情だけの場面や何も変わらない場面はカードの段階で弾けます。
レビューを頼まれたときはまず違反を箇所つきで返します。直すかどうかは書き手が決めて、修正が必要なら修正します。
- [視点] 3章2場面: 一人称なのに相手の内心を断定している。伝聞か、観察できる動作に置換。
- [章末] 4章: 解決して終わっている。未解決を1つ残す。
Web小説の体裁に合わせた文体ルール
文体のルールは references/style.md にまとめています。
純文学の作法より、スマホで縦に読まれるWeb小説の体裁を優先しました。抜粋します。
- 地の文と会話の切り替わりで空行を1行入れる
- 閉じ括弧の前に句点を付けない。「！」「？」「……」は付ける
- 会話比率の目安は30〜45%。地の文が2割を切る長い話は会話過多として扱う
- 1文は40字前後を目安にし、長文は山場だけにする
AI調として回数を絞る語の一覧も持っています。
「息を呑んだ」「瞳が揺れた」「胸の奥が熱くなる」「〜せずにはいられなかった」「〜と言えるだろう」などで、どれも1話につき1回までです。
人間の書き手も普通に使う表現なので、全面禁止にはしていません。困るのは連発で、1話に3回息を呑む主人公は読者に笑われます。
文体チェックは、検出をスクリプトに、判断をエージェントに任せる
「この本文、AI臭くないかチェックして」と頼むと、スキルはまず check_style.py で機械的に検査します。スクリプトの場所はエージェントがスキルのフォルダから割り出すので、頼むときにパスを書く必要はありません。
下はリポジトリを clone した状態で、先ほどの癖だらけのファイルに手で実行した結果です。自分で実行するときだけ、パスをインストール先に合わせてください。
$ python3 .claude/skills/light-novel/scripts/check_style.py tests/fixtures/ai_like.md
- [冒頭] 3行目: 天気・目覚め・通学路で始まっている。視点人物の欠落かフックが見える場面から入る。
- [比喩] 5行目: 段落を比喩で締めている。締めは事実か動作にする。
- [句点] 7行目: 閉じ括弧の前に句点がある。句点を取る。
- [比喩] 9行目: この場面で比喩が2つ目。1場面1つまで。
- [感情ラベル] 11行目: 感情の名前で段落を終えている。動作か身体に置き換える。
- [文末] 13行目: 地の文の文末「いた」が3連続。1つ変える。
- [説明] 15行目: 段落が151字ある。会話か動作で割る。
- [長文] 15行目: 1文が85字ある。山場でなければ割る。
- [長文] 15行目: 1文が64字ある。山場でなければ割る。
- [の連続] 17行目: 「の」が3つ以上続いている。語順を変えて切る。
- [AI定型] 19行目: 「息を呑んだ」が2回目。1話1回まで。動作か状況に置き換える。
- [記号] 21行目: 本文に太字記法か絵文字がある。外す。
- [章末] 23行目: 要約で締めている。未解決を1つ残して切る。
会話比率 14% / 地の文の平均文長 24.6字 / 違反 13件
1行目が見出しの # 第1話 なので、本文の最初の文は3行目になります。
元魔王のほうのファイルにかけると、違反は0件、会話比率29%、平均文長16.1字でした。
ただし、どちらもテスト用に用意した文章で、実際の作品での誤検出率はまだ測っていません。違反があれば終了コード1を返すので、CIやpre-commitにも組み込めます。
検出を正規表現に任せたのは、書いたのと同じAIに自分の文章を確かめさせても、同じ癖を見落としやすいためです。冒頭の天気、閉じ括弧前の句点、「の」の3連続のように形で判定できるものは、スクリプトに毎回同じ結果で拾わせたほうが確実です。
一方で、山場で意図して長い文を書くこともあれば、キャラの口癖として定型句を言わせることもあります。
エージェントには、スクリプトが出した違反から誤検出を理由つきで外させ、機械では決められない項目を判定させます。
テンポ、一人称の地の文がそのキャラの語彙になっているか、掛け合いがキャラの関係を見せているか、といった項目です。返すのは違反一覧と判定と統計だけです。
スクリプトは Python 3 の標準ライブラリだけで書きました。Python がない環境でもスキルは動き、その場合はエージェントが references/check.md の検査項目を目で確かめます。
常時指示は呼び出し条件1行とルール5行だけ
CLAUDE.md（Claude Code 用）と AGENTS.md（Codex と Grok Build 用）は、どちらも呼び出し条件の1行とルール5行でできています。ルールの中身は少し違い、CLAUDE.md はこうなっています。
日本語のラノベ、ライトノベル、Web小説について、企画、プロット、キャラ、地の文、セリフ、章立て、文体の作成、執筆、推敲、レビュー、文体やAI臭さのチェックを頼まれたら `.claude/skills/light-novel/SKILL.md` に従う。純文学、脚本、論文、翻訳には使わない。
- 設計ファイルが正本。本文の前にログライン、視点、結末、口調を固定する。
- 依頼は構築 / 執筆 / 推敲のどれか一つ。指定外はしない。
- 視点は固定。頭跳ね、設定講義、文学調の足し、AI調の定型をしない。
- 出力は本文か指定メモだけ。解説は頼まれたときだけ。
- 質問は最大3つ。口調サンプルが無いキャラのセリフは書かない。
常時指示は毎回のコンテキストに載るので、長く書くほど他の作業の邪魔になります。詳しい手順は SKILL.md に、構成・文体・レビュー・チェックの詳細は references/ の各ファイルに分け、必要になったときだけ読ませています。
呼び出し条件の文言は、SKILL.md の description、CLAUDE.md、AGENTS.md の3か所でそろえ、README にも同じ文を控えとして載せました。どれか1か所だけ直すと、Claude Code と Codex で起動条件が食い違うおそれがあります。
CIはインストール経路まで確かめる
GitHub Actions では、ubuntu・macOS・Windows と Python 3.9・3.13 の組み合わせで単体テストを回しています。もう1つのジョブでは、一時ディレクトリに npx skills add -a claude-code で実際にインストールし、必要なファイルがそろっているか、雛形を置くスクリプトが動くかを確かめます。スキルは配布先で壊れても作者が気づきにくいので、npx skills add でのインストール手順もテストに入れました。Codex と Grok Build への配置は、まだCIで確かめていません。
書きかけの1話から試せる
文体チェックは plot.md がなくても動くので、手元の1話に「episode01.md、AI臭くないかチェックして」と頼むだけで試せます。設計ファイルは、結果を見て使えそうだと思ってから作れば十分です。
どこまでAIに書かせるかは、使う人が決めてください。
不具合や要望、特に自分の作品で出た誤検出の例を、GitHub の Issues で教えてください。