はじめに
サムネイル作成がめんどくさい。そう思ったことはないだろうか？ 私はめんどくさいと思っている。そしてその作業に時間をかけたくない。もっというと自分の時間は別の事に使いたい。
そう思ってサムネイル作成のワークフローを構築した。
記事分析：詳しくやる 画像生成：圧縮して渡す 文字入れ：あとから人間が調整する
この記事では、そのワークフローをまとめる。
完成イメージ
目指す状態はこうである。
記事本文を読む ↓ 記事の中心メッセージを一文に圧縮する ↓ 左・中央・右の3要素に分ける ↓ 画像生成AIで背景構図を作る ↓ CanvaやFigmaで日本語タイトルを後入れする ↓ 小さく表示しても意味が分かるか確認する
サムネイルに記事内容を全部入れない。
入れるのは、基本的に次の3つだけでよい。
1. 問題または入力 2. 解決構造 3. 得られる結果
たとえば、ObsidianのProject管理記事なら、
左：Project別タスク入力 中央：自動生成処理 右：Dashboard / Gantt / Kanban
という構図にする。
実際に作成したのはこれである。
なぜこのワークフローを作成したか
初めは記事を分析してサムネイルをそのまま出させるといったことを試した。しかしながらそれだとそもそも安定しない。
またCanvaで作成させることもさせたが、この段階でも分析・構成をしてもあまりにも変になるというか、そもそもオブジェクトの塊がおかしくなる。修正案を出させてもそれを反映するのが凄い大変である。だったら人の手でやったほうがいい。
サムネイル君をつくろうとして、せっかくだからAIにTool持たせてやらせようとした結果、うおおおおおおおこれはゴミ！！！！！！っていうのしかでてこない
— しゅらいぬ (@syurainu) 2026年6月19日
その時の嘆きである。変なのできた。
普通にはてなの機能使った方がいいです
— しゅらいぬ (@syurainu) 2026年6月19日
作成する時に変なのをのせるぐらいならはてなの標準機能使った方がいい。
で、一日たってこう考えた。
「分析データからサムネイルを作成する方針とそれを元にワークフロー構築をさせ、それぞれを個別の指令にして.zipにまとめて、そこから作成すればいい」
で、それを行った。初めは情報がかなり多くなり、なんだかポンチ絵みたいなった。多分解説とかだと使える。
そこで以下の考えに変えた。
でやりとりをしてまとめさせ、いかに変更をした。
正確さより視認性 情報量より構図 説明より印象 詳細よりクリック理由
記事本文で説明できるものは、本文に戻す。 サムネイルには、クリック前に伝えるべき最小単位だけを残す。
全体構成
改善版ワークフローは次の通り。
flowchart TD
A[記事本文を読む] --> B[記事情報を抽出]
B --> C[記事を一文に圧縮]
C --> D[中心メッセージを1つ決める]
D --> E[左・中央・右の3要素を選ぶ]
E --> F{構図タイプを選ぶ}
F -->|変換型| G[左: 入力 / 中央: 処理 / 右: 出力]
F -->|分離型| H[左: 人間用 / 中央: 境界 / 右: System側]
F -->|Before After型| I[左: Before / 右: After]
G --> J[圧縮プロンプトを作成]
H --> J
I --> J
J --> K[AIで背景画像を生成]
K --> L[CanvaまたはFigmaで文字を後入れ]
L --> M[縮小表示で確認]
M -->|NG| E
M -->|OK| N[完成]
この流れにすると、毎回サムネイルをゼロから考えなくてよくなる。
記事情報を抽出する
まず、記事から以下を抜き出す。
記事タイトル： 記事の主題： 読者の悩み： 記事で解決すること： 読んだ後の状態： 重要キーワード：
ここで大事なのは、いきなり画像生成プロンプトを書かないこと。
先に、記事の構造を理解する。 ただし、理解した情報を全部サムネイルへ入れるわけではない。
記事を一文に圧縮する
次に、記事を一文にする。
使う型はこれ。
この記事は、【読者の悩み】を【方法】によって【結果】に変える記事である。
例として、Project管理記事ならこうなる。
この記事は、Project管理が散らばる問題を、Project別タスク入力と自動生成処理によって、Dashboard・Gantt・Kanbanで見える状態に変える記事である。
この一文が、サムネイルの中心になる。
中心メッセージを1つに絞る
サムネイルで伝えることは1つにする。
悪い例。
人間用画面とSystem側データを分けて、Project Recordを正本にして、Task Indexを生成して、DashboardとGanttとKanbanを作る
これは正確だが、サムネイルには長すぎる。
良い例。
Project管理を自動生成する
または、
入力はタスクと日付だけ
このくらいまで削る。
構図タイプを選ぶ
記事タイプごとに、使いやすい構図を決めておく。
変換型
入力から出力が生まれる記事に使う。
左：入力 中央：処理 右：出力
例。
Project別タスク入力 ↓ 自動生成処理 ↓ Dashboard / Gantt / Kanban
分離型
人間用とSystem側、安全領域と公開領域などを分ける記事に使う。
左：人間用 中央：境界・ゲート 右：System側
例。
人間用Project画面 ↓ 分離ゲート ↓ System側データ
Before / After型
改善記事やエラー解決記事に使う。
左：Before 右：After
例。
混乱したタスク管理 ↓ 整理されたDashboard
画像生成用プロンプトを作る
画像生成AIに渡すのは、詳細分析ではなく圧縮版だけにする。
たとえば、Project管理記事なら次のようにする。
Create a 4:3 technical blog thumbnail. Theme: In Obsidian project management, the user only writes task text and schedule dates, while the system automatically generates structured views such as dashboard, Gantt, and Kanban. Composition: Use a simple left-to-right transformation layout. Left: Show a human-friendly dark note panel with a few large task checkboxes and date fields. This side should feel simple and editable. Center: Show a clean automation engine or script gateway with arrows. It should communicate conversion from light human input into structured project data. Right: Show polished output views: a dashboard card, a Mermaid Gantt-like timeline, and a Kanban board with clear columns. This side should feel organized and automatically generated. Text: Main headline: "Project管理を自動生成" Subheadline: "入力はタスクと日付だけ" Small label: "Obsidian" Style: Dark technical blog thumbnail, navy and black-purple background, purple and cyan accents, pale green success accents, minimal UI, strong empty space. Constraints: No real screenshots, no logos, no dense infographic, no tiny text, no YAML or code blocks.
ポイントは、細かいファイル名やコードを入れないこと。
入れないもの： - 長い説明文 - 小さいUI文字 - YAML全文 - JSONLの中身 - コード全文 - ファイル一覧
文字は後から入れる
画像生成AIに日本語タイトルまで任せると、文字が崩れることがある。
そのため、基本はこうする。
AI：背景と構図を作る Canva / Figma：日本語タイトルを後入れする
文字量は以下に制限する。
メイン見出し：1行 サブ見出し：1行 補助ラベル：最大3個
例。
Project管理を自動生成 入力はタスクと日付だけ
これ以上は入れない。
実行結果
このワークフローを使うと、サムネイルは次のように変わる。
Before。
記事の情報を全部入れようとする ↓ 小さい文字が増える ↓ 図解資料のようになる ↓ 初見で分かりにくい
After。
記事を一文に圧縮する ↓ 左・中央・右の3要素だけ残す ↓ 背景はAIで作る ↓ 文字は後から整える ↓ 小さく見ても意味が伝わる
詰まったところ
文字を減らせない
最初に詰まったのは、文字を減らせないことだった。
記事内容を削ると、正確ではなくなる気がする。 しかし、サムネイルにすべて入れる必要はない。
詳細は本文で説明できる。 サムネイルは、何の記事か一瞬で分かればよい。
図解資料っぽくなる
もう一つの問題は、構造を正確に描こうとすると、図解資料になること。
これは、画像生成プロンプトに詳細を入れすぎると起きる。
対処は、画像生成用プロンプトを圧縮すること。
詳細分析：記事理解用 圧縮プロンプト：画像生成用
この2つを分ける。
日本語文字が崩れる
画像生成AIに日本語文字を任せると、文字が崩れる場合がある。 そのため崩れた場合は無くした方がいい。
Before / After
Before。
記事タイトルをそのまま画像化する 記事内容を全部詰め込む 小さい文字が増える サムネイルというより説明図になる
After。
記事を一文に圧縮する 3要素だけ残す 背景はAIで生成する 文字は後入れする 縮小表示で確認する
この形にすると、記事ごとのサムネイル品質が安定する。
これらを.zipでまとめる
フローを構築するためには記事など分析する対象が必要であるが、それを分析→テーマと伝えたい事を選定→デザインのルールに落とし込む→工程を順番に選定し、プロンプトに落とし込んで指示書とした後はまとめて以下のようにするだけである。
今回のは自分のブログのURLである。
これで大体同じ事ができる。
Geminiの場合は少し仕様が違う。
こちらのほうはGoogle NotebookKLMにファイルをソースとして入れた方がいい。理由としては以下の通りである。
- Google Driveのフォルダであると並列にファイルを読み取るため、指示が全て読み取るとは限らない。
- そのためワークフローの工程が守られない。
- 特定のソース（ファイル）の内容を前提知識として共有するのがGoogle NotebookLMなので、ソースの内容を完全に把握した状態になるため、こうした複数のワーフフローの場合はこちらが良い。
そうした事から、Google NotebookKLMを進める。
まとめ
改善版サムネイルワークフローの核心は、記事分析をやめることではない。
むしろ、記事分析はしっかりやる。
ただし、その詳細を画像生成にそのまま渡さない。
分析は詳細に 画像は圧縮して 背景はAIで 文字は後編集で
とはいえ改善はもっといる。実際にはもっと削れる部分がある。
