2026/3/31 9 min read

デジタル庁のダッシュボードガイドブックを Claude Code のスキルにした

デジタル庁が「ダッシュボードデザインの実践ガイドブック」をリニューアルした。このツイートで知った。

＜ぜひ拡散のほどを！＞
デジタル庁より公表している「ダッシュボードのテンプレート」をリニューアルしました。誰でも、より簡単にキレイなダッシュボードが作れるようになります。

・グラフの種類を大幅に増えました
・カラーパレットが7タイプから選べます
・活用事例がどんどん増えています
— hikaru / 樫田光 (@hik0107) March 31, 2026

行政向けの資料だけど、民間でもそのまま使える内容だった。チャートの選び方、Do’s/Don’ts、カラーパレットまで、ダッシュボードを作るときに必要な判断基準が一通り揃っている。

業務では Lightdash で BI as Code をやっている。ダッシュボードやチャートを YAML で定義して Git 管理し、CI/CD でデプロイする運用。YAML を書く部分は Claude Code のスキル（コンテキストとして自動で読み込まれるドキュメント）で半自動化しているが、「どのチャートタイプを選ぶか」「何を載せるか」の設計判断はスキルでカバーできていなかった。

ガイドブックの内容がちょうどこの穴を埋めてくれるので、スキルに変換した。

ガイドブックの概要

59ページの PDF で、以下の構成になっている。

はじめに — ダッシュボードの定義と類型（提示型 vs 探索型）
要件の整理 — 5W1H フレームワーク、制約条件の確認
プロトタイピング — 載せるべき情報の選定原則、レイアウトの考え方
情報表現のポイント — グラフの種類と選び方、カラーパレット、グラフ設計の原則、Do’s/Don’ts
実装 — チェックリスト、アクセシビリティ

「情報表現のポイント」の章が特に良くて、Do’s/Don’ts が具体的な図解つきで書かれている。「棒グラフの原点は0にする」「色のみで分類を識別しない」「タイトルにデータ種別を表記する」など、わかっているつもりでも雑になりがちなポイントが並んでいる。

ガイドブックの中身で使えるところ

スキルに入れるにあたって、59ページの中から BI as Code のワークフローで実際に使える部分を抜き出した。いくつか紹介する。

ダッシュボードの類型

ダッシュボードは「提示型」と「探索型」の2つに分かれる、という整理がまず冒頭にある。

	提示型	探索型
目的	概況の把握	詳細の分析
前提知識	一般的な知識	特定のドメイン知識
操作	単純な操作	複雑な操作

自分のチームで作っているダッシュボードはほぼ提示型。「見る人が素早く状況を把握して、異常に気づいて、行動の必要性を判断する」のが目的。これを言語化してスキルに入れておくと、Claude が勝手にフィルターを大量に生やしたり、探索型寄りの設計にしたりすることが減る。

チャート選択ガイドライン

「伝えたい情報」からグラフの種類を逆引きするテーブルがある。スキルへ組み込む際、Lightdash の chartType とのマッピングを追加した。

伝えたい情報	グラフ	Lightdash chartType
時間変化・傾向	折れ線グラフ	`cartesian` (line)
数量比較	棒グラフ	`cartesian` (bar)
構成比	円グラフ/ドーナツ	`pie`
KPI 単値	指標	`big_number`

特に円グラフについて「多くの場合、棒グラフの方がデータを正確に伝えられる」と明記されているのが良い。これがスキルに入っていると、Claude が安易に円グラフを提案しなくなる。

Do’s / Don’ts

10項目ある中から、自分が刺さったものをいくつか。

タイトルにデータ種別を表記する —「国産自動車」ではなく「国産自動車の出荷台数（月次推移）」。タイトルだけでグラフの中身がわかるようにする
グラフと凡例を隣接させる — 凡例が離れていたり、順番がグラフと逆だったりすると誤読の原因になる
グラフに使用する色数を絞る — 目安は 1〜5色。注目すべき系列を明確にする

