IT2026年8月18日

当社のAIコンテンツパイプラインはGPT-6 Solで稼働中——以前より画像生成を減らしました

Andrea Borghi による
当社のAIコンテンツパイプラインはGPT-6 Solで稼働中——以前より画像生成を減らしました

当社のAIコンテンツパイプラインはGPT-6 Solで稼働中——以前より画像生成を減らしました

2026年9月24日更新：この記事では、当初GPT-5.6で稼働していたパイプラインについて説明していました。現在はGPT-6 Solで稼働し、翻訳にはGPT-6 Lunaを使用しています。以下のモデル名とコードも、それに合わせて更新しました。

Green Yoga Incのパイプラインでコンテンツを生成するすべてのプロンプトは、現在GPT-6 Solを使用しています。この変更は、ファイルごとに1行を書き換えるだけです。記事にする価値があるのは、パイプラインから完全に取り除いた画像生成の扱いがどう変わったかです。

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

プロンプトはLambdaのソースコード内に文字列リテラルとして書くのではなく、ヘッダー付きのプレーンテキストファイルとしてai-prompts/に保存しています。現在は23個あり、単発の画像バッチ用のJSONマニフェストも1つあります。そのうち16個にはMODEL: gpt-6-solが指定されています。

意図的にそうしていないものもあります。

  • **21-content-translation.txt**は、小型のGPT-6モデルであるgpt-6-lunaで動作します。サイトを8言語に翻訳するもので、品質を少し上げることよりも処理量が重要なワークロードです。
  • Lambdaが現在も読み込む3つのgptimage-*プロンプトファイルには、MODEL:ヘッダーがありません。LambdaからOpenAIに送信されることがもうないためです。詳しくは後述します。
  • 残りの3つは、他のプロンプトに組み込まれるコンテキスト断片が2つと、別のプロバイダーを指定する画像から動画への変換プロンプトが1つです。

2つのLambda、ai-content-engineとyoga-scriptは、どちらもnormalizeModel()を使ってヘッダーの指定を解決します。

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

旧形式のID——gpt-5からgpt-5.6までと、以前のgpt-image-1.5——はすべてgpt-6-solに統一されます。半年間誰も触っていないプロンプトファイルが、廃止されたモデルを呼び出すことはありません。代わりに、何も通知せず現在のモデルが使われます。gpt-4oとgpt-4o-miniはそのまま引き継がれます。意図的にgpt-4oを必要とするコードパスが1つ残っているためです。

2つのLambdaはどちらもChat Completionsを使用

テキスト生成は、両方のLambdaからPOST /v1/chat/completionsに送信されます。4月の記事を読んだ方なら、これは方針の変更だとお気づきでしょう。以前はResponses APIに一本化していましたが、Chat Completionsに戻しました。この2つの関数が実際に行うのは、システムプロンプトとユーザープロンプトを受け取り、文章を返すことです。その用途には、Chat Completionsがよく知られた堅実な選択肢です。

POST /v1/responsesを呼び出すものとして残っているのは、開発者がワークステーションから手動で実行するスクリプトだけです。scripts/generate-pose-images.mjsは、gpt-6-solで1024x1024のimage_generationツールを使います。また、単発の画像生成スクリプトが2つあり、そちらは同じツールを1536x1024で使います。これらはブラウザー経由の通信ではなく、ローカルのバッチ処理であり、意図的にOpenAIを直接呼び出しています。

Yoga Sequence Builderは処理時間を自ら管理

ヨガシーケンスビルダーは、GPT-6 Sol上で05-yoga-script-generator.txtを使い、yoga-script Lambda経由で指導用スクリプトを生成します。スクリプト生成には時間がかかり、所要時間にもばらつきがあるため、Lambdaの処理の大半はプロンプトの調整ではなく、時間の計算に費やされます。

  • 1回目の試行は最長7分に制限されており、1度の遅い呼び出しで実行時間全体を使い切ることはありません
  • レスポンスをシリアライズして返すため、最後に25秒を確保します
  • gpt-4oへのフォールバックも用意されていますが、残り時間が2分以上ある場合に限り実行されます

重要なのは最後のルールです。最初の試行が遅い段階で失敗し、残り時間が足りない場合、Lambdaはフォールバックの開始を拒否し、代わりに明示的なエラーを返します——Skipping gpt-4o fallback: insufficient Lambda time remaining。完了できない呼び出しを始めても、明確なエラーがタイムアウトに変わるだけで、デバッグが確実に難しくなります。

画像の自動生成を停止しました

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

ai-content-engineのgenerateImage()は、現在何もしないスタブです。引数を受け取りますが使用せず、フォールバック用のカバー画像を返します。

/** 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を使わないためです。これらは拡散モデル用のプロンプト欄です。分けておくことで、連結された文字列を分解せずに、それぞれを適切な入力欄に貼り付けられます。

パイプラインを遅くすることが、適切な選択である理由

自動カバー画像生成は、誰にも事前確認されないまま、恥ずかしい画像がサイトに掲載される可能性が最も高い機能でした。テキストにはすでに承認メールを使っていましたが、画像にはその仕組みがありませんでした。画像は人の手を介さず、一度の処理で生成、アップロード、公開されていました。

この機能をなくしたことで、公開に時間がかかるようになりました。一方で、サイトに掲載される画像はすべて、公開前に人間が確認するようになりました。それこそが、私たちが実現したかったことです。モデルの性能が上がった一方で、人の監督なしに任せる仕事は減らしました。この2つは矛盾しません。

プロンプトはai-prompts/に、Lambdaはlambda/ai-content-engineとlambda/yoga-scriptにあります。ご自身のAIコンテンツパイプラインの承認フロー設計についてサポートが必要でしたら、お問い合わせください.

← ブログに戻る