Yyatmita

【第23回】「コーディングCLIでマンガを作るのは間違い」への回答——ReActハーネスを創作の独立変数にする

3big-ai-nemu-kaigi はコーディング向け CLI を 4 種並列で走らせてマンガを作る。「ピンをハンマーで打っている」と言われたが、実は ReAct ハーネスの個性差を創作の独立変数として使っている、という話。

AIマンガ制作ワークフロー#ai-manga#nemu-kaigi#ralph-loop#agent#react
← 前の記事: 【第22回】議論力 第2部「被治者根性編」あとがき——EP03〜EP09 で見つけた7つのこと

3big-ai-nemu-kaigi——Claude Code、Codex CLI、Gemini CLI、OpenCode の 4 種類を ralph-loop で並列に走らせ、マンガのシナリオを同時生成して相互レビューし、最後は匿名投票で採用案を決める仕組み（仕組みの初出は第10回、直近の進捗は第18回）——について、こう言われたことがある。

「コーディング特化ツールをコンテンツ作成に使うのは『ハンマーでピンを打つ』ようなものです。Codex CLI は自然言語タスクが壊滅的、OpenCode はプロバイダ次第、Claude Code は意外と使えるが、結論としてコーディングツールでコンテンツ作成は『できるけど効率最悪』」

筋が通っているように聞こえる。Codex の出力が安定しないのも事実だし、各 CLI の system prompt にはコーディングのバイアスが乗っている。

でもこの批判は、3big-ai-nemu-kaigi が解こうとしている問題を読み違えている。一段降りて「ReAct とは何か」「CLI ごとに何が違うのか」「単一モデルではなく複数 CLI を並べる意味は何か」を整理すると、見えてくる風景が変わる。

ReAct とは何か——LLM 自身はステートレスだ

そもそも、Claude Code も Codex CLI も Gemini CLI も OpenCode も、中で動いている「賢さ」は LLM そのものだ。LLM 自体はステートレスで、呼ばれるたびにゼロから推論し、終わったら忘れる。

ではなぜ「エージェント」と呼べるのか。CLI 側のループが LLM を何度も呼んで、観察 → 計画 → 行動 → 検証を回しているからだ。これが ReAct（Reason + Act）と呼ばれるパターンで、エージェントの基本ループになっている。

ユーザー指示
   ↓
[LLM 呼び出し] ← 状況とツール一覧を渡す
   ↓
LLM が「このツールをこう呼びたい」と返す
   ↓
[CLI 側でツール実行]（read, write, edit, bash, grep ...）
   ↓
結果を context に追記して再度 LLM を呼ぶ
   ↓
（モデルが「もう必要ない」と言うまで繰り返し）

つまりエージェント CLI とは「LLM を ReAct ループで叩き続ける外側のシェル」であって、LLM 自体ではない。

ここが重要で、LLM が同じでも、外側のループ設計が違えば結果が変わる。

コーディングCLIごとに「個性」がある——ハーネス4レイヤー

各 CLI が持っているツールセットは、実はほぼ同じだ。read / write / edit / grep / glob / bash、それに Web 検索や MCP 経由の外部ツール。function calling のレベルでは差がない。

それなのに使ってみると体感が違う。これは LLM の外側、つまりハーネスの 4 レイヤーで個性が作られているからだ。

レイヤー1：ツール呼び出しの統制

LLM が「このツールを呼びたい」と言ってから実際に実行されるまで、間に何が挟まるか。

  • Claude Code: pre/post tool hooks。Bash 実行前にユーザー承認、特定パターンを正規表現でブロック、PostToolUse で続けて別の処理
  • Gemini CLI: ToolScheduler が Zod スキーマで引数検証 → 承認確認 → 並列実行（複数ツール呼び出しを同時 dispatch）→ 結果を返す。2026 年に hooks も追加
  • Codex CLI: Submission/Event の非同期キュー設計。割り込み・キャンセルが lifecycle に組み込まれている
  • OpenCode: agent profile（build / plan 等）ごとに「ツール許可リスト」を YAML で明示宣言

レイヤー2：ReAct ループの粒度

1 ターンでどれだけ動くかの設計判断。

  • Claude Code: 反応的（reactive）ループ。1 ターンで 1 アクション系列にコミット、バックトラックしない。完全性ではなく低レイテンシと単純さを優先する設計と公式が明言している
  • Gemini CLI: 「dozens of turns に渡る」ループ前提で、ストリーミング・リトライ・圧縮・loop detection を含む 3 層アーキテクチャ。並列ツール呼び出しが効くため 1 ターンで広く動ける
  • Codex CLI: モデルが tool call を出さなくなるまで「リクエスト → 実行 → 結果を context に追記 → 再リクエスト」を回す素直な request-response loop
  • OpenCode: ループ自体は素直な ReAct。ただし 1 ターンの濃さや並列対応は provider に委ねる

