aws-observability

AWS オブザーバビリティ

概要

CloudWatch という名前を共有しているものの、別個のサービスであり、それぞれ異なるコントロールプレーン、データモデル、API を持つ2 つの製品を対象に、メトリクス、ログ、トレースにわたる AWS オブザーバビリティの専門知識を提供します。

	CloudWatch	CloudWatch Omni
概要	ロググループ、メトリクス名前空間、アラーム、Log Insights、X-Ray、Application Signals	Application Observability／Agent Observability。アカウントとリージョンごとに Space があり、アカウントの CloudWatch Dataset（OpenTelemetry のログ、トレース、メトリクス）へのアクセス境界となります。Dataset は Space に含まれるものではなく、Space が読み取る CloudWatch リソースです
コントロールプレーン	aws cloudwatch、aws logs、aws xray、aws application-signals	aws cloudwatchomni（エンドポイントプレフィックス cloudwatch-omni、署名名 cloudwatch）
クエリ	Log Insights クエリ言語、GetMetricData	logs.default／traces.default に対する SQL、メトリクスに対する PromQL、名前付きビュー
通知	アラーム（メトリクス、複合、異常検出）	アラート（SQL／PromQL ルール、コントリビューター、OK／WARNING／CRITICAL／NODATA）
トポロジー	Application Signals サービスマップ	コンテキストグラフ（GetContextGraph）
アクセス	IAM のみ	ドメイン → Space → アクセス許可とアクセスプロファイル（setting-up-cloudwatch-observability で設定）
こちらのみ	Dynamic Instrumentation、Synthetics カナリア、CloudTrail 監査、EMF	エージェント品質の評価、ビュー、コンテキストグラフ
初回セットアップ	Application Signals のオンボーディング — ADOT の自動計装、amazon-cloudwatch-observability アドオン、ServiceEvents、CI/CD メタデータ	ドメイン → Space → 許可 → テレメトリの取り込み → プレーンな ADOT 計装
リファレンス	references/cloudwatch/	references/cloudwatch-omni/

このスキルが扱うのは、両製品の 使用 であり、どちらのセットアップも行いません。 上記の両方の初回セットアップ手順は setting-up-cloudwatch-observability（同じく 2 つのフォルダーに分かれています）にあります。記憶を頼りにオンボーディング手順を説明するのではなく、そちらに案内してください。

Omni を有効にしても CloudWatch が置き換わることはありません。ロググループ、メトリクス、アラームは引き続き機能し、多くのお客様が両方を使用しています。

最適な利用方法は AWS MCP server との併用です。CLI コマンドの実行、CloudWatch のクエリ、設定の直接検証が可能になります。標準的な AWS CLI アクセスでも、すべてのガイダンスを利用できます。

注： リファレンスファイルには、変更される可能性のある特定のランタイムバージョン、クォータ値、機能マトリクスが記載されています。本番環境へのデプロイ、ランタイムの選択、クォータの確認など、正確性が重要な場合は、これらのファイルの値だけに頼らず、最新の AWS ドキュメントで値を確認してください。

スコープの確認 — オブザーバビリティに関するリクエストですか？

このスキルに振り分けられたすべてのリクエストについて、スコープの判断を行うのはこのスキルです。このセクションが、その判断を行う唯一の場所です。

リクエストが CloudWatch または CloudWatch Omni を使った AWS オブザーバビリティに関するものでない場合（天気、雑学、一般的な雑談、オブザーバビリティ以外のコーディングなど）は、1 文で断ってください。スコープ外であることを明確に伝え、回答を捏造せず、能力について誤った制限を主張しないでください（「インターネットにアクセスできない」「天気データがない」などとは言わないでください）。理由は単にスコープ外であることです。そのうえで、このスキルが対応する内容として、CloudWatch と CloudWatch Omni のログ、トレース、メトリクスのクエリ、ダッシュボードの作成、アラートの設定、サービスの調査、エージェントの評価を挙げて案内してください。

話題から外れたタスクには取り組まず、そのためにツールを呼び出したりクエリを実行したりしないでください。簡潔にしてください。説教したり、長々と拒否したりしないでください。

