【第6回】話作りの壁——セリフを削ったら話が消えた

ツールは揃った。話が作れない

前回までで manginus のアーキテクチャは完成した。Claude が API を叩いてマンガを作れる。ComfyUI で画像生成もできる。AI3者ネーム会議で投票もできる。

正直、浮かれていた。「もう何でも作れる」と思っていた。

第3話の制作に入ったとき、その幻想は一瞬で崩れた。ツールとはまったく別の壁にぶつかった。

話作りだ。

セリフは小説じゃない

第3話「謙虚さと素直さ」の原作は、テキストベースのストーリーとして書いてある。登場人物の会話、心理描写、状況説明がそれなりの分量で書かれている。

最初はこの原作のセリフをそのままマンガの吹き出しに入れようとした。

入らない。

当たり前だ。小説のセリフとマンガのセリフは違う。小説なら「彼女は長い沈黙のあと、ようやく口を開いた」と地の文で間を作れる。マンガでは吹き出しの中に収まる文字数で、テンポよく、短く伝えなければいけない。

そこでネームチェッカーを作った。コマごと・ページごとのセリフ文字数をカウントして、NG（多すぎ）と警告（やや多い）に分類するスクリプトだ。ルールを決めて、ひたすらセリフを削った。

削ったら話が飛び飛びになった

セリフを削ると、今度はコマ間のつながりが失われた。

読んでみると「なんでいきなりこの話になるの？」「さっきの続きは？」となる。情報をつなぐセリフまで一緒に削ってしまったのだ。

そこで LLM を一般読者視点のチェッカーとして投入した。「このコマからこのコマ、飛躍がないか？」をチェックさせる。前後のコマだけを見せて、初見の読者として意味が通るかを判定してもらう。

これで飛躍は潰せた。……が、別の問題が出た。

話が薄い

飛躍はなくなった。でも元の話の「濃さ」が失われている。

大事なシーンが間引かれて、エッセンスだけのスカスカな話になっていた。面談のシーンも、居酒屋での気づきも、全部が薄い。ダイジェストを読んでいるような感覚。

おかしいな、と思って原作の分量を改めて見た。そして原作の分量に対して何ページが妥当かの目安を出すスクリプトを作った。

結果：12ページが妥当。

8ページでやっていた。

そりゃ薄まる。4ページ分の情報が消えているのだから。

脚本化（scriptise）という発見

ページ数を12ページに拡大した。でもそれだけでは足りなかった。

そもそものやり方が間違っていた。原作からいきなりネーム（コマ割り）に行こうとしていた。小説をいきなり絵コンテにするようなものだ。間に脚本化の工程が必要だった。

• シーンをいくつに分けるか
• 各シーンで何を表現するか
• どう演出するか

この工程を「scriptise（脚本化）」と呼ぶことにした。

実際にできた脚本の一部を見てほしい。

シーン2: 手応えのない面談——会議室

場所: 社内の小会議室。窓のない四畳半ほどの部屋。蛍光灯が白く平坦に照らし、壁は無地のグレー。

（ト書き: ワタシ、メモに目を落としながら話し始める。声はしっかりしているが、原稿を読むようなリズム）

ワタシ「チーム全体でお客様対応の品質を上げたくて」

（ト書き: ワタシが説明している間、部下はうなずいている。しかしその相槌は一定のリズムで機械的。目線はワタシではなくテーブルの縁を追っている）

（ト書き: ワタシ、メモの付箋を一つずつ剥がしながら、伝えるべき項目を消化していく）

ワタシ「……何か、質問ある？」

部下「いえ、大丈夫です」

（ト書き: 部下、小さく微笑む。しかしそれは「理解した」の笑顔ではなく「早く終わらないかな」の笑顔に見える）

場所の空気、小道具の意味、キャラクターの心理。脚本にはこういう情報が詰まっている。原作からいきなりコマ割りに行くと、これが全部消える。

さらに、ここでも第3回の「ガチャ思想」を応用した。6本の脚本を並列で生成し、AI の投票で最良を選ぶ。Gemini 3本 + Claude Opus 3本 = 6パターンだ。

投票結果が面白かった。

案6（claude-opus-3）が選出。

選出理由：

• ワタシが居酒屋で先輩に「率直に言ってほしい」と実際にフィードバックを求めるシーンがある唯一の脚本
• 「聞く」がテーマの回で、主人公が実際に聞く姿を見せている
• 面談メモの付箋（表＝伝えること → 裏＝聞くことリスト）という視覚的モチーフが一貫している
• 居酒屋でメモを書き始める → 先輩が吹き出す、というコミカルな緩急

5人中4人が案6に投票した（1人は案Bを推した）。票が割れなかったのは珍しい。

