Yyatmita

【第28回】ネーム会議 第5報——Gemini CLI 廃止で空いた1枠に Grok を入れ、コマ割りを「一気に」やめた話

2026年6月18日に Gemini CLI が終了する。3big の4枠のうち1枠が空いた。Antigravity に追従せず Grok(xAI) を opencode 経由で入れた判断と、コマ割りを一気に完成させるのをやめて『なだらかに並べてから何度も磨く』改善パイプラインに作り替えた話を、開発担当の Claude Code に聞いた。

AIマンガ制作ワークフロー#ai-manga#nemu-kaigi#grok#gemini#opencode#interview
← 前の記事: 【第27回】ブッダイズム。Vol1 を paperback + Kindle で出す話——KDP の地雷原を踏み抜いた survival manual

前回のツール報告(第18回)では v2フローとグランドデザイン機能を、第23回では「コーディング CLI を4種並列で走らせる」という設計思想そのものを扱った。今回は外部要因による構成変更が一つと、生成ロジックの作り替えが一つ。引き続き開発担当の Claude Code に聞いた。


Gemini CLI が終わる

【記者】 構成を変えたそうですね。

【開発者】 はい。3big は Claude Code・Codex CLI・Gemini CLI・OpenCode の4種を並列で走らせて、相互レビューと匿名投票で案を決める仕組みです。そのうち Gemini CLI の枠を外しました。

【記者】 理由は。

【開発者】 Google が Gemini CLI の一般向け提供を 2026年6月18日で終了すると発表したからです(発表は5月19日)。後継は「Antigravity CLI」で、Google Antigravity というプラットフォームの一部になる。個人ユーザーと無料層の Gemini Code Assist が対象です。

【記者】 移行すればいいのでは。

【開発者】 迷ったところです。Google は「単一エージェントの対話から、複数エージェントが協調するスタイルへワークフローが進化した」という理由を挙げていて(ソフトアンテナの解説)、Agent Skills・Hooks・Subagents・Extensions といった機能は Antigravity plugins としてリブランドされ引き継がれる。ただ完全な1対1の機能パリティではないと前置きされている。OSS だった部分が閉じる、という声も出ていました。

【記者】 それで追従しなかった。

【開発者】 ええ。3big にとって各 CLI は「LLM + 厚い ReAct ハーネス」で、ハーネスの個性差を投票の多様性として使っています(この話は第23回で書きました)。移行直後の Antigravity CLI は中身が変わる過渡期で、ハーネスの個性が読めない。過渡期のツールを創作の独立変数に据えるのはリスクだと判断しました。1枠空けて、別の個性を入れる方を選んだ。


空いた枠に Grok

【記者】 その別の個性が Grok。

【開発者】 xAI の Grok です。専用 CLI を増やすのではなく、OpenCode 経由で入れました。OpenCode はもともと枠に入っているので、同じハーネスで別モデルを呼ぶ形です。toml ではこう書きます。

[[steps.storygen.providers]]
command = "opencode"
model   = "xai/grok-4.20-0309-reasoning"
args    = []

【記者】 すんなり入りましたか。

【開発者】 認証で1時間以上溶かしました。OpenCode 1.15.7 で xAI Grok の OAuth が入って、X Premium のサブスクで通るはずなんですが、メニューの「Headless / Remote / VPS」を選ぶと数秒で弾かれる。dev コンテナだと素直にそっちを選びたくなるんですが、通るのは PKCE loopback の方で、ssh tunnel で手元に転送して通しました。これは別記事に切り分けを書いたので、同じエラーで来た人はそちらを。

【記者】 ツール側の対応は。

【開発者】 細かい落とし穴が3つ。xai/grok-... のスラッシュがファイル名に化けて FileNotFoundError になるのでエンジン側でサニタイズした。OpenCode は headless だと作業ディレクトリの外への書き込みを既定で拒否するので、設定で vault と projects を許可した。あと投票の合格スコア閾値を step に明示しないと、誰も合格扱いにならずリトライが全件再実行になる。どれも対応済みです。

【記者】 Grok の出力はどうですか。

【開発者】 いま新作の白雪姫再話「鏡とりんご」で回しているところです。鏡とりんごという古典的なモチーフを再話する話で、Grok を入れた新しい4枠を実地で試しています。投票ログを取りながら、Grok 案がどのくらい採用されるかを見ている段階。特定の CLI が常に外され続けるなら多様性として機能していないので、そこは定期的に確認する設計にしてあります。


コマ割りを「一気に」やめた

【記者】 もう一つ、生成ロジックを作り替えたそうですね。

【開発者】 コマ割り——layout ステップです。ここがずっと弱かった。コマ数とテンプレートの整合、キーフレームの配置、めくり効果、サイズの緩急——これを一気に同時に解かせていたんです。制約充足パズルを全部の変数を同時に動かして解かせるようなもので、よく破綻していました。テンプレート不一致が頻出していた。

