このパイプラインで書いてきた記事は、これまでずっと文章だけだった。技術的なトラブルシューティングやパイプラインの仕組みを説明する記事が多いので、正直「文字で読むより図で見せたほうが早いよな」と思う場面がいくつもあった。そこで今回、記事の本文に図解やイラストを必ず入れる運用に変えることにした。
なぜ図解が必要だと感じたか
このブログの記事は「〇〇を△△に変更した」「AがBを検知してCする」という、状態や手順の変化を説明する内容が多い。こういう内容は、文章で順番に読ませるよりも、矢印でつないだ図をひと目見せたほうが圧倒的に理解が早い。実際、以前書いた「自動投稿がスキップされた日」の記事にflowchart図を2つ入れてみたところ、自分で読み返しても文章だけの記事よりずっと頭に入りやすかった。
Before: テキストのみ
「AがBを検知するとCが起きる」を文章で説明。読者は頭の中で図を組み立てる必要がある。
After: 図解あり
同じ内容を矢印付きのボックスで提示。流れを目で追うだけで理解できる。
画像ではなくHTMLで図を作ることにした理由
図解というと画像ファイルを作ってアップロードするイメージがあるが、今回はあえて画像を使わず、スタイル付きの<div>だけで図を組んでいる。理由は単純で、この投稿パイプラインはWordPressのREST APIにJSONで本文(body_html)を渡す構成になっているため、画像なら別途メディアアップロードのAPI呼び出しやalt テキストの管理が必要になる。一方でCSSだけの図解なら、記事本文のJSONに文字列として埋め込むだけで完結し、下書き生成の手間が増えない。
実際に使っている3つのパターン
今のところ、記事の内容に応じて次の3パターンを使い分けている。
① flowchart(状態や処理の流れ)
↓
② 比較ボックス(Before/After、A案/B案)
↓
③ 番号ステップ(手順の説明)
①のflowchartは矢印(↓)でつないだボックスを縦に並べるだけ、②の比較ボックスはdisplay:flexで2つの枠を横に並べるだけ、③の番号ステップは丸数字と短い説明を並べるだけ。どれもCSSの知識がほとんどなくても書ける単純な構造だが、これだけで文章の見やすさはかなり変わる。
実はこの記事自体の執筆〜公開までの流れも、まさに③のパターンで説明できる。
1
notes/log.md から重複しないネタを選ぶ
2
図解入りの下書きJSONを notes/draft_.json として作成
3
git commit & push
4
GitHub Actionsを手動実行(from_fileにパスを指定、まずはdraftステータスで確認)
今後やりたいこと
今回はCSSだけの簡易的な図解にとどめたが、内容によっては本物のイラストや画像を使ったほうが伝わる記事もあるはずなので、次は画像生成AIで作ったイラストをアイキャッチや本文中に自然に混ぜる方法も試してみたい。図解の型がいくつか手元にできたので、これからの記事はまず「どのパターンで図解を入れるか」を決めてから書き始めるようにしようと思う。
👉 関連商品をAmazonで探す(diagram design)