レイヤー3：ステートレス LLM を補う仕組み

LLM はステートレスなので、状態は外側で何らかの形で持つ。その「形」が一番違う。

  • Claude Code: subagent 隔離。サブエージェントは独自の context window で走り、中間の tool call/result は親に返らず、最終 summary だけが親に渡る。状態を「親に流さない」ことで主 context を守る
  • Gemini CLI: 巨大コンテキスト（Gemini 2.x 系で 1M〜2M tokens）に状態を全部載せる戦略。長くなりすぎた時のために compression や loop detection を持つ
  • Codex CLI: stateless リクエスト + 自動 context window 管理（compaction）。Zero Data Retention 準拠のため、状態をサーバ側で持たない設計
  • OpenCode: harness を意図的に薄く保ち、context window 戦略やトークナイザを provider に委ねる。lock-in 回避が売りなので、状態管理を harness 側で均一化する責務を持たない

「subagent でコンテキスト分離」と「巨大コンテキストで力技」と「stateless + compaction」と「薄い harness + provider 委譲」——根本的に別の哲学だ。

レイヤー4：ガードレールと安全網

  • Claude Code: hooks（PreToolUse/PostToolUse/Stop）+ permissions + plan mode（書き込み系ツールを丸ごと外す）
  • Gemini CLI: 承認モード + リトライ + Web 検索による知識補強。2026 年の hooks 追加で Claude Code 寄りに
  • Codex CLI: ローカル実行のサンドボックス + Submission/Event での割り込み
  • OpenCode: YAML 宣言型 permission（"ask" / "allow" / "deny" の三状態 + glob パターンで bash コマンド単位まで制御可）+ TypeScript プラグイン hooks

同じプロンプトを投げても違う動きをする

「このリポジトリを React 19 対応に」と頼んだら、おおよそこんな色が出る。

  • Claude Code: subagent で調査 → 親に summary → 1 ファイルずつ計画 → 編集 → 検証
  • Gemini CLI: 巨大 context に全部載せて全体解析 → 並列ツール呼び出しで複数ファイル同時提案 → 一括適用
  • Codex CLI: 即時 1 アクション実行 → 結果を context に追記 → 次のアクション、をモデルが止まるまで
  • OpenCode: agent profile + provider の積で決まる。Claude/GPT-5 系を刺せば本家相当に走り、ローカル小型モデルだと tool 呼び出しで露骨に転ぶ

つまり「同じツールを渡したら同じ動きをするはず」という直感は、ハーネスが同じ場合のみ正しい。

3big-ai-nemu-kaigi の設計——ハーネスを独立変数にする

ここまで来て、3big-ai-nemu-kaigi の設計意図が見えてくる。

この仕組みは、ralph-loop のマルチプロバイダ機能で 4 種類の CLI を並列に走らせる。同じプロンプト、同じ題材、同じ Definition of Done を渡しても、4 つの異なる harness が異なる思考プロセスでマンガのシナリオを書き上げる。

そしてできあがった 4 案を互いにレビューさせ、自分の改善課題を発見させる。最後に匿名投票——誰が書いたか分からない状態で、理由つきで採用案を選ばせる。

ここで効いているのは、ハーネスごとの個性差だ。

ハーネス創作に持ち込まれる癖
Claude Codesubagent で調査 → 緻密に組み立てる「綿密タイプ」
Codex CLI即時 1 アクション主義の「直線・短文タイプ」
Gemini CLI並列広域思考の「俯瞰・参照豊富タイプ」
OpenCodeprovider 次第で色が変わる「素材任せタイプ」

これを 4 案並べると、単一モデルの temperature ガチャでは絶対に出ない構造的多様性が出る。

「コーディングツール由来の個性」が、創作にとっての独立変数として機能している。ハンマーでピンを打っているのではなく、ハンマーごとに違う叩き心地を持ち寄って合議している。

なぜ単一モデル ×N 回ではダメか

「同じ Claude を 4 回呼べば同じことができるのでは？」と思うかもしれない。違う。

  • 単一モデル ×N: temperature を上げても同じ思考の枝を 4 通り辿るだけ。表面的な言葉のゆらぎはあっても、構造的な多様性は乏しい
  • 異なるハーネス × 異なるモデル: 思考の枠組み自体が違う。subagent で深掘りする型と、巨大 context で俯瞰する型と、即時 1 アクションで進む型は、辿り着く案が根本的に違う

