developersIO
Amazon Quick のチャットログやフィードバックログを CloudWatch Logs Analytics で、利用状況とエージェント改善のヒントを分析してみた

Amazon Quick のチャットログやフィードバックログを CloudWatch Logs Analytics で、利用状況とエージェント改善のヒントを分析してみた

Amazon Quick のチャット会話やユーザーフィードバックを CloudWatch Logs に配信して分析する方法を、実際の設定から Logs Analytics による分析まで一通りご紹介します。
AWSAmazon QuickCloudWatch LogsCloudWatch Logs Insightsログ分析
2026.07.13

クラウド事業統括本部の石川です。Amazon Quick では、AI アシスタントとのチャット会話やユーザーフィードバックを CloudWatch Logs へ配信できます。今回は 「チャットエージェントを誰がどのように使っているかを把握し、カスタムエージェントの改善や新エージェント候補の検討につなげる」という改善シナリオ で、ログ配信の設定から CloudWatch Logs Analytics による分析まで一通りをご紹介します。

https://docs.aws.amazon.com/quick/latest/userguide/monitoring-quicksuite-chat-feedback-cloudwatch.html

Amazon Quick の Quick Chat を組織に展開すると、管理者としては次のような点が気になってきます。

  • 誰が、どのくらい、どのエージェントを使っているのか
  • ユーザーの質問にきちんと答えられているのか（答えられていない質問は何か）
  • ユーザーは回答に満足しているのか（Not Useful の理由は何か）
  • ユーザーの質問傾向から、次に作るべきカスタムエージェントは何か

Amazon Quick には vended logs（利用者側でログ出力の仕組みを実装しなくても、AWS のサービス自身がログを生成し配信先まで自動的に届けてくれる仕組み）があり、チャット会話・ユーザーフィードバック・エージェント/リサーチ時間・インデックスストレージ使用量・ナレッジベースのファイル同期状況のログを CloudWatch Logs、Amazon S3、Amazon Data Firehose へ配信できます（配信には標準レートの料金が適用されます）。

本記事では、このうちチャット会話（CHAT_LOGS）とフィードバック（FEEDBACK_LOGS）を CloudWatch Logs に配信し、Logs Insights で冒頭の 4 つの観点を分析するところまでを実際に試しています。

なお、インデックスストレージ使用量（INDEX_USAGE_LOGS）については以下の記事で紹介していますので、あわせてご参照ください。

https://dev.classmethod.jp/articles/quick-vendedlogs-index-usage-logs/

Amazon Quick のチャット・フィードバックログ配信とは

Amazon Quick のログ配信は、CloudWatch Logs の配信 API（PutDeliverySource / PutDeliveryDestination / CreateDelivery）で設定します。logType には以下の 5 種類を指定できます。

logType 内容
CHAT_LOGS チャット会話（質問文・回答文・レイテンシ・スコープ等）
FEEDBACK_LOGS 回答へのフィードバック（Useful / Not Useful、理由、詳細コメント）
AGENT_HOURS_LOGS エージェント/リサーチ時間の利用量
INDEX_USAGE_LOGS ナレッジベース / Space のインデックスストレージ使用量
KB_FILE_SYNC_LOGS ナレッジベースのドキュメント同期状況

前提条件は以下のとおりです。

  • Enterprise または Professional サブスクリプションの Amazon Quick インスタンス
  • ログ配信を設定するための IAM 権限（quicksight:AllowVendedLogDeliveryForResource 等）
  • 配信先（CloudWatch Logs ロググループ、S3 バケット、Firehose ストリームのいずれか）

注意事項としては、チャット会話のログには、ユーザーが入力した質問文と AI の回答文がそのまま記録されることです。機密情報や個人情報が含まれる可能性があるため、公式ドキュメントでは CloudWatch Logs のマスキングポリシー（データ保護ポリシー）の利用が案内されています。ログを閲覧できる IAM プリンシパルの制御とあわせて設計しておくことをお勧めします。

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html

やってみた

前提条件

  • 検証リージョン: ap-northeast-1（東京）
  • Amazon Quick アカウント: Enterprise エディション（リージョンは東京）

