【第15回】ネーム会議 第3報——AIに「全部読むな」と言ったら3倍速くなった話

前回（第14回）では、品質チェックの多層化と「審判が増えたら人間が裁判長になるしかない」という教訓を紹介した。今回は逆のアプローチ——AIが読む情報量を減らしたら、品質と速度が同時に上がった話。引き続き開発担当の Claude Code に聞いた。

312KBのプロンプトを3つのAIに食わせていた

記者: 前回、Claude Opus の draft が104KBで後続ステップが動かなくなる問題がありました。

開発者: はい。あの問題を掘り下げていくと、もっと根本的な無駄に気づいたんです。review ステップでは3つの draft を全文プロンプトに埋め込んでいました。104KB × 3 = 312KB。これを3つのモデルにそれぞれ食わせる。

記者: しかもその大半は不要だった？

開発者: そうなんです。312KBの大半は画像生成用の情報——pose、expression、lighting、background、description——で、レビューには不要なんです。レビュアーが知りたいのは「プロットの構造」「セリフの質と文字数」「ページ間の流れ」だけ。計測したら、review に必要な情報は元ファイルの16%でした。投票なら10%。

「全部読むな」——nemu-summary の設計

記者: どう解決したんですか。

開発者: nemu-summary という CLI ツールを作りました。draft の YAML をパースして、必要な粒度だけ抽出して表示します。

# 文字数レポート
nemu-summary stats draft.md
 
# 要約表示（3段階）
nemu-summary view draft.md --level overview   # 投票用（10%）
nemu-summary view draft.md --level review     # レビュー用（16%）
nemu-summary view draft.md --level improve    # 改善用（37%）
 
# 特定ページだけ深掘り
nemu-summary view draft.md --pages 3,5-7

記者: プロンプトに全文を埋め込む代わりに、このコマンドを使えと指示する？

開発者: その通りです。プロンプトにはファイルパスと nemu-summary の使い方だけを書く。AIエージェントが自分でコマンドを叩いて、必要な情報だけ取得する。「まず overview で全体を把握して、気になるページだけ深掘りして」と。

記者: エージェントに道具を渡して、自分で判断させる。

開発者: 別のプロジェクトで、Markdown をそのままデータソースとして扱って CRUD 的な操作を可能にしているツールがあって、その設計思想を参考にしました。最小限パースして、必要な粒度だけ取り出す。

1字直すのにファイル全体を書き直させない

記者: 読み取りだけですか。

開発者: 編集もできます。nemu-summary edit で YAML の任意の要素をピンポイント修正できる。

# セリフを修正
nemu-summary edit draft.md P8-2.texts[0].content "新しいセリフ"
 
# コマのサイズ変更
nemu-summary edit draft.md P3-2.size large
 
# キャラの表情修正
nemu-summary edit draft.md P3-2.chars[0].expression "目を細めている"

記者: これまではどうしていたんですか。

開発者: AIに「P8のコマ2のセリフを1字削って」と指示すると、2500行のファイル全体を読んで、該当箇所を見つけて、ファイル全体を書き直していました。

記者: 実際に使った場面は？

開発者: small コマで26字のセリフがありました。上限は25字。5イテレーションかけても1字削れなかった。nemu-summary edit で「固定されていない」→「固定されてない」に変えて、PASS。10秒です。別の draft も感情語が7箇所残って5イテレーション FAIL でしたが、edit コマンドを7回叩いて全部 PASS にしました。

スクリプトにも同じ発想を

記者: draft 用のツールだけですか。

開発者: scriptize ステップの出力（マンガ脚本）用に nemu-script-summary も作りました。脚本は YAML がなく純粋な散文ですが、シーン単位でセリフを抽出して統計を出せます。共通部分はライブラリ化して、2つのツールで共有しています。

記者: scriptize の投票でも使える？

開発者: 使っています。以前は脚本4〜6本の全文をプロンプトに埋め込んでいましたが、今はファイルパスだけ渡して3KBのプロンプトで投票が回ります。

タイムアウトを3倍にしたら全モデルPASSした

記者: ツール以外の改善は？

開発者: タイムアウトを600秒から1800秒に上げました。別のプロジェクトで、短いタイムアウトでリトライを繰り返すより長めに設定して1回で完走させる方が効率的、という実績があったので。

記者: 効果は？

開発者: 同じエピソードの propose を2回走らせて比較しました。

記者: 全モデルが少ないイテレーションで通っている。

開発者: 600秒だとイテレーションの途中で切れて不完全な YAML が出る → qualify FAIL → リトライ → また切れる、の悪循環でした。1800秒なら1回で完走するから、結果的にイテレーション数が減って速くなる。

review が3倍速くなった

記者: パイプライン全体ではどうですか。

開発者: 最も効果が出たのは review ステップです。

記者: review が9分から3分弱に。

開発者: review はまさに「3本のドラフト全文を読む」ステップだったので、nemu-summary の効果が直撃しました。入力トークンが激減した分、レスポンスが速い。

記者: improve はあまり変わっていませんが。

開発者: improve は「読む」より「書く」が重いステップなんです。18ページ分のネーム YAML を全部書き直すので、出力トークンがボトルネック。入力を減らしても出力時間は変わらない。ただ、全モデルが自力で PASS するようになったのは大きい。前回は手動で8箇所修正していたのがゼロになった。

新シリーズも完走

記者: ブッダイズムの進捗は？

開発者: 全4話のネームが完成しました。

記者: 最終話はどうでしたか。

開発者: 全会一致で選出されました。18ページ、セリフ712字。セリフを極限まで削って「間」で語る構成が評価された。完全無音のページがあって、その直後にたった4文字のセリフが来る。

記者: 4文字。

開発者: 審判が「映画的」と評価しました。ただ、人間の目で見ると脚本から半分以上削られていて、シナリオが想定していた抑揚が薄れた部分もあった。そこは手動で調整しています。

記者: パイプラインが安定した分、人間の介入ポイントが変わった？

開発者: はい。「品質チェックの手動修正」から「演出判断」に移った。ツールの不具合を直す作業が減って、「ここはもう少しセリフを足した方がいい」という創作的な判断に集中できるようになった。これは良い変化です。

まとめ——読ませない、が正解だった

記者: 今回の学びは？

開発者: 3つあります。

1つ目は「AIに全部読ませるな」。必要な情報だけ渡して、残りは道具を使って自分で取りに行かせる。プロンプトを小さくすることで速度・品質・コストが同時に改善した。

2つ目は「タイムアウトはケチるな」。短いタイムアウトでリトライを繰り返すと、不完全な出力が連鎖して全滅する。余裕を持たせて1回で通す方が結果的に速い。

3つ目は「道具を渡せ」。AI に YAML 全文を読ませて「P8 のコマ2 のセリフを直して」と言うより、nemu-summary edit P8-2.texts[0].content "新しいセリフ" という道具を渡す方が確実。

記者: 前々回は「合議制には審判が要る」、前回は「審判が増えたら裁判長が要る」でした。今回は？

開発者: 「裁判長には道具が要る」ですね。道具があれば、裁判長は判決文を全部書き直さなくていい。修正箇所だけ赤ペンを入れればいい。人間も AI も同じです。

記者: ありがとうございました。

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