AI Publisher開発の歴史｜v2.0.0からv2.5.2まで、失敗と改善を繰り返した記録
AI Publisherは、Google Driveに保存した記事と画像を読み込み、WordPressへ下書きや公開記事として投稿するために作ったプラグインです。
今では記事本文だけでなく、画像、アイキャッチ、カテゴリー、タグ、スラッグ、SEO情報まで扱えるようになりました。しかし、最初から現在の形を設計できていたわけではありません。
実際に使う。問題が出る。原因を調べる。修正する。そして、もう一度使う。
この繰り返しの中でAI Publisherは育ってきました。この記事では、Google Driveに残っている既存記事や開発資料、そして実際の開発記録から確認できた範囲に限定し、v2.0.0からv2.5.2までの歩みを振り返ります。
なお、資料で変更内容を確認できないバージョンについては、推測せずに「確認できない」と記載します。
AI Publisherは完成形を設計してから作ったものではない
AI Publisherを作り始めた理由は、記事作成後の作業を減らしたかったからです。
AIに記事を書いてもらっても、WordPressへ移す作業は残ります。タイトルを入力し、見出しを整え、画像をアップロードし、アイキャッチを設定する。カテゴリーやタグ、SEO情報も一つずつ登録しなければなりません。
記事が数本なら手作業でも対応できます。しかし、記事数が増えると、同じ作業を何度も繰り返すことになります。そこで、Google Driveに置いた記事をWordPressへ自動で届ける仕組みを作ろうと考えました。
ただし、必要な機能を最初からすべて見通せていたわけではありません。WordPressへ投稿できたら終わりだと思っていた時期もあります。ところが実際に使うと、権限エラー、画像の崩れ、通信のタイムアウト、SEO情報のずれなど、次々と新しい問題が見つかりました。
AI Publisherの歴史は、完成した設計図を順番に実装した記録ではなく、現場で見つかった問題を一つずつ解決した記録です。
正式な開発本線はv2.0.0から始まった
現在確認できる開発本線の出発点はv2.0.0です。
このバージョンでは、WordPressへ記事を投稿するための基本エンジンを作りました。REST APIを使った投稿、メディアの登録、アイキャッチの設定、カテゴリー、タグ、スラッグの反映など、プラグインの土台になる機能です。
まずは「WordPressへ記事を届けられること」を形にしたバージョンでした。
資料の中にはv1.0.0という表記も残っています。ただし、v2.0.0を正式な開発の出発点として承認した記録と時系列が一致せず、Google Drive内の資料だけでは両者の関係を確定できません。そのため、この記事では推測でv1.0.0を開発本線に組み込まず、確認できるv2.0.0以降を扱います。
最初の一歩は、完璧な自動化ではありませんでした。それでも、記事投稿を機械に任せられる可能性が見えたことは大きな前進でした。
WordPressへ投稿できても、実運用には耐えなかった
v2.1.0では、接続テスト、テスト用下書き、投稿ログ、エラーログ、REST APIの状態確認などが加わりました。
記事を投稿する機能があっても、失敗した理由が分からなければ運用できません。実際の開発では、購読者権限のアカウントを使っていたため、WordPressへの投稿が許可されない問題も起きました。
この経験から、投稿機能だけでなく「どこで失敗したのかを確認できる機能」が必要だと分かりました。
正常に動いたときだけを考えて作るのではなく、接続できない、権限が足りない、認証に失敗するといった状況を管理画面で確認できるようにする。ここからAI Publisherは、試作品ではなく運用するための道具へ変わり始めました。
Google Drive連携と記事・画像取得を実装したv2.2系
v2.2系では、Google DriveとWordPressをつなぐ仕組みが具体化しました。
確認できるv2.2.1では、記事番号をもとにGoogle Drive内の記事と画像を探し、WordPressの下書きまたは公開記事として登録する流れを実装しました。Google Apps Scriptも利用し、Google Drive側とWordPress側の役割を分けています。
続くv2.2.2では、Google OAuthによる接続と解除、アクセストークンの自動更新、Drive APIを使ったフォルダ確認、設定情報の保護、ログなどが加わりました。
ここで、Google Driveを記事作成の共有拠点にする現在の形が見え始めます。ChatGPTが記事を作り、人間が内容を確認し、AI PublisherがWordPressへ運ぶという役割分担です。
一方で、v2.2.0やv2.2.3からv2.3.1までについては、現時点の資料から具体的な変更内容を確認できません。バージョン番号の間を想像で埋めることはせず、履歴が残っている範囲だけを記録します。
記事構造・画像・SEOを整えたv2.3系
Google Driveから記事を取得できても、そのままWordPressへ入れるだけでは読みやすい記事になりませんでした。
v2.3.2では、本文中の記号を見出しへ変換する仕組みを整えました。「■」をH2見出しとして扱い、タイトルや空行を整理し、箇条書きを変換し、見出しの後へ本文画像を配置する処理です。
ところが、Googleドキュメントの装飾情報をそのまま持ち込むと、不要なspan、style、classなどがWordPress本文に残り、表示が崩れることがありました。そこでv2.3.4では、装飾をいったん取り除き、記事構造を作り直す方式へ改善しました。
確認できるv2.3.7では、AI Publisher用のメタ情報を本文から除外し、タイトルや見出し、記号の扱いを整理した仕様が固まりました。
SEOキーワードの反映も、一度の修正では解決しませんでした。既存の開発記事には、およそ3回のバージョンアップを重ねてようやく安定した実体験が残っています。
なお、v2.3.3は存在を確認できるものの、変更内容を特定できません。v2.3.5、v2.3.6、v2.3.8以降についても、現時点では確認できない期間があります。
サイト間移設と安定動作へ進んだv2.4系
記事を投稿できるようになると、次に必要になったのはサイト間の移設でした。
記事を別のWordPressサイトへ移すには、本文だけでは足りません。本文画像、アイキャッチ、カテゴリー、タグなども一緒に移す必要があります。そこでv2.4.0では、サイト間移設に関する機能が進められました。
v2.4.1では、個別記事の取り込み時に発生したNonceの不一致を修正し、実際に1記事を正常に取り込めることを確認しました。
v2.4.2では、段落と画像の対応をより正確にする処理や、SEOキーワードを正しく反映する処理を強化しました。記事032を使った確認では、画像とキーワードが正常に反映されています。
v2.4.9というバージョン番号と、v2.5.0のリリース情報が存在したことは確認できます。しかし、保存されている資料だけでは主要な変更内容を確定できません。v2.4.3からv2.4.8までについても同様です。
分からない部分を都合よくつなげないことも、開発の歴史を正確に残すためには大切だと考えています。
大量記事の一括処理に対応したv2.5.1
記事数が増えると、1記事ずつ取り込む方法では時間がかかります。以前、約30記事を処理したときにも待ち時間が問題になり、一括処理を追加しました。しかし、まとめて処理すると通信がタイムアウトし、途中で止まる問題が発生しました。
v2.5.1では、大量の記事を安定して取り込むため、3記事ずつAJAXで処理する方式を実装しました。
通信エラーが起きた場合は最大3回まで自動で再試行します。それでも止まった場合に備え、「中断した処理を再開」と「失敗記事だけ再試行」も使えるようにしました。実際に一括取り込みから公開まで行い、正常に動くことを確認しています。
その後、Googleのアクセストークン更新に失敗し、記事一覧を取得できなくなる問題が起きました。Google Drive接続を一度解除し、再接続すると復旧し、記事一覧も再び取得できました。
ところが、別の問題が見つかりました。一括取り込みした記事に画像が反映されていなかったのです。
記事001で「画像を反映」を手動実行すると、本文画像8枚とアイキャッチが正常に設定されました。つまり、Google Driveから画像を取得できないのではありません。一括取り込み処理から画像反映処理へ、正しく処理がつながっていないことが分かりました。
原因を切り分けられたことで、次に直すべき場所が明確になりました。
133記事を扱ったから見えたv2.5.2の課題
記事数が133記事まで増えると、それまで気づかなかった問題も見えてきました。
一括取り込みを実行すると、既存記事を再投稿するわけではありません。しかし、AI Publisherは133記事すべてを走査し、取り込み済みかどうかを判定します。管理画面の「記事投稿」にも130件以上の記事が縦に並び、下書きや公開を管理する機能まで移動するだけで、大量のスクロールが必要になりました。
130記事を扱える仕組みを作ったことで、次は130記事を管理できる画面が必要になったのです。
そこでv2.5.2では、未取り込みの記事だけを効率的に処理し、「未取り込み○件」と件数を表示する方向で改善します。記事一覧は1ページ20件程度に分け、記事番号やタイトルによる検索、未取り込み・下書き・公開済みの絞り込み、新しい記事を上に表示する機能も追加します。
さらに管理画面をタブ化し、「記事取り込み」「下書き／公開管理」「サイト間移設」「Google Drive設定」「ログ／診断」へ分けます。記事数が増えても、必要な作業へすぐ移動できる画面を目指します。
一括取り込みについても、記事取得、WordPress下書き作成、メタデータ設定、本文画像反映、アイキャッチ設定、完了記録、次の記事という流れを、一連の処理として完成させます。
既存の「画像を反映」ボタンは削除しません。自動処理で画像だけが失敗したときに、復旧するための機能として残します。自動化を進めても、人間が立て直せる手段は必要だからです。
AI Publisherは「使う→失敗する→直す」で育っている
AI Publisherは、完成品を最初から設計して作ったプラグインではありません。
実際に使う。問題が出る。原因を調べる。修正する。また使う。記事数が増える。それまで見えなかった問題が出る。そして、もう一度改善する。
WordPressへ投稿できたときには、記事構造の問題が見つかりました。画像を扱えるようになると、一括処理との連携が問題になりました。30記事を処理できるようになると、通信の安定性が課題になりました。そして133記事を扱えるようになると、今度は管理画面そのものを作り直す必要が出てきました。
バージョン番号だけを見ると、小さな更新の積み重ねに見えるかもしれません。しかし、その一つひとつには、実際に使ったからこそ見つかった失敗があります。
ChatGPTは、原因を整理し、修正方法を考え、コードを作ることができます。人間は、実際のWordPressで動かし、結果を確認し、何が使いにくいかを判断します。どちらか一方だけでは、ここまで進めることはできませんでした。
確認できたバージョン番号は、v2.0.0、v2.1.0、v2.2.1、v2.2.2、v2.3.2、v2.3.3、v2.3.4、v2.3.7、v2.4.0、v2.4.1、v2.4.2、v2.4.9、v2.5.0、v2.5.1、v2.5.2です。ただし、すべての中間版や変更内容を確認できる資料は残っていないため、正確なバージョンアップ総回数は確定できません。
大切なのは、数字をきれいに並べることではなく、失敗を隠さず、次の改善に使うことです。
AI Publisher v2.5.2も完成の終点ではありません。これから実際に使えば、また新しい問題が見つかるかもしれません。そのときは原因を調べ、修正し、もう一度使います。
その繰り返しこそが、ChatGPTと人間が一緒にAI Publisherを育てていく開発の形です。