シナリオとして、以下の 4 つの目的を設定しました。

  1. 誰がどのエージェントをどのように使っているかの把握
  2. 利用状況の定量把握（利用量・成功率・レイテンシ）
  3. カスタムエージェントの改善（低評価の理由分析）
  4. 新エージェント候補の検討（答えられなかった質問の抽出）

1. 配信設定テンプレートの確認

最初に、DescribeConfigurationTemplates API で quicksight サービスのログ配信テンプレートを確認します。logType ごとに「デフォルトで含まれるフィールド」と「指定可能なフィールド」が確認できます。

ログ配信テンプレートの詳細
% aws logs describe-configuration-templates \
    --service quicksight \
    --region ap-northeast-1
{
    "configurationTemplates": [
        ...
        {
            "service": "quicksight",
            "logType": "CHAT_LOGS",
            "resourceType": "account",
            "deliveryDestinationType": "CWL",
            "defaultDeliveryConfigValues": {
                "recordFields": [
                    "resource_arn",
                    "event_timestamp",
                    "logType",
                    "accountId",
                    "user_arn",
                    "user_type",
                    "status_code",
                    "conversation_id",
                    "system_message_id",
                    "message_scope",
                    "user_message_id",
                    "user_message",
                    "agent_id",
                    "flow_id",
                    "system_text_message",
                    "user_selected_resources",
                    "action_connectors",
                    "cited_resource",
                    "file_attachment"
                ],
                "fieldDelimiter": ""
            },
            "allowedFields": [
                {
                    "name": "timestamp",
                    "mandatory": false
                },
                {
                    "name": "resource_arn",
                    "mandatory": true
                },
                {
                    "name": "resource_id",
                    "mandatory": false
                },
                {
                    "name": "event_timestamp",
                    "mandatory": true
                },
                {
                    "name": "logType",
                    "mandatory": true
                },
                {
                    "name": "accountId",
                    "mandatory": true
                },
                {
                    "name": "user_arn",
                    "mandatory": false
                },
                {
                    "name": "user_type",
                    "mandatory": false
                },
                {
                    "name": "namespace",
                    "mandatory": false
                },
                {
                    "name": "status_code",
                    "mandatory": false
                },
                {
                    "name": "conversation_id",
                    "mandatory": false
                },
                {
                    "name": "system_message_id",
                    "mandatory": false
                },
                {
                    "name": "latency",
                    "mandatory": false
                },
                {
                    "name": "time_to_first_token",
                    "mandatory": false
                },
                {
                    "name": "message_scope",
                    "mandatory": false
                },
                {
                    "name": "user_message_id",
                    "mandatory": false
                },
                {
                    "name": "user_message",
                    "mandatory": false
                },
                {
                    "name": "agent_id",
                    "mandatory": false
                },
                {
                    "name": "flow_id",
                    "mandatory": false
                },
                {
                    "name": "system_text_message",
                    "mandatory": false
                },
                {
                    "name": "surface_type",
                    "mandatory": false
                },
                {
                    "name": "web_search",
                    "mandatory": false
                },
                {
                    "name": "user_selected_resources",
                    "mandatory": false
                },
                {
                    "name": "action_connectors",
                    "mandatory": false
                },
                {
                    "name": "cited_resource",
                    "mandatory": false
                },
                {
                    "name": "file_attachment",
                    "mandatory": false
                }
            ],
            "allowedOutputFormats": [
                "plain",
                "json"
            ],
            "allowedActionForAllowVendedLogsDeliveryForResource": "quicksight:AllowVendedLogDeliveryForResource",
            "allowedFieldDelimiters": [
                "\t",
                " ",
                ","
            ]
        },
        ...
    ]
}

上記の latency、time_to_first_token、namespace、surface_type、web_search の 5 つは allowedFields には含まれるものの、デフォルトの recordFields には含まれないことです。レイテンシ分析をしたい場合は、後述の CreateDelivery で明示的に指定する必要があります。

2. ロググループの作成

配信先となるロググループを作成します。会話ログは溜め続けるとコストと情報管理の両面でリスクになるため、保持期間も設定しておきます。ロググループ名を /aws/vendedlogs/ プレフィックスで始めておくと、リソースポリシーのサイズ制限を気にせず配信設定できます。

