記事一覧

2026-09-16 00:00:00

AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ

AIと小説をつくる仕組み・全8回 第7回

――設定を誰に、どの条件で使わせ、評価後にどう改稿するか

AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ

AIと小説をつくる仕組みを紹介する、全8回連載の第7回です。

前回の 「時系列と確定事実 — 矛盾はここで起きる」 では、過去の出来事を記録し、次の場面と照合する工夫を紹介しました。 今回は、それらをどう組み合わせてAIに使ってもらうかという話です。

これまで、作品の目的、文体、人物、タイムライン、用語集について書いてきました。 ほかにも、各回で何を描くかを決めた場面設計があります。

必要な設定をそろえても、AIが適切に参照し、作品に反映するとは限りません。 何を読んでから書くのか。設定が食い違ったら何を優先するのか。 書いた本文を誰が確かめ、どこへ戻して直すのか。 その手順も設計する必要があります。

第1回「AIが働く環境をつくった一年」 では、AIと制作する仕組みを四つの層で整理しました。 今回は、そのうちの「Harness Engineering — AIが働く『環境』を設計する」と 「Loop Engineering — 生成・評価・修正の『反復』を設計する」を、実際の執筆工程から紹介します。 以下では、それぞれを短く「ハーネス」「ループ」と呼びます。

これまで整えてきた設定ファイルを、どの担当AIエージェントに、どの条件で使わせるか。 そして、評価で見つかった問題を、どう次の改稿へ戻すか。 問い50までの制作記録をもとに、そのつながりを見ていきます。

1.設定ファイルを、執筆の手順につなぐ

「何を渡すか」の次に、「どう使うか」を決める

人物設定には、その人が何を願っているかを書きます。 タイムラインには、いつ何が起きたかを残します。 場面設計には、その回で起こす出来事や、中心となる場面を記します。

それぞれ役割が違うので、AIにまとめて渡すだけでは、どの情報を何の判断に使うかが曖昧になります。

そこで、執筆担当AIエージェントには、その回に関係する設定を読み直してから書くよう指示しています。

日付や小道具の状態は、以前のチャットで伝えたから覚えているはず、と考えず、 執筆のたびに設定ファイルを読み直して確認させます。

読む順序と、判断の優先順位も分けて考えます。 後から読んだファイルが、そのまま優先されるわけではありません。 記述が食い違った場合は、あらかじめ定めた優先順位へ戻ります。

何を読むかに加えて、読んだ情報をどう扱うかまで決める。
これが、小説を書くためのハーネスの中心です。

入口になる二つのファイル

この運用を記述しているのが、AGENTS.mdCLAUDE.mdです。

制作を始めるときの入口として、依頼の受け取り方、執筆から評価へ進む手順、保存方法、 改稿や承認の扱いを伝えます。 ファイル自体がプログラムを実行するのではなく、AIが作業するときに従う指示書です。

二つのファイルは、使う環境に応じて参照される入口として用意し、同じ運用内容を保つ方針にしています。

たとえば、AGENTS.mdには、次のような依頼の読み分けがあります。

私が入力すること AIに行わせること
Q44を書いてください 執筆し、各担当AIエージェントが評価し、結果を統合する
Q44を本文だけ書いてください 本文の執筆だけを行う
Q44を書き直してください 最新稿と評価レポートを読み、改稿して再評価する
Q44を承認してください 確定稿を保存し、タイムラインと用語集を更新する

「書いてください」という短い依頼の後ろに、必要な作業をあらかじめ置いておきます。 毎回、同じ長い指示をチャットに書かなくても、何をどこまで行うかが決まります。

場面設計を、均等に文章化しない

場面設計に書かれたことを、順番にすべて文章にすれば小説になるわけではありません。

そこで、執筆担当AIエージェントには、本文を書く前に、必ず入れる出来事、表現の候補、禁止事項、 核となる場面、短く処理する場面、分量を取り出すよう指示しています。

必ず入れる出来事と、使ってもよい表現の候補を分ける。 中心となる場面に分量を寄せる。すべての出来事を同じ長さで並べない。

問い50では、二人が答案を広げ、一緒に分からない問題を調べる場面を書きました。 その後、勉強の場面を約250字短くした版を作っています。

再評価では、会話の奥行きを見る担当AIエージェントが、短くしても 「二人とも分からない問題を一緒に調べる」という場面の働きは保たれていると確認しました。

大切なのは、勉強の手順を残らず書くことではありません。 片方が教え、片方が教わるだけの関係にならず、二人が一緒に取り組んでいることです。

こうした場面の核を、執筆時にも改稿時にも確かめられるようにします。

2.四つの視点で読み、それぞれの問題を見つける

同じ本文を、違う観点から読む

本文ができたら、執筆担当AIエージェントの自己確認を経て、評価へ進みます。

問い50までの基本となる評価は、四つの観点に分けています。それぞれに別の指示文があります。

