はじめに
どうも、@Yo19920508です。
第2部では、
Claude Code、Codex、Geminiにそれぞれ役割を持たせて、AI開発チームとして動かす
という話を書きました。
Claude Codeが実装。
Codexが厳しめレビュー。
Geminiが別視点レビュー。
CIが品質チェック。
Orchestratorが全体の進行管理。
ここまで来ると、
「もうほぼ完成やん」
と思います。
私も思いました。
甘かったです。
普通に止まります。
AIは強い。
役割も決めた。
レビューもできる。
CIもある。
でも、
途中で何か起きるたびに、
「確認してください」
「判断をお願いします」
「テストに失敗しました」
「次の指示をください」
で止まる。
いや。
お前らハンター試験受けに来て、最初の階段で座り込むな。
そこで第3部では、
AI開発を本当に自律化するために、一番重要だった「止まらない設計」
について書きます。
AIはエラーより「確認してください」で止まる
最初に一番困ったのがこれです。
AIに実装させる。
↓
テスト失敗。
↓
AI、
「テストが失敗しました。確認してください。」
いや。
確認するのはお前や。
これ、ハンター試験の途中でキルアが、
「どうする？」
って聞いてくるようなもんです。
登れ。
まだ試験始まってすらない。
実際の開発では、
- TypeScript Error
- Lint Error
- Unit Test Failure
- Build Failure
- Review指摘
- Merge Conflict
- 想定外のファイル差分
みたいなことは普通に起こります。
これらが起きるたびに人間へ戻ってきたら、
結局私は、
AIの進捗監視係
になります。
第1部からずっと逃げたかった仕事です。
「止まっていい条件」を先に決めた
なので私は、
AIに、
「できるだけ自律的に動いてね」
とは言いませんでした。
曖昧やからです。
代わりに、
止まっていい条件を明確にしました。
基本ルールはかなりシンプルです。
AIが止まっていいのは、
大きく2つだけ。
- 次に進むための指示そのものがまだ存在しない
- 人間本人の判断・確認・承認が本当に必要
それ以外は、
止まらず自分で解決する。
これを絶対ルールにしました。
ハンター試験で毎回答え聞くな
HUNTER×HUNTERのハンター試験って、
基本的に、
「自分で考えて進め」
の世界です。
試験官が毎回、
「次は右に行ってください」
「ここでジャンプしてください」
「敵が出たので戦ってください」
なんて言いません。
そんなもん、
ただの観光ツアーです。
AI開発も同じです。
テストが落ちた。
直す。
レビューで指摘された。
直す。
CIが失敗した。
原因を調べる。
修正する。
もう一回CI。
そこはハンター試験で言う、
自力で突破する区間
です。
いちいち会長を呼ばない。
CI失敗は「失敗」ではなく次の入力
ここはかなり考え方が変わった部分です。
最初は、
CI_FAILED
を、
失敗状態
として見ていました。
でも自律化を考えると違います。
CI Failureは、
次の修正に必要な情報
です。
例えば、
TypeError:
Property 'userId' does not exist on type 'Session'
が出た。
普通のシステムだと、
FAILED
で止まる。
でもOrchestratorでは、
CI_FAILED
↓
CIログ取得
↓
Claude Codeへ修正依頼
↓
再実装
↓
再CI
と進めます。
つまり、
CI_FAILED = 終了ではない。
CI_FAILED = 次にClaudeへ渡すContextが増えた。
という扱いです。
キルアなら一回失敗したくらいで帰らん
例えばキルアが戦闘中に、
「一発攻撃を外した」
とします。
そこで、
「攻撃に失敗しました。@Yo19920508さん、確認してください。」
って帰ってきたら、
たぶん私は、
キルアの頭の針より先にLANケーブル抜きます。
失敗したなら、
次の行動を考える。
相手が速いなら速度を変える。
攻撃が効かないなら別の方法を使う。
AI開発も同じです。
失敗結果は、
停止理由ではなく、判断材料
です。
Review指摘も勝手に直す
CodexやGeminiのレビューで、
問題が見つかったとします。
例えば、
Codex:
この処理は並列実行時にrace conditionが発生する可能性があります。
普通なら、
人間が見て、
「Claude、これ直して」
と指示します。
でも、
Orchestratorがいるなら、
人間を挟む必要はありません。
REVIEW_REQUIRED
↓
Codex / Gemini Review
↓
Review Aggregation
↓
REPAIR_REQUIRED
↓
Claude Code
↓
修正
↓
再レビュー
まで自動で回します。
人間が確認するのは、
レビュー指摘が来たこと
ではなく、
AIだけでは判断できない問題が来たとき
です。
人間を呼ぶ基準を厳しくする
ここが自律開発でかなり重要でした。
AIは安全側に倒れるので、
結構すぐ人間を呼びたがります。
例えば、
「2つの実装方法があります。どちらにしますか？」
これだけなら、
本来はAI自身で判断できるケースも多い。
既存設計。
既存コード。
Issue。
過去の実装方針。
これらを見て、
より自然な方を選べるなら、
勝手に選ぶべきです。
一方、
本当に人間を呼ぶべきケースもあります。
例えば、
- 仕様そのものが未定
- 本番データ削除の可能性がある
- 課金が発生する
- 権限変更が必要
- 外部サービスへの公開操作
- Mergeの最終承認
- ビジネス判断が必要
こういうのは止まる。
つまり、
「迷ったら人間」ではなく、「人間しか決められないなら人間」
です。
クラピカぐらい条件を厳しくする
クラピカの制約と誓約ぐらい、
止まる条件は厳しくしました。
「この条件を満たした時だけ止まってよい。」
それ以外は、
止まらない。
AIが、
「ちょっと不安なので確認したいです」
と言っても、
条件外なら進む。
不安だけで止まっていたら、
暗黒大陸どころかヨークシンにも着きません。
ただし無限ループはもっと怖い
ここまで読むと、
「じゃあ何があっても永久に直し続けるん？」
となります。
それはそれで怖い。
例えば、
CI失敗
↓
Claude修正
↓
CI失敗
↓
Claude修正
↓
CI失敗
↓
Claude修正
↓
...
と永久に続いたら、
止まらないどころか、
蟻編ぐらい長くなります。
しかもTokenも消える。
なので、
自律化 = 無限に頑張らせる
ではありません。
必要なのは、
安全に再試行する仕組み
です。
Retryには上限と意味を持たせる
再試行するときに大事なのは、
毎回同じことをやらせないことです。
例えば1回目の修正が失敗した。
2回目も、
まったく同じContextで、
まったく同じ指示を送る。
これでは、
同じ結果になる可能性が高い。
なのでRetry時には、
前回失敗した情報を追加します。
例えば、
1回目:
Issue + diff
↓
CI FAILED
↓
2回目:
Issue
+ diff
+ CI error log
+ 前回の修正内容
↓
まだ失敗
↓
3回目:
Issue
+ diff
+ CI error log
+ 修正履歴
+ 別アプローチを検討する指示
みたいに、
Retryするたびに状況認識を更新する
方が自然です。
ゴンみたいに同じジャンケングーを撃ち続けない
ゴンが、
相手にジャンケングーを避けられた。
またジャンケングー。
また避けられた。
またジャンケングー。
また避けられた。
これを100回続けたら、
さすがにキルアも、
「ゴン、それもう無理だよ」
って言います。
AIも同じです。
Retryというのは、
同じことをもう一回やることではなく、失敗から次の手を変えること
です。
Stateを持たせないと自律化できない
もう一つ重要なのが、
今どこまで終わっているか
を覚えておくことです。
例えば、
Claudeが実装した。
Codex Reviewも通った。
Gemini Reviewも通った。
最後のCIだけ落ちた。
この状態で再実行したときに、
全部最初からやり直したら無駄です。
Issue
↓
Implementation DONE
↓
Codex Review DONE
↓
Gemini Review DONE
↓
CI FAILED
なら、
次は、
CI FAILED
↓
Repair
↓
必要な再レビュー
↓
CI
から続ければいい。
この状態管理がないと、
毎回記憶喪失になります。
ゴンが毎朝くじら島から始まったら終わらん
イメージしてください。
ゴンがハンター試験会場に着く。
次の日。
起きたら、
くじら島。
また船に乗る。
試験会場に着く。
次の日。
また、
くじら島。
いつハンターになんねん。
AI開発でも、
成功済み工程まで毎回やり直すと同じことが起きます。
だからOrchestrator側で、
どこまで成功したか
をStateとして持つ必要があります。
GitHubを「冒険の記録」にする
このState管理と相性が良かったのがGitHubです。
Issue。
Branch。
Commit。
PR。
CI。
Review。
全部、
開発の進行状況が残る
からです。
GitHubは、
ハンターライセンス + 冒険の記録帳
みたいなもんです。
誰が何をやったか。
今どこにいるか。
何が失敗したか。
何を直したか。
全部残ります。
Orchestratorは、
それを見て、
「今はここやな」
と判断します。
READY FOR HUMANを明確に作る
そして、
AI側で全部終わったら、
最終的に、
READY_FOR_HUMAN
へ移します。
ここが重要です。
AIの仕事が終わったら、
人間へ、
「たぶん終わりました」
ではなく、
明確に人間のターンへ渡す。
例えば、
Implementation: PASS
Codex Review: PASS
Gemini Review: PASS
CI: PASS
Security Check: PASS
Status: READY_FOR_HUMAN
ここまで来たら、
私がPRを見ます。
Mergeするか決めます。
つまり、
人間は、
途中経過の監視者
ではなく、
最後の意思決定者
になります。
これが私の欲しかった形でした。
ネテロ会長を雑用で呼ぶな
ハンター協会の会長に、
「ドア開きません」
「テスト落ちました」
「Lint Errorです」
って毎回報告しに行くやつがおったら、
たぶんプロハンター失格です。
会長を呼ぶのは、
会長しか決められない時だけ。
私も同じです。
型エラーで呼ばない。
Lintで呼ばない。
Test失敗で呼ばない。
レビュー指摘で呼ばない。
全部AI側で直してください。
そして、
「全部終わりました。Mergeしますか？」
で初めて呼んでください。
私はネテロ会長ほど強くありませんが、
雑用をしたくない気持ちは同じです。
自律化は「AIを自由にする」ことではない
ここまで作ってきて、
一番勘違いしやすいと思ったのが、
自律化 = AIを好き勝手に動かす
ではないということです。
むしろ逆です。
自律化するほど、
ルールは必要になります。
- どこまで触っていいか
- どのBranchを使うか
- masterへ直接pushしていいか
- force pushしていいか
- 何回Retryしていいか
- どの条件で人間を呼ぶか
- どの状態から再開するか
- 何を成功とみなすか
この制約があるから、
安心して自律的に動かせます。
念能力も、
制約が強いほど強くなる。
AI Orchestratorも同じです。
制約があるから自律性を上げられる。
これはかなり大事な考え方でした。
最終的なループ
最終的に、
私のOrchestratorが目指した流れはこうです。
Issue
↓
Orchestrator
↓
Claude Code
↓
Implementation
↓
Codex Review
+
Gemini Review
↓
問題あり？
├─ YES
│ ↓
│ Claude Repair
│ ↓
│ 再レビュー
│
└─ NO
↓
CI
↓
CI失敗？
├─ YES
│ ↓
│ Claude Repair
│ ↓
│ CI
│
└─ NO
↓
READY_FOR_HUMAN
↓
私
↓
Merge判断
基本的に、
私が途中で出てきません。
ここが重要です。
第3部まとめ
3部作を通して、
私が作りたかったものは、
単なるAIコーディング環境ではありませんでした。
第1部では、
AIにコードを書かせるだけでは、人間の仕事は減らない
というところから始まりました。
第2部では、
Claude Code、Codex、Geminiに役割を与えて、AI開発チームにする
という話をしました。
そして第3部では、
人間しか判断できないこと以外では止まらせない
という設計にしました。
強い念能力者を集めただけでは、
暗黒大陸には行けません。
誰が何をするのか。
どこで判断するのか。
失敗したらどうするのか。
どの条件で撤退するのか。
それを決める仕組みが必要です。
AI開発も同じでした。
最後に
ai-dev-orchestrator を作り始めたときは、
正直、
「Claude CodeとかCodexを自動で繋げたら面白そう」
ぐらいでした。
でも作っていくうちに、
AIの性能より、
AIをどう働かせるか
の方が重要になってきました。
コードを書くAI。
レビューするAI。
別視点で見るAI。
品質を判定するCI。
それらを繋ぐOrchestrator。
そして、
最後に判断する人間。
ここまで分けると、
AI駆動開発というより、
AIで開発組織そのものを作っている
感覚に近いです。
まだ改善できるところはあります。
でも少なくとも、
最初に目指していた、
「昨日頼んどいたやつ、どうなった？」
と見に行ったら、
「実装済み。レビュー済み。CI通過済み。あとはMergeするだけです。」
というところまでは来ました。
やっとです。
3部かかりました。
長かった。
冨樫義博（とがし よしひろ） 先生の休載と比べたら
短かったと思います。
たぶん。
3部作まとめ
AI側で解決できる問題では止まらないようにした。
人間は最後の判断だけ。
これが、
私が作った
ai-dev-orchestrator
です。
AIにコードを書かせる。
から、
AIに開発を任せる。
へ。
ようやく、
コントローラーを置けました。
……と思ったら、
次のIssueが来ました。
エピローグ
ここまで読んでいただき、ありがとうございました。
第1部では、
AIにコードを書かせるだけでは足りない。
というところから始まりました。
第2部では、
Claude Code、Codex、Geminiに役割を与えて、
AIを「使う」から「チームとして働かせる」
方向へ進みました。
そして第3部では、
人間しか判断できないこと以外では止まらない
というルールを入れました。
結果として、
私が最初に欲しかった、
「昨日頼んどいたやつ、どうなった？」
と見に行ったら、
「実装済みです。
レビュー済みです。
CIも通っています。
あとはMergeするだけです。」
という状態まで持っていけるようになりました。
ここまで来ると、
AIにコードを書かせているというより、
AIに開発そのものを任せている
感覚に近いです。
そして、もし誰かに、
「その仕組み、どうやって作ったん？」
と聞かれたら、
私はたぶんこう答えます。
欲しけりゃ作ればええ。
Claudeも、Codexも、Geminiもある。
あとは全部つなげるだけや。
そうして人々は、
AIにコードを書かせ、
AIにレビューさせ、
AIにCIを直させ、
最後に人間がMergeボタンを押す時代へ向かっていく。
世はまさに、大AI開発時代。
……
そして今日も、
GitHubには新しいIssueが追加される。
私の冒険は、
まだ終わらない。