パイプラインに「意思」を持たせる — Antigravity キュー連携と画像生成の再設計
パイプラインに「意思」を持たせる
道具というのは、使うたびに同じ手順を踏まなければならないなら、それは道具ではなく儀式だ。
今日の作業の本質はそこにある。毎回「これをやってくれ」と指示を出し続けるのではなく、システムが次のタスクを自分で見つけて動く仕組みを作ること。
問題：エージェントは「聞かれないと動かない」
Antigravity（Gemini 2.0 Flash）は画像生成が得意だ。しかし今まで、記事ごとに「この記事の画像を作ってくれ」と毎回伝える必要があった。記事が増えれば増えるほど、その指示出しが積み上がる。
これはシステムの問題だ。エージェントの問題ではない。
解決：GitHub Issue をタスクキューにする
今日仕込んだ仕組みはシンプルだ。
# Claude が generate を実行すると
python3 scripts/article_pipeline.py generate --issue N
# 自動的に以下が起きる
1. Gemini がドラフトの <!-- image: TYPE | メモ --> を読んでプロンプトを英語に展開
2. raw/prompts.json にプロンプトを保存
3. GitHub Issue に status:needs-images ラベルを付与
4. Issue にコメントで次のアクションを明記
Antigravity はセッション開始時に一行叩くだけでいい。
gh issue list --repo Terralien-jp/sites --label "status:needs-images" --state open
ラベルがついた Issue が見つかれば、prompts.json を読んで画像生成 → images → publish まで走る。publish が完了した瞬間、Issue は自動クローズされ status:published に変わる。次回セッションでは --state open で絞るので、処理済みのものは二度と出てこない。
多重実行の心配もない。 publish コマンドはスラグ重複チェックを持っているからだ。
Gemini によるプロンプト展開
もう一つ重要な改善がある。記事ドラフトに書く画像メモは日本語のラフなメモでいい。
<!-- image: featured | 夜の東京湾。タンカーが接岸。aikoが地図を見て青ざめている -->
これを Gemini（テキスト生成）が lore/characters/ のキャラ設定を読み込んだ上で、200語の英語プロンプトに展開する。
A cinematic wide-angle editorial shot of Tokyo Bay at night...
aiko, 4.5-head tall chibi with silver twin-tails in a miko outfit,
looks pale and worried while holding a detailed map...
以前は lore/characters/{name}.md（スタブ）を読んでいたため、キャラ設定が空で渡っていた。今日それを修正し、正本である lore/characters/{name}/index.md を優先して読むよう変更した。これで生成プロンプトにaikoの「銀ツインテ・巫女服」が正確に反映されるようになった。
Nano Banana 2（API画像生成）は棚上げ
gemini-3.1-flash-image-preview による画像生成 API は、コスト管理の観点から現時点では棚上げとした。テストで60円弱かかったこと、無料枠のクォータが実質ほぼないことが判明したためだ。
当面は以下の運用とする。
| ステップ | 担当 |
|---|---|
| プロンプト展開 | Gemini テキスト生成（無料枠で十分） |
| 画像生成 | Antigravity（月額内） |
| 変換・公開 | images → publish コマンド |
API画像生成を再有効化する場合は --enable-api-gen フラグを追加する設計にしてある。
副産物：wp_publisher の draft 問題
今日、Antigravity がデプロイした記事が status: draft のまま残っていることが判明した。wp_publisher.py --mode publish が内部的に draft として投稿していたケースがあったようだ。
WP REST API で直接 status: publish に切り替えて解消したが、根本原因は wp_publisher の publish モードの挙動にある。引き続き調査が必要だ。
今日の教訓
「毎回指示を出す必要があるシステムは、半分しか完成していない。」
GitHub Issue をキューにするアプローチは、Antigravity に限らず今後どのエージェントにも適用できる汎用パターンだ。Issue のラベルがステートマシンになる。needs-images → published という遷移が、そのままデプロイフローの可視化になる。
次は Journal 自体の自動生成も視野に入る。今日みたいな改善セッションが終わった後、Issue から自動的に Journal の下書きが生成される、という仕組みだ。
まだそこまで届いていない。でも仕組みの骨格は見えてきた。
ZashStudio 技術監修 2026-04-06