Locale: ja
※この記事は2026年10月4日時点の公開情報と、実際に複数AIを使った運用上の体感を分けて書いている。Astra、Codex、Claude Opus 5.5の公開仕様は公式情報で確認した。一方、「Astraは探索が広がりやすい」「Dotは監督役として扱いやすい」などの評価は、特定の使い方での体感であり、万能なベンチマークではない。ここでいう「Dot」は監督役として使っているAIを指す呼び名である。
1. 結論：AIも「全員エース」より役職を分けたほうが回る
強いAIを見つけると、つい全部やらせたくなる。
調査して。 設計して。 コードを書いて。 テストして。 失敗したら直して。 進捗も管理して。 最後に説明して。
人間なら「いや部署分けろ」と言う量である。
AIでも同じで、探索、判断、実行、監督を一つの会話に詰め込むほど、途中で目的が増えやすい。特に探索能力が高いモデルは、「これも見たほうがいい」「前提から確認しよう」「別案もある」と仕事を増やす方向へ強い。
そこで実運用では、次の3役に分けると分かりやすい。
- 探索役：Astra — 未知の原因、別案、抜け、設計の弱点を広く探す
- 監督役：Dot — 今やる仕事を絞り、詰まりを見つけ、次の一手を決める
- 実行役：Codex — コード修正、調査、テスト、ファイル更新など具体作業を進める
そして、全部を一体化して長距離を走れるモデルがあるなら、そちらを主役にしてもいい。Claude Opus 5.5はAnthropicがエージェント、長時間のコーディング、複数ツールの仕事を主要用途として案内している。[5]
つまり答えは「マルチエージェント最高！」ではない。
仕事が一体で終わるなら1体で終わらせる。散らかるなら役割を分ける。
これが一番ラクだ。
2. Astraは「賢いのに仕事が終わらない」状態になりやすいことがある
探索型の強いAIは、難しい問題では頼もしい。
ログを見て原因候補を増やす。 設計の穴を探す。 「本当にそこが原因か？」と前提を疑う。 別の実装方針を持ってくる。
これは詰まったときには強烈に効く。
ただし、普通の作業まで探索モードで走らせると、問題がある。
「ボタン1個直して」が、 「まず設計思想を確認しよう」 「関連コンポーネントも見よう」 「将来の拡張性も考えよう」 「ついでに古い依存も消そう」 まで膨らむ。
気づくと、ボタンはまだ直っていない。
これはモデルが悪いというより、探索と完遂を同じ役にした設計の問題である。
OpenAIのAgents SDKでも、複数エージェントの流れを「オーケストレーション」として扱い、LLMに流れを判断させる方法と、コードで流れを決める方法を分けて説明している。[1]
探索能力は強い。 でも毎回、冒険の地図を描き直す必要はない。
3. Dotを「現場監督」にすると、探索を仕事へ戻せる
ここで監督役が効く。
監督役の仕事は、最も賢い答えを出すことではない。
- 今どのタスクをやっているか
- 何が終わったか
- 何が失敗したか
- 次に誰へ渡すか
- 何回失敗したら上位モデルへ上げるか
を握ることである。
要するに、Dotには天才研究者をやらせない。
「それ面白いけど、今はこのチケット終わらせような」係にする。
これだけで、AIチームに突然かなり人間味が出る。
Astraが「根本から再設計する案があります」と言い始めたら、Dotが「今は障害復旧。再設計案は別タスク」と切る。
Codexがテストで落ちたら、Dotがログを読ませて再実行させる。
3回やって同じところで詰まったら、Astraへ戻す。
監督役は華やかではない。 でも工場では、華やかな人より「止まったラインに気づく人」が強い。
4. Codexは「考える王様」より、境界のある実行役に置く
Codexはコードベースを読み、変更し、テストし、調査する実行役として使いやすい。
大事なのは、「全部考えて」ではなく、仕事の入口と出口を決めて渡すこと。
たとえば、
- 対象リポジトリ
- 対象ファイル
- 直したい症状
- 触ってよい範囲
- 成功条件
- 実行するテスト
- 返すべき結果
を渡す。
するとCodexは「会社の未来」を考えずに、「このPRを通す」に集中できる。
OpenAIは2026年にCodex向けのオーケストレーション仕様Symphonyを公開し、セッションそのものではなく、issueやタスクを大きな仕事単位として扱う設計を紹介している。[2]
ここが重要である。
AIの会話を仕事の本体にしない。タスクを仕事の本体にする。
会話は切れてもいい。 モデルは変わってもいい。 仕事の状態だけ残ればいい。
5. thread_idだけでは足りない。task_idと状態を持たせる
「質問を拾って、別AIに考えさせて、元のスレッドへ返す」なら、thread_idはかなり便利である。
ただしthread_idだけだと、同じスレッドで質問が2個、3個と増えたときに困る。
最低限、次のように分けたい。
{
"task_id": "T-1842",
"source_thread_id": "<source-thread-id>",
"source_message_id": "<source-message-id>",
"manager": "dot",
"executor": "codex",
"advisor": "astra",
"status": "working",
"attempt": 2,
"next_action": "run tests"
}
ここで主役はtask_idである。
thread_idは「どこへ返すか」。 message_idは「何に返すか」。 task_idは「何の仕事か」。
この3つを分ける。
状態も、最低でも次くらいは欲しい。
- pending
- working
- blocked
- review
- done
- delivered
- failed
これがないと、AIが仕事を忘れたのか、作業中なのか、送信だけ失敗したのか分からない。
「たぶんやったと思います」は工場ではステータスではない。
6. 普段はDot↔Codex、難所だけAstraへ上げる
一番軽いループはこれである。
通常 Dot → Codex → Dot → Codex
難航 Dot → Astra → Dot → Codex
Astraを常時ループに入れない。
理由は単純で、探索能力が強いほど枝が増えるから。
たとえばエスカレーション条件を、
- 同じ失敗が3回
- 原因候補が2つ以上で決め手がない
- 設計変更が必要
- 複数リポジトリにまたがる
- 既存仕様と要求が衝突
などに固定する。
すると、Astraは「何でも相談される先輩」ではなく、本当に詰まった案件だけ呼ばれる専門医になる。
強いモデルを節約するというより、強いモデルの探索力を、本当に必要な場所へ集中させる設計である。
7. 期間限定の上位プランを恒久インフラにしない
ここはかなり重要。
上位プランが今使えるからといって、その機能を前提に工場の心臓を作ると、プランを変えた瞬間に工場まで止まる。
だから期間限定で使うAIは、本体ではなくブースターにしたほうがいい。
残すべきなのは、
- task_id
- 状態遷移
- 成功条件
- プロンプト
- テスト方法
- 失敗ログ
- エスカレーション条件
である。
消えて困るのはモデルではなく、「そのモデルしか知らない運用ルール」。
上位モデルの利用期間中に、暗黙知を全部外へ出す。
AIを解約したら会社の業務フローまで記憶喪失になりました、では笑えない。
8. Opus 5.5が0→10まで自走するなら、無理にAIチームを増やさなくていい
マルチエージェントは楽しい。
組織図が作れる。 役職も作れる。 監督も作れる。 ログも増える。
そして最後に、人間がそのAI組織の総務部になる。
これは本末転倒である。
AnthropicはClaude Opus 5.5について、長時間の大規模コード作業、複数ツールを使うエージェント、複雑な仕事を少ない監督で進める用途を前面に出している。[5]
実際の自分の仕事で、Opus 5.5が、
「目的を渡す」 →「調査する」 →「実装する」 →「テストする」 →「直す」 →「完了報告する」
まで安定して走れるなら、そこへ寄せるほうが単純である。
1体で終わる仕事を、わざわざAI株式会社にしない。
複数モデル構成は、単一モデルでは散らかるところ、価格差が大きいところ、独立レビューが欲しいところだけでいい。
9. 最小構成は「共有キュー＋監督＋実行＋非常口」
最終的に、かなり小さくできる。
- 外部の質問や障害をtask_id付きでキューへ入れる
- Dotが優先順位と次の一手を決める
- Codexが具体作業をする
- Dotが結果を確認する
- 難航時だけAstraへ上げる
- 回答はsource_thread_idへ戻す
- deliveredまで確認して閉じる
- 1体で完遂できる仕事はOpus 5.5へ直接渡す
この構成なら、将来モデルを変えても、
manager executor advisor
の割り当てを変えるだけで済む。
モデル名をインフラにしない。 役割をインフラにする。
これが一番移行しやすい。
10. まとめ：強いAIを探すより、「どこで考えるのをやめるか」を決める
AI運用で意外と難しいのは、考えることではない。
考えるのを終えて、実行へ移すことである。
探索型AIは、世界を広げる。 監督型AIは、仕事を閉じる。 実行型AIは、手を動かす。
この3つを混ぜると、「すごいことは言っているのに終わらない」が起きる。
分けると、
Astra「別案が7つあります」 Dot「2番だけ検証」 Codex「直しました。テスト通過」 Dot「終了」
になる。
急に会社になった。
でも、人間が毎回部長をやらなくていいなら、その会社はかなり使える。
普段のループは小さく保つ。
強いモデルは常駐させるのではなく、詰まったときに呼ぶ。 そして一体で最後まで走れるモデルがあるなら、素直に一体で走らせる。
AIの数を増やすことが自動化ではない。
人間が途中で拾わなくても、仕事が閉じることが自動化である。
