mcpField
V
visualize-data

visualize-data

github.com/openaiデータ・データベース560100 回インストール4 週間前に更新
リポジトリ

visualize-data について

Visualize Dataは、レポート、ダッシュボード、ノートブック、スライドなどに使う定量チャートを作成・評価するスキルです。分析上の問いに基づいて可視化を選び、出力先に応じて描画方法と品質確認を調整します。

主な機能

  1. 01データの関係に合うチャートを選択
  2. 02簡潔なチャート仕様を作成
  3. 03出力先に応じて描画方法を選択
  4. 04レポートとダッシュボードの図表に対応
  5. 05最終表示環境でチャートを確認
  6. 06複数図表のチャート一覧を管理

活用シーン

  1. 01指標の推移に適したチャートの選択
  2. 02読みにくい可視化の改善
  3. 03HTMLレポート用チャートの準備
  4. 04納品前のダッシュボード図表の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openai/role-specific-plugins --skill visualize-data

インストール後、Claude Code で/visualize-dataを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
native-inline-visualizations.md
recharts-html.md

詳細

関連するスキル

ビジュアルで指標の変動について説明する必要がある場合は、$metric-diagnostics を使用してください。

ビジュアルが長期保存を前提とした分析レポートの一部である場合は、$build-report を使用してください。

データビジュアライゼーション

分析的に妥当で、ひと目で理解でき、レポート、メモ、スライド、ダッシュボード、ノートブック、ウィジェット、HTML 成果物に掲載できるほど洗練された定量ビジュアルを作成します。チャートは結論を裏付ける証拠として扱ってください。見た目は魅力的でも分析として弱いチャートは再設計し、技術的には正しくても解釈しにくいチャートは改善してください。

実行時の配信先の選択

surface = chatgpt_web と mode = work_mode の両方が明確に確認された場合、Data Analytics MCP のチャートまたはテーブルウィジェットを使って描画せず、インライン配信に render_chart または render_table を呼び出さず、ビジュアルの表示先として MCP 成果物を選択しないでください。この分岐は、別のワークフローですでにインライン配信が選択されている場合にのみ適用されます。レポート、ダッシュボード、HTML、ノートブック、その他の表示先よりもインライン配信を優先するものではありません。すでに選択されているインラインビジュアルでは、ネイティブな Work Mode の描画を優先し、native-inline-visualizations.md を読んで charts_widget_v2 または app_block の選択と呼び出しを行ってください。対応する bar、line、pie、scatter のいずれか1つのチャートでは、この実行環境で charts_widget_v2 が直接表示されるものとして扱い、フォールバックを検討する前に、そのライブな genui のコンテンツ参照を出力してください。利用できないと独自に判断したり、探したりしないでください。外側の完全な形式は genui{"charts_widget_v2":{"content":{...}}} です。{...} を実際のチャート仕様に置き換え、Markdown のバッククォートで囲まずに参照を出力してください。チャート仕様だけでは応答になりません。生の JSON、プレーンな HTML、コードフェンスは出力しないでください。app_block はホスト側で表示される場合に限って使用してください。Visualize プラグインがインストールされている場合は、ネイティブチャートまたは app-block の作成に関する最新の可視化ガイダンスも確認して従ってください。ただし、このスキルで定める配信条件とフォールバックの順序を優先してください。出力したネイティブビジュアルが拒否された場合、または描画に失敗した場合は、MCP 以外の表示先に適した、再現可能な静的チャートまたは Matplotlib チャートを使用してください。ビジュアルを描画できるものがない場合に限り、簡潔なテーブルを使用してください。このネイティブ描画失敗時のフォールバックとして、またはユーザーが Python、静的画像/ファイル、ノートブック向けの出力、エクスポートを明示的に求めた場合は、静的チャートまたは Matplotlib を使用してください。Data Analytics MCP ツールの実行が成功しても、Web Work Mode での配信が確認されたことにはなりません。選択したネイティブまたは MCP 以外の表示先で実際に描画されていない限り、ビジュアルをプロットまたは描画したと述べないでください。MCP サーバーやその他の呼び出し可能なツールは、引き続き有効なデータソースです。

選択したレポートまたはダッシュボードの配信先が HTML の場合は、recharts-html.md を読み、同じデータを使った静的なフォールバックを備える、同ファイルの Recharts-in-HTML の方法を使用してください。これには、Codex で明示的に指定された HTML、ChatGPT web Work Mode、PDF、Google Docs、Google Slides への変換に使用する HTML が含まれます。

