AI Publisher開発物語第18話｜自動化しても「画像を反映」ボタンを残した理由

AI Publisherは、完成した設計図どおりに作ったプラグインではありません。

実際に使う。問題が出る。原因を調べる。修正する。そして、もう一度使う。

この繰り返しで現在の形になりました。第18話では、画像の自動反映を一括処理へ組み込んでも、失敗時に人間が復旧できる「画像を反映」ボタンを残すことにしました。

Contents

前回までにできていたこと

Google Driveに保存した記事を取得し、WordPressへ投稿する基本の流れは少しずつ形になっていました。

最初は「記事を投稿できた」という結果だけでも大きな前進でした。しかし、実際の運用では、成功したときより失敗したときに仕組みの不足が見えます。

AI Publisherの開発では、動いた画面を完成とせず、次の記事、複数記事、大量記事でも同じように使えるかを試しました。

一括取り込みした記事に画像が反映されませんでした。しかし記事001で手動ボタンを押すと、本文画像8枚とアイキャッチは正常に設定されました。

この時点で、最初から現在の完成形を想像できていたわけではありません。目の前の問題を解決するため、まず正常に動いている範囲と、止まっている工程を分けました。

エラーの表示だけで原因を決めず、成功した事実を手がかりにしました。ある処理が正常なら、その手前までの接続やデータ取得は成立している可能性が高いからです。

画像取得や配置処理は正常で、一括取り込みから画像処理への連動に問題があると切り分けました。自動連動を修正しつつ、手動ボタンは復旧機能として残しました。

修正後は、画面上の成功表示だけでなく、WordPressの投稿本文、画像、アイキャッチ、メタ情報など実際のデータを開いて確認しました。

一つの問題を直すと、新しい記事数や使い方に耐えられるようになります。そして運用範囲が広がることで、以前は存在しなかった次の問題が見えるようになります。

完全自動化を目指して手動操作を消すと、一つの連携エラーで運用が止まります。非常口を残すことも自動化設計の一部です。

AIとの開発では、要望を一度伝えれば完成するわけではありません。人間が実際の画面と結果を確認し、「どこまで正常か」「何が期待と違うか」を具体的に返す必要があります。

ChatGPTはコードや修正案を考えられますが、実際のWordPressで何が起きたかを確認し、完成条件を決めるのは人間の役割です。

今回の改善は、一つのエラーを消しただけではありません。

こうした考え方が、次のバージョンや機能へ引き継がれました。

画像の自動反映を一括処理へ組み込んでも、失敗時に人間が復旧できる「画像を反映」ボタンを残すことにしました。

完成品を最初から設計できたわけではありません。実際に使い、問題を見つけ、原因を調べ、修正し、また実際に使う。その結果、記事数が増え、それまで見えなかった問題が現れ、さらに改善しています。

AI Publisherのv2.0.0からv2.5.2までの全体像は、関連記事「AI Publisher開発の歴史｜v2.0.0からv2.5.2まで、失敗と改善を繰り返した記録」で紹介しています。