手順の流れ図、組織の関係図、システムの構成図。資料に入れたい図をAIに作らせようとして、うまくいかない人は多いはずです。
画像生成で作ろうとしているなら、そこが原因です。
画像生成では図が作れない
拡散という方式では、ノイズから少しずつノイズを取り除いて絵を浮かび上がらせます。文字らしい模様は作れても、正しい綴りである必要を理解していません。
その結果、文字が崩れる。線が途中で切れる。矢印が繋がっていない。図として成立しません。
近年のモデルは文字の扱いが改善していますが、図解のように「意味が決まっている要素を正確に配置する」作業は苦手なままです。
図はコードで書かせる
代わりに使うのが、図を記述するための書き方です。文章で構造を書くと、それが図に変換される仕組みがあります。
| 方式 | 向いている図 |
|---|---|
| Mermaid | 流れ図、順序図、ガントチャート。多くのツールで表示できる |
| PlantUML | システムの構成図、クラス図 |
| SVG を直接書かせる | 細かい配置を指定したい図 |
| 表計算のグラフ | 数値のグラフ。データを渡して式を書かせる |
最大の利点は、直せることです。画像で出てきたものは直せませんが、記述で出てきたものは1行変えれば図が変わります。
頼み方
「図を作って」ではなく、方式を指定します。「Mermaidの記法で流れ図を書いて」。
そのうえで、図に入れる要素を箇条書きで渡す。誰が何をして、次に何が起きるか。この材料がないと、一般的な流れ図になります。
分岐や条件も言葉で書いておく。「承認されたら次へ、却下されたら差し戻し」。構造が決まっていれば、あとは記法に落とすだけの作業です。
既存の図を直させる
すでにある図を更新したい場合も、記述で持っておくと楽になります。
画像として保存した図は、直すたびに作り直しです。記述で残しておけば、変わった箇所を1行書き換えるだけで済む。
画像しか手元にない場合は、その画像を読ませて記述に起こさせる手もあります。完全には再現されませんが、ゼロから書くよりは速い。
起こした記述は、元の図と並べて確かめます。要素が抜けていることがあります。
確認すること
出てきた記述は、表示させて目で見ます。
構文が間違っていて表示されないことがある。その場合はエラーの文言をそのまま渡せば直ります。
表示されても、要素が抜けていたり、矢印の向きが逆だったりする。渡した箇条書きと突き合わせて確かめます。
数値のグラフでは、軸の範囲と単位を必ず見ます。ここが変だと、図が誤解を招く形になります。
色と大きさの指定
記述の方式によっては、見た目も指定できます。
要素ごとに色を変える、強調したい箇所を太くする、並びの向きを縦から横へ変える。資料の配色に合わせたいなら、色の指定を渡します。
ただし凝りすぎると記述が長くなり、直しにくくなる。構造が伝わればよい図なら、既定のままで十分でしょう。
図が要らない場合も多い
作れるようになると、つい入れたくなります。
ただ、箇条書きや表で済む内容を図にしても、読みやすくはなりません。図が要るのは、順序や分岐や位置関係のように、並べただけでは伝わらない構造がある場合です。
3つの項目を並べるだけなら、表のほうが速く読めます。
写真と図を使い分ける
画像生成が向いているのは、雰囲気を伝える絵のほうです。
資料の扉、記事のアイキャッチ、印象を作るための背景。正確さが問われない用途なら、生成した写真が使えます。
正確さが要るものは記述で書かせ、雰囲気が要るものは生成させる。この分け方で、たいていの資料は作れます。
記述をそのまま資料に貼る
ツールによっては、記述を貼るだけで図が表示されます。
社内の文書管理ツール、ノートアプリ、開発者向けのサービス。対応しているなら、画像に書き出す工程そのものが要りません。
対応していない場合は、表示させた図を画像として保存します。ただし記述のほうも一緒に残しておく。次に直すときに使えます。
画像だけ残して記述を捨てると、半年後に一から作り直すことになります。
まず1枚作ってみる
記法を覚える必要はありません。作りたい図の中身を箇条書きで渡して、方式だけ指定すれば出てきます。
出てきた記述を見れば、書き方の見当も付く。次からは自分で少し直せるようになります。
画像生成で崩れた図を作り直すより、こちらのほうがずっと速いはずです。
出典
画像生成の仕組みについては、下記の論文に基づきます。記述で図を作る方式の仕様は、Mermaidの公式ドキュメントを参照しました。
