Slide Figures

スライドの図と挿絵

AIが作る図の失敗は、ほぼすべて「いらない情報を足しすぎ」に集約される。スライドの版面は思っているより狭く、要素を足すより大きくするほうが効く。

描く前に決めること

図を主役にするか、文字を主役にするか、どちらかに決める。図が主役のスライドは、テキストを見出しと導入の1行までにして、図を版面の幅いっぱいに使う。文字が主役のスライドは、図を挿絵の大きさ（幅100〜330px）に留めて隅へ置く。両方を立てようとすると、図は縮み本文は詰まる。

仕組みの図は1スライドで完成させない。同じ図を3〜5スライドに割り、要素を1つずつ足していく。聞き手の認知負荷が下がり、話し手も説明の順序に迷わない。

箇条書きの項目どうしに階層や分岐があるなら、図にする。「AとBは全員が行い、CとDはどちらかを選ぶ」のような関係は、同じ深さの箇条書きでは対等な選択肢に見える。判定は、矢印か囲みを描きたくなるかどうか。図にすると、書き手自身の理解の誤りも見えやすくなる。箇条書きを図へ移したら、そのスライドの結論の箱は外す。図が主役になり、箱と競合する。

手順のスライド

操作手順のスライドは、最初から「左に説明、右に実機のスクリーンショット」の2カラムで組む。文字だけの手順が続くと単調になる。スクリーンショットがまだ撮れていない段階でも、破線の枠と「何を撮るか」の1行を置き、撮影リストを残しておく。撮れたら枠を画像へ差し替える。

• 左カラムの幅は％ではなく px で固定し、改行は意味の切れ目で手で入れる。％で指定すると、本文が語の途中で折り返す（「スクリーン／ショット」）
• 右の枠は絶対配置にして、高さを左の本文に合わせる。枠が低いと、下だけが大きく空く
• 話し手が撮ったスクリーンショットは原寸のまま載せる。切り取るのは範囲を指定されたときだけにする。ブラウザの枠やサイドバーは「どの画面のどこか」を伝える情報で、切ると参加者が自分の画面と見比べる手がかりが落ちる。範囲を指定されても、指定された端より内側で切らない。収まらないなら、余白か縮尺で調整する
• 窓の影の透過部分は背景色で埋め、外枠は付けない
• 押す場所は枠で囲んで番号を振り、順に矢印でつなぐ。元の画像に描き足すだけにして、切り抜きと組み合わせない

情報量の規律

足す前に「これが無いと図が読めなくなるか」を問う。「あると親切」で足したものが、結果として図全体を小さくする。

• 1スライド1テーマ。前提条件、後続フェーズ、キーメッセージの帯は別のスライドが担当する
• 同じことを二重に書かない。段の見出しとアイコンと矢印が同じことを言っているなら、見出しを消す
• 箱の名前の下に説明のサブラベルを入れない。「CDN／配信の入口」のような名前と説明の2段組みは、機械が作った図の署名になっている。名前だけで足り、説明は口頭で言う
• 図の中に注記の文を入れない。図は図形と短いラベルだけにして、言いたい文は本文へ出す
• 矢印の下や図の隅に説明の文を書き込まない。製品名の箱は名前だけで伝わる。説明は口頭へ回す
• 横並びの要素が4つを超えたら、関係の近いものを同じ薄い背景で包んでまとめる。人が一度に追えるのは3つ前後である
• 差し戻されたら、中身ではなく骨格を疑う。前の版のレイアウトを残したまま直すと、直すたびに情報が増えて密度が上がる

構成図

