AIに完成図を任せるより、素材を先に作った方が早かった

記事の図版を、仕上げまでAIに任せていた時期がある。置かれたのは、記事と関係のない氷山の背景と、本文の手順を箱に入れて並べ直しただけの図だった。いまは、何の図かを先に決めて素材に分け、素材だけをAIに作らせてから組み合わせている。その切り替えの記録。
結論
少なくとも今回の制作では、図版を完成までAIに任せるより、何の図かを先に決めて素材に分け、素材をAIに作らせてから文字・数字・矢印をHTML/CSS/SVGで重ねるほうが早く、安定した。AIは素材づくりが苦手だったわけではない。難しかったのは、この記事にどんな図が要るかを決めて、読者の役に立つ図として一度に仕上げることだった。
きっかけ
記事7本の画像を数え直した記事では、図版づくりの工程は消えず、担当が変わっただけだったと書いた。あの記事は数えるところまでで、図版をどう分けて頼むようになったかは書いていない。この記事はその続きになる。
この連載では、記事の制作をAIに任せるとき、図やUIの実装まで含めて完成させる前提にしていた。本文を書き、必要なら図やイラストも入れ、ブラウザで表示できる状態まで持っていく。図版だけ別の工程に切り出してはいなかった。
その進め方で、図版について引っかかる結果が2つ出た。
1つ目は記事6の図。AIのセッションを引き継ぐ流れを示す図で、背景を画像生成AIに作らせ、その上に文字と矢印を重ねる作りにした。背景の生成条件はAIが組み、文字・ラベル・矢印・人物は描かせない指定にした。7枚生成して4案に絞り、見た目の魅力、文字を重ねる余白、重ねた要素と干渉しないか、サイトの画風に合うか、の4つで比べた。選ばれたのが下の画像だ。
氷山の風景だった。4つの条件はすべて満たしている。文字は入っていないし、上の余白も空いている。ただ、仕事にもセッションにも引き継ぎにも関係がない。図の意味は、上に重ねた「セッションA → 終了処理 → セッションB」の文字と矢印がすべて持っていて、背景は読者の理解に何も足していなかった。
これは自分の目視確認も通って、そのまま公開している。記事と関係がないと気づいたのは公開後で、比べた4つの条件の中に「記事の内容とつながっているか」が入っていなかった。背景の画像はいまも記事6に載っている。
2つ目は記事4の図。AIが自分で作業を進める範囲と、人間に判断を戻す地点の境目を、1枚の説明イラストで見せる指示だった。初版は、角丸の箱を縦に並べて矢印でつないだ図になった。
図用の共通部品で組んであり、記事1・3の図と見分けがつかない。図の下の説明文にも「模式図」と書いてある。図としては成立している。ただ、本文にある作業の並びを箱に入れ直したものに近く、どこで主体がAIから人間に変わるのかは、破線の箱1つに任されていた。この初版は、AI側のまとめ役が要件を満たしていないと判断して差し戻し、道を進むAIが赤い停止ゲートの手前で止まる絵に作り直している。
どちらも「図を入れる」という要件は満たしていた。足りなかったのは、この記事の読者にこの図で何を分かってもらうのか、という判断のほうだった。
やったこと
図版の頼み方を、完成図から素材に変えた。手順は4つ。
- 何を伝えるための図かを先に決める。 記事の中でその図が担う役割を、1文で言える状態にしてから作り始める。
- 必要な素材に分ける。 背景、キャラクター、ボード、記号、文字、数字、矢印のように部品にする。
- 絵の部品だけをAIに作らせる。 構図・表情・ポーズなど、条件をはっきり渡せる単位で頼む。
- 正確さが要る部分はHTML/CSS/SVGで組む。 文字・数字・矢印・比較・情報の構造は、生成画像に描き込まず上から重ねる。
いちばん使っているのは、記事の上部に置く表紙の画像(ヒーロー画像)だ。背景、案内役のキャラクター「ロク」、何も書いていないボードまでを生成画像で用意する。記事の見出しや数字、短い比較、矢印は、ボードの上にHTML/CSS/SVGで重ねる。
最初の試作では、分類の見出しを生成画像のボードに描き込んでいた。いまは描き込まず、ボードは空のまま作っている。記事ごとに変わる文字は、全部あとから重ねる側に回した。
逆向きの失敗もあった。「危険だった」の表紙で、ヘルメットの絵をSVGで描き足す案があり、これは無理があるという判断で採らなかった。いまの「危険だった」の土台画像は、ヘルメットを描かず、生成画像のロクの険しい表情と、手のひらを前に出して止めるポーズで表している。絵で伝える部分は、コードで描くより生成画像に任せたほうが収まった。
最終的に、表紙は結果の種類ごとに8種類の土台画像を固定した。うまくいった、うまくいかなかった、比較してわかった、などの8つで、違いは主にロクの表情とポーズになる。記事1本ごとにやることは、8つから1つ選ぶことと、ボードに載せる文字を数行書くことだけになった。
わかったこと
AIは、素材を作るのが苦手だったわけではない。氷山の背景は、渡した条件をすべて満たしていた。表紙の土台画像も、背景・キャラクター・ボードまで生成画像で揃っていて、方向性は良いという判断で採用している。部品として頼んだものは、部品としてちゃんと出てきた。
難しかったのは、その手前だった。この記事にどんな図が要るか、読者が図を見たときに何が分かればいいか。完成図を頼むと、この判断もまとめて渡すことになる。記事6では判断の物差しに「記事とつながっているか」が抜けていて、記事4では「説明イラスト」という指示に対して、いちばん典型的な形が出てきた。記事6は自分も目視確認で見落としているので、AIだけの問題とも言えない。
素材から頼む形に変えて早くなったのは、判断と作業が分かれたからだと考えている。何の図かを人間が先に決めてしまえば、AIに渡す依頼は小さくなり、出てきたものが合っているかもその場で判断できる。文字や数字を直すときは、重ねる側の数行を書き換えるだけで、絵を作り直さなくていい。記事1〜7の表紙を同じ仕様に揃えたときは、7本分をまとめて入れ替えられた。制作時間は測っていないので、何割早くなったかは言えない。
比較:図版の頼み方
完成図を任せる
- AIに渡すもの
- 記事の本文と「必要なら図も入れて」
- 合っているかの判断
- できあがった図を見て、記事に合うかを後から判断する
- 直すとき
- 作り直しになりやすい。文字や意味を絵に描き込むと、部分だけ直せない
素材を先に作る(採用)
- AIに渡すもの
- 何の図かを決めたうえで、部品を1つずつ
- 合っているかの判断
- 部品ごとに、渡した条件に合うかを見る
- 直すとき
- 文字・数字は重ねる側を書き換える。絵は該当する部品だけ差し替える
CSSやSVGで図を作ること自体が悪かったわけでもない。記事4の初版の箱と矢印も、表紙に重ねている文字や矢印も、同じ種類の部品で組んでいる。違いは、何を伝えるための部品かを先に決めてから使ったかどうかだった。正確な文字・数字・矢印を出す役としては、生成画像よりこちらのほうが崩れない。
範囲も書いておく。これは1人が、この連載の制作ラインで、当時使っていたAIと画像生成の構成で試した結果だ。より新しいモデルなら、何の図が要るかの判断まで含めて一度に仕上げられるようになっている可能性はある。そうなれば、この記事の結論も変わる。