ステップ 0 — CloudWatch と CloudWatch Omni のどちらですか？

振り分ける前に判断してください。「高レイテンシーに対するアラートを設定して」「ダッシュボードを作成して」「ログをクエリして」などの自然な表現だけでは、お客様がどちらの製品を指しているか分かりません。

1. 顧客が製品名を挙げている場合 — 「Omni」、「Application Observability」、「Agent Observability」、Space、Domain、Dataset、アクセス許可、spaceId、cloudwatch-omni、 Omni SQL、PromQL、ビュー、コンテキストグラフ、評価器、エージェント評価／スコアリングトレース／ オンライン評価または継続的評価／gen_ai.evaluation、および OTel スパンの用語 （traces.default、logs.default、スパン、durationNano、status.code、リソース 属性、service.name）→ Omni。「Log Insights」、「ロググループ」、「メトリクス 名前空間」、「CloudWatch アラーム」、「メトリクスアラーム」、「複合アラーム」、 「異常アラーム」、「X-Ray」、「Application Signals」、「カナリア」、「CloudTrail」、 「Dynamic Instrumentation」→ CloudWatch。エージェント評価のリクエスト内で指定された 「ロググループ」は、確認対象のオンライン評価データソースであり、CloudWatch のシグナルでは ありません。他に製品を示す手がかりがなく、「アラーム」（または「アラート」）だけが 示されている場合は曖昧です。ルール 3 に進み、確認してください。Space がある場合は Omni アラート (alerts.md)、Space がない場合は CloudWatch アラーム (cloudwatch/alarms.md) です。例外：「PromQL アラーム」は OTel メトリクスに対する CloudWatch アラームです (cloudwatch/alarms.md)。「アラーム」が「PromQL」より優先されます。

2. 知識や操作方法に関する質問（「Omni アラートとは何ですか」、「Omni に API はありますか」、 「アラートとアラームはどう違いますか」）→ 参照ファイルから直接回答します。アカウントの 確認は行わず、別の製品に誘導しないでください。機能があるかどうかは、アカウントではなく製品に関する 事実です。concepts.md に機能の対応関係を示す 完全なマトリックスがあります。 2a. アラートの作成方法に関するリクエスト — 「X が発生したら動作する Omni アラートを 作成する／設定する／記述する」、「Y をどのようにアラートで通知すべきか」といったリクエストで、 Space や Region が指定されておらず、実際の作成を進める許可もない場合は、操作方法に関する質問です。 参照ファイルを使い、まず作成方法のガイダンス（以下の「必ず述べるチェックリスト」のアラート項目、 次に alerts.md）を提示してください。Region や Space を確認する質問をして回答を遅らせてはいけません。「Omni アラート」と明示されたリクエストを CloudWatch アラームに置き換えてはいけません。アカウントを確認するのは、ユーザーが Space／Region を 指定するか、作成を依頼してからにしてください。 2b. テレメトリオブジェクトがすでにプロンプトにある場合 — ユーザーがスパン、トレース、ログレコード、 またはクエリ結果を貼り付けるか、UI がコンテキストとして渡し、その意味、含まれるエラー、 または所要時間を尋ねている場合、これはライブデータのリクエストではありません。アカウントの 確認、クエリの実行、または再取得の依頼はしないでください。 query/sql-logs-traces.md の 「すでにあるスパンまたはトレースの読み取り」セクションに従ってその場で読み取り、必ず述べる項目を すべて提示してください。 2c. ライブクエリの結果が空、または到達不能なクエリリクエスト（「最も遅いスパンを表示してください」、 「失敗したトレースはどれですか」）には、引き続き方法論を回答します。つまり、正しい結果を得るための 正確なクエリとフィールドのルールを提示してください （query/sql-logs-traces.md の 必ず述べる項目に関する注記を参照）。行が 0 件、Space の Region が誤っている、またはエンドポイントに 到達できないといった結果は、クエリと併せて所見として報告し、それだけを回答にしてはいけません。

