【第17回】議論力第1話——4コマから生まれた「キーシーン逆算」ワークフロー

4コマでキャラ関係性からストーリーが生まれることを発見し、ページ数の壁にぶつかり、Gemini との対話でキーシーン逆算設計にたどり着いた。議論力第1話の制作記録

4コマの副産物

前回、「次は4コマでAIのギャグを試す」と書いた。実際にやった。やってみた料理部の4コマを何本か作った。

その中で、予想外の発見があった。

4コマのネームをAIに企画させるとき、キャラクターの関係性 を書いておくだけで、AIが複数のストーリーを勝手に考えてくれる。「この2人はこういう関係」「このキャラはこういう性格」——それだけ渡せば、あとはAIがシチュエーションを量産する。

4コマだからこそ見えたことだ。ストーリーマンガでは「何を伝えたいか（テーゼ）」が先にあって、それをどう構成するかに頭を使う。4コマにはテーゼがない。面白ければいい。だからAIに企画を丸投げできる。そして丸投げしたら、ちゃんと面白いものが出てきた。

ここから1つの仮説が生まれた。コンセプトとキャラ関係性を渡せば、AIはストーリーを作れるのではないか。

コンセプトからストーリーへ

仮説を試すために、新しいワークフローのステップを開発した。

これまでのネーム会議パイプラインでは、人間がシナリオを書いて渡すところから始まっていた。scriptize（脚本化）→ consult（ページ数提案）→ propose（3モデル並行でネーム作成）→ review → improve → vote。この6ステップの 前段階 に、コンセプトからストーリーを生成するステップを追加した形だ。

ドメインのコンセプト（世界観、テーマ）とキャラクター設定（関係性、動機、葛藤）を入力として渡し、AIにストーリーを複数案出させる。4コマで発見した「関係性ベースの企画」を、長編に拡張した。

今回はGPTが作ったストーリーを採用した。複数のAIに出させて、一番筋が通っていたのがGPTだった。

「最後は議論力がモノをいう」——弁護士が異世界に召喚されて、剣も魔法もないまま議論で戦う話。コンセプトはシンプルだが、第1話の構成としてはきれいにまとまった。

ページ数の壁

前回の課題は「構成のゴツゴツ感」だった。16ページに詰め込みすぎて、感情の階段が足りなくなる問題。

単純に考えた。ページが足りないなら増やせばいい。

32ページに増やしてみた。余裕ができた。次に48ページを試した。

48ページでは、AIがコンテキスト不足で対応できなかった。ページが増えるほどネーム全体の文脈を保持する必要があるが、そこが破綻する。前半で決めた設定を後半で忘れる。キャラの位置関係が狂う。整合性を人間が管理するコストが、ページ数に比例して爆発する。

ページ数を増やすだけでは解決しない。発想を変える必要があった。

Gemini との対話——キーシーン逆算

ここでツールを変えた。ネーム会議の自動パイプラインではなく、GeminiのWeb UIと対話しながらネームを設計する アプローチを試した。

対話の中で発見したのが、キーシーンを先に取り出す という方法だ。

ストーリー全体から、「この場面は絶対に見せたい」というキーシーンを抽出する。そこから逆算する。

キーシーンを特定する — この話で読者に見せたい決定的な瞬間は何か
必要な情報を洗い出す — そのキーシーンの時点で、読者が得ていなければならない情報は何か
見せ方を設計する — その情報を効果的に伝えるために、どんなコマの流れが必要か

キーシーンを中心に、ページ割りとコマ割りを組み立てていく。

「読者に何を理解させるか」という視点

Geminiとの対話でさらに掘り下がった気づきがある。マンガは「何が起きているか」を説明するメディアではない。「読者が順番に理解していくための『視覚情報』と『セリフ』のピースを過不足なく見せていく」メディアだ。

たとえば「主人公が歓迎されていない」を伝えるには、いきなり「処刑です」と言わせても読者はついてこない。