• クライアント（ブラウザやアプリ）を1つのノードとして描く。人のイラストからクラウドへ直接線を引くと、画面の存在が消える
• アイコンを「役割ごとの箱」に入れない。箱に入れた時点で、描けるのは箱どうしの関係だけになる。囲ってよいのは、アカウントやネットワークのような実在する境界だけ
• スコープの外も描く。既存環境や後続フェーズは薄いグレーで置き、範囲外であることを示す
• 矢印は実装どおりに引く。「画面 → API → データ」の直列を仮定せず、権限の設定とフロントエンドの呼び出し先を読んでから引く。実際に権限を持って他を呼ぶ主体を図の中心に置くと、絵の重心と説明の核が一致する
• 1つの起点から放射状に伸びる線に、線に沿ってラベルを置かない。必ず線が文字を貫く。ラベルは、その線が通らない帯へ置く
• クラウドのアイコンは公式のアイコンセットを使う。似た色のブランドロゴで代用しない。製品名を略して別の製品と同じ表記にしない
• インフラ（実行基盤）は、上に載るものの下に敷く土台として描く。載るものを箱で並べ、ラベルに基盤の名前を書くだけでは関係が伝わらない。載るもの同士の関係（呼び出しのプロトコルなど）は、土台の上で矢印と札でつなぐ。実際に別々のインスタンスなら、土台も1つずつ分ける。1本の長い土台にすると、全部が同じ基盤に載っているように伝わる
• 手持ちに無いアイコンを、四角や記号を描いて自作しない。公式の一式（サービスのアイコンと、ブラウザ・ユーザー・フォルダなどの汎用アイコン）を手元に置き、ファイル名で引いて、使う分だけ資料のフォルダへコピーしてから埋め込む。別のリポジトリのパスに依存させない。他社のサービスはロゴを作らず、汎用アイコンとサービス名の文字で表す

2軸の図（4象限のマトリクス）