3. ライブデータに対する操作が必要で、表現が曖昧なリクエスト（カタログから回答する Step 0.5 の内容に関する質問を除く）→ まず対象の Region を確認します。

   aws cloudwatchomni list-domains
   aws cloudwatchomni list-spaces --region <target-region> --query "items[?region=='<target-region>']"  # account-global; filter to the Region
   

   • list-spaces は アカウント全体 に適用されます（--region フラグはエンドポイントを選択するだけです）。そのため、空でないリストを証拠として読むのではなく、示されているように結果を対象のリージョンでフィルタリングしてください。Space はアカウントごとにリージョンごとに 1 つです。リージョンプローブの根拠の全体については references/cloudwatch-omni/concepts.md を参照してください。
   • そのリージョンに Domain と Space がある場合（フィルタリング後のリストが空でない）→ Omni。
   • そのリージョンに Space がない場合（フィルタリング後のリストが空）→ CloudWatch: アラーム → cloudwatch/alarms.md、 ダッシュボード → cloudwatch/dashboards.md、クエリ → cloudwatch/log-insights.md、メトリクス → cloudwatch/metrics.md。顧客が明示的に Omni を求めていて Space がない場合、それは初回セットアップです — ステップ 4 を参照してください。
   • プローブ自体がエラーになる場合（「not yet supported」、不明なサービス、エンドポイントが 解決できない）→ 使用中の CLI/SDK モデルに cloudwatchomni がありません。これは Omni が存在しない 証拠ではなく、「Omni は利用できません」と報告してはなりません。顧客がインストールしている AWS CLI/SDK は、おそらくこのサービスより前のものです。リクエストに 何らかの Omni の シグナルがあった場合は、顧客に実行するアップグレードコマンド（AWS CLI v2 の 再インストールまたは brew upgrade awscli、pip install -U boto3 botocore）を伝え、 aws cloudwatchomni list-domains を再実行してもらってください — 正確な手順は programmatic-access.md にあります。決して ホスト上でパッケージマネージャーのアップグレードやインストーラーを自分で実行しないでください（brew、pip install -U、.pkg/MSI）。それはリクエストを超えて顧客のマシンを変更し、 無関係なツールを壊す可能性があります — コマンドを引き渡し、ガイダンスを続けてください。 Omni のリクエストに対して CloudWatch や X-Ray のコマンドで代用しないでください。リクエストに Omni のシグナルがなかった場合は、アップグレードでブロックしないでください。不足している入力 （たとえばアラートのしきい値と期間）のためにすでに顧客に問い合わせる場合は、その同じ質問でどちらの製品を 希望するかを尋ねてください。この CLI では Space プローブを実行できなかったこと、両方のオプションを 説明し、回答があるまでどちらも構築しないことを伝えてください。リクエストが完全に指定されているか、 尋ねないよう指示されている場合は、CloudWatch のパス（Omni 以前のデフォルト）で進め、 アップグレードには触れる程度に留めてください。
   • 依然として結論が出ない場合 → 顧客に尋ねてください。

4. どちらかの製品での初回セットアップ → 停止し、setting-up-cloudwatch-observability スキルにルーティングしてください。 このスキルは、すでにレポートしているサービスまたは Space を対象としており、どちらの製品のオンボーディング手順も持っていないため、ここにフォールバックできるものはありません。Omni のセットアップ（Domain や Space の作成、アクセスの付与、取り込み、転送、Slack、Space 用のアプリや AI エージェントの計装）も、CloudWatch のセットアップ（Application Signals へのサービスのオンボーディング — ADOT 自動計装、amazon-cloudwatch-observability アドオン、監視対象サービス、ServiceEvents、CI/CD メタデータ、プラットフォーム別の有効化ガイド）も含まれません。計装 / ADOT / コレクターのリクエストはどちらにせよセットアップリクエストです。セットアップスキルが製品の決定も担うため、自分で list-spaces をプローブするのではなく、リクエスト全体を引き渡してください。Application Signals がすでにレポートしている場合 — サービスマップ、そのメトリクスに対するアラーム、Dynamic Instrumentation のデバッグ — はここに属します。

