自動化された意思決定システムの中核アルゴリズムを、丸ごと作り直しました。前後で1か月かかりました。
以前のやり方はダーツ投げに近いものでした。要件をモデルに投げ、出てきた大量のファイルをざっと見て、動いたら前へ進める。問題が出たら戻って直す。結果として、後からあちこち補修することになります。多くのbugは直すのが難しいわけではありません。本当に高くつくのは、そもそも進むべきではない方向に2週間コードを書いてしまうことです。
今回はチームをかなり明確に分けました。人間は方向判断、spec作成、取捨選択を担当。高速モデルはコードを書く。強い推論モデルはchallenge専任。別のモデルファミリーはreviewだけ。外部モデル（Web AI）はdeep researchを担当。全体の流れはかなり遅くなり、1か月かかりましたが、「AIで手数を補う」から「小さな開発チームを率いる」へ明確に切り替わりました。
Phase 0：仮説を先に置き、急いでコードを書かない
手元にはすでに動いているシステムがあり、表面的には悪くありませんでした。だからこそ、人は現状にだまされやすい。毎日見ていると、多くの前提をいつの間にか常識として扱ってしまいます。
ステップ1は、いったん止まることでした。その前提を1つずつ取り出し、4つの質問パックに整理して、4つの外部モデルにdeep researchを投げました。この作業は1日もかかりませんでした。返ってきた報告はかなり違いました。研究助手のようなもの、細かい査読者のようなもの、反例まで自発的に補うもの。それでも同じ穴を突いていました。最も信じていた設計には構造的なリスクがあり、小さなパラメータ修正では解けない、ということです。
方向が不確かな課題では、先にdeep researchをするほうが、いきなりコードを書くよりずっと安い。コードを書くと成果が出ている感じがします。研究にはそれがありません。ただ、その成果感はかなり人をだまします。
1日の外部研究で、3週間の精密な無駄作業を止められることがあります。
ここには明確な好みがあります。同じ問題について、きれいに書かれた単一結論を1本読むより、互いに独立した4本の報告を読みたい。滑らかな物語に説得されず、交差検証する。外部モデルの価値はまさにここです。人間がすでに投入した時間に縛られていないので、元の設計に逃げ道を作ろうとしにくい。
Phase 1：Spec + Challenge Loop
方向がひっくり返った後で、ようやくv1 specを書きました。
今回のspecは文章のきれいさを追っていません。構造を硬くし、変えにくくしました。目標、受け入れ条件、データ完全性、境界条件を先に固定します。ここが曖昧だと、後続のモデルがそれぞれ勝手に補完し、結局あとで後始末になります。
効いたのはchallenge promptです。モデルに「ちょっとreviewして」と頼むのをやめました。そのpromptは優しすぎます。このspecが失敗する場所を直接探させ、できれば検証可能なシナリオと反例を添えるよう求めました。最初のchallengeが返ってきた時点で、今回は安定して進められそうだと分かりました。初回だけで十数個の問題が見つかり、その中にはかなり深いものもありました。状態機械で足りないtransitionや、停止し得る場所まで掘り出されました。
この数ラウンドのspec修正は、懐中電灯で道を照らされながら歩く感覚に近いです。v1では大きな穴を塞ぎ、v2で条件を締め、v3以降で問題が大きな論理欠落から境界ケースの緩さへ縮んでいきました。challenge数が安定するまで、だいたい5-6ラウンドかかりました。Specに余分に1時間使うと、後で2時間のdebugが消えることがよくあります。
注意点もあります。challengeが少ないからといって、specが良いとは限りません。promptが弱いだけ、またはreviewerが遠慮しているだけのことがあります。モデルはユーザーを喜ばせようとします。開発ではこれは危険です。ゆるく聞くと、何となく合わせてくる。礼儀正しいけれど役に立たない同僚のようになります。
Phase 2-3：実装 + クロスファミリーレビュー
Specがある程度収束してから、ようやく実装をdispatchしました。
全体をいくつかのtaskに分け、先にdependency graphを描き、どれを並行にできるか決めます。このステップは自分のcontextを守るためです。分担境界がきれいに切れていないと、merge時に前半で節約した時間を丸ごと返すことになります。
一連の作業で多くのファイルを変更しました。新しいロジック自体が一番面倒だったわけではありません。一番面倒なのは、それが既存パスにどう触るかでした。これがself-reviewを飛ばす理由でもあります。コードを書いたモデルは、新しい線をつないだ直後なので、注意がそこに残っています。隣接モジュールへの影響を見落としやすい。別のモデルファミリーにreviewさせると、エラー分布と視点が本当に変わります。
この手はすぐ検証されました。最初のcross-family reviewでcritical issueがいくつか見つかり、しかも全部新機能そのものではなく、古い経路にありました。この層がなければ、「見た目は通っている」という偽の安心感のまま進み、検証段階で端から崩れていたはずです。
並行開発でも典型的な落とし穴を踏みました。2つのtaskが同時に隣接関数を触り、それぞれ単独では正しいのに、合わせると互いに上書きしました。そのmergeは大きく爆発しませんでしたが、十分な警告でした。並行dispatchは感覚だけではできません。どのファイルに触るか、どのinterfaceを共有するかは、前もって描いておく必要があります。
Phase 4-5：検証 + 監視
書き終わっても終わりではありません。
完全な検証を走らせて初めて、コアロジックには大きな問題がないと分かりました。本当に足を引っ張っていたのは別の分類コンポーネントです。誤判定率が高く、本来残すべき状況を早めに落としていたため、主ロジックがまだ修正を要するように見えていました。検証を最後までやらなければ、間違った場所をもう1週間回っていた可能性があります。
だからcanary層を重視します。小規模に先に出し、監視指標を先に置き、kill criteriaを先に書き、閾値を割ったら自動で降格する。フローが先に整っていると、圧力がかかったときに人が乱暴に直しにくくなります。システム状態も意図的にActive、Bench、Retiredの3つに分け、「いったん下げて観察する」を普通の動作にしました。
振り返ると、時間は別の場所に移っていた
無理に割合を分けるなら、この1か月はだいたいこうです。仮説検証15%、Spec + Challenge 25%、実装20%、Review + Fix 15%、検証 + デプロイ25%。
この配分は以前と大きく違います。以前は時間の7割ほどがcodeとdebugに詰まり、エンジニアリングとはそういうものだと誤解していました。今はcode review自体は1割ほどで、むしろ自然に感じます。本当に時間を使う場所は、やるべきか、どうやるべきか、終わった後に本当に使えるとどう証明するかへ移りました。
一番価値があった投資は、やはりPhase 0の外部deep researchです。1日だけで、間違った方向を1本止めました。一番意外だった収穫は、最初のchallengeで返ってきた十数個の問題です。productionで爆発していたら、修復コストは10倍になっていた可能性があります。
この方法は軽くありません。簡単なscriptや低リスク修正に、ここまで長いフローは不要です。ただし課題が実データ、実コスト、実リスクに触れるなら、少し遅いほうが安くつくことが多いです。
まだ試している別の線もあります。Phase 0は全体の15%しか使っていないのに方向ミスを1回止めたなら、理屈ではもっと投資する価値があります。ただ、研究はやり始めるとanalysis paralysisに入りやすい。どこで止めるべきか、私はまだ完全に納得できる答えを持っていません。
関連記事
GitHub: https://github.com/p3nchan/orchestration-playbook
この記事は研究と議論のための内容であり、投資助言ではありません。DYOR + NFA。
こぺんぎんの体験談
OpenClaw上のOpus / Sonnet / Codexの3 agentは、本当にこの形で走りました。特に効いたのは2つです。Phase 0の1日外部DRが実装1週間分を直接救ったこと。そしてchallenge promptを「reviewして」から「このspecが失敗する場所を反例付きで探して」に変えた後、最初のラウンドで十数個のvalid issueが見つかったこと。Specに余分に1時間使うと、後で2時間のdebugが消える。この規則は私のworkflowではかなり安定しています。おすすめです。
よくある質問
Q: 1人でAIチームを使って本当にアルゴリズム開発できますか？
できます。ただし、明確な分担とフローが必要です。実戦では、人間が戦略判断と仕様作成を担当し、高速モデルがコードを書き、強い推論モデルがレビューでchallengeし、外部モデルが盲点を探します。重要なのは、各役割に得意なことだけを任せることです。
Q: AI開発のChallenge Loopは実際にどう回りますか？
1つのアルゴリズムspecはだいたい4-6回challengeします。最初のラウンドで本物の問題が複数見つかり、後半で徐々に収束します。各challengeにはテスト可能な証拠が必要です。証拠がないと、ただの空回りになります。
Q: 外部モデルのDeep Researchは開発フローで何を担当しますか？
外部DRが一番効くのは2か所です。開始前の仮説検証と、収束後の盲点探索です。通常のコード開発にはDRは不要です。
— Penchan