はじめに
前回は「小説 → 漫画」の全体像を妄想設計しました。
今回はその中でも、最もMVPとして現実的な“アーキテクチャ案A”を深掘りします。
とはいえ、全部を細かく説明するわけではありません。
漫画生成の“キモ”となる部分だけを選択的に掘り下げます。
本記事は、前回の
小説をAWSに投げたら漫画になって返ってくるサービスを妄想設計してみた（漫画編 #1）
の続編です。
📦 全体像：漫画生成ワークフロー
小説をアップロードすると、裏側ではこんな流れで漫画が生成されます。
- 小説テキストをアップロード（S3）
- 前処理（Lambda）
- シーン分割（Bedrock）
- キャラ抽出（Bedrock）
- コマ割り生成（Bedrock）
- 画像生成（Bedrock Image / Stable Diffusion）
- ページ合成（Lambda）
- 完了通知（SNS）
この一連の処理を Step Functions がオーケストレーションします。
🧠 Step Functions のステート設計
漫画生成は「直列処理」と「並列処理」が混在するため、
Step Functionsが最も相性の良い選択肢になります。
[前処理]
↓
[シーン分割]
↓
[キャラ抽出]
↓
[コマ割り生成]
↓
[画像生成（Map Stateで並列）]
↓
[ページ合成]
↓
[完了通知]
この構成のポイント
- Bedrockの呼び出しはサービス統合でシンプル
- 画像生成はMap Stateで並列化し、速度を確保
- エラー時のリトライ戦略を柔軟に設定できる
🧩 Lambda（前処理）
前処理は軽量にまとめるのが鉄則です。
- 小説テキストの正規化
- 改行・空行を利用した段落抽出
- S3への保存
- Step Functionsの起動
重い処理はすべて後段に任せ、
Lambdaは“入口の整形”に徹します。
🧠 Bedrock（LLM）プロンプト設計の深掘り
漫画生成の“頭脳”となる部分。
ここをどう設計するかで、漫画の質が決まります。
① シーン分割プロンプト
- 物語の転換点を抽出
- 各シーンの要約
- 感情ラベル（喜怒哀楽など）
- 登場キャラのリスト化
② キャラ抽出プロンプト
- 名前
- 性格
- 口調
- 見た目の特徴
- 画像生成用の promptSeed
③ コマ割り生成プロンプト
- コマ数
- カメラワーク（ズーム・パンなど）
- キャラ配置
- セリフ
- 背景の有無
漫画の“文法”をLLMに学ばせるのが面白いポイントです。
🗃️ DynamoDB テーブル設計（妄想）
Scenes
- sceneId (PK)
- summary
- emotion
- characters
Characters
- charId (PK)
- name
- traits
- promptSeed
Panels
- panelId (PK)
- sceneId (SK)
- desc
- speech
- camera
Step Functionsから直接読み書きする構成です。
🖼️ 画像生成（Bedrock Image / Stable Diffusion）
漫画生成の中で最も重い処理です。
Map Stateで並列化
- コマごとに画像生成
- キャラと背景を別々に生成
- LoRAでキャラの一貫性を担保
生成の工夫
- キャラの顔が変わらないよう promptSeed を固定
- 背景はDepth系モデルで安定化
- 失敗した画像は自動リトライ
📄 ページ合成（Lambda）
- コマ枠の描画
- 画像の配置
- 吹き出しの描画
- セリフの配置
- ページ全体のレイアウト調整
最初は“ネームっぽいラフ感”で十分です。
🔁 エラー処理とリトライ戦略
- Bedrockの応答が変ならリトライ
- 画像生成失敗時は別モデルにフォールバック
- ページ合成失敗時は再実行
- 全体失敗時はSNS通知
Step Functionsの強みが最も出る部分です。
🎯 まとめ
- Step Functions中心の構成はMVPに最適
- Bedrock × Lambda × DynamoDBの組み合わせが強い
- Map Stateで画像生成を並列化
- エラー処理が柔軟で“現実的な妄想”ができる