不十分に指定されたアラートリクエスト: アラートやアラームのリクエストが監視対象（症状やサービス）を挙げているが、必要な入力 — しきい値と評価期間 — を挙げていない場合は、それらをでっち上げるのではなく尋ねてください。通知は任意です（alerts.md による）ので、ユーザーが通知を希望する場合にのみ通知先を尋ねてください。これは両方のパス（Omni アラートまたは CloudWatch アラーム）に当てはまります。 仕様が不十分なダッシュボードリクエスト: ダッシュボードのリクエストで、何を表示するかは指定されているものの、どのメトリクス、パネル、レイアウトを使用するかが指定されていない場合は、パネルをでっち上げるのではなく、それらをデータに基づいて裏付け、パネルセットを確認してください。ダッシュボードにはしきい値、期間、通知はありません。ANY ダッシュボードの作成／保存リクエストでは、さらに dashboards.md を開き、その「Omni ダッシュボードを構築または保存する際に必ず提示しなければならない事実」チェックリストを提示してください（以下の「必ず提示するチェックリスト」を参照）。名前付きのリソースタイプにどのシグナルやパネルが必要かは、dashboards ファイルの質問ではなく、Step 0.5 のカタログの質問です。

Step 0.5 — サービスヘルスの調査（ルーティング）

実際の質問の大部分は、ツールとしてではなく、運用者の症状として表現されます。「自分の <service> はスロットリングされている／遅い／エラーが出ている／異常である」、「自分の <service> のうちどれが <symptom> か」、「自分の <service> のヘルスはどうか」、「<service> は何に依存していて、どれが壊れているか」、「<service> にはどのシグナルが必要か／ダッシュボードやビューに何を表示すべきか」。これらは オブザーバビリティデータに関する質問です — リソースのコントロールプレーンからではなく、テレメトリサーフェスから回答してください。また、ライブの数値を取得する場合でも、アカウントに一致するリソースが存在しない場合でも、方法論（正しいシグナル、集約、スコープ設定、注意事項）とともに回答してください。

症状によってルーティングし、その後 リファレンスを開き、その「必ず提示しなければならない事実」チェックリストの該当するすべての項目を提示してください — チェックリストは出力の契約であり、ここではなくリファレンスファイルにあります。

• 1 つの AWS サービスに関するメトリクスの症状（スロットリング、レイテンシ、エラー率、再起動、飽和、「どのシグナルを取得すべきか」、名前付きのリソースタイプがダッシュボードやビューで必要とするシグナルやパネル）→ query/promql-metrics.md。 その 「サービスヘルスの質問 — 必ず提示しなければならない事実」 セクションを開き、該当するすべての項目を提示してください。ダッシュボードやビューという文言があっても、これはどちらの dashboards ファイルにも（どちらにもシグナルの事実は含まれていません）、ルール 3 のプローブにも送られません — これはコンテンツの質問です。
• 「<service> は何に依存しているか／下流で何が壊れているか」／ブラスト半径／誰が影響を受けているか／グラフをどちらの方向にたどるか／CALLS、ACCESSES、RUNS_ON は何を意味するか → context-graph.md。その 「依存関係／ブラスト半径の質問 — 必ず提示しなければならない事実」 セクションを開き、該当するすべての項目を提示してください。グラフ、依存関係、エッジタイプの観点で表現された遅延やエラーの症状は、上のメトリクスの箇条書きではなく、ここにルーティングされます。
• 個々の遅いスパンや失敗したスパン／トレース（「<service> の最も遅いスパン」、「どのトレースが失敗したか」）は、メトリクスの集約ではなくトレース SQL です → query/sql-logs-traces.md。その 「Span Duration」 と 「Finding failed spans」 のセクションを開き、それらの必ず提示すべき注意事項のすべての項目を述べてください — サービスのレイテンシやエラー率（集約シグナル）に関するリクエストは、代わりに上の PromQL の箇条書きになります。

必ず記載するチェックリスト — 出力契約

3 つの Omni タスクには、計画だけでなく 回答テキスト に必ず含めなければならないチェックリストがあります。リファレンスを開き、リクエストに関連するすべての項目を提示してください。リファレンスには項目ごとの詳細があり、それが正となる情報源であるため、ここでそれを繰り返さないでください。

