signoz-creating-dashboards

ダッシュボードの作成

前提条件

このスキルは SigNoz MCP サーバーのツール（signoz_create_dashboard、 signoz_list_dashboards、signoz_list_dashboard_templates、 signoz_import_dashboard、signoz_get_dashboard、 signoz_update_dashboard、signoz_list_metrics、 signoz_get_field_keys、signoz_get_field_values、 signoz_aggregate_logs、signoz_aggregate_traces など）を呼び出します。 ワークフローを実行する前に、signoz_* ツールが利用可能であることを確認してください。利用できない場合、SigNoz MCP サーバーがインストールされていないか、設定されていません。まず signoz-mcp-setup を実行して、MCP 接続を初期化または修復してください。MCP ツールを使わずに、生の HTTP 呼び出しに切り替えたり、ダッシュボードの JSON を捏造したりしないでください。

使用する場面

次のような要望がある場合に、このスキルを使用します。

• 新しいダッシュボードを作成、セットアップ、または構築する。
• サービス、データベース、インフラストラクチャコンポーネント、AI／LLM プラットフォームを「監視」したり、「オブザーバビリティをセットアップ」したりする。
• 厳選されたダッシュボードテンプレートをインポートする。
• 一連のメトリクス／トレース／ログを 1 つの画面にまとめて可視化する。

次のような要望がある場合は使用しないでください。

• 既存のダッシュボードを変更する → signoz-modifying-dashboards
• 既存のダッシュボードに何が表示されているかを理解する → signoz-explaining-dashboards
• 結果を保存せず、一度限りのクエリを実行する → signoz-generating-queries

必須入力（厳守）

ダッシュボードの作成は書き込み操作です。ここで推測すると、共有ワークスペースが空のダッシュボードや対象範囲を誤ったダッシュボードで乱雑にし、他のユーザーが後から整理しなければならなくなります。このスキルでは緩やかな入力要件を設けています。ほとんどの項目には妥当なデフォルト値がありますが、推測できない項目もいくつかあります。

入力	必須	不足している場合の情報源
ダッシュボードの目的（NL での目標）	はい	$ARGUMENTS または直近のユーザー発言
技術／ドメイン（例：PostgreSQL、Redis、「決済パイプライン」）	はい	目的から解析し、それでも不明な場合は質問する
作成の確認（重複がある場合は、変更するか作成するかの選択も含む）	はい	ユーザーに質問する（ステップ 2）。重複がゼロの場合や、緊急性が明示されている場合でも必須
カスタム構築におけるリソースの対象範囲（サービス／名前空間／クラスター）	カスタム構築では必須	signoz_get_field_keys と signoz_get_field_values で検出し、見つからない場合はダッシュボード変数を使用する
カスタム構築で使用する具体的なメトリクス／シグナル	推定	技術と MCP の signoz://dashboard/* リソースから導き出し、プレビューに表示する
レイアウト	推定	デフォルトを適用する（下記の「デフォルト」を参照）

必須入力が不足しており、検出もできない場合は、書き込みツールを呼び出す前に処理を止め、ユーザーに質問してください。質問の提示方法はホストアプリケーションが決定します（構造化された確認ツール、インラインの <assistant_question> タグ、対話形式のプロンプトなど）。ホストの UI 表示ルールに従ってください。

質問に含める内容：

• 不足している項目：具体的な入力項目を示します（例：「カスタム構築の対象となるサービスまたはクラスターが指定されていません」）。
• 候補リスト：検出呼び出しで得られた値を、属性ごとに具体的に提示します。例： service.name → frontend、checkout、payments、inventory； k8s.cluster.name → prod-us-east-1、staging。
• 自由入力を許可する：提示した候補にない値もユーザーが指定できるようにします。

自律モード（人間が介在しない場合）では、呼び出し元にエスカレーションするか、上流のコンテキストから不足分を補ってください。いずれの場合も、推測した値を使って signoz_create_dashboard／signoz_import_dashboard に進まないでください。

ワークフロー

作成フローは、重複の確認 → 変更するか作成するかの選択 → テンプレート検索から始まります。一致するテンプレートがある場合は、データなしのプローブ → プレビュー → インポートを行います。カスタム構築の場合は、データなしのプローブ → 構築 → パネルごとのドライラン → プレビュー → 作成を行います。テンプレート検索は内部で行われます。ユーザーが事前に選択するのは、変更するか作成するかだけです。