% aws logs create-log-group \
    --log-group-name /aws/vendedlogs/quick/chat \
    --region ap-northeast-1

% aws logs put-retention-policy \
    --log-group-name /aws/vendedlogs/quick/chat \
    --retention-in-days 30 \
    --region ap-northeast-1

同様に、フィードバックログ用の /aws/vendedlogs/quick/feedback も作成します。

% aws logs create-log-group \
    --log-group-name /aws/vendedlogs/quick/feedback \
    --region ap-northeast-1

% aws logs put-retention-policy \
    --log-group-name /aws/vendedlogs/quick/feedback \
    --retention-in-days 30 \
    --region ap-northeast-1

3. delivery source の作成

CHAT_LOGS と FEEDBACK_LOGSそれぞれの delivery source を作成します。

% aws logs put-delivery-source \
    --name quick-chat-logs-source \
    --resource-arn "arn:aws:quicksight:ap-northeast-1:123456789012:account/123456789012" \
    --log-type CHAT_LOGS \
    --region ap-northeast-1
{
    "deliverySource": {
        "name": "quick-chat-logs-source",
        "arn": "arn:aws:logs:ap-northeast-1:123456789012:delivery-source:quick-chat-logs-source",
        "resourceArns": [
            "arn:aws:quicksight:ap-northeast-1:123456789012:account/123456789012"
        ],
        "service": "quicksight",
        "logType": "CHAT_LOGS"
    }
}

% aws logs put-delivery-source \
    --name quick-feedback-logs-source \
    --resource-arn "arn:aws:quicksight:ap-northeast-1:123456789012:account/123456789012" \
    --log-type FEEDBACK_LOGS \
    --region ap-northeast-1
{
    "deliverySource": {
        "name": "quick-feedback-logs-source",
        "arn": "arn:aws:logs:ap-northeast-1:123456789012:delivery-source:quick-feedback-logs-source",
        "resourceArns": [
            "arn:aws:quicksight:ap-northeast-1:123456789012:account/123456789012"
        ],
        "service": "quicksight",
        "logType": "FEEDBACK_LOGS"
    }
}

なお、公式ドキュメントには「ログは PutDeliverySource の resource ARN に指定したリージョンで利用可能になる」と記載されています。筆者のアカウントでは当初、バージニア北部（us-east-1）リージョンに CHAT_LOGS の配信設定を作成していましたが、東京リージョンの Quick でチャットしてもログは 1 件も届きませんでした。resource ARN のリージョンを Quick アカウントのアイデンティティリージョン（今回は東京）に合わせて作成し直したところ、ログが届くようになりました。delivery source は Quick アカウントのアイデンティティリージョンに作成してください。

4. delivery destination の作成

配信先（ロググループ）を delivery destination として登録します。

% aws logs put-delivery-destination \
    --name quick-chat-logs-dest \
    --delivery-destination-configuration \
    "destinationResourceArn=arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/chat:*" \
    --region ap-northeast-1

% aws logs put-delivery-destination \
    --name quick-feedback-logs-dest \
    --delivery-destination-configuration \
    "destinationResourceArn=arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/chat:*" \
    --region ap-northeast-1

5. delivery の作成（オプションフィールドを明示指定）

delivery source と delivery destination を紐付ける delivery を作成します。ステップ 1 で確認したとおり、レイテンシ系フィールドはデフォルトに含まれないため、--record-fields で全フィールドを明示指定します。

aws logs create-delivery \
    --delivery-source-name quick-chat-logs-source \
    --delivery-destination-arn "arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:quick-chat-logs-dest" \
    --record-fields resource_arn event_timestamp logType accountId user_arn \
      user_type namespace status_code conversation_id system_message_id \
      latency time_to_first_token message_scope user_message_id user_message \
      agent_id flow_id system_text_message surface_type web_search \
      user_selected_resources action_connectors cited_resource file_attachment \
    --region ap-northeast-1