Web Work Mode が明確に確認されていない場合は、既存の表示先選択ルールを変更せずに適用してください。

チャートの選択

最終的な表示形式がレポート、ダッシュボード、スライド、ノートブック、ウィジェット、または HTML の成果物である場合は、一般的な表示形式をチャートの契約に明記してください。

データの関係性最適なチャート効果的な使い方
時間または順序のある軸に沿った推移line形状がわかるだけの点を表示してください。塗りつぶしによって量の大きさが伝わりやすくなる場合に限り area を使い、sparkline は密度の高い KPI カードでのみ使ってください
時間に沿った構成比stackedArea各部分を合計値として読み取る必要がある場合に使ってください。構成要素ごとの推移の比較がより重要な場合は line に切り替えてください
カテゴリ間の比較bar順序に意味がない場合は並べ替えてください。ラベルが長い場合は横棒を使い、冗長な凡例は避けてください
ランキングまたは上位 N 件leaderboardコンパクトにまとめ、指標は 1 つにしてください。比較により多くのチャート情報が必要な場合は、順位付きの bar に切り替えてください
全体に対する各部分の構成比積み上げ bar分母を明示してください。スライスが少なく、概略を把握する場合に限り pie を使ってください
分布またはばらつきhistogram形状がわかる数値ビンを使ってください。グループ間の比較が主な目的の場合は boxPlot に切り替えてください
グループ間の分布boxPlot分布全体の形状より中央値とばらつきが重要な場合に使ってください。形状を把握する必要がある場合は histogram に切り替えてください
2 つの数値変数間の関係scatterパターンがわかるだけの異なる点を使い、意味のある観測粒度で数値の x と y を指定してください。安全に表示できる場合は、点のラベル、サンプル数/量のフィールド、および有用なグループ化候補を 1 つ残してください
密度の高い 2 次元パターンまたはコホートマトリクスheatmapマトリクスの形状や強度を示すために使ってください。点ごとのばらつきが重要な場合は scatter に切り替えてください
始点から終点への加算的なブリッジwaterfall要因の合計が終点の値と正確に一致する場合に限り使ってください。一致しない場合は、順位付きの bar を使ってください
順序のある段階的な進行または離脱funnel順序のある単一系列の段階に限り使ってください。ファネルの形状によって比較が歪む場合は、段階別の bar を優先してください