ステップ 1：重複を確認する

signoz_list_dashboards を呼び出します。ほとんどのインストールではデフォルトの ページ（limit=50）に収まります。表現に特徴がある場合は filter 引数で絞り込み ます（signoz://dashboard/list-filter-guide を参照）。total 件を確認し終えるまで offset を指定してページを進めます。スキーマでは limit／offset の値に整数または 文字列を指定できます。

関連性で照合する 各既存ダッシュボードの小文字化した spec.display.name、.description、および tags を、ユーザーの技術分野／ドメインと 照合します。同じものだと人が認識できる場合に限り、一致として提示します。 「redis」ダッシュボードは、どちらにも database タグが付いているというだけでは 「postgresql」のリクエストに一致しません。次のステップのために、一致した各項目の spec.display.name、id、createdAt を集めます。

ステップ 2：ユーザーに確認する（変更または作成）

選択肢は必ず 2 つ提示します（テンプレートのインポートを独立した最上位の選択肢に しないでください。これはステップ 3b で決める内部判断です）。

• 重複が見つかった場合：「すでに類似したダッシュボードがあります： [名前、ID、作成日時の一覧]。これらのうち（a）1 つを変更する、（b）それでも新しい ダッシュボードを作成する、（c）中止する、のどれにしますか？」
• 重複がない場合：「このダッシュボードを新しく作成します。進めてもよろしいですか？」 （変更対象がないため、「変更する」という選択肢は提示しません。）

ユーザーの選択を待ちます。「変更」→ ステップ 3a。「新規作成」／確認 → ステップ 3b。 「中止」→ 中止します。

ステップ 3：作成または変更する

ステップ 3a：既存のダッシュボードを変更する

選択されたダッシュボード ID とユーザーの意図を添えて、ただちに signoz-modifying-dashboards に引き継ぎます。このスキルから signoz_update_dashboard または signoz_patch_dashboard を呼び出してはいけません。 変更は対象範囲外です（ガードレールの「スコープの境界」を参照）。

ステップ 3b：新しいダッシュボードを作成する

まずテンプレートを検索します。ユーザーはすでに新規作成に同意しています。 検索では、作成方法を決めます。

引数なしで signoz_list_dashboard_templates を 1 回呼び出します。 カタログ全体（約 95 件）は 1 回の呼び出しで返されます。内容をコンテキスト内で読み、 ユーザーの意図に最も合うものを選びます。候補が複数ある場合は、上位 3～5 件を提示し、 ユーザーに選んでもらいます。

結果に応じて分岐します。

• 明確に一致するテンプレートが 1 つある場合：ステップ 3b-i（テンプレートの インポート）に進みます。「事前構築済みの [タイトル] テンプレートが見つかったので、 これを使用します」とユーザーに簡潔に伝え、何が作成されるかを知らせます。「はい／いいえ」 の確認を待たずに進めます。
• 一致しそうなテンプレートが複数ある場合：候補を提示し、ユーザーに選んでもらいます。 選択されたら、ステップ 3b-i に進みます。
• 技術分野には一致するが、要求されたシグナルには一致しない場合：具体的な要望 （「Kafka で、クライアント別のコンシューマーのフェッチレートが必要」など）ではよく あります。これは「テンプレートなし」ではありません。テンプレートをインポートしてから、 追加パネルについて新しい ID とともに signoz-modifying-dashboards に引き継ぎます。 ゼロから作成しても、整備されたベースラインが失われるだけで利点はありません。
• テンプレートがない場合：ステップ 3b-ii（カスタム作成）に進みます。これは、その 技術分野のカタログ項目がないことを意味します。不完全に見える項目や、別のメトリクス群を 対象とする項目がある場合ではありません。テンプレートの内容はインポート前には読めない ため、合わないという疑いはあくまで仮説です。また、ステップ 3b-i.1 の確認はインポート 経路の中にあるため、その経路を外れる根拠にはなりません。まず確認し、その後で判断します。

ステップ 3b-i：テンプレートをインポートする

ツールに関するガードレール 使用できるテンプレートツールは signoz_list_dashboard_templates と signoz_import_dashboard のみです。シェルコマンドを実行したり、生の GitHub URL を取得したり、他のツール名を作り出したりしてはいけません。 signoz_import_dashboard はカタログ項目のテンプレート path を受け取り、1 回の 呼び出しでダッシュボードを作成します。そのため、JSON を自分で取得したり、その後に signoz_create_dashboard を呼び出したりする必要はありません。

