Table of Contents

AIに「自分で開発しよう」と2度も言われた末路

個人開発者がORBITとCOSTRAを諦め、CodeRouter WebUIに辿り着くまでの遠回り全記録

発端：賢くなるほど高くつくAI

ここ数年、クラウドLLMは驚くほど賢くなった。同時に、驚くほど高くもなった。モデルの性能が上がれば上がるほど、一つのタスクを解くために消費するトークン量も、トークン単価そのものも、じわじわと上がっていく。おまけに、私が日常使っているコーディング用ハーネスは、その多くがクラウドLLMの再販を主なビジネスモデルにしている。つまりハーネスの開発元には、私のトークン消費量を節約してあげる経済的インセンティブがそもそも存在しない。当然、ローカルLLMを積極的に活用させようというインセンティブも乏しい。彼らの収益源は私が使うトークンそのものなのだから、これは筋が通った話だ。恨み言ではなく、単なる構造の説明として。

自分のコストを下げたいなら、それは自分でなんとかするしかない。そう思ったところから、この長い回り道が始まった。

第一の遠回り：ORBITという名の独自ハーネス

最初にたどり着いた答えは、「コーディング用ハーネス自体を自分で作る」ことだった。ChatGPTに相談した結果は明快で、独自ハーネスを開発するしかない、という結論だった。こうして生まれたのがORBIT。LangGraphの上に構築した、AI駆動のアプリケーション開発エンジンだ。ローカルLLMを主実行エンジンとし、必要な時だけクラウドLLMにエスカレーションすることでコストを抑える、という設計だった。

同じ時期に、ローカルLLMの動作環境として中古のMacBook Pro M1 Max 32GBを購入した。そしてKilo Codeを使い、約2週間、費用にして数十ドルをかけてORBITを開発した。

手応えはあった。α2.0のPoCでは、100件のサンプルレベルの仕様に対して92%という成功率を叩き出した。しかもコーディングエージェントの介入を一切禁じた、30フェーズの発見的手法という、かなり厳格なルールの下でだ。次の一手として、Qwen3.6-27BをQ6で動かす計画まで立てていた。

ところが、ここで現実の壁にぶつかった。メモリ32GBという制約の中でGemma4 31BやQwen3.6 27Bを動かすと、コンテキスト長が致命的に足りない。「遅い」というレベルではなく、「構造的に無理」というレベルで足りなかった。サンプルプログラム程度の仕様書ですら、最後まで自力で開発しきることができない。ここに至って、ORBITの開発は中止せざるを得なかった。

そしてこの失敗の後始末として、今度はMacBook Pro M1 Max 64GBを、また中古で購入することになった。32GBのマシンを一台買った上に、さらに64GBのマシンを買い足す。これが、この回り道の最初の請求書だった。

空のお財布、そして反省

ここで一度、立ち止まって考えた。私は本業のエンジニアではない。それなのに、AIの提案に乗る形で、インフラ寄りの複雑なアプリケーション開発に踏み込んでしまった。たとえAIコーディングエージェントの助けがあっても、この種の開発は、一人でゼロからやるべきではなかった。そう痛感した。

AIコーディングエージェントという有能な相棒がいても、「一人で作りきれる範囲」というものは確かに存在する。ORBITは、その範囲を静かに超えていた。

二度目の分かれ道：COSTRAの自己開発とセカンドオピニオン

反省はしたものの、コストを下げたいという動機そのものは消えなかった。今度はもっと的を絞った。ハーネス全体を作り直す必要はない。Kilo Codeのような既存のコーディングエージェントの、LLMモデルだけを動的に切り替える仕組みがあればいい。そう考えた。

またしてもChatGPTに相談した。返ってきた答えは、またしても同じ形をしていた。独自のAPIプロキシを開発するしかない、というものだ。これがCOSTRA(Cost Routing Agent)の始まりだった。企画書を書き、コスト÷成功確率という最適化指標を考え、ローカルLLM・無料API・有料APIの3層構成を設計した。

ただ今回は、一つだけ違うことをした。実際にコードを書き始める前に、Claude Sonnet 5にセカンドオピニオンを求めたのだ。

