Claude Codeと作ったAIオーケストレータを、私はなぜ使わなくなったのか
以前、私は Claude Code と一緒に dark-part-time-job というオーケストレーションシステムを作りました。
これです。
複数のAIエージェントを tmux 上に並べ、親分・若頭・若衆のような役割分担で開発タスクを進めるための仕組みです。名前からしてだいぶ治安が悪いですが、やりたかったことは意外とまじめでした。
親分がユーザーの指示を受け、若頭がタスクを分解し、若衆がそれぞれ実装します。ここで重要なのは、人間がworker一人ひとりに細かく指示を出すのではなく、タスク分解と割り振り自体もAIの仕事にしていたことです。タスクはYAMLキューで渡され、作業結果はレポートとして戻されます。さらに、git worktree を使って並列作業を分離する仕組みも持っていました。
このシステムで特に重視していたのが、yb というCLIを通じて、新規・既存を問わずどのリポジトリにも組み込めることでした。特定のプロジェクト専用の仕組みにするのではなく、任意のリポジトリに後からオーケストレーション層を注入できる形にしたかったのです。
当時はかなり真剣に使っていました。単なる実験ではなく、実際の開発作業に投入しながら改善を重ね、v1からv2への移行設計まで作っていました。かなりの時間を、このオーケストレーション自体の改善にも注いでいました。趣味プロジェクトの顔をしていますが、私はかなり本気でした。
ただ、今はもう使っていません。
この記事では、なぜそのような仕組みを作ったのか、実際に使って何が良かったのか、そしてなぜ今は使わなくなったのかを書きます。
解きたかったのは、コンテキストの混線でした
この仕組みを作った理由は、単にAIエージェントをたくさん並べたかったからだけではありません。もちろん、当時はそういう構成が少し流行っていたので、並べてみたかった気持ちもありました。tmuxにAIをずらっと並べると、それだけで何かすごいことをしている気分にはなれます。
一番大きかった問題意識は、作業に必要ない情報でコンテキストが埋まっていくことでした。
AIコーディングエージェントに長いタスクを任せると、セッションの中にいろいろな情報が混ざっていきます。全体方針、過去の判断、実装中の試行錯誤、エラーのログ、レビューの指摘、再作業の理由。気づくと、引っ越し直前の机みたいな状態になります。どれも完全に不要ではありませんが、常に同じ場所にあるべき情報でもありません。
監督者に必要な情報と、実際に手を動かす作業者に必要な情報は違います。
監督者は、全体の目的、進捗、判断の履歴を持つ必要があります。一方で、作業者に必要なのは、今やるべきタスク、触ってよいファイル、満たすべき条件です。
それなのに、1つのセッションで全部を抱えると、作業者のコンテキストに監督用の情報まで混ざってしまいます。逆に、監督者のコンテキストにも実装中の細かい試行錯誤が流れ込んでしまいます。
だから、監督者と作業者はそもそもセッションとして分けるべきだと考えていました。
Claudeに全体を見てもらい、Codexに手を動かしてほしかった
もうひとつのモチベーションは、モデルごとの得意不得意を分けて使いたかったことです。
当時の私は、Claude Opus は方針を考えたり、全体を見たり、文章化したりするのがとても強いと感じていました。監督者としてはかなり信頼していました。
一方で、実際にコードを書いて修正し、テストし、細かい作業を進める作業者としては、Codex を信じていました。小さな単位に切られたタスクであれば、きっちり最後までやり切る能力が高いと思っていたからです。
つまり、やりたかったのは「ClaudeかCodexか」を選ぶことではありませんでした。
Claudeに全体を見てもらい、Codexに手を動かしてもらう構成を作りたかったのです。
そのためには、単にモデルを切り替えるだけでは足りません。監督者と作業者を別セッションにし、役割ごとに必要なコンテキストだけを渡し、作業結果をレポートとして戻す仕組みが必要でした。
加えて、人間が毎回「このworkerにはこれ」「次はこのworker」と手で割り振るのでは、すぐに面倒になります。やりたかったのは、ユーザーは大きめの依頼を出し、AIの監督者側がそれを実装単位に分解し、適切なworkerへ流すことでした。人間が見たいのは、worker管理そのものではなく、最終的に仕事が進んでいるかどうかです。
その発想で作ったのが dark-part-time-job でした。
仕組みとしてはかなり素朴でした
仕組み自体は、今振り返るとかなり素朴です。壮大な名前に対して、やっていることはだいたいファイルとtmuxと根性です。
中心にあるのは yb というCLIです。
yb init を実行すると、対象リポジトリに .yamibaito/ という作業用ディレクトリを作ります。そこにプロンプト、設定、キュー、レポートを置きます。
ここはかなり意識して作っていました。新しく作るリポジトリだけでなく、すでに存在するリポジトリにも後から組み込めることが yb の強みでした。アプリケーション側の構造に深く入り込むのではなく、外側から .yamibaito/ を置き、yb start でtmuxセッションを立て、必要な作業状態をそのリポジトリ内に閉じ込める。そういう形です。
つまり、dark-part-time-job は「このリポジトリ専用のAIチーム」ではなく、「どのリポジトリにも派遣できるAIチーム」を目指していました。言い方はだいぶ怪しいですが、思想としてはここがかなり大事でした。
tmux セッションを起動すると、親分、若頭、複数のworkerがそれぞれ別ペインで立ち上がります。親分はユーザーから指示を受け、若頭にタスク分解を依頼します。若頭はYAMLでworker向けのタスクを書き出し、どのworkerに何をやらせるかを決めます。workerは割り振られたタスクを読んで作業します。作業が終わるとレポートを書き、yb collect がそれを集約します。
セッションを分けることで、監督者と作業者のコンテキストを分離できます。worktreeを分けることで、worker同士の作業も分離できます。
やっていることは単純ですが、当時欲しかった性質はかなり満たしていました。雑に言うと、AIたちに席を与え、若頭AIに紙を配らせ、終わったら報告書を出してもらう仕組みです。人間は配膳係をやらなくて済みます。
実際、便利でした
これは失敗作ではありませんでした。
複数のworkerにタスクを投げ、並列に実装させ、結果を集める体験はかなり良かったです。しかも、どのworkerに何をやらせるかを毎回人間が考えなくてよいのが大きかったです。「AIに丸投げする」のではなく、「AIの監督者に現場を回してもらう」感覚がありました。少なくとも画面上は、かなり仕事が進んでいるように見えます。
特に良かったのは、作業が構造化されたことです。
タスクがYAMLとして残り、レポートも残ります。worktreeで作業を分離でき、review/reworkのループも明示できます。
1つの長いセッションの中で全部を進めるより、何がどこまで進んでいるのかを把握しやすくなりました。自分でworkerを一人ずつ面倒見る必要も薄くなります。少なくとも当時の自分にとっては、AIエージェントをかなり制御しやすくなった感覚がありました。
使い込むと、ボトルネックが移動しました
ただ、使い込むほど別の問題が見えてきました。
最初は「1体のAIに全部やらせるとコンテキストが混ざる」という問題を解きたくて始めました。実際、セッションを分けることでその問題はある程度解消できました。
そこから先も、かなりの時間をオーケストレーションの改善に使いました。起動の安定化、タスク分割、レビュー、rework、レポート回収、プロンプト改善。使って出た問題を直し、また使い、また直す、ということを繰り返していました。
面白かったのは、このオーケストレーションシステム自体の改善も、かなり yb で回していたことです。yb を改善するために yb を使う。自分で作った仕組みに、自分自身の修理を手伝わせていました。セルフホストと言うと少し格好よすぎますが、少なくとも「自分で自分の開発現場に投入する」くらいのことはしていました。
しかし今度は、分けたものをどう管理するかが問題になりました。
tmux pane の起動タイミング、send-keys の失敗、YAMLキューの状態管理、report の上書き競合、collect 時のリセット事故、rework で既存のOK部分が消える問題、prompt の肥大化、review loop の長時間化、worker間の依存関係管理。
つまり、AIに仕事をさせるための仕組みを作った結果、その仕組み自体を保守する必要が出てきました。自動化のための自動化を手動で面倒見る時間が発生します。ここで少し冷静になります。
これは当たり前といえば当たり前です。セッションを分ければコンテキストはきれいになりますが、状態管理は外に出ます。役割を分ければ責務は明確になりますが、受け渡しの契約が必要になります。並列化すれば速くなる可能性はありますが、統合とレビューのコストも増えます。
さらに、自律改善ループもどきのようなものも組み込んでいました。
使っていて見つかった問題をフィードバックし、次の実行でよりよく動くようにする。考え方としては自然ですし、実際に改善もされました。ただ、その改善行動のために書いたプロンプトがどんどん大きくなっていきました。
「次はこの失敗を避けよう」「このケースではこう判断しよう」「このレース条件に注意しよう」と足していくうちに、最初からかなりのコンテキストを食うようになります。コンテキストを節約したくて役割を分けたのに、その役割を賢くするためのプロンプトがコンテキストを圧迫していく。かなり美しい悪循環です。美しくはないです。
しかも、各ロールのプロンプトは一度書いたら終わりではありません。
モデル側の能力や癖が変われば、親分、若頭、worker、reviewer それぞれのプロンプトも見直す必要があります。モデルが進化するほど、本来はプロンプトもそれに合わせて軽くしたり、役割を変えたりできるはずです。
しかし現実には、モデルの進化の速度に対して、こちらのプロンプト整備が追いつきませんでした。昨日まで必要だった注意書きが、今日はむしろ邪魔になることもあります。プロンプトは資産でもありますが、放っておくとだんだん地層になります。
改善レポートには「5並列は成立したが、後半は実質1worker稼働になった」といった分析も残っています。並列化したからといって、常に速くなるわけではありませんでした。
ボトルネックは、実装そのものから、タスク分割、レビュー、再作業、統合に移っていきました。
急にやめたわけではなく、だんだん使わなくなりました
今使っていない理由をひとつにまとめるのは、少し雑かもしれません。
dark-part-time-job は、自分の問題意識にはかなり合っていました。監督者と作業者を分けたい。ClaudeとCodexを役割で使い分けたい。作業状態をファイルとして残したい。そういう目的にはよく効いていました。
実際、しばらくはメインの作業環境としてかなり使っていました。
その時期に、Claude Code 側でも Agent Teams、つまりエージェントチームという仕組みがリリースされました。複数の Claude Code インスタンスをチームとして動かし、リーダーが作業を調整し、チームメンバーが独立したコンテキストで作業できる仕組みです。
ただ、その時点ですぐに dark-part-time-job を捨てようとは思いませんでした。
むしろ当時は、まだ自分のオーケストレータの方に優位性があると考えていました。理由は、トークンなどのコスト面とのバランスです。
dark-part-time-job では、監督者と作業者のセッションを分け、必要な情報だけをworkerに渡すことをかなり意識していました。小さく切った実装単位を Codex に渡す構成にすれば、全部を大きなコンテキストで抱えるよりも、コストと制御のバランスが良いと思っていました。
つまり、外部ツールが出てきたからすぐ負けた、という感じではありませんでした。むしろしばらくは「いや、こっちの方が細かく制御できるし、コストも読みやすい」と思っていました。自作ツールを信じる人間は、だいたい一度この顔になります。
それでも、日常的に使う道具としては、だんだん重くなっていきました。
毎回セッションを立て、キューを流し、workerの様子を見て、レポートを集め、必要ならreworkを回す。その一連の流れが、ある程度大きなタスクでは役に立つ一方、小さなタスクでは明らかに過剰でした。タスクの割り振り自体はAIに任せられても、仕組み全体を起動して見守る儀式は残ります。ちょっとした修正に対しては、やはり大きすぎました。
もうひとつ大きかったのは、モデルそのものの能力が変わっていったことです。
もともと私の中には、「Claudeには全体を見てもらい、Codexには手を動かしてもらう」という役割分担がありました。これは当時の体感として、かなり自然でした。
しかし、Claude Code 側のコーディング能力が上がってくると、その前提が少しずつ揺らぎます。監督者と作業者を外側の仕組みで分けなくても、Claude Code の中でかなりの範囲を任せられるのではないか、と思うようになりました。
その流れをさらに進めたのが、Opus 4.6 の登場でした。
Opus 4.6 はコーディング能力もかなり高いと聞いていました。実際に Claude Code で触っているうちに、ふと思いました。
これ、subagent と skills をちゃんと整備すれば、もう自前のオーケストレーションはほとんどいらないかもしれないな、と。
これは、Opus 4.6 のコーディング能力の向上があったから気づけたことでした。以前の自分は、Claude に全体を見てもらい、Codex に手を動かしてもらう構成をかなり自然に考えていました。しかし、Claude Code 側の作業能力が上がってくると、「監督者と作業者を完全に外部の仕組みで分ける必要はどれくらい残っているのか」と考えるようになりました。
とはいえ、その時点でも完全に Claude Code だけでよいとは思っていませんでした。
まだ、レビューや全体確認など、詰めが甘くなりそうな部分は GPT に見てもらいたい感覚がありました。なので少しずつ、Claude Code と Codex を画面2分割で使うようになりました。Claude Code に実装を進めてもらい、Codex にレビューや確認をしてもらう。これは自前のオーケストレータほど大げさではありませんが、自分の中ではかなり自然な移行先でした。
最後に追い打ちをかけたのが、まさかの OpenAI 側が Claude Code から Codex を呼び出せる plugin を用意したことです。
正直、ここで「自分のオーケストレーションは引退だな」と思いました。
これは単に「Codexも使えるようになった」という話ではありませんでした。
やりたかったことは、Claude と Codex を役割で組み合わせることでした。監督と作業、実装とレビュー、全体確認と細部の詰め。そこを自作のtmuxオーケストレータでつないでいたわけです。
その橋が、ツール側に用意されてしまいました。
でも、Claude Code の中で subagent や skills を整備でき、さらに必要なところで Codex を呼べるなら、かなり話が変わります。自分でtmux上に組織図を作らなくても、必要な役割分担をツール側に寄せられるようになってきました。
壊れていたから使わなくなったわけではありません。競合する仕組みが出た瞬間に不要になったわけでもありません。
Agent Teams が出ても、しばらくは自作側に優位性があると思っていました。Opus 4.6 で「Claude Code 側に寄せてもよいかもしれない」と思い始めました。Claude Code と Codex の2分割運用で、日常作業ではそれで足りる場面が増えました。そして Codex plugin の登場で、ついに「これはもう引退でいいな」となりました。
強い道具ではありましたが、役目を終えた感じがありました。自作オーケストレータ、ここで静かに暖簾を下ろします。
学び
このシステムを作ったことで学んだのは、AIエージェント開発で本当に難しいのは「並列に動かすこと」ではない、ということでした。
今は使っていませんが、作ってよかったとはかなり思っています。
久しぶりに熱中できるものがありました。実際に使い、問題を見つけ、直し、また使う。その繰り返し自体がかなり楽しかったです。AIエージェントをどう扱うかについて、頭の中で考えているだけではわからないことを、かなり身体で覚えた感覚があります。
結果として日常利用からは引退しましたが、あの時間が無駄だったとは全く思っていません。むしろ、今の Claude Code や Codex の使い方は、このオーケストレータを作っていたときの試行錯誤の上にあります。
難しいのは、どこで判断を分離するかです。
どこまでをスクリプトに任せ、どこからをLLMに判断させるか。レビュー結果をどう保持するか。再作業で文脈を壊さないようにするか。並列作業の統合をどう安全にするか。
v2設計で「1エージェント1判断」という原則に向かったのは、その反省からでした。
LLMに何でも判断させると、柔軟にはなりますが、再現性は落ちます。逆に、スクリプトに寄せすぎると安定しますが、変化に弱くなります。その境界をどこに置くかが、オーケストレーションの一番難しいところでした。
今ならどうするか
今なら、同じものをもう一度そのまま作ることはしないと思います。
tmuxで大量のエージェントを並べるより、Claude Code 側の subagent と skills をまず整備すると思います。
タスク分割はMarkdownやYAMLで明示します。worktree管理は既存ツールに寄せます。並列化は本当に独立した作業だけに限定します。状態管理はLLMではなくスクリプトに寄せます。review/reworkは小さく回します。
そして、レビューや全体確認のように別の視点が欲しいところで Codex を呼びます。オーケストレータは「常駐する司令塔」ではなく、「必要な時だけ呼ぶ補助ツール」にすると思います。
巨大なAI組織を作るより、人間が把握できるサイズの自動化を積む方が、今は実用的だと感じています。
最近の使い分け
最近は、用途によって使う道具をかなり分けています。
調べ物や簡単な実装は、Codex のネイティブアプリを使っています。特にアプリの感触がかなり良くて、かなりおすすめです。軽く調べて、少し直して、確認する、くらいの作業にはかなり向いていると感じています。
最新情報のキャッチアップも、最近は Codex App からやることが増えました。特にオートメーション機能が便利です。自分で毎回見に行くのではなく、気になる領域を継続的に追わせておけるので、情報収集の入口としてかなり使いやすいです。
ちなみに、この記事も Codex App を使って書いています。こういう文章の構成を一緒に考えたり、既存の下書きを少しずつ直したりする用途では、かなり相性が良いです。昔なら自作オーケストレータで役割を分けていたような作業も、今はだいぶ軽い道具で済むようになりました。
一方で、ちゃんとした開発実装をするときは、ターミナルから Claude Code を呼び出して実装しています。こちらは subagent と skills をきちんと整備しました。
今の自分にとっては、昔のように外側に大きなオーケストレータを立てるより、Claude Code 側の subagent と skills を整えておき、必要に応じて Codex を併用する方が自然です。
ただ、これで全部解決したわけでもありません。
最近は Opus 4.7 になってから、明示的に指示しないと subagent に振ってくれず、結果として実装が遅いと感じることがあります。ここはまだ「どうにかならんかな」と思っています。
まとめ
dark-part-time-job は、かなり使いましたし、かなり学びがありました。名前のわりに、得られた学びは健全でした。
作った当時の問題意識は、今でも間違っていなかったと思います。監督者と作業者のコンテキストは分けた方がいいですし、モデルごとの得意不得意を前提に役割を分ける発想も有効でした。
ただ、それを実現するための仕組みとして、当時の dark-part-time-job はだんだん重くなっていきました。
さらに、Claude Code 側の能力が上がり、subagent や skills で役割分担を作れるようになり、必要な場面で Codex も呼べるようになってきました。自分が外側に作っていたオーケストレーション層のかなりの部分が、ツール側に吸収されていった感覚があります。
AIを複数並べれば、自動的に開発が速くなるわけではありません。
重要なのは、判断の境界、状態の管理、レビューの設計、そして人間がどこで介入するかです。
このシステムは、今の自分にとっては日常的に使う道具ではなくなりました。
でも、AIエージェントをどう扱うべきかを考えるうえで、かなり重要な実験でした。
さいごに
Xもたまに呟いています。
よかったらフォローしてみてください。
Discussion