Recharts・Chart.js・D3の使い分け、迷ったらこの順で選ぶ

「グラフ出して」とだけ頼んだら、Claude CodeはためらいなくD3を引っ張ってきました。

たしかに動く。動くんだけど、たった1本の折れ線を出すために、scaleやaxisの設定が60行。後日「色を変えて」と頼んだら、また別の60行を読み解くハメになりました。Rechartsなら10行で済んだやつです。

グラフライブラリ選びの失敗は、だいたいこれです。作れるかどうかじゃなくて、半年後の自分が直せるかで間違える。今日は、Recharts・Chart.js・D3の3つを、どういう順番で考えれば手戻りしないかという話をします。

この記事の要点

• 迷ったらRecharts → Chart.js → D3の順で検討する。先に重いものを選ぶと保守で泣く。
• Reactで折れ線・棒・円といった定番グラフなら、ほぼRechartsで終わる。乗り換えは「足りなくなってから」で遅くない。
• React以外のページや、点が数千を超える重いグラフはChart.jsのCanvas描画が安定する。
• D3は「ライブラリ」ではなく「部品箱」。独自の凝った図が1枚だけ要るとき限定で使う。
• Claude Codeには「Rechartsで、ここだけD3」と範囲を指定する。任せると無駄に高機能なものを足してくる。

考え方とデータ準備はClaude Codeのデータ可視化、グラフより先に決める3つのことに、D3そのものの手の動かし方はD3.jsの棒グラフ、scale・axis・joinでつまずく人へに分けてあります。ここは純粋にライブラリの比較と選定だけに絞ります。一次情報はRecharts公式、Chart.js公式、D3公式を起点に確認してください。

3つは「同じ土俵」にいない

まず勘違いしやすいのが、Recharts・Chart.js・D3を横一列で比べてしまうことです。この3つ、抽象度が違います。

• Recharts … Reactの「部品」。<LineChart> と書けば折れ線が出る。完成品が並んでいる。
• Chart.js … 設定オブジェクトを渡すと描いてくれる「設定型」。Reactでなくても動く。
• D3 … グラフ部品ではなく、数値を座標に変換する「部品箱」。完成品は自分で組む。

料理にたとえると、Rechartsは冷凍食品、Chart.jsはレシピ付きミールキット、D3は素材と包丁。早く・安全に食べたいなら冷凍食品で十分で、わざわざ包丁から始める理由は「この一皿だけは自分で作り込みたい」というときだけです。

この温度差を分からずに「人気だから」でD3を選ぶと、冒頭の僕みたいに、折れ線1本のために包丁を研ぐことになります。逆に、本当に独自の図が要る場面でRechartsに固執すると、今度は出せない表現を無理やりこじ開けようとして、かえって複雑なコードになります。大事なのは優劣ではなく、作りたいものの抽象度に、ライブラリの抽象度を合わせることです。ここがずれた瞬間に、コード量もレビュー時間も跳ね上がります。

比較表：どれが何に向くか

役割が違うものを、それでも実務目線で並べるとこうなります。

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

描画方式の違いは、地味だけど効いてきます。SVGは要素が1個ずつDOMに乗るので、検証ツールで覗けるし、CSSも当てやすい。そのかわり点が増えると重くなります。Canvasは1枚の絵に塗るので大量の点でも軽いけれど、後からスクリーンリーダーに読ませる工夫を足す必要があります。「読者の環境」と「点の数」、この2つで描画方式の向き不向きが決まります。

判断フロー：上から順に当てはめる

選定はフローチャートにすると一瞬です。上から順に「はい」を拾っていくだけ。

Reactのプロジェクト？
├─ いいえ → Chart.js（素のJS/Vue/Svelteでも動く）
└─ はい
   └─ 出したいのは折れ線・棒・円などの定番？
      ├─ はい → 点は数千以下？
      │        ├─ はい → Recharts ← まずここで足りる
      │        └─ いいえ（重い）→ Chart.js
      └─ いいえ（独自の凝った図が要る）→ その1枚だけ D3

ポイントは、最初の分岐でほとんどがRechartsに着地することです。世の中のダッシュボードの大半は「Reactで・定番グラフを・数百点」なので、それならRecharts一択で迷う必要がありません。

逆に言うと、いきなりD3を検討すべきなのは右下の細い枝、「Reactだけど、定番では表現できない独自の図が、特定の1枚だけ必要」という限られた場合だけ。ここを最初から太い道だと思い込むのが、最大の遠回りです。

まずRechartsで動かす：コピペで動く例