担当AIエージェント 主に見ること
創造性の担当AIエージェント 人物が動いているか、場面に引っかかりや余白があるか
読者視点の担当AIエージェント 本文だけで理解でき、続きを読みたくなるか
会話の奥行きの担当AIエージェント 本音と建前のずれや、言わないことが働いているか
情景と感情の担当AIエージェント 場所や身体の描写から、感情を受け取れるか

実際に問い50のv3では、評価する場所が分かれました。

読者視点の担当AIエージェントは、前の回を読んでいないと一瞬分かりにくい言い回しを指摘しています。 一方、情景と感情の担当AIエージェントは、6月という時期が日付の情報にとどまり、 湿度などの体感が弱いと指摘しました。

会話の奥行きの担当AIエージェントは、莉子が保管していた絵について言う 「捨てる理由ないし」という台詞を評価しています。 保管していた理由を説明せず、言葉の表面と、その下に読めるもののずれを残しているからです。

同じ原稿でも、読む入口が違えば、拾うものが変わります。 評価を分けることで、何を残し、何を検討するかが具体的になります。

読者役には、設定を渡さない

役割を分けるときには、渡す情報も変えています。

読者視点の担当AIエージェントには、設定ファイルや場面設計、ほかの評価レポートを渡しません。 今回の本文だけを読ませます。

設定を知っていれば、本文に書かれていない理由を補えてしまいます。 作者の意図を知っているから理解できたのか、本文だけで理解できたのかが分からなくなるためです。

問い50の評価で「前の回を読んでいないと分かりにくい」と指摘できることも、この読み方に意味がある理由です。 その指摘を受けて、説明を足すか、連続して読む作品として残すかを検討できます。

一方、整合性を確認する担当AIエージェントには、設定と確定稿を読み直させます。

問い50には、莉子の「真帆方式」に、ルミが「真帆さん方式」と返す短いやり取りがあります。 会話としては、姉を呼ぶ妹と、憧れている相手を呼ぶルミの違いが出ています。

同時に、整合性の確認では、ルミがすでにその名前を知っているかを確かめる必要があります。 問い47で命名が成立しているため、問い50で使える呼び名です。

言葉の面白さを読むことと、その言葉を使える時点かを確かめること。
両方が必要なので、担当AIエージェントと渡す情報を分けています。

複数の指摘を、改稿する箇所へまとめる

問い44の初稿では、ルミが不満をぶつける長い台詞に、複数の担当AIエージェントが注目しました。

創造性、読者視点、会話の奥行きの評価が共通して指摘したのは、 不満が経緯どおりに並び、報告のように整いすぎていることでした。

整合性の担当AIエージェントは、同じ台詞の「仕事くださいって」という言い方が、 問い42での実際の発言と少し違うことを指摘しています。

統合担当AIエージェントは、これらを同じ箇所の改善提案としてまとめました。

次の版では、台詞が途中で切れる形になっています。

「お姉さんも。弟子にしてって言ったら、募集してないって。お父さんは、信じるんだ、って。信じて、どう――」

再評価では、長台詞の整いすぎと、過去の発言との微差が解消されたことを確認しています。

「もっと自然な会話にする」という依頼だけでは、何を変えるかが曖昧です。 誰がどこを問題にしたかをまとめ、次の原稿で直す箇所へつなげます。

3.評価を、次の改稿へ戻す

ループの指示は、どこにあるのか

評価が終わると、統合担当AIエージェントが各レポートを読み、総合点と改善提案をまとめます。 その指示文が、99_integrated_analyzer.txtです。

点数の計算方法だけでなく、優先して直す箇所、修正の大きさ、次にどの評価を行うかも定めています。

一方、改稿を依頼されたときに、どの原稿とレポートを読み、どこまで実行するかは、 AGENTS.mdCLAUDE.mdに書いてあります。

ループは、一つの専用ファイルにまとまっているわけではありません。 運用ファイルが改稿の進め方を定め、統合担当AIエージェントの指示文が評価結果を次の修正へつなぎます。

設定を確認する → 本文を書く → 各担当AIエージェントが評価する
→ 結果を統合する → 改稿を依頼する → 次の版を書き、再評価する

現行の基本コマンドでは、「書き直してください」と依頼すると、改善提案を反映し、評価と統合まで一巡します。 「優先度1だけ反映してください」と指定した場合は、その範囲を直し、再評価は明示して頼む扱いです。

どこを直すか、どこまで評価を回すかを指定できるようにしています。

原稿と評価を、同じ版で残す

ループを回すには、評価がどの原稿に対するものかを間違えないことも必要です。

原稿はq44_v1.md、次の版はq44_v2.mdというように保存し、 評価レポートにも同じ版番号を付けます。原稿は上書きしません。

問い44では、長台詞の問題が解消された後のv2でも、別の指摘が残っていました。

理由になっているような、なっていないような答えだった。

この一文を、読者より先に地の文が答えを採点していると最初に指摘したのは、v2の評価です。 v4でも指摘され、確定稿で削除しました。

版を残していれば、何がいつ指摘され、いつ直ったかを確かめられます。 「評価されて直した」という一つの話にまとめず、 どの原稿に対する評価だったかをたどれるようにしています。