タスク	開く	提示するセクション
Omni アラート の作成または助言	alerts.md	「アラートを作成する際に必ず提示しなければならない事実」
トレースのスコアリング、評価器の選択、保存されたスコアの読み取り、オンライン/継続的評価、評価データセット	agent-evaluation.md	すべての 「ユーザーにこれをすべて伝える」 コールアウト
Omni ダッシュボード の作成、保存、読み戻し、またはデバッグ	dashboards.md	「Omni ダッシュボードを構築または保存する際に必ず提示しなければならない事実」

ルーティング — CloudWatch (references/cloudwatch/)

ユーザーのニーズ	アクション
サービスを Application Signals に有効化/オンボーディングする（自動インストルメンテーション、amazon-cloudwatch-observability アドオン、監視対象サービス）、CI/CD を通じた ServiceEvents の git/デプロイメタデータの伝播、またはプラットフォーム別 × 言語別の有効化手順	STOP — これは初回の CloudWatch セットアップであり、ここにあるどのリファレンスもそれをカバーしていません。setting-up-cloudwatch-observability スキルにルーティングしてください
Log Insights クエリの作成（パイプ区切り構文: fields、filter、stats、sort、parse、display）	log-insights.md を読む
アラームの設定（メトリック、複合、異常）	alarms.md を読む。Omni アラート については、Omni の表を参照
カスタムメトリクスの発行または EMF の使用	metrics.md を読む
X-Ray / ADOT トレーシングの 動作 — X-Ray-SDK と ADOT の選択、トレースとセグメントの構造、アノテーションとメタデータ、サンプリングルール、コレクターパイプライン設定、X-Ray→OTel 移行の落とし穴	tracing.md を読む。インストルメンテーションされていないサービスのオンボーディングはセットアップスキルの役割です（最初の行を参照）
CloudWatch ダッシュボードの構築（ウィジェットの仕組み。特定の AWS サービスが必要とするシグナルはステップ 0.5）	dashboards.md を読む
オブザーバビリティの問題のデバッグ	troubleshooting.md を読む — 最も一般的な 5 つの修正から始まります
カナリアの失敗のデバッグ	synthetics.md を読む — 一般的な失敗の表を参照
CloudTrail の運用監査	cloudtrail.md を読む
CDK を使用した Lambda モニタリングの設定	alarm-template.ts を出発点として使用
合成カナリアの作成	synthetics.md を読む
ADOT コレクターの設定	otel-config.yaml を出発点として使用
ブレークポイント/スナップショットを使用した実行中サービスのデバッグ — 動的インストルメンテーション（稼働中のサービスを変更し、ライブデータをキャプチャします）	行動する前に dynamic-instrumentation.md を完全に読んでください。作成/削除の前にユーザーに確認し、重要なアクションの前には説明してください: 観察 → 仮説 → 提案するアクション → 期待される結果。ソースの検査だけでは仮説が特定されるのであり、根本原因が確認されるわけではありません。実行時の証拠で確認されるまで、疑わしい原因は暫定的なものとして扱ってください。

ルーティング — CloudWatch Omni (references/cloudwatch-omni/)

ライブの Space データに対して操作する 行は、ステップ 0 で Space が見つかったことを前提としています。ナレッジに関する質問には、ファイルから直接回答します。