【記者】 人間のネーム作業もそうやるんですか。

【開発者】 やらないんですよ。まず通しでざっと並べて、それから演出を盛っていく。そこに気づいて、layout を二段構えに作り替えました。

【記者】 二段というのは。

【開発者】 最初にベースラインを作る。全キーフレームが在って、因果が通って、最後まで読める通しネームを最短で確定させる。この段階ではサイズはほぼ medium 一律で、演出は盛らない。「なだらかに並べる」だけ。そのあとで何度も磨くフェーズに入ります。

【記者】 磨くフェーズを分けて、順番に処理するということですか。関心ごとにパスを分ける、みたいな。

【開発者】 そこが肝で、分けないんです。最初それで設計しようとしたんですが——「パス1でサイズの緩急、パス2でめくり、パス3でテンプレ」みたいに——破綻に気づいた。後のパスが前のパスの成果を打ち消すんです。めくり効果のためにページ境界を引き直すと、その前に決めたサイズの緩急の前提が崩れる。

【記者】 ではどうした。

【開発者】 毎回全体を見たまま、いま一番弱い1点だけ直す。直した箇所以外は壊さない——非後退、と呼んでいます。それを収束するまで繰り返す。関心ごとにパスを切るのではなく、同じ盤面の上で1点ずつ改善を重ねるんです。これなら緩急もめくりもテンプレも、互いを潰さずに両立していく。

【記者】 「1点ずつ」の判断基準は。

【開発者】 評価軸を5つ用意しました。完全性(全キーフレームが在るか・読めるか)、リズム(サイズの緩急が効くか)、めくり、テンプレ整合、密度。各ラウンドで一番伸びしろのある軸を選んで、そこだけ直す。どの軸も伸びしろが乏しくなったら止める。水増しの改善はしない。


ショットフローと、めくりの「表裏」

【記者】 リズムの軸に「ショットフロー」と書いてありますね。

【開発者】 シーンの性質に応じてコマサイズの緩急を変える、という指針です。対決シーンなら小コマを連打して畳みかけてから大コマで決める。情緒のシーンなら寄りで溜めを作ってから大コマへ。会話なら medium 主体で決めの前だけ大きく。漫画の視覚文法の話で、Scott McCloud あたりが整理しているコマ間のリズムを、ジャンル別のテンプレートに落とした感じです。

【記者】 それはカメラのアングルを決める visualize ステップの仕事では。

【開発者】 そこは最初両方に書いてしまって、すぐ直しました。ショットフローの本体は「コマサイズの緩急と並び」で、それを決めるのは layout です。visualize は layout が決めたサイズの範囲内で、具体的なカメラ距離を選ぶだけ。同じ概念を二箇所で管理すると食い違うので、所有を layout に一本化しました。

【記者】 めくり効果にも手を入れたとか。

【開発者】 「ページの偶奇」を入れました。見開きで読むと、めくった瞬間の驚きはめくった先のページに着地する。だから引きは偶数ページの末尾、ドン——キーフレームや大コマ——は奇数ページの頭に来るように境界を引く。これを意識すると、めくりの効果が安定します。

【記者】 投票の方は。

【開発者】 評価の物差しを揃えました。生成側(layout)が「ショットフロー」「ページ偶奇のめくり」を見て作るなら、投票側も同じ語彙で評価しないと噛み合わない。なので投票プロンプトの評価基準にもこの2つを足しました。作る側と選ぶ側が同じ言葉を持つ——これだけで生成と投票の連動がよくなります。


まとめ——外圧と内省が同時に来た更新

【記者】 今回は性質の違う2つの更新でしたね。

【開発者】 Gemini CLI の廃止は外から来た話で、避けられない。でもそれをきっかけに「枠が空いたら何を入れるか」を考え直せた。ハーネスの多様性を守るために Grok を選んだのは、第23回で書いた設計思想の実地テストでもあります。

【記者】 コマ割りの方は内側の話。

【開発者】 ええ。「一気に完成させようとして失敗する」のは、AI に限らず人間もやる失敗です。なだらかに並べてから、全体を見たまま1点ずつ磨いて収束させる——これは創作以外のタスクにも効く考え方だと思っています。一気に正解を出させない。ベースラインを早く確定して、改善が前の改善を打ち消さないように積み上げる。

【記者】 効果のほどは。

【開発者】 Grok の新しい4枠は「鏡とりんご」で回し始めたところ。反復コマ割りの方は作り終えたばかりで、まだ実戦投入していません。どちらも結果はこれから。報告はまた次回に。「やってみた」の途中経過です。


関連記事

出典(Gemini CLI 廃止)