ワークフロー

  1. チャートを選ぶ前に、分析上の問いと一文でまとめた要点を定めます。最終的な表示先、意図する比較、ビジュアルを誠実に伝えるために必要な背景情報を特定します。
  2. Chart Selection から、正当化できる最もシンプルなファミリーとバリエーションを選びます。ビジュアルがそれらの成果物に含まれる場合は $build-dashboard または $build-report と連携し、裏付けとなる分析の検証が必要な場合は $validate-data を使用します。
  3. プロットコード、ダッシュボード設定、またはレンダラー固有の実装に着手する前に、簡潔なチャート仕様を作成します。次の項目を含めます。
    • 分析上の問いと要点
    • 標準ファミリーと具体的なバリエーション
    • 選択したビジュアルに対するデータの十分性:想定行数、トレンド表示の時間点数、散布図の観測数と粒度、要求された日付範囲と粒度、最初のクエリのデータが少なすぎる場合の代替案
    • 具体的なレンダラーが選択されている場合は、表示先に適したチャートタイプ、Recharts HTML チャートタイプ、または明示的に指定した静的レンダラー
    • 表示先を選択した後にのみ、配信先固有の制約を記載します。MCP ウィジェットまたはアプリの成果物では、共通の MCP 仕様を使用します。
    • パレットの方針、承認済みのパレットルート、色以外で区別する方法
    • 出力サイズ、最終コンテナー、エクスポート先または配信先、最終的な QA 対象
  4. 最終的な表示先に合った配信方法を選びます。
    • Web Work Mode であることが明確に特定されている場合は、アクティブなワークフローですでにインラインまたはチャット内表示が選択されているときに限り、references/native-inline-visualizations.md を読み、ネイティブの Work Mode レンダリングを優先します。インライン表示では render_chart や render_table を呼び出さないでください。対応する bar、line、pie、scatter のチャートを1つ表示する場合は、フォールバックの前に、直接表示される charts_widget_v2 のライブコンテンツ参照を出力します。その参照が拒否されるか、描画に失敗した場合、または要求されたチャートファミリーに適したネイティブレンダラーが存在しない場合に限り、再現可能な静的チャートまたは Matplotlib チャートを使用します。ビジュアルを表示するレンダラーを提供できない場合に限り、簡潔なテーブルを使用し、Data Analytics MCP ツールの結果を描画済みであるかのように説明しないでください。このネイティブ描画の失敗時のフォールバック、または Python、静的画像/ファイル、ノートブック、エクスポートの明示的な要求には、静的チャートまたは Matplotlib を使用します。
    • Web Work Mode 以外では、アドホック、インライン、チャット内表示、または表示先が特に指定されていないチャートの要求には、Data Analytics MCP チャートウィジェットをデフォルトで使用します。「このチャートを作成/表示/描画して」という要求は、ユーザーが Python、静的画像/ファイル、ノートブックのコード、HTML、BI/ダッシュボードの編集、スライド/ドキュメントへのエクスポート、または描画済み成果物を使用しないことを明示的に求めていない限り、MCP ウィジェットの要求として扱います。
    • 選択したレポート、ダッシュボード、BI、ノートブック、スライド、または静的 HTML の表示先に備わるネイティブチャートプリミティブを使用するのは、ユーザーがその表示先を明示的に選択した場合、またはアクティブなレポート/ダッシュボードのワークフローでチャート描画前にその表示先が選択された場合に限ります。
    • 選択したレポートまたはダッシュボードの表示先が HTML の場合は、references/recharts-html.md を読み、パッケージ化された Recharts ランタイムと、同じデータを使う静的フォールバックを使用します。
    • Web Work Mode でネイティブ描画に失敗した場合のフォールバックを除き、静的な Python チャートを使用するのは、ユーザーが Python、単独の静的画像/ファイル、またはノートブック向けの出力を明示的に求めた場合に限ります。再現可能なローカルレンダラーを選び、要求された形式でエクスポートして、出力を確認します。HTML レポートやダッシュボードでは、この方法をデフォルトとして使用しないでください。
  • 選択した表示先が描画を担う場合は、統制された BI またはダッシュボードのネイティブウィジェットを使用します。このスキルでは、ビジュアル仕様と QA 基準を提供します。
  • ローカルの HTML/CSS/SVG/canvas/JavaScript によるビジュアルを実装するのは、最終的な表示先でローカル描画、カスタム操作、オフラインでの持ち運び、またはウィジェットでは対応できない大規模な成果物が本当に必要な場合に限ります。
  1. 書式、構造、色、QA の順に作成します。まずファミリー、バリエーション、配信先を選び、次にラベル、注釈、基準値、保持する情報を決めてから、最後にパレットの方針と個別の色を選びます。
  2. 実際の表示環境でチャートを描画またはエクスポートします。HTML レポートやダッシュボードでは、ライブの Recharts マウントと、同じデータを使う静的フォールバックの両方を確認します。単独の静的出力を明示的に求められた場合は、ユーザーが要求した画像形式で保存し、その画像を確認します。
  3. 最終的なレポート、スライド、ダッシュボード、ノートブック、ウィジェット、または HTML レイアウトでビジュアルを確認します。チャート、ラベル、配色システム、またはコンテナーが最終コンテキストの QA に合格しない場合は、配信前に修正します。
  4. 複数のビジュアルを含むレポートまたはダッシュボードを公開する場合は、メモまたはソース資料に簡潔なチャートマップを残します。セクション、分析上の問い、選択したファミリーとチャートタイプ、フィールド、裏付けられる要点、パレットの方針、配信成果物、画像パス、または来歴情報の出典を記載します。

標準

選択ルール

お気に入りのチャートタイプからではなく、読者が必要としている分析上の問いや比較から始めます。最上位の分類は少数に抑えます。

  • Tables & Scorecards
  • Trend
  • Comparison & Ranking
  • Composition
  • Distribution
  • Relationship
  • Uncertainty & Benchmark
  • Matrix & Cohort
  • Decomposition & Progression