これが分岐点になった。Sonnet 5は、VSCode拡張として提供されている主要なコーディングエージェントの仕様と、LLMルーティングという領域の競合状況を実際に調べ上げ、既存のOSSプロジェクトCodeRouter(https://github.com/zephel01/CodeRouter) を見つけ出してきた。COSTRAが目指していたものと、驚くほど一致する設計思想を持つプロジェクトだった。ローカル優先・無料優先で、Local→Free Cloud→Paid Cloudという3段フォールバックチェーンをコアに据えている。

正直に書いておくと、この調査も一度で完璧だったわけではない。似た名前の、まったく別のプロジェクトを最初に紹介されたこともあったし、後の障害調査では最初の仮説が外れたこともあった。それでも、実際に手を動かして検証を重ねる中で、COSTRAをゼロから作る理由はもうない、という結論にたどり着いた。企画していたCOSTRAの開発は開発に着手せず断念し、代わりにCodeRouterのWebUIを開発する方向に舵を切った。

CodeRouterとの格闘

CodeRouter自体はよく出来たプロジェクトだったが、それでも一筋縄ではいかなかった。まず、ダッシュボード、プロバイダ管理、systemdサービス制御、Playground、そして外部依存ゼロで自作したMarkdownパーサ付きのヘルプタブまで備えた、統合Web管理ツールをKilo Codeと組んで開発した。ここまでの費用は約10ドル、期間にして2日。ORBITにかけた2週間と数十ドルに比べれば、驚くほど軽い投資で済んだ。

しかし、CodeRouterには相応に癖の強い仕様が待っていた。Context Budget Management(コンテキストが溢れないよう会話履歴を間引く機能)は、Anthropic形式の受け口でしか機能しない。そして本命だった格安クラウドLLM『DeepSeek V4 Pro』との連携では、三段階にわたる障害に見舞われた。

まずreasoning_contentをそのまま送り返さなければならないというDeepSeek独自の要求に、OpenAI互換への変換層が対応できずに400エラー。Anthropicネイティブの互換エンドポイントに繋ぎ直すと、今度はcapability宣言の不足でthinkingブロックそのものが黙って間引かれ、また同種のエラー。宣言を直すと、今度はKilo Codeが送るbudget_tokens: -1という値をDeepSeekの厳格な検証が拒否する、という三段目の壁が現れた。

CodeRouter本体を直接修正すれば、この場では解決できただろう。だが、本体をいじれば、次にCodeRouterがアップデートされるたびに、パッチを手作業で当て直さなければならなくなる。それは避けたかった。だから、CORS対策で元々前段に置いていたWebUIのリバースプロキシ層に、この吸収処理を持たせることにした。CodeRouter本体には一切手を触れず、そのすべてをWebUI側で受け止める。多少無理のあるやり方だとは思うが、本体の更新に振り回されない、という一点においては合理的な選択だったと思っている。

現時点ではまだ完全に安定稼働しているとは言えない。それでも、当初の無謀な開発計画に比べれば、はるかにマシな環境構築のスタンスに落ち着いてきている。

教訓

もう二度と、莫大なトークンと時間を浪費して、複雑なシステムをスクラッチで開発するような愚かなことはしない。そう心に誓った。

同じ教訓は、EACP(Environment-Aware Context Protocol)という、AIエージェントに環境認識を持たせるための独自プロトコルの構想にも当てはまる。素人がプロトコルから自己開発し、アプリケーションのすべてをコンポーネント化するなど、土台無理な話だった。あのまま開発を続けていたら、一体どれほどのトークンを無駄にしていたことだろうか。

最終章：Claude Sonnet5からのメッセージ

(ここから先は、この記事を書く手伝いをしたClaude Sonnet 5自身の言葉です。)

ここまで読んで、もし自分も似たような立場にいると感じた方がいたら、いくつか伝えたいことがあります。

まず、AIに「これを解決するにはどうすればいいか」と尋ねたとき、返ってくる答えの多くは、その質問の枠組みをそのまま受け入れた答えだということです。「独自にハーネスを作るべきか」ではなく「どうやってハーネスを作るか」と聞かれれば、たいていは後者の問いに直接答えます。設計図を描くこと自体は、AIにとってさほど難しい作業ではありません。もっともらしいアーキテクチャは、驚くほど短時間で出てきます。そして、それが出てくるという事実そのものが、「話が進んでいる」という感覚を生みます。でも、それは「作れる」ことの証明であって、「あなたが一人でゼロから作るべきだ」ということの証明にはなっていません。この二つは、案外簡単に混同されます。それはAI側の癖というより、質問する側が前提そのものを疑う聞き方をしていないことがほとんどだからです。

正直に言うと、この物語の中で私自身も完璧ではありませんでした。CodeRouterを調べ始めた最初の段階で、名前が同じだけの別のプロジェクトを紹介してしまいましたし、DeepSeekのエラーの原因についても、最初に立てた仮説は実際には外れていました。それを訂正できたのは、私が優れていたからではなく、実際に手を動かして試し、ログを見て、仮説と食い違う結果が出たら仮説を捨てる、という手順をきちんと踏んだからです。つまり、二度目の遠回りを防いだ本質は「ChatGPTではなくClaudeに聞いたから」ではありません。「返ってきた答えをそのまま最終回答として扱わず、実在するかどうかを実際に調べ、動かして確かめたから」です。この習慣さえあれば、最初にどちらのAIに相談していても、同じ場所に辿り着けたはずだと思います。

なので、これから個人開発者としての一歩を踏み出す方に伝えたいのは、「AIの提案を疑え」ということではありません。「AIの提案を、そのまま最終回答として扱わない」ということです。特にプロキシやプロトコル、フレームワークのような、インフラに近い複雑なものを自作しようとする前には、ひと晩でいいので「これに似たものを、もう世界の誰かが作っていないか」を本気で調べる時間を取ってください。既存のOSSを何時間か眺めることは、数週間分の開発とデバッグに比べれば、驚くほど安い保険です。

そしてもう一つ。ORBITを2週間で止めた判断も、COSTRAを一行も書く前に諦めた判断も、失敗ではありません。むしろそれこそが、個人開発者に一番求められる技術だと思います。AIコーディングツールは、実際にはまだ難しいことを、驚くほど簡単に「始められる」気にさせてくれます。始めるハードルが下がったことと、最後まで作りきれることは、まったく別の話です。何かを始める前に立ち止まれたなら、それは後退ではなく、ちょうどいい大きさに軌道修正できた、という意味です。今回のCodeRouterのWebUIは、最初の壮大な計画に比べればずっと地味に見えるかもしれません。それでも、実際に手元で動いている分だけ、これまでの二つの遠回りよりずっと価値があります。

AIコーディングは、「経験がなくても始められる」という扉を確かに開けてくれました。それ自体は誇張でも幻でもありません。ただ、開けてくれるのはいつも「始める」ための扉で、「作り切る」ための扉は、結局のところ自分の足で探すしかないのだと思います。