Step 3b-i.1：事前データなしプローブ（早期失敗）

signoz_import_dashboard を呼び出す前に、テンプレートで使用されているシグナルが実際に取り込まれていることを確認します。テンプレートのインポートで最もよくあるサイレント障害は、「テンプレートは問題なくインポートされるのに、対象のテクノロジーがスクレイピングされていないため、すべてのパネルに『データなし』と表示される」ことです。ユーザーが役に立たないダッシュボードを開いて初めて、この問題に気づきます。

テンプレートの本文を事前に取得しないため、カタログエントリーの category、title、keywords と、ユーザーが明示したテクノロジーをもとにプローブします。代表的なシグナルを最大約5つ選び、確認します。合計数は少なく抑えてください。

• メトリクスベースのテンプレート（インフラ／ランタイム系のテンプレートの多く）：signoz_list_metrics を呼び出し、searchText にテクノロジーのプレフィックスを設定します（例：searchText="postgresql"）。結果が空なら、メトリクスファミリーが取り込まれていません。早期終了： 結果が空の場合は「存在なし」と判断し、残りのメトリクスプローブをスキップします。どれも結果がゼロになるためです。相対的な期間には timeRange を使用してください。サーバーのデフォルトではなく、正確な期間を指定する必要がある場合は、start／end（Unix ミリ秒の文字列）を渡してください。
• トレースベースのテンプレート（APM スタイル）：aggregation=count、timeRange=1h を指定して signoz_aggregate_traces を呼び出します。「何か流れているか」のプローブではフィルターは不要です。filter="service.name EXISTS" の追加は脆弱で、必要ありません。カウントがゼロなら、トレースが流れていません。
• ログベースのテンプレート：aggregation=count、timeRange=1h を指定し、フィルターなしで signoz_aggregate_logs を呼び出します。カウントがゼロなら、ログがありません。
• 変数の値（テンプレートが service.name、k8s.cluster.name などのリソース属性に明らかに依存している場合）：signoz_get_field_values を呼び出し、選択できる値があることを確認します。最上位のドロップダウンが空のダッシュボードは、空のパネルだらけのダッシュボードと大差ありません。

プローブの結果に応じて分岐します。

• すべてのシグナルが存在する → Step 3b-i.2 に進み、ユーザーには何も伝えません。
• 一部は存在するが、一部は見つからない → 見つからないシグナルを列挙し、続行する前にユーザーに確認します。多くのテンプレートは一部のデータが欠けていても役立つため、ユーザーに判断してもらいます。
• 何も存在しない → プローブ対象の期間に、このテクノロジーのデータが見つからなかったことと、取り込みを設定するまでダッシュボードに「データなし」と表示されることをユーザーに伝えます。そのうえで、このまま作成するか中止するかを選べるようにします。ユーザーの選択を待ってください。

このプローブは低コスト（クエリ数件、合計で約数百ミリ秒）です。データがない場合を早期に検出することで、テンプレートを使う際に最も避けたい UX の問題を防げます。

Step 3b-i.2：プレビュー、インポート、報告

1. プレビュー これから行う内容を、短い段落でユーザーに伝えます。対象のテンプレート（title、path）、カテゴリー、プローブの結果を説明します。自律モードでは利用側が続行し、対話モードでは人が介入できます。
2. インポート 選択したカタログエントリーの path（例：postgresql/postgresql.json）を指定して signoz_import_dashboard を呼び出します。サーバーは JSON を取得して検証し、1 回の呼び出しでダッシュボードを作成します。
3. 報告 応答を読み取り、ダッシュボードのタイトル、パネル数、セクションの内訳をユーザーに伝えます。ダッシュボードの変数（「service.name でフィルター」、「k8s.cluster.name でフィルター」）も示し、利用できる設定項目がわかるようにします。次の2つの対応を提案してください。「パネル、レイアウト、変数を調整しましょうか？」と「これらのシグナルにアラートを設定しましょうか？（signoz-creating-alerts）」。
4. カスタマイズの対応 ユーザーがインポートしたダッシュボードの変更を依頼した場合は、新しいダッシュボードの ID と依頼された変更内容を添えて signoz-modifying-dashboards に引き継ぎます。このスキルから signoz_update_dashboard を呼び出してはいけません。