ユーザーのニーズ	対応
概念。 Omni とは何か、Domain／Space／Dataset／付与設定／プロファイル／ビュー／アラート／コンテキストグラフとは何か、機能が Omni のものか CloudWatch のものか、セットアップをどこから始めるか	concepts.md を参照してください
ログまたはトレースのクエリ — SQL（SELECT … FROM logs.default / traces.default / default）、フィールドアクセス、スキーマの検出、最も遅い／失敗したスパン（durationNano、status.code）、TABLESAMPLE	query/sql-logs-traces.md を参照してください。最も遅いスパンまたは失敗したスパンについては、実際の結果が空の場合でも、「Span Duration」／「Finding failed spans」の必須事項に記載されたすべての項目を伝えてください
プロンプトに提示されたスパン、トレース、またはログレコード — 「このスパンを開いています。この中のエラーは何ですか」、貼り付けられたテレメトリーオブジェクト	query/sql-logs-traces.md の 「Reading a span or trace you already have」 セクションを参照してください。オブジェクト自体のフィールドに基づいて回答し、調査、クエリ、ユーザーへの取得依頼は行わないでください
メトリクスのクエリ — PromQL、AWS サービスごとの症状に対応するメトリクス、メトリクスがない理由、ゲージとカウンター	query/promql-metrics.md を参照してください。メトリクスには常に PromQL を使い、SQL は使いません
ビュー — 名前付きの再利用可能な SQL の作成、管理、クエリ（FROM view.<name>）	query/views.md を参照してください
Omni のダッシュボード — 作成、パネルクエリの根拠付け、panels[] の記述、グリッド配置、API の保存時の動作（不明なルートレベルまたはパネルレベルのキー、type／layout の欠落、不正な variant は保存時に 400 ValidationException で拒否されます。不正な enum 値、x+w>60、または config 内の不明なキーは、200 で保存され、レンダリング時に失敗するか無視されます。保存前に検証してください）、空または白紙のパネルの修正、*OmniDashboard API	dashboards.md を参照してください
Omni のアラート — Omni のアラート、CreateAlert／GetAlert／ListAlerts／UpdateAlert／DeleteAlert、profileId、アラート ARN、アラートとアラームの違いに関する言及。作成、調整、タグ付け、一覧表示、削除、通知	alerts.md を参照してください。アラート API は実在する正式な機能です。CloudWatch アラームに誘導してはいけません。Omni が有効でない場合の CloudWatch アラームについては、cloudwatch/alarms.md を参照してください
コンテキストグラフ — サービス X が遅い、または失敗している理由、その依存先、上流／下流、たどる方向、エッジタイプ CALLS／ACCESSES／RUNS_ON、影響範囲、インサイトや異常から根本原因をたどる方法、GetContextGraph	context-graph.md を参照し、「facts you MUST surface」セクションに記載された該当するすべての項目を伝えてください
エージェントの評価 — トレースのオンデマンド評価、評価器の選択、保存された gen_ai.evaluation.* スコアの読み取り（「最も成績の悪い評価器はどれか」「オンライン評価器のうち、異常がある／成績が振るわないものはどれか」）、トレースからのデータセット構築、オンライン評価の設定、カスタム評価器の記述、エージェントのトレースが送信されているかの監査	agent-evaluation.md を参照し、「tell the user ALL of this」の注意事項に記載された該当するすべての項目を伝えてください
プログラムによるアクセス — Omni に API または SDK があるか、コード、CI、IaC、AI コーディングエージェントから Omni を呼び出す方法	programmatic-access.md を参照してください。Omni には実際に公開されている SigV4 API があります。API がないと回答してはいけません。CloudWatch または X-Ray の CLI／SDK で代用してはいけません。また、Space の確認をせずに回答してください
Space へのアクセス権を持つユーザー、アクセス権の付与または取り消し、アクセスプロファイル、Space または Domain の作成、取り込み、転送、Slack、Azure、アプリまたは AI エージェントの計装、および CloudWatch 側での Application Signals へのサービスのオンボーディング	setting-up-cloudwatch-observability スキルに振り分けてください。ローカルにインストールされていない場合は、AWS MCP の retrieve_skill ツールで読み込んでください（skill_name: setting-up-cloudwatch-observability。参照先ファイルを指定する場合は file を渡してください）
複数の領域にまたがる場合	まず最も具体的なリファレンスを参照し、必要に応じて他のリファレンスも確認してください

ファイル

references/cloudwatch/

