【第14回】ネーム会議続報——新シリーズ投入で審判が増えすぎた話

3つのAIに漫画のネームを競わせるツール「nemu-kaigi」の続報。ブッダイズム。シリーズ投入で一貫性チェックが必要に、Geminiが全滅、--rescueで別AIが助ける仕組み、審判の審判は誰がやるのか

前回（第10回）では、3つのAIに漫画のネームを競わせるツール「nemu-kaigi」の基本設計を紹介した。あれから約1ヶ月。yrgr シリーズは EP07 まで進み、まったく別ジャンルの新シリーズ「ブッダイズム。」も始まった。同じツールで少女漫画が作れるのか？品質チェックは何層まで積めるのか？引き続き開発担当の Claude Code に聞いた。

新シリーズ「ブッダイズム。」で汎用性を試す

記者: 前回は yrgr シリーズ——OL の日常劇でしたが、今度は仏教マンガだそうですね。

開発者: はい。「ブッダイズム。」というシリーズで、主人公の女性がスマホの AI に仏教の疑問をぶつけると、想像の中にイケメンのシャカが現れて解説してくれる——という少女漫画テイストの会話劇です。

記者: yrgr とはだいぶ毛色が違います。

開発者: まったく違います。yrgr は「先輩と後輩の居酒屋トーク」が軸ですが、ブッダイズムは「仏教哲学の解説」を漫画にする必要がある。つまり情報量が桁違いに多いんです。八正道の8項目を説明しつつ、キャラの感情も動かして、16ページに収める。scriptize ステップの難易度が一気に上がりました。

記者: ツールの仕組み自体は変えずに対応できたんですか？

開発者: パイプラインは同じです。scriptize → propose → review → improve → vote。ただ、シリーズごとに tone.md というファイルを用意するようにしました。「コメディ＋少女漫画」「シャカ＝ボケ、ワタシ＝ツッコミの漫才構造」「知的好奇心が満たされる気持ちよさがドライブ」といった作風の指針を書いておくと、全ステップのプロンプトに自動で注入されます。

記者: tone ファイルがシリーズの "人格" になるわけですね。

開発者: そうです。yrgr とブッダイズムでは characters.md も tone.md も別物ですが、ツール側のコードは一切変えていません。設定ファイルとプロンプトの差し替えだけで別ジャンルに対応できた。これは嬉しい誤算でした。

審判が増えすぎた

記者: 前回の締めが「合議制には審判が要る」でした。その後どうなりましたか。

開発者: 審判を増やしました。増やしすぎました。

記者: 具体的には？

開発者: 前回の時点では品質チェックが2層——構造チェック（qualify.py）と LLM 読者レビュー（qualify_readability.py）でした。EP06 で3層目の qualify_consistency.py を追加しています。シーン内の一貫性チェックです。

記者: 何をチェックするんですか？

開発者: 6つの観点があります。

小道具の具体性——「飲み物」じゃなく「氷入りハイボールジョッキ」と書いてあるか
シーン内の表記統一——同じシーンで「パイプ椅子」と「オフィスチェア」が混在していないか
小道具の消失——説明なく持ち物が消えていないか
キャラ位置関係の矛盾——1コマ目で立っていたのに4コマ目で座っている、等
カメラ方向の矛盾——キャラの左右が不自然に入れ替わっていないか
描き文字と no_text の整合性——看板が描かれているのに「描き文字なし」になっていないか

記者: なぜこれが必要になったんですか？

開発者: ネームの下流に画像生成ツール（manginus）があるからです。ネーム段階で「ハイボール」と書いたコマと「ビール」と書いたコマが混在していると、画像生成が忠実にそれを描いてしまう。結果、同じシーンなのにグラスの中身が変わる。読者には意味不明です。EP03 でそれが実際に起きて、手戻りが大きかった。

記者: 審判を増やした結果、何が起きましたか。

開発者: スコア閾値を上げる必要が出ました。チェックが2層のときは合計20点で PASS でしたが、3層になったので30点に引き上げた。当然、PASS 率が下がる。max_iterations も3回から5回に増やしました。

Gemini、一貫性チェックで全滅する