点数は、改稿の良し悪しを一つで表せない

総合点は、原稿の状態を確認する目安になります。承認基準の一つは85点以上です。 ただし、必要な評価がそろい、重大な矛盾や規則違反がないことなど、ほかの条件も満たす必要があります。

問い50では、勉強の場面を約250字短くしたところ、総合点はv2の90点からv3の88点になりました。

一方、v3のレポートでは、創造性と情景の担当AIエージェントが、中盤のもたつきが解消したと評価しています。 会話の奥行きの担当AIエージェントも、二人が一緒に取り組む場面の働きが保たれたと確認しました。

レポートには、評価が別のセッションで行われたため、数点の揺れを含むという注記もあります。 この記録から、短くしたことが点数を下げた原因だとは言えません。

点数だけなら、前の版へ戻したくなるかもしれません。 しかし、何を直そうとして、本文がどう変わり、各評価が何を確認したかまで読むと、判断する材料は変わります。

問い44でも、総合88点の稿に残っていた地の文の指摘三箇所に対し、 確定稿では二つを削除し、一つを残しています。

ループの目的は、評価の指摘をすべて消すことではありません。
作品に必要な表現を残しながら、問題を直すことです。

止める条件と、次へ渡す条件を決める

整合性を確認する担当AIエージェントが重大な矛盾を見つけた場合は、 ほかの評価が高くても承認不可にします。 面白さの点数で、事実の食い違いを埋め合わせないためです。

後半の制作では、本文の現実性を見る担当AIエージェントと、 執筆前に調査記録の根拠の確かめ方を検査する担当AIエージェントも加えました。 進める手順と同じように、止める条件も必要になったからです。

そして、承認するときには、本文を確定するだけでなく、次の回へ渡す記録も更新します。

問い47では、莉子からのLINEで『真帆』という名前が伝わります。 それまで「お姉さん」だった人の名前を、ルミが知る場面です。

評価レポートは、本文を承認できる水準としつつ、命名などを設定へ反映する必要も挙げています。 用語集には、問い47で名前が伝わったことが記録されています。 その記録が、問い50の「真帆さん方式」という台詞を支えます。

今回の本文で起きたことが、次の回の前提になる。 前回紹介した記録の仕組みも、ここで執筆の流れにつながります。

経営に置き換えると

業務でも、AIに資料を渡して「提案書を作って」と頼むだけでは、 何を根拠に書き、誰に確認してもらうかが曖昧になります。

提案書なら、顧客の要望、社内の商品情報、承認済みの価格を参照させる。 作成後は、顧客に伝わるかを読む担当AIエージェントと、価格や提供条件を照合する担当AIエージェントを分ける。 未承認の条件が含まれていたら、提出前に止める。こうした手順が、ハーネスにあたります。

確認で見つかった問題をまとめ、修正した版を作り、直した箇所を再確認する。その反復がループです。 提案書と確認結果に同じ版番号を付けておけば、 古い価格を直したのか、前の版への指摘が残っているだけなのかも区別できます。

小説の制作で設計してきたのも、同じことです。 何を参照するか、何を確かめるか、どの条件で止めるか、修正をどこへ戻すか。 AIに任せる仕事を、この単位まで具体的にしておきます。

設定ファイルに、作品の判断基準を書く。 ハーネスで、その基準を誰がどの場面で使うかを決める。 ループで、評価を本文の修正へ戻す。

小説を書くうえで私が大切だと感じているのは、このつながりです。 設定を詳しく書くだけでなく、その設定が執筆と評価のどこで働くかまで設計しておきます。

次回は、全8回の最終回です。 一年の運用で捨てた設計と、設定ファイルに書いても保証できなかったことを振り返ります。

関連する運用ファイルと指示文

AGENTS.mdCLAUDE.md

制作の入口となる運用指示です。 依頼の解釈、執筆・評価・改稿の流れ、版の保存、承認、失敗時に止める条件を定めます。

00_priority.md

設定が食い違った場合に、どの指定を優先するかを定めます。

1_writer_agent_extended_v2.txt

執筆担当AIエージェントへの指示文です。 執筆前に参照する設定、場面設計から取り出す項目、本文を出す前の確認などを定めます。

2_creative_evaluator.txt3_reader_validator.txt4_dialogue_complexity_evaluator.txt5_landscape_emotion_evaluator.txt

基本となる四つの評価担当AIエージェントの指示文です。観点と、必要な入力を分けています。

7_consistency_validator.txt8_simulation_reality_evaluator.txt9_research_integrity_validator.txt

それぞれ、設定と本文の整合性、本文の現実性、執筆前の調査記録の根拠の確かめ方を検査します。

99_integrated_analyzer.txt

評価を統合し、総合点、優先度別の改善提案、合否判定、再評価の対象をまとめるための指示文です。

前回: 時系列と確定事実 — 矛盾はここで起きる

次回: 「一年運用してわかった、設定ファイルの限界」