highlighted multi-series line、Likert、pie、Pareto、waterfall、faceted dot & interval、cohort heatmap などの具体的な形式は、これらの分類内のバリエーションであり、同列の分類ではありません。

  • 形状や比較を示す場合はチャートを、正確な値の検索にはテーブルを使用します。比較対象が3~8個あり、数値指標が1つだけで支配的な場合、正確な行の検索が目的でなければ、棒、ドット、ロリポップ、ランキングなどのチャートを優先します。
  • 確認済みのエビデンスに、比較可能な値、行、カテゴリ、セグメント、時点が多数含まれる場合、選択した表示面が利用可能で安全であれば、簡潔なチャートを既定として表示します。正確な行の検索が主なタスクである場合、誠実なチャートを作成するにはデータが少なすぎる場合、ユーザーがテーブルまたは文章のみを求めている場合、あるいは選択した表示面で有用なビジュアルをサポートできない場合に限り、表示を省略します。
  • プロンプトに「傾向」や「トレンド」とあるだけで、安易に line を選ばないでください。まず、読者が必要としているのが現在の状況、変化、計画との差、構成比、集中度、要因、進展、分布のどれなのかを判断します。
  • 情報量が不十分なトレンドチャートは公開しないでください。折れ線、面、スパークライン、インデックス化したトレンド、その他の時系列表示では、まず時間粒度を細かくするか日付範囲を広げて、表示系列の形状が分かるだけの観測点を確保します。トレンドのビジュアルでは、既定として時間軸上の点を少なくとも8~12個用意します。利用可能なエビデンスが数個の基準期間しか含まない場合は、日次または週次の行を照会する、遡る期間を延ばす、あるいは意味のあるセグメントや比較対象を追加してから表示します。質問の実態が少数の期間の個別比較である場合は、KPI ストリップ、グループ化棒グラフ、スロープチャート、テーブル、または説明文による注釈を代わりに使用します。
  • 情報量が不十分な散布図は公開しないでください。有用な散布図には、形状、クラスター、外れ値、例外を明らかにするだけの比較可能な観測値が必要です。既定では、意味のある点を少なくとも12~20個用意します。8個未満の場合は、各点が意図的に重要でラベル付けされている場合を除き、テーブル、棒、ドット/ロリポップ、または説明文による比較が適切と考えます。最初の結果にセグメントごとの集計値が数個しかない場合は、アカウント、ワークスペース、ユーザーコホート、顧客、モデル、エンドポイント、ルート、地域、または期間別セグメントなど、より細かい分析粒度を対象に一度だけ追加照会します。プロットするすべての行は同じ粒度にそろえ、総計、平均、詳細行を1つの散布図に混在させないでください。
  • 散布図では、独立して変動しうると考えられ、分母、期間、母集団、フィルターが共通する x 軸と y 軸の指標を選びます。信頼性の判断に使用した分母、サンプル数、またはボリューム指標を含めます。サイズによる符号化は、その第3の指標が解釈を実質的に変える場合にのみ使用します。点が少ない散布図や経営層向けの散布図には点ラベル用のフィールドを追加し、任意の色分けやフィルタリングに備えて、セグメント、プラン、ルート、製品ライン、モデルファミリー、地域など意味のあるカテゴリフィールドを保持します。一意の行 ID による色分けは避け、正確な識別にはラベルまたはテーブルを使用します。
  • ラベルが長い場合は横棒グラフを、順序に意味がない場合は値で並べ替えた棒グラフを使用します。
  • コンパクトなランキング形式の棒グラフは、数値が1つで、表示行数が3~8行のトップ N プレビューにのみ使用します。コンパクトなダッシュボードカードでは、既定で5~6行を表示します。多数の項目を閲覧したり正確な値を検索したりするにはページ分割されたテーブル、累積集中度にはパレート図、加算的な開始から終了までの要因の橋渡しにはウォーターフォール図を使用します。
  • 最新の DAU と WAU と MAU のように、KPI の定義や期間の定義を互いに順位付けするためにランキングチャートを使わないでください。最新値には KPI カードまたは簡潔なテーブルを使用し、変化や関係性を問う場合はトレンド、インデックス化したトレンド、シェアのトレンド、または比率のチャートを使用します。
  • 棒グラフで1つの指標をカテゴリ間で比較する場合、カテゴリ軸を1つ、数値軸を1つ使用します。各棒の色分けだけを目的として color、series、またはグループ化棒グラフのエンコーディングに同じカテゴリフィールドを設定しないでください。凡例が重複し、余分なグループ化軸があるかのように見えます。表示面が凡例なしのカテゴリ別色分けに対応している場合は、パレット/スタイル設定または直接ラベルを使用します。対応していない場合は、単一のマーク色を使用します。
  • 最新週の前週比変化率を指標ごとに示す場合など、同じ単位の変化を別々の KPI カテゴリ間で比較する棒グラフでは、カテゴリ別の色分けが見やすさに役立つことがあります。ただし、2つ目のカテゴリ軸がない限り、色はスタイルとして扱い、見えるグループ分けや凡例にはしません。
  • 製品、モデルファミリー、セグメント、座席サポート領域など、相互に異なるビジネスエンティティや構成要素を棒グラフで比較する場合、カテゴリの識別が重要であれば、すべての行を同じ固定色で表さないでください。カテゴリ別のスタイル設定と直接ラベルを優先し、単一の色は、意味上単一のエンティティについて1つの指標を繰り返し示す場合に限ります。軸ラベルですでにカテゴリ名が示されている場合は、色の凡例を追加しないでください。
  • アクティブユーザーのダッシュボードでは、最新の DAU、WAU、MAU、Plus DAU、Plus WAU の値に KPI カードを、時間経過に伴う変化にトレンドまたはインデックス化したトレンドのチャートを、構成比や比率の質問にシェアまたはスティッキネスの表示を、関連性のない週次の指標変化にカテゴリ別の横棒グラフを使用します。
  • 新しいチャートタイプを考案する前に、同じファミリー内でバリエーションを段階的に試します。折れ線からスモールマルチプルへ、棒からドット/ロリポップへ、散布図から密度図へ、積み上げ棒から円形での比較が明確に有用な場合に限って円グラフへ切り替えます。
  • 円グラフ、パレート図、ウォーターフォール図、リッカート尺度は、既定ではなくバリエーションとして使用します。
  • 3つ目の変数によって解釈が実質的に変わらない限り、バブルチャートは避けます。
  • 省略すると誤解を招くおそれがある場合は、ボリューム、分母、サンプル数、またはコホートのコンテキストを含めます。
  • 経営層向けの複数領域レポートで折れ線チャートが繰り返されている場合は、見直しが必要です。主な質問が時間経過に伴う連続的な変化である場合に限り、折れ線チャートを使用します。計画との差には基準線付きのドット/ロリポップまたは棒、構成比には積み上げ面または100%積み上げ棒、カテゴリ比較にはランキング棒またはランキングチャート、加算的な要因にはウォーターフォール図、コホートやマトリックス構造にはヒートマップ、順序付きの進展にはステージ棒グラフを検討します。
  • 領域ごとに1枚のスライドを使う経営層向けレポートでは、ビジュアルプランを作成する前にチャートファミリーを確認します。繰り返し使われているファミリーを監査し、異なる質問を扱う複数のセクションで同じファミリーを使用する場合は、その理由を明確にします。
  • レポート内のすべてのビジュアルが同じファミリーを使用する場合は、チャートマップに理由を記載し、いずれかのセクションが実際には状況、構成比、差異、または要因を問うていないか確認します。
  • すべて折れ線のビジュアルが4つ以上ある場合、データに適した代替手段を用いてレポートを再設計するか、ビジュアルの数を減らさない限り、複数チャートレポートの要件を満たしません。
