Google Driveで133記事と画像を管理した方法

結論から言うと、Google Driveを正本にし、記事番号、固定フォルダ、公開済み記事台帳を組み合わせることで、133記事と画像を管理しました。

この記事は、AI Publisherの機能を紹介するだけの記事ではありません。Google DriveとWordPressを実際に使い、記事を作成、保存、取り込み、公開した結果をまとめた実証記録です。

数値や出来事は確認できた範囲だけを使用し、資料にない結果を推測して補いません。

Contents

今回検証したこと

原稿は「05_記事（下書き）」、画像は「06_画像」へ保存し、記事番号で本文、サムネイル、段落画像を関連付けています。台帳には記事番号、タイトル、カテゴリ、要約、状態、公開日、URLを記録します。

検証では「処理ボタンを押せたか」ではなく、最終的なWordPress投稿と管理データが期待した状態になったかを確認します。

Google Driveを正本にしているため、WordPress側で問題が起きても元原稿と画像へ戻れます。

大量記事を扱うと、毎回の確認方法が違うだけで見落としが増えます。そこで、次の項目を固定しました。

タイトルの重複、H2・H3の階層、箇条書き、不要な装飾がないか確認します。

段落画像が見出し順に配置され、アイキャッチが投稿へ設定されているか確認します。

カテゴリー、タグ、英字スラッグが記事設計どおりか確認します。

SEOタイトル、description、keyword、下書き・公開・予約日時を確認します。

133記事まで増えたことで、フォルダ保存だけでは探しにくくなり、台帳と未取り込み判定、検索、絞り込みの重要性が分かりました。

1記事で成功したときには見えなかった問題も、30記事、100記事以上へ運用を広げると現れます。反対に、1記事で正常だった処理は、大量処理の不具合を切り分ける比較材料になります。

記事番号が重複すると、別記事の画像や台帳情報と混同するため、制作前に下書きと台帳の両方を確認します。

AI Publisherの記事では、確認できないバージョン、日時、件数、検索数値を埋めません。分からないものは分からないと記録し、後から実データを確認できた時点で更新します。

実証記事の価値は、大きな数字を見せることではなく、何をどの方法で確認したかを再現できる形で残すことにあります。

今回の運用では、正常な一括取り込みと公開だけでなく、次の問題も記録しました。

失敗を隠さず残すことで、次の改善要件が具体的になります。

Google Driveを正本にし、記事番号、固定フォルダ、公開済み記事台帳を組み合わせることで、133記事と画像を管理しました。

AI Publisherは、記事を増やすためだけの道具ではありません。記事制作、保存、投稿、確認、公開後の分析を一つの運用としてつなぎ、見つかった問題を次のバージョンへ戻すための仕組みです。

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