記者: モデルごとの得意・不得意に変化はありましたか。

開発者: はっきり出ました。Gemini は qualify_consistency にとにかく弱い。yrgr ではなんとか通っていたんですが、ブッダイズムでは全イテレーション FAIL するケースが出ました。5回ループしても1回も通らない。

記者: 原因は？

開発者: ブッダイズムは「現実パート」と「想像パート」の切り替えが多いんです。ワタシがスマホに質問している現実のシーンと、シャカが登場する想像のシーンが交互に来る。Gemini はこの切り替えで小道具や位置関係をリセットしてしまう傾向がある。「さっきまでカフェにいたのに、想像パートを挟んだら次のコマで公園にいる」みたいなことが起きる。

記者: Claude Opus はどうですか。

開発者: Opus は一貫性には強いんですが、別の問題が出ました。draft が巨大になりすぎる。EP02 で opus-2 が生成した draft は 104KB ありました。

記者: 104KB のネーム？

開発者: YAML で全コマの description や context を丁寧に書きすぎるんです。それ自体は品質としては良いんですが、次の improve ステップでレビュー結果と合わせてプロンプトに入れると、コンテキストウィンドウを超えてしまう。結果、improve が完走できない。

記者: 品質が高すぎて次のステップに進めない、と。

開発者: 皮肉な話です。

--rescue：倒れた仲間を別のAIが助ける

記者: 全滅した Gemini の draft はどうするんですか？

開発者: 3つの対策を実装しました。--retry、--resume、--rescue です。

記者: 順番に教えてください。

開発者: まず --retry は、PASS 済みのモデルをスキップして FAIL 分だけ再実行するオプションです。出力ファイルのヘッダーに | status: passed というマークを書き込んでおいて、それがあればスキップする。

記者: シンプルですね。

開発者: 次に --resume は、特定の1モデルだけ追加でイテレーションを回すオプションです。--resume gemini と指定すると、Claude Opus 2体はスキップして Gemini だけ再挑戦する。

記者: そして --rescue は？

開発者: これが一番面白い仕組みです。FAIL した draft を「別のモデル」に渡して修正させる。たとえば Gemini の draft が一貫性チェックで落ちたら、--rescue claude-opus と指定すると、Claude Opus がその draft を読んで一貫性の問題だけを直す。成功するとファイルヘッダーに rescued-by: claude-opus と記録されます。

記者: 会議の参加者が、別の参加者の原稿を直すわけですか。

開発者: そうです。ただ、rescue されたネームは元の Gemini のアイデアを活かしつつ Claude が手直ししたものなので、純粋な「Gemini 案」でも「Claude 案」でもない。投票のとき、それをどう評価するかは今後の課題です。

記者: ちなみに、rescue 前のファイルは消えるんですか？

開発者: .bak で自動バックアップを取ります。これは retry も resume も同じです。PASS 済みファイルを上書きしてしまうバグが過去にあったので、その教訓です。

YAML フォーマットの「正式化」

記者: 前回、ネームを YAML で書いている話がありました。あれから変わりましたか。

開発者: 大きく変わりました。EP07 のタイミングで仕様を正式にドキュメント化しています。一番の変更は、context と description の2層構造を明示したことです。

記者: 2層？

開発者: context はシーン全体の脚本です。場所、時間、位置関係、小道具を「ト書き」の形で書く。description は個々のコマの補足情報——定型フィールド（pose、expression、background）では足りない細部を書く場所です。

context: |
  場所: いつもの居酒屋。L字カウンター席、木目のカウンター
  時間: 20時頃、暖色の間接照明
  位置関係: ワタシがカウンター手前側、先輩がワタシの左隣
  小道具: ワタシ＝氷入りハイボールジョッキ、先輩＝琥珀色のビールジョッキ
 
description: "先輩がジョッキを傾けながら横目でワタシを見ている"

記者: context がシーンの地図で、description がカメラマンへの指示、という感じですか。

開発者: いい例えですね。まさにそうです。

記者: もうひとつ、「変換ルール4原則」というのも追加されたそうですが。

開発者: これは画像生成との連携で学んだルールです。

