ブログ記事って、よく考えるとWordで文章を作るのとかなり似ている。
見出しがあって、本文があって、途中に画像を入れていく。
それならChatGPTに文章を書いてもらうだけじゃなく、画像まで入ったWord文書（DOCX）を作って、そのままWordPressへ持っていけたらかなり楽なんじゃないか？と思ったのが始まり。
実際に試してみると、本文・見出し・画像だけじゃなく、スラッグ・カテゴリ・タグ・抜粋などの投稿情報までDOCX側から設定できることが分かった。
SEOについても、AIOSEOの設定を使えばタイトルやメタディスクリプションを投稿ごとに毎回入力しなくても運用できる。
※2026/8/21現在ではすこし手直しや調整が必要なので参考記事として残しています。
試してみると色々な問題も出てきた
もちろん最初からうまくいったわけではない。
- Mammoth
- Seraphinite
- Convert to Blocks
- 画像の空ブロック
- WAFの403
など、試している途中でかなり詰まった。
それでも一つずつ解決していった結果、今ではChatGPTで記事を作る → 画像を用意する → DOCXにまとめる → WordPressへ読み込む → 最終確認して公開するところまで、かなり楽にできるようになった。
ブログ投稿は意外と手作業が多かった
最初はChatGPTで本文を作り、このWordPressの新規投稿画面へ貼り付けていた。文章だけならこれでも十分。ただ、自分のブログは操作画面のスクショを使う記事が多い。画像が10枚近くなると、メディアライブラリから探して順番に入れるだけでも結構な作業になる。
しかも、そのスクショは問題を解決するためにChatGPTへ送った時点ですでに揃っている。それなら会話の中で使った画像も、そのまま記事作成へ流用できた方が無駄がない。ここから「文章だけではなく、画像も含めて投稿直前まで持っていけないか」を試し始めた。
追加プラグインを試してみた
ChatGPTでWord文書を作れると分かってから、本文・見出し・画像位置までまとめたWord文書のDOCXファイルをWordPressへ読み込ませる方向へ切り替えた。最初から今の形にたどり着いたわけではなく、プラグインのMammothを試してからSeraphinite Post .DOCX Sourceへ移っている。
Mammothでは手作業が残った
最初に試したMammoth .docx converterでは、DOCXの本文と画像をWordPressへ取り込めた。
DOCX内の画像がメディアライブラリへ登録されるところまで動いたので、「画像入りDOCXでいけそう」という感触はここでつかめた。
ただ、投稿タイトル欄は空のままで、DOCXのタイトルが本文側へ入るなど投稿情報の手作業が残った。
本文を移す手間は減るけど、自分がやりたかった「投稿直前までまとめて整える」には少し届かなかった。
Seraphiniteへ変更した
次に試したのがSeraphinite Post .DOCX Source。本文だけではなく、WordPressの投稿属性までDOCX側から渡せるので、自分の目的にはこちらの方が合っていた。
投稿画面のDOCX SourceからLocal fileを選び、作成したDOCXを指定してLoadする。
今は最初のHeading 1を投稿タイトルとして使い、Separate Attributeのtitleは使わない。slug・categories・tags・excerpt・featured imageだけを別属性として持たせる形にしている。
つまり設定は何も触っていない。
課金すれば設定が保存されるが無料の範囲だと設定は初期に戻される。
ならこっちから設定に合わせていく方針にした。
SEOタイトルはAIOSEOの全体設定へ任せ、メタディスクリプションは投稿の抜粋を使う。DOCX側でAIOSEOの個別SEO値まで無理に触らない方が、今の自分の環境ではシンプルだった。
DOCX投稿でつまずいたところ
Seraphiniteで読み込めば全部終わり、とはならなかった。実際に使い始めると、ブロック変換・文字サイズ・画像の置き方で細かい問題が出てきた。ここは何度もテスト用DOCXを作って、WordPress側の変換結果を見ながら調整したところ。
Gutenbergのブロック変換
自分の環境では、DOCXを読み込んだ後にClassic形式が残ることがあった。
Classic形式だと文字の編集ができなくてブロックを選択することしかできない。
そこでConvert to Blocksを使い、通常のGutenbergブロックへ変換するようにした。
編集画面を再読込する手間があるが、これで投稿後の修正もしやすくなった。
DOCXの文字サイズ
次に出たのが本文サイズの問題。DOCX側で本文フォントサイズを固定すると、Cocoon側の本文より大きい文字で入ることがあった。
普通に書いた文字のほうが少し大きいのが分かる。
そこで本文フォントサイズ・フォントファミリー・文字色はDOCX側で直接指定せず、WordPressテーマ側のCSSに任せるように変更した。H1・H2・H3は見出しレベルを伝えるためだけに使う。
同じフォント・サイズになっているのがわかる。
画像配置とALTテキスト
画像配置は一番検証回数が多かった。画像を独立段落にすると、Convert to Blocks後に画像下へ空ブロックが出ることがあった。
空ブロックを消したくて、文字と画像を同じ段落に入れる方法も試した。ただ、置き方によっては横並びっぽく崩れたり、段落ブロックの中へ画像が入る形になった。
問題なさそうだがウインドウ幅を変えると
文字 画像 文字
のレイアウトになってしまう。
一時期は「本文 → 段落内改行 → 画像 → 段落内改行 → 本文」というC方式を使っていた。空ブロックはかなり抑えられたけど、後から別の問題が分かった。Convert to Blocks後に画像をクリックしても右側が「画像」ではなく「段落」扱いになり、ALTテキスト欄が出ない。WordPress側から画像の使用状況も追いにくくなる。
こちらも問題なさそうだがブロック上は画像扱いではない。
そのため現在はA方式へ戻した。本文段落 → 画像だけの独立段落 → 次の本文段落、という構造にして、画像の前後へ意図的な空段落は入れない。空ブロックが1個出ることがあっても、公開プレビューで問題がなければ必要に応じて手動削除する。未使用画像を整理するプラグインを使う場合も、標準の画像ブロックとして認識される方が安心だと思っている。
WAFの403をどう回避したか
画像入りDOCXで本番記事を読み込ませた時、もう1つ大きく詰まったのがWAFだった。画像が多い記事だとSeraphiniteの処理中に一部画像が403になり、何枚か抜けることがあった。
画像が多いと403になった
全てではないが複数の画像アップロードがエラーと出ている。
切り分けではロリポップ側のWAFを無効にした時だけ全画像が通った。ただ、ブログを楽に投稿するためにWAFを切ったまま運用するのは避けたい。毎回OFFにして反映を待ち、終わったらONへ戻すのも面倒だった。
メディアライブラリ先行方式へ変更
そこで発想を変えて、DOCXから画像を大量アップロードさせないことにした。まず画像ZIPをChatGPTに用意してもらい、自分でWordPressのメディアライブラリへ画像を一括アップロードする。その後で実ファイル名・実URLを確認し、DOCX側は既存メディアURLを参照する。
ここで大事なのが、URLを推測しないこと。WordPressは同名ファイルがあると「-1」「-2」などを付けることがある。アップロード後の実ファイル名を確認してからDOCXを作るようにしている。
今の半自動投稿フロー
ここまで試した結果、今の投稿フローはかなり固まった。完全自動ではないけど、自分が触るのは画像のアップロードと最後の確認が中心になっている。
- ChatGPTで記事本文と画像を用意する
- 画像ZIPを取得する
- WordPressメディアライブラリへ画像を一括アップロードする
- 実ファイル名・実URLを確認する
- ChatGPTで既存メディアURL参照型DOCXを作る
- Seraphinite Post .DOCX SourceでLoadする
- Convert to Blocksで通常ブロック化する
- タイトル・画像・スラッグ・カテゴリ・タグ・抜粋を最終確認する
- 公開する
「画像入りDOCXを1回読み込めば全部終わり」ではない。でも、記事ごとに同じクリックを何十回も繰り返していた頃とはかなり違う。特にスクショの多いトラブル解決記事では効果が大きい。
ChatGPTをブログ制作で使うコツ
この使い方では、文章生成だけではなくスクショ・PNG・ZIP・DOCXを行き来する。だから自分の場合は、ChatGPTを「記事を書くAI」というより、問題解決から投稿用ファイル作成までまとめる作業環境として使う感覚に近い。
ChatGPT Plusにした理由
自分はこの運用でChatGPT Plusを使っている。無料版でもファイルや画像を扱える機能はあるけど、Plusは無料版よりモデルやツールへのアクセス範囲・利用上限が広い。自分のようにファイルアップロード・分析・画像生成を何度も使いながら1本の記事を仕上げるなら、その余裕が使いやすさにつながっている。
現在のPlusの機能は変わることがあるので、詳しくは OpenAI公式「ChatGPT Plusとは？」 を確認するのが確実。
自分にとっては「AIに記事を量産させるための課金」というより、普段の問題解決で使った素材をそのままブログへ持っていくための作業環境への課金に近い。
指示＝プロンプトの大切さ
投稿方法を半自動化しても、文章が自分のブログと合わなければ結局直すことになる。最初はDOCXの仕様ばかり気にしていたけど、文章の修正に時間がかかるようでは半自動化の意味が薄い。
そこで、実体験ベース・常体寄り・見出しは短め・読点を連発しない・語句の並列は中黒を使う、といった書き方までプロンプト側へ入れた。さらにH2/H3の役割・画像位置・リスト・囲み・WordPress投稿用DOCXの技術ルールも固定した。
最近はH2を大きな章、H3をスマホで文字が続きすぎる時の区切りとして使う形にしている。H3のためだけに画像は増やさず、画像は基本H2直下。ここまで決めておくと、後からWordPressで直す量がかなり減った。
今後の課題
今の形はかなり実用的だけど、まだ100点ではない。特に今回、空ブロックを消すために使っていたC方式をやめて、画像を独立段落にするB方式へ戻した。見た目だけならC方式がきれいでも、WordPress標準の画像ブロックとして扱えずALTテキスト欄も出ないなら、運用上はそちらの方が困る。
今は多少の空ブロックは許容してでも、画像ブロックとして認識されること・ALTテキストを扱えること・WordPress側で画像使用状況を追いやすいことを優先している。画像下に空ブロックが出たら、公開プレビューを確認して必要な時だけ手動で消す。
- 画像は先にメディアライブラリへアップロードする必要がある
- WordPressがファイル名へ「-1」などを付けた場合は実URL確認が必要
- B方式ではブロックエディター上に空ブロックが出る場合がある
- 記事によって画像追加・順番変更が必要になることがある
- 公開前の目視確認は自分で残している
最後の確認を残しているのは、今のところ不満ではない。変な画像・重複文章・見出し崩れまで完全自動で公開される方が怖いので、「最後だけ自分で見る」くらいがちょうどいい。
最後に
完全自動投稿ではない。でも、自分が実際に困ったことをChatGPTへ相談し、そのスクショと会話を記事素材にして、DOCXからWordPressの投稿直前まで持っていく流れはかなり形になった。
今は「AIに記事を書かせる」というより、「自分が解決した内容を、ブログへ投稿できる状態まで整えてもらう」という使い方に近い。画像は先にメディアライブラリへ入れ、WAFはONのまま。DOCXは既存メディアURL参照、画像はB方式の独立段落でALTを持たせる。これが現時点の結論。
まだ手作業は残っているけど、目指していた「記事セットを用意してもらう → WordPressで数回確認 → 投稿」はかなり現実的になった。今後も実際に使いながら、手数が減ったところ・逆に詰まったところがあれば更新していく。
※ブログに特化したAIならすべてAI任せに出来るんだろうけどね・・・
コメント