記事7本のうち、画像生成AIの絵が入ったのは1本だけだった

きっかけ

引っかかったのは、記事の本文が仕上がったあとに、毎回同じところで止まっていたことだった。

文章は出る。HTMLやCSSも出る。ビルドも通る。そこまで来て、「で、この記事の図はどうするのか」が残る。画像生成AIは手元で動く状態にあるのに、その場で解決しない。

最初は指示の出し方が悪いのだと思っていた。もっと具体的に指示すれば、記事に合う図が一発で出るはずだと。実際には、指示を具体的にするほど、別の問題が出た。

仮説として置いたのは、詰まっているのは画像生成の性能ではなく、絵に何をやらせるかの判断のほうだ、ということ。だとすれば、生成AIの出力が記事に入る割合は低く出るはずだし、入った場合も限定された役割を担っているはずだ。

確かめ方は、数えること。感覚で「絵が大変だった」と書くのではなく、公開済みの記事を開いて、画像ファイルが何点入っているか、それぞれ何で作られたかを数える。

範囲も先に書いておく。数えるのは、この連載の記事7本だけ。イラスト主体のサイト、広告のビジュアル、商品写真のような用途は含まないし、画像生成AIの性能比較もしていない。

やったこと

手順は4つ。

1. 公開済みの記事7本を開いて、画像ファイルの点数を数える。 本文に埋め込んだ画像と、記事の表紙として指定した画像を分けて数える。
2. 各画像の作り方を分類する。 画像生成AIの出力か、手で組んだ図か、実際の画面の撮影か。
3. 生成AIを使った分について、生成時の指示内容を確認する。 何を生成させ、何を除外したかを、保存してある生成記録から読む。
4. 絵を用意するまでに実際に踏んだ工程を書き出す。 差し戻しが起きた地点を記録する。

制作時間は測っていないので、「絵の工程が全体の何割か」は言えない。書けるのは点数と工程の内訳だけになる。

7本の内訳

記事	画像	画像の作り方
1	0点	HTML/CSSとSVGのみ
2	2点	実ログを出せないため作り直した図
3	1点	同上（ほかにSVGの図1点）
4	1点	同上（ほかにSVGの説明イラスト1点）
5	0点	HTML/CSSのみ
6	1点	画像生成AIの出力（背景のみ）＋SVGを重ねる
7	0点	公開時は図ゼロ。表紙の絵だけ後から1点追加

本文に入った画像ファイルは5点。画像生成AIが作ったのは、そのうち1点だけだった。図を1枚も置かずに公開した記事も2本あった。

その1点が、何を担当していたか

記事6の図は、生成した背景の上にSVGで文字と矢印を重ねる作りになっている。生成時の指示は保存してあり、除外指定にこう並んでいた。

文字、アルファベット、単語、キャプション、ラベル、矢印、透かし、ロゴ、看板、数字、画面上の文字、読める文字

つまり、意味を持つ要素はすべて生成させない指示になっている。生成AIに任せたのは、淡い色の抽象的な背景だけだった。順序も、ラベルも、矢印も、上に重ねたSVG側が持っている。

背景の絵は、この形になるまでに1回作り直している。最初の試作は作業机の絵で、左が作業中・右が未着手という意味を絵に持たせていた。意味を絵に焼き込むと、後から直せない。そこで意味を完全に外したら、今度は氷山の風景になり、記事の内容と何の関係もない絵になった。記事6にはこの氷山の背景のまま載っている。関係がないと気づいたのは公開した後で、絵は差し替えず、線引きだけを決めた。背景は記事の雰囲気を弱く連想させるところまで。正確な意味は重ねる側が持つ。

絵で差し戻しが起きた地点

記事	起きたこと	どこで直したか
4	説明イラストのつもりが、箱と矢印の模式図になっていた	作り直し
5	図を画像にしたら、文字主体だったため縮小時に読めなくなった	画像をやめてHTML/CSSへ
6	生成画像に工程の意味を持たせすぎた／次は記事と無関係になった	意味は重ねる側へ移した。背景は差し替えず、線引きを後から決めた

記事5の差し戻しからは、共通の判断基準が1つ増えた。絵そのものから大意が伝わるときだけイラストにする。文字を読ませないと成立しないものはHTML/CSSで組む。 この記事のためのルールではなく、以降の全記事に適用する基準として書き出してある。

図ゼロで出した記事に、あとから絵が戻ってきた

記事7は、図もカードも画像も置かずに公開した。本文が言葉の対比そのものを扱っていて、図にすると情報が減るという判断だった。その13日後、この記事に表紙の絵を追加している。本文は変えていない。一覧に並べたときの見え方の問題で、本文の読みやすさとは別の理由だった。

本文の完成と絵の完成は、別のタイミングで来る。

わかったこと

絵が出ないのではなく、絵を「この記事のもの」にする判断が自動化できていない。実際に残った工程を並べると、こうなる。

1. 何を描くか決めるそもそも図が要るのか、要るとして何を示す図なのかを決める。ここを飛ばすと、きれいだが記事と関係のない絵が出る
2. 形式を選ぶ生成画像か、手で組む図か、HTML/CSSか、実際の画面か。文字を読ませる図なら画像にしない
3. 素材を作る生成する場合は複数案を出す。1発で決まったことはなかった
4. 文字を載せるラベル・矢印・順序は生成させず、あとから重ねる。ここを絵に焼くと直せなくなる
5. 組み込むページへ入れて、他の記事の表示を壊していないか確かめる
6. 実機で見るPCとスマホの実画面で見る。縮小したときに文字が潰れていないか

このうち、画像生成AIが担当したのは3番目の一部だけだった。何を描くか、画像にするかHTML/CSSにするか、文字をどこに載せるか。この判断を飛ばすと、きれいだが記事と関係のない絵になるか、文字が潰れて読めない図になる。実際に両方やった。

分類してみると、必要な視覚素材は4種類あり、生成AIが向くのは1種類だけだった。

種類	何に使うか	向いている作り方
装飾・雰囲気	記事の空気を作る。意味は持たない	画像生成AI
説明図	順序・対比・構造を正確に伝える	HTML/CSS、SVG
実物の画面	実際にそうなっている証拠	撮影。出せない場合は作り直した図
文字主体の図	表・一覧・対応関係	HTML/CSS（画像にしない）

この連載は説明が中心なので、必要な素材の大半が2番目と4番目に寄る。だから生成AIの出番が1点で済んだ、とも言える。イラストが主役のサイトなら、この比率は変わるはずだ。

落ち着いたのは、役割を分ける形だった。雰囲気は生成に任せ、意味は毎回同じ形で出せるHTML/CSS/SVGの側が持つ。少なくともこの連載では、図版づくりという工程は消えず、担当が変わっただけだった。

この分担に変えてから図版をどう頼んでいるか、完成図までAIに任せていたときと何が違ったかは、素材を先に作った記事に書いた。

もう1つ効いていたのは、実物の画面を出せない制約だった。実際のログや操作画面は、内部のファイル名やパスを含んでいて、そのままでは出せない。伏せ字にしても掲載に向かない。だから4点は「実際の構造だけ残して作り直した図」になった。これは生成AIの問題ではなく、公開してよい素材が手元にない、という別種の制約になる。

弱いところもある。数えたのは7本で、統計と呼べる量ではない。使った画像生成の構成は1つだけで、他のモデルや他の指示の出し方なら違う結果になった可能性がある。1人・記事7本・約1か月の範囲で数えた。