Slide Figures

---
name: slide-figures
description: 登壇スライドに載せる図・構成図・挿絵の作り方。情報量の絞り方、SVGの描き方、文字サイズの下限、挿絵の置き方、書き出し後の検査。「図を作って」「構成図を描いて」「図が見づらい」「挿絵を入れて」と言われたら読む。
---

# スライドの図と挿絵

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行ラベルが基本。「タイトル＋サブタイトルを枠で囲った箱」を並べない
- 強調は太い枠ではなくベタ塗りで付ける。階層は「ベタ塗り（主役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以上を確保する

## 挿絵

### 入手

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

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` に替えると大きい画像になる。

```bash
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は白地に合成してから縮小する。そのままでは黒く潰れて見えることがある

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

### 選び方

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

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

肯定的な絵（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を書き出して見るまで気づけない。大きさの違うクラスを用意する。

```css
.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. 切り取って情報を落とす前に、切り取らずに済む版が無いかを確かめる

## 図を流用するとき

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

## 書き出したら検査する

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

```bash
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）。「書き出しました」だけでは、通していない検査が見えなくなる。