【AIビルダーの現場】親は判断と確認だけ　月10ドルのモデルに実装を任せた記録

Tom氏は、半導体のデジタル設計の出身で、今は開発基盤のエンジニアとして働きながら、ゲーム・スマホアプリ・開発ツールを1人で作る個人開発スタジオ「Maveroni」を運営している。Zennに36本の記事があり、Claude CodeとCodexからほかのエージェントに作業を任せる仕組みを、リポジトリと記事で公開してきた。11月10日の記事では、親のClaude CodeやCodexを方針の判断と成果物の確認だけに絞り、実装と調査を月10ドルのモデルに任せた約3週間の記録をまとめている。

親は判断、実装は月10ドルの側へ

11月10日の記事「月10ドルのコーディングエージェントでClaude Codeのサブエージェントを置き換える」によると、Tom氏は10月下旬から、範囲の決まった実装と調査を月10ドルのOpenCode Goに任せている。モデルはDeepSeek V4.1 Flashだ。親のClaude CodeとCodexは、仕様や変更範囲、完成の判断と、成果物の確認に使う。使う量が増えて上限に当たる日が出てきたため、11月4日に同じ月10ドルのCommand CodeのGOATプランを足した。高い親のモデルが受け持つのは、何を作るかを決めることと、出てきた物が正しいかを見ることの2つに限られる。手を動かす作業の量が増えても、親の側の消費は依頼の作成と確認の分で済む形だ。

依頼はcurlで送り、IDを残す

同じ記事では、安いモデルへの依頼は、OpenCodeのHTTP APIをcurlで呼んで行う。会話を作り、指示を送り、終わるまで待ち、結果を取得する4つの手順だ。会話のIDと依頼の受付IDは、返ってきた時点でファイルに保存する。通信が途中で切れても、保存したIDから状態を確かめられるので、同じ依頼を2回送らずに済む。待機がタイムアウトしても作業は続いているため、同じ会話をもう一度待つ。

「終わった」は3つで確かめる

記事によると、完了の判断に使うのは、終了状態が成功であること、応答に記録されたモデルが指定どおりであること、実際の差分とテスト結果の3つだ。権限の要求が拒否された場合は成功の終了状態が付かないため、完了とは別に扱う。

指示は変更してよい範囲を絞って書く。例として挙げているのは「変更はeventlog/ の中だけにしてください。」「tests/ とプロジェクト設定は変更しないでください。」といった文だ。報告の末尾は「RESULT=ok | VERIFY=公開テストを実行して成功 | NEXT=none」の形にそろえ、ok・fail・partialで、終わった・できなかった・一部だけ終わったを区別する。親の会話には途中のログを入れず、短い報告だけを返す。記事に理由は書かれていないが、編集部は、親の文脈を子の作業の細部で埋めない狙いと見る。親は報告を受けてから差分と必要な検証を見に行く。

18日で月間上限、モデルの上書きで枠切れ

記事は、10月21日から11月7日までの18日間の、デスクトップ1台分の記録を公開している。OpenCode Goは会話554・依頼1,025回で、11月7日に月間上限に達した。Command Codeは使った4日間で会話189・依頼1,102回となり、同じ11月7日に週間上限に達した。後から足したCommand Codeが、4日でGoの18日分を超える依頼を受けた計算になる。トークン量から計算した換算費用はGoが約40ドル、Command Codeが約43ドルだが、請求額や枠の消費量とは一致しないとTom氏は書いている。

上限に早く達した理由には、使い方を挙げている。推論の強さをhighに固定し、ゲームのシミュレーションを並列数を増やせるだけ増やして回す実験もしていた。

失敗も記事に書いている。同じ価格帯のQoderでは、キャンペーン中に無料だったDeepSeek-Flashだけを使うつもりだった。ところが自作のスクリプトの1つがモデルの指定を、Creditsを消費する別のモデルに上書きしていて、トライアルの300 Creditsを使い切った。それからは、DeepSeek-Flash以外を指定した実行を呼び出し側で拒否している。サービス側で別のモデルを禁止できているわけではない、とも断っている。指定したはずのモデルと実際に動いたモデルが食い違うと、品質だけでなく費用の見込みも崩れる。完了の判断に「応答に記録されたモデル」を入れている理由が、この失敗からも読み取れる。

前の公開物は「1サイクル＝1コミット」

Tom氏が5月にGitHubで公開したcodex-cycle-kitでも、判断は大きいモデル、実装は小さいモデルに分けている。1回の起動で1ファイルとその関連だけを編集させ、検証・画面のキャプチャ・ビルド・動作確認が通ればcommitとpushまで進める「1サイクル＝1コミット」の形だ。1サイクルの平均トークン消費は約84%減（36.7M→6.0M、348サイクルの平均）と書く一方で、最初から軽量のモデルでサブエージェントを回している環境では、削減の幅は小さくなると注記している。

編集部の見方

編集部は、この事例で真似る価値が最も高いのは安いモデルの選び方より、子の「できました」を親が3つの事実で確かめている点だと見る。完了の判断に終了状態・応答に記録されたモデル・差分とテスト結果を使い、権限の拒否を成功に数えていないことが根拠だ。自分の運用で試すなら、子のエージェントの報告を受け取った後に、指定したモデルで動いたかと差分・テスト結果を親の側で見ているかを書き出すとよい。ただし、子に渡す作業が差分もテストも出ない調査だけの運用では、この3つのうち差分とテスト結果の確認は当てはまらない。