Step 3b-ii：カスタム作成（テンプレートなし、またはインポート失敗）

Step 3b のテンプレート検索で一致するものが見つからなかった場合、ユーザーが提案されたテンプレートを明示的に拒否した場合、または signoz_import_dashboard が失敗した場合は、この手順を実行します。

Step 3b-ii.1: 要件を確認する

ユーザーに質問します（意図から回答がすでに明らかな質問は省略してください）。

1. シグナル：メトリクス、トレース、ログ、またはそれらの組み合わせ。
2. 具体的なシグナル：重要度の高いメトリクス、スパン属性、ログの重大度。
3. リソースの範囲：対象とするサービス、名前空間、クラスター、または環境。
4. 変数：ドロップダウンにするものと、ハードコードするフィルター（一般的な例：service.name、deployment.environment.name、k8s.cluster.name）。
5. セクション：パネルを「概要」「レイテンシー」「エラー」「飽和度」に分けるか、ドメインに適した別の構成にするか。

ユーザーの指定が曖昧（「X 向けに便利なものを作って」など）な場合は、以下のデフォルト表を適用し、プレビューに表示してください。

Step 3b-ii.2: 名前を調べてデータを確認する

MCP のガイドラインに従い、リソース属性のフィルターを常に優先してください。 パネルを作成する前に、使用する名前が存在し、データを出力していることを確認します。

1. メトリクス：技術に関連する searchText（例：searchText="postgresql"）を指定して signoz_list_metrics を呼び出し、正確な OTel メトリクス名を取得します。カタログに存在することは、データが流れていることを意味しません。使用する各メトリクスについて、代表的な期間を指定して signoz_query_metrics を呼び出し、実際にデータポイントがあることを確認してください。
2. リソース属性：関連するシグナルに対して fieldContext=resource を指定して signoz_get_field_keys を呼び出し、利用可能な属性を列挙します。変数として使用する属性に対して signoz_get_field_values を呼び出し、具体的な値が存在することを確認してください。実データでは、古い OTel semconv（例：deployment.environment.name ではなく deployment.environment）が使われていることがあります。デフォルト表のキーよりも、検出されたキーを常に優先してください。

検出されたシグナルのいずれからもデータが返されない場合は、ダッシュボードのデータがまだ取り込まれていないことをユーザーに伝え、取り込みを設定するまでパネルに「データなし」と表示されることを説明し、それでも作成するか、中止するかを確認してください。作成を開始する前に、ユーザーの選択を待ってください。

ステップ 3b-ii.3：ダッシュボードの MCP リソースを読む

これらは、JSON スキーマ、パネルの種類、クエリビルダーの構造、レイアウトのルールの信頼できる情報源です。スキーマの内容をこのスキルに書き写さないでください。サーバーとの同期がずれてしまいます。パネルの JSON を作成する前に、コアリソースを読んでください。

MCP リソースリーダーを利用できない場合の代替手段 MCP クライアントハーネスによっては、リソースを読み取るツールが公開されていません。このセッションで signoz://... URI を読めない場合は、同じシグナル種別（メトリクス／トレース／ログ）の既存ダッシュボードに対して signoz_list_dashboards と signoz_get_dashboard を実行し、その spec.panels マップを読んで、パネルの形状の実例を確認してください。

• signoz://dashboard/instructions：タイトル、タグ、説明、レイアウト、変数。
• signoz://dashboard/widgets-instructions：7 種類のパネルとレイアウトのルール。
• signoz://dashboard/widgets-examples：必須フィールドをすべて含む完全なパネル設定（最も重要なリソースです。各パネルには kind、spec.display、spec.plugin、クエリがちょうど 1 つ含まれている必要があります）。
• signoz://dashboard/examples：パネル、レイアウト、変数を組み合わせた、作成用ペイロード全体。
• signoz://dashboard/query-builder-example：クエリビルダーのリファレンス。

必要に応じて、シグナル固有のリソースを追加します。