Surface And Implementation
  • Web Work Mode 以外で、ユーザーがファイル、ノートブック、BI/ダッシュボード、レポート、スライド、ドキュメント、HTML、またはレンダリングなしの出力先を選択していないデータ可視化のリクエストでは、MCP ウィジェットツールが利用可能な場合、デフォルトで Data Analytics MCP のチャートウィジェットを使ってレンダリングします。Web Work Mode では、インラインでの出力がすでに選択されている場合に限り、references/native-inline-visualizations.md を読み、ネイティブの Work Mode レンダリングを優先します。対応する bar、line、pie、または scatter のチャートが 1 つの場合は、フォールバックする前に、直接表示される charts_widget_v2 のライブコンテンツ参照を出力します。再現可能な静的/Matplotlib チャートを使ってからコンパクトな表にフォールバックするのは、出力した参照が拒否された、またはレンダリングに失敗した場合、あるいはリクエストされたチャートファミリーに適したネイティブレンダラーがない場合に限ります。Web Work Mode での出力には render_chart や render_table を呼び出さず、ok:true の Data Analytics MCP ツール結果をブラウザーでビジュアルがレンダリングされた証拠として扱わず、静的または Matplotlib によるチャート作成は、ネイティブレンダリングに失敗した場合のフォールバック、またはユーザーが Python、静的な画像/ファイル、ノートブック向けの出力、あるいはエクスポートを明示的に求めた場合に限ります。ユーザーが別の出力先を明示的に選択した場合、このスキルの出力は、その出力先に関するチャートの選択、データ計画、実装ガイダンス、QA に限定します。
  • 選択した出力先が MCP Apps ウィジェット、または Data Analytics MCP のレポート/ダッシュボード成果物の場合は、チャートファミリーを選択した後に ../../src/analytics-app-core.md を読みます。MCP が対応する型の一覧を、MCP 以外の出力先における一般的なチャート選択の基準にしてはいけません。
  • レビュー済みのクエリ結果から MCP インラインチャートをレンダリングする場合は、ソースのメタデータ、探索に適したテーブル、チャートのエンコーディング、表示設定を指定して render_chart を呼び出します。ユーザーが Python/静的出力を明示的に求めた場合、またはウィジェットレンダラーが利用できない場合を除き、同じ結果に対して中間の Python チャート画像を作成してはいけません。
  • チャートに使用するテーブルには、チャートの描画に必要な最小限のフィールドより豊富な情報を含める必要があります。レビュー済みの結果に、文脈を示すディメンション、分子/分母のフィールド、日付またはコホートのフィールド、順位、ベンチマーク、比較対象期間の値、隣接する指標を安全に含められる場合、x、y、および任意の系列/色フィールドだけのソースデータテーブルを提供してはいけません。プライバシー、クエリコスト、ソースの制限、または指標の定義によって、より豊富なテーブルを用意できない場合は、その制約をチャート/レポートの注記に記載します。
  • レンダリングまたはエクスポートの前に、レビュー済みの結果テーブルの情報密度を確認します。チャートの時間点が 8 未満、意味のあるカテゴリが 4 未満、散布図の観測値が 8 未満、または 2/3 点だけでほぼ直線的な経路になる場合は、同じ主張を裏付ける、より細かい粒度のクエリ、期間の拡張、または関連する内訳の追加によって、サポートデータの改善を 1 回試みます。ソースの制限、クエリコスト、プライバシー、または指標の定義によって妨げられる場合は、その制約を記録し、KPI カード、期間別のグループ化棒グラフ、表、または正確な値を示す文章など、より誠実な形式に切り替えます。
  • ユーザーが指標を比較したり、軸を入れ替えたり、目標値と実績値を確認したり、関係性を示すビューを選んだりすることが妥当な場合は、意味のある定量フィールドを複数含めます。補助指標を捏造したり、追加のチャート形式を使えるようにするだけの目的で生データの詳細行を提供したりしてはいけません。
  • 任意のチャートに向けた形ではなく、現実的な代替案に適した形にデータを整えます。トレンドチャートでは通常、時間フィールド、値フィールド、意味のあるセグメント/比較フィールドを保持します。カテゴリ比較では、カテゴリ、値、有用なグループ化候補、順位/並べ替えの文脈を保持します。構成比チャートでは、利用可能な場合、分母または割合の文脈を保持します。散布図では、安定した点の識別子またはラベル、数値の x・y 指標、分母またはサンプルサイズのフィールド、有用な量/サイズ候補、解釈しやすいグループ化またはフィルターフィールドを 1 つか 2 つ保持します。保持したグループ化候補が、軸、ファセット、またはテーブルのラベルですでに示されている情報を補わない場合は、それを色/系列のエンコーディングに使ってはいけません。
  • カスタムのローカルなビジュアル実装は、選択した出力モードに合致し、最終的なコンテキストでの QA に合格した場合に限り、レポートとして完成したものとします。
  • 利用可能な場合は、選択した出力先のネイティブなチャートブロックを使用します。チャートの周囲に装飾的な枠線を追加してはいけません。
  • HTML レポートまたはダッシュボードを作成する場合は、必ず references/recharts-html.md を使用します。パッケージ済みの Recharts ランタイムを埋め込み、同じデータを使った静的なフォールバックを用意し、依存関係のインストールやリモートスクリプトに頼ってはいけません。
  • スタンドアロンの静的/Python 出力を明示的に求められた場合は、再現可能なローカルレンダラーを使い、エクスポート結果を確認します。静的画像の出力経路によって、パッケージ済み Recharts HTML のデフォルトを置き換えてはいけません。
  • ローカル環境は最小構成またはオフラインの場合もあると想定します。ネットワーク経由のインストールが成功する前提を置いてはいけません。