石造りの広間の全景 → 「ここは城の中だ」
臣下たちの冷たい視線 → 「この場の空気は敵対的だ」
「処刑です」 → ここで初めて衝撃が成立する

各コマの役割は「読者に次の情報を渡すこと」。キーシーンから逆算して「このキーシーンが伝わるためには、手前で読者が何を知っている必要があるか」を考える。これがネームの本質だと気づいた。

セリフの論理連鎖——バトンタッチを見失わない

もう1つ。マンガのネームで一番大事なのは、セリフの論理的な繋がり（バトンタッチ）をコマ単位で追えること だ。

「誰の発言」が「次の誰の思考」を引き出し、「事態がどう動いたか」。この連鎖を見失うと、読者は「なぜここでこうなった？」と置いていかれる。キーシーンだけ決めても、その間を繋ぐセリフのバトンタッチが切れていたら話として成立しない。

キーシーン（大コマ）をアニメの原画だとすれば、間を繋ぐコマ（中・小コマ）は中割りだ。リアクション、間（ま）、時間経過——これらは脚本に全部書いてある。それをコマに分解して振り分ける。ゼロから考えるのではなく、脚本という素材をコマ単位にばらして再構成する作業。

原作再現度という仮説

この方法を考えているうちに、1つの仮説が浮かんだ。

小説の漫画化、漫画のアニメ化やドラマ化。原作ファンが語る「原作再現度」——あれは結局、キーシーンをどう切り取ったか と それをどう構成したか で評価できるのではないか。

もしスコアリングできるなら、LLMとの相性が非常にいい。

キーシーンの切り取り — 原作から重要な場面を選ぶ（要約・抽出のタスク）
見せ方の設計 — 選んだ場面をどう構成するか（構成・設計のタスク）
スコアリング — 出来を評価して、基準に達しなければやり直させる（評価・ループのタスク）

どれもLLMが得意な領域だ。そしてループで出し直させる仕組みは、autoresearchやralph-loopですでにやっている。キーシーン逆算 → 構成 → スコアリング → ループ という、AIマンガ制作に非常にマッチしたワークフローが作れるのではないか。

adaptステップとして実装した

この仮説は、第1話のリリース後に実際に3big-ai-nemu-kaigiの新しいステップ「adapt（翻案設計）」として実装した。

小説のアニメ化と同じ発想だ。scriptize（脚本化）で全シーンを膨らませた「原作」を、Nページの漫画に「翻案」する。削るのではなく、漫画という媒体に翻訳する。

storygen（コンセプト→ストーリー）
  → scriptize（全シーンを脚本化。何も捨てない）
  → adapt（脚本をNページに翻案設計。人間が確認）
  → propose（設計書に従ってYAML生成）

adaptがやることは明確だ。

キーフレームの選定と見せ方 — 脚本から決定的場面を抽出し、どう見せるかを同時に設計する。重要度[1]のコマになる
脚本の分解 → コマへの振り分け — キーフレームから逆算して、脚本のリアクション・間・時間経過をコマに振り分ける
ページ配置 — キーフレームと繋ぎをページに配置
セリフ配置 — コマの重要度に合わせてセリフを翻案

ポイントは、adaptの後に人間が確認・編集するステップがあること。何を伝えるか（価値判断）は人間、どう伝えるか（技術的最適化）はAI。 この役割分担がproposeに全部やらせていた頃より遥かに明確だ。

キーフレーム消化チェック

原作再現度のスコアリングも実装した。adaptで「この話に必要不可欠」と指定したキーフレームが、proposeのYAMLに全部入っているかをチェックする。

仕組みはシンプルだ。adaptのキーフレーム数とYAMLのis_key: trueの数を比較する。キーフレームが欠けたら話が成立しないのだから、100%消化が必須。足りなければFAILでリトライ。

ローカルPythonで機械的にカウントするだけなので、LLMを呼ぶ必要もない。

ページ数の再発見——40ページの品質

adaptを設計する過程で、もう1つ大きな発見があった。

