※WordPressやテーマ全体の仕様解説ではなく、自分のブログ運用で起きた小さな失敗から考えたことです。
最近、AIにブログ下書きを作ってもらう流れが少しずつ安定してきました。
ネタ出しをする。
下書きを作る。
公開前にタイトル、スラッグ、タグ、メタディスクリプション、関連記事を確認する。
このあたりまでは、かなりAIに手伝ってもらえるようになってきました。
ただ、そこでひとつ小さな事故が起きました。
記事そのものはできていたのに、WordPressに貼ったら目次が出なかったんです。
最初はCocoonの設定か、キャッシュか、記事側の何かかと思いました。
でも確認してみると、原因はもっと単純でした。
下書きの見出しに使っていた ## が、WordPress上で見出しブロックに変換されず、そのまま本文の文字として貼り付いていたんです。
つまり、AIが作った文章は一見ちゃんと完成していた。
でも、公開環境でそのまま使える形式にはなっていなかった。
今回は、この話を残しておきます。
AIの下書きは、完成品に見えやすい
AIにブログの下書きを作ってもらうと、かなり完成品っぽく見えます。
タイトルがある。
導入文がある。
見出しがある。
本文がある。
まとめがある。
関連記事もある。
ぱっと見た時点では、もう公開できそうに見える。
実際、自分も最近はこの流れにかなり助けられています。
何もないところから書くより、会話で出た内容をAIに整理してもらった方が、記事の芯が見つかりやすい。
特に、ObsidianやCodexまわりの実運用メモは、会話しながら少しずつ角度を調整した方が記事になりやすいと感じています。
ただ、ここで油断しやすいです。
文章として完成していることと、WordPressでそのまま使えることは別でした。
問題は文章ではなく、貼り付け形式だった
今回の問題は、本文の内容ではありませんでした。
見出しの数も足りていた。
構成もおかしくなかった。
記事としての流れも問題なかった。
でも、WordPressに貼った本文では、見出しの行がH2見出しとして認識されていませんでした。
下書きでは、
## Obsidianをきれいな本棚にしようとすると、たぶん止まる
という形になっていました。
Markdownとして見れば、これはH2見出しです。
でも、WordPress側でそれが見出しブロックにならず、本文上に ## として残ってしまった。
その結果、Cocoonの目次にも拾われませんでした。
これは地味ですが、かなり大事な失敗でした。
自分は「下書きができた」と思っていたけれど、実際には「Markdownとしての下書き」ができていただけだったんです。
WordPressに貼って公開するなら、WordPressで読める形にするところまで必要でした。
AIに頼む時は、どこまでを成果物にするかを決めないとズレる
ここで思ったのは、AIに頼む時の成果物の範囲です。
「ブログ記事を書いて」と頼むと、AIは文章を書いてくれます。
でも、自分が本当に欲しいものは、ただの文章ではありません。
WordPressに貼れる本文。
目次に拾われる見出し。
メタディスクリプション。
スラッグ。
タグ。
関連記事。
必要ならInstagram用の文面。
そこまで揃って、ようやく自分の作業では「公開直前セット」になります。
以前から、AIにブログ記事を見てもらうなら、下書きだけでなく公開直前セットまで作る方が楽だと感じていました。
今回の件は、その延長にあります。
下書きだけでは足りない。
公開する場所に合わせた形式まで、AIに指定する必要がある。
ここを曖昧にすると、AIは悪くないのに、最後の貼り付けで詰まります。
Markdownで作るなら、Markdownのまま貼れるとは限らない
Markdownは便利です。
自分もCodexやObsidianでは、Markdown形式の方が扱いやすいです。
見出しは ##。
箇条書きは -。
メモとしても残しやすい。
あとから検索もしやすい。
AIに渡す時も、Markdownはかなり相性がいいです。
ただ、WordPressに貼る時は別です。
環境や貼り付け方によっては、Markdownが自動でブロックに変換されないことがあります。
そうなると、## は見出しではなく、ただの文字になります。
これを見落とすと、本文には見出しっぽいものがあるのに、実際のHTML上では見出しになっていない状態になります。
人間の目には見出しに見えても、テーマや目次機能からは見出しとして扱われない。
今回、まさにそれでした。
これからはWordPress貼り付け用HTML版も作る
今回の対策として、WordPress貼り付け用のHTML版も作ることにしました。
Markdown版の下書きとは別に、WordPress本文欄へ貼るための版を作る。
具体的には、見出しをこういう形にします。
<h2 class="wp-block-heading">見出し</h2>
さらにWordPressのブロックコメントも入れて、段落やリストも貼り付けやすい形にする。
これなら、少なくとも ## が本文に残る事故は減らせます。
もちろん、毎回HTMLを手で書くつもりはありません。
Codex側で、Markdownの下書きからWordPress貼り付け用HTMLを作るようにすればいい。
今回も実際に、その形のファイルを作りました。
ここで大事なのは、AIに文章だけを求めるのではなく、
「どこに貼るのか」
「何の形式で必要なのか」
「公開時に何が壊れると困るのか」
まで含めて頼むことだと思います。
AIの仕事は、文章作成から公開作業の手前まで広げられる
AIにブログを書かせるというと、どうしても本文作成の話になりやすいです。
でも、実際に運用していると、本文よりも周辺作業で止まることが多いです。
タイトルをどうするか。
関連記事をどう並べるか。
スラッグをどうするか。
メタディスクリプションをどうするか。
WordPressに貼った時に見出しとして認識されるか。
こういう細かいところで、意外と時間を取られます。
そして、こういう部分こそAIに任せやすいのかもしれません。
ただし、任せ方を間違えると、今回のように「文章はできているのに、公開形式で壊れる」ということが起きます。
だから最近は、AIに頼む単位を少し変えたいと思っています。
「記事を書いて」ではなく、
「WordPressに貼れる形の本文まで作って」
にする。
「下書きを作って」ではなく、
「公開直前で確認する項目まで揃えて」
にする。
この違いは小さいようで、実運用ではかなり大きいです。
まとめ
今回、WordPressで目次が出ない原因を確認してみたら、見出しの ## が本文にそのまま残っていたことが分かりました。
記事の内容が悪かったわけではありません。
AIの下書きも、Markdownとしてはちゃんとできていました。
ただ、WordPressに貼って公開するための形式にはなっていなかった。
ここが抜けていました。
AIにブログを手伝ってもらうなら、文章の完成度だけを見るのではなく、その文章が実際に使う場所でちゃんと機能するかまで確認する必要がある。
そして、できるならそこまでAIに頼んだ方がいい。
今回の件で、下書き、公開直前セット、WordPress貼り付け用HTMLまでをひとつの流れとして考えた方が楽だと感じました。
AIに任せるなら、文章だけではなく、使える形式まで。
小さな失敗でしたが、ブログ運用ではかなり大事な気づきでした。
関連記事
ObsidianをAIに整理してもらうなら、「整理して」で動くルールを作るのが一番効いた
AIにブログ記事を見てもらうなら、下書きだけでなく公開直前セットまで作る方が楽だった
コメント