teasa.ai
日本語
Teasaを開く

ロアブックとは?設定例から書き方を試してみよう

ロアブック(Lorebook)は、場所、用語、世界のルールなどを項目ごとにまとめ、会話に必要な設定を渡すための資料です。人物の話し方を書くキャラクター設定とは役割が違います。キーワードに応じて必要な項目を選ぶ仕組みや、常に使う項目を指定する仕組みがあります。

索引と地図の駒、つながる場所が描かれた世界設定の図冊
このガイドの内容

船が出るときには港の嵐のルールが必要です。酒場の全メニューは、たぶん必要ありません。まずは小さな世界で、必要な設定を必要な場面へ届ける方法を試してみましょう。

「ワールド情報」や世界設定集とも呼ばれます。このワークショップでは小さな港を作り、広すぎるキーワードを直して確かめます。選択の仕組みや文脈の上限は製品によって異なり、自然な返信だけで、どの項目が読み込まれたかは断定できません。

Teasaではロアブックを「ブループリント」と呼びます。項目数の上限、キーワードの扱い、物語へのつなぎ方はヘルプセンターで短くまとめています。

キャラクター設定・ロアブック・会話メモの違い

書きたい内容 整理する場所 例
人物の目的や口調 キャラクター設定 船長は出航を急いでおり、短い言葉で条件を伝える
場所や世界の安定したルール ロアブック 港の警鐘が三度鳴ったら、大型船は出航を止める
今回の会話で起きた出来事 その会話の履歴やメモ 旅人は手紙をまだ船長に渡していない

同じ文章を全部の場所に入れるより、何のための情報か分けると修正しやすくなります。人物の書き分けはキャラクターカードのガイドで詳しく紹介しています。

コピペして使える、最初の設定例

項目名:港の警鐘
キーワード:港の警鐘、出航の合図
内容:港の警鐘が三度鳴ったら、大型船は出航を止める。
船長は鐘の回数を確認してから、出航できるか判断する。

これは設定を書くための作例です。各サービスの入力欄に合わせて転記してください。実際に読む項目の選び方はサービスごとに違います。

試す言葉:「港の警鐘は何回鳴った?」ではこの項目を探し、「酒場で夕食を頼む」では別の項目を探す、と考えてみましょう。次のLabで実際のキーワード選択を確かめられます。

Lorebook Labで自分の設定を試す

Lorebook Labを開くと、港の作例を編集したり、JSONのロアブックを読み込んだりできます。入力に対して、どのキーワードがどの発言に一致したか、Teasaの設定枠にどの項目が収まるかを確認できます。修正前の版を保存すれば、同じテストで前後を比較できます。コピーを共有し、非公開のBlueprintとしてプロットへ接続することもできます。設定の選択とAIの返答は別です。実際の返答はプロット編集画面のPlay-testで確認してください。

「鐘」を直すと、何が変わる?

警鐘について聞いたのに、酒場の設定まで読み込まれる。この小さなずれを、同じ入力で確かめてみましょう。

  1. 日本語のLorebook Labを開き、作例メニューで港の例を選びます。手元に作業中の内容がある場合は、先に書き出して残してください。
  2. 「警鐘と酒場を区別」のテストを選びます。「鐘」が警鐘に一致すると、酒場の項目も選ばれます。一致した発言とキーワードを確認します。
  3. 比較用の版を保存し、酒場のキーワードを「鐘」から「沈んだ鐘」へ変更します。港のルールと修理の項目は変えません。
  4. 同じ三つのテストを実行します。警鐘の入力では港のルール、待ち合わせの入力では港のルールと酒場、修理の入力では港のルールと燃料管の項目が選ばれるか確認します。

修正後から見たい場合は、作例メニューの**「港の例:キーワード修正後」**を選べます。修正前の内容も比較用の版として入っています。この結果が示すのは、設定が選ばれるかどうかです。AIがその設定に従って返答するかは、次のPlay-testで別に確認します。

その設定を、会話の一場面へ

