AI Publisher開発物語第17話｜130記事を扱えたから管理画面を作り直すことになった

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

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

この繰り返しで現在の形になりました。第17話では、記事を130本以上扱えるようになった結果、130本を探し、絞り込み、処理するための管理画面が必要になりました。

Contents

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

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

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

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

記事投稿欄に130件以上が縦に並び、下書き公開管理などの機能までスクロールするのが大変になりました。一括取り込みでは133記事を走査して取り込み済みか判定していました。

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

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

v2.5.2では未取り込み件数、1ページ20件程度のページネーション、記事番号・タイトル検索、状態絞り込み、新着順、機能別タブを設計しました。

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

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

機能が動くことと、毎日使いやすいことは別です。データ量が増えると、それまで見えなかった操作上の問題が現れます。

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

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

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

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

記事を130本以上扱えるようになった結果、130本を探し、絞り込み、処理するための管理画面が必要になりました。

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

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