NovelAIで登場人物の設定を登録したのに、続きを生成すると年齢や所持品が変わる場合は、設定文を増やす前に、生成用の文脈へ入ったかを確認します。Lorebookに保存したこと、項目が有効であること、文脈に含まれたこと、生成文が設定を守ったことは、それぞれ別の確認です。
この記事はNovelAIのテキスト生成に関する公式資料を基にした切り分け手順です。実製品での操作・生成は行っていません。人物設定と確認ケースは説明用の架空例です。画像生成のキャラクター固定は扱いません。
目次
最初に、人物設定と現在の状況を分ける
たとえば、主人公の澪が港の倉庫へ戻る場面を書いているとします。設定を一つの長い説明にまとめず、何を保持したいかで整理します。
表は横にスクロールできます
| 情報 | 架空の記入例 | 置き場所の考え方 |
|---|---|---|
| 現在までの重要な経緯 | 澪は倉庫の鍵を返した。今は鍵を持っていない | Memoryの候補 |
| 今回の場面の方向 | 澪の視点で、入れない焦りを会話より行動で描く | Author’s Noteの候補 |
| 人物の基本設定 | 澪は港の修理工。弟の陸と暮らしている | Lorebookの人物項目の候補 |
これは編集上の配置例で、入力欄ごとに内容の種類が強制されるという意味ではありません。公式はMemoryを現在の設定や過去の出来事などの保持に使える欄、Author’s Noteを出力の方向を短い文で示す欄として説明しています。既定では両者が文脈に置かれる位置も異なります。
出来事が進んだら、現在の状況を更新します。「鍵を返した」と書いた後に、別の欄へ古い「鍵を持っている」が残っていないか確認してください。正反対の情報を同時に渡したまま、生成の設定だけを調整しても原因が分かりにくくなります。
Lorebookはタイトルだけで人物を伝えない
公式によると、LorebookのEntry Titleは整理用で、AIには見えません。人物名をタイトルだけに置かず、実際に文脈へ入るEntry Textにも書きます。
Entry Title：澪
Entry Text：澪は港の修理工で、弟の陸と暮らしている。
Activation Keys：澪
この例は入力内容の整理例です。画面へ一つの文章として丸ごと貼る指示ではありません。タイトル、本文、キーの各欄へ分けて入力します。
公式は、最近の文脈でActivation Keyが見つかると項目の本文が文脈へ挿入されると説明しています。さらにEnabledが無効なら、キーが見つかっても項目は入りません。「登録済みだから常に読まれる」と考えず、次の順で確認します。
- Entry Textに、人物名と必要な設定が書かれているか。
- Enabledが有効か。
- Activation Keysに、本文で使っている表記があるか。
- 対象の場面に、そのキーとなる語があるか。
- Context Viewerで、実際の組込み状態を確認する。
本文で「澪」ではなく「修理工」とだけ呼んでいるなら、人物名のキーだけでは期待した条件に合わない可能性があります。表記をそろえるか、必要な呼び方をキーとして整理します。ただし「彼女」など多くの人物に使う語を安易に追加すると、意図しない場面で同じ項目が対象になりやすくなります。
Context Viewerで含まれた情報を確認する
AdvancedタブのContextから、Last ContextまたはCurrent Contextを選ぶとContext Viewerを開けます。公式は、この画面でLorebook、Memory、Author’s Noteなどが文脈の中でどう扱われているかを確認できると説明しています。
確認するときは、どちらのContextを見ているかを記録します。設定を直した後の文脈を見ただけで、以前の生成にも修正後の情報が渡っていたとは判断しません。調べたい生成と、参照する文脈の時点をそろえてください。
Context Viewerの詳細には、次の項目があります。
表は横にスクロールできます
| 表示 | 調べること | 結果から分かる範囲 |
|---|---|---|
| Identifier | 目的の人物項目を見ているか | 別の項目との取り違えを防ぐ |
| Inclusion | 文脈へ含まれたか | 設定を登録しただけの状態と区別できる |
| Reason | 含まれた／除外された理由 | 次に確認する設定を絞れる |
| Key | 関係する起動キー | 想定した語との対応を調べられる |
| 本文表示 | 必要な設定文が残っているか | 項目名だけでなく、渡る内容を確認できる |
有効なのに非起動の項目を調べる場合、公式はShow non-activated entriesで表示を広げる方法も案内しています。また、HiddenにしたLorebook項目はContext Viewer内でも内容が隠れるため、見えないことだけで除外と判断しないでください。
文脈へ入っていても、生成文が設定を正しく使う保証にはなりません。ここで確かめるのは「何が渡ったか」です。その次に、生成された本文を作者の設定と照合します。
入らない場合と、入っていても矛盾する場合を分ける
以下は原因を切り分けるための架空ケースです。製品上で再現した試験結果ではありません。
表は横にスクロールできます
| ケース | 確認した状況の例 | 次に行うこと |
|---|---|---|
| A | Enabledが無効だった | 有効にする必要があるか判断し、組込みを再確認する |
| B | 本文は「修理工」、キーは「澪」だけだった | 対象を取り違えない表記・キーへ整理する |
| C | 項目は含まれるが「鍵を返した」が本文表示に残っていない | 文脈の長さやトリミングを確認し、必要な情報を短く整理する |
| D | 「鍵を返した」は含まれるが、生成文で鍵を取り出した | 生成文を採用せず、他の欄の古い情報や直前本文との矛盾を確認する |
CとDは別の問題です。Cでは情報が届く状態を調べ、Dでは届いた情報と生成文の関係を調べます。どちらも「もっと覚えて」と同じ依頼を繰り返すだけでは、修正理由が残りません。
公式は、設定によってLorebookなどの情報と物語本文が文脈の領域を取り合う場合があると説明しています。長い設定を追加し続ける前に、不要な説明や古い状況を減らします。トークン数を文字数と同じものとして計算したり、すべてのモデル・契約で同じ上限だと決めたりしないでください。
Always Onを万能な修正にしない
公式はAlways Onを有効にすると、キーの有無にかかわらず項目を文脈へ入れると説明しています。ただし、これを使う目的は起動条件を変えることです。人物設定への違反を防ぐ保証や、文脈の容量を増やす機能ではありません。
いつも必要な短い設定か、その人物が登場するときだけ必要な詳しい設定かを考えて選びます。全人物の長い項目を一律にAlways Onへ変える前に、Context Viewerで物語本文と設定の配分を確かめてください。
Placementなどの高度な配置設定は、モデルによって提供範囲が異なります。まずは本文、Enabled、キー、組込み状態を確認し、必要な場合だけ対象モデルの公式説明を読んで調整します。
再開できる記録を残して、次の場面へ進む
修正後は「項目を保存した」で終わらせず、対象の文脈に必要な設定が含まれることと、採用する本文が設定に矛盾しないことを別々に記録します。今回なら、少なくとも「澪は鍵を持っていない」と、生成文で鍵を取り出していないかを照合します。
記録には、場面、対象項目、変更した欄、確認したContext、採用した本文を残します。一度にキーと人物設定と文体指示をすべて変更せず、原因に対応する箇所から直すと、次の章でも判断を引き継げます。
作品全体の台帳や章ごとの整合確認を整える場合は、AIで小説を書くときのツール選びと使い方も参照してください。サービスへ渡す設定と、作者が正本として管理する作品設定を対応させて進めます。
確認した公式情報
- Story Settings：MemoryとAuthor’s Note（新しいタブで開く）
- Lorebook：本文・キー・有効化・Always On（新しいタブで開く）
- Advanced Settings：Context Viewerと文脈の配分（新しいタブで開く）
資料確認日：2026年10月21日。操作名、モデルごとの設定範囲、利用できる文脈の上限は、利用中の画面と契約条件を確認してください。