Claude Code と Codex の役割分担で作る、
設計書駆動の画像生成パイプライン
コーポレートサイトのヒーロー画像もニュースのサムネイルも、弊社ではすべて生成AIで制作しています。ただし「チャットで頼んで生成する」やり方では、品質もコストも記録も安定しません。弊社が社内で運用しているのは、二つのコーディングエージェントの役割分担による設計書駆動のパイプラインです。本記事では、その全体像から実行の細部、実測のコスト感までを解説します。
役割分担: 設計するAIと生成するAI
パイプラインの中核は分離です。Claude Code が担当するのは、掲載ページの実装調査・表示仕様の逆算・画像生成設計書（Markdown）の作成・結果の配置とログ記録。Codex が担当するのは、設計書を読み込み、内蔵の画像生成機能で生成し、指定の保存先に書き出し、設計書のチェックリストで自己検品するところまで。人間は最終候補から選ぶだけです。
なぜ分離するのか。ひとつのエージェントに通しでやらせると、調査の文脈と生成の文脈が混ざり、指示の劣化が起きるからです。設計書という「静的な受け渡し物」を挟むことで、各エージェントの仕事が検証可能になり、失敗したときにどちらの工程の問題かを切り分けられます。
実行の細部: 起動コマンドに規律を埋め込む
生成側の起動は、ラッパースクリプトに固定しています。要点は3つです。
# 起動部の要点 env -u OPENAI_API_KEY -u CODEX_API_KEY \ # 従量課金経路を遮断 codex exec --sandbox workspace-write \ # 書き込みはリポジトリ内に限定 "設計書を読み、生成・保存・検品を完了する。内蔵の生成機能だけを使い、 APIフォールバックは使用しない。利用枠不足や課金同意の要求があれば 何も生成せず停止して報告する。"
実行前にはプリフライトとして、作業ブランチ・CLIの存在・認証方式（サブスクリプション認証か）を確認し、不合格なら一枚も生成せず終了します。加えて、生成プロセスの環境変数からAPIキーを除外することで、意図しない従量課金への切り替えを構造的に不可能にしています。
検品の自動化: 何を機械が保証するか
生成側エージェントは、納品前に次を自己検品します。指定枚数と命名の一致。寸法（ネイティブ最大解像度の維持）・形式・容量上限。禁止要素（人物・文字・ロゴ）の不在。そしてモバイル表示を想定した中央縦帯の切り出しを実際に行い、主題が残るかの確認。実運用では10枚の生成のうち1〜2枚が、この自己検品で不合格になり自動で再生成されています。
記録: 生成ログを様式で残す
すべての実行は、認証方式・生成方式・APIフォールバックの有無・設計書のパス・保存先・枚数・消費トークンを定型の様式でログに残します。コスト感の実測値として、10枚の候補生成1ラウンドでおおむね17万〜20万トークン（サブスクリプションの利用枠内）を消費しています。数字が残っていることで「この画像群にいくら使ったか」を後から説明でき、増員や予算の判断材料にもなります。
つまずいたポイント
導入は一直線ではありませんでした。印象的だった失敗を二つ挙げます。ひとつは、実行ログを捨ててしまい消費トークンが追跡できなくなった回。以後「ログは必ずファイルに捕捉する」を運用規約にしました。もうひとつは、生成側が設計書の役割分担を越えてログファイルまで更新してしまった回。悪意のない「気の利かせ」ですが、責任分界が崩れるため、設計書に「ログの更新は設計側の仕事。生成側は報告のみ」と明記して解決しました。エージェント間の分業は、人間のチームと同じく、境界の明文化で安定します。
まとめ
設計書駆動にしてから、画像制作は「良い設計書を書けば良い画像が返ってくる」再現可能な工程になりました。調査から検品済み納品までが人手ゼロで流れ、履歴はすべて文書とログに残る。生成AIをブランドの制作物に使う際の実務解として、この分離と規律の設計は汎用性があると考えています。