CodexがBizタスクで強い本当の理由

勝敗を分けるのは多段エージェントではなく「工程設計」と「コメント設計」

最近、Codex を触った人たちのあいだで、かなり似た声を見かけます。
「Bizタスクは Codex が強い」
「Swarm が便利すぎて戻れない」
「ちょっとコメントを入れるだけで精度が一段上がる」

この手の話は、表面だけ見ると「また新しいツール礼賛か」で終わりがちです。ですが、今回は少し違います。
ここで起きているのは、単なるモデル性能の差ではありません。

本質は、AIの使い方が
“1回の指示でうまく答えを出させるゲーム” から、
“中間工程をどう分け、どこで品質を管理するかを設計するゲーム” に変わり始めていることです。

Codex の multi-agent は、その変化をかなり露骨に見せてくれます。
親エージェントがすべてを抱え込むのではなく、調査、整理、検証、レビューのような仕事を sub-agent に切り分けて進める。しかも各段階で途中結果を見て、差し戻しもできる。これは単なる並列化ではありません。
仕事そのものを工程として扱うためのUI です。

だから、Bizタスクで差が出ます。
Bizタスクは、コード生成のように「できた / できていない」で割り切れないからです。
・論点整理が甘い。
・期待値が曖昧。
・出力形式がズレる。
・レビュー観点が抜ける。
現場で AI 活用が不安定になる原因の多くは、モデルの知能不足というより、こうした工程の未設計にあります。

そしてもう一つ重要なのが、コメントです。
多くの人は AI へのコメントを、「補足」や「お願い」に近いものとして書いています。
「これやって」
「いい感じにまとめて」
「実務向けに直して」
これでは、たまたま当たることはあっても、再現性は出ません。

本当は、コメントはもっと重いものです。
コメントとは、各工程で
・何を返せば完了なのか
・どこまでの精度を求めるのか
・何を失敗とみなすのか
・次に誰へ渡すのか
を定義する、いわば工程契約です。

この記事で書きたいのは、Codex がすごいという話ではありません。
むしろ逆です。
Codex が強く見える現象を手がかりにして、これからの AI 活用で本当に差を生むものが何かを整理したい。

結論を先に言えば、勝敗を分けるのはツール名ではありません。
多段化された工程設計と、各段に書き込むコメント設計です。
Bizタスクで AI を安定稼働させたいなら、見るべき場所はそこです。

以下、そのまま叩き台にできる記事ドラフトです。

まず確認したい事実

Codexは「群れで進める」ことを前提に置きやすい

Codex の multi-agent は、専門化した sub-agent を並列に起動し、親エージェントがその結果を回収する仕組みです。
公式 docs では、main agent は requirements、decisions、final outputs に集中し、sub-agent は exploration、tests、log analysis のような noisy work を引き受けることで、main thread の信頼性を保つと説明されています。OpenAI はこれを context pollution と context rot の回避として位置づけ、まずは read-heavy な仕事で並列化し、write-heavy な並列編集は競合と調整コストが増えるので慎重に、とかなり明確に書いています。

さらに設定面でも、Codex は agents.max_threads、agents.max_depth を持ち、既定では同時オープン agent thread 数が 6、nesting depth が 1 です。つまり、多段化そのものを制御対象として持っているわけです。
加えて built-in role として worker、explorer、monitor などを備え、役割ごとに model、reasoning、sandbox を変える前提も docs に出ています。

この設計は、Bizタスクにかなり効きます。
なぜなら Biz タスクは、コード生成そのものより前に、論点整理、情報収集、仮説比較、要件分解、レビュー、表現調整という前工程が長いからです。実装より前に仕事が詰まる。だから「考える作業を分けられる」ことの価値が大きいのです。

Claude Codeが弱い、という話ではない

ただし分業の置き方が違う

ここで注意したいのは、Claude Code を雑に下げないことです。
Claude Code の subagents も、それぞれ独自の context window、custom system prompt、specific tool access、independent permissions を持ちます。
main conversation を汚さずに探索や検証を外出しする、という発想自体は Claude Code にもあります。しかも hooks は deterministic control を与える仕組みとして設計されていて、フォーマット、通知、コマンド検証、ルール強制のような処理を「LLM が気づいたらやる」ではなく「必ず走る」に変えられます。bundled skills が並列 agent を spawn できることも公式に書かれています。

ただし、Claude Code の subagents には明確な制約があります。
公式 docs では、subagents cannot spawn other subagents と明記されています。より複雑な並列協調が必要なら、subagent ではなく experimental な Agent Teams を使う設計です。
Agent Teams は、複数セッションが shared task list と inter-agent messaging で協調する強力な仕組みですが、そのぶん token cost は高く、Anthropic 自身も single session や subagents の方が向くケースを明示しています。

つまり、両者の違いは雑に言うとこうです。

Codex は orchestration-first。
Claude Code は specialist-first。

前者は「親が振り分けて回収する」感じが強く、後者は「専門家を呼ぶ」感じが強い。
この差が、Biz タスクでは操作感の差として表れやすいのだと思います。

Bizタスクで差が出る本当の理由

仕事が「正解生成」ではなく「工程管理」だから

Bizタスクは、実は AI が一発で答えを出すゲームではありません。
多くの場合は、

• 何を論点にするか決める

• 情報を集める

• どこが曖昧か特定する

• 期待値を置く

• 形式をそろえる

• レビューする

• 差し戻す

• 最後に経営・現場向けに整える

という工程の連続です。

ここでは、モデル単体の IQ より、工程の見取り図の方が効きます。
OpenAI の Codex ガイドでも、Project Manager agent がまず REQUIREMENTS.md、TEST.md、AGENT_TASKS.md を作り、その後に designer、frontend、backend、tester に gated handoff していく例が示されています。
これは単なるデモではなく、「曖昧な仕事を、誰が何をいつ返すかに分解する」設計例です。しかも trace で handoff を追えるので、工程監査とも相性がいい。

私はここに、Biz タスクで Codex が強く見える理由があると思っています。
つまり、Codex が正しい答えを“魔法のように出す”から強いのではない。
曖昧な仕事を、工程ごとの責任と出力に分解しやすいから強いのです。

「コメント品質の差」が10倍の差になる

それは補足文ではなく、工程契約だから

現場で「コメント品質の差が成果を10倍変える」と言われるのは、かなり本質を突いています。
OpenAI の GPT-5.4 prompt guidance は、GPT-5.4 が特に強くなる条件として、output contract、tool-use expectations、completion criteria を明確に書くことを挙げています。
さらに、長いタスクや tool-heavy な環境では、exact output format、dependency-aware rules、what counts as done をはっきり定義することが高レバレッジだと説明しています。

これは、現場でよくある「これやって」という雑なコメントと、次のようなコメントの差そのものです。

• 何を返せば完了か

• 精度はどこまで求めるか

• 何を失敗とみなすか

• どの形式で返すか

• 次に誰へ渡すか

ここまで書くと、コメントはただの補足ではありません。
工程契約です。
AI に仕事を投げるのではなく、工程を受け渡している。
だから結果が安定します。

では、実務で再現できるコメントはどう書けばよいのか。
ここから先は、私が最低限必要だと思っている6要素と、Bizタスク向けの3段ハーネスの基本形まで具体化します。