「迷ったらRecharts」が口だけにならないよう、コピペで動く折れ線を置いておきます。売上推移を出すコンポーネントで、空データ・null・日付の並べ替えまで最初から面倒を見ています。ここが実務で一番事故るところなので、サンプルに含めておくのが大事です。

npm i recharts

"use client";

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

type Point = {
  date: string;            // ISO形式の文字列
  revenue: number | null;  // 欠損があり得るのでnull許容
  orders: number;
};

// 金額は通貨フォーマットで揃える（桁区切り・記号つき）
const money = new Intl.NumberFormat("ja-JP", {
  style: "currency",
  currency: "JPY",
  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("ja-JP", { month: "short", day: "numeric" }).format(
        new Date(point.date),
      ),
      // nullの売上は0として描く（線が途切れて見えるのを防ぐ）
      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">表示できるデータがありません。期間や絞り込みを見直してください。</p>;
  }

  return (
    <figure aria-labelledby="revenue-chart-title">
      <h2 id="revenue-chart-title">売上の推移</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>日付順に並べ替え、売上が空の日は0として描画しています。</figcaption>
    </figure>
  );
}

このコードのうち、グラフ描画そのものは <LineChart> まわりの十数行だけ。残りは全部「渡すデータをきれいにする」処理です。Rechartsを選ぶと、この描画が薄くて済むのが効きます。D3だと、この十数行のかわりにscale・axis・joinの設定が積み上がります。

なお、ここで <LineChart> を <BarChart> に、<Line> を <Bar> に差し替えれば、ほぼそのまま棒グラフになります。定番グラフの間の乗り換えがこれだけ軽いのも、Rechartsの強みです。

Claude Codeに頼むときの渡し方

ライブラリ選定をClaude Codeに丸投げすると、たいてい一番高機能なものを引いてきます。先回りして、候補と範囲を指定するのがコツです。

このReact画面に売上推移の折れ線グラフを実装してください。

【ライブラリ】Rechartsを使う。D3やChart.jsは追加しない。
【データ】date(ISO文字列), revenue(数値・null可), orders(数値)
【必ず含める】空データ・読み込み中・エラーの表示, 日付の昇順ソート, aria-label
【禁止】既存のコンポーネント構造を壊す, 変更ファイルを増やしすぎる
【最後に】なぜRechartsで十分かを1行、乗り換えが要るとしたらどんな条件かを1行で返す

最後の「なぜRechartsで十分か／乗り換え条件」を書かせるのがミソです。これがあると、判断の根拠がコードと一緒に残ります。後で「やっぱりD3に変えるべき?」と迷ったとき、過去の自分の判断を読み返せる。Claude Codeは聞けば理由を言語化してくれるので、使わない手はありません。

逆に、この制約を渡さずに「いい感じにグラフを」とだけ頼むと、依存パッケージが3つ増えて初回表示が重くなった、なんてことが普通に起きます。実際に僕は一度それで、recharts chart.js d3 が全部入った差分が返ってきて、レビューで突き返しました。

バンドルサイズという現実

選定でもう1つ見落としがちなのが、初回表示の重さです。グラフライブラリは小さくありません。素のCSSとちょっとのJSで足りる程度の図に、わざわざ大きな依存を足すと、ページが重くなって検索流入の読者が離脱します。

判断はシンプルで、こう考えます。

• 数値を1つ大きく見せたいだけ → ライブラリ不要。ただの数字とCSSで足りる。
• 簡単な棒や折れ線が数本 → Recharts1つで十分。複数ライブラリを混ぜない。
• 重い・特殊な1枚だけ凝りたい → その画面だけ動的import（遅延読み込み）で切り出す。

特に「グラフは特定ページにしか無いのに、全ページのバンドルに混ざっている」状態は要注意です。Reactなら next/dynamic や React.lazy でグラフ部分だけ遅延読み込みにして、トップページなど関係ない画面の表示速度を守ります。これもClaude Codeに「このグラフは動的importで分離して」と頼めば、数分で差分が返ってきます。

チームのレビューコストで考える

ライブラリ選びは、自分一人の話で終わりません。チームで開発しているなら、そのコードを他人がレビューできるかが、バンドルサイズより効いてくることがあります。

Rechartsの <LineChart> は、Reactを書く人なら初見でも意味が読めます。propsを見れば何のグラフか分かるからです。一方、D3で組んだ60行は、書いた本人以外には「これは何のグラフで、どこを直せば色が変わるのか」が即座には分かりません。レビュー担当が毎回scaleの定義から追う羽目になり、PRが滞ります。

