レポートやブログのグラフをスクリプトや AI で自動生成している方向けに、SVG グラフがスマホで読めなくなる仕組みと、公開済みの図をまとめて描き直す手順を紹介します。筆者がこのサイトの運用で、公開済みのグラフ 97 枚のうち 94 枚を描き直した記録をもとにしています。読み終わると、図の幅と文字の大きさを数字の基準で決め、配った図を漏れなく直す段取りを組めるようになります。
この記事で分かること
- SVG グラフの文字がスマホで何 px になるかを、viewBox の幅と font-size から計算する方法
- 公開済みの図を、記事の本文を書き換えずに一括で描き直す手順
- 描き直しの時に、何を保存しておかないと後で困るのか（つまずいた点）
何が起きていたか：幅 960 の図はスマホで文字が約 3.7px
このサイトのグラフは、SVG（線や文字を座標で記録する画像の形式。拡大しても荒れない）で自動生成しています。描き直す前の図は、横幅 960 の座標で作り、文字の大きさを 12〜15 にしていました。描画スクリプトが同じ設計の幅と文字で、すべてのグラフを描いていました。
ところが、スマホでは文字がほとんど読めませんでした。原因は viewBox（SVG の中の座標の範囲を、左上の位置と幅・高さの 4 つの数値で決める属性）にあります。MDN の説明では、viewBox があると、SVG は入れ物の大きさに合わせて引き伸ばされたり縮められたりします。図が レスポンシブ（画面の幅に合わせて表示の大きさが変わること）に表示されるのは、この仕組みのおかげです。
つまり、図の中の文字も、図全体と同じ割合で縮みます。このサイトの記事ルールでは、幅 360px のスマホの画面で本文の幅を 292px と見積もっています。幅 960 の図は 292px まで縮むため、文字は約 0.30 倍になります。
縮小率 = 本文の幅 292 ÷ viewBox の幅
画面上の文字 = 縮小率 × font-size
幅 960・font-size 12 の場合
292 ÷ 960 = 0.304
0.304 × 12 = 3.65px（約 3.7px）筆者がこの式で計算すると、描き直す前の図の文字は画面上で約 3.7〜4.6px でした。図の中の文字は、座標の上では 12〜15 でも、スマホの画面ではその 3 割ほどの大きさまで縮んでいたことになります。
点検した時点では、公開中の記事 81 本のうち 48 本で、図の文字が画面上 12px 未満になっていました。数えた件数は 213 件です。
基準を数字で決める：viewBox の幅と font-size の組み合わせ表
直す前に、「どの大きさなら読めるとするか」を数字で決めました。このサイトでは、画面上 12px 以上を基準にしています。12px は筆者の運用の基準で、公的な決まりから取った数字ではありません。
アクセシビリティ（障害の有無や環境にかかわらず使えること）の国際的な指針である WCAG 2.2 も確かめました。WCAG 2.2 の達成基準 1.4.4 は、文字を支援技術なしで 200% まで拡大しても内容が失われないことを求めています。達成基準 1.4.10 は、縦にスクロールする内容を、幅 320 CSS ピクセル相当の画面で、横スクロールなしに読めることを求めています（2 次元の配置が要る部分は除きます）。
ただし、筆者が確かめた範囲では、図の中の文字の最小 px を直接定める基準はありませんでした。
そこで、viewBox の幅 4 通りと font-size 3 通りの 12 通りで、画面上の文字の大きさを計算しました。図 1 と表 1 が結果です。
表 1：本文の幅 292px での画面上の文字（px）。筆者が 292 ÷ 幅 × font-size で計算
| viewBox の幅 | 縮小率 | font 12 | font 15 | font 20 | 12px に要る font |
|---|---|---|---|---|---|
| 480 | 0.61 | 7.30 | 9.13 | 12.17 | 19.7 |
| 640 | 0.46 | 5.48 | 6.84 | 9.13 | 26.3 |
| 800 | 0.37 | 4.38 | 5.48 | 7.30 | 32.9 |
| 960 | 0.30 | 3.65 | 4.56 | 6.08 | 39.5 |
図 1 のとおり、12 通りのうち 12px を超えるのは、幅 480・font-size 20 の 1 通りだけでした。幅 960 のまま 12px にするには、font-size を 39.5 以上にする必要があります。文字を 3 倍以上にすると、ラベルが図に収まらなくなると考えられます。
表 1 の右端の列は、12 ÷ 縮小率で求めました。式を変形すると、幅 × 12 ÷ 292、つまり幅のおよそ 24 分の 1 になります。本文の幅が 292px の画面なら、図の font-size を viewBox の幅 ÷ 24 以上にしておくと、画面上の文字が 12px 前後になります。このサイトの検査は、この「幅 ÷ 24」をそのまま基準にしています。
描き直しの手順：スクリプトを直す、仕様を集める、一括で描く、検査する
基準が決まったので、公開済みのグラフを描き直しました。手順は図 2 の 5 段階です。
- 描画スクリプトの設計の幅を 960 から 480 に、文字を 12〜26 から 20〜26 に変える
- 図の元になった 仕様ファイル（グラフの種類・値・題名を書いた JSON）を集める
- 古い描画で仕様を描き、公開済みの図と中身を突き合わせる
- 一致した図だけを、新しい描画で同じファイル名に上書きする
- 記事の検査と、ブラウザでの文字の実測で確かめる
手順 1：幅を半分にすると、縦棒が入らなくなる
幅を 480 にすると、縦棒のグラフが成り立たなくなりました。4 系列 × 7 カテゴリの図では、棒 1 本が約 12px になり、カテゴリ名も値も読める大きさで入りません。そこで、縦棒とグループ化した縦棒も、横向きの棒で描くように変えました。
仕様 JSON の書き方は変えていません。仕様の type が vbar のままでも、描画スクリプトが横向きに描きます。書き方を変えなかったため、古い仕様をそのまま新しい描画に渡せました。
文字の幅の見積もりも変えました。前は「全角は 1 文字分、半角は 0.32〜0.66 文字分」という大まかな分類でした。新しい描画では、Chrome で Hiragino Sans の字ごとの幅を実測した表（端数は切り上げ）を使います。幅の狭い図では、見積もりのずれが文字のはみ出しにつながりやすいと考えたためです。
手順 4：本文を書き換えずに済んだ理由
記事の本文は 1 行も変えていません。図のファイル名を変えず、本文の画像の参照に幅や高さを書いた箇所も無かったためです。画像の参照はそのままで、新しい図が表示されました。
図のファイル名を変えずに中身だけを入れ替えれば、記事の本文を書き換えずに図を差し替えられます。ただし、本文の画像に幅と高さを直接書いている場合は、縦横の比が変わって図が歪むと考えられます。差し替える前に、本文の参照に width や height が無いかを検索しておくと安全です。
図を再生成できる状態とは：入力・処理・出力の置き場所
描き直しでつまずいたのは、手順 2 と 3 でした。描画スクリプトはリポジトリ（コードの保管場所）にありましたが、図の仕様ファイルが無かったためです。
データパイプライン（データを入力から出力まで順に加工する流れ）として見ると、図の生成は次の 4 つの部品でできています。図 3 はその置き場所と関係です。
表 2：図の生成の部品と置き場所
| 部品 | 役割 | 描き直し前 | 描き直し後 |
|---|---|---|---|
| 仕様 JSON | 入力 | 手元の下書きだけ | リポジトリに 94 件 |
| 描画スクリプト | 処理 | リポジトリ | リポジトリ |
| SVG | 出力 | 公開フォルダ | 同じ名前で上書き |
| 記事本文 | 参照 | リポジトリ | 変更なし |
出力（SVG）だけを公開し、入力（仕様）を残していなかったことが、再生成を難しくしました。自動生成した図を後から描き直すには、出力の画像と一緒に、入力の仕様ファイルと描画スクリプトをリポジトリに残しておく必要があります。処理は残っていても、入力が無ければ同じ図は作れません。
つまずきやすい点：仕様が手元にしか無いと、対応づけに手間がかかる
ここからは、実際につまずいた点を 2 つ記録します。どちらも、出力だけを残していたことから起きました。
つまずいた点 1：仕様ファイルが手元の下書きにしか無かった
毎日の記事づくりでは、AI が仕様 JSON を一時的な下書きフォルダに書き、描いた SVG だけを記事と一緒に公開していました。そのため、公開済みの図の仕様は、手元の下書きフォルダにしか残っていませんでした。
描き直しでは、手元の下書きフォルダから仕様 104 件を集めました。下書きフォルダを消していたら、97 枚の図を一から作り直す必要があったと考えられます。
再発防止として、描き直しに使った仕様 94 件をリポジトリの次の場所に置きました。公開フォルダに置くと仕様がウェブに出てしまうため、公開しない素材のフォルダを選んでいます。
assets/charts/記事のスラッグ/figure-NN.chart.jsonただし、毎日の記事づくりは今も仕様を一時フォルダに書いています。そのため、新しく公開する記事の仕様はこの場所に増えません。公開する時に仕様も一緒に置く変更は、別の課題として扱っています。
つまずいた点 2：仕様と公開済みの図の対応が確かめられない図があった
仕様を集めても、「どの仕様がどの公開済みの図の元か」はすぐには分かりませんでした。下書きの中で手直しした図や、公開しなかった図が混ざっていると考えたためです。
そこで、古い描画スクリプトで仕様をもう一度描き、公開済みの SVG と中身を比べました。題名とすべての文字列が同じ図は、対応を確かめられたとしました。結果は表 3 のとおりです。
目盛りの数字だけが違う 2 枚は、仕様の値が公開済みの図と同じだったため、対応ありとして描き直しました。目盛りは値から描画スクリプトが計算して振る数字で、仕様には書かれていません。
表 3：公開済みのグラフ 97 枚の突き合わせの結果
| 突き合わせの結果 | 枚数 | 扱い |
|---|---|---|
| 題名と文字列がすべて一致 | 92 | 描き直した |
| 目盛りの数字だけが違う | 2 | 描き直した |
| 値や系列名が違う | 2 | 描き直さず保留 |
| 仕様が見つからない | 1 | 描き直さず保留 |
| 合計 | 97 | 描き直し 94 |
筆者が数え直すと、描き直せたのは 97 枚中 94 枚（96.9%）でした。値や系列名が違う 2 枚は、公開した後に仕様のほうが直されていたため、公開済みの図と中身が合いませんでした。仕様が見つからない 1 枚は、どの記事からも参照されていない余りの図でした。
集めた仕様 104 件のうち、描き直しに使ったのは 94 件で、使わなかった仕様は 10 件でした。10 件の内訳は、記録からは確かめられませんでした。中身を突き合わせて一致を確かめる前に描き直すと、値の違う図で公開済みの数字を上書きしてしまうおそれがあります。
検査の結果：不合格 94 件から 0 件へ
描き直した 94 枚は、記事の検査でスマホ向けの判定（図の font-size が viewBox の幅 ÷ 24 以上か）にかけ、不合格が 94 件から 0 件になりました。さらに Chrome で全部の文字の箱の位置を実測し、はみ出し 0 件・文字どうしの重なり 0 件・最小の font-size 20 を確かめました。ほかの検査も合わせて、テスト 405 件と、サイト全体 314 ページの組み立てが通っています。
表 4 は、描き直しの前と後の比較です。
表 4：描き直しの前と後
| 項目 | 描き直し前 | 描き直し後 |
|---|---|---|
| viewBox の幅 | 960 | 480 |
| font-size | 12〜15 | 20 以上 |
| 画面上の文字 | 3.65〜4.56px | 12.17px 以上 |
| 描き直した図の不合格 | 94 件 | 0 件 |
公開中の記事 81 本全体で見ると、図の文字の不合格は 213 件から 119 件に減りました。内訳は図 4 のとおりです。
表 5：図の文字の検査の不合格（公開中の記事 81 本）
| 図の種類 | 描き直し前 | 描き直し後 |
|---|---|---|
| グラフ | 96 件 | 2 件 |
| 手書きの図 | 117 件 | 117 件 |
| 合計 | 213 件 | 119 件 |
残った 119 件のうち 117 件（98.3%）は、手書きの図です。手書きの図は描画スクリプトで描いた図ではないため、今回の描き直しの対象に入っていません。グラフの残り 2 件は、値が違うため保留した 2 枚と考えられます。
検査の決まりにも 1 つ判断がありました。最初はグラフを警告だけにし、手書きの図だけを不合格にする案がありました。
しかしそれでは、数値のグラフを手書きの図に置き換えて検査を通す道が残ります。そこで、グラフも手書きの図と同じ基準で不合格にしました。
自分のレポートに当てはめる時のチェック表
自動生成のグラフを配っている方が、同じ描き直しをする前に確かめたい点を表 6 にまとめました。手書きの SVG の図も、仕様ファイルの行以外は同じ考え方で点検できます。
表 6：描き直しの前のチェック表
| 確かめること | 見る場所 | 理由 |
|---|---|---|
| 本文の幅 | スマホでの表示 | 縮小率の分母になる |
| viewBox の幅 | SVG の先頭 | 縮小率の分子になる |
| 最小の font-size | SVG の text | 12px に要る値と比べる |
| 仕様ファイルの置き場所 | リポジトリ | 無いと再生成できない |
| 本文の画像の参照 | 記事の本文 | 幅や高さの指定を探す |
| 公開済みの図との一致 | 古い描画の結果 | 値の上書きを防ぐ |
Google の画像検索は、img の src で参照された SVG も対象にし、画像の内容を伝える代替テキスト（alt）を手がかりに使います。ファイル名を変えずに描き直せば、alt と画像の参照はそのまま残ります。描き直しの時に図の内容が変わる場合だけ、alt も合わせて直すとよいでしょう。
同じように、AI の成果物を機械の検査で止める仕組みは、AI の成果物を人の確認なしで本番へ出すための 4 つの検査をまとめた記事でも扱っています。検査を手元で動かすか CI で動かすかは、CI と手元の検査の選び方を記録した記事で比べています。
まとめ
- SVG グラフの画面上の文字は「本文の幅 ÷ viewBox の幅 × font-size」で決まります。本文の幅 292px なら、幅 480・font-size 20 で約 12px になり、幅 960 のままでは約 3.7〜4.6px でした
- 公開済みの図は、ファイル名を変えずに中身だけを入れ替えれば、本文を書き換えずに描き直せます。ただし、仕様と公開済みの図の一致を確かめてから描き直します
- 図を後から直せるように、出力の SVG だけでなく、入力の仕様ファイルと描画スクリプトをリポジトリに残します
自動生成のグラフやレポートの作り方、描き直しの段取りを相談したい方は、お問い合わせからご連絡ください。グラフの元になる集計を BigQuery の SQL で作っていて、読むデータ量や集計の単位が意図どおりかを第三者の目で確かめたい方は、BigQuery SQL レビューパックもご利用いただけます。