• マスは全部同じ淡い面にし、載せる名前は同じ形の濃い札にする。白抜き文字の濃い箱と、濃い文字の淡い箱を1枚に混ぜると、読み方がそろわない
• 1つのマスに名前を2つ入れるなら、2行の文字ではなく札を2つ並べる。2行だと改行なのか列挙なのか分からない
• マスの隅に小さい注記を置かない。マスの色を少しずつ変えて意味を持たせない
• 空きのマスも同じ淡い面にして、札が無いことで空きを示す
• 矢印を引くなら、横切る面と明度の離れた色にする。濃い箱どうしの間に暗い色の矢印を引くと見えない
• 札の色はデッキのほかの図と同じグラデーションにそろえる。出す前に rg -o 'fill="#[0-9a-fA-F]{6}"|stop-color="#[0-9a-fA-F]{6}"' images/*.svg | sort | uniq -c で他の図の配色と並べる

機械っぽさを消す

• アイコンを絵文字で済ませない。登場人物や道具はイラストか実物のアイコンで描く
• 人物は「ユーザー」と書いた角丸の箱ではなく、イラストを1枚置く
• 箱の中は大きめの1行ラベルが基本。「タイトル＋サブタイトルを枠で囲った箱」を並べない
• 強調は太い枠ではなくベタ塗りで付ける。階層は「ベタ塗り（主役1つ）、暗い塗りで枠なし（通常）、枠線のみ（脇役や道具）、薄い背景（ゾーン）」の4段で作る
• 図の面の色は、スライドの背景色に合わせる。中間色のレーン背景を勝手に敷かない
• 白地用の図の色だけを機械的に置換した図は、枠線とサブテキストの構造がそのまま残る。ベタ塗りと1行ラベルの型で作り直す
• 縦長の帯や大きい図形に置く文字は、縦中央に揃える。上端に寄せると浮いて見える
• 左右に分けたページの本文と画像は上揃えにし、見出しの直下から始める。縦中央に揃えるのは図形の中の文字だけで、本文を縦中央に置くと浮いて見える
• アイコンは高解像度の原本から取る。小さいスクリーンショットからの切り出しを拡大するとぼける
• 余白を残す。詰めて収めるより、箱を大きく、間隔を広く、要素を少なくする

SVGの実装

文字サイズ

図の中の文字は、書き出したPDFの実寸で16pt以上にする。会場の後ろの席から読める下限である。SVGのソースに font-size: 21px と書いてあっても、Marpで ![center w:820] と縮めて貼れば13ptになる。目安として、viewBoxの幅が1000のSVGを w:1000 で貼るなら、箱のラベルは19〜22pxにする。

文字と箱の縁のあいだは14px以上あける。

収まらないときの直す順番は、文言を短くする、箱を広げる、図の幅を上げる、font-sizeを上げる、の順である。長い文言を大きくしても箱に入らない。文言を削れば、同じ箱で13ptから17ptまで上げられる。

文字が箱に収まるかは実測する

ソースの数字から「この幅なら収まるはず」と計算しない。実際の字幅はソースに書かれておらず、font-size × 文字数 × 0.6 のような見積もりは2割ほど外れる。縮小したページ画像を見て「収まっている」と判断するのも、同じくらい当てにならない。数pxのはみ出しは見えない。

描画してから getBBox() で測る。tools/check-svg-box-fit.mjs がこれを行う。

箱の中にアイコンを入れると、そのぶん文字が押し出される。飾りのアイコンなら外すのが正解で、フォントを1〜2px下げても解決しない。

矢印

SVGの <marker> は既定が markerUnits="strokeWidth" なので、矢尻の実寸は markerWidth × stroke-width になる。8 × 4 なら32pxで、42pxの線の両端に付けると軸が消えて矢尻だけが残る。

• 矢尻は markerUnits="userSpaceOnUse" で18px前後に固定する
• 線は矢尻の3倍以上の長さを取る
• ラベルは矢印から10px以上離す
• 図形が近すぎると、矢印の軸が隠れて矢尻しか見えなくなる

グラデーション

• 水平または垂直の線の stroke にグラデーションを指定すると、線が描画されない。線のbboxの片方の辺が0になり、objectBoundingBox のグラデーションが定義できないためである。線と marker の中は単色にする。斜めの線と曲線には使ってよい
• 複数の箱をまたいで1本のグラデーションを流すなら gradientUnits="userSpaceOnUse" にして、x1 と x2 に図全体の座標を入れる。既定のままだと箱ごとにグラデーションが完結して、同じ柄が繰り返される
• 色を一括置換すると、marker-end:url(#id) のid文字列まで書き換わって矢尻が消えることがある。置換したら矢印の先端まで目で確かめる
• <text> の fill にグラデーションを指定しない。PDFへ書き出すと文字の形が失われ、文字の外接矩形がそのまま塗られて色の塊になる。縮小画像では気づけないので、拡大して確かめる。図の中の文字は単色にし、グラデーションは面の塗りだけに使う

その他

• 図の上下の空白は viewBox で切る。viewBox="0 50 1000 320" のように中身の無い帯を落としてから幅を上げる
• 図の中で数字を並べるときは、フォントサイズとベースラインを明示的に揃える
• 色の明度が近い2色を隣り合わせない。片方を薄い地に濃い文字、もう片方を濃い地に白文字にする
• 図の中の要素どうしの接触は座標で検算する。吹き出しのしっぽの先と隣の絵、ラベルの両端と隣の要素のあいだに10px以上を確保する
• 自作の図は、生成スクリプトの中で要素どうしの隙間を測る。画像・文字・矢印・札の外接矩形を記録し、どの2つも14px以上（ラベルと補足の2行は8px以上）離れ、枠から6px以上内側にあることを、書き出すたびに検査する。矢印は四角で近似せず、線分との距離で測る。意図した重ね置き（画面の中のロボットなど）だけを対象外にする。目分量で置いた図は「詰まっている」「くっついている」と全面のやり直しになる

コードに補足を付ける

コードのスライドは、コードを主役にする。小さいコードブロックの前後に説明文を足すと、余白は多いのに文字がびっしりの絵になる。

• コードの文字を大きくし、版面の幅いっぱいに使う。本文は見出しの下の1行だけにする
• 構文の色は2色まで（キーワードと文字列など）に絞る。関数名・クラス名・変数まで塗り分けると、色が散って読みにくい
• 補足はコードの中のコメントに書かない。行ごとの帯の強調もしない。コードと補足の区別が付かなくなる
• コードを1枚の画像のように扱い、その上に横向きの吹き出しを重ねる。吹き出しの箱から斜めに伸びるしっぽで、指したい行を指す
• 吹き出しはコードと別系統の色（コードが青系ならオレンジや赤）のベタ塗りに白の太字にする。同系色だとコードと補足が見分けにくい
• 吹き出しを傾けない。箱に矢印を付けない。しっぽだけを斜めにする
• 吹き出しは指す行のすぐそばの空きに置き、しっぽを短く保つ。空きが無ければコードの側に空行を足す
• 位置は目分量で決めない。書き出したPDFの行の座標（mutool draw -F stext）から、しっぽの先の座標を決める
• 吹き出しの層は、スライド全面の大きさの透明なSVGを作って重ねる。Marp の書き出しは data-* 属性を落とすので、位置や見た目はクラスで指定する
• 文言は短い1句にする（「ここで保存する」「戻り値はこの形」程度）

挿絵

入手

作者は「いらすとや」の素材をよく使う。画像はこのリポジトリに同梱していないので、必要なものを都度サイトから取得する。

1. https://www.irasutoya.com/search?q=<語> で探す。見た目の語（ロボット）より用途の語（AI 会話）のほうが当たる
2. 記事ページを開き、画像の直URLを確かめる
3. curl -sL -o "images/irasutoya-<内容>.png" "<直URL>" で保存する

利用条件（点数の上限や禁止される使い方）は、いらすとやの「ご利用について」で各自確かめる。

素材をまとめて探すときは、検索結果のHTMLから一覧を抜くと速い。検索結果の各エントリは bp_thumbnail_resize("<画像URL>","<タイトル>") の形で埋め込まれていて、記事を開かずにタイトルと画像URLが取れる。URLの s72-c を s800 に替えると大きい画像になる。

bashCopy code
curl -sL -A "Mozilla/5.0" --get --data-urlencode "q=会話" "https://www.irasutoya.com/search" -o page.html
rg -o 'bp_thumbnail_resize\("[^"]+","[^"]+"\)' page.html | head -8

• 2語以上で検索すると0件になりやすい。1語で引いて一覧から選ぶ
• タイトルが「いろいろな〜」のエントリはセット画像である。個別の画像は記事の中に並んでいる
• 取った素材は一覧画像に並べて見る。透過PNGは白地に合成してから縮小する。そのままでは黒く潰れて見えることがある

手元に保存した素材が色落ちしていたり低解像度だったりしたら、着色や拡大でごまかさず、元の記事を探して取り直す。

過去に切り出した素材が、無彩色に変換されたまま残っていることがある。納品前に、デッキが使う画像の彩度を数え、色の無いものは原本を取り直して比べる。原本がもともとモノクロ（書類の山など）なら、そのまま使う。

bashCopy code
python3 -W ignore -c "import re,sys;from PIL import Image
md=open(sys.argv[1],encoding='utf-8').read()
for u in sorted(set(re.findall(r'\./images/[^\")\s]+\.png',md))):
    im=Image.open(u[2:]).convert('RGBA');im.thumbnail((300,300));px=[q for q in im.getdata() if q[3]>200]
    r=sum(1 for a,b,c,d in px if max(a,b,c)-min(a,b,c)>25)/max(len(px),1)
    r<0.02 and print(round(r,3),u)" deck.md   # デッキのフォルダで実行。色の無い画像だけが出る

選び方

絵が本文の名詞そのものを描いているかで決める。「待つ」のスライドに待つ人、「馬車」の比喩に馬車、は通る。雰囲気合わせ（AIっぽい、仕事っぽい、OKっぽい）で選んだ絵は全部外す。合う絵が無いスライドには置かない。

選ぶ前に「このスライドの要点は何か」を1行で言い、その場面が描かれた絵を検索語にする（AIが資料を検品した振り返りなら「虫眼鏡で調べる人」）。手元の素材フォルダから選ぶのは、要点に合う絵がそこにあるときだけにする。OKサインやガッツポーズのように、どのページにも置ける汎用の絵を埋め草にしない。デッキをまたいで同じ絵に偏っていないかも数える。

bashCopy code
rg -o --no-filename 'irasutoya-[^")\s/]+\.png' slides/ | sort | uniq -c | sort -rn | head

人物の格を本文の意味に合わせる。「優秀な部下」の喩えに、やんちゃな子どもの絵を置かない。

肯定的な絵（OKサイン、ガッツポーズ、笑顔）は、本文が肯定的な結論のときだけ置く。課題や不満を並べたスライドに置くと、トーンが逆になる。1枚を差し替えるときも、元の絵を選んだ理由ではなく、いまの本文を読み直してから探す。

事例、製品、リポジトリを紹介するスライドは、挿絵ではなく実物のスクリーンショットを使う。

入れる数と位置

• 表・図・コードなど目を引く要素があるスライドには入れない。挿絵を置くのは、文字だけで殺風景になるスライドに限る。右下が空いていることは置く理由にならない。空きで判断すると、デッキ全体では多すぎて煩わしくなる
• 毎スライドに置かない。作者の例では、49スライドのデッキで挿絵は6か所が適量だった。13か所に入れたときは多すぎた
• 同じ位置に連続させない。前半だけ、後半だけにも偏らせない
• 同じ絵を2回使わない。納品前に数えて、2以上が出たら差し替える：rg -o 'irasutoya-[^."]+' deck.md | sort | uniq -c | sort -rn | head
• 基本の位置は右下の空き。右下が空いているのに左上へ置いて図形と重ねるのは逆効果になる
• 位置を散らしてメリハリを付けようとしない。挿絵は右側に揃えたまま、長い箇条書きを意味の切れ目で改行して2行に割る。すると右側に縦長のくぼみができ、そこへ挿絵が収まる
• 挿絵の右端は、本文の左右余白より内側へ入れる。本文の余白が96pxなら、挿絵は118px
• 横に長い締めの文があるスライドでは、左下に置かない。文の右端が版面いっぱいまで伸びて重なる
• 縦長の素材は幅を100〜120pxに抑える。幅190pxでも高さが380pxになり、上の要素へ食い込む
• 挿絵と吹き出しや枠は、ペアで位置を動かす
• 箱のあるスライドでは、箱と重ならない位置を選ぶ。枠線はテキスト抽出に出ないので、機械検査をすり抜ける

Marpでの書き方

<img> にインラインの style 属性を書いても効かない。Marpのパーサーが属性を落とすためで、PDFを書き出して見るまで気づけない。大きさの違うクラスを用意する。

cssCopy code
.ill { position: absolute; right: 118px; bottom: 200px; width: 200px; }
.ill.sm { width: 160px; bottom: 95px; }
.ill.md { width: 180px; bottom: 110px; }

bottom の値はスライドごとに、本文の下端からスライドの下端までの空きを測って決める。

公開ページから図を借りるとき

DOMから画像のURLを抜いて直接ダウンロードするのを、最初の手にしない。レスポンシブなサイトは同じ図の縦積み版と横並び版を両方持っていることがあり、URLだけ拾うと縦積み版を掴む。スライドは16:9なので、必要なのはほぼ常に横並び版である。

1. ページを実際の幅で表示し、スクリーンショットを1枚見る
2. 候補の画像が複数あれば、全部開いてから選ぶ。縦横比が1未満の縦長を外すだけでも当たる
3. 切り取って情報を落とす前に、切り取らずに済む版が無いかを確かめる
4. 図が小さいときは、版面の下へ押し込めて縮めない。図の上の題字と周りの余白を切り落とし、大きく貼る

図を流用するとき

• 別のデッキから図を持ってくるときは、その図を含む全デッキを素材名やSVGのクラス名で列挙し、いちばん後に直された版を使う
• 本編に出てこないサービスのアイコンを持ち込まない。デッキごとに構成が違うと、資料の中で矛盾する
• 黒地のデッキの図を白地のデッキへそのまま貼らない（逆も同じ）。黒い四角が白い紙面に浮き、別の資料から切り取ってきたように見える。素材の原本を取り直し、貼る側の背景で図を組み直す。スクリーンショットの黒い余白も同じで、外周を背景色へ抜く
• 同じ見出しのスライドは、図の対応も含めて変えない。見出しは合っているのに図が別のスライドのもの、という取り違えは縮小画像では判別できない。tools/check-reuse-diff.py で流用元と突き合わせる
• 構成図にbase64で埋め込んだアイコンは、正規表現で抜いてデコードすれば単体の画像として再利用できる
• 話し手の元の図がある図を描き直すときは、元の図を横に並べて寄せる。矢印の太さ、色の濃さ、矢印どうしの間隔まで合わせる。循環を表す矢印は同じ円の一部として描く。ばらばらの曲線では、つながっている感じが出ない。意味が元の図から離れていないかも確かめる

書き出したら検査する

機械検査と目視は、見ているものが違う。両方やる。

bashCopy code
python3 tools/check-figure-text.py deck.pdf          # 16pt未満の文字、箱の縁まで14px未満の文字
node tools/check-svg-box-fit.mjs images/*.svg        # SVGを描画して文字と枠の余白を実測

機械検査は「存在する要素」を測るので、要素が丸ごと描かれなかった崩れは検出できない。図を触ったページは150dpi以上で1ページずつ焼いて見る。見るのは、文字と図形の重なり、矢印の軸、線の合流部、枠の角、文字が箱からはみ出していないか、である。

1つの図を指摘されたら、同じデッキの全図へ同じ検査を当ててから直す。指摘は1つでも、同じ条件に当てはまる図はたいてい複数ある。

報告には、通した検査の名前をそのまま並べる（check-figure-text.py OK、全ページ目視 OK）。「書き出しました」だけでは、通していない検査が見えなくなる。