AI Publisher開発物語第15話｜投稿できても原因が分からない―ログと診断を追加

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

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

この繰り返しで現在の形になりました。第15話では、記事を投稿できる機能だけでは、エラー時にどこで止まったか分かりません。そこで接続テスト、投稿ログ、エラーログ、REST API状態確認を追加しました。

Contents

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

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

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

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

WordPressへ記事を届ける基本機能ができた後、権限不足や接続失敗が起きました。購読者権限のアカウントでは投稿が許可されず、画面上では結果だけが失敗として残りました。

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

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

v2.1.0で、接続テスト、テスト用下書き、投稿ログ、エラーログ、REST APIの状態確認を加えました。

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

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

『動かない』を解決するには、入力、認証、権限、通信、WordPress処理を順番に観察できる必要があると学びました。

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

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

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

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

記事を投稿できる機能だけでは、エラー時にどこで止まったか分かりません。そこで接続テスト、投稿ログ、エラーログ、REST API状態確認を追加しました。

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

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