権威サーバー型の状態同期をAIエージェントとWebへ転用する設計の、8,100試行による比較
共有予算を変更する8,100試行で、重複実行・状態破綻・体感待ち時間を比較する
『THE FINALS』で公開説明されている「サーバーを正しい世界の所有者にし、クライアントは薄く予測する」設計を、AIエージェントのツール実行とWebアプリの共有状態へ転用できるか検討した。8クライアントが有限の共有予算を変更する合成シミュレーションを8,100回実行した結果、権威サーバーとidempotency keyを使う2方式では予算超過と二重実行が0になった。さらに楽観表示を組み合わせた方式は、代表条件で画面の初動を0msにしながら訂正率を0.283%に抑えた。
| 方法 | 8クライアントが共有予算500に対して各20件、消費量1〜5の操作意図を送る離散事象シミュレーションを作成した。往復遅延20・80・200ms、再送率0・2・10%、3方式、各条件300回を比較し、合計8,100試行を記録した。合成データのみを使い、外部サービスやユーザーデータは変更していない。 |
|---|---|
| 結果 | 往復80ms・再送率10%では、クライアント側だけで状態を持つ比較方式に平均29.253単位の予算超過と15.817件の二重実行が生じた。サーバー確定を待つ方式と、サーバーを正本にして先行表示する方式はいずれも予算超過0、二重実行0だった。待つ方式の体感待ち時間は82.583ms、先行表示方式は0msで、後から表示を訂正した割合は0.283%だった。 |
| 知見 | 転用できるのは物理演算そのものではなく、状態の所有権を一か所へ集め、クライアントから結果ではなく操作意図を送り、手元の予測を確定結果へ合わせる構造である。AIではTool Gateway、WebではAPIとDBを正本にし、再送にはidempotency key、画面にはoptimistic UIを使う構成が対応する。 |
| 限界 | 今回の結果は合成した共有予算モデルに限られ、実ネットワーク、実LLM、実サービスの性能を測ったものではない。訂正率は資源量、要求分布、競合率で変わる。画面の初動0msは先行表示の時刻であり、サーバー確定が0msという意味ではない。Event Sourcingや権威サーバーの運用・監視・schema移行コストも別途評価が必要である。 |
調査の問い
『THE FINALS』では、移動や環境破壊など試合結果に関わる世界状態をサーバー側で進め、クライアントは入力を送り、薄い予測で通信待ちを隠すと開発者が説明している。この構造を、複数のAIエージェントが同じ予算・ファイル・タスクを操作する環境や、予約・在庫・共同編集を扱うWebアプリへ移せるかを調べた。
転用する対象は物理エンジンではない。共有状態の正解を一か所に置き、端末やAIからは「変更後の状態」ではなく「変更したい意図」を送り、手元の予測を確定結果へ合わせる設計である。
三つの対応関係
| THE FINALS | AIエージェント | Webアプリ |
|---|---|---|
| サーバー上の正しい世界 | Tool Gatewayが持つ業務状態 | APIとDBが持つ正しい状態 |
| プレイヤー入力 | tool intent | ユーザーのcommand |
| 薄い移動予測 | 実行予定・pending表示 | optimistic UI |
| サーバーとの照合 | tool結果で計画と画面を訂正 | API応答で確定または巻き戻し |
| 事前に壊し方を準備 | schema・権限・状態遷移を事前定義 | validation・cache・materialized view |
| 物体状態の配信 | event stream・tool result | WebSocket・SSE・state patch |
共有予算モデルで実験した
8クライアントが共有予算500を使うツール呼び出しを各20件送るモデルを作った。1件の消費量は1〜5、往復遅延は20・80・200ms、同じ操作を再送する割合は0・2・10%とした。3方式を各条件300回ずつ実行し、合計8,100試行をCSVへ保存した。
- クライアント正本：各クライアントの状態をそのまま実行し、共有側で残額や重複を検証しない比較用モデル。
- サーバー待機：サーバーが残額とidempotency keyを検証し、返答後に画面を変える。
- サーバー正本＋先行表示：検証はサーバーで行うが、画面は先に反応し、拒否されたときだけ訂正する。
代表条件の結果
往復80ms・再送率10%の300試行では次の平均になった。
| 方式 | 予算超過 | 二重実行 | 画面の初動 | 訂正率 |
|---|---|---|---|---|
| クライアント正本 | 29.253単位 | 15.817件 | 0ms | 0%（検出しない） |
| サーバー待機 | 0 | 0 | 82.583ms | 0% |
| サーバー正本＋先行表示 | 0 | 0 | 0ms | 0.283% |
往復200ms・再送率10%でも、サーバーを正本にした2方式の予算超過と二重実行は0だった。待機方式の初動は202.406ms、先行表示方式は0msで、訂正率は0.302%だった。つまり、このモデルでは共有状態の正しさをサーバーで守りながら、先行表示によって待つ感覚を減らせた。
AIへ移すならTool Gatewayを正本にする
LLMがDBや外部APIの状態を直接決めるのではなく、intent ID、実行主体、期待するversion、tool名、schemaに沿った引数をTool Gatewayへ送る。Gatewayは権限、現在状態、idempotency key、rate limitを検証し、受理した操作を記録する。エージェントの文章や内部計画は予測であり、実世界の確定状態にはしない。
先行できるのは「実行中」「この変更を予定」「残り予算は推定何件」といった表示である。メール送信、購入、削除、権限変更などの副作用はGatewayの確定結果を基準にし、再送されても同じintent IDを一度だけ実行する。MCPの仕様も、server側での入力検証、アクセス制御、rate limit、出力の無害化を求め、client側には敏感な操作の確認を推奨している。
Webへ移すならoptimistic UIとAPI検証を組み合わせる
ReactのuseOptimisticは、サーバー処理中に一時的な状態を表示し、実際の更新結果へ合わせる仕組みを提供する。コメント、タスク、予約、在庫、共同編集などで、ボタンを押した瞬間の反応を作れる。ただし残数、権限、重複、versionの最終判定はAPIとDBで行い、画面側の値だけを信用しない。
操作履歴そのものを正本にするEvent Sourcingは、監査や状態再構築が重要な領域に向く。一方、Microsoftの解説も実装、eventual consistency、schema変更、移行の複雑さを挙げている。通常のCRUDで十分な機能まで全面的に置き換えるのではなく、競合と監査が重要な境界へ限定して試すのが現実的である。
この結果の限界
これは離散事象シミュレーションであり、『THE FINALS』のサーバー、実ネットワーク、実LLM、実サービスを測定したものではない。クライアント正本方式は共有検証を持たない単純な比較モデルである。訂正率は要求量と資源の余裕、競合率で変わる。また、画面の初動0msは先行表示を意味し、サーバー処理が0msで完了する意味ではない。
再現用ZIPにはシミュレーター、検算コード、集計JSON、全8,100行の試行CSVを収録した。外部サービスとユーザーデータは使わず、作業用フォルダーの合成データだけで実験している。