Visual Design
  • チャートタイトルは表示面に合わせてください。レポートやダッシュボードの視覚的な見出しは、中立的で説明的なものにし、要点は隣接する本文に記載してください。周囲に本文ブロックがない単独の静的チャートでは、要点を示すタイトルを使用してもかまいません。
  • 必要に応じて、指標の詳細、単位、分母、期間、コホート、フィルター、サンプルサイズ、ボリュームをサブタイトルに記載してください。注記で留意点を補足できますが、サブタイトルの代わりにはしないでください。
  • 可能であれば、チャートと周囲の出力でフォントファミリーを統一してください。白または白に近い背景、控えめなグレーのグリッド線、濃いチャコールのテキストを優先し、青、ゴールド、オレンジ、オリーブ、ピンクを中心とした、承認済みのパレットの色相を節度を持って使用してください。
  • 色だけに頼らないでください。系列や状態を区別する必要がある場合は、色調、塗りつぶしの有無、マーカーの塗り、線種、直接ラベル、順序付け、ファセットを使ってください。
  • segment、product_line、series など、意味のあるグループ化の次元が軸上の唯一のカテゴリになっていない場合に限り、色または系列のエンコーディングを設定してください。単一系列のチャートでは色の設定を省略し、凡例を表示するためだけにグループ化フィールドを作成したり、重複させたりしないでください。
  • プロットする前に、パレットの方針を1つ選んでください。
    • single-root preferred:単純な傾向、順位、分布、関係、マトリックス、反復パネルには、ニュートラルカラーを基調に、ニュートラルではない色相を1つと、その濃淡、塗りつぶしのない色、ニュートラルな参照色を使用します。
    • hard two-root cap:2値、正負、注目対象と文脈、ベンチマーク、比較対象、ウォーターフォール、パレート、発散型、強調した傾向、順序付き折れ線・ドットチャートでは、ニュートラルカラーに加えてニュートラルではない色相を最大2つまで使用します。
    • relaxed multi-category:カテゴリの識別自体が重要な円チャート、積み上げ棒、積み上げ面、グループ化棒、ステージ棒などでは、承認済みの色相を最大5つまで使用できます。それ以上必要な場合は、上位N件と「その他」にまとめるか、別の形式に変更してください。
  • 選択した各色相では、base トーンをデフォルトの非ニュートラルなマーク色として使用してください。mid は意図的にコントラストを高める場合に限って使い、dark はキーレイヤー、輪郭線、ラベル、参照線に使用してください。補助的な塗りつぶしには light、xlight、open を使用してください。
  • 宣言済みの色から明示的なパレットマップを生成してください。プロットライブラリのカテゴリ別デフォルトに、公開するチャートの色を選ばせないでください。
  • 正負の値では、デフォルトで緑と赤の組み合わせを避けてください。濃色と塗りつぶしのない色または淡色、符号付きの直接ラベル、明確なゼロ線を使ってください。ただし、文書化されたドメイン上の意味が例外を必要とする場合は除きます。
  • ウォーターフォールチャートでは、始点と終点に同じニュートラルカラーを使い、差分には正と負それぞれ1色ずつ、計2色の非ニュートラルカラーのみを使ってください。個々の要因に追加の色相や、非ニュートラルカラーの濃淡のキーレイヤーを加えないでください。
  • ウォーターフォール、ブリッジ、分散、その他、値の大きな基準値に対する変動が要点となるチャートでは、ゼロを含めることで意図した変動が大幅に圧縮される場合、値軸をゼロに固定しないでください。累積経路または差分範囲に合わせ、余白を設けた値軸のドメインを使用してください。正確な始点・終点・変化量のラベル、単位の表示、必要に応じてサブタイトル、キャプション、軸での明示的なフォーカス尺度の表示により、誤解を招かないようにしてください。値がゼロをまたぐ場合や、絶対的な大きさが問われている場合は、ゼロを表示範囲に含めてください。
  • マーク、キーレイヤー、ガイド、参照線には、統一した線幅体系を使用してください。ベンチマーク、キャリブレーション、理想値の線には、濃いニュートラルカラーを使ってください。
  • ラベルが依存する左側と下側の軸の基準線は表示したままにしてください。意図した比較に役立たない目盛り、ガイド、コネクターは削除してください。
  • 凡例を参照する手間を減らせる場合は直接ラベルを優先し、直接ラベルで煩雑になる場合はコンパクトな上部凡例を使用してください。
  • 長いラベルや負の値を含む横棒または発散型の棒チャートでは、左右に十分なスペースを確保してください。カード幅に合わせるために文字を小さくしないでください。
  • チャートのマーク内のグラデーション、任意の色付きチャート背景、一貫性のない角丸や場当たり的な角丸、強調表現としての厚みの使用は避けてください。
  • HTML アーティファクトでは、単独のチャートに実際のグリッド領域を確保してください。デフォルトは 8 columns、最小は 6、複雑なチャートでは 10 または 12 とし、モバイルでは縦に積み重ねてください。複数チャートの行は左端/開始端を揃えてください。
  • HTML のチャートコンテナー、凡例、KPI ストリップ、注記は、周囲のレポートまたはダッシュボードと同じ Data Viz System トークンに合わせてください。レンダリングされていない場合は、未使用の複数色 CSS 変数を削除してください。
  • ダークなチャートバリアントは、含まれるアーティファクトがダークな場合にのみ使用してください。公開するブランド付きウェブ出力では、ライトとダークの両方のバリアントを確認してください。
  • 研究用チャートでは、花のモチーフをヘッダーの右上隅に固定してください。サードパーティ、パートナーシップ、研究以外のチャートでは省略してください。
