Claude Codeのデータ可視化、グラフより先に決める3つのこと

「サイトのデータ、いい感じにグラフにして」

そうClaude Codeに頼んだら、5分でそれっぽい折れ線グラフが出てきました。色もきれい、アニメーションも滑らか。でも僕はその画面を3秒見て、そっと閉じました。だって、それを見て僕が何を変えればいいのか、まったく分からなかったからです。

グラフは「作れた」のに「使えない」。これ、可視化でいちばんよくある事故です。

僕はこの記事で、グラフの描き方そのものよりも前の話をします。誰が何を決めるために、どのデータを、どう見せるか。Claude Codeはコードを書くのは速いけれど、ここを決めるのは僕らの仕事です。ライブラリの比較はClaude Codeでグラフライブラリを選ぶ実務ガイド、D3の手を動かす実装はClaude CodeでD3.jsデータ可視化を実装するに任せて、ここは「考え方・データ準備・伝わる見せ方」に絞ります。

この記事の要点

• グラフを作る前に「誰が・何を見て・何を決めるか」を1行で書く。これが全部の出発点。
• きれいさよりデータ準備が9割。型・単位・空欄・並び順を先に固定すると、Claude Codeが崩れない。
• グラフの選び方は単純。時間は折れ線、比較は棒、割合は円か積み上げ、即見たい数字はKPIカード。
• 棒グラフはゼロ始まり、色だけで意味を持たせない。この2つを破ると「人をだますグラフ」になる。
• Claude Codeには完成形ではなく「データ契約・空データ・誤解防止ルール」を渡すと、レビューできる成果物が返る。

グラフより先に「決める文」を1行書く

可視化の失敗は、たいてい着手の順番が逆です。グラフを先に作って、あとから「で、これ何に使うんだっけ」と考える。順番が逆だから、きれいだけど使えない画面が量産されます。

僕がいま必ずやるのは、最初に決める文を1行書くことです。フォーマットはこれだけ。

〔誰が〕〔どの数字〕を見て、〔どのアクション〕を決める。

ClaudeCodeLabならこんな具合です。

• 僕が、記事ごとの読了率とCTAクリックを見て、導入文と内部リンクの位置を直すか決める。
• 僕が、チャネル別の売上を見て、どの流入経路に記事を足すか決める。
• 僕が、相談フォームの完了数を見て、研修・相談への導線を増やすか決める。

この1行があると、グラフは自動的に絞られます。「読了率を見て導入文を直す」なら、必要なのは記事別の棒グラフであって、サイト全体のページビュー折れ線ではありません。ページビューを眺めても、僕は明日何も直せないんです。

逆に言うと、決める文が書けない数字はグラフにしない。「なんとなく見たい」は、たいてい見ても何も起きません。可視化は飾りじゃなくて、行動を変えるための道具です。

「きれいさ」より「データ準備」が9割

ここが今日いちばん伝えたいところです。Claude Codeが出すグラフが崩れる原因は、グラフ描画のコードじゃなくて、渡すデータが汚いことにあります。

僕が最初にやらかしたのは、CSVをそのままClaude Codeに渡して「グラフにして」と言ったことです。結果はこうでした。

• revenue が文字列のまま扱われて、合計が "840980" みたいに連結された
• 空欄が NaN になって、ツールチップだけ静かに壊れた
• 日付が文字列ソートされて、2026-05-10 が 2026-05-2 より前に並んだ

どれもグラフの問題に見えて、全部データの問題です。だから僕は、グラフを描く前にデータ契約を決めます。データ契約というのは、画面が受け取るデータの「約束ごと」のこと。難しい話じゃなくて、こう書くだけです。

項目	型・単位	約束
date	文字列(ISO)	2026-05-01 の形。並べ替え可能にする
channel	決まった単語	organic / email / social など。表記ゆれ禁止
sessions	数値	整数。空欄は0に変換
revenue	数値(USD)	金額。文字列で来たら数値化
readRate	数値(0〜1)	読了率。0.61 のような割合で持つ

この表をプロンプトに貼るだけで、Claude Codeの出力が見違えます。「revenue は数値、空欄は0、不正な日付の行は捨てる」と先に宣言しておくと、グラフに渡る前にゴミが弾かれるんです。

下が、僕が実際に使っているデータ準備の最小コードです。生のCSVを受け取って、型を固定し、チャネル別に集計するところまで。グラフはこのきれいになったデータを受け取るだけで済みます。

// prepare-data.ts
// 画面に渡す前に、データの「約束ごと」をここで全部守らせる
export type Channel = "organic" | "email" | "social" | "referral" | "paid";

export type TrafficRow = {
  date: string;     // ISO形式の文字列
  channel: Channel;
  sessions: number;
  revenue: number;  // USD
  readRate: number; // 0〜1の割合
};

const channels: Channel[] = ["organic", "email", "social", "referral", "paid"];

// 文字列を数値に。変なものは fallback に倒す
function toNumber(value: string | undefined, fallback = 0) {
  const parsed = Number(value);
  return Number.isFinite(parsed) ? parsed : fallback;
}

