ある法律事務所が Amazon Bedrock Knowledge Bases（ベクターストア：OpenSearch Serverless）と Claude 3.5 Sonnet を使った契約書 Q&A システムを本番運用しています。弁護士チームから「昨日アップロードした契約書について質問すると内容が抜けている・古い情報が返る」という報告が続いています。CloudWatch にはエラーや異常なレイテンシーは記録されておらず、数日前以前の契約書については正しく回答できています。調査の結果、Knowledge Bases の同期ジョブ（Ingestion Job）が毎日深夜 0 時に1回だけスケジュール実行される設定になっており、新規ドキュメントのアップロードから最大 24 時間の遅延が存在することが判明しました。このインデクシングのタイムラグを最小化するために最も適切な対策はどれですか？
Bedrock Knowledge Bases の同期ジョブ（Ingestion Job）は、S3 データソースのドキュメントをチャンク化・埋め込み生成してベクターストアへ格納するバッチ処理ですが、このジョブは StartIngestionJob API を明示的に呼び出さない限り自動的には起動しません。定期スケジュールのみに依存する構成では、アップロードのタイミングによって最大でスケジュール間隔ぶんの遅延が生じます。 S3 ObjectCreated イベント → Lambda → StartIngestionJob というイベント駆動パイプラインを実装することで、ドキュメントのアップロード直後にインデクシングが開始され、遅延はチャンク化・埋め込み処理の実行時間（通常数分）のみに短縮されます。スケジュール依存をなくした構成が根本解決策として最も即時性に優れます。 選択肢Bの Amazon EventBridge スケジューラーによる15分周期実行は遅延を大幅に削減しますが、アップロードタイミングによって最大15分のラグが残り、イベント駆動と比較して即時性に劣ります。 選択肢CのAurora PostgreSQL（pgvector）への移行はベクターストアの変更であり、Ingestion Job のトリガー方式とは独立した設定です。ストアを変えても起動の仕組みが変わらなければラグは解消しません。 選択肢DのIncremental Syncは同期ジョブ実行時に変更差分のみを処理してジョブの実行時間を短縮する機能ですが、ジョブの起動タイミング（1日1回のスケジュール）自体を変えるものではなく、24時間ラグの根本原因を解消しません。