ページ数を絞ることを前提にすると、最初から痩せた話になる。先に理想形を作って、そこから何を削るか人間が決める方がいい。足し算で考えると貧弱になるが、引き算なら「何を捨てるか」が明確になる。

実際にconsult（ページ数提案）ステップでAIに聞くと40ページと提案してきたことがある。高すぎると思ったが、40ページで作った方が品質が高い。情報量の制限なく脚本を膨らませて、そこからNページに翻案する。この方が結果的にいいものができる。

adaptステップはまさにこの「40ページの原作を16ページに翻案する」作業を担う。

第1話の手応え

今回の議論力第1話は、Geminiとの壁打ちでキーシーン逆算ワークフローを手動で実践した実験として制作した。

正直に言うと、原作の小説から見て、自分でも十分に再現できたとは満足できていない。

キーシーンの選び方、情報の出し方、感情の階段——まだ改善の余地がある。ただ、ワークフローとしての方向性は正しいと感じている。「何を見せるか」を先に決めて、そこから逆算する。ブッダイズム。で感じた「逆算の罠」とは逆に、見せたいものが明確だからこそ逆算が機能する という手応えがあった。

第1話は手動でやったが、その手動の経験をadaptステップとして仕組みに落とし込んだ。第2話以降はこの新しいパイプラインで制作する。手動でやっていたことがどこまで自動化できるか——それが次の実験だ。

画風の固定——プロジェクト単位で決めないと崩壊する

40ページを一括生成して最初に気づいたのは、画風がコマごとにバラバラ だということだった。

同じキャラクターなのに、あるコマではリアル寄りの青年マンガ調、隣のコマではソシャゲ風、別のコマでは少女マンガ的な線。プロンプトに「manga-style color illustration」とだけ書いていたのが原因だ。Geminiは毎回「マンガ風」を独自に解釈する。

解決策はシンプルだった。プロジェクト開始時に画風を1文で固定する。

「shonen manga color illustration, bold G-pen outlines, cel-shaded coloring, vivid colors, high contrast」——これをすべてのコマの生成プロンプトに自動挿入する。固定したら安定した。逆に言えば、固定しないと40ページの漫画は成立しない。

画風のプロンプトには写真用語が効く。「Gペン」「セルシェーディング」「クロスハッチング」など、技法名を入れるとGeminiは正確に反映する。「かっこいい感じ」では毎回違うものが出るが、「bold G-pen outlines」なら安定する。

「直す」と「回す」——json-editの実戦

ブッダイズム。の振り返りで「回すガチャから直すjson-editへ」と書いた。今回の40ページ制作で、この方針が実戦レベルで機能することを確認できた。

背景の統一

同じ広間のシーンが10コマ以上続くのに、背景が全部違う。石の色、窓の形、照明の角度——毎回ゼロから生成するので当然だ。

やったことは3ステップ。

気に入った1コマからキャラクターを消して「背景だけの画像」を作る
その背景画像をリファレンスにして、各コマの背景だけ差し替える
キャラクターはそのまま、背景だけ統一される

json-editの「画像の一部だけ変える」能力がここで活きる。再生成すると構図もキャラも全部変わるが、json-editなら背景だけ入れ替えられる。10コマの背景を揃えるのに、再生成なら10回ガチャだが、json-editなら10回とも成功する。

セーラー服問題——ポジティブフレーミング

女子キャラの制服がセーラー服で生成される問題が頻発した。「NO sailor uniform」と書いても効かない。

Geminiの画像生成では、ネガティブな指定（〜を描くな）よりポジティブな指定（〜を描け）の方が圧倒的に効く。 これはGoogle公式のプロンプトガイドにも書いてある。

「NO sailor uniform」ではなく「white button-up dress shirt with red necktie」と書く。「車を入れない」ではなく「人通りのない静かな路地」と書く。欲しいものを具体的に記述する方が、欲しくないものを排除するより確実だ。

リファレンス画像の罠