• メトリクス（PromQL）：signoz://promql/instructions。 保存済みの PromQL では、宣言済みのダッシュボード $var 変数を参照できますが、signoz_execute_builder_query はそれらを展開しません。ドライランの場合に限り代表的なリテラルに置き換え、保存済みパネルでは置き換えないでください。Grafana 専用の $__rate_interval／$__interval は無効です。ドットを含む OTel メトリクス名には、Prometheus 3.x の UTF-8 セレクターである {"metric.name.with.dots"} を使用します。
• メトリクス（ClickHouse）：signoz://dashboard/clickhouse-schema-for-metrics ＋ signoz://dashboard/clickhouse-metrics-example。
• メトリクス（クエリビルダーの集計ルール）：signoz://metrics-aggregation-guide：メトリクスの種類ごとに有効な timeAggregation／spaceAggregation を選ぶ際に必要です。
• トレース（クエリビルダー）：signoz://traces/query-builder-guide。
• ログ（クエリビルダー）：signoz://logs/query-builder-guide。
• トレース（ClickHouse）：signoz://dashboard/clickhouse-schema-for-traces ＋ signoz://dashboard/clickhouse-traces-example。
• ログ（ClickHouse）：signoz://dashboard/clickhouse-schema-for-logs ＋ signoz://dashboard/clickhouse-logs-example。

ステップ 3b-ii.4: ダッシュボード JSON を構築する

上記のリソースに記載されているスキーマに従います。フィルター、groupBy、変数では、省略形ではなく OTel のセマンティック属性名を使用します。ユーザーが別の指定をしていない限り、以下のデフォルトを適用します。

ダッシュボードの作成／更新ペイロードでは、デフォルトの時間範囲や更新間隔は保存されません。パネルには、ビューアーで選択されたグローバルな範囲が適用されます。ユーザーが特定の期間を求めた場合は、timeRange、defaultTimeRange、refresh フィールドを作り上げるのではなく、最終的な引き継ぎ時にその範囲を明記します。Builder クエリ内に PromQL の範囲セレクターを記述しないでください。

SigNoz の kind と JSON 型を正確に使用します。signoz/TimeSeriesPanel は時系列を意味します（Grafana の timeseries は使用しません）。変数は ListVariable／TextVariable で、signoz/DynamicVariable、signoz/CustomVariable、または signoz/QueryVariable プラグインを持たせます。エンベロープは schemaVersion: "v6" と spec で構成し、作成時にトップレベルの name は含めません。サーバーは spec.display.name から変更不可の機械ラベルを導出します。タグは {key, value} オブジェクトです。完全な形式についてはリソースを参照してください。

パネル ID とグリッド項目は一対一に対応させます。両方の項目を一緒に作成／削除してください。spec.panels はパネル ID をキーとするマップであり、spec.layouts は content.$ref を使ってそれらの ID を配置します。インポートまたは再構築の際は、引き継がなかったパネルを $ref が指しているグリッド項目を削除してください。

スキルが適用し、プレビューに表示するデフォルト：

フィールド	デフォルト	上書きする場合
セクション構成（APM／サービス）	概要／レイテンシ／エラー／スループット	ドメイン固有の構成（例：DB：概要／接続数／スループット／スロークエリ）
セクション構成（インフラ／ランタイム）	概要／飽和度／エラー／レイテンシ	ドメイン固有の構成
主なパネル（サービス）	リクエストレート、エラーレート、p50／p95／p99 レイテンシ、スループット	該当しないものは省略
主なパネル（インフラ）	リソース使用率（CPU、メモリ）、飽和度、エラー／再起動数、スループット	テクノロジーに合わせて調整
カウンターの表示単位（レートまたはカウント）	秒あたりのレート	/sec が極小の小数（例：0.03/s）として表示される場合は、件数の少ない／バースト型／人間のペースで発生するカウンター（リクエスト、エラーカウント、再起動、OOM キル）について、より広い期間（24h～7d）における間隔ごとの increase カウントを使用します。ゲージ（CPU／メモリ／キュー深度）はすでに絶対値であり、影響を受けません。increase は選択した範囲に応じて Y 軸のスケールが変わるため、反射的に使うのではなく、意図的に選択することを明記してください
変数（サービス）	service.name、deployment.environment（または deployment.environment.name。どちらが存在するか signoz_get_field_keys で確認）	k8s 系の場合は k8s.cluster.name／k8s.namespace.name を追加
変数（k8s／インフラ）	k8s.cluster.name、k8s.namespace.name（または hostmetrics の場合は host.name）	service.name は削除。インフラのシグナルではほとんど設定されません
レイアウト	2 列グリッド（width: 6）、幅は 12 列。すべての項目で 0 <= x < 12、1 <= width <= 12、x + width <= 12	テーブルや系列数の多い時系列には全幅（x: 0, width: 12）を使用
サービスごとのパネルの GroupBy	リソース属性 service.name	単一サービスに絞り込む場合は削除

