■ きっかけ

弥七とふかのすけたちの画像が、ようやく「その場に棲んでいる」ように見え始めた。
単発の当たり画像で終わらせず、屋敷アルバムとして継続生成できる形にしたくなった。

そのため、Codexに画像生成の段取りを組ませる前提で、生成用の構造を本丸プロジェクト内に切り出し始めた。

---

■ 先に整えたもの

最初にやったのは、長いプロンプトをそのまま抱え続けるのをやめることだった。

画像生成を数回回した時点で、以下の問題が見えていた。

• 弥七の出方が毎回ぶれる
• ふかのすけが置物化しやすい
• シーン差分が効きにくい
• 当たり画像が出ても再利用しづらい

そこで、プロンプトと参照画像を役割単位で分けた。

プロンプト分離

• common_yashichi.txt
• common_fukanosuke.txt
• style_yashiki_real.txt
• scene_01_night_desk.txt
• scene_02_corridor_corner.txt
• scene_04_rain_shoji.txt
• scene_05_morning_backdoor.txt

参照画像分離

• refs/yashichi/
  • 初代生成画像
  • リアル寄りで当たった弥七画像
• refs/fukanosuke/
  • ふかのすけ単体基準
  • 3体並び基準
• refs/combos/
  • 当たりだった「縁側の外光」

さらに scene ごとの設定を album-scenes.json にまとめ、Codex が読みやすい形にした。

---

■ 何を期待していたか

認識としてはこうだった。

• Codex は ChatGPT Plus で使える
• ChatGPT 側では画像生成もできる
• ならば、Codex経由の画像生成も Plus の範囲で扱えるのではないか

この理解で、Codex には屋敷アルバム生成用の補助スクリプトを作らせた。
構成確認だけでなく、scene 指定、refs 参照、dry-run、ログ出力まで含む形である。

ここまではかなり順調だった。

---

■ 実際に起きたこと

問題は、本実行に入った時点で発生した。

Codex が作った generate_scene.mjs は、ChatGPT 窓の画像生成を使っていたのではなく、OpenAI Images API を直接呼ぶ実装 になっていた。
しかも今回は、単純な text-to-image ではなく、

• 複数の参照画像を入力
• scene 用の複数プロンプトを連結
• 縦長サイズ指定
• images/edits 系の処理

という、比較的重い生成条件だった。

その結果、1枚生成して Usage を確認したところ、$0.27 が計上されていた。

---

■ 誤解のポイント

今回の引っかかりどころは、「全部が誤情報だった」わけではないことにある。

たしかに、

• Codex は ChatGPT Plus で使える
• ChatGPT 窓では画像生成もできる

ここまではその通りだった。

しかし今回やったのは、

• ChatGPT 窓で画像を生成した
  ではなく、
• ローカルの Node スクリプトから Images API を直接叩いた

である。

つまり、
「CodexがPlus内で使える」 と
「Codexが作ったスクリプトから呼ぶ画像生成もPlus内」
は同じではなかった。

この境界が曖昧なまま理解されやすいのが、今回の落とし穴だった。

---

■ ただし、無駄ではなかった

課金で転んだのは事実だが、一晩かけた作業が無駄になったわけではない。

今回残ったものは大きい。

1. 生成構造が整理できた

• common
• style
• scene
• refs
• JSON

に分けたことで、今後の再利用性が一気に上がった。

2. 参照画像の役割が明確になった

「なんとなくよかった画像」ではなく、

• 弥七の基準
• ふかのすけの基準
• 同居バランスの当たり画像

として整理できた。

3. scene差分をファイルとして持てるようになった

夜の机、廊下の曲がり角、雨の日の障子際、朝の勝手口。
この差分を scene ファイルとして持てるようになったのは大きい。

4. 課金事故防止のガードを追加できた

その後 generate_scene.mjs には、以下の制御を入れた。

• --execute がないと本実行しない
• --ack がないと本実行しない
• dry-run では API を叩かない
• billable execution をログに残す

つまり、同じ種類の事故はかなり踏みにくくなった。

---

■ コスト感の比較

今回の OpenAI 側の実測は、1枚で $0.27 だった。
参照画像つき、編集系、縦長出力込みの値である。

一方、手元感覚では Gemini 側は 1画像入力出力で約6円 だった。
条件差はあるが、体感としてはかなり差がある。

この比較を見る限り、使い分けはこうなる。

OpenAI 向き

• 当たり基準画像づくり
• 弥七とふかのすけの空気感を詰める回
• アルバムの表紙候補
• 勝負の1枚

Gemini 向き

• 差分量産
• 日次運用
• バリエーション展開
• 試行回数を増やしたい回

つまり、OpenAI は基準作り、Gemini は量産 という役割分担が現実的だと見えた。

---

■ 今回の収穫

今回の一件で整理できたのは、画像生成の品質論そのものより、運用境界 だった。

• ChatGPT Plus で使えるもの
• Codex が補助できるもの
• ローカルスクリプトから API を直接叩くもの
• その結果として別財布になるもの

この線が、やっと実感を伴って見えた。

便利になったのは事実である。
しかし、便利さと課金境界は別問題だった。

屋敷の空気が立ち上がり始めたと思ったら、Usage の数字だけが妙に現実だった。
その意味では、今回の実装は画像生成基盤を作っただけでなく、料金境界に札を立てた実装 でもあった。

---

■ まとめ

今回やったことを短く言うとこうなる。

• 屋敷アルバム生成のために prompt / refs / scene / JSON を分離した
• Codex に補助スクリプトを書かせた
• 参照画像つき画像生成を1回実行した
• その結果、Images API 課金が発生した
• ChatGPT Plus と API 課金は別財布だと確認できた
• そのうえで dry-run / execute / ack の安全弁を実装した

転んだのは事実だが、知見も残った。
今後は、OpenAI を基準画像と勝負絵に、Gemini を量産側に寄せる運用で組むのがよさそうである。