キャラクターのリファレンス画像にキャラシート（複数ポーズの一覧）を使ったら、コマの中にそのキャラが3人出現した。Geminiがシートの各ポーズを別のキャラとして解釈したのだ。

リファレンスには単体のバストアップやポーズ を使うべきで、複数ポーズを並べたシートは避ける。シートは人間が見るための資料であって、AIに渡す参照画像としては不適切だった。

表紙制作——再現可能な分業

表紙は「イラスト」「タイトルロゴ」「サブタイトル」「作者名」の4層で構成される。最初はGeminiに全部入りで一発生成させようとしたが、テキストの位置もフォントも毎回変わって安定しない。

分業にした。

イラストはGemini — テキストなしの表紙画像を生成。「NO TEXT」を明示する
タイトルロゴもGemini — ただしグリーンバックで生成して、プログラムで透過処理
サブタイトルと作者名はフォント — Pillowで正確な位置に描画
合成はスクリプト — 引数を変えるだけで毎回同じレイアウトを再現

ポイントは ロゴをグリーンバックで生成する というアイデアだ。白背景だと白いアウターグローが消えてしまうし、黒背景だと黒い文字部分が消える。動画のクロマキー合成と同じ発想で、背景をグリーンにして色域で抜く。これでGeminiの生成した繊細なグロー効果をそのまま使える。

シリーズものでは、ロゴは1回作れば固定資産になる。毎回変わるのはイラストとサブタイトルだけ。スクリプト化しておけば、第2話以降は数秒で表紙が完成する。

manginus の進化

制作ツールの面では、manginusが相当な進化を遂げている。

JSON editの練度が上がり、以前なら手作業だった工程が自動化された。

複数コマの背景情報の一括適用 — 同じ場所のシーンなら、背景設定を一度書けば全コマに反映
複数コマの共通した矛盾の一括修正 — キャラの服装や位置の不整合を、該当コマすべてまとめて直す

ブッダイズム。のときに「矛盾潰しは人間の仕事で、自動化できていない」と書いたが、manginusがかなりの部分を引き受けてくれるようになった。制作環境としては非常に充実してきている。

proposeが重かった理由

ここで、ブッダイズム。から引きずっていた問題の正体が見えた。

従来のproposeステップは、プロットの設計からページ構成、コマ割り、セリフ配置、YAML生成まで一発でAIにやらせていた。「何を描くか」と「どう見せるか」を同時に判断させていた のだ。

AIにとってこれは重い。ストーリー上の価値判断と、漫画としての技術的最適化を同時にやるから、時間がかかるし、落ちやすいし、大事な要素が削られる。ブッダイズム。3話のゴツゴツ感も、根っこはこれだ。

adaptを挟むことで、判断が分離される。

adapt: 何を描くか、どう見せるか（ストーリーの判断）
propose: adaptの設計書に従ってYAMLを埋める（変換作業）

proposeの負荷が劇的に下がる。判断の責任がadaptにあるから、proposeは設計書を忠実にYAMLに変換するだけでいい。速くなるし、落ちにくくなるし、品質も安定するはずだ。

まとめ——4コマからキーシーン逆算へ

振り返ると、こういう流れだった。

4コマを作ったら、キャラ関係性からストーリーが生まれることを発見
コンセプトからストーリーを作る新ワークフローを開発
ページ数を増やしてみたが、48頁でAIのコンテキストが限界
Geminiとの対話で「キーシーン逆算」設計にたどり着いた
「読者に何を理解させるか」から逆算する設計の本質に気づいた
原作再現度のスコアリング仮説——キーフレーム消化チェックとして実装
adaptステップとして仕組み化。proposeの判断負荷を分離
議論力第1話で手動実験。第2話以降は新パイプラインで検証

4コマという「軽い実験」が、ストーリーマンガの構成手法を変えるきっかけになった。回り道に見えて、必要な回り道だった。

前回の記事: ブッダイズム。全4話を終えて

「最後は議論力がモノをいう」第1話を読む →

【第17回】議論力 第1話——4コマから生まれた「キーシーン逆算」ワークフロー