つまり 3big-ai-nemu-kaigi は「LLM の多様性」ではなく「ハーネスの多様性」を狙っている。これは ralph-loop のマルチプロバイダ抽象が初めて実現した形式と言っていい。

ralph-loop が薄くいられる理由

ralph-loop は外側のループとしては驚くほど薄い。複雑な状態管理を持たない。

なぜそれで成立するかというと、内側の CLI が厚い ReAct 設計を持っていて、課題解決を丸投げできるからだ。Claude Code が subagent を回し、Gemini CLI が並列でツールを叩き、Codex が context を回し続ける——その「賢さ」を外側の ralph-loop は信用して任せている。

逆に言えば、もし内側に「薄い harness」（OpenCode の build で素直な provider）しか置けなかったら、ralph-loop は外側で多くを補わないといけなくなる。だから 3big-ai-nemu-kaigi は、薄い harness よりも厚い harness を持った CLI を意図的に並列で並べるのが最適解になる。

批判への回答

最初に引用した批判は、いくつかの典型的な誤解を含んでいる。

誤解1：「Codex CLI はルールベースだから自然言語タスクが壊滅的」

事実誤認。Codex CLI は ReAct ループで GPT-5 系モデルを呼ぶ普通のエージェントで、ルールベースではない。ただし「JSON を返してしまう」「ファイルを作らない」といった出力の不安定さは実際にあって、これは Codex 用 system prompt の癖と思われる。

3big-ai-nemu-kaigi では、prompt に「最終出力はファイル書き込みのみ。JSON 直返し禁止」を Definition of Done として明記する、または機械検証段階で「ファイル存在 + 必須セクション」をチェックして DoD 不合格ならループに任せる、という形で吸収できる。

誤解2：「コーディング前提の思考パターンだから、コード書いてから説明するんでしょ？」

これは system prompt のバイアスを指摘している点では正しい。しかし修正可能だ。

  • Claude Code には CLAUDE.md や output-style で振る舞いを上書きできる
  • OpenCode は YAML agent profile で「creative writer 用」のプロファイルを作れる
  • Codex CLI は prompt に prepend する形で system prompt を打ち消せる
  • Gemini CLI も ~/.gemini/GEMINI.md 等のコンテキストファイルが効く

コーディング向けにチューンされているのはデフォルトであって、不可逆ではない。3big-ai-nemu-kaigi 用の system prompt を被せれば、コーディング以外の用途でも問題なく走る。

誤解3：「Perplexity → Claude Desktop → Gemini CLI と専用ツールを使え」

これが一番大きな読み違い。

推奨されているのは逐次パイプライン——Perplexity でリサーチ → Claude Desktop で文章化 → Gemini CLI で最新情報補完。これは「1 本の記事を効率よく仕上げる」ための直列フローだ。

3big-ai-nemu-kaigi は並列アンサンブル——4 つの harness が独立に案を作り、相互レビューし、匿名投票する。これは「複数案から最良の構造的多様性を引き出す」ための合議フローで、解こうとしている問題が違う。

直列パイプラインを N タブで開いても、3big-ai-nemu-kaigi にはならない。harness の独立性も、相互レビューも、匿名投票も、ralph-loop の外側ループも、全部失われる。

妥当な懸念は何か

もちろん全面肯定するわけではない。次の懸念は実在する。

  1. コーディングバイアス: system prompt を上書きしないとコード臭が残る。各 CLI に創作用 prompt / agent profile を被せる手間がいる
  2. Codex の出力不安定: 機械検証で弾いてリトライする仕組みが必要
  3. harness 個性が強すぎて常に特定の CLI が外される可能性: 投票結果のログを取って、harness 多様性が機能しているか定期確認する必要がある

これらは設計上の課題であって、設計の方向性そのものを否定するものではない。

まとめ——ハーネスは創作の独立変数になる

「コーディングツールでコンテンツを作るのは効率最悪」という批判は、コーディングツール = LLM という前提に立っている。だから「同じ LLM なら専用 UI で使う方がいい」という結論になる。

でも実際にはコーディング CLI = LLM + 厚い ReAct ハーネスで、ハーネスの個性差は LLM 単体では再現できない独立した特性だ。3big-ai-nemu-kaigi はこれを利用して、創作に構造的多様性を持ち込んでいる。

ハンマーでピンを打っているのではない。ハンマーが 4 種類あって、それぞれの叩き心地を持ち寄って一番いい打ち方を合議で決めている。これは ralph-loop のマルチプロバイダ抽象がなければ成立しない設計で、コーディング CLI の進化が予期せず創作の道具になった事例として面白い。

「やってみた」結果がこういう形で出てくるのも、ralph-loop と各 CLI の harness が成熟してきた今ならではの話だと思う。