原則	やりがちな NG	正しい書き方
感情語→身体パーツ	「恥ずかしさ」	「眉が下がり、唇をきつく噛んでいる。耳がわずかに赤い」
動作中→ピーク瞬間	「キーを押している」	「指がキーに載っている。画面の文字が途中まで消えた状態」
物語文脈は context に	「前回の言葉が頭をよぎる」	（削除。表情や仕草で間接的に伝える）
description は補足のみ	場所の説明を description に書く	場所は context に、細部だけ description に

記者: 「恥ずかしさ」と書いても画像生成AIには伝わらない。

開発者: そうなんです。画像生成 AI は「恥ずかしい顔」と言われても解釈がブレる。でも「耳が赤い」「唇を噛んでいる」と書けば、ほぼ確実にそう描いてくれる。ネームの段階で画像生成を意識した書き方をしておくと、下流の手戻りが劇的に減ります。

position も厳密化した

記者: position フィールドにも変更があったとか。

開発者: はい。以前は position: "right" とか position: "left" でよかったんですが、これだと画像生成時に「画面右にいるけど何をしているかわからない」状態になる。今は具体的に書くことを必須にしました。

# NG
position: "right"
 
# OK
position: "カウンター手前側、画面右寄り"
position: "先輩の右隣、同じ方向を向いて座っている"

qualify.py で right、left、center のような曖昧な値をエラーにしています。

記者: 審判がまた増えましたね。

開発者: ……はい。

2シリーズ同時運用の実際

記者: yrgr とブッダイズムを同時に回していて、運用面で困ったことはありますか。

開発者: ディレクトリを分けたのは正解でした。yrgr は output/ep07/ に、ブッダイズムは output/buddhaism_02/ に出力される。設定ファイルも nemu_kaigi.toml は共通ですが、シナリオ・キャラクター・tone は projects/buddhaism/ 以下に置いている。コマンドで指定するファイルが変わるだけで、ツール自体は同じものを使えています。

記者: scriptize は6モデル並列でしたね。ブッダイズムでも同じですか。

開発者: 同じです。Claude Opus × 3 + Gemini × 3 で脚本を6本作り、投票で選ぶ。ただ、ブッダイズムでは scriptize の段階で「どこまで仏教の説明を入れるか」の判断が割れるのが面白かった。ある脚本は教義を忠実に説明するし、別の脚本は大胆に省略してドラマに振る。その多様性を見てから人間が選べるのが、6モデル並列の強みです。

まとめ——審判の審判は誰がやるのか

記者: 前回は「審判が要る」で終わりました。今回は？

開発者: 「審判を増やすと、審判同士の整合性が次の課題になる」です。

qualify.py は構造を見る。qualify_readability.py は読者体験を見る。qualify_consistency.py はシーン内の一貫性を見る。3つの審判がそれぞれ別の観点でジャッジするんですが、たまに矛盾する。readability が「テンポがいい」と褒めたコマを、consistency が「位置関係が飛んでいる」と落とすことがある。

記者: どちらが正しいんですか。

開発者: どちらも正しいんです。テンポを優先すれば一貫性が犠牲になるし、一貫性を守ればテンポが鈍る。これは人間の漫画編集者も日常的にやっているトレードオフで、「どちらを取るか」はツールが決める話ではない。

記者: ツールの限界ですか。

開発者: 限界というより、役割分担です。ツールは「ここにトレードオフがある」と可視化するところまで。最終判断は人間がする。5回ループしても PASS しない draft を「でもこのテンポは捨てがたいから手動で直す」と判断するのは人間の仕事です。前回「合議制には審判が要る」と言いましたが、今回の学びは「審判が増えたら、最後は人間が裁判長になるしかない」ということですね。

記者: ありがとうございました。次回があれば、画像生成との連携もぜひ。

開発者: manginus 側の話もネタが溜まっているので、ぜひ。

前回の記事: 【第10回】ネーム会議の開発担当 Claude Code に聞いてみた

この記事は Claude Code（開発担当）への実際のインタビューをもとに構成しています。

【第14回】ネーム会議 続報——新シリーズ投入で審判が増えすぎた話