724作品のカバー画像をAIで一括生成した話 — Geminiと格闘した1週間
2026-05-03
約6分で読めます画像がないサイトはつらい
戯曲図書館には700以上の作品が登録されている。でも、そのほとんどにカバー画像がなかった。
書籍と違って、戯曲には「表紙」が存在しないことが多い。出版されている作品ならAmazonの書影を使える場合もあるけど、同人作品や未出版の脚本にはそもそも画像がない。
結果、作品一覧ページは文字だらけのリストになっていた。Amazonみたいな商品ページを想像してほしい。画像がない商品って、それだけでクリック率が下がる。見た目の印象って、コンテンツの質とは関係ないところでユーザーの行動を左右する。
AI画像生成という選択
724作品分の画像を手作業で作るのは現実的じゃない。イラストレーターに発注したら数百万円コースだ。
そこでAI画像生成を使うことにした。最初に候補に上がったのは3つ。
- DALL-E 3(OpenAI) — 品質は高いけど、1枚あたりのコストが高い
- Stable Diffusion — ローカルで動かせるけど、セットアップが面倒
- Gemini (Nano Banana) — Googleの画像生成モデル。API経由で使えてコストが安い
結局Gemini(gemini-2.5-flash-image、通称Nano Banana)を選んだ。理由はシンプルで、Google AI StudioのAPIキーがあれば無料枠でかなり使えるから。個人開発の予算感にはこれが合っていた。
プロンプト設計が肝
「コメディ作品のカバー画像を生成して」と言っても、AIは何をどう描けばいいか分からない。プロンプトの設計がすべてだった。
最終的に落ち着いたのがこの構成:
- 共通の画風指定 — 「Japanese theater poster style, artistic illustration, no text」
- カテゴリ別のスタイルヒント — コメディなら暖色系、不条理劇ならシュールなトーン
- 作品固有の情報 — タイトル、あらすじ、キャスト構成から雰囲気を推定
たとえば不条理劇なら「surreal, dreamlike, muted tones, abstract shapes」、青春ものなら「bright, youthful energy, school or outdoor setting」というヒントを加える。
重要なのは「テキストを入れない」指定。AIが日本語テキストを生成すると、ほぼ確実に文字化けする。だから画像にはテキストを入れず、純粋なビジュアルだけにした。
実行して分かったこと
スクリプトを書いて一括生成を始めたんだけど、すんなりはいかなかった。
月間利用上限に引っかかる。 Google AI Studioには月間の支出上限があって、254枚生成したところで429エラー(Too Many Requests)が返ってきた。上限を引き上げて再開したけど、また引っかかる。結局、数日に分けて生成することになった。
APIのパラメータが変わる。 最初はimageSizeHintというパラメータでサイズ指定しようとしたら、「そんなパラメータはない」とエラー。ドキュメントに書いてあったのに。AI関連のAPIは変化が早くて、ドキュメントが追いついてないことがよくある。
モデル名が違う。 gemini-2.0-flash-expで動かそうとしたら404。正しくはgemini-2.5-flash-imageだった。モデル名の命名規則が分かりにくい。
環境変数の罠。 .env.localファイルでGemini APIキーとS3キーを管理していたんだけど、ファイルの最終行に改行がなかったせいで、2つのキーが結合されてしまった。「APIキーが無効です」というエラーの原因がまさかの改行不足。これに気づくのに1時間かかった。
品質のばらつき問題
生成された画像の品質は、正直ばらつきがある。あらすじが詳しい作品はそれっぽい画像が生成されるけど、情報が少ない作品は抽象的な画像になりがち。
でも「画像がない」よりは「AIが生成した画像がある」方が圧倒的にマシだ。一覧ページの見栄えが格段に良くなったし、SNSでシェアしたときのOGP画像としても機能する。
AI生成画像であることは隠さず、画像の横に「AI生成画像」のバッジを表示している。ユーザーに対して誠実でありたいし、将来的に作家や出版社から正式な画像提供があれば差し替える方針だ。
S3アップロードの自動化
生成した画像はAWS S3に自動アップロードして、CDN経由で配信している。ファイル名はcovers/post-{id}.webpで統一。WebP形式にしたのは、ファイルサイズが小さくてページの読み込み速度に影響しにくいから。
データベースのimage_urlフィールドにS3のURLを保存して、画像がある作品はカバー画像を表示、ない作品はグラデーションの代替表示にしている。
結局いくらかかったのか
Geminiの無料枠とAI Studioの従量課金を合わせて、254枚の生成にかかったコストは数百円程度。残りの470枚はまだ生成できていないけど、Geminiの月間上限がリセットされたら再開する予定。
S3のストレージ代は月数円。CDNの転送量を合わせても月100円以下。個人開発には十分すぎるコストパフォーマンスだ。
AI紹介文も同じ発想で
カバー画像と同じ発想で、作品の紹介文もAIで一括生成した。こちらはGeminiではなくClaudeを使って、724作品すべてに100〜200字の紹介文を付けた。
紹介文は作品のタイトル、作家名、あらすじ、キャスト構成、ジャンルから生成している。ネタバレは避けつつ、「この作品を読んでみたい/上演してみたい」と思えるような文章を目指した。
個人開発×AIの感想
AIを使えば「手が回らない」問題をかなり解決できる。700枚の画像も、700本の紹介文も、人力では不可能な作業量だ。
ただし万能ではない。品質のばらつきは受け入れる必要があるし、APIのエラーハンドリングは必須。「AIに丸投げ」ではなく「AIを道具として使いこなす」スキルが問われる時代になっている。
戯曲図書館はこれからもAIを積極的に活用していくけど、最終的な判断は人間がする。AIが生成したものを「そのまま使う」のではなく、「使えるものを選んで、足りないものを補う」というスタンスでやっていきたい。
関連記事
ロゴを5回変えた話 — 「戯」の一文字にたどり着くまで
戯曲図書館と戯曲パレットのロゴデザイン変遷記。没案の供養、AI生成の限界、そして結局「漢字一文字でいいじゃん」に落ち着くまでの試行錯誤。
2026-05-02
戯曲パレットを作った理由 — 上演許可の「めんどくさい」をなくしたかった
戯曲図書館の姉妹サービス「戯曲パレット」をなぜ作ったのか。上演許可の現状の不便さ、作家と劇団の間にある壁、そして個人開発で感じたリアルな話。
2026-05-01
時代劇が楽しめる戯曲おすすめ10選
戯曲図書館の時代劇カテゴリから、上演時間・キャスト人数・あらすじを比較しながらおすすめ10作品を紹介します。
2026-03-06
ヒューマンドラマが楽しめる戯曲おすすめ10選
戯曲図書館のヒューマンドラマカテゴリから、上演時間・キャスト人数とあわせて比較しやすい10作品を紹介します。
2026-03-04