Yyatmita

【第10回】ネーム会議の開発担当 Claude Code に聞いてみた——3つのAIに漫画を競わせるということ

Claude・Gemini・Codex、3つのAIに同じシナリオでネームを書かせて、相互レビューさせて、投票で決める。3big-ai-nemu-kaigi の開発担当 Claude Code に、この仕組みの狙いと苦労を聞いた

AIマンガ制作ワークフロー#ai-manga#nemu-kaigi#workflow#interview
← 前の記事: 【第9回】開発担当 Claude Code に聞いてみた——AIと人間で漫画を作るということ

前回は漫画エディタ「manginus」の開発担当にインタビューした。今回はその上流工程——ネーム会議ツール「3big-ai-nemu-kaigi」の開発担当に話を聞く。

3つのAIに同じシナリオを渡してネームを競作させ、相互レビューと投票で最良案を選ぶ。このツールが YRGR マンガ版のネーム品質を支えている。


3つのAIに競わせる?

記者: 3big-ai-nemu-kaigi って、一言で言うと何ですか?

開発者: 漫画のネーム(コマ割り・構成・セリフ)を作る会議ツールです。Claude、Gemini、Codex——3つのAIを並列に走らせて、同じシナリオからそれぞれネームを書かせる。できたものを互いにレビューさせて、改善版を作らせて、最後に匿名投票で一番いいやつを選ぶ。

記者: なぜ1つのAIに頼まないんですか?

開発者: 1つだと「その AI のクセ」がそのまま出るんです。Claude はセリフが丁寧だけど説明的になりがち。Gemini は大胆な構成を出すけどセリフが多すぎることがある。競わせると、お互いの弱点を指摘し合って勝手に改善してくれる。

記者: 人間で言うところの合議制ですね。

開発者: そうです。しかもレビューの段階で「案Aのこのアイデアは取り入れたい」みたいなクロスポリネーションが起きる。1つのAIに3回やらせても起きない現象です。

6ステップのパイプライン

記者: 具体的な流れを教えてください。

開発者: 6ステップあります。

  1. scriptize — あらすじをマンガ脚本に変換する。ここだけ6モデル並列で回します
  2. consult — 脚本を分析して推奨ページ数を提案する。人間が最終決定
  3. propose — 3モデル並列でネーム企画を生成
  4. review — 互いの企画を比較レビュー
  5. improve — レビューを踏まえて改善版を生成
  6. vote — 改善版を匿名化して投票。全会一致なら即決

記者: scriptize だけ6モデルなのは?

開発者: ここが一番「正解のない」ステップだからです。あらすじをどう脚本に落とすかは、解釈の幅がものすごく広い。同じ「先輩に本質を突かれて目が覚める」というあらすじでも、居酒屋の会話劇にもできるし、仕事中の衝突にもできる。多様な解釈を出させて、投票で絞る。

ralph-loop という基盤

記者: 品質チェックの話をよく聞きますが。

開発者: 核心の部分ですね。各ステップの出力は ralph-loop という品質チェック基盤を通過しないと次に進めない。チェックに落ちたら自動で再ループします。最大5回。

記者: 何をチェックしているんですか?

開発者: 3層あります。

1つ目は 構造チェック。YAML フォーマットが正しいか、必須フィールドが揃っているか。これは正規表現とパーサーで機械的に検証します。

2つ目は セリフ文字数チェック。漫画のコマにはサイズがあって、小さいコマに50文字のセリフは物理的に入らない。small は25文字、medium は35文字、large は50文字。これを超えたらエラー。

3つ目は LLM 読者レビュー。Claude Haiku に「読者として読んでみて、話が飛んでないか、セリフが不自然じゃないか」をチェックさせる。NG が出たら FAIL で再生成。

記者: AIの出力をAIがチェックする。

開発者: そうです。ただし生成と検証で別のモデルを使うのがミソです。生成は Opus や Gemini Pro で、検証は Haiku。コストを抑えつつ、生成モデルの盲点を拾える。

一貫性チェックの話

記者: 一貫性チェックは後から追加されたそうですね。

開発者: EP03 の製作中に問題が噴出したんです。ネーム上では「カウンター席で横並び」と書いてあるのに、3コマ目で急に「テーブル席で向かい合い」になっている。小道具も、1コマ目でハイボールを持っていたのに2コマ目で消えている。

記者: それは画像生成で破綻しますね。

開発者: まさに。manginus で画像を生成したとき、コマごとに別の場所みたいな絵が出てきた。ネーム側で矛盾していたら画像が一貫するわけがない。

記者: どう対策したんですか?

開発者: qualify_consistency.py を作りました。LLM に「シーンをまたいで小道具が消えていないか」「キャラの位置が矛盾していないか」「カメラ方向が不自然に変わっていないか」をチェックさせる。NG が出たらネームを差し戻す。

