0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

小説をAWSに投げたら漫画になって返ってくるサービスを妄想設計してみた(漫画編 #2.5)

Posted at

はじめに

前回の
小説をAWSに投げたら漫画になって返ってくるサービスを妄想設計してみた(漫画編 #2)
では、王道サーバーレス構成(案A)を深掘りしました。

今回はその対になる アーキテクチャ案B を妄想します。

案Aが「MVP(Minimum Viable Product)として最適な王道サーバーレス」だとすれば、
案Bは “品質を最優先したプロフェッショナル構成”

  • キャラの一貫性
  • 画質の安定性
  • 高精度モデルの活用
  • 大規模生成の耐性
  • 商用レベルの品質管理

これらを実現するために、構成は一気に“重厚”になります。


🎯 案Bのコンセプト:品質>コスト>速度

案Bは 「とにかく品質を上げる」 ことを最優先にしています。

  • GPU(Graphics Processing Unit)前提の画像生成
  • LoRA(Low-Rank Adaptation)によるキャラ一貫性
  • Embedding※による品質チェック
  • 非同期パイプラインで大量生成に耐える
  • 高精度モデル(SDXL / ControlNet)をフル活用

案Aよりもコストは上がりますが、
商用レベルの漫画生成を想定した構成になります。

※ Embedding(エンベディング)は、画像や文章を“意味を表す数値ベクトル”に変換する技術です。似ているものほど数値が近くなるため、キャラの顔や雰囲気が前のコマと一致しているかを数値で判定できます。


🏗️ 全体アーキテクチャ(文章で図解)

[EventBridge] 
     ↓
[SQS(画像生成キュー)]
     ↓
[ECS/BATCH(GPUジョブ)]
     ↓
[Embedding品質チェック]
     ↓
[S3(画像保存)]
     ↓
[ECS(ページ合成)]
     ↓
[DynamoDB(メタデータ管理)]
     ↓
[完了通知]

案Aの Step Functions 中心構成とは異なり、
案Bは イベント駆動 × 非同期 × GPU前提 の構成です。


🔥 画像生成パイプライン(案Bの核心)

■ ECS/BATCH + GPU

案Bでは、画像生成を GPUジョブとしてECS/BATCHで実行します。

  • SDXL(Stable Diffusion XL)
  • ControlNet
  • LoRA
  • 高解像度生成
  • キャラ一貫性のためのLoRAロード

これらを扱うには Lambda では非現実的。
GPU前提のコンテナ実行が必須になります。


■ Embeddingによる品質チェック

案Bの最大の特徴は 品質ゲート を設けること。

  • 顔の一致度
  • キャラ特徴の一致度
  • ポーズの整合性
  • 背景の破綻チェック

Embeddingベクトルを比較し、
しきい値を下回ったら自動リトライします。

if (similarity < threshold) {
    regenerate();
}

これにより、
「キャラの顔が毎回違う問題」を大幅に軽減できます。


🧠 キャラ一貫性のための仕組み

案Bではキャラ管理が高度化します。

■ LoRA管理

  • キャラごとにLoRAを作成
  • S3でバージョン管理
  • ECS起動時にロード

■ promptSeedの固定

  • キャラの顔が変わらないように
  • シーンごとに微調整も可能

■ Embedding辞書

  • キャラの特徴ベクトルを保存
  • 一致度チェックに利用

案Aよりも“キャラの人格”が安定します。


🖼️ コマ生成の高度化

案Bでは、コマ生成もより“漫画らしく”なります。

  • Depth系モデルで背景を安定化
  • ControlNetで構図を固定
  • カメラワークを画像モデル側で制御
  • コマごとに構図テンプレを適用

LLM任せではなく、
画像モデル側で構図をコントロールするのがポイント。


📬 ワークフロー制御:EventBridge + SQS

案Aの Step Functions と違い、案Bは 疎結合なイベント駆動

■ EventBridge

  • シーン生成完了
  • コマ生成完了
  • 画像生成完了
    などのイベントをトリガーに次の処理へ。

■ SQS

  • 大量の画像生成リクエストをキューイング
  • ECS/BATCHがGPUジョブとして処理
  • 失敗時はDLQへ

大量生成に強く、
スケールアウトしやすい構成になります。


🧩 ページ合成(案Aより高機能)

案Bではページ合成もECSで実行します。

  • コマ枠の自動レイアウト
  • 吹き出しの自動配置
  • 画質補正(超解像)
  • ページ全体の最適化

案Aの“ネームっぽいラフ”とは違い、
商用レベルのページ品質を目指します。


💰 コストと品質のトレードオフ

案Bは高品質ですが、当然コストは上がります。

項目 コスト メリット
GPU生成 高い 高品質・高速
Embedding比較 品質安定
LoRA管理 キャラ一貫性
非同期構成 低〜中 スケールしやすい

案Aと案Bは、
「MVP」か「商用品質」か の違いです。


🎯 まとめ

  • 案Bは 品質最優先の重量級構成
  • GPU前提の画像生成で高精度モデルを活用
  • Embeddingによる品質チェックが最大の特徴
  • キャラ一貫性のためのLoRA管理が強力
  • EventBridge + SQS + ECS/BATCH の非同期構成
  • 商用レベルの漫画生成を想定したアーキテクチャ

案Aと案Bを比較すると、
「目的によって構成は大きく変わる」 ことがよく分かります。


🔮 次回予告(漫画編 #2.6)

次回は、案A・案Bとは真逆の
「最小構成でとりあえず動く漫画生成(案C)」
を妄想します。

  • Lambda + Bedrock + S3 だけ
  • コマ割りは固定テンプレ
  • キャラ一貫性なし
  • 画像生成は直列
  • とにかく“動くもの”を最速で作る

案A・案Bとのギャップが面白い回になります。

お楽しみに。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?