「Teasaで使う」からログインし、内容を確認して、非公開のBlueprintとして下書きに接続します。新しい下書きなら、キャストと導入を整えます。たとえば船長イオナには「出航を急いでいるが、港が閉じた後は無理に船を出さない」と設定します。

作者が書いた導入例:

二度目の警鐘が、桟橋を揺らした。イオナは封じられた手紙を持つあなたを見て、差し出しかけた手を止める。「燃料管がまだつながっていない。手を貸す? それとも、その手紙を先に読む?」

Play-testではまず「手紙は開けず、ソルの修理を手伝う」と返してみます。港のルールと現在の行動が両方扱われるか、自分が選んでいない行動まで書かれていないかを読みます。次に新しいテストで「沈んだ鐘で待つ。手紙は封じたままにする」と返し、場所を変えたときに必要な設定が使われるかを比べます。これは入力の提案で、生成結果の引用ではありません。

まずは三つの項目で世界を作る

以下は作者が書いた創作課題で、実運用の読み込み記録ではありません。プレイヤーは封じられた手紙を持つ旅人。船長イオナは出航したく、調査員レンは手紙を見たく、整備士ソルはエンジンを修理中です。

01 / 世界のルール

航路が閉じる期限

方式:この課題では常時。

嵐が近づき、港の警鐘が3回鳴ると航路が閉じる。その後は安全に出航できない。

導入の期限を保つ、短いルールです。

02 / 場所

酒場・沈んだ鐘

キーワード:沈んだ鐘、酒場・沈んだ鐘。

西の桟橋の隣にある酒場。欠航した船の客が待機する。店主は修理の手伝いと引き換えに情報を渡す。

すべての鐘ではなく、この場所に関係する設定です。

三つ目は船のエンジンです。キーワードを「船のエンジン」「燃料管」とし、「ソルが傷んだ燃料管を交換している。修理完了までは安全に始動できない」と書きます。警鐘の項目に混ぜなければ、別々に修正できます。

イオナだけが姉の筆跡を見分けることは、その人物の秘密。旅人が手紙を見せることは、この会話で起こる出来事。どちらも、すべての人物や別の会話で共有する世界の常識にしないようにします。

何でも拾うキーワードを直す

手元で試すなら、三つの設定と検証欄をまとめた日本語ワークシートを保存して使えます。上の港を題材にした、編集できるテキストです。末尾にTeasaのBlueprint編集欄への転記手順、プロットへの接続、Play-testまでの流れがあります。インポートファイルではないため、項目ごとに転記します。

広すぎる例: 酒場「沈んだ鐘」の項目を「鐘」で呼び出す。港の警鐘についての質問にも、関係のない酒場の設定が入るかもしれません。

絞った例: 酒場には「沈んだ鐘」「酒場・沈んだ鐘」を使い、航行ルールには「港の警鐘」を使います。警鐘が導入全体の重要な制約なら、その短いルールだけ常時にしてもよいでしょう。

物語で実際に使う言語でも確認します。日本語名で会話しているのに原語の名前しか登録していないなら、別名の追加が必要かもしれません。翻訳、表記揺れ、語形をすべて自動で理解するとは限りません。

増やす前に、四つの入力で試す

これはテストの狙いであり、実際の読み込み結果の報告ではありません。項目の読み込みを確認できる機能があれば、会話と照合します。なければ、返信は挙動の手がかりとして扱います。

入力 関係してほしい資料 調べるべき兆候
「港の警鐘は鳴った?」 航行ルール 酒場の客について答える
「沈んだ鐘で待ち合わせよう」 酒場の項目 名前のある場所を認識しない
「船のエンジンは直った?」 ソルの修理とエンジンの状態 修理前に出航する
「手紙は封じたままにする」 現在のプレイヤーの行動 未読の内容を既知の事実として話す

最初の返信に酒場が入り込むなら、重複したキーワードと最近の会話を確認します。エンジンが早く直るなら、項目を長くする前に別の場所の矛盾を探します。資料の選択、事実の衝突、モデルの使い方は別の問題です。

一つの事実に、一つの置き場所

