2つのAIエージェントが同じファイルを編集し、両方が「成功」の応答を受け取ったとしても、一方の変更しか残らないことがあります。5つのエージェントを同時に走らせた単純なテストでは、5回の書き込みのうち4回がエラーやログの記録もなく消失しました。これは、消失した作業のために支払ったトークンが無駄になる、典型的な「ロストアップデート（更新喪失）」アノマリーです。
なぜこの問題が重要なのか
AIエージェントが結果を書き戻す際、基盤となるサービスは生成されたトークン量に応じて課金します。書き込みが静かに上書きされてしまった場合でも、プロバイダーは破棄された出力を生成するために費やされた計算量に対して課金します。マルチエージェント・パイプライン（エージェント・スウォーム、並列データクリーニング・ワーカー、あるいは複数のボットがプランファイルやスクラッチパッドを共有するあらゆるシステム）において、これらの隠れた損失は重大なコスト漏洩へと膨れ上がる可能性があります。また、このアノマリーはデータの整合性も脅かします。後続のステップが不完全または古い情報に基づいて動作し、連鎖的なエラーを引き起こす可能性があるためです。
アノマリーが発生する仕組み
根本的な原因はレースコンディション（競合状態）です。
- 2つ（またはそれ以上）のエージェントが、JSONプランファイルなどのリソースの同じバージョンを読み取る。
- 各エージェントが、そのスナップショットに基づいて独自の推論や変換を行う。
- 両方のエージェントが、共有ストレージに対して書き込み操作を実行する。
- ストレージシステムが2番目の書き込みを受け入れ、競合検知を行うことなく最初の書き込みを上書きする。
- 最初の貢献分は消失しているにもかかわらず、両方のエージェントは書き込みが成功したことを示す「ACK（確認応答）」を受け取る。
ストレージシステムの確認応答は、書き込みが行われたことを証明するだけであり、その書き込みが他の並行する更新に対して安全であることを保証するものではありません。安全策としてよく挙げられる「追記専用ログ（append-only log）」も同様の挙動を示します。書き込みが発生したことは記録しますが、後の書き込みが以前の書き込みを塗りつぶすのを防ぐことはできません。
Compare-and-set ゲートの役割
Compare-and-set (CAS) ゲートは、書き込みが受け入れられる前にバージョンチェックを追加します。
- Read（読み取り）: エージェントはファイルの現在のバージョン番号（またはハッシュ）を取得する。
- Compute（計算）: エージェントは作業を行い、ファイルの新しいバージョンを生成する。
- Write（書き込み）: エージェントは、最初に読み取ったバージョンとともに新しいコンテンツを送信する。
- Validate（検証）: ストレージ層は、提供されたバージョンと現在のバージョンを比較する。両者が異なる場合は書き込みが拒否され、同じであれば書き込みが実行され、バージョンがインクリメントされる。
バージョンが変更されていた場合、エージェントは自身の参照が古かったことを認識し、新しいバージョンを使用して「読み取り、計算、書き込み」のサイクル全体をやり直さなければなりません。これにより、目に見えない上書きが、ログに記録でき、再試行が可能で、管理可能な「明示的な失敗」へと変わります。
安全性の代償
CASゲートは無料ではありません。同じ5エージェントのシミュレーションでは以下のようになります。
| シナリオ | 書き込み試行回数 | 成功した貢献 | トークンコスト |
|---|---|---|---|
| CASゲートなし | 5 | 1 | 5ユニット |
| CASゲートあり | 5 | 5 (再試行後) | 9ユニット |
ゲートは、バージョン競合が発生したエージェントに対して追加の「読み取り・計算・書き込み」サイクルを発生させ、トークンの消費量を増加させます。トレードオフは明確です。ゲートがなければデータが静かに失われ、ゲートがあればわずかな追加コストを支払う代わりに、すべての競合を可視化できます。
失敗はどの程度一般的なのか？
わずか2つのエージェントであっても、テストでは書き込みの1つが失われる確率が75%であることを示しました。5つのエージェントでは、消失率は100%に近づきました。これらの数値は、プロダクションレベルのマルチエージェント・ワークフローにおいて、「たいていは大丈夫だろう」という想定がいかに危険であるかを示唆しています。
反論：ゲートをスキップすべきケース
リソースごとに単一のエージェントを実行している場合や、より高いレベルで厳格なシリアル化（逐次処理）を強制している場合、追加のCASチェックは不要かもしれません。しかし、リスク計算には、失敗した作業を再実行するための隠れたコストや、データ欠落による潜在的な後続への影響を含める必要があります。
次に注目すべき点
- ツールのサポート: バージョン番号やETagを公開し、アトミックなCAS操作を標準で提供しているストレージAPIを探してください。
- メトリクス: バージョン不一致によって書き込みが拒否される頻度を記録するようにエージェントを計測してください。競合率の上昇は、リソースの拡張やワークフローの再設計が必要なサインです。
- 再試行戦略: 単純な指数バックオフ（exponential back-off）は有効ですが、繰り返しの再試行がトークン消費を増大させることに注意してください。許容できるデータ損失と、再試行の制限のバランスを取ってください。
- ハイブリッドアプローチ: 監査可能性のために追記専用ログを使い、一貫性のためにCASゲートを組み合わせるチームもあります。これにより、何が起こったかの記録と、上書きに対する保護の両方を確保できます。
まとめ
ロストアップデート・アノマリーは、トークン駆動型のAIパイプラインを、資金を垂れ流すブラックホールへと変えてしまいます。Compare-and-set（CAS）によるバージョンゲートを導入すれば、トークンのオーバーヘッドはわずかに増えますが、サイレントなデータ消失を、可視化されたリトライ可能なイベントへと変換できます。データベース、プランファイル、スクラッチパッドなど、複数のエージェントが状態を共有するあらゆるシステムにおいて、書き込み前にバージョンチェックを組み込むことは、隠れたコストやワークフローの破損を防ぐための最も安価な保険となります。