AIゲームマスター設計
長いAI RPGキャンペーンのプロンプトキャッシュ
OpenAI、Claude、Geminiのプロンプトキャッシュを比較し、長いAI RPGで変わらない世界設定と毎ターンの状態を分け、使用量と費用を測ります。
長いキャンペーンで同じ情報が繰り返される理由
AIゲームマスターには、毎ターン同じ舞台のルール、登場人物の役割、ナレーションの境界が必要なことがあります。プレイヤーが扉を開けたり証人に質問したりすると場面は変わりますが、世界そのものが別世界になるわけではありません。まとまりのある返答のために、共通する情報を繰り返し渡す場合があります。プロンプトキャッシュはAPIが同じ入力の処理を再利用する方法であり、ゲームが保存していない出来事を記憶する方法ではありません。
失われた星図を探す飛空船の遠征を想像してください。雲海の地理と、日没後は嵐の壁を越えられないというルールは毎ターン必要です。一方、現在の甲板、目撃者、手がかり、プレイヤーの行動は変わります。この違いから開発者はキャッシュの挙動を調べ始められます。これは設計例であり、計測済みのPlayworlds最適化ではありません。
変化するターンの事実より前に、安定した世界情報を置く
リクエストは、持続的な指示から始められます。ナレーターの役割、確立した世界の制約、ダイスの結果をどう渡すか、繰り返し登場する人物の短い説明です。後の部分に現在の場面を置きます。どの甲板へ行けるか、誰がいるか、プレイヤーは何を知り、何を試みたかです。再利用できる情報の前に時刻、セッション識別子、新しいプレイヤー文を置くと、再利用できたかもしれない先頭部分が変わる可能性があります。
キャッシュの対象にするためだけに概要を水増ししないでください。正しい判断に役立つ事実を入れ、提供元の適格条件を確認します。恒久的なルールが変わったなら、新しい版の処理が必要になっても事実の基準を更新します。
APIごとに異なる「キャッシュヒット」
OpenAIのAPI資料は、共通のプロンプト先頭部分の再利用と、対応モデルの使用量におけるキャッシュ済み入力トークンの表示を説明しています。Anthropicは自動キャッシュと明示的な区切りを文書化し、安定した内容の終端を示す場所も説明しています。GeminiはGenerate Content APIで暗黙的なキャッシュと明示的なキャッシュオブジェクトを説明しています。仕組みは異なるため、一つのAPIの例をコピーしても他で使える設定にはなりません。
ヒットすると、対象となる入力の処理量と料金が減る場合があります。新しい場面の事実が無料になるわけでも、出力費用がなくなるわけでも、答えが正しい証拠にもなりません。保存期間、最小長、対応するインターフェース、請求方法は提供元とモデルによって異なります。節約率を約束する前に、実際に使うAPI経路を調べましょう。
飛空船の場面に使うリクエスト例
共通部分は簡潔にします。「あなたは飛空船遠征のゲームマスター。確立した事実を使い、プレイヤーの選択を守り、ゲームが解決済みのルール結果を描写する。日没後は嵐の壁を越えられない。航海士イリは航路を計画する。現在の知識はターンごとに渡される」。これは例示用のプロンプト概要であり、Playworldsのプロンプトでもモデルの実行記録でもありません。
その後に変化する状態を加えます。「現在の場面：日没後、船が嵐の壁に近づく。保存済みの出来事：プレイヤーは機関室で焦げた星図を見つけた。イリは出発以来その星図を見ていない。プレイヤーの行動：星図をイリに見せ、誰が機関室に入ったか尋ねる」。次のターンでは共通部分を保ち、本当に変わった事実だけを替えます。キャンペーンの更新として扱う前に、保存済みの出来事と応答を照合します。
見出しの割引率より、役立つ一ターンの費用を測る
リクエストごとに、モデルとインターフェース、入出力の総トークン、キャッシュ済み入力または読み取りトークン、課金される場合の書き込みトークン、経過時間、実際のタスク結果を記録します。通常のターンの列と、安定した先頭部分を意図的に保つ版を比較します。一ターンに二回の呼び出しや再試行が必要なら両方含めます。安く見えるリクエストでも、壊れた応答で再生成が必要なら節約ではありません。
再利用された入力の割合と、完了した一ターンの請求額を比較します。答えが星図の発見、嵐の壁のルール、イリの知識を守るかも確認します。使用量の欄が示すのは再利用であり、物語の連続性ではありません。キャッシュミスを直すためプロンプトを変える前に、実際のリクエストの差を調べます。
物語の事実をキャッシュ配置と分ける
キャンペーンが当初の世界概要を超えることもあります。乗組員が嵐の壁を消したなら、日没後に越えられないという固定文は誤りになります。ゲームはそのルールを更新し、概要に版を付けるか、例外をナレーターに届く正式な現在状態へ移すべきです。キャッシュヒットを守るために矛盾を残してはいけません。同様に、ゲームマスターだけが知る秘密をプレイヤーに見える要約へ載せるべきではありません。
提供元のキャッシュは処理を助けるもので、キャンペーンのデータベースではありません。保存済みの冒険には、確定した行動、ロール、発見、キャラクターの変化を別に記録する必要があります。Playworldsにはアカウントに紐づく冒険とAIナレーターがありますが、この記事はライブのゲームが特定の提供元のプロンプトキャッシュを使うとは主張しません。例はゲームチームが評価できる計画です。
最適化前の短いチェックリスト
第一に、複数ターンで繰り返す事実を特定し、正確で版を管理した一つの概要にまとめます。第二に、その後へプレイヤーの行動と現在の場面を置き、秘密を知るべき人物の範囲に限ります。第三に、正確な提供元のAPI経路とキャッシュ使用量の欄を記録し、再試行と出力を含むターン全体を比較します。第四に、請求額が下がったことを成功と呼ぶ前に、物語の事実の連続性とプレイヤーの選択を検証します。
継続するAI冒険をプレイヤーとして体験するなら、Playworldsの世界一覧からキャラクターが調べたくなる舞台を選んでください。最初のセッションを形にするには、ソロロールプレイのガイドも役立ちます。