私は提案書や社内資料に図を多く使います。この記事では、その図を AI に描かせるための自作スキル「zukai（図解）」についてお話しします。AI に「図を描いて」と頼んで画像が出てくる作り方ではなく、構造を JSON に書いてコードで描く作り方です。
結論を先に書きますと、依頼の一言から完成図まで、ラフの協議1往復と直しの1往復、合計2往復で終わります。この記事の1本目（gtasks の記事）に載せた図がまさにそれで、依頼から完成まで15分でした。以前は画像生成に頼っていて、文字化けと枠からの溢れを直すだけで同じ時間を使っていました。
作った動機は、AI が生成した図は「そのまま資料に貼れない」ことにあります。文字が化ける、枠から文字がはみ出す、意味の無い矢印がある、そして「この箱の文言だけ直して」ができない、という4つが毎回起きるのですが、図を生成物ではなく設計物として扱えば、全部消えると考えました。この記事では、gtasks の図1枚が依頼から完成までどう作られたかを、途中でできたものを全部見せながら追っていきます。
依頼の前に AI が書く「仕様書」
依頼はこれだけでした。「gtasks の全体像を図にして。入口が3つあって、正本は Google ToDo ひとつ。毎朝ダイジェストになって届く、というのが伝わる形で」。これに対して AI は、絵を描く前にまず仕様書を書きます。目的・主役・関係の型・強調する1点・捨てるもの、という項目です。
{"purpose": "タスクの入口が複数あっても、正本は Google ToDo ひとつに集まり、毎朝ダイジェストになる",
"audience": "ブログ読者",
"hero": "Google ToDo",
"relations": ["収束", "段階"],
"emphasis": "ダイジェスト（焦点色は1つだけ）",
"omit": ["コマンド名", "ファイル名", "認証の話"],
"density": "簡潔", "target": "doc"}
ここで効いてくるのは「捨てるもの」です。コマンド名やファイル名を図に入れてしまうと、読者が読む図ではなく、作った人の備忘録になってしまいます。図解の9割は、何を描くかより何を描かないかで決まると思います。仕様書はそれを最初に決めさせるための型で、AI が「意味の無い図形」を置く余地を構造的に減らしてくれます。
関係の型も仕様書で決めます。この図は「収束」（3つの入口が1点に集まる）と「段階」（集まった後に流れる）の複合です。スキルには元型が18種あり、並列・順序・収束・中心と派生・循環・積層・2軸・時系列・比較・前後などから選び、複合することができます。1つの型に押し込めない、というのが大原則の1つになっています。
さらに、仕様書には密度と載せ先も書きます。興味を引くための図は「詳細」、手順を示す図は「簡潔」。載せ先が文書なら横長、スライドなら判型固定、という具合です。同じ資料に図が複数あるなら、どの図をどの元型で描くかの配役も仕様書に書いておき、単調にならないようにします。この段階で決めておくと、後の工程で AI が迷いません。
ラフ2案 — 灰色のワイヤーで構図だけを選ぶ
AI は元型 converge（収束）と flow（工程）で2案を作り、文章ではなく灰色のラフで出してきました。色も文字の細部も付いていません。構図だけを見せる、というのがラフの役割です。
添えられた説明は各1行です。案A（収束）は「入口が複数あっても正本は一つ」を形で言い、ダイジェストを焦点色にします。一方、案B（工程）は時系列が分かりやすいものの、「正本が一つ」が形に出ません。そこで私は案A を選びました。案は文章で出させても選べません。灰色のラフを2〜3枚並べて初めて、構図の良し悪しが見えてきます。
この方式にする前は、AI が1案を完成品の状態で出してきて、私が「なんか違う」と言い、また1案作り直す、というやりとりを繰り返していました。そこで、構図の候補を先に絵で見せ、色や文字は決まってから付ける、というように工程を分けたところ、往復が減りました。
ラフは完成図と同じ中間表現（JSON）から描いています。灰色にしているだけで、要素も座標も本番と同じです。ですから案A を選んだ瞬間に、その JSON がそのまま次の工程に進みます。ラフのために別の絵を描いて、選ばれた後に本番を描き直す、という二度手間がありません。案ごとに「何を強調し、何を捨てたか」を1行ずつ添えているのは、比べる軸を揃えるためです。3案目が要るのは A と B の折衷が思い浮かぶときだけで、無理に3つ出させることはしていません。
描く前の機械検査 — lint
確定した案A を描く前に、lint（機械検査）を通します。見ているのは、枠からの文字のはみ出し、要素の重なり、1文字だけ次行に落ちる孤立、フォントに無い文字（絵文字は豆腐になります）、文字と地の色のコントラスト、焦点色が2つ以上ないか、重心と余白の偏り、といった項目です。この図は一発で通りました。
通らないとどうなるかをお見せするために、わざと崩した版も検査してみました。入口の文言を長くし、焦点色を2か所に付けたものです。私が見るのは検査の生の出力ではなく、AI がそれを読んで会話で報告してくる形です。
AI に「気をつけて」と言うのではなく、描画の前に機械が止めるようにしています。検査の項目は、私が過去の図を講評した履歴から増えてきました。「最終行が1文字だけ落ちる」「絵文字が豆腐になる」「英単語の途中で折り返す」「完／了のように語の途中で割れる」。どれも実際に起きてから項目に足したものです。このように講評を規約に、規約を検査に変えていくと、同じ崩れは二度と出ません。
文字の溢れは自動で縮小され、それでも収まらなければエラーになります。日本語の折り返しは、開き括弧の前・閉じ括弧の後・句読点の後を優先し、閉じ括弧が行頭に来ないよう前行にぶら下げます。また、括弧だけの行は付属情報とみなして小さく薄く描きます。この2つは、gtasks の図を見た私の指摘から、この記事を書いている途中で入った規約です。一方、lint で判定できないこと、つまり図が章の主張を表しているか、誤読を招かないかについては、描いた PNG を AI 自身に読み込ませて確かめてから出させています。「だいたい OK」で流さない、と SKILL.md に書いてあります。
直しは番地で受ける — review モード
完成図はこちらです。
ここで私が「入口の3つ目の文言を変えたい」「右端の文も少し」と言ったとします。すると AI は、要素番号を重ねた review モードの画像を出してきます。
私はこの番号で指示します。「E5 を『メールやチャットから「タスクに追加」』に。T12 の2行目は『削除だけは人が押す』。A11 に『毎朝6時』のラベル」という具合です。AI はそれを JSON の操作に写し、該当要素だけを直して再描画します。構図の協議をやり直さずに、番地の指示だけで1往復で終わります。図の本体が JSON だからできることです。
[{"id": "E5", "set": {"text": "メールやチャットから\n「タスクに追加」"}},
{"id": "T12", "set": {"text": "朝、チャットに届く\n削除だけは人が押す"}},
{"id": "A11", "set": {"label": "毎朝6時"}}]
番号の付け方は単純で、E は箱や楕円などの要素、A は矢印、T は独立した文字です。操作は3種類あり、文言や役割を書き換える set、要素を消す remove、位置をずらす move です。文言・位置・色の役割・スタイルはこの操作で直し、構図そのものが変わる直しだけ元型の選び直しに戻ります。私が「直して」と言ったものの9割は文言と位置ですので、ほとんどの直しは元型に戻りません。
直しの履歴も JSON に残ります。どの要素をいつどう変えたかが追えますので、「前の版の方が良かった」と言われても戻せます。画像を生成し直す方式では、この履歴が残りません。差分が見えることが、図を「設計物」と呼ぶ理由の半分だと思っています。
手直しできる形で渡す — そして使うには
完成図は PNG だけでなく、同じ JSON から SVG・draw.io・スライド用の図形データ・Mermaid でも出ます。私が draw.io で文字を直しても、元の JSON は残ります。AI の出力は、人が手直しできる形で渡して初めて仕事で使えるものになると思います。
| 形式 | 用途 |
|---|---|
| PNG | Google ドキュメント・ブログに貼る |
| SVG | 鮮明に拡大したい資料・Web |
| draw.io | 人が手で位置や文言を直す |
| スライド用 JSON | Google スライドに図形として挿入（編集可能なまま） |
| Mermaid | 文書内に文字として埋め込む |
自分の環境で動かすなら、置く場所は .claude/skills/zukai/SKILL.md（進め方と大原則）と scripts/zukai/（元型18種・検査・描画器・アイコン）です。前提は Python 3 と Pillow だけで動きます。ただし日本語フォントは環境依存で、社内版は macOS のヒラギノ固定になっていますので、他の OS では zukai_ir.py のフォントパスを変えてください。起動の言葉は「◯◯の仕組みを図にして」。AI が仕様書と入力 JSON を書き、ラフを2〜3枚出してきます。
## 大原則 1. 「見た目」より先に「構造」を見抜く。図解の9割は関係の型を正しく捉えられるかで決まる 2. 1つの型に押し込めない。元型を複合して内容の構造を素直に写す 3. 案は文章でなく絵で出す。妥当な構図が複数あるなら、ラフ2〜3案を画像で提示する 4. 提示前に lint と自分の目。機械検査を通し、PNG を読んでから出す 5. 直しは番地で受ける。review モードの要素番号で修正指示を受ける 6. 人が手直しできる形（draw.io / SVG）を常に一緒に出す
向いているのは、提案書や教材に図を多く使い、毎回デザイナーに頼むほどではないが自分で描くと崩れる、という方と、構成図を差分で管理したいエンジニアだと思います。一方、写真のような画像やイラストが欲しい方には向きません。描けるのは概念図（箱・楕円・矢印・文字・アイコン）だけです。
まとめ
- 図は「生成」ではなく「設計」する。仕様書が最初
- 構図はラフの絵で選ぶ。文章で選ばない
- 崩れは描く前に lint が止める。講評は規約と検査に変える
- 直しは要素番号で受け、1往復で終える
- 同じ JSON から PNG・SVG・draw.io が出る
記事カテゴリー
同じカテゴリのブログ