僕の感覚だと、習熟度と保守のしやすさはこう並びます。

観点	Recharts	Chart.js	D3
初見での読みやすさ	高い（propsで完結）	中（設定オブジェクトを追う）	低い（scale/axisを読む）
Reactチームの学習コスト	ほぼゼロ	小	大
仕様変更への強さ	強い（差し替えが軽い）	中	弱い（連鎖して直す）

だから、エンジニアが入れ替わるチームや、レビューを速く回したい現場ほど、定番グラフはRechartsに寄せる価値があります。D3の表現力が要る1枚だけ、その部分の責務をコメントで明記して切り出す。こうしておけば、レビュー担当は「ここはD3の特殊ゾーン」と割り切って読めます。Claude Codeにレビューだけを頼むときも、「変更ファイル」「削れる処理」「失敗ケース」「手動確認」を分けて出させると、見落としが減ります。実装・レビュー・修正を一度に混ぜず、3段階に分けるのが結局いちばん速い、というのが何度もやって出た結論です。

ありがちな選定ミス5つ

僕や周りが実際にやらかした、選定の落とし穴を並べます。

• 人気だからD3 … スター数で選ぶと、折れ線1本に60行。定番グラフは抽象度の高いRecharts。
• 全部入り … Recharts・Chart.js・D3を「念のため」全部入れる。バンドルが膨らみ、書き方も統一されない。
• React前提を忘れる … Rechartsの例をVueやSvelteのページにコピペしてReactごと持ち込み事故。React外はChart.js。
• 空データ未対応 … 正常系だけ実装して、本番の0件で軸だけのグラフやクラッシュを見せる。状態は最初に作る。
• Canvasのアクセシビリティ放置 … Chart.jsはDOM要素を作らないので、別途テーブルやaria-labelで数字を読ませる必要がある。

どれも「選ぶときに一言足しておけば防げた」ものばかりです。ライブラリ選びは、書き始める前の30秒で勝負がつきます。

よくある質問

Q. 結局、最初に選ぶならどれ? Reactなら迷わずRechartsです。折れ線・棒・円という定番グラフはこれで足ります。表現が足りなくなってから乗り換えても遅くないので、最初から重い選択肢を取らないでください。

Q. RechartsとD3、どう使い分ける? 役割が違います。Rechartsは完成品の部品、D3は部品箱。基本はRechartsで組み、「定番では作れない独自の図が、この1枚だけ必要」というときだけ、その画面に限ってD3を足します。両方を1画面に混ぜても問題ありません。D3側の実装はD3.jsの棒グラフの記事にまとめました。

Q. ReactじゃないサイトはChart.jsでいい? はい。Chart.jsは素のJSでもVue/Svelteでも動き、Canvasなので点が多くても軽快です。ただしCanvasはDOM要素を作らないため、グラフの下に素のテーブルを置くなど、数字を別経路で読ませる対応をセットにしてください。

Q. グラフのために重いライブラリを入れたくない まず「ライブラリなしで足りるか」を疑ってください。数値1つを大きく見せるだけなら、CSSと数字で十分です。必要な場合も、グラフのある画面だけ動的import（遅延読み込み）で切り出せば、他ページの表示速度は守れます。

Q. Claude Codeにライブラリ選定を任せていい? 任せると一番高機能なものを引きがちです。候補と範囲（「Rechartsで、D3は追加しない」など）を先に指定し、選んだ理由を1行で説明させてください。根拠が残るぶん、後の判断がぶれません。

実際に試した結果

冒頭の「折れ線1本にD3で60行」以来、僕はライブラリを頼む前に、必ず例の判断フローを上から当てはめるようになりました。「Reactか? 定番か? 点は少ないか?」——この3問でほぼRechartsに着地します。実際、小さなダッシュボードを組み直したときも、定番グラフは全部Rechartsに寄せ、どうしても凝りたかった1枚だけD3に分けたら、コードの見通しが段違いに良くなりました。

効いたのは「最初に重いものを選ばない」という一点でした。Rechartsで動くものを先に出し、足りなくなってから乗り換える。乗り換えが発生しないことのほうが、実際は多いです。賢いライブラリを探すより、半年後の自分が読めるコードを選ぶ。それがいちばん速い、というのが今の実感です。

選定からデータ準備、検証までを一気通貫で手を動かしたい人向けに、自分のサイトのデータで試せる教材を教材一覧にまとめてあります。既存画面を題材に相談したい場合は研修・相談もどうぞ。