8月18日、AWSが「Consistency is the new latency: AI at the data layer」と題した記事を公開した。この記事では、AIエージェントのデータ層におけるレプリケーション遅延が引き起こす一貫性問題と、その対策となる3つのアーキテクチャパターンについて詳しく紹介されている。
「500ミリ秒の遅延」がエージェントを壊す
Webアプリケーションでは、非同期レプリケーションによる500msの遅延はほぼ無害だ。ユーザーが投稿を少し遅れて見るだけで、実害はない。
しかしAIエージェントにとって、この500msの遅延は致命的な毒になる。エージェントがプライマリノードに書き込み、即座にレプリカから読み取ると、古いデータを「現在の真実」として扱う。その上で論理的に整合した多ステップのプランを実行してしまう。
記事中の具体例が鮮明だ。フラッシュセールを管理する在庫調整エージェントを想定する：
- 書き込み:
us-east-1のプライマリDBにavailable_stock = 500を書き込む - 遅延: ネットワーク輻輳により、
ap-south-1（ムンバイ）レプリカへの反映に2秒かかる - 読み取り: ムンバイで動くサブエージェントがレプリカを参照し、レプリケーションがまだ完了していない古い値（更新前の在庫数）を取得
- 誤動作: エージェントが「在庫切れ」通知を送信し、セールを停止——倉庫に500個あるにも関わらず
エージェントは推論エラーを起こしていない。汚染されたコンテキストの上で完璧に論理的に動いた結果がこれだ。
さらに問題は連鎖する。エージェントが誤った結論をDBに書き戻すと、それが長期記憶になる。以降の検索でこの汚染された履歴が参照され、誤りが自己強化されていく。記事はこれを「Hallucination Debt（幻覚債務）」と呼ぶ。LLMはDBから取得した値を疑わず「現在の事実」として扱うため、時間的な検証をアーキテクチャ側で担保しなければならない。
一貫性モデルの選択：3つのパターン
すべてのAIタスクが同じ一貫性要件を持つわけではない。タスクの「真実要件」に合わせてレプリケーションモデルを選ぶことが肝心だ。
パターンA：強一貫性（高リスクデータ向け）
ユーザー権限、セキュリティポリシー、金融レコードなど、古い読み取りが許容できないケースでは、**Amazon Aurora Global Database** を活用する。
Global Write ForwardingをGLOBAL一貫性レベルで有効化することで一貫性ギャップを埋められる。SESSION一貫性レベルを設定すれば「Read-Your-Own-Writes」の整合性も確保でき、エージェントは自分の書き込みがレプリカに反映されるまで待ってから読み取る。
次世代のグローバル分散AI向けには Amazon Aurora DSQL も選択肢として紹介されている。複数リージョン間でネイティブな同期型強一貫性を提供し、どのリージョンのエージェントも同一の状態を参照できる設計だ。ただし、Aurora DSQLは現時点でプレビュー段階のサービスであり、本番環境への適用可否はAWSの最新ステータスを確認する必要がある。
適用先: IDメタデータ、金融台帳、変更不可のシステムプロンプト
パターンB：グローバルスケールの可用性（並行更新向け）
超低レイテンシと大規模スケールが必要なケースでは、**Amazon DynamoDB Global Tables** のマルチリーダーアーキテクチャを使う。
ここで注意が必要なのは、DynamoDB Global Tablesはデフォルトで最終整合性（Eventual Consistency）モデルを採用している点だ。複数リージョンへの書き込みが同時発生する環境では、レプリカ間の収束に時間差が生じる。これは高速・高可用性を得るためのトレードオフとして元記事でも前提とされている。
この競合リスクを軽減する鍵になる技術がConditional Writesだ。ConditionExpressionでバージョンタイムスタンプや属性の存在を確認し、「最後に取得した時点から変更がない場合のみ更新する」という制約を課す。条件が失敗するとConditionalCheckFailedExceptionが返り、エージェントは現在の状態を再読み取りして判断を見直す。
これにより「Lost Update（複数エージェントが互いの書き込みを上書きする）」の問題を同期型グローバル調整なしで抑制できる。ただし、Conditional Writesはあくまで競合検出の手段であり、最終整合性モデルそのものを強一貫性に変えるものではない点は理解しておきたい。
適用先: 会話履歴、ユーザーセッション状態、パーソナライズされたエージェントメモリ
パターンC：高速インジェスト（リアルタイム異常検知向け）
大量のテレメトリデータをリアルタイムで処理するエージェントには、**Amazon Keyspaces（Apache Cassandra互換）** のリーダーレスアーキテクチャが適している。
書き込みはLOCAL_QUORUMでコミットし、読み取りもLOCAL_ONEではなくLOCAL_QUORUMに設定する。このクォーラムの重なりにより、エージェントは高速インジェストパイプラインを遅らせることなく最新データを取得できる。
適用先: IoTテレメトリ、リアルタイムログ解析、高頻度センサーデータ
データ層の設計者としてのアーキテクト
記事はデータベースレプリケーションを「一度設定したら忘れるインフラ」として扱う時代は終わったと指摘する。自律エージェントの時代において、データ層の安定性はAIの信頼性と直結する。エージェントに渡るコンテキストの鮮度そのものを設計の対象として捉えることが、現代のアーキテクトに求められるという主張だ。
「AIの速い答えが間違いなら、少し遅くても正しい答えより高くつく」——これが記事全体を貫くメッセージだ。レプリケーションモデルをエージェントの推論要件に合わせて選択することが、現代の設計判断の核心になっている。
詳細はConsistency is the new latency: AI at the data layerを参照していただきたい。