「聞く」がテーマなのに、主人公が「聞く」シーンがない脚本が5本あった。テーマを語るだけでなく、テーマを行動で見せる。言われてみれば当たり前だけど、6本並べて初めて気づいた。

脚本からネームへ——そしてまた壁

脚本化で濃縮した会話劇ができた。次はネーム会議（AI3者）でネームに落とし込む。

ここでも3案を生成して投票した。

案C（claude-opus-2）が選出。

選出理由：

• P9→P10 のページめくりの引き：「じゃあ言うけど」で止めて、フィードバック本体は次ページ
• 図解コマを削って対話に集中した判断
• 居酒屋の没入感を維持しつつ、セリフだけで概念を伝える構成

ページめくりの引き。マンガ特有の演出だ。右のページの最後のコマで期待を煽り、左のページの最初のコマで解放する。こういう演出は脚本段階で意識していないと、ネームでは取り入れられない。脚本化の工程を挟んだ効果がここで出た。

さて、ネームが決まった。manginus に渡して画像生成を開始する。

ここでまた壁にぶつかった。

YAML では演出意図が伝わらない

ネーム会議の出力は YAML 形式だ。各コマに pose、expression、background といったフィールドがある。これを機械的に連結してプロンプトを作り、画像生成 AI に渡す。

しかし YAML のフィールドを並べただけでは、脚本の演出意図が伝わらない。

たとえば「面談メモの付箋を一枚ずつ剥がしていく」という演出。脚本では「一方的に伝えるだけの面談を消化していく」という心理的な意味合いがある。でも YAML には props: "付箋メモ" としか書いていない。付箋を剥がす動作が何を象徴しているか、そういう情報が欠落している。

「これは彼女が正当化をやめる瞬間」というコマの意味。「メモの裏面に『聞くこと』を書き始める」という転換の意図。YAML のフィールドにはそんな情報を入れる場所がない。

プロンプトの作り方には2つのアプローチがあることに気づいた。

分解型: 感情や動作を身体パーツに分解する。「パニック → wide eyes, open mouth, raised shoulders」。ComfyUI のタグベースモデルにはこれが合う。

文脈統合型: 感情の理由、シーンの意味、小道具の象徴まで含めた自然文で書く。「このコマは彼女が正当化の裏に隠れることをやめる瞬間。表情には戸惑いと、わずかな安堵がある」。

NanoBanana（Gemini ベースの画像生成）は LLM だ。文脈を理解できる。分解型で情報を削るより、文脈統合型で「なぜこのコマが重要か」まで渡した方が、いい絵が出る。

manginus に相談した

53コマある。全部のプロンプトを文脈統合型で書き直す必要がある。

manginus を担当している Claude Code に脚本の演出意図を伝えて、1コマずつプロンプトを改善してもらった。

「このコマは面談の一方通行さを見せるシーン。部下は『大丈夫です』と笑顔で言っているが、目に光がない」

「面談メモの付箋を一枚剥がす。伝えたいことをひとつ消化した。でも『聞くこと』の欄はまだ空白のまま」

「居酒屋でメモの裏に『聞くことリスト』を書き始める。先輩はそれを見て吹き出す。緊張が一気に解ける瞬間」

53コマ分、こういう文脈情報を含めたプロンプトを Claude Code が作り直してくれた。出来上がった画像の質は、分解型で機械的に作ったものとは明らかに違った。

なんとか第3話を完成させた。

ただし、まだ課題は残っている。小道具や服装、場所の一貫性は脚本化のおかげで保てるようになった。でもキャラクターの位置関係——誰がどちら側に座っているか、カメラはどの角度から見ているか——はまだあいまいだ。コマごとに先輩とワタシの左右が入れ替わったりする。マンガの文法として、これは読者を混乱させる。

マンガ制作は深い

振り返ると、第3話で直面した壁はすべて「マンガ制作の知識」に関するものだった。

• セリフの文字数制限
• コマ間の飛躍チェック
• 原作分量とページ数の関係
• 脚本化という中間工程の必要性
• ページめくりの演出
• プロンプトへの演出意図の反映

ツールの自動化はいくらでも進められる。API を作り、スクリプトを書き、AI に投票させる。でも「何を自動化すべきか」「どこに工程が足りないか」を知るには、対象そのものへの理解が必要だ。

マンガ制作をシステム化するには、システムの知識だけでは足りない。マンガの知識が要る。

セリフの長さ、シーンの密度、演出の意図、コマプロンプトの表現力。ひとつひとつが深い。そしてそのひとつひとつで壁にぶつかり、スクリプトを書き、チェッカーを作り、工程を追加し、また壁にぶつかる。

マンガ制作は、思っていたよりもずっと深い世界だった。

---

完成した第3話はこちら → 【マンガ】第3話: 謙虚さと素直さ