build-dashboard

関連スキル

ダッシュボードの作業で、データコンテキストの保存、またはセマンティックレイヤーの作成、更新、確認、修復が明示的に求められている場合に限り、$create-data-context を使用します。

ダッシュボードの指標が一致しない場合や、データソースの鮮度、粒度、結合、定義が信頼性に影響する可能性がある場合は、$analyze-data-quality を使用します。

ダッシュボードの作成

レポート、ノートブックのみの分析、スプレッドシート、一時的なチャット要約ではなく、ダッシュボードが必要な場合にこのスキルを使用します。優れたダッシュボードは、要約を先に示し、グラフを中心に構成し、ひと目で把握でき、対象者が監視、理解、または対応する必要がある内容を軸に整理されています。

入力の不足によってダッシュボードの要件、分析、または推奨内容が大きく変わる場合は、ユーザーに確認します。それ以外の場合は妥当な前提を置き、それを明示して進めます。

このスキルでは、ダッシュボードの要件、提供方法の選択、指標の定義、データソースへの期待、レイアウトの考え方、ダッシュボードの品質確認、引き継ぎを扱います。提供方法固有の仕組みについては、選択したダッシュボード仕様で扱います。

スキルの設定

実行時の提供先の振り分け

surface = chatgpt_web と mode = work_mode の両方が明確に確認できた場合は、Data Analytics MCP アーティファクトアプリを選択せず、そのダッシュボード仕様も読み込みません。mode = work_mode が明確に確認でき、surface が不明、または明確に codex_desktop と確認できない場合も、安全のため同じ非 MCP の提供ルールを適用します。ユーザーが選択した、または要求されたダッシュボードの提供先として明らかに適している接続済み BI の提供先を使用し、それ以外の場合はポータブルな HTML を作成します。Streamlit はユーザーから明示的に求められた場合に限り使用します。MCP サーバーやその他の呼び出し可能なツールは、引き続き有効なデータソースです。

データソースの探索と検証

関連するセマンティックレイヤーは出発点となる案内図として使用し、境界とはみなしません。

1. 考えられるデータソースをすべて調べます。 タスクに関連するデータが含まれている、または解釈を変える可能性がある、接続済みまたは提供済みのすべてのデータソースを検索します。各構造化データソースでは、関連するスキーマ、データセット、テーブル、ビュー、モデル、指標について、カタログまたはメタデータを新たに調査します。既知のデータソース、テーブル、ダッシュボード、セマンティックマッピングは出発点であり、探索の終点ではありません。
2. 重複や矛盾を比較します。 データソースが重複または食い違う場合は、管理主体、鮮度、定義、粒度、網羅性、直接性を比較します。最も権威のあるデータソースを使用するか、必要に応じて相互補完するデータソースを組み合わせます。重要な矛盾を記録し、選択したデータソースが回答の根拠となる理由を説明したうえで、結論を出す前にライブ読み取りで選択したデータを検証します。

データソースへのアクセスに関するガードレール

データソースへのクエリ、成果物の作成、結論の提示を行う前に、回答に特定の信頼できるデータソースが必要かどうかを判断します。

必須のデータソースを利用できない場合は、その手順を中止します。必要なデータソースをユーザーに伝え、利用可能にするか、レビュー済みの代替手段を提供するよう依頼します。より信頼性の低い代替データソースを同等のものとして扱ってはなりません。

不足しているデータソースが任意の補足情報にすぎない場合は、利用可能な中で最も信頼性の高い根拠を使って続行し、回答に大きく影響する場合はその不足を明示します。

ワークフロー

1. ダッシュボードの要件を定義する

誰がダッシュボードを使うのか、何を測定または監視する必要があるのか、どの指標が重要か、どの画面で使用するのか、また作成内容に影響する制約は何かを把握します。

主要な対象者、測定目標、指標の範囲、提供先、更新頻度への期待、必須フィルター、アクセス制約、共有の要件など、ダッシュボードに大きく影響する入力のみを確認します。ダッシュボードの主な目的が、ステータスの監視、定期的な運用レビュー、分析的な探索のどれかを判断します。これによってレイアウト、フィルター設計、検証基準が変わります。

