AI Publisher開発物語 第7話 「大きい画像は運べない」という結論

文章の質と、実体験の集め方は形になってきた。次に立ちはだかったのは、まったく別の種類の壁だった。

今回の目標：記事に画像を入れる仕組みを作る

文章だけの記事は、正直なところ読んでいて単調になりがちだ。今回の目標は、アイキャッチ画像と、文章の途中に入れる区切りの画像を、記事作成の流れの中に組み込むことだった。

なぜ画像が必要だと考えたか

長い文章を読んでいると、どこかで一息つきたくなる瞬間がある。段落ごとに、なんとなく見出しのような画像が入っていれば、読み進めやすくなるのではないか。そう考えて、アイキャッチ画像だけでなく、文章の区切りごとに挿入する画像も用意したいと考えた。

実際にやったこと：Claudeに作らせて、そのままDriveに送る

最初に思い描いていたのは、Claudeに画像を生成させ、それをそのままGoogle Driveの指定フォルダに自動的に格納してもらうという流れだった。人の手を介さず、記事も画像も自動的に積み上がっていく。それが理想の形だと思っていた。

問題発生：気づかないうちに、画像が壊れていた

ところが、この仕組みには最初、気づいていない落とし穴があった。作成した画像の容量が大きいと、Google Driveへの転送がうまくいかないという問題だ。厄介なのは、その場ではエラーに気づきにくいということだった。

実際に記事がある程度たまった段階で、画像を改めて確認してみると、想像していたよりもずっと小さく、荒い画質の画像になっていた。使おうとしていたサイズでは、画素が粗く、とても見られたものではない状態だった。最初はそのことに気づかず、後になって気づいたときには、既にかなりの数の記事にこの状態の画像が使われてしまっていた。

試行錯誤：やり取りを重ねても、結論は変わらなかった

なんとかこの状況を改善できないかと、Claudeとの間で何度もやり取りを重ねた。きれいな画像自体は作れる。しかし、その「きれいで容量の大きい画像」を、そのまま自動でDriveに移動させることができない。何度試しても、行き着く結論は同じだった。大きい画像は、そのままでは運べない。この事実を受け入れるところから、次の一手を考える必要があった。

対策：判別を人の手に戻す

記事の数がおよそ20本ほどに達した時点で、方針を切り替えることにした。画像の作成そのものをすべて自動化しようとするのではなく、どの記事にどんな画像が必要かを自分の目で判別し、その上で作成を指示するという形に変えたのだ。全自動を目指していたところから一歩後退したようにも見えるが、無理に自動化を押し通すよりも、現実的な運用として納得のいく形だった。

今回学んだこと

この経験から学んだのは、理想の仕組みを追い求めるあまり、目の前で起きている小さな異常を見逃してしまうことの怖さだった。うまくいっているように見えても、実際には荒れた画像がそのまま積み上がっていた。定期的に、実際の仕上がりを自分の目で確認するという工程を怠ってはいけないと痛感した。また、すべてを自動化することにこだわりすぎず、必要な部分は人の判断を残すという柔軟さも大切だと学んだ。

次回への課題

画像まわりの運用は、人の判断を挟む形に落ち着いた。次の課題は、こうして出来上がった記事と画像を、実際にWordPressへどう届けるかという、公開に向けた最後の工程についてだ。次回は、その試行錯誤について書いていきたい。