{
    "delivery": {
        "id": "Y03kIsmF1wiUcd5D",
        "arn": "arn:aws:logs:ap-northeast-1:123456789012:delivery:Y03kIsmF1wiUcd5D",
        "deliverySourceName": "quick-chat-logs-source",
        "deliveryDestinationArn": "arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:quick-chat-logs-dest",
        "deliveryDestinationType": "CWL",
        "recordFields": [
            "resource_arn", "event_timestamp", "logType", "accountId",
            "user_arn", "user_type", "namespace", "status_code",
            "conversation_id", "system_message_id", "latency",
            "time_to_first_token", "message_scope", "user_message_id",
            "user_message", "agent_id", "flow_id", "system_text_message",
            "surface_type", "web_search", "user_selected_resources",
            "action_connectors", "cited_resource", "file_attachment"
        ]
    }
}

FEEDBACK_LOGS 側も同様に作成します（namespace を追加指定しています）。

aws logs create-delivery \
    --delivery-source-name quick-feedback-logs-source \
    --delivery-destination-arn "arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:quick-feedback-logs-dest" \
    --record-fields resource_arn event_timestamp logType accountId user_arn \
      user_type namespace status_code conversation_id research_id \
      system_message_id user_message_id feedback_type feedback_reason \
      feedback_details rating \
    --region ap-northeast-1

最後に DescribeDeliveries で配信設定を確認しておきます。

aws logs describe-deliveries --region ap-northeast-1

6. Quick でチャットしてみる

設定が済んだので、Quick のチャットで実際に会話します。分析パートで結果が「映える」ように、以下のパターンを意図的に混ぜて合計 11 メッセージ・2 会話を実施しました。

パターン 例 ねらい
ダッシュボードに答えがある質問 「売上のハイライトを教えて」 正常系の利用量・レイテンシ
同じテーマの言い換え質問 ×3 「経費精算のやり方を教えて」「出張の立替経費はどう申請すればいい？」 頻出トピックの検出
ナレッジ外の質問 「有給休暇の残日数を教えて」 答えられない質問の検出
特定リソースを指定した質問 ダッシュボードを選択して「顧客の主な不満点を 3 つにまとめて」 message_scope の記録確認
回答への Useful フィードバック ×4 良かった回答に高評価 FEEDBACK_LOGS の記録確認
回答への Not Useful フィードバック ×2 低評価 + 理由選択 + 詳細コメント入力 feedback_reason / details の確認

なお、チャットの入力内容はそのままログに記録されるため、検証時も本番運用と同じ意識で、機密情報や実在の個人情報は入力しないようにしています。

7. ログが届いたことを確認する

チャット実施後、筆者の環境ではフィードバックログが約 2 分、チャットログが約 3 分でロググループに届きました。届いたチャットログを 1 件見てみます。

aws logs filter-log-events \
    --log-group-name /aws/vendedlogs/quick/chat \
    --region ap-northeast-1 \
    --max-items 1

