IT2026年8月18日

私たちのAIコンテンツパイプラインはGPT-5.6で動作し、以前より生成する画像が少なくなりました

Andrea Borghi による
私たちのAIコンテンツパイプラインはGPT-5.6で動作し、以前より生成する画像が少なくなりました

私たちのAIコンテンツパイプラインはGPT-5.6で動作し、以前より生成する画像が少なくなりました

Green Yoga Inc のコンテンツパイプラインにあるすべてのテキストプロンプトは、現在 GPT-5.6 を対象にしています。ここでの変更は、各ファイルにつき1行の修正で済みます。本当に書く価値があるのは、画像生成に何が起きたかであり、私たちはそれをパイプラインから完全に削除しました。

実際にモデルが選ばれる場所

プロンプトは ai-prompts/ に、文字列リテラルではなくヘッダー付きのプレーンテキストファイルとして置かれています。現在は19件あり、さらに単発の画像バッチ用にJSONマニフェストが1つあります。15件には MODEL: gpt-5.6 が付いています。

意図的に付いていないものが2つあります。

  • 21-content-translation.txt は gpt-5.4-mini のままです。サイトを8言語に翻訳する役割であり、ここでは最後の品質向上分よりも処理量のほうが重要です。すべてを再翻訳しても費用は約10セントです。
  • 3つの gptimage-* プロンプトファイルには MODEL: ヘッダーがまったくありません。Lambda からはもう OpenAI に送られていないからです。詳細は後ほど。

両方の Lambda — ai-content-engine と yoga-script — は、normalizeModel() を通じてヘッダーに書かれたものを解決します。

function normalizeModel(raw?: string): string {
  if (!raw) return "gpt-5.6";
  // Legacy GPT-5.x ids -> current flagship
  if (m === "gpt-5" || m === "gpt-5.1" || ... || m === "gpt-5.5" || m === "gpt-image-1.5") {
    return "gpt-5.6";
  }
  if (m === "gpt-4o" || m === "gpt4o") return "gpt-4o";
  return m;
}

gpt-5 から gpt-5.5 までのレガシーIDと、旧 gpt-image-1.5 はすべて gpt-5.6 に集約されます。6か月間誰も触っていないプロンプトファイルが、廃止されたエンドポイントを呼び出すことはできません。代わりに、何も言わずに現在のフラッグシップへ切り替わります。gpt-4o と gpt-4o-mini はそのまま通過します。というのも、1つのコードパスでは意図的に gpt-4o がまだ必要だからです。

両方の Lambda は Chat Completions と通信する

テキスト生成は、両方の Lambda から POST /v1/chat/completions に送られます。4月の投稿を読んだ方なら、これは逆戻りです。私たちは Responses API に統一していましたが、元に戻しました。Chat Completions は、この2つの関数が実際に行っていること、つまり system prompt と user prompt を受け取り、文章を返す、という用途に対して、地味ですがよく理解されている実装面です。

POST /v1/responses を呼び続けているのは scripts/generate-pose-images.mjs だけです。これはワークステーションから手動で実行する開発者向けスクリプトです。gpt-5.6 の image_generation ツールを 1024x1024 で使用します。これはローカルのバッチ処理であり、ブラウザからのトラフィックではありません。意図的に OpenAI に直接呼び出しています。

Yoga Sequence Builder は自分の時間を予算化する

Yoga Sequence Builder は、05-yoga-script-generator.txt に基づいて yoga-script Lambda を通じてティーチングスクリプトを生成し、GPT-5.6 を使っています。スクリプト生成は遅く、結果もばらつくため、Lambda のロジックの大半はプロンプトよりも計算処理に費やされています。

  • 単発の主要試行は7分で上限が設定されており、1回の遅い呼び出しが実行全体を消費してしまうことはありません
  • 応答をシリアライズして返すために、最後に25秒が確保されています
  • gpt-4o のフォールバックは存在しますが、少なくとも2分の余裕が残っている場合にのみ実行されます

最後のルールが重要です。主要試行が終盤で失敗し、残り時間が十分でない場合、Lambda は フォールバックの開始を拒否し、代わりに明示的なエラー — Skipping gpt-4o fallback: insufficient Lambda time remaining — を返します。完了できない呼び出しを開始しても、明快なエラーがタイムアウトに変わるだけであり、デバッグの観点では明らかに悪化します。

私たちは画像を自動生成するのをやめました

これが4月以降の本当の変更です。

ai-content-engine の generateImage() は、いまや no-op のスタブです。引数を受け取り、それらを無視して、フォールバックのカバー画像を返します。

/** Kept as a no-op stub for callers that still reference it directly. */
async function generateImage(imagePrompt: string, s3Key: string): Promise<string> {
  void imagePrompt;
  void s3Key;
  return FALLBACK_COVER_IMAGE;
}

これを置き換えたのは別のモデルではありません。人間です。generateOrReuseImage() は画像プロンプトを空の S3 キーとともに DynamoDB に書き込み、フォールバックを返し、承認メールがそのプロンプトを人間へ届けます。返信に画像が添付されて戻ってきたら、別の media-receiver Lambda が実際のアセットを埋め込みます。

そのプロンプトは1つの塊ではなく、clipL、t5xxl、negative の3つの別フィールドとして保存されます。というのも、これをレンダリングする人は通常 OpenAI を使っていないからです。これらは拡散モデルのプロンプト欄であり、分けておくことで、オペレーターは連結された文字列をほどく代わりに、それぞれを適切な入力欄に貼り付けられます。

なぜ遅いパイプラインのほうが正しいのか

自動カバー画像生成は、誰にも先に見られないまま、サイト上に気まずいものを載せてしまう可能性が最も高い機能でした。テキストはすでに承認メールを経由しています。画像はそうではありませんでした。生成され、アップロードされ、監視なしのまま一気に公開されていたのです。

それを取り除いたことで、公開は確かに遅くなりました。しかしそれは、このサイト上のすべての画像が公開前に人間の目を通っていることも意味します。私たちが本当に欲しかったのは、その性質です。モデルはより良くなり、私たちはそのモデルに対して、監督なしでやらせることを減らしました。それらは相反するものではありません。

プロンプトは ai-prompts/ にあり、Lambda は lambda/ai-content-engine と lambda/yoga-script にあります。ご自身のAIコンテンツパイプライン向けに承認フローを設計したい場合は、お問い合わせください。

← ブログに戻る