これで何ができるか

記事やレポートに図を入れると読みやすくなるので、AIに図解やグラフを作らせたくなります。作ってはくれます。ただしAIの作る図は、それらしく見えて細部が崩れます。文字の上を線が横切る。ラベルが枠からはみ出す。しかも困ったことに、この種の崩れは目視のチェックをすり抜けます。全体の印象を見てしまい、1本の線までは見ないからです。

このサイトの図も全部AIに作らせていますが、崩れた図が公開されたことはありません。人間の目が優秀だからではなく、公開の前に機械の検査を通しているからです。この記事はその検査を「作らせる」頼み方です。

図の崩れを止める流れ。図を生成したら、①公開のたびに自動で座標を検査（文字を線が貫く・枠や画面からのはみ出し。実例として副題を枠の上辺が貫いたのを公開前に停止）、②図を触った日にはブラウザで実寸を計測（実例として3pxと22pxのはみ出しを検出）、その両方を通ってから公開する。
2段構えの検査。右に書いてあるのは、この検査が実際に捕まえた崩れです。どちらも目視では見落としていました。

前提
かかる時間 30分
費用 無料
必要なもの ファイルを作れるAI（Claude Code など）と、AIに作らせた図（SVG形式）
プログラミング 不要。この記事の指示文をコピーして貼るだけです

図の形式はSVG（文字や線の位置がデータとして残る画像）を前提にします。位置がデータで残っているから、機械で検査できます。

AIへの頼み方

1. 図は「手描き」ではなく「計算」で作らせる

検査の前に、そもそも崩れにくくする頼み方があります。

図はSVGを直接手で書くのではなく、位置を計算で出すプログラムから生成してください。 文字の位置、枠の高さ、棒グラフの長さを目分量で書くと必ずどこかで重なります。行数や項目数から計算して配置してください。

AIに図を直接書かせると、要素が増えたときに前に置いたものと新しいものが重なります。人間が紙に描くときと同じです。計算で出させれば、項目が増えても配置が自動で追従します。

2. 公開の工程に検査を入れさせる

ここが本体です。検査は「たまに実行するもの」ではなく、公開の通り道に置きます。

公開の工程に、図の検査を追加してください。見るのは3つです。 1. 文字の上を線が横切っていないか 2. 文字が枠から上下にはみ出していないか 3. 枠や画面の右端からはみ出していないか 1枚でも崩れていたら、公開そのものを止めてください。「崩れた図だけ古いまま公開を続ける」という中途半端な状態を作りたくないです。

この検査が実際に捕まえた崩れがあります。図の副題の文字を、すぐ下の枠の上辺が貫いていました。公開直前まで、人間は誰も気づいていませんでした。検査がビルドを止めて、初めて分かりました。

3. 「誤検知しない側」に倒させる

検査を作らせるとき、精度の方針を先に渡します。

検査は、誤検知しない側に倒してください。文字の幅を推定で判定する部分は、確実にはみ出していると言える場合だけ報告してください。数ピクセルの見逃しは許します。 崩れていないのに止まる検査は、そのうち「また誤報か」と全部無視されるようになって、検査ごと死にます。

検査の敵は見逃しではなく、狼少年化です。誤検知だらけの検査は必ず無視されるようになり、本物の崩れまで素通りします。見逃し側は、次の手当てがあります。

4. 図を触った日は、実寸で測らせる

推定に頼らない検査を、もう1段だけ足します。毎回ではなく、図を追加・変更した日だけで十分です。

この図をブラウザで開いて、文字の実際の描画サイズを測って、枠からのはみ出しが1ピクセルでもないか確かめてください。測った数値も見せてください。

実寸の計測は、推定の検査が見逃した3ピクセルと22ピクセルのはみ出しを実際に捕まえています。「たぶん収まっている」と「測って収まっている」は別物です。この言い分けは「たぶん動きます」と言わせない頼み方と同じ考え方です。

うまくいかないときの言い直し方

検査は通ったのに、図が真っ黒になっていた

実際に起きました。SVGの中で使っている色の名前（class）が、定義の書き忘れで宙に浮き、図全体が真っ黒に塗り潰されたのに、検査は素通りしました。座標の検査は位置しか見ていないからです。真っ黒でも、位置は正しかったのです。

座標の検査の死角を説明する図。見ているもの＝文字と線の位置、枠からのはみ出し、画面からのはみ出し。見ていないもの＝色。定義漏れのclassは真っ黒になるが、位置は正しいので検査を通る。塞ぎ方＝使っているclassがstyleに定義されているかを、公開のたびに機械で照合する。
検査には死角があります。死角を無くすのではなく、死角がどこかを知って、別の小さな検査で塞ぎます。
SVGの中で使っている色やスタイルの名前（class）が、そのSVG自身のスタイル定義にすべて存在するか、照合する検査を追加してください。 定義に無い名前を使うと図が真っ黒に塗られるのに、座標の検査では捕まえられません。これも公開の通り道に置いて、毎回自動で照合してください。

大事なのは考え方のほうです。検査が通った、は「検査が見ている範囲では問題ない」でしかありません。事故が起きたら「なぜ検査が見逃したか」を聞いて、死角を1つずつ検査に変えていきます。

検査が厳しすぎて、毎回止まる

この検査は誤検知です。崩れていない図で止まっています。 検査自体は消さないでください。代わりに、この誤検知のパターンだけを正確に除外する条件を足してください。何を除外したかコメントで残してください。

面倒だからと検査を消すのが、一番高くつきます。消した検査は戻ってきません。除外条件を精密にする方向で直させます。

同じ崩れが、別の図でまた出た

前に直したのと同じ種類の崩れが、別の図で出ました。 その図だけを直すのではなく、図を生成しているプログラム側を直して、全部の図に同じ直しが効くようにしてください。直したら全部の図を作り直して、検査を通してください。

1枚ずつ直すと、直し漏れが必ず残ります。直しは「生成する側」に入れて、全部作り直させるのが結局一番速いです。

応用・次の一手

この記事の考え方は図に限りません。「目視では見落とすものを、機械の検査に置き換える」は、AIに作らせるあらゆるものに効きます。

いま公開前に人間の目で確認していることを一覧にしてください。そのうち、機械で検査に置き換えられるものはどれですか。 置き換えられるものから順に、検査として実装してください。人間の確認は、機械にできないものだけに減らしたいです。

検査が増えるほど、人間の確認は短くなります。このサイトでは、機密の混入・リンク切れ・画像の崩れ・マーカーの使いすぎまで機械が見ていて、人間は「内容が本当か」だけを読んでいます。

図そのものより先に仕組みを整えたい場合は、自動化が静かに壊れたのを、AIに見つけさせるが隣の話題です。