// 知らないチャネル名が来たら referral 扱い（表記ゆれを吸収）
function toChannel(value: string | undefined): Channel {
  return channels.includes(value as Channel) ? (value as Channel) : "referral";
}

// 生CSV → 型が保証された行の配列
export function parseCsv(csv: string): TrafficRow[] {
  const [headerLine, ...lines] = csv.trim().split(/\r?\n/);
  if (!headerLine) return [];
  const headers = headerLine.split(",").map((h) => h.trim());

  return lines
    .filter(Boolean)
    .map((line) => {
      const cols = line.split(",").map((c) => c.trim());
      const get = (name: string) => cols[headers.indexOf(name)];
      return {
        date: get("date") ?? "",
        channel: toChannel(get("channel")),
        sessions: toNumber(get("sessions")),
        revenue: toNumber(get("revenue")),
        readRate: toNumber(get("readRate")),
      };
    })
    // 日付が壊れている行は、グラフに渡す前に捨てる
    .filter((row) => row.date && !Number.isNaN(Date.parse(row.date)));
}

// チャネル別に合計し、CVRではなく「読了率の平均」も出しておく
export function aggregateByChannel(rows: TrafficRow[]) {
  const map = new Map<Channel, { channel: Channel; sessions: number; revenue: number; readSum: number; count: number }>();

  for (const row of rows) {
    const cur = map.get(row.channel) ?? { channel: row.channel, sessions: 0, revenue: 0, readSum: 0, count: 0 };
    cur.sessions += row.sessions;
    cur.revenue += row.revenue;
    cur.readSum += row.readRate;
    cur.count += 1;
    map.set(row.channel, cur);
  }

  return [...map.values()]
    .map((r) => ({
      channel: r.channel,
      sessions: r.sessions,
      revenue: r.revenue,
      readRate: r.count === 0 ? 0 : r.readSum / r.count, // 平均読了率
    }))
    .sort((a, b) => b.revenue - a.revenue); // 売上の大きい順
}

このコードのキモは、グラフのコードが1行も入っていないことです。データの掃除と集計だけ。ここが固まっていれば、あとはRechartsでもD3でも、何で描いても崩れません。逆にここを飛ばすと、どんなに高機能なライブラリを使ってもNaNが混ざります。

引用符つきCSVやカンマを含む列、タイムゾーン変換が必要なら、Papa Parseのような専用パーサーに切り替える判断も、Claude Codeに「この簡易パーサーで足りるか」と聞いてしまうのが早いです。

グラフの選び方は、覚えるほど少ない

「どのグラフを使えばいいか」で悩む人が多いですが、実は選択肢はほとんどありません。目的とグラフは、ほぼ一対一で決まります。

見たいこと	使うグラフ	例
時間とともにどう変わったか	折れ線	日別セッション、週次売上
カテゴリ同士を比べたい	棒グラフ	チャネル別売上、記事別読了率
全体に占める割合	円 / 積み上げ棒	売上の構成比
とにかく今いくつか即見たい	KPIカード	今月の売上・登録数

迷ったら棒グラフでだいたい正解です。困るのは円グラフで、カテゴリが5個を超えると一気に読めなくなります。色の違いだけで7個も8個も比べるのは人間には無理なので、その場合は棒グラフに倒します。

もうひとつ、初心者がやりがちなのが二軸グラフです。売上とCVRみたいに単位が違う指標を、左右の軸に分けて1つの折れ線に重ねるやつ。一見プロっぽいんですが、軸のスケール次第で「相関しているように見える」だけの錯覚を生みます。僕は管理画面では二軸を使わず、素直にグラフを2つに分けます。並べたほうが、よっぽど正直です。

ここまでのデータの流れを図にすると、こんな順番です。グラフ描画は最後の最後で、その前の準備が全部です。

flowchart LR
  Raw["生CSV / イベントログ"]
  Contract["データ契約<br/>(型・単位・約束)"]
  Clean["掃除・集計"]
  Decide["決める文<br/>(誰が何を決める)"]
  Chart["グラフ選び"]
  Check["誤解チェック"]

  Raw --> Contract --> Clean --> Chart
  Decide --> Chart --> Check

「人をだますグラフ」になる2つの線引き

伝わる見せ方の話で、これだけは外せないという線が2本あります。どちらも、守らないと無意識に人をだますグラフになります。僕も最初は知らずに作っていて、あとからゾッとしました。

ひとつ目は、棒グラフはゼロから始めること。Y軸を途中（たとえば800）から始めると、840と980の棒が「倍くらい違う」ように見えます。実際は2割の差なのに。これでチャネルへの投資判断を間違えたら、目盛りひとつのせいでお金を溶かすことになります。折れ線は変化を見るものなのでゼロ始まりが常に必要なわけではありませんが、棒グラフは原則ゼロ始まり。Claude Codeには「棒グラフのY軸は必ず0始まり、軸を途中で切らない」と明記します。

