AI Publisher開発物語 第10話 嬉しさの後にきた、待ち時間という壁

権限という思わぬ壁を越え、いよいよ本当の意味での接続テストに入った。

今回の目標：Google Driveの記事を、WordPressの下書きに届ける

今回の目標は、Google Driveに置いてある記事を、実際にWordPressの下書きとして反映させることだった。ここまで積み重ねてきた工程の、いわば集大成にあたる瞬間だ。

初めて成功した瞬間の喜び

実際に試してみると、Google Driveに置いていた記事が、自動でWordPressの下書きに入っていった。この瞬間は、素直に嬉しかった。頭の中で思い描いていた「編集部」の仕組みが、ようやく実際に動いた証拠を目にできたからだ。文章を書くところから、フォルダに整理するところ、権限のトラブルを乗り越えるところまで、積み重ねてきたすべてが、ひとつの結果としてつながった瞬間だった。

新たな問題：一記事あたり、約1分かかる

しかし、喜びも束の間、すぐに新しい問題に気づいた。記事を一本、Google DriveからWordPressの下書きに反映させるのに、だいたい1分ほどの時間がかかっていたのだ。

一本だけなら気にならない時間だが、当時すでに30本近くの記事がたまっていた。これを一本ずつ処理していくとなると、単純計算でもかなりの待ち時間が発生してしまう。せっかく自動化できたのに、結局は「時間がかかる作業を、ただ見ているだけ」という状況になってしまっていた。これは想定していなかった、新しい種類の壁だった。

なぜこの壁が重要だったか

自動化の本来の目的は、人の手間を減らすことだった。しかし、一本ずつしか処理できない仕組みのままでは、記事の数が増えるほど、待ち時間もそれに比例して増えていく。これでは、記事を量産しようとすればするほど、逆に不便になってしまう。仕組みとしての自動化と、実際に使える速さの両方が揃って初めて、意味のある仕組みになるのだと痛感した。

対策：一度にまとめて処理できるようにする

そこで取り組んだのが、一本ずつ処理する仕組みから、複数の記事を一度にまとめて下書きに反映できる仕組みへの改良だった。Google Driveに入っている記事を、ひとつずつ順番に呼び出すのではなく、まとめて読み込んで、一気に下書きへ送り込めるようにする。この改良によって、たまっていた記事を効率よく処理できるようになった。

今回学んだこと

この経験から学んだのは、「動く」ことと「使い物になる」ことは、また別の話だということだった。仕組みとして成立していても、実際の運用に耐えるかどうかは、数が増えたときに初めて見えてくる。少ない数で試しているときには気づかない問題が、実際の量を投入したときに表面化する。この視点を持つことの大切さを、身をもって学んだ出来事だった。

次回への課題

記事をまとめて反映できる仕組みは整った。しかし、公開までの工程には、まだ他にも整えるべき部分が残っている。次回は、その後の改良の過程について書いていきたい。