2026年、Amazon Bedrock AgentCoreでトレースデータが見つからない場合の対処法

結論：Amazon Bedrock AgentCoreのトレースデータ排查 2026では、まずCloudWatch Transaction Searchの有効状態とAgentCoreリソースの可観測性設定を確認し、次にログの保存先、権限、検索範囲を点検してください。AgentCore Runtime以外で動くAgentなら、アプリ側のOpenTelemetry計装も必要です。

AgentCore Runtimeの呼び出しに失敗し、調査に使える追跡情報が見つからない開発者向けです。 CloudWatchのログやトレースを管理するAWSプラットフォームエンジニアにも役立ちます。 本番Agentの障害を再現できる形で記録したい技術責任者は、最後の記録項目も確認してください。

「データがない」と「検索場所が違う」の切り分け

呼び出しの失敗、ログの欠落、トレースの欠落は別々の症状です。Agentがエラーを返していてもログが記録されている場合があり、反対にメトリクスが見えていても、個々のリクエストを追うspansは見つからないことがあります。まず「AgentCore CloudWatchに何もない」と一括りにせず、必要なデータの種類を決めます。

最初に、AWSアカウント、リージョン、対象のRuntimeや他のAgentCoreリソース、検索対象の時間範囲を照合してください。開発環境と本番環境でアカウントやリージョンが分かれていると、正しい画面を開いていても別の環境を検索していることがあります。Runtimeのspansを表示する場所については、AgentCoreの可観測性ビューに関するAWSの説明も確認できます。

AgentCoreのCloudWatchにtraceが出ないとき

最初の確認対象は、検索条件を変えたときにデータが見つかるかどうかです。呼び出しを行った時間帯、対象リソース、アカウント、リージョンをメモし、同じ条件で再検索します。時間範囲を広げて見つかった場合は、データ未生成ではなく検索範囲の問題だった可能性があります。

次に、同じ実行についてログ、メトリクス、spansのどれが見えているかを分けて記録してください。たとえば「呼び出し自体は失敗するが、ログはあり、spansはない」なら、アプリケーションの失敗原因だけでなく、トレースの有効化条件やTransaction Searchの状態を優先して調べます。

Transaction Searchとアカウント設定

CloudWatch Transaction Searchが無効、または設定変更がまだ反映されていない状態では、トレースの検索場所や見え方を誤認しやすくなります。Transaction Searchの有効化手順に沿ってアカウント側の設定を確認し、AgentCoreリソース側のテレメトリー設定とは別に扱ってください。アカウント設定を変更した直後は、対象の呼び出しを新たに実行し、検索条件とデータの到着状態を改めて確かめます。

AWSのガイドに記載された例示時間は、すべてのアカウント、リージョン、実行形態での表示保証ではありません。待ち時間だけで結論を出さず、設定の有効状態、対象リソース、直近の新しい実行を一組にして検証してください。AgentCore可観測性の概要では、ログ、メトリクス、トレースなど、データ種別ごとの確認方法が説明されています。

リソース別テレメトリー設定

「AgentCore可観測性」が有効かどうかは、ひとつのスイッチだけで判断できません。Runtime、Memory、Gatewayなど対象リソースごとに、必要なデータと設定、ログの送り先を確認します。公式のテレメトリー設定ガイドと可観測性の導入手順を照らし、利用中のリソース種別に該当する項目を選んでください。

AWSのリリースノートには、ログの出力先など設定に関わる変更が記録されることがあります。手順書や過去の設定例をそのまま流用せず、AgentCoreのリリースノートで現行の仕様も確認してください。

リクエスト本文をログに含める場合、認証情報、個人情報、プロンプト内の機密情報まで保存されるおそれがあります。障害調査に必要な項目だけを記録し、マスキング、閲覧権限、保存先の扱いを先に決めてください。

Runtime以外で動くAgentの計装

AgentがAgentCore Runtimeにホストされていない場合、Runtimeの自動計装やリソース設定だけでは、アプリケーション内部の処理を表すspansが生成されないことがあります。OpenTelemetry SDK、使用しているAgentフレームワークの計装、エクスポーター設定、テレメトリー関連の環境変数を、アプリ側で点検してください。可観測性の導入ガイドに示される手順を基準にし、実際の実行形態に合った設定を選びます。

切り分けでは、同じ入力と処理経路を使って、ローカル実行とクラウド実行のテレメトリーを比較します。ローカルではspansが生成されるのにクラウドでは出ないなら、環境変数、認証、ネットワーク経路、エクスポーターの接続先に調査範囲を絞れます。両方で生成されない場合は、フレームワークの計装方法やSDKの初期化を見直します。これは実行環境を比べる診断方法であり、AWS側の自動計装を保証する説明ではありません。

権限、保存先、検索条件の照合

空のログやトレースが見つかったときは、権限と保存先のどちらを先に見るべきかを、データがどこまで生成されているかで判断します。リソース設定に出力先が指定されていない、または意図したロググループと異なるなら、先に保存先を確認してください。出力先が正しく、書き込みが拒否される、あるいはデータが届かない場合は、実行ロールや関連するアクセス許可を調べます。Runtimeの権限に関するAWSの説明を基に、現在の構成に必要な権限を照合してください。

条件分岐で次の作業を決める

• 対象リソースとリージョンが特定できていない場合は、まず実行元を特定してください。特定できないまま権限変更を行うと、別環境の設定を変える危険があります。
• Transaction Searchが未設定、または設定状態が不明な場合は、公式手順に沿ってアカウント設定を確認し、新しい実行で再検証してください。
• ログの出力先が設定と一致しない場合は、先にリソース設定と保存先を合わせてください。設定が一致していて書き込みも確認できない場合は、権限と実行ロールの確認へ進みます。
• AgentがRuntime外で動作する場合は、AWSリソース設定だけで解決しようとせず、OpenTelemetry SDKとアプリ側の計装を確認してください。
• ログに機密情報が含まれうる場合は、詳細ログを増やす前にマスキングとアクセス範囲を定めてください。

調査結果を共有するときは、アカウント識別情報を必要な範囲で匿名化したうえで、実行リージョン、対象リソース、呼び出し時刻、失敗の有無、見つかったデータ種別、検索条件、適用済み設定、確認した権限、直前に変更した内容を記録します。AWS公式のRuntimeトラブルシューティング資料も確認し、アプリケーションの失敗とテレメトリーの欠落を別々に追ってください。

AWS上のRuntimeを使っているのにトレースが見つからない場合は、CloudWatch側の設定だけでなく、対象リソース、出力先、権限を順に照合するのが近道です。一方、Runtime外のAgentでは、アプリ側の計装が不足していればCloudWatchの検索条件を変えてもspansは現れません。

調査対象がAWSの本番Runtimeなら、MacをレンタルしてもCloudWatch側の欠落は解消しません。ローカルで自前Agentの計装や再現用環境を整える場合は、自前機材の環境差、常時稼働の管理、チームでの共有といった負担も判断材料になります。短期間だけMac上の開発・検証環境が必要なら、kvmbootの利用案内で利用条件を確認し、構成が決まらない場合は問い合わせ窓口で適合性を相談できます。長期の常時稼働や物理接続が必要な用途では、自社保有環境やAWS上の実行基盤のほうが適する場合があります。