ダッシュボードの目的、指標の定義、運用上の背景、対象者の期待、既存のダッシュボードの慣例が不明確で、適切な設計に支障がある場合は、$gather-business-context を使用します。

2. 提供先を選択する

ユーザーのニーズと利用可能なアクセスに適合する提供先を、最初に選びます。ユーザーが提供先または提供方法を指定した場合は、デフォルトの順序よりもその指定を優先します。

Web Work Mode が明確に確認された場合、または Codex デスクトップの提供方法が明確に確認されていない状態で Work Mode のシグナルが確認された場合は、次の順序を使用します。

1. ユーザーが接続済み BI ツールを選択している場合、またはそのツールが提供先を明確に担っている場合は、そのツールを使用します。
2. それ以外の場合は、ダッシュボードの引き継ぎに HTML を使用します。

Codex デスクトップの提供方法が明確に確認されていない場合、ツールが表示されていても Work Mode で MCP artifact アプリを選択しないでください。それ以外の環境では、次のデフォルトの順序を使用します。

1. デフォルトでは、接続済み BI ツールを使用します。現在のリクエスト、現在の実行コンテキスト、またはユーザーの明示的な希望から特定できる BI 提供方法を使用してください。指定がない場合は、別の提供方法を選択する前に、利用可能な接続済み BI ソリューションを探します。
2. 接続済み BI での構築ができない場合、リクエストに対して大がかりすぎる場合、またはユーザーが Codex 内でコンパクトな分析ダッシュボードを必要としている場合は、MCP artifact アプリを使用します。
3. BI と MCP が適さず、ユーザーが持ち運び可能な静的ダッシュボードを必要としている場合は、HTML を使用します。

Streamlit は、ユーザーが明示的に指定した場合、または既存の Streamlit アプリを変更する必要がある場合にのみ使用します。

構築前に、該当する仕様を確認します。

• ../../src/analytics-app-core.md：MCP artifact に共通する仕組み、ソースの安全性、ランタイムの動作、検証ヘルパーについて。
• specifications/bi-platform-dashboard.md：BI プラットフォームのダッシュボードについて。
• specifications/mcp-artifact-dashboard.md：MCP artifact アプリで表示するダッシュボードについて。
• specifications/html-dashboard.md：持ち運び可能な静的 HTML ダッシュボードについて。
• specifications/streamlit-dashboard.md：Streamlit ダッシュボードについて。

3. データを収集して検証する

次の順序でデータを扱います。

• レンダリング前にソースのパスを特定します。 ソースの特定はダッシュボード構築の一部であり、任意の追加作業ではありません。ダッシュボードの主要指標のソースパスを特定します。ウェアハウスや別の構造化データソースからデータを取得する必要がある場合は、~~structured_data を使用します。構造化データだけでは把握できないビジネス上の意味、信頼できる唯一の情報源に関する指針、指標の定義、要件が必要な場合は、~~company_docs、~~team_communication、~~dashboards_or_bi などのコンテキストレーンを使用します。
• 永続性のあるダッシュボードデータを使用します。 ダッシュボードに組み込む前にデータを検証します。用途に応じて範囲を限定した詳細テーブルを含める場合を除き、最終的な抽出データはコンパクトな集計済みデータにします。スクラッチテーブルや一時テーブルに依存する最終ダッシュボードは避けます。
• 信頼性を検証します。 シンプルなダッシュボードでは、表示する指標を信頼できるよう、ソース、粒度、鮮度、基本的な突合を確認します。新しいソース、最近のバックフィル、複雑な結合、予想外の結果など、データの信頼性に重大なリスクがある場合は、$analyze-data-quality を使用します。
• 時間とコンテキストの基準を確定します。 指標を選ぶ前に、ダッシュボードの設計に必要となる日付の基準、比較期間、最新の完了済みデータの日付、ソースの対象範囲、信頼できる成果物（ローンチ日、インシデント期間、キャンペーン期間など）を確定します。プロンプトに情報がない場合は、$gather-business-context を使用します。それでも不明な場合、ダッシュボードが大きく変わるときに限り質問します。それ以外の場合は、前提を明記し、その前提に沿ってクエリを設計します。
• ソースに裏付けられたデータが利用できない場合は中止します。 ユーザーがモックアップを明示的に依頼した場合を除き、フォールバックデータ、サンプルデータ、スクラッチデータ、または一部しか利用できないデータからダッシュボードをレンダリングしないでください。ダッシュボードの主要データを利用できない場合は、構築を中止し、必要なソースまたはアクセスをユーザーに伝えます。ソースパスがない場合に、実データからダッシュボードを作成したと主張しないでください。