わかっていても、チャートの YAML を書いているとつい雑になる。スキルに入れておくことで、レビュー時にも「ガイドブックの Do’s/Don’ts に照らしてどうか」という観点が入る。

スキルの構成

もともと Lightdash の YAML テンプレートや実装手順をまとめたスキルがあった。デザイン原則を同じスキルに足すとサイズが膨れるので、別スキルに分けた。

設計判断（WHY / WHAT）  → lightdash-design-principles（今回追加）
実装手順（HOW）          → lightdash-guide（既存）
制約・規約（MUST）       → rules/lightdash/（既存）

スキルの description にキーワードを書いておくと、Claude Code が指示内容に応じて自動で読み込むスキルを選んでくれる。「ダッシュボード設計」「チャート選択」みたいな話をするとデザイン原則スキルが読み込まれ、YAML を書き始めると実装ガイドスキルに切り替わる。

59ページをスキルに落とすときの取捨選択

PDF をそのままスキルに突っ込んでも効かない。コンテキストが長すぎると Claude は重要な部分を拾えなくなるし、自分のワークフローに合わない記述が混ざっていると判断がブレる。59ページを約280行のスキルに絞り込むにあたって、いくつか判断基準があった。

「コードで表現できるか」で切る

スキルに入れる意味があるのは、Claude が YAML を書くときに参照できる情報。「棒グラフの原点は0にする」は YAML の min: 0 に直結するから入れる。「PowerPoint でプロトタイプを作る」はコード生成と関係ないから入れない。

同じ理由で、アクセシビリティの詳細（スクリーンリーダー対応など）も外した。Lightdash の YAML レベルでは制御できない領域なので、スキルに書いても Claude が実行できない。

ツール固有のマッピングを足す

ガイドブックの記述はツール非依存。「時間変化を見せたいなら折れ線グラフ」とは書いてあるが、それが Lightdash の chartType: cartesian の type: line に対応するとは書いていない。

この対応関係を足さないと、Claude は原則を理解しても正しい YAML を出力できない。逆に言えば、マッピングさえ足せばガイドブックの知識をそのまま YAML 生成に活かせる。ここの効果が一番大きかった。

自チームの文脈を足す

ガイドブックは汎用的に書かれているので、「提示型と探索型がある」という説明はあっても「うちのチームはどっちか」は書いていない。スキルには「主に提示型」と明記した。これがないと Claude は毎回どちらの方針で設計すべきか迷う。

カラーパレットも同じで、ガイドブックには7タイプのパレットが載っているが、全部入れると Claude がどれを使うか迷う。実際に使うパレットだけに絞った。

捨てたものの基準

まとめると、以下に該当するものは外した。

コード生成に関係しないプロセスの説明（プロトタイピングの進め方、ステークホルダーとの合意形成など）
使っている BI ツールでは制御できない領域
複数の選択肢が並列で書かれていて、自チームの文脈を足さないと判断できないもの（そのまま入れると迷いの原因になる）

利用規約

ガイドブックは公共データ利用規約（PDL1.0）の下で公開されている。CC BY 4.0 と互換性があり、出典を記載すれば自由に利用・加工・商用利用が可能。スキルファイルには出典と加工した旨を記載している。

やってみて

Do’s/Don’ts が図解つきで書かれていて、そのまま実務に持ち込める内容だった。

スキルにしたことで、ダッシュボードの YAML を書くときに設計原則が勝手にコンテキストへ入るようになった。Claude が円グラフを出してきたときに「スキルに『棒グラフの方が正確に伝えられる』と書いてあるので棒グラフにします」と自分で判断を修正してくれる、みたいなことが実際に起きている。

ガイドブック自体は BI ツールに依存しない内容なので、Lightdash 以外でも参考になるはずだ。

出典：「ダッシュボードデザインの実践ガイドブック」（デジタル庁）(2026年3月31日版) https://www.digital.go.jp/resources/dashboard-guidebook PDL1.0 に基づき、内容を要約・加工して利用。