コーポレートサイトに「事業別売上の構成比」や「アンケート結果の割合」を円グラフで一枚だけ載せたい——受託でよく出る要望です。ところがこの「一枚だけ」のために、Chart.js や ApexCharts のようなグラフライブラリを丸ごと読み込んでいるサイトを、引き継ぎのたびに見かけます。数十KB〜100KB を超える JavaScript を、たった一つの静的な円グラフのために初回ロードで運んでいる。スマホでの表示も一拍遅れ、Lighthouse のスコアもそこで削られます。
円グラフが「データに応じて動的に変わる・ツールチップで詳細を出す」必要があるなら、ライブラリは正解です。しかし、値が決まっていて動かない構成比を見せたいだけなら、CSS の conic-gradient() だけで描けます。本記事では、受託で「軽くて壊れにくい可視化」を作る道具として CSS 円グラフをどう使うか、そしてどこまでなら CSS で済ませ、どこからライブラリに渡すべきかを、制作の立場から整理します。
なぜ「グラフライブラリ一択」が負債になるのか
グラフを出すと決めた瞬間にライブラリを入れる、という反射は、後で三つの形で効いてきます。
ひとつは、バンドルサイズです。汎用グラフライブラリは折れ線・棒・散布図まで含む多機能なぶん重く、円グラフ一枚のために全機能を運ぶことになります。コード分割で遅延読み込みにしても、結局その円グラフが見えるまで描画は走りません。
ふたつめは、バージョン追従の保守です。ライブラリを入れた瞬間、それは将来のアップデート対象になります。メジャーバージョンが上がるたびに API が変わり、「グラフ一枚のために毎年追従コストが発生する」状態になる。受託で納品したあと、この一枚のグラフが保守見積もりに乗り続けます。
みっつめは、描画タイミングのちらつきです。JavaScript でキャンバスに描く以上、HTML が表示されてから一拍遅れてグラフが現れます。静的な構成比なら、本来は最初から表示されているべきものです。
conic-gradient() で描けば、追加の JavaScript はゼロ、バンドルは増えず、HTML が表示された瞬間にグラフも出ます。CSS の新機能を「振る舞いを宣言に寄せて軽くする」道具として使う発想は、CSS offset-path でJSなしの動きを作る記事で扱った方針の延長線上にあります。
conic-gradient で円グラフを描く基本
conic-gradient() は、中心から角度方向に色が切り替わるグラデーションです。色の境界を「ぼかさず」角度をぴったり指定すると、グラデーションではなく塗り分けられた扇形、つまり円グラフになります。
たとえば「40% / 35% / 25% の三分割」なら、こう書きます。
.pie {
width: 200px;
aspect-ratio: 1; /* 正円を保つ */
border-radius: 50%; /* 角を落として円にする */
background: conic-gradient(
#176B87 0 40%, /* 0%から40%まで */
#64CCC5 40% 75%, /* 40%から75%まで（=35%ぶん） */
#DAFFFB 75% 100% /* 残り25% */
);
}ポイントは、各区切りの「開始%」と「終了%」を隣り合わせに書くことです。前の色の終わりと次の色の始まりを同じ値にすると、境界がくっきり分かれます。割合を変えたいときは、この数値を差し替えるだけ。画像の作り直しも、JavaScript の再計算もありません。
中央をくり抜いてドーナツグラフにするなら、円の上に背景色の小さな円を重ねるか、mask で中心を抜きます。mask を使うと、背景が透過でも中抜きが効きます。
.donut {
/* .pie と同じ conic-gradient を指定したうえで */
mask: radial-gradient(circle, transparent 55%, #000 56%);
}どこまでCSSで済ませ、どこからライブラリに渡すか
判断の軸はシンプルで、「そのグラフは動くのか、止まっているのか」です。受託の現場で出てくるグラフを、この軸で振り分けると次のようになります。
| グラフの性質 | 推奨手段 | 理由 |
|---|---|---|
| 値が固定の構成比（売上比・回答割合） | CSS conic-gradient | 動かないものに JS は不要 |
| ホバーで内訳を出す程度 | CSS + 最小限の JS | 描画は CSS、装飾だけ JS |
| 値が動的・複数系列・ズーム/凡例連動 | グラフライブラリ | CSS では破綻する |
つまり、「止まっているグラフ」は CSS、「触ると変わるグラフ」はライブラリ、という線引きです。受託で多いのは前者——会社案内や実績紹介に載る静的な構成比です。ここをライブラリで作っていると、前述の三つの負債を全部抱えることになります。
アクセシビリティの観点では、CSS で描いたグラフは見た目だけで、スクリーンリーダーには「ただの装飾要素」に見える点に注意が必要です。グラフの隣に、同じ数値を表やテキストで添えておく。値そのものは HTML 側に持たせ、CSS は見せ方だけを担う——この分担が、可視化を支援技術にも伝わる形にします。考え方はWebアクセシビリティ実務ガイドで扱った「視覚情報を必ずテキストでも提供する」原則と同じです。
受託で置き換えたときに効いたこと
弊社が運用を引き継いだある業界団体のサイト（団体名は伏せます）では、トップに会員構成比のドーナツグラフが一枚あり、そのためだけに 90KB ほどのグラフライブラリが全ページで読み込まれていました。グラフは年に一度、総会後に数値を更新するだけの、完全に静的なものでした。
私たちはこのグラフを conic-gradient + mask の十数行に置き換え、ライブラリの読み込みを削除しました。数値はグラフ脇の表に持たせ、CSS の % はその表の値と一致させる運用にしました。結果、トップページの JavaScript 転送量がそのぶん丸ごと減り、初回表示で一拍遅れてグラフが出る挙動もなくなりました。年次更新の作業も、CSS の % と表の数字を二箇所直すだけになり、ライブラリのバージョン追従という宿題が消えました。
この案件で一番効いたのは、「動かないものに動的な道具を使わない」と最初に決めたことでした。可視化と聞くとライブラリに手が伸びますが、まず「このグラフは将来動くのか」を問えば、半分以上は CSS で足ります。
どこから着手するか
いま動いているサイトで「静的な構成比なのにグラフライブラリを読んでいる」箇所があれば、そこが最初の置き換え候補です。値が固定で、ホバーやズームの操作が要らないなら、conic-gradient の数行で同じ見た目を、JavaScript ゼロで作れます。数値は HTML の表に持たせ、CSS とアクセシビリティの両方をそこで担保すれば、本番に出せる品質になります。
グラフ一枚のために重いライブラリを運んでいて表示が重い、可視化の保守がバージョン追従で毎年発生している、軽さとアクセシビリティを両立させたい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行サイトの可視化を拝見し、CSS で軽くできる部分とライブラリが必要な部分を切り分けたうえで、軽く保守しやすい形に作り直します。