4. 指標モデルを定義する

指標を選択します。

ダッシュボードの指標を選ぶ際は、測定対象を分類し、その対象に適したバランスのよい指標モデルを選択します。固定のチェックリストは使わないでください。どの指標群が意思決定に関係し、どの指標群を意図的に対象外とするのかを明確にします。

以下の指標群は必須セクションではなく、検討の手がかりとして使用してください。

• リーチ：何が、または誰がその対象を利用しているか、対象となり得る母集団、浸透率、アクティベーション、導入、カバレッジ。
• 量：イベント、利用状況、トランザクション、セッション、リクエスト、単位、スループット、頻度。
• 価値：収益、コスト、利益率、節約額、コンバージョン、顧客維持の価値、生産性、ビジネス成果。
• 品質：成功、失敗、信頼性、レイテンシ、満足度、正確性、安全性、サポート負荷。
• 深さ：継続利用、利用強度、機能の構成比、ワークフローの完了、本番運用への移行、成熟度、ライフサイクルの段階。
• 構成：セグメント、顧客の種類、地域、チャネル、モデル／製品／バージョン、プラン、ユースケース、コホート。
• 変化：傾向、成長、季節性、前後の変化、ベンチマーク、目標、予測、先行指標。
• リスクと制約：データのカバレッジ、データソースの鮮度、既知の見落とし、容量、コンプライアンス、運用上の制限。

ダッシュボードの幅を広げつつ、全体を平板化しないようにします。

測定対象と意思決定に関連する指標群をすべてカバーできるだけの幅広い指標を用意します。既定のビューは網羅的ではなく、階層的に構成します。まず主要な成果と、最も有力な要因を示し、その後、追加の関連指標をセクション、タブ、フィルター、詳細テーブル、補助ビューなどで提供します。選択した指標群は、ユーザーが監視または診断する必要に応じて、1つ以上の KPI、要因、ガードレール、内訳で表現できます。

作成を始める前に、選択した指標群をダッシュボード内の役割に割り当てます。既定のビューに表示する主要指標、変化や内訳を分析する診断指標、解釈のためのガードレール、検索や追加確認のための詳細指標に分けます。

主要指標カードの数は、意思決定に基づいて決めます。4つ、あるいは任意の固定数に合わせて、カードを水増ししたり削ったりしないでください。各カードには、意思決定に関係する固有の見出し指標を1つだけ表示します。チップは、前期間の値、目標、差分など、その見出し指標に直接結び付く短い比較情報にのみ使用します。独立した副次指標は、それぞれ個別のカード、グラフ、テーブル、説明文、詳細ビューに移します。関連性の高いカードは同じ行にまとめます。成果物のレンダラーは行をレスポンシブに調整するため、カード数が奇数でも問題ありません。

指標設計が難題である場合は、より専門的な対応に進みます。

この基本的な指標群の検討だけでは不十分な場合は、$design-kpis を呼び出します。たとえば、ダッシュボードにより深い指標フレームワーク、目標設定、正式な KPI のトレードオフ分析、またはこのワークフローで安全に推測できる範囲を超えた明確な定義が必要な場合です。推奨する指標を対象者とユースケースに適合させるため、ダッシュボードの概要、ビジネスの背景、データソースの背景、既存の指標定義、制約を渡してください。

データモデルの一貫性を保ちます。

可能な場合は、少しずつ異なるタイル用クエリを多数作るのではなく、再利用可能で簡潔なデータモデルを基盤にします。カード、グラフ、テーブル間で日付のロジック、フィルター、ディメンション、指標の定義を統一し、数値の整合性を保ちます。利用可能な場合は、選択したツールまたはセマンティックレイヤーの共有指標定義を再利用します。

