Codexを組み込んだ画像生成フローで漫画を1コマずつ制作したところ、想定以上にトークン消費が積み上がりました。これまでの記事では、指示文の短縮、そしてVault（第二の脳）の読み込み量という2つの仮説を検証してきましたが、いずれも主因とは言えませんでした。今回はその続きとして、最後まで残った候補を検証し、影響の大きい要因を絞り込んだ記録をまとめます。
残った候補は2つだった
指示文の長さも、Vaultの読み込み量も主因ではないとわかった時点で、疑わしい候補はかなり絞られていました。
候補①：システムプロンプト自体の固定費
毎回のやり取りの前提として送られる指示や設定そのものに、無視できないコストがかかっているのではないか、という見立てです。
候補②：画像生成のbase64入出力
1コマごとの画像データは、テキストのメッセージとは別の形式でやり取りされます。この画像データそのものが、テキストのトークンとは違う重さでコストを積み上げているのではないか、という仮説です。
検証方法：切り分けて実測
システムプロンプトの固定費については、画像生成を一切行わないやり取りと、画像生成を含むやり取りとで、同じ回数のリクエストを送って比較しました。
base64の入出力については、生成する画像の枚数を段階的に増やしながら、トークン消費がどう変化するかを確認しました。
実際の結果・体験談
結論から言うと、画像を生成する回数が増えるほど、トークン消費がほぼ比例して増えていくことが確認できました。これは、指示文の長さやVaultの読み込み量では説明できなかった「使うほど重くなる」という体感と、はっきり一致する動き方でした。
システムプロンプトの固定費も無視できるものではありませんでしたが、画像1枚あたりのbase64データがやり取りされるコストの方が、実際に体感していた消費増をずっとよく説明していました。
漫画1冊分となると数十コマの画像を1コマずつ生成することになるため、この「1枚ごとに乗ってくるコスト」が積み重なって、あの重さになっていたということです。厳密な数値比較まではできていないため、あくまで自分の環境・使い方の範囲での見立てとして書いています。
使い分けのルールを確立
影響が大きい要因を絞り込めたことで、運用のルールもはっきりさせることができました。
- 1ページ単発の差し替え：CLIを隔離環境で使う。1コマだけなら画像データの負荷も小さく、CLIの手軽さを活かせる
- 全ページ一括生成：Codexアプリを手動で直接叩く。数十コマ分の画像データが一気に発生する場面では、自動化でまとめて回すよりも、手動で状況を見ながら進めた方が今の自分には合っている
「全部自動で流せた方がラク」というのが最初の理想でしたが、今回の検証を経て、量が多い場面ではあえて手動を組み合わせた方が、今の運用には合っているとわかりました。
よくある質問（FAQ）
Q. なぜ最初からシステムプロンプトやbase64入出力を疑わなかったのですか？
A. 体感として一番わかりやすかったのが指示文の長さとVaultの読み込み量だったため、まずそちらから検証しました。結果的に遠回りにはなりましたが、候補を1つずつ削っていったことで、最後に影響の大きい要因まで絞り込めました。
Q. CLIとアプリを使い分ける基準は「枚数」だけですか？
A. 基本は枚数ですが、1ページの差し替えでも急いでいない場合はアプリを使うこともあります。目安として、数コマ程度ならCLI隔離環境、それ以上まとまった枚数ならアプリ手動、と考えています。
Q. この使い分けは他のAIツールでも応用できますか？
A. 画像などのバイナリデータをやり取りするAIツール全般で、同じような「データ量に比例したコスト」が発生している可能性はあります。自分の用途で気になる場合は、同じように条件を分けて実測してみることをおすすめします。
まとめ
指示文の短縮、Vaultの読み込み量、そしてシステムプロンプト＋base64入出力と、3つの仮説を順番に検証してきました。今回の環境で実測した範囲では、画像1枚あたりのbase64データのコストの影響が大きいという結論になりました。1ページ単発の差し替えはCLIを隔離環境で、全ページ一括生成はCodexアプリを手動で、という使い分けに落ち着いています。「全部自動」ではなく「量が多い場面ではあえて手動を組み合わせる」というのが、今回たどり着いた運用方針です。
