AI画像の生成と記事への差し込みを別工程に分ける
今回やったこと
画像を生成する処理と、記事へ画像を差し込む処理を分ける設計を整理する。対象は、記事ごとに画像生成を外部の担当へ依頼し、結果を後から記事へ反映するワークフローである。ここで扱うのはデータの受け渡しと工程分割であり、費用や処理時間の削減率を示す実測ではない。
実装ステータス
設計記録あり。素材に含まれる構成を説明するもので、現時点の稼働状態や個別の性能値を断定しない。
画像生成を記事執筆から切り離す
記事の下書きに画像生成を直接組み込むと、生成待ちや失敗が本文作業に影響する。そこで、記事ごとの作業ディレクトリに依頼データを置き、生成と差し込みを別々の処理にする。素材に記録された例では、backend/wp_drafts/{post_id}/ の下に prompts.json と images/ を用意する。
依頼データは、画像ごとの識別子、記事内の挿入位置、英語プロンプト、出力先を持つ。生成側は依頼を読み、header.webp など所定のファイルを出力する。差し込み側は生成物を受け取り、記事へのアップロードと本文への組み込みを担当する。記事の識別子をディレクトリ名に含めることで、異なる下書きの画像が混ざらないようにする設計だ。
backend/wp_drafts/{post_id}/
├── prompts.json # 画像ごとの依頼内容と配置先
└── images/ # 生成側が出力する画像
この構成では、生成担当と記事側の間にファイルを介した受け渡しの境界ができる。生成処理が止まった場合、本文の原稿そのものを巻き戻さずに画像だけを再依頼できる。逆に、画像が揃う前でも記事の下書きや文章レビューを進められる。工程を分ける狙いは、作業の依存関係を減らし、失敗の影響範囲を画像側へ閉じることにある。
受け渡し形式を先に決める
分業を成立させるには、「画像を作ってください」という文章だけでなく、受け渡し条件をデータに含める必要がある。どの画像が必要か、どこへ置くか、記事のどこに使うかが曖昧だと、生成物を後から人手で照合する工程が残る。prompts.json に識別子と配置情報を持たせるのは、その照合作業を減らすための境界設計として読める。
この方式は、生成品質を自動で保証するものではない。プロンプトの妥当性、画像の内容確認、ファイル形式の検査、記事への正しい差し込みはそれぞれ別に必要になる。また、素材には具体的な費用額や処理時間の比較はない。したがって「APIコストを何％削減した」といった定量的な結論は出せない。確認できるのは、生成待ちや再試行を記事本文の作業から切り離すために、依頼と成果物を記事単位で受け渡す設計である。
更新履歴
- 2026-09-26: 初稿を作成。