ふたつ目は、色だけで意味を持たせないこと。「青がorganic、緑がemail」とだけ決めて凡例も表もないと、色が見分けにくい人には何も伝わりません。これはデザインの好みじゃなくて、WCAG 2.2の非テキストコントラストでも求められている話です。対策はシンプルで、色は補助にして、ラベル・凡例・表を必ず添える。僕はグラフの下に必ず素の表を置きます。スクリーンリーダーでも数字が読めるし、丸め誤差のレビューも表のほうが速いからです。

ついでに言うと、空欄をそのまま渡してNaNが混ざる事故も「だます」側です。グラフが空っぽなのにエラーも出ないと、レビューで見落とされて、間違ったまま公開されます。だからこそ前章のデータ準備で、グラフに渡す前に弾く。全部つながっています。

Claude Codeには「完成形」ではなく「制約」を渡す

ここまでの考え方を、そのままClaude Codeへの依頼文に落とすとこうなります。僕がいつも使っているプロンプトです。完成形のUIを描写するのではなく、データ契約と禁止事項を先に渡すのがコツです。

ClaudeCodeLab向けに、コンテンツ分析ダッシュボードを React + TypeScript で作ってください。

【データ契約】画面に渡すデータは必ずこの形に従う:
date(ISO文字列), channel(organic/email/social/referral/paid), sessions(数値), revenue(USD数値), readRate(0〜1)

【必ず含める】サンプルデータ, CSVパース, チャネル別集計,
読み込み中・エラー・空データの表示, グラフ下の表(フォールバック), aria-label

【禁止】棒グラフのY軸を途中から始める, 二軸グラフ, 色だけで意味を伝える

【最後に】「どこを確認すべきか」をレビュー観点として箇条書きで返す

この依頼文の狙いは、Claude Codeに「きれいなデモ」ではなく「公開前に壊れにくい実装」を作らせることです。とくにデータ契約・空データ・誤解防止ルールを先に書くと、あとからの手戻りが激減します。逆にこれを渡さないと、成功時だけ動く、本番で崩れる画面が返ってきます。

実装そのものの作り方はClaude Codeでダッシュボード開発、計測イベントの設計はClaude Code Analytics Implementation、読みやすさの担保はアクセシビリティ実装が詳しいので、手を動かすときはそちらと合わせてください。公式の基準はClaude Code docsを起点にしておくと迷いません。

よくある質問

Q. RechartsとD3、どっちを使えばいい? まずRecharts。Reactのコンポーネントとして素直に書けて、空データやレスポンシブも扱いやすいです。D3は尺度計算や特殊な注釈など、Rechartsで届かない一部だけ補助に使う。最初から全部D3でやると実装量が爆発します。使い分けの詳しい話はグラフライブラリ選びの記事に書きました。

Q. データ契約って、わざわざ書く意味ある? あります。むしろこれが可視化のいちばんの近道です。型・単位・空欄の扱いを先に決めておくと、Claude Codeがrevenueを文字列扱いしたり日付を誤って並べたりする事故が、グラフを描く前に消えます。1分で書ける表が、何時間ものデバッグを防ぎます。

Q. 円グラフは使っちゃダメ? ダメではないですが、カテゴリが5個までなら、です。それを超えると色での見分けがつかなくなるので棒グラフに切り替えます。全体に占める割合をどうしても見せたいときだけ、少数カテゴリで使うのが安全です。

Q. 棒グラフをゼロ始まりにすると差が小さく見えて困る それが正しい姿です。差が小さいなら、本当に小さいんです。軸を切って差を大きく見せた瞬間、それは事実を盛ったグラフになります。差を強調したいなら、軸ではなく数値ラベルや注釈で「+18%」のように添えてください。

Q. グラフが正しいかは、どう確認する? 見た目だけでは確認しきれません。数値の正しさはユニットテスト、表示崩れはモバイルとデスクトップのスクリーンショット比較、キーボード操作とコントラストはアクセシビリティチェック、と分担します。とくにグラフの下に置いた表と数字が一致しているかは、目で追える最初のチェックです。

実際に試した結果

冒頭の「いい感じにグラフにして」で出てきた使えない折れ線。あれ以来、僕はグラフを頼む前に必ず決める文を1行書くようになりました。「僕が、記事別の読了率を見て、導入文を直すか決める」。たったこれだけで、出てくるグラフがいきなり的を射るようになりました。

そして効いたのは、やっぱりデータ準備でした。CSVをそのまま渡すのをやめて、型を固定し、空欄を0にし、壊れた日付の行を捨てる——この掃除を先にやるだけで、NaNでツールチップが壊れる事故も、金額が文字列連結される事故も消えました。Claude Codeは描画が速いぶん、汚いデータを渡すと汚いまま速く崩れます。きれいなグラフを探す前に、きれいなデータを用意する。遠回りに見えて、これがいちばん速い見せ方でした。

可視化をもう一段ちゃんとやりたくなったら、データ準備から検証までを一気通貫で扱った教材を教材一覧にまとめてあります。手を動かしながら自分のサイトのデータで試すのが、いちばん身につきます。