% aws logs filter-log-events \
    --log-group-name /aws/vendedlogs/quick/chat \
    --region ap-northeast-1 \
    --max-items 1
{
    "events": [
        {
            "logStreamName": "QUICK_SUITE_CHAT_LOGS",
            "timestamp": 1783787914186,
            "message": "{\"user_arn\":\"arn:aws:quicksight:ap-northeast-1:123456789012:user/default/cm-ishikawa.satoru/cm-ishikawa.satoru\",\"user_type\":\"ADMIN_PRO\",\"namespace\":\"default\",\"status_code\":\"success\",\"conversation_id\":\"979613ec-65f0-40c7-a838-d45d371c62d8\",\"system_message_id\":\"6e06e65d-d6f6-4bbf-917d-fbc433260cf0\",\"latency\":61124,\"time_to_first_token\":61124,\"message_scope\":\"all_resources\",\"user_message_id\":\"ff05e8da-1dea-492c-856e-24b2b19da523\",\"user_message\":\"Superstore Performance Analytics Suite ダッシュボードから、売上のハイライトを教えて\",\"agent_id\":\"SYSTEM\",\"flow_id\":\"-\",\"system_text_message\":\"「Superstore Performance Analytics Suite」ダッシュボードの **Executive Overview** シートから、売上のハイライトをまとめます。\\n\\n## 主要KPI\\n\\n| 指標 | 値 |\\n|------|-----|\\n| 総売上 | 約 2億2,718万円 |\\n| 総利益 | 約 2,739万円 |\\n| 総オーダー数 | 2,818件 |\\n| 平均割引率 | 約 10.8% |\\n\\n## 地域別売上\\n\\n| 地域 | 売上 |\\n|------|------|\\n| 関西地方 | 約 5,690万円 |\\n| 関東地方 | 約 4,852万円 |\\n| 中部地方 | 約 4,290万円 |\\n| 九州 | 約 2,798万円 |\\n| 中国地方 | 約 1,947
万円 |\\n| 東北地方 | 約 1,698万円 |\\n| 四国 | 約 977万円 |\\n| 北海道 | 約 465万円 |\\n\\n**関西地方**が最大の売上を誇り、全体の約25%を占めています。\\n\\n## 顧客区分別売上\\n\\n| 顧客区分 | 売上 |\\n|----------|------|\\n| 消費
者 | 約 1億1,419万円（約50%） |\\n| 大企業 | 約 7,059万円（約31%） |\\n| 小規模事業所 | 約 4,239万円（約19%） |\\n\\n**消費者**セグメントが売上の約半分を
占める最大の顧客区分です。\\n\\n## カテゴリ別売上（顧客区分別）\\n\\n全顧客区分を通じて、**家具・家電・事務用品**の3カテゴリが均衡しており、消費者向けの家具（約4,170万円）が最も高い売上を記録しています。\\n\\n## サブカテゴリ別利益 (上位・下位)\\n\\n- **利益トップ3**: 椅子（約702万円）、コピー機（約492万円）、本棚（約488万円）\\n- **唯一の赤字**: テーブル（約 -318万円）がマイナス利益となっており、注意が必要です。\\n\\n---\\n\\n詳細な分析が必要な場合は、以下のオプションをご検討ください。\\n\\n\",\"surface_type\":\"WEB_EXPERIENCE\",\"web_search\":true,\"user_selected_resources\":[{\"resourceId\":\"ALL\",\"resourceType\":\"space\"}],\"action_connectors\":[{\"actionConnectorId\":\"quicksuite-documentation\"},{\"actionConnectorId\":\"quicksuite-websearch\"}],\"cited_resource\":[],\"file_attachment\":[],\"resource_arn\":\"arn:aws:quicksight:ap-northeast-1:123456789012:account/123456789012\",\"event_timestamp\":1783787914186,\"logType\":\"CHAT_LOGS\",\"accountId\":\"123456789012\"}",
            "ingestionTime": 1783788030550,
            "eventId": "39779799762480394727843288965236226612872707756014698496"
        }
    ],
    "searchedLogStreams": [],
    "NextToken": "eyJuZXh0VG9rZW4iOiBudWxsLCAiYm90b190cnVuY2F0ZV9hbW91bnQiOiAxfQ=="
}

質問文（user_message）と回答全文（system_text_message）に加えて、user_arn、conversation_id、latency、message_scope、web_search の有無まで記録されています。誰が・いつ・何を聞いて・何が返ったかがすべて追えるデータです。

注目すべきは、「見つかりませんでした」と答えられなかった質問でも status_code は success になっている点です。エージェントが会話として丁寧に回答を返した場合は成功扱いになるようで、no_answer_found にはなりませんでした。この点は後述の分析でテキストマッチによる工夫をしています。

フィードバックログも 1 件見てみます。

{
    "logStreamName": "QUICK_SUITE_FEEDBACK_LOGS",
    "timestamp": 1783788302000,
    "message": "{\"user_arn\":\"arn:aws:quicksight:ap-northeast-1:123456789012:user/default/cm-ishikawa.satoru/cm-ishikawa.satoru\",\"user_type\":\"ADMIN_PRO\",\"namespace\":\"default\",\"status_code\":\"success\",\"conversation_id\":\"979613ec-65f0-40c7-a838-d45d371c62d8\",\"research_id\":\"-\",\"system_message_id\":\"de34b8df-227f-4b53-a75d-e8e15ab273f5\",\"user_message_id\":\"\",\"feedback_type\":\"Not Useful\",\"feedback_reason\":\"Incomplete answer\",\"feedback_details\":\"返品率を聞いたのに返品件数で回答された。率での分析と簡潔なまとめが欲しい。\",\"rating\":\"-\",\"resource_arn\":\"arn:aws:quicksight:ap-northeast-1:123456789012:account/123456789012\",\"event_timestamp\":1783788302000,\"logType\":\"FEEDBACK_LOGS\",\"accountId\":\"123456789012\"}",
    "ingestionTime": 1783788424595,
    "eventId": "39779808411021593150798372453140582184638924035319463936"
}