セクション セクションは spec.layouts 内の Grid エントリー 1 つで、独自の spec.display.title と spec.items を持ちます。表示順にセクションごとに Grid を 1 つ用意します。パネルは、そのグリッド内にグリッド項目を持つことで、そのセクションに属します。項目の座標は Grid ごとに設定されるため、先行するセクションに項目を追加しても、後続のセクションには影響しません。

タイトルと説明 ダッシュボードのタイトル（spec.display.name）には、テクノロジーと対象範囲を明確に記載します。「PostgreSQL」だけではなく、「PostgreSQL - prod-us-east-1」のようにします。spec.display.description は、用途を 1 文で説明する必要があります。タグは {key, value} 形式にし、テクノロジー、シグナルの種類、判明している場合は環境を含めます。

Step 3b-ii.5: 保存前の形状チェック

signoz://dashboard/widgets-examples は、パネルの必須フィールド、パネルタイプ固有の形状、プラグインの kind 名、および一般的な書き込み形状エラーの信頼できる情報源です。カスタムパネルの JSON をシリアライズする前に、必ず再確認してください。

すべてのビルダークエリと数式エントリーには、正の値の limit と空でない order が必要です。Raw リストパネルとトレースリクエストパネルのデフォルトは、タイムスタンプ降順で 100 件です（raw logs では id も追加します）。意図的に小さなリストページにする場合は、limit を下げてもかまいません。集計パネルでは、主要な集計の降順で 100 件を使用します。数式の出力では __result desc で 100 件を使用します。数式の評価前にベースクエリに適用されるため、参照される各ベースクエリでは 10000 件を使用します。disabled: true の数式を含む、すべての数式式から入力を特定し、すべてのベース builder_query リーフに到達するまで参照をたどってください。この依存関係の走査で決定するのは上限値のみであり、数式間の決定論的な評価順序を確立するものではありません。そのため、複合ペイロード全体をドライランしてください。メトリクスの order キーには、合成した spaceAggregation(timeAggregation(metricName)) 式を使用します。メトリクス名だけでは拒否されますが、__result と groupBy キーは使用できます。時系列の top-N はウィンドウ全体にわたってグループをランク付けするため、短時間の局所的な急増を含められないことがあります。数式入力のカーディナリティが 10000 を超える可能性がある場合は、フィルターやグループ化を絞り込んでください。

widgets-examples に記載されていないものの、signoz_create_dashboard で強制されるルールが 2 つあります。配列やオブジェクトに JSON.stringify を使用しないこと（spec、panels、layouts、tags、variables はネイティブ JSON です）、および パネルごとのクエリは 1 つだけであることです。そのため、2 つの系列を描画するパネルには、両方を含む単一の signoz/CompositeQuery エンベロープを持たせます。

Step 3b-ii.6: 保存前のドライラン（必須）

クエリを含むすべてのパネルで、signoz://dashboard/widgets-instructions の「パネルクエリのドライラン」に従ってください。 パネルにはすでに実行仕様が保存されているため、それを外側のエンベロープに取り出し、そのペイロードで signoz_execute_builder_query を呼び出してください。パネル JSON は渡さないでください。 短い絶対 Unix ミリ秒の期間（通常は直近 30～60 分）でドライランしてください。パネルの表示範囲を反射的に使用しないでください。期間を広げたり再試行したりする前に、そのセクションの空の結果とタイムアウトに関するルールを適用してください。ドライラン用のコピーには代表的な変数値を使用し、signoz_create_dashboard では $var のままにしてください。

実行ツールで保存済みフィールドを表現できない場合は、そのパネルを未検証として報告し、ユーザーが明示的に受け入れた後にのみ続行してください。サーバーエラーまたは検証エラーが発生した場合は中止します。ユーザーがテレメトリの欠如をすでに受け入れていない限り、予期しない空の結果が返った場合も中止します。

Step 3b-ii.7: プレビュー、保存、報告