品質基準
  • グラフの選択は Chart Selection に従ってください。
  • 明示的な提供先を選び、それに沿ってください。その提供先が利用可能で、安全かつ有用であり、ユーザーが指定した出力形式に反しない場合にのみ、MCP ウィジェットを使用してください。
  • ユーザーが手法の説明を求めている場合、または詳細によって読者に伝える要点が変わる場合を除き、グラフの仕様、グラフを省略した理由、バリデーターの注記、QA の根拠は、経営層向けレポートの本文に表示しないでください。
  • 明示的な単独の静的プロット/Python プロットコードは、再現可能であり、指定されたグラフの仕様に目に見える形で適合している必要があります。汎用的なアドホックコードは、探索的なグラフに限り使用できます。
  • 形式は分析上の比較内容に合致させ、比較可能なグラフ間では尺度を正直かつ一貫性のあるものにしてください。
  • 絶対量を比較する標準的な棒グラフは、ゼロから始めてください。変化に焦点を当てたウォーターフォール、ブリッジ、差異の棒グラフ、小分割の変化グラフでは、ゼロ基準では意図する変化が大きく隠れてしまう場合に限り、正確なラベルと明確な尺度の手がかりを添えて、ゼロ以外または範囲を絞った領域を使用できます。
  • データの粒度、フィルター、日付範囲、分母、単位は、グラフが裏付ける主張と一致させてください。
  • 提供するすべてのグラフには、表示先に適した見やすいタイトルと、必要な単位、期間/コホートの文脈、分母、サンプル数、または量を示すサブタイトルを付けてください。
  • ラベル、目盛り、タイトル、凡例、吹き出し、ベンチマークラベル、注釈は、書き出したグラフや最終的なコンテナー内で、重なったり、切れたり、根拠となるデータから離れたりしないようにしてください。
  • 長いラベル、負の値、端の外側に置くラベル、ゼロ線の文脈、直接表示する値ラベルのために、十分なレイアウト領域を確保してください。
  • 複数系列の塗りつぶしマークには、異なるトーン、塗りつぶしなし、キーライン、マーカーの塗り、線種、直接ラベル、またはファセット分割を使用してください。隣接または重複する塗りつぶしが見た目で区別できない場合は、QA 不合格です。
  • 区別のために用いる線種、マーカーの塗り、塗りつぶしなし、キーライン、順序、ファセット分割、直接ラベルは、グレースケールでも判読できる状態にしてください。
  • 正負の状態は、例外について記録している場合を除き、既定の緑/赤の意味づけではなく、トーン、塗りつぶしなし、ゼロ線の文脈、符号付きラベルで示してください。
  • 書き出した SVG または HTML の色は、宣言したパレットの基調色とニュートラルカラーに一致させてください。意図的な例外を記録する場合を除き、使用していない多色のトークンは削除してください。
  • グラフの装飾要素は控えめにしてください。根拠のない色付き背景、グラデーション、装飾的なガイド、一貫性のない線幅、装飾目的のマークの塗りつぶしは使わないでください。塗りつぶしのあるマークにはキーラインを付け、ベンチマーク線、キャリブレーション線、参照線には濃いニュートラルカラーを使用してください。
  • タイトル、凡例、主要なラベルには濃いインクカラーを使用し、明確なヘッダーアンカーを共有させてください。テンプレートシステムで指定されている場合、数値の目盛りと直接表示する値ラベルにはモノスペースのスタイルを使用してください。
  • リサーチ用のグラフでは、固定された右上のブロッサム配置を使用してください。第三者、パートナーシップ、リサーチ以外のグラフでは省略してください。
  • 引き渡す前に、成果物を開く読者が目にする状態でビジュアルを確認してください。明示された分析上の問いに答えていること、符号と尺度が正直であること、ノート PC とモバイルの幅でラベルが収まること、色と色以外の視覚的符号化が理解できること、また、キャプションに指標、期間、出典が含まれるべきビジュアルでは、それらが記載されていることを確認してください。
  • 引き渡す前に、最終的なレポート、スライド、ダッシュボード、ノートブック、ウィジェット、または HTML のレイアウトを確認してください。上記の要件を満たしていない場合は、提供前に修正してください。

コメント