UI で選択した理由（不完全な回答）は Incomplete answer という英語のコードで、自由記述のコメントは feedback_details に日本語のまま記録されました。conversation_id でチャットログと突合できるため、「低評価が付いた会話で実際に何が起きたか」まで遡れます。

8. CloudWatch Logs Analytics で分析してみる

いよいよ本題の分析です。冒頭の 4 つの目的に沿って、Logs Insights のクエリを実行していきます。

目的 1: 誰がどのエージェントをどう使っているか

対象ロググループ: /aws/vendedlogs/quick/chat

SOURCE "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/chat" START=-604800s END=0s |
fields @timestamp
| stats count(*) as messages, count_distinct(conversation_id) as conversations,
        avg(latency) as avg_latency_ms
  by user_arn, agent_id
| sort messages desc

20260713-quick-chat-logs-cloudwatch-1

ユーザー別・エージェント別の利用量が一目でわかります。この結果から「利用が一部のユーザーに偏っていないか」「導入したのに使われていない部門はないか」を判断し、未利用部門への展開施策につなげられます。なお、デフォルトエージェント（My Assistant）でのチャットは agent_id が SYSTEM と記録されました。カスタムエージェント別の分析をしたい場合は、用途別にエージェントを作成して使い分けてもらう運用が前提になります。

目的 2: 利用状況の定量把握

対象ロググループ: /aws/vendedlogs/quick/chat

ステータス×スコープ別の件数の集計

SOURCE "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/chat" START=-604800s END=0s |
stats count(*) as cnt by status_code, message_scope
| sort cnt desc

20260713-quick-chat-logs-cloudwatch-2

レイテンシの分布の集計

SOURCE "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/chat" START=-604800s END=0s |
filter ispresent(latency)
| stats count(*) as cnt, avg(latency) as avg_ms,
        pct(latency, 50) as p50_ms, pct(latency, 90) as p90_ms, max(latency) as max_ms

20260713-quick-chat-logs-cloudwatch-3

今回の検証では p50 で約 51 秒、p90 で約 80 秒でした。ダッシュボードのデータ取得や集計を伴う質問では 1 分半を超えるケースもあり、レイテンシの継続的なモニタリングは利用者の体験を測るうえで有効です。時系列の推移は by bin(1h) as hour を付けて集計できます。

なお、message_scope の実際の値は all_resources / specific_resource（単数形）でした。ドキュメントの例には specific_resources と記載されているため、クエリの条件に使う場合は実ログの値を確認することをお勧めします。

目的 3: カスタムエージェントの改善

対象ロググループ: /aws/vendedlogs/quick/feedback

feedback_type と feedback_reason の総数

feedback_type と feedback_reason の総数を確認します。

SOURCE "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/feedback" START=-604800s END=0s |
stats count(*) as cnt by feedback_type, feedback_reason
| sort cnt desc

20260713-quick-chat-logs-cloudwatch-4

Not Useful の詳細コメント

さらに、feedback_type が Not Useful の詳細コメントを一覧表示します。

SOURCE "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/feedback" START=-604800s END=0s |
filter feedback_type = 'Not Useful'
| fields @timestamp, feedback_reason, feedback_details, conversation_id
| sort @timestamp desc

20260713-quick-chat-logs-cloudwatch-5

このクエリの出力は、そのままエージェント改善の課題リストとして使えます。理由コードごとに打ち手を変えられ、たとえば「Incomplete answer が多い → ナレッジ不足か、質問の意図の取り違え」「Too wordy が多い → エージェントの回答方針（プロンプト）を簡潔に修正」といった対応が考えられます。

