散在ログ問題に向き合う公式リファレンス
AWS Machine Learning Blogが公開した今回のソリューションは、エンタープライズAIプラットフォーム「Amazon Quick」を数百〜数千ユーザー規模で運用する企業が直面する具体的な課題を出発点としている。公式は次のように問題設定する。
When hundreds to thousands of users are onboarded to an enterprise AI platform, business leaders and platform owners need visibility into who is using the platform, whether users are satisfied with the answers they receive, and which capabilities are driving the most engagement.
この3点（誰が使っているか・満足度・機能別エンゲージメント）は、AI基盤導入後の運用責任者が経営に説明責任を負う典型的な指標だが、ログは複数AWSサービスに散在しており、横断集計には独自のデータパイプラインが必要になる。
落とし穴: 観測を後付けにするコスト
本家ブログは構築手順を示すが、読者がハマりやすいのは「導入が終わってから観測を考える」順序だ。ユーザー識別子の連結キー、満足度シグナルの収集タイミング（回答直後か、セッション終了時か）、機能別エンゲージメントの定義は、本番運用が始まってから遡って整備するとログ欠損が発生する。導入計画の段階でKPI定義と収集経路を先に固定することが、後の再設計コストを下げる。
また、AWSネイティブの統合パターンが示されたことで、汎用の外部AI観測SaaSを別途採用する動機は相対的に弱まる。コスト面の公開数値はないが、AWS内で完結させるか外部ツールで標準化するかは、他のAI基盤（Bedrock利用アプリ等）との観測統合範囲によって判断軸が変わる。