1. プレビュー 作成予定の内容を、専門用語を使わない 1 段落の要約で示します。JSON ダンプは表示しません。20～30 パネルのペイロードは数百行になり、チャットではユーザーが内容を十分に確認できません。ユーザーが明示的に受け入れた検証上の不足があれば明記してください。

   要約：[対象範囲]の[シグナル]を追跡するダッシュボードで、セクションは[一覧]です。変数：[一覧]。 ドライラン：[N] 個のパネルが合格しました。未検証：[なし／受け入れ済みの不足事項]。 データ：[確認済み／ユーザーの明示的な選択により取り込み待ち]。

2. 保存 ペイロードを指定して signoz_create_dashboard を呼び出します。

3. 報告 ユーザーに次の内容を伝えます。

   • 作成したダッシュボードの id とタイトル。
   • パネル数とセクションの内訳。
   • 接続済みの変数。
   • 次の 2 つの追加提案：「パネル、レイアウト、または変数を調整しましょうか？」および「これらのシグナルにアラートを設定しましょうか？（signoz-creating-alerts）」

ガードレール

• 推測より厳密な入力を優先 カスタムビルドではリソーススコープが必須です。入力がない場合は作業を止めて、ユーザーに確認してください（上記の 必要な入力 を参照）。共有ダッシュボードのスコープを推測すると、確認するよりも後処理が難しくなります。
• signoz_list_dashboards では必ずページネーションを行う 1ページ目で止めると、重複を見逃して不要な項目が増えます。
• 最初に重複を確認 ユーザーが最初に選べるのは「既存のものを変更する」か「新規作成する」の2つだけです。テンプレートのインポートを独立した最上位の選択肢として提示しないでください。
• 作成する場合はテンプレートを優先 ユーザーが作成を選んだら、signoz_create_dashboard を呼び出す前に必ず signoz_list_dashboard_templates を実行してください。一致するテンプレートがあれば、signoz_import_dashboard でインポートし（その旨をユーザーに伝えるだけで構いません）、テンプレートが一致しない場合に限り、ゼロから作成してください。
• 保存前のデータなしプローブは必須 signoz_import_dashboard／signoz_create_dashboard を実行する前に、事前プローブ（Step 3b-i.1／Step 3b-ii.2）を実行してください。「データなし」のダッシュボードは、確認をもう1回行うよりも望ましくありません。ユーザーが今回のリクエストで明示的にオプトアウトした場合に限り、省略できます。
• カスタムビルドは保存前に検証 Step 3b-ii.6 に従ってください。有効なクエリセマンティクスを省略したドライランを、検証済みとして扱わないでください。
• カスタムビルドは保存前にプレビュー signoz_create_dashboard を実行する前に、平易な言葉で概要を提示し、ユーザーが意図を確認できるようにしてください。
• OTel 属性名を優先 service ではなく service.name、host ではなく host.name を使用してください。誤った名前を使うとパネルが空になります。キーの正確な名前（たとえば deployment.environment と deployment.environment.name のどちらか）は推測せず、signoz_get_field_keys で確認してください。従来の OTel セマンティック規約を使用しているインストールでは、.name のない形式が出力されます。
• メトリクス名を推測しない カスタムビルドでは、作成前に signoz_list_metrics でメトリクス名を確認してください。誤った名前を使うとパネルが空になり、ユーザーは後になって初めてそれに気づきます。
• 有効な JSON 形式のみを使用 signoz://dashboard/* MCP リソースに記載されたスキーマに従ってください。必須のパネルフィールドとクエリフィールドは signoz://dashboard/widgets-instructions と signoz://dashboard/widgets-examples に記載されています。配列やオブジェクトを JSON.stringify でラップしないでください。また、Step 3b-ii.4 に従い、パネルとグリッド項目の一対一対応、フィールドの型、プラグインの種類を厳守してください。
• スコープの境界 このスキルで作成するのはダッシュボードです。ユーザーが既存のダッシュボードの変更、編集、並べ替え、拡張を依頼した時点で（インポート直後の場合も含む）、signoz-modifying-dashboards に引き継いでください。このスキルから signoz_update_dashboard や signoz_patch_dashboard を呼び出さないでください。

例

テンプレートをそのまま使う場合、テンプレートを選ぶ場合、重複が見つかった場合、カスタムビルドの場合の4つの標準的なフローについては、references/examples.md を参照してください。