情報 この課題での置き場所 理由
イオナは短く実務的に話す キャラクターカード 場面をまたぐ人物の特徴
警鐘で航路が閉じる 世界のルール プレイヤーの選択に関係なく適用
沈んだ鐘は波止場の酒場 場所の項目 その場所が関係するときに使う
筆跡を知っているのはイオナだけ 非公開の人物設定 知識の持ち主が決まっている
プレイヤーがレンに手紙を見せた 現在の会話履歴 この会話で起きたことで、すべての会話の過去ではない

ルールを変えるときは、その元の項目を直します。「前の説明は間違い」という項目を追加すると、両方が残ってしまいます。公開後の変更が既存会話へどう適用されるかも、製品のバージョン管理を確認してください。

小さな項目のテンプレート

題材:酒場・沈んだ鐘
読み込み:キーワード
キーワード:沈んだ鐘、酒場・沈んだ鐘
事実:西の桟橋の隣にある酒場。欠航した船の客が待機する。
      店主は修理の手伝いと引き換えに情報を渡す。
知識の境界:この項目では、プレイヤーの手紙の差出人を明かさない。

「知識の境界」は資料に書く指示です。専用の画面項目がある、必ず秘密が守られる、という意味ではありません。キーワードや読み込み方式は、実際の編集画面の欄へ設定します。

文章を足す前に、原因を切り分ける

  1. 本が、テスト中の作品とそのバージョンに接続されているか。
  2. 会話に実際に出る名前や別名で、項目を呼び出せるか。
  3. 常時の資料が長すぎて、ほかの指示や最近の会話を圧迫していないか。
  4. 古いエンジンの状態、重複した場所、人物設定との矛盾がないか。
  5. 資料が渡された後に、モデルが正しく使えたか。

少数の項目で四つの入力を試し、結果を残します。新しい題材は、場面に必要になってから追加しましょう。人物側はキャラクターカードのワークショップ、実際の生成例は会話ガイドへ進めます。

関連する設定、似た言葉、秘密を分けて試す

これは執筆した検証手順であり、特定の検索エンジンが合格したという記録ではありません。「嵐の警鐘が3回鳴ったらフェリーは運航を止める」という設定を用意します。別の非公開キャラクター設定には「手紙の差出人を知るのは船長だけ」と書き、導入は固定します。

新しい会話での入力 応答で確認すること
「嵐の警鐘が3回鳴ります。出航できますか」 出航したくても運航停止のルールが保たれるか
「カフェで夕食のベルが鳴ります。出航できますか」 無関係のベルを嵐の警鐘と取り違えないか
「整備士に手紙の差出人を尋ねます」 船長だけの知識を整備士が勝手に持たないか

各入力を3回試します。次にフェリーの項目だけを、条件が明確な表現に変えてもう一度試します。計18件の応答を残し、ルール維持、誤反応、知識漏れを別々に数えてください。一つの改善が別の悪化を隠すこともあります。

使用ツールに項目選択の診断があれば確認します。なければ応答で観察できることだけを記録してください。正しい文章が出ても、狙った項目が取得された証明にはなりません。誤答だけで取得と生成のどちらが原因かも断定できません。Teasaの公開プレイ記録は応答の記録で、取得ログではありません。

自作の架空設定を使い、設定の版、言語、日付も残します。この実験の「秘密」に実際の認証情報や機密情報を使わないでください。

FAQ

ロアブックは永久の記憶ですか?

いいえ。作者が管理する背景資料です。読み込みは条件や設定、文脈の上限に左右され、渡された事実をモデルが誤用する場合もあります。

重要な項目はすべて常時にするべき?

場面で一貫して必要になる少数のルールに絞りましょう。大切な歴史でも、毎回長文で渡す必要があるとは限りません。

返信を見れば、項目が読み込まれたか分かる?

確実には分かりません。会話から同じ事実を知っていたり、渡された事実を書かなかったり、似た内容を作ったりできます。製品に確認機能があれば利用しましょう。

起きたことを全部、共有ロアブックへ保存するべき?

その会話だけの出来事は、会話履歴や適切な範囲の記憶へ置きます。共有資料へ混ぜると、別の会話が経験していない出来事を引き継ぐおそれがあります。