0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【第1部】AI開発オーケストレーターを作った話

0
Last updated at Posted at 2026-09-03

はじめに

どうも、@Yo19920508です。

最近、Claude CodeやCodex、Geminiを使って開発してる人もだいぶ増えてきました。

私も最初は、

「うわ、AIめっちゃコード書くやん」
「もうこれエンジニアいらんのちゃう?」
「私、明日から昼まで寝れるんちゃう?」

とか思ってました。

甘かったです。

全然寝られへん。

むしろAIが増えれば増えるほど、

「Claude、終わった?」
「Codex、レビューした?」
「Gemini、お前はどう思う?」
「CI落ちてるで」
「誰か直して」
「いや、なんで全員こっち見てんねん」

みたいな状態になってきました。

これ、会社でいうと部下が3人増えたのに、全員めちゃくちゃ優秀やけど、

全員、仕事が終わるたびに私のデスクまで来て「次どうします?」って聞いてくる状態

なんですよ。

しんどい。

AIを使って楽するはずが、AIの上司として忙しくなってる。

そこで私は気付きました。

これ、コードを書く作業はAI化できてるけど、開発そのものは全然AI化できてへんやん。

ということで、

「じゃあAIたちを勝手に働かせる仕組み作ったらええやん」

となって作り始めたのが、今回の

ai-dev-orchestrator

です。


AI開発、ドラクエで言うと「さくせん」がない

Claude Codeはかなり優秀です。

指示したら実装してくれるし、テストも書くし、バグも直してくれる。

ドラクエでいうと、レベル99の勇者みたいなもんです。

めちゃくちゃ強い。

ところが問題があります。

こいつ、

「さくせん」が設定されてない。

毎回、

  • 次はこの敵倒して
  • 次はこの洞窟行って
  • 宝箱取って
  • 回復して
  • ボス倒したら戻ってきて

まで人間が指示してる。

いやもう、

それファミコンのドラクエ1やないか。

仲間おらんし、全部自分で指示せなあかん。

今のAI開発って、割とこれに近いと思っています。

AI自体はめちゃくちゃ賢くなってる。

でも、

  1. Issueを確認する
  2. 実装する
  3. テストする
  4. レビューする
  5. 修正する
  6. CIを確認する
  7. 次へ進む

この 「仕事の流れ」 は、まだ人間が繋いでることが多い。

Claudeが実装を終えたら、人間がCodexにレビューを頼む。

Codexが問題を見つけたら、人間がClaudeに戻す。

Claudeが修正したら、人間がCIを見る。

CIが失敗したら、

「Claudeさん、CI落ちてますよ」

って伝える。

いや。

見たら分かるやろ。

なんで私が伝書鳩せなあかんねん。


船長が全部やってる

理想的な開発チームって、麦わらの一味みたいなもんやと思っています。

  • ゾロは戦う
  • ナミは航海する
  • サンジは飯を作る
  • チョッパーは治療する

それぞれ役割があります。

これがもし、

ルフィ「ゾロ、敵倒して」
ゾロ「倒したで」
ルフィ「次、ナミに航路聞いてきて」
ナミ「航路出したで」
ルフィ「今度はサンジに飯作るよう言って」
サンジ「作ったで」

って毎回ルフィが中継してたらどうでしょう。

海賊王になる前にルフィが過労死します。

私がなりかけてたのが、これです。

Claude Code、Codex、Gemini。

せっかく能力の違うAIがいるんやから、それぞれ勝手に連携してくれたらええ。

私は最終的に、

「お、できたん? ほな見るわ」

ぐらいでいたい。

これが今回の発想のスタートでした。


私が作りたかったもの

目指したのは、単なるAIコーディングツールではありません。

AIだけで開発工程そのものを前に進める仕組み

です。

ざっくりいうと、こんな感じです。

GitHub
  ↓
AI Development Orchestrator
  ↓
Claude Code:実装・修正
  ↓
Codex / Gemini:レビュー
  ↓
問題あり
  ↓
Claude Codeへ修正依頼
  ↓
CI
  ↓
失敗したら再修正
  ↓
READY FOR HUMAN
  ↓
人間が最終確認・Merge

GitHubでやることが決まる。

Orchestratorが仕事を拾う。

Claude Codeが実装する。

CodexとGeminiがレビューする。

問題があればClaudeに戻す。

Claudeが修正する。

CIを流す。

失敗したら原因を見てまた修正する。

全部通ったら、

「人間の確認が必要です」

という状態まで持ってくる。

そこで初めて私が登場します。

理想としては、

「昨日頼んどいたやつどうなった?」

と見に行ったら、

PRできてます。
レビュー終わってます。
指摘も修正済みです。
CI通ってます。
あとはあなたがMergeするだけです。

となっていてほしい。

めちゃくちゃええやん。

これなら私は船長です。

甲板掃除から料理から航海まで全部指示する雑用係ではありません。


Orchestratorって何するん?

名前だけ見ると、なんか急に強そうです。

AI Development Orchestrator

めちゃくちゃラスボス感あります。

ただ、やってることは割とシンプルです。

