Claude Codeでグラフライブラリを選ぶ実務ガイド

最初に決めるべきこと

Claude Codeでグラフライブラリを選ぶときに大事なのは、Claude Codeに「見た目を整えて」と丸投げしないことです。初心者ほど、動いた瞬間に完成だと思いがちですが、実務では空データ、スマホ幅、アクセシビリティ、既存CSSとの衝突、広告やコードブロックの表示まで確認して初めて公開できます。この記事では、グラフ表示を小さく安全に導入し、あとから壊れにくい形へ育てる手順をまとめます。

関連する基礎は Claude Codeでダッシュボード開発、Claude Codeでデータ可視化、Claude Codeのアクセシビリティ対応 も合わせて確認してください。公式情報は Claude Code docs, Recharts, Chart.js, D3, WCAG 2.2 を参照します。Claude Codeへの指示では「対象ファイル」「禁止事項」「確認観点」を先に渡すと、生成される差分の品質が安定します。

Claude Codeへの安全な依頼文

この画面にグラフ表示を実装してください。
既存のコンポーネント構造を壊さず、変更ファイルを最小化してください。
ユースケース、落とし穴、アクセシビリティ、スマホ表示、失敗時の表示を確認してください。
コード例はコピペで動く形にし、最後にレビュー観点を箇条書きで返してください。

このプロンプトの狙いは、Claude Codeに「完成形のUI」ではなく「壊れにくい変更プロセス」を作らせることです。特に既存サイトでは、派手な改善よりも、離脱を増やさず、問い合わせや購入導線を邪魔しないことが重要です。

ユースケースのチェックリスト

1. ランディングページのファーストビュー改善。CTAの近くで視線を誘導するが、本文や価格表の可読性は落とさない。
2. SaaS管理画面の状態変化。保存完了、エラー、読み込み中、空データを分かりやすくする。
3. 記事サイトや商品ページの回遊改善。関連記事、料金表、相談導線を自然に見つけてもらう。
4. チーム開発のレビュー短縮。Claude Codeに差分と確認観点を同時に出させ、レビュー担当が見る場所を減らす。

実装例

npm i recharts chart.js react-chartjs-2 d3
npm i -D @types/d3

"use client";

import {
  CartesianGrid,
  Line,
  LineChart,
  ResponsiveContainer,
  Tooltip,
  XAxis,
  YAxis,
} from "recharts";

type Point = {
  date: string;
  revenue: number | null;
  orders: number;
};

const money = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
  maximumFractionDigits: 0,
});

function normalize(points: Point[]) {
  return points
    .filter((point) => Number.isFinite(Date.parse(point.date)))
    .sort((a, b) => Date.parse(a.date) - Date.parse(b.date))
    .map((point) => ({
      ...point,
      label: new Intl.DateTimeFormat("en-US", { month: "short", day: "numeric" }).format(
        new Date(point.date),
      ),
      revenue: point.revenue ?? 0,
      orders: Number.isFinite(point.orders) ? point.orders : 0,
    }));
}

export function RevenueChart({ data }: { data: Point[] }) {
  const rows = normalize(data);

  if (rows.length === 0) {
    return <p role="status">No chart data yet. Check the date range or filters.</p>;
  }

  return (
    <figure aria-labelledby="revenue-chart-title">
      <h2 id="revenue-chart-title">Revenue trend</h2>
      <ResponsiveContainer width="100%" height={320}>
        <LineChart data={rows} margin={{ top: 16, right: 24, bottom: 8, left: 8 }}>
          <CartesianGrid strokeDasharray="3 3" />
          <XAxis dataKey="label" />
          <YAxis tickFormatter={(value) => money.format(Number(value))} />
          <Tooltip formatter={(value) => money.format(Number(value))} />
          <Line type="monotone" dataKey="revenue" stroke="#2563eb" strokeWidth={3} dot={false} />
        </LineChart>
      </ResponsiveContainer>
      <figcaption>Data is sorted by date and null revenue is rendered as zero.</figcaption>
    </figure>
  );
}

ライブラリの選び方：Recharts・Chart.js・D3

グラフライブラリは「人気だから」で選ぶと後悔します。実務では、表示したいグラフの種類、チームの習熟度、デザインの自由度、バンドルサイズのどれを優先するかで決めます。Claude Codeに選定を任せるときも、この3つを候補として渡し、「なぜそれを選んだか」を説明させると、あとで判断の根拠が残ります。

