「AIにコードを書かせる」はもう珍しくないです。でも今回かなり衝撃だったのは、ただ書かせるだけではなく、原因調査、修正、確認、ダメなら再修正まで回る形に持っていけたことでした。
しかも自分はガチの開発者というより、まだまだ素人寄りです。それでも Codex の環境を整えて、入口と完了条件をかなり厳しく決めるだけで、「自律で実装から検証まで回す社長AI」みたいな運用が現実になりました。これは正直、超すげーです。
ずっと直らなかったバグが、調査して、直して、確認して、まだダメならもう一回やる。そこまで自律で進んだ体験は、単にモデルが賢いというより、環境設計と役割設計の勝ちでした。
以前は何がつらかったのか
以前の自分の AI 活用は、かなり典型的な詰まり方をしていました。
- 「直しました」→「いや直ってない」の往復が多い
- agent や workflow を増やしても、結局どれを使えばいいか分からない
- 指令室 repo と外部 agent 群が分かれていて、実戦では使いこなせない
- 日本語の長文ルール、文字化けした文書、散らかった指示が実行系にうまく読まれない
一番きつかったのは、AI がコードを書けること自体よりも、「直したつもり」で止まりやすいことでした。人間側が毎回チェック役をやらないといけないので、楽になったようで、実は別の面倒に置き換わっていただけでした。
転換点は「入口を減らす」だった
そこで発想を変えました。たくさんの agent を表に並べるのではなく、入口を 2 つだけに絞りました。
grill-meで設計を 1 問ずつ詰めるceo-orchestratorで実装、確認、再修正、最終確認まで回す
ここがかなり大きかったです。素人目線だと、agent が多いことは安心ではなく、むしろ混乱の原因でした。どれを呼べばいいのか、何が違うのか、いつ切り替えるのかが分からないからです。
それよりも重要だったのは、「最後まで走る監督役」を作ることでした。途中で賢い役が何人いるかより、完了まで責任を持つ 1 人がいるかの方が、体験が圧倒的によくなりました。
grill-me がよかった理由
grill-me に対しては、「全部自律でやって、最後まで確認まで回す社長AIを作りたい」と、そのまま伝えました。すると、必要な役割、止まる条件、完了条件を 1 問ずつ詰めていけます。
これのいいところは、素人でも設計を会話で固められることです。最初から綺麗な仕様書を書けなくても、「何を自律化したいのか」「どこで人間承認にするのか」「何をもって完了とするのか」を順番に言語化できます。
しかも自分の場合、そもそも「何を決めればいいのか」のアイディア自体があまりありませんでした。こんな感じで決めたらいいのかも、という発想すら弱かったです。
でも grill-me を使うと、「これはどうする？」「それはどうする？」と勝手に問いを前に進めてくれます。だから素人でも、最初に優秀な設計案を持っている必要がありません。何のアイディアもなくても、会話に答えていくうちに必要な論点が埋まっていく。この体験はかなりすごかったです。
参考にしたのは、mattpocock の grill-me です。
ceo-orchestrator がハマった理由
設計が固まったら、実行側は ceo-orchestrator に寄せました。ここで効いたのは、依頼を受けた瞬間に必ず次の 4 つへ整理することです。
- Objective
- Deliverables
- Constraints
- Acceptance
そのあと内部では、だいたい次の流れで仕事を進めさせます。
- Research / PM
- Design / UI if needed
- Engineer
- Debugger / QA
- retry
- CEO final check
つまり「コードを書く担当」だけでは終わらせず、「確認担当」「やり直し判断」「最終承認」まで 1 本の流れとして持たせるわけです。
ここが以前との一番の違いでした。昔は実装力だけを見ていましたが、実際に欲しかったのは完了までの実行力でした。
厳しくした完成条件
この社長AIで一番効いたのは、自由度を上げたことではなく、完了条件を厳しくしたことです。
- UI 変更はスクリーンショット必須
- API、ロジック、バッチ変更は PASS / FAIL とログ必須
- テスト失敗や未確認が 1 つでもあれば完了にしない
- 最後の報告は
Confirmed / Unverified / Residual Risks / Evidenceの 4 項目固定
つまり「たぶん動く」「見た感じ大丈夫」を禁止しました。これをやると、AI の出力が急に実務っぽくなります。
AI に全部任せるなら、自由にさせるより、どこで止まり、何を証拠に完了と言うかを厳しく固定した方が強いです。ここはかなり意外でした。
push だけは人間承認にした
一方で、全部を完全自動にしたわけではありません。外に出る操作だけは明確に人間承認にしました。
- push
- release
- 外部公開
- 破壊的なデータ操作
- 請求や認証まわりの変更
逆に言うと、それ以外の普段の実装、確認、再修正は自動で進めさせる前提にしました。ここを分けると、安心感と速度のバランスがかなりよくなります。
repo 設計も作り直した
もう 1 つ大きかったのは、既存 repo を無理やり直すより、新しく codex-solo-company-os を切ったことです。
Codex 専用に絞ることで、他ツール対応の複雑さを捨てられました。いろんな環境に配慮しすぎると、ルールも入口も増えて、結局いちばん使う本人が迷います。
この repo では、次の役割をかなり明確にしました。
- skill の正本は
skills/ - 完了条件の正本は
verification/acceptance-checklist.md - 各 PC への導入は
scripts/install.ps1
つまり、ノリでその場しのぎの運用をするのではなく、repo 自体を社長AIの運用ルール集として固定したわけです。最小構成にしたことで、迷わず回せるようになりました。
各部署の考え方は内部に隠した
社長AIの内部で使う各部署の考え方には、agency-agents の skill / agent 集をかなり参考にしました。
ただし、ここで学んだのは「たくさん見せれば便利」ではなかったです。むしろ内部では参考にしつつ、入口としては見せない方が使いやすい、ということでした。
ユーザーから見えるのは 2 つだけでよくて、必要な役割分担は内部で勝手に回る。それくらいの方が、素人でも実用になります。
一番伝えたいこと
今回いちばん言いたいのはこれです。
AI を増やすことより、入口を減らして、完了条件を厳しくした方が体験は一気によくなる。
すごかったのはモデル性能そのものだけではなく、環境設計と役割設計でした。もっと言うと、「AI に何をさせるか」以上に、「AI がどこで止まり、何を証拠に完了と言うか」の方が大事でした。
これはプロンプト芸の話ではなく、運用設計の話です。
AI に全部任せたいなら、自由にさせるより、厳しい完了条件を置く方がむしろうまくいく。素人でも、入口を 2 つに絞ればかなり戦えます。
次は、この社長AIを別の PC に持っていっても同じように動くかを試したいです。そこまで再現できたら、かなり本物だと思っています。