オーケストラの指揮者と同じで、

「誰に、いつ、何をやらせるか」

を管理します。

役割としては、こんな感じです。

担当 役割
Claude Code 実装・修正
Codex 設計・正確性・Securityレビュー
Gemini Edge Case・別視点レビュー
GitHub Issue・PR・成果物・状態管理
CI テスト・品質ゲート
Orchestrator 全体の進行管理

例えばClaudeが実装を終えたとします。

普通ならそこで人間が見に行って、

「次Codexレビューして」

と指示します。

でもOrchestratorがいれば、

「実装終わったな。ほなレビュー工程や」

と勝手に進めます。

Codexが、

「ここバグの可能性あるで」

と言ったら、

「Claude、これ直して」

と戻します。

Claudeが直したら、

「もう一回確認しよか」

とレビューします。

つまり私は、

AI同士の会話にいちいち参加せんでええ。

これがめちゃくちゃ大きかったです。


一番大事にしたルール

この仕組みを作るとき、かなり重要にしたルールがあります。

それが、

AI側で解決できる問題では止まらない

というルールです。

例えば、

CIが落ちた。

止まらない。

テストが失敗した。

止まらない。

レビュー指摘が来た。

止まらない。

実装ミスが見つかった。

止まらない。

よくあるAIエージェントやと、

テストに失敗しました。確認してください。

みたいな顔して止まることがあります。

いやいや。

そこからがお前の仕事や。

スライムに遭遇するたび、

「敵が出ました。戦いますか?」

って確認されたら、5分でコントローラー投げます。

敵が出たら戦ってください。

HP減ったら回復してください。

毒になったら毒消し使ってください。

そのぐらいは自分でやってくれ。

AI開発も同じです。

私のOrchestratorでは、基本的に

「人間しか判断できないこと以外は勝手に進める」

という考え方にしました。

逆に止まっていいのは、大きく2つだけです。

  1. 次に何を作るか、人間からまだ指示されていないとき
  2. 仕様判断や承認など、人間本人の確認が必要なとき

それ以外は、

「頑張って。」

です。

かなりブラック企業みたいになってきました。

ただしAIなので労基は来ません。

たぶん。


でも勝手にmasterへ突っ込ませるのは怖い

ここで当然こう思います。

「そんな勝手にAI動かして大丈夫なん?」

大丈夫ではありません。

無制限に動かしたら普通に怖いです。

AIを自律的に動かすのと、

ルフィに「masterだけは好きにしてええで」と言うのは話が違います。

あいつ、

たぶん一回は直接pushします。

しかも悪気はありません。

なので、自律化すると同時に安全装置もかなり重要になります。

例えば、

  • masterへ直接pushさせない
  • force pushさせない
  • CIが通るまで完成扱いにしない
  • レビュー工程を飛ばさない
  • 人間の最終承認なしでMergeしない
  • 同じ処理を無限ループさせない
  • AIが勝手に作業範囲を広げすぎない

といった制御を入れます。

つまり、

自由に働かせるけど、船からは降ろさない。

そんな感じです。


そして完成した

最初は、

「ClaudeとCodexとGeminiを自動で回せたら面白そうやな」

ぐらいでした。

ところが作っていくうちに、

  • 状態管理が必要になり
  • レビュー結果の扱いを決め
  • CI失敗時の再試行を作り
  • 停止条件を決め
  • GitHubとの連携を作り
  • AIごとの役割を整理し
  • 安全装置を追加し

気付いたら普通に一つの開発基盤になっていました。

そして今は、

ai-dev-orchestrator自身を作るために作ったOrchestratorが、別の開発プロジェクトを動かすところまで来ています。

メタい。

ドラクエで言うと、

勇者を育てるために作った育成システムが、次の勇者を勝手に育て始めた

みたいな状態です。

もう私は、

ルイーダの酒場のおっちゃんでええんちゃうか

と思っています。


第1部まとめ

今回やりたかったことを一言で言うと、

「AIにコードを書かせる」から、「AIに開発を任せる」へ進みたかった。

これです。

Claude Code単体でも十分強いです。

Codexも強い。

Geminiも強い。

ただ、それぞれを人間が毎回操作していたら、

AIが増えるほど管理コストも増えます。

だから私は、

AIを増やすのではなく、AIがチームとして働く仕組みを作る

ことにしました。

次回は、

Claude Code・Codex・Geminiに、それぞれどんな役割を持たせたのか。

そして、

どうやってAI同士にレビュー・修正を回させているのか。

この辺をもう少し技術的に書いていきます。

たぶん第2部は、第1部よりコード多めです。

でも安心してください。

ちゃんと読みやすいように書きます


次回

第2部:Claude Code・Codex・Geminiで「AI開発チーム」を作る

  • Claude Codeを実装担当にした理由
  • CodexとGeminiをレビュー側に置いた理由
  • 複数AIに同じ仕事をさせない設計
  • AIレビューの結果をどう扱うか
  • Tokenを無駄遣いしないためのContext設計
  • Review → Repair → CIの自律ループ
  • AI同士を『第7班』にすると誰が誰なのか

を書いていく予定です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?