ライブラリ	向いている場面	注意点
Recharts	ReactでKPIカードや売上推移など定番グラフを早く出す	複雑な独自表現や数千点の描画は苦手
Chart.js	React以外のページでも使い、Canvasで軽快に描く	DOM要素ではないので、アクセシビリティは別途補う
D3	独自のデータ可視化を細かく作り込む	学習コストが高く、実装量とレビュー量が増える

最初の判断はシンプルです。Reactのダッシュボードで折れ線、棒、円といった定番グラフを出すだけなら、Rechartsで十分です。React以外のページや、点が数千以上ある重いグラフは、Chart.jsのCanvas描画のほうが安定します。動きのある独自表現や、レポートのような凝った図が必要なときだけD3を検討します。迷ったら、まずRechartsで動くものを作り、表現が足りなくなってから乗り換えるほうが、手戻りが少なくて済みます。

Masaが小さなダッシュボードで試したときも、最初からD3に手を出して実装が膨らみ、レビューが追いつかなくなりました。定番グラフはRecharts、特殊な1枚だけD3、と役割を分けたほうが、全体の保守はずっと楽になります。Claude Codeには「このグラフはRechartsで、ここだけD3で」と範囲を指定して頼むと、無駄に高機能なライブラリを足されずに済みます。

空データ・読み込み中・エラーを必ず用意する

グラフで一番事故が多いのは、データがまだ無いときの表示です。APIが空配列を返した、集計が0件だった、取得に失敗した、という状態を考えずに作ると、軸だけのグラフや、真っ白な領域、最悪はクラッシュした画面を読者に見せてしまいます。上の実装例でrows.length === 0のときにメッセージを返しているのは、この事故を防ぐためです。

実務では、最低でも次の4状態を用意します。読み込み中は、グラフと同じ高さのプレースホルダーを置き、レイアウトが飛ばないようにします。空データは「まだデータがありません」と理由や次の操作を示します。エラーは原因と再試行ボタンを出します。そして正常時だけ、グラフ本体を描きます。

状態	表示	よくある失敗
読み込み中	同じ高さのスケルトン	スピナーだけで高さが変わり、画面が跳ねる
空データ	理由と次の操作	軸だけのグラフを見せる
エラー	原因と再試行	例外でページごと落ちる
正常	グラフ本体	0件と正常を区別しない

Claude Codeに依頼するときは、「正常系だけでなく、空・読み込み中・エラーの表示も出して」と最初に伝えます。これを言わないと、AIは成功パスだけを実装しがちで、本番のデータで必ず詰まります。グラフは見た目が派手な分、壊れたときの印象も強く残るので、状態の作り込みは投資に見合います。

落とし穴チェックリスト

• 目的が曖昧なまま実装すると、見た目は良くてもCVRが下がります。CTA、フォーム、価格表の邪魔をしていないか確認します。
• スマホ幅で横スクロールが出ると、検索流入の読者がすぐ離脱します。375px幅で必ず確認します。
• 色や動きだけで意味を伝えるとアクセシビリティが落ちます。テキスト、状態ラベル、フォーカス表示を残します。
• ライブラリを増やしすぎると、初回表示が重くなります。まずCSSと小さなJSで足りるかを判断します。
• Claude Codeの提案をそのまま採用せず、既存の設計トークン、命名規則、テスト方法に合わせます。

レビュー手順

実装後は、Claude Codeにもう一度レビューだけを依頼します。「変更したファイル」「削った方がよい処理」「失敗ケース」「手動確認」を分けて出させると、見落としが減ります。加えて、Playwrightやブラウザのスマホ表示で横幅、コードブロック、CTA、広告枠を確認します。

マネタイズにつなげる見方

グラフ表示は装飾ではありません。問い合わせ、資料請求、購入、研修申込へ向かう読者の迷いを減らすための改善です。自社サイトでClaude Codeの導入やレビュー体制を整えたい場合は、Claude Code研修・相談 で、既存画面を題材にした改善手順を相談できます。

追加のレビュー観点

• 変更前後のスクリーンショットを並べ、CTA、広告、本文、コードブロックが読みやすいか確認します。
• Claude Codeの提案をそのまま採用せず、削れる処理、命名の違和感、既存CSSとの競合を質問します。
• 本番反映前に、スマホ、デスクトップ、キーボード操作、低速回線、空データを一通り見ます。

この記事で紹介した内容を実際に試した結果

この手順は、既存のブログUIを壊さない前提で、スマホ幅375px、通常表示、低速回線、キーボード操作を見ながら確認しました。Claude Codeには一度に全部を任せず、実装、レビュー、修正の3段階に分ける方が、差分が読みやすく品質も安定しました。