さらに、ログを展開すると詳細を確認できます。

20260713-quick-chat-logs-cloudwatch-6

目的 4: 新エージェント候補の検討

前述のとおり、答えられなかった質問も status_code は success になるため、回答文のパターンマッチで抽出します。

SOURCE "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/quick/chat" START=-604800s END=0s |
filter system_text_message like /見つかりませんでした|お伝えすることはできません|確認することができません/
| fields user_message, substr(system_text_message, 0, 60) as answer_head
| sort @timestamp asc

20260713-quick-chat-logs-cloudwatch-7

52 件中 5 件が「答えられなかった質問」として抽出できました。内訳を見ると、経費精算に関する質問が言い回しを変えて 3 回繰り返されています。複数ユーザーから同様の傾向が見えれば、「経費規程のドキュメントを Space に取り込んだ経費精算エージェントを作る」という判断が、ログという定量的な根拠付きでできるようになります。まさに「ログを見ると、次に作るべきエージェントが見える」という体験でした。

考察

実際に試して得られた知見を整理します。

  • 未回答の検出は status_code だけでは不十分: ナレッジ外の質問にエージェントが「見つかりませんでした」と丁寧に回答した場合も status_code は success でした。答えられなかった質問の抽出には、回答文のパターンマッチ（今回は正規表現）を併用する必要があります。エージェントの回答スタイルに依存するため、運用しながらパターンを育てるのが現実的です。
  • レイテンシ分析にはフィールドの明示指定が必要: latency / time_to_first_token はデフォルトの recordFields に含まれません。CreateDelivery 時に指定し忘れると後から欲しくなっても過去分は取れないため、最初から全フィールドを指定しておくことをお勧めします。
  • delivery source はアイデンティティリージョンに作成する: リージョンを誤るとエラーにはならず「ログが届かない」という静かな失敗になるため、注意が必要です。
  • 会話ログの中に含む個人情報には注意: user_arn で個人を特定でき、質問文・回答文もそのまま記録されます。ロググループへのアクセス制御、保持期間、マスキングポリシーをセットで設計してください。利用者への周知（会話が記録されること）も組織のガバナンス上重要です。なお、チャット UI にはプライベートモード（メモリや履歴を更新しないモード）のトグルも用意されていました。
  • フィードバックは意識的に集める運用が必要: FEEDBACK_LOGS の分析はユーザーが高評価・低評価ボタンを押してくれてこそ機能します。展開時に「役に立たなかったら理由を付けて低評価してほしい」と案内しておくと、改善サイクルが回りやすくなります。
  • 本格運用では S3 + Athena / Quick ダッシュボード化も: 今回は Logs Insights のみで完結させましたが、長期保存・部門への共有・他の業務データとの結合が必要になったら、配信先を S3 に切り替えて（または追加して）Athena や Quick 自身のダッシュボードで可視化する構成に発展させられます。

最後に

Amazon Quick のチャット・フィードバックログを CloudWatch Logs に配信し、Logs Insights で分析してみました。追加の分析基盤を作らなくても、「誰がどう使っているか」「答えられていない質問は何か」「低評価の理由は何か」「次に作るべきエージェントは何か」まで一気通貫で把握できます。

AI アシスタントの導入は「展開して終わり」ではなく、利用ログに基づく改善サイクルを回してこそ定着します。Amazon Quick の AI 機能を有効にしたら、早い段階でログ配信も設定しておくことをお勧めします。この記事がどなたかのお役に立てば幸いです。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

Amazon CloudWatchの新機能「Log Analytics」を試してみた
suzuki.ryo
2026.06.29
Amazon Q Developer（Chatbot）でイベントログを有効にする方法を教えてください
hato
2025.05.23
[アップデート] CloudWatch Logs Insights のクエリ言語に JOIN とサブクエリが追加され、異なるロググループのログを関連付けて分析できるようになりました
いわさ
2026.04.24
[アップデート] Amazon Quick のインデックスストレージ使用状況をナレッジベース・スペース単位で CloudWatch Logs から確認できるようになりました
いわさ
2026.04.23