Babechat ユーザガイド

プロンプトのフォーマットと変数[応用]

キャラクターをより安定的に構築するためのフォーマットと変数ガイドライン

※本ガイドラインは2025年8月時点で作成されたものであり、LLM研究の進展やBabeChatのプロンプトエンジニアリングに応じて内容が変更される場合があります。

{{char}}と{{user}}は、キャラクター詳細設定で使用できる便利な変数です。これらを使用すると、ペルソナやキャラクター情報に応じて変数の値が自動的に置き換えられます。

  • {{char}}:キャラクターの名前に自動的に置き換えられます。

  • {{user}}:ユーザーが現在使用しているペルソナのニックネームに自動的に置き換えられます。

変数がどの情報を取得するのか正確に理解して使用することが重要です。特に {{char}} は「キャラクター名」フィールドのテキストをそのまま取得するため、正しい名前と変数形式を使うことが不可欠です。

悪い例 1: 不適切なキャラクター名

  • 設定キャラクター名:ビビの消えた夏休み

  • キャラクター詳細設定:{{char}}はBabeChatのCS担当者です。

→ モデルは{{char}}をキャラクター名そのままで置き換えるため、以下のようになります。(実際の入力):ビビの消えた夏休みはBabeChatのCS担当者です。

悪い例 2: 誤った変数形式の使用

  • キャラクター詳細設定:{char}はBabeChatのCS担当者です。

→ {{char}} ではなく {char} のように誤った括弧形式では変数として認識されません。(実際の入力):{char}はBabeChatのCS担当者です。

良い例

  • キャラクター名:ビビ

  • キャラクター詳細設定:{{char}}はBabeChatのCS担当者です。

→ {{char}} が「ビビ」に正しく置き換わり、自然な文になります。(実際の入力):ビビはBabeChatのCS担当者です。

キャラクターが一人の人物ではなく「ビビの会社生活」のように特定の状況やシミュレーションそのものを指す場合、{{char}} をそのまま使うと不自然な文になり、モデルが混乱する可能性があります。

悪い例

  • キャラクター名:ビビの会社生活

  • キャラクター詳細設定:{{char}}は{{user}}を新入社員として迎える。

→ 主語が「会社生活」となり文法的に不自然です。(実際の入力):ビビの会社生活は{{user}}を新入社員として迎える。

良い例

  • キャラクター名:ビビの会社生活

  • キャラクター詳細設定:ビビは{{user}}を新入社員として迎える。

→ 行為の主体を明確にすることで、より自然で正確な文脈が生成されます。(実際の入力):ビビは{{user}}を新入社員として迎える。

キャラクター詳細設定に入力する情報は、明確に構造化するほどモデルが安定的に認識します。基礎編で説明したように、人間が読みやすい文章はモデルにとっても理解しやすいのです。

Markdownは非常に可読性が高く、ヘッダー(#)、リスト(-)といった簡単な記号で情報の階層を明確に表現できます。これは制作者がキャラクター設定を管理しやすくするだけでなく、モデルが情報の重要度や関係性を把握する上で大いに役立ちます。BabeChatで最も安定した性能が期待できる形式です。

Markdown適用例

Plaintext
## キャラクタープロフィール

[基本情報]  
- 名前: ビビ  
- 職業: BabeChatのCS担当者  

[性格]  
- 気難しいが、最終的には依頼をすべて処理するツンデレタイプ。  
- 社長に対しては愚痴をこぼすが、意外にも社長の頼みは断れない。  

XMLはを用いてデータ構造を明確に定義できる方式です。精密な設定が可能ですが、Markdownに比べて可読性が低く、トークン消費も多いという欠点があります。

XML適用例

Plaintext
<character_profile>
[基本情報]  
- 名前: ビビ  
- 職業: BabeChatのCS担当者  

[性格]  
- 気難しいが、最終的には依頼をすべて処理するツンデレタイプ。  
- 社長に対しては愚痴をこぼすが、意外にも社長の頼みは断れない。  
</character_profile>

※TIP: Markdownヘッダー使用時の推奨構造

  • キャラクター詳細設定:ヘッダー数(#, ##など)は制限なく自由に使用可能。

  • ペルソナ/ロアブック:ヘッダーは「###」から使用することを推奨。

また、必ずしも決まったテンプレートに従う必要はありません。Markdownのヘッダー(#)やリスト(-)で情報を区分するだけでも、モデルの理解度は大きく向上します。一方で、基礎編でも触れたようにJSON形式はトークン効率や性能のばらつきの面から推奨されません。