説明用の図は、生成AIより自分で作ったほうが速かった

• 正確な配置と文字が必要な図は、生成では作れない
• 意味のある図は、こちらが構造を分かっている必要がある
• 簡単な図形と文字なら、手元の道具で数分でできる

記事に載せる説明図を生成で作ろうとして、何十回も作り直した末にやめた。向き不向きがはっきりしているので、整理しておく。

作ろうとしたもの

こういう図を作りたかった。

• 処理の流れを、矢印でつないだ図
• 要素の関係を示した図
• 画面の構成を示した枠線の図

どれも位置と文字に意味がある。見た目の良さではなく、正確さが要る種類だった。

なぜ難しいか

試して分かった理由は3つある。

• 文字が読めない — 図のラベルが崩れる
• 配置が指示通りにならない — 「左に A、右に B」が守られない
• 矢印の向きが変わる — 関係が逆になる

3つ目は意味が反転するので致命的だ。見た目は図でも、内容が間違っているものができる。

気づきにくい失敗

雰囲気が図らしいので、一見すると正しく見える。よく見ると矢印が逆だったり、ラベルが入れ替わっていたりする。

手元の道具で作る

結局、図形を並べて文字を置くだけの道具で作った。

• 四角と矢印と文字だけで足りる
• 慣れれば、簡単な図は5分ほど
• 色はサイトの配色から選ぶ。統一感が出る

生成で何十回も試した時間を考えると、最初から手で作るべきだった。

コードで図を書く方法

文字で図の構造を書き、画像にする仕組みもある。これはAIと相性がよかった。

• 構造を文字で書くので、配置が正確
• 文字も崩れない
• AIに「この図の定義を書いて」と頼める

図そのものを生成させるのではなく、図の定義を書かせるという使い方だ。間違っていれば文字を直せばよく、作り直す必要がない。

生成が向いている図

一方で、生成が合う場面もあった。

• 内容を持たない装飾。記事の区切りに置く模様
• 抽象的な概念の挿絵。正確さを求めないもの
• 背景。文字を上に載せる前提のもの

共通するのは間違いようがないものだった。意味を持たせなければ、崩れても害が無い。

画面の写しを使う

手順を説明する記事では、実際の画面を撮るのが一番だった。

• 読者が見る画面と一致する
• 作る手間がほぼゼロ
• 必要な箇所に枠を付けるだけで、説明として成立する

当然のようだが、生成に慣れると忘れがちだった。作れるからといって、作る必要があるとは限らない。

作り直しやすさで選ぶ

どの方法で作るか決めるとき、作り直す前提で考えるようになった。

• 生成 — 作り直しは最初からやり直し。同じものは出ない
• 図形を並べる — 一部だけ直せる。元ファイルを残せば何度でも
• 文字で定義 — 差分で直せる。履歴も残せる

記事は後から直すものなので、直せる形で作っておくほうが結局安い。生成した画像は、1文字直したいだけでも作り直しになる。

図を使わない選択

図にしようとして、文章や表で足りることもあった。

• 項目の比較 — 表のほうが読みやすい
• 手順の列挙 — 番号付きの箇条書きで足りる
• 2つの違い — 並べて書けば伝わる

図は作るのも読むのも手間がかかる。文章で伝わるなら、そのほうが速い。

図を載せる前に考えること

作る手段より前に、そもそも必要かを考えるようになった。

• その図を見て、読者が何を理解するのか
• 文章で書いた場合と比べて、どれだけ短くなるか
• スマホの幅で見たとき、読めるか

3つ目で落とすことが多い。横に広い図は、スマホでは縮んで読めない。縦に長い形にするか、文章に置き換えるかの判断が要る。記事の読者の大半がスマホなら、図の形はそれに合わせる。

まとめ

• 位置と文字に意味がある図は、生成では作れない
• 矢印の向きが変わると、内容が反転する。気づきにくい
• 図形と文字を並べる道具なら、簡単な図は5分でできる
• 図の定義を文字で書かせる方法なら、AIが使える
• 手順の説明は、画面の写しが最も正確で速い