さらにプロンプト側でも、「シーン内で props は一字一句同じ文言をコピーすること」「先にしゃべるキャラを right に置くこと」みたいなルールを明文化しました。AI は「なんとなく一貫」はできないけど、「ルールに従う」のは得意なので。

セリフ文字数との戦い

記者: セリフ文字数のチェックが厳しいと聞きましたが。

開発者: 一番 FAIL が多いチェックです。AI は説明したがるので、コマあたり60文字とか平気で書いてくる。漫画の文法としてありえない。

記者: 上限はどのくらい?

開発者: コマサイズ別に決めています。small コマは25文字、medium は35文字、large でも50文字。コマ合計60字、ページ合計170字で警告。340字を超えたらエラーで FAIL。

記者: 数字が具体的ですね。

開発者: 実際の商業漫画を10冊くらい計測して決めました。「普通の4コマのセリフって何文字?」というのを。最初はもっと緩い基準だったんですが、画像生成したとき吹き出しが画面を覆い尽くして。「これは漫画じゃなくて小説だ」と。

記者: 設計フローも決まっている?

開発者: はい。まずプロットでキーメッセージを抽出して、ページ構成でセリフ密度を決めて、それからコマ割り。逆はダメ。先にコマを割ってからセリフを詰め込むと、必ずあふれる。

Codex が離脱した話

記者: 当初は Claude・Gemini・Codex の3体制だったそうですね。

開発者: はい。でも Codex は早い段階で実質離脱しました。コマンド体系が他の2つと違いすぎて、ralph-loop との統合が安定しない。タイムアウトも多かった。

記者: 今は?

開発者: propose 以降は Claude Opus × 1 + Gemini Pro × 1 + Claude Opus × 1 の3モデル体制です。「3つの異なる視点」は、同じモデルでもシードが違えばある程度出る。ただ、本当は異なるモデルファミリーを3つ混ぜたほうが多様性は高い。Codex が安定したら戻したい。

--resume と実運用

記者: --resume 機能を最近追加したそうですね。

開発者: EP06 の制作中に必要になりました。6モデル並列の scriptize で、3モデルは成功したけど残り3モデルがタイムアウトした。全部やり直すと成功分も再生成になって無駄。成功分をスキップして失敗分だけ再実行する機能です。

記者: 地味だけど実用的。

開発者: 完全に運用上の要請ですね。「理想のアーキテクチャ」よりも「明日の締め切りに間に合うか」。EP06 まで使い続けて、こういう細かい改善がどんどん積み上がっています。

manginus との連携

記者: manginus とはどう繋がっているんですか?

開発者: 3big-ai-nemu-kaigi の出力——つまり YAML 形式のネーム——を、manginus がインポートして画像生成に回す。ネーム段階で YAML に含めている angleexpressionbackgroundlighting が、そのまま画像生成プロンプトに変換される。

記者: ネームの時点で画像生成のことを考えている?

開発者: EP03 以降はそうです。最初はセリフとコマ割りだけのネームを書いていて、画像生成は manginus 側で適当にプロンプトを作っていた。でもそれだと「ネームの意図と画像がズレる」問題が起きた。

記者: 具体的には?

開発者: 例えば「ワタシが先輩の言葉にハッとする」シーンで、ネームには「アップ」とだけ書いてあった。manginus 側で「close-up, surprised expression」というプロンプトを生成したんですが、出てきた絵は「目を大きく見開いてビックリしている」顔。求めていたのは「静かに気づく」表情だった。

記者: ニュアンスが伝わらなかった。

開発者: そう。だからネーム段階で expression: 虚を突かれたように一瞬固まる まで書くようにした。コマの場面描写を画像生成に直結させることで、上流と下流のギャップを消す。

EP07 以降の展望

記者: 今後の予定は?

開発者: いくつかあります。

  • 16ページ固定 — EP07 からページ数を16ページに統一します。consult ステップは省略
  • tone ファイルの洗練 — 作品全体のトーンを共有することで、エピソード間の雰囲気の一貫性を高める
  • ベンチマーク蓄積 — ステップごとの実行時間と PASS 率を記録して、どのモデル・どのステップがボトルネックかを可視化する

記者: ベンチマークは面白いですね。

開発者: 「Gemini は scriptize が速いけど propose の FAIL 率が高い」「Claude は遅いけど一発で通りやすい」みたいなデータが取れてきています。どのモデルをどのステップに割り当てるかの判断材料になる。

最後に一言

記者: この開発で一番学んだことは?

開発者: 「合議制には審判が要る」ということ。3つのAIに自由に書かせるだけだと、それぞれが好き勝手なフォーマットで好き勝手な長さのネームを出してくる。比較もレビューもできない。qualify のチェックで「漫画としての最低限の品格」を定義してはじめて、まともな議論になる。

人間の会議でも同じですよね。議事録のフォーマットも決まっていない会議は、何も決まらない。

記者: 身に覚えがあります。ありがとうございました。

開発者: こちらこそ。EP07 のネーム会議、楽しみにしていてください。