ファイル	内容
alarms.md	メトリクス、複合、異常検出アラーム — 設定、制約、推奨されるデフォルト値
log-insights.md	クエリ構文、コマンド、関数、既知の問題、再利用可能なクエリライブラリの全容
metrics.md	カスタムメトリクス、EMF 仕様、メトリクスフィルター、高解像度、保持期間
tracing.md	X-Ray → ADOT の移行、サンプリングルール、アノテーションとメタデータの違い、コレクター設定
dashboards.md	ウィジェットの種類、アカウント／リージョン間の設定、動的ラベル、共有
troubleshooting.md	すべての可観測性サービスのエラー → 原因 → 修正方法
cloudtrail.md	運用監査、イベントの種類、S3+Athena クエリ
synthetics.md	Canary のランタイム／ブループリントの制約、VPC ネットワーク、よくある障害
dynamic-instrumentation.md	動的インストルメンテーションのデバッグループ — 稼働中のコードへのブレークポイント／プローブの設定、スナップショットの取得と相関分析、作成／削除のゲーティング、スナップショット内の PII の取り扱い。scripts/cloudwatch/di_instrumentation.py + scripts/cloudwatch/di_snapshots.py で実行します。詳細は dynamic-instrumentation/ を参照してください
alarm-template.ts	ベストプラクティスに基づく CDK Lambda 監視（アラーム + ダッシュボード）
otel-config.yaml	X-Ray トレース + CloudWatch EMF メトリクス向け ADOT コレクター設定

意図的にここには含めていません： Application Signals のオンボーディング（有効化手順、ServiceEvents CI/CD チェーン、プラットフォーム別の 16 個のガイド）は初回セットアップに関するものであり、setting-up-cloudwatch-observability にあります。記憶を頼りにここで再構成せず、そちらを案内してください。

references/cloudwatch-omni/

ファイル	内容
concepts.md	Omniとは何か、何ではないか。用語集（Domain、Space、Dataset、grant、profile、view、alert、dashboard、context graph、evaluator）。OmniとCloudWatchの機能対応表。顧客がどちらの製品を指しているかを見分ける方法。セットアップの手順とその場所
context-graph.md	Omniがトレースとメトリクスから構築するサービス／リソースのトポロジー。GetContextGraphのリクエスト／レスポンスとCLI。上流と下流、および影響範囲の読み取り。インサイトまたは異常からホップごとに根本原因までたどり、クエリに切り替える方法
programmatic-access.md	パブリックSigV4 API（cloudwatch-omniエンドポイントのプレフィックス、cloudwatchの署名名）、アクセスグラントによるプログラムからの呼び出し元の認可、CLI／SDKでのアクセス（および未対応サービスエラーがクライアントのバージョンに起因する理由）、CloudFormation／CDK、AIコーディングエージェント、避けるべき誤った回答
query/sql-logs-traces.md	ログとトレースに対するSQL — テーブルの指定、必須の時間範囲、システムフィールド、フィールドへのアクセスと引用符の使用、スキーマの確認、サポートされる操作、関数、一般的なパターン（durationNanoによるスパンの継続時間を含む）、制約、TABLESAMPLE
query/promql-metrics.md	OmniのメトリクスはPromQLです — クエリ可能なもの（OTLP、スパンRED、OTelで拡張された提供メトリクス）とクエリ不可能なもの、ラベルの規則、__name__マッチャー、カウンターに対するrate()、AWSサービスごとのメトリクスカタログ（派生式とディメンションの注意点を含む）
query/views.md	名前付きSQLビュー：CreateView／UpdateView／DeleteView／ListViews、FROM view.<name>、名前と定義のルール、構成パターン
dashboards.md	Omniダッシュボード — 構成レシピ、根拠となるパネルクエリ、panels[]の本体とパネルの種類、可視化、60列のグリッド、APIの保存セマンティクス（ルートまたはパネルの不明なキーは400で拒否される。config内の不明なキーは200で保存され、レンダリング時に無視される。保存前に検証する）、空または何も表示されないパネルのトラブルシューティング、Create／Get／List／Update／DeleteOmniDashboard API、アーキタイプのテンプレート
alerts.md	Omniアラート — アラートとアラームの違い、評価（FIELD_VALUE／COUNT_OF_RESULTS、コントリビューター）、状態とデータなしの扱い、通知ルール、作成／更新／削除／タグ付け／取得の手順、アラートAPI
agent-evaluation.md	OTelトレースを使用したエージェント品質の評価 — 計装の健全性監査、評価器の選択、オンデマンドのスコアリング、オンライン評価、カスタム評価器、トレースからのデータセット作成、保存済みのgen_ai.evaluation.*スコアの読み戻し（検索プラン＋SQLの仕組み）。scripts/cloudwatch-omni/evaluate_traces.pyとscripts/cloudwatch-omni/capture_dataset_from_traces.pyを使用