5. ダッシュボードのレイアウトを設計する

閲覧者が操作する前から、デフォルトビューが役立つようにします。概要から詳細へとダッシュボードを構成します。主要なステータスまたは主要 KPI の背景情報を先頭に置き、次に時間経過に伴う変化を示し、その後に傾向を説明する内訳を表示します。照会や運用上のフォローアップが必要な場合は、詳細テーブルをページの下部に配置します。

グローバルフィルターは、ダッシュボード全体の表示を実質的に更新する場合にのみ使用します。フィルターパネルを密にするより、シグナルの強いコントロールを少数に絞ります。ダッシュボードはビジュアルを中心に、ニュートラルなものにします。メインキャンバスでは、短いラベル、直接的な指標名、控えめな注釈、最小限の説明文を使用します。表示ラベルとデータの鮮度を示すテキストには、人が読みやすい短い日付形式を使い、機械可読なソースメタデータには ISO タイムスタンプを使います。

運用上の精度のためにタイムスタンプが必要な場合を除き、表示ラベルとツールチップには、人が読みやすい短い日付形式を使います。

6. 適切なグラフを選ぶ

ダッシュボードでグラフの選択、視覚的なエンコーディング、またはグラフの仕上げが必要な場合は、$visualize-data を使用します。このスキルでは各グラフで伝える内容を定義し、詳細なビジュアルデザインは $visualize-data が担当します。

閲覧者の疑問に答えられる、最もシンプルなビジュアルを選びます。テキストやテーブルよりもパターンを理解しやすくなる場合は、グラフを使います。

直接比較するのが適切な場合に限り、指標を同じグラフにまとめます。それ以外の場合は、別々のグラフ、KPI カード、またはテーブルに分けます。

選択したダッシュボード仕様に従い、スキーマ、レンダラー、インタラクションに関する要件を正確に満たします。

7. 選択した環境で構築し、検証する

選択した環境のネイティブなパターンに従って構築します。引き渡す前に、ダッシュボードが問題なく開くこと、フィルターが機能すること、グラフが表示されること、数値の整合性が取れていること、アクセス方法が明確であること、パフォーマンスが許容範囲内であることを確認します。

後から再特定するのが難しい場合は、ソースまたはクエリのパスを記録します。

8. ダッシュボードを引き渡す

ダッシュボードのリンクまたはローカルの成果物パス、ソースやアクセスに関する注意事項、共有や運用に必要な残りの手順を記載します。通常の確認事項はサポート用の成果物に記録します。確認に失敗した場合、確認できなかった場合、またはユーザーに関係する注意事項が判明した場合を除き、ユーザー向けの引き渡し情報に内部チェックを記載しないでください。MCP アーティファクトダッシュボードでは、specifications/mcp-artifact-dashboard.md の検証およびレンダリング時の引き渡しルールに従います。

ダッシュボードの品質基準

引き渡す前に、ダッシュボードが測定のための画面として使いやすいことを確認します。

• 閲覧者が操作する前に、デフォルトビューで主要な対象者の疑問に答えられます。
• フィルターは少数で意味が明確であり、制御対象として示す各画面で機能します。
• 違いが明確にラベル付けされている場合を除き、カード、グラフ、テーブルの内容に整合性があります。
• グラフは、互換性のある指標を使って明確な疑問に答えます。
• テーブルは、グラフを中心とした概要の後に、照会、比較、または運用上のフォローアップを支援します。
• 測定対象に対して、指標の範囲が十分に広くなっています。主要な成果、重要な要因、ガードレール、補足的な内訳を含む関連する指標群を網羅しつつ、デフォルトビューの使いやすさも保たれています。
• KPI カードでは指標が正確に定義されています。ビジネスで定義された指標には、何を、どの期間に、どの分母または適格性ルールに基づいて数えているかを読者が理解できるよう、十分な情報が表示されているか、近くに説明が添えられています。
• ソースの鮮度、アクセス制限、注意事項が、必要な箇所に表示されています。
• レイアウト、ラベル、パフォーマンスが、選択した提供方式に適しています。
• 選択したダッシュボード仕様の検証およびレンダリングのルールに従っています。