なぜ「Greeting」がフロントエンド間で壊れるのか

典型的な破損パターンは次の3つ。

• プレースホルダ依存：{{user}} {{char}} を独自マクロやテンプレート構文で装飾し、他フロントで未展開のまま出力される
• UI 前提の演出：*斜体* や 「台詞」 の解釈、改行・空行の扱いがフロントごとに異なる
• 状態の埋め込み：特定の World Info／Lorebook 発火を前提にした挨拶で、知識が欠落した環境では意味が通らない

2026 年現在、SillyTavern 代替として iOS/Android アプリ、Web 版、Chrome 拡張など複数のフロントが併存している。カードを1枚書けば全環境で使える時代になった分、Greeting の「環境非依存性」が品質を左右する。

ポータブルな Greeting の設計原則

1. プレースホルダは素の {{user}} / {{char}} のみ使う

V2 標準のマクロだけに限定する。{{random}} や条件分岐マクロはフロントによって未対応・挙動差があるため、代替グリーティングの分岐で代替する。

× {{getvar::mood}} に応じて…
○ （代替グリーティングを3パターン用意し、状況別に書き分ける）

2. マークアップは最小公約数に合わせる

要素	安全度	備考
*動作描写*	高	主要フロントで斜体解釈される
"台詞" / 「台詞」	高	どちらも可読
空行による段落分離	高	プロンプト整形に影響しにくい
独自タグ <status> 等	低	未解釈で生テキスト化する
Markdown 見出し・表	低	チャット本文では崩れる

3. 最初の1文で「誰が・どこで・何をしているか」を確定させる

フロントが変わってもコンテキストは引き継がれない。Greeting は毎回ゼロから状況を提示する必要がある。Kaelen the Wandering Blade のような放浪者キャラなら、場所・天候・直前の行動を冒頭2文に畳み込む。

雨宿りのため軒下に身を寄せた。「……君も雨に降られた口か」

この程度の密度で、どのフロントでも情景が立つ。

4. ユーザーの入力を誘導する余白を残す

Greeting で問いを投げ、{{user}} の応答を自然に引き出す。長すぎる独白はトークン消費とフロント差の両面で不利になる。

代替グリーティングの実装手順

1. 基準となる First Message を1本書く（150〜250字目安）
2. 分岐軸を決める：時間帯／場所／関係性のいずれか1軸に絞る
3. alternate_greetings に2〜4本追加：各本は独立して成立させる
4. Lorebook 依存を除去：固有名詞の説明は本文に1行だけ埋め込む
5. 複数フロントで検証：SillyTavern、MiniTavern アプリ、Web Tavern、Chrome 拡張で表示確認

特に手順5は省略されがちだが、\n の扱いや空行の圧縮はフロント差が出る。検証せずに配布すると、購入者側で「改行が潰れて読みにくい」という評価に直結する。

フロントエンド移植性チェックリスト

• マクロは {{user}} {{char}} のみ
• 独自タグ・HTML・Markdown 表を使っていない
• 1つの Greeting が単独で状況説明として完結している
• 台詞と動作描写の比率が 6:4 程度
• 固有名詞の初出に最小限の説明がある
• 代替グリーティング同士で設定矛盾がない

このチェックを通せば、sillytavern-alternative な環境——ネイティブアプリでもブラウザでも——で同じ体験を再現できる。Character Card Market で配布する場合も、Greeting の品質はそのままレビュー評価に反映される。

まとめ

Greeting はキャラクターカードの「第一印象」であり、同時に最も移植性の影響を受けやすいパーツだ。V2 標準マクロに限定し、マークアップを抑え、各代替グリーティングを独立させる。この3点を守るだけで、frontend-portability は大幅に向上する。

MiniTavern では iOS/Android アプリ、Web Tavern、Chrome 拡張の各環境で同一カードを扱えるため、書き上げた Greeting の検証にも向いている。Kaelen the Wandering Blade のような完成度の高いカードは Character Card Market で入手できるので、代替グリーティング設計の参考として実際に読み込んでみるとよい。