ゲーム状態の設計
面白いワールドには必ず追跡されているものがあります。Battle Royaleは40人の生徒と誰が生き残っているかを追跡します。Sakura Seasonは3つの独立した恋愛アークを追跡します。Wandering Diaryは仲間の態度、インベントリ、ロケーション状態を同時に追跡します。変数システムは、ワールドに記憶を与えるための仕組みです。
このガイドでは変数の選び方と設計の技術を解説します — ワールドのプレイ感覚を形作る判断です。変数の型とディレクティブの基本については はじめに：変数 を参照してください。
創造的な判断：何を追跡すべきか
エディタを開く前に、自問してください：プレイヤーが「リアル」だと感じるために必要なものは何か？
サバイバルゲームでは答えはリソース — 体力、空腹、弾薬。プレイヤーには希少性を感じてもらう必要があります。恋愛ものでは関係の深さ — プレイヤーは自分の選択が何かに向かって積み上がっていることを感じる必要があります。ミステリーでは知識フラグ — プレイヤーは捜査が絞り込まれていく感覚を必要とします。
何でもかんでも変数にする必要はありません。AIは物語の細部を見事に扱えます — 天候がメカニカルに重要でない限り current_weather 変数は不要です。判断と結果を駆動するもの を追跡しましょう。
経験則：次にAIが書くものに影響すべき値なら変数にします。単なる風味要素ならAIに即興させます。
変数の誕生から死まで
変数は明確なライフサイクルを持ちます：エディタで 定義 し（型、デフォルト、制約）、プレイヤーが新規セッションを開始したときデフォルト値で 初期化 され、プレイ中AIが括弧ディレクティブで 修正 し、さらに条件が満たされるとルールエンジンが 修正 することもあります。そして毎ターン終了時にゲーム状態全体がデータベースに 永続化 されます。
すでにプレイ中のワールドに新しい変数を追加すると、既存のセーブは次回ロード時に自動的にデフォルト値を取得します。変数を削除すると、それは静かに除外されます。誰のセーブも壊さずに変数設計を反復できます。
適切な型を選ぶ
4つの変数型（number、string、boolean、JSON）は はじめに：変数 で説明しています。設計上の判断は いつどれを使うか です。なぜならその選択がAIとワールドのやり取りに影響するからです。
Number は、値が徐々に変化する場合、イベントのしきい値が必要な場合、変化の大きさが意味を持つ場合に使います。Numberはエンジンが min/max 境界を強制するので、AIに「体力をゼロ未満にしないで」とプロンプト領域を浪費する必要はありません。
String は、値がラベル（数量ではない）の場合に使います — ロケーション、ムード、ストーリーフェーズなど。2状態の値（locked/unlocked）にはstringではなくbooleanを使ってください。
Boolean は、何かが起きたか起きなかったかという場合に使います。最もシンプルな型で、AIが管理しやすく、条件付きエントリやルールの理想的なゲートになります。
JSON は、1つの変数に構造化データが必要な場合に使います：プロパティ付きアイテムのインベントリ、複数関係を持つ派閥マップ、ネストされた進捗を持つクエストログなど。単純な値にはJSONを使わないでください — [health: -10] の方が [stats.health: -10] より信頼できます。
behavior rulesを書く — 4つの質問の公式
はじめに：変数 では behavior rules の基礎を扱い、漠然としたものと具体的なものの違いを示しました。このセクションでは、一貫して優れたものを書くための公式を教えます。
優れたbehavior rulesは4つの質問に答えます。
1. 値は何を意味するか？ AIに凡例を与えてください。Numberなら各範囲が物語的に何を表すかを記述します。Stringなら有効な状態をリスト化します。Booleanなら true/false がストーリー上何を意味するかを説明します。
2. 何が変化を引き起こすか？ 具体的な状況を示します。「親切なやり取りで親密度が上がる」は関係変数なら十分です。「物理的なダメージでhealthが下がる」はHPに有効です。例を多く与えるほど、AIの一貫性は高まります。
3. どれだけ変化すべきか？ ここがほとんどのクリエイターの投資不足の場所です。変化量の範囲を与えましょう。小さな出来事には小さな変化を、大きな出来事には大きな変化を。これがないとAIは過剰反応（毎回 +20 親密度）するか、過少反応（瀕死体験で healthが2だけ下がる）するかになりがちです。
4. 上限は？ 1ターンあたりの最大変化量を制限しましょう。これで没入感を壊す大幅変動を防げます。「1ターンで15以上は変化しない」と書けばペースは自然になります。
TIP
2〜4文で通常は十分です。behavior rulesが短いパラグラフより長くなったら簡素化しましょう。AIは賢いので、ルールブックではなく概念と境界を与えてください。
知っておく価値のあること
delete 操作 はJSONオブジェクトからキーを削除するか、JSON配列から要素を削除します。通常の括弧構文で機能します — [npcs: delete "aria"]（オブジェクトキーは引用付き文字列）または [inventory: delete 0]（配列インデックスは数値）。1つの罠：delete の後にはJSON形状の値が必要です。裸の [var: delete] は暗黙のsetに落ち、変数にリテラル文字列 "delete" が書き込まれます — まずそんなことを望まないでしょう。バッチ削除や配列をIDで削除する場合は <UpdateVariable> JSON Patchブロック（AIディレクティブとマクロ を参照）や、ルールアクションの modify-variable で operation: "delete" を使うのも問題ありません。
公開ワールドの実例パターン
関係追跡
はじめに：変数 で示したように、Sakura Seasonはヒロインごとに別のnumber変数を使い、behavior rulesで変化量の範囲を指定しています。最もシンプルなアプローチで、2〜5人のキャラクターに対しては良く機能します。
代替案：すべての関係を1つのJSONオブジェクトに格納する。
{
"aria": { "trust": 50, "romance": 0, "met": true },
"kael": { "trust": 30, "romance": 0, "met": false }
}これは多数のキャラクターがいる場合にすっきりします。AIはドットパス（[relationships.aria.trust: +10]）で誰でも更新でき、新しいキーをマージすることでキャラクターを追加できます。トレードオフ：個別のnumber変数はAIにとって理解しやすく、ミスもしにくいです。
個別変数を選ぶ のは2〜5人のキャラクターで信頼性を最大化したい場合。JSONオブジェクトを選ぶ のは多数のキャラクターがいる場合や動的に追加する必要がある場合。
インベントリシステム
最もシンプルなインベントリは append を使うstring変数です — はじめに：変数 のBattle Royaleの死亡者ロスターで示した通り。アイテムプロパティを持つ本格的なインベントリにはJSON配列を使います。
[
{"id": "torch", "name": "Torch", "qty": 1},
{"id": "bread", "name": "Bread", "qty": 2}
]アイテム追加には push を使います。アイテム削除には delete とインデックスを使います。behavior rulesはAIにどのアプローチを使うか伝えるべきです。
push を使って完全なアイテムオブジェクトでアイテムを追加。アイテムを削除するには配列インデックスとともに delete を使う。インベントリ上限：10アイテム。上限に達したら何かを捨ててから入れる。
ロケーションとシーン状態
location というstring変数（デフォルト："starting village"）だけで通常は十分です。AIは旅すると [location: set "dark forest"] を書き、ロケーションキーワードでゲートされたエントリが適切なシーン記述を注入します。
シーンの複数の側面を追跡する複雑なワールドではJSONオブジェクトを使います。
{
"area": "castle",
"room": "throne-room",
"time": "night",
"alert-level": "high"
}AIは個別の側面を更新できます：警備を抜けた後の [scene.alert-level: set "low"] など。
すべての9操作、ショートハンドの罠、JSON変数のドットパス記法を含む完全なディレクティブ構文については、AIディレクティブとマクロ を参照してください。
よくあるミス
追跡しすぎ。 何でも変数にする必要はありません。AIが背後に数字なしで物語的に扱えるならスキップします。変数を増やすほどAIが管理する状態と書くべきディレクティブが増えます。ベストワールドは5〜15個の追跡項目です（50ではなく）。
曖昧なbehavior rules。 「healthを追跡」ではAIに何も伝わりません。「軽い打撃で5-15減少、重い打撃で15-25減少、0 = デスシーン」ならAIに必要なすべてを伝えます。Behavior rulesは、機能する変数と無視される変数を分ける境界です。
シンプルな型で済むのにJSONを使う。 numberが必要ならnumberを使いましょう。[health: -10] は [stats.health: -10] よりシンプルで信頼できます。JSONは真に構造化されたデータのために残しておきましょう。
Numberにmin/maxを忘れる。 境界がなければAIはhealthを-47やgoldを999,999まで押し上げかねません。すべてのnumber変数にminとmaxを設定しましょう。エンジンが自動的にクランプします — タダの保険です。
変化量をテストしない。 自分のワールドを10ターンプレイして数字が妥当か確認しましょう。3回のやり取りで親密度が15から80に跳ねたら、変化量の範囲が大きすぎます。20ターン経っても動かないなら狭すぎます。
AIにとってIDが扱いにくい。 health、player-gold、aria-trust のようなシンプルで読みやすいIDを使いましょう。スペース、特殊文字、組み込みマクロと衝突する名前（user、char、time、date）は避けてください。
関連項目
- AIディレクティブとマクロ — ディレクティブ構文、全9操作、ドットパス、ショートハンドの罠
- 優れたエントリの書き方 — 変数に反応する条件付きエントリ
- ビヘイビアと自動化 — 変数がしきい値を超えた時に発火するルール
完全な変数スキーマ → World Spec：変数