※この記事は、2026年8月時点の自分のAI・ブログ運用について書いた実運用メモです。
最近は、ブログの下書きだけでなく、公開直前の準備までAIに手伝ってもらっています。
投稿用の最終版。 WordPressへ貼り付けるHTML。 スラッグ、カテゴリー、タグ。 メタディスクリプションと抜粋。 関連記事。 公開前の確認メモ。
ここまで一式そろった状態を、自分の中では「UP版」と呼んでいます。
以前は本文の下書きができた後に、投稿設定や関連記事を一つずつ考えていました。 今はUP版までAIに作ってもらえるので、公開前の作業はかなり軽くなりました。
ただ、運用を続けるうちに別の問題が出てきました。
UP版が完成したことと、WordPressで公開されたことが混ざりやすい。
当たり前と言えば当たり前の話です。
それでも、投稿用ファイルがきれいにそろい、AIから「公開OKです」と返ってくると、作業が終わったように見えてしまいます。
実際には、まだWordPressへ貼り付けていない。 あるいは、貼り付けたかもしれないが、公開URLを確認できていない。
そんな記事が残るようになりました。
今回は、AIにブログ運用を手伝ってもらう時、文章の完成と外部サービス上の公開をどう分けるか整理しておきます。
UP版が完成しても、WordPressでは何も起きていない
今の自分の運用では、AIがUP版を作ると複数のファイルができます。
本文の最終版。 WordPress貼り付け用HTML。 投稿設定をまとめたメモ。 関連記事をまとめたメモ。
必要なものは、だいたいそろっています。
AI側から見れば、頼まれたローカル作業は完了しています。
しかし、その時点ではWordPress側で何かが変わったわけではありません。
自分がHTMLを貼り付ける。 カテゴリーやタグを設定する。 公開ボタンを押す。 公開されたページを開く。
この外部操作が残っています。
つまり、UP版完成は「公開できる材料がそろった状態」であって、「公開された状態」ではありません。
ここを同じ完了として記録すると、あとで一覧を見た時に分からなくなります。
この記事はまだ貼っていないのか。 すでに公開したのか。 公開したが、記録だけ更新していないのか。
ファイルがあるだけでは判断できません。
「公開OK」と「公開済み」は別の情報だった
混乱しやすかった理由の一つは、「公開」という言葉を複数の意味で使っていたことです。
たとえば、公開前チェックを通過した記事には、
「公開OK」
と書くことがあります。
これは、本文の内容や公開範囲、WordPress用の形式を確認した結果です。
ブログの本線に合っているか。 privateな情報が入っていないか。 見出しやタグの形式は整っているか。 関連記事のリンクは確認できているか。
こうした条件を通過したので、投稿して問題ないという意味です。
一方の「公開済み」は、WordPress上で実際にページが公開されたという事実です。
公開OKは品質の判定。 公開済みは外部で起きた状態。
この二つは似ていますが、まったく同じではありません。
公開OKでも、投稿していなければ未公開です。 投稿操作をしたつもりでも、公開URLを確認できなければ状態はまだ曖昧です。
AIに確認を頼む時も、ここを分けないと、ローカルファイルを見ただけで公開済みのように整理される可能性があります。
ブログ記事の状態を4段階に分けたい
そこで、今後はブログ記事の状態を少なくとも四つに分けた方がよさそうだと考えています。
1. 下書きがある
本文の方向性を確認する段階です。
タイトルと記事の核はある。 ただし、表現や事実確認、関連記事、WordPress用の設定はまだそろっていない。
この段階では、記事の内容そのものを直します。
2. UP版一式がそろった
本文を最終版へ整え、WordPress用HTMLや投稿設定まで用意した段階です。
自分の運用で言えば、AIへ「UP版お願いします」と頼んだ後の状態です。
ここでは、公開できる準備は整っています。
ただし、まだWordPressへ反映したとは限りません。
最近は、この状態を up_package_ready として残すようにしています。
3. WordPressへ反映した
本文や投稿設定をWordPressへ入れた段階です。
ただし、下書き保存なのか、予約投稿なのか、公開ボタンまで押したのかで状態はさらに変わります。
少なくとも、ローカルでUP版を作っただけの状態とは分けておきたいところです。
4. 公開URLを確認した
実際の公開ページを開き、URLと表示を確認した段階です。
記事タイトルが合っているか。 見出しが崩れていないか。 関連記事がリンクになっているか。 公開ページへ到達できるか。
ここまで確認できて、ようやく「公開済み」として扱えます。
厳密には、公開後にも修正やキャッシュ確認はあります。
それでも、UP版完成と公開確認の間に段階を置くだけで、かなり分かりやすくなるはずです。
完了は、成果物の名前ではなく証拠で決めたい
今回ややこしかったのは、投稿用の最終ファイルに published という名前を使っていたことも関係しています。
この名前は、「公開用として整えた最終版」という意味で使っていました。
ただ、後からファイル一覧だけを見ると、「もう公開した記事」にも見えます。
AIにとっても、人間にとっても少し紛らわしい名前でした。
とはいえ、過去のファイル名を全部変えれば解決するとも思っていません。
大事なのは、名前だけで状態を決めないことです。
UP版一式がある。 WordPressへ反映した記録がある。 公開URLがある。 そのURLへ到達できる。
状態を進める時は、その段階に合った証拠を見る。
ローカルファイルがあるなら、UP版準備完了。 WordPress上の公開URLを確認できたなら、公開済み。
このように分けた方が、あとからAIへ整理を頼んだ時にも誤解が減りそうです。
AIには、実行していない外部操作を完了扱いさせない
今のところ、WordPressへの貼り付けと公開は自分で行っています。
AIに任せているのは、公開できる状態まで材料をそろえるところです。
この境界があるなら、AI側の完了報告も、
「UP版を作成しました」
で止める必要があります。
「公開しました」とは言わない。
次に人間が行うこととして、
「WordPressへ貼り付ける」 「公開後のURLを確認する」
を残す。
将来、WordPressへの反映まで自動化する可能性はあります。
ただ、その場合でも考え方は同じです。
APIへ送信したことと、公開ページが正常に表示されたことは別です。
操作を実行しただけで完了にせず、外部で期待した状態になった証拠まで確認する。
AIエージェントに作業を任せるほど、この区別は重要になりそうです。
ブログ以外でも同じことが起こりそう
今回の例はブログですが、この状態のズレは他のAI作業でも起きます。
メールの文面を作ったことと、送信したこと。 申請書を作ったことと、提出したこと。 コードを修正したことと、本番環境へ反映したこと。 共有資料を作ったことと、相手へ共有したこと。
AIが成果物を作るところまで速くなると、つい全体も終わったように感じます。
でも、成果物の完成と、外部世界で状態が変わることは別です。
特に、送信、公開、購入、削除、申請のような操作は、勝手に完了扱いされると困ります。
AIには準備を任せる。 外部操作は人間が行う。 あるいは自動化する場合でも、実行結果を確認する。
どの境界にするにしても、状態を分けておく必要があります。
まだ過去分の状態照合は終わっていない
この問題に気づいたからといって、すでに全部きれいに整理できたわけではありません。
現在も、UP版までは作ってある記事と、WordPress側の公開状態を確認する必要がある過去記事が残っています。
最近のメモでは、UP版一式ができた状態を up_package_ready と書き始めました。
ただし、過去の記録まで統一できたわけではありません。
まずは、今後の新しい記事で状態を混ぜない。 その上で、過去分はWordPress側の公開一覧と照合する。
今はその段階です。
状態名を考えただけで問題が解決した、という記事ではありません。
それでも、「なぜ一覧を見ても公開済みか分からなかったのか」は、かなりはっきりしました。
準備完了と公開完了を、同じ言葉で扱っていたからです。
まとめ
AIにブログのUP版を作ってもらうと、公開前の作業はかなり軽くなります。
ただし、UP版が完成したことと、WordPressで公開されたことは別です。
下書きがある。 UP版一式がそろった。 WordPressへ反映した。 公開URLを確認した。
少なくとも、この四段階は分けて持ちたいと思っています。
「公開OK」は品質の判定です。 「公開済み」は外部で起きた事実です。
AIが実行していない操作を完了扱いせず、人間が次に何をするか残す。
そして、外部操作まで任せる場合は、実行したことではなく、期待した状態になった証拠まで確認する。
ブログ運用の小さな話ですが、AIエージェントへ仕事を任せる時の完了条件として、かなり大事な違いだった気がします。
コメント