トークン爆発を防げないAIエージェントの構造的問題とコスト削減を目指す独自ハーネス「ORBIT」の取り組み
近年、Claude CodeやCline、Kilo CodeをはじめとするAIコーディングエージェントが開発現場に浸透しつつあります。しかし、これらの商業ツールが採用しているビジネスモデルを見ていると、エンジニアとしてある種の「不健全さ」を禁じ得ません。
本記事では、現在のAIコーディングエージェントが抱える構造的なインセンティブの歪みについて指摘した上で、この状況に対抗するために私が個人で開発している独自のエージェント・ハーネス「ORBIT（Operational Runtime Bridge for Iterative Tasks）」のアーキテクチャと設計思想について解説します。
1. API再販ビジネスの罠：なぜ「トークン効率」が向上しないのか
現在の多くのAIコーディングツールは、クラウドLLM（Claude Opus、ChatGPT、GLM 5.2、Kimi K2.7 Codeなど）のAPIを自社ブランドで再販し、バルク購入で生まれるマージンで利益を得るビジネスモデル、あるいは段階的なサブスクリプション（月額定額制＋上限超過時の従量課金）を採用しています。
一見するとユーザーに便利さを提供しているように見えますが、このモデルには「開発者側にトークンを節約するインセンティブが存在しない」という致命的な問題があります。
- 従量課金モデルの場合: ユーザーが湯水のようにトークンを消費すればするほど、ベンダーの売上が上がります。無駄に長いコンテキストを読ませたり、試行錯誤のループを回させたりするほど利益が増えるため、ツール側にプロンプトの最適化やコンテキスト圧縮を図る動機がありません。
- 段階的サブスクモデルの場合: ユーザーに快適に作業させすぎず、絶妙なタイミングで利用制限（Fast requestの上限など）にぶつからせ、上位プランへアップグレードを促すのが最適な利益戦略になります。
つまり、ベンダーの利益とユーザーの利益（最小のトークンで高い精度のコードを得ること）は真っ向から対立しているのです。
さらに、裏側でどれだけのトークンが消費されているかはブラックボックス化されており、ユーザーは「このタスクに本当にこれだけのAPIコストが必要なのか？」を検証する術を持っていません。
2. ユーザー側の自衛：ローカルLLMとクラウドLLMのハイブリッド
この不健全な構造から抜け出すため、ユーザー側が取れる戦略のひとつが「コンテキストの前処理をローカルで行い、クラウドには最小限のプロンプトだけを送るハーネス（実行枠組み）を自前で構築すること」です。
現在、私はローカルLLMとクラウドLLMを併用する独自ハーネス「ORBIT α2.0」を開発しています。ORBITの主題は、「非力だが低コストなローカルLLM（30Bクラス）をどれだけ多く活用し、コストを抑えつつ問題解決までこぎつけられるか」にあります。
しかし、30BクラスのローカルLLMを自律的に動かそうとすると、以下のような壁にぶつかります。
- コンテキスト過負荷: 16K制限を超過し、単一文字のタイポすら修正できなくなる。
- SEARCH/REPLACE崩壊: LLMがハルシネーションを起こし、対象コードの正確な再現に失敗して修正が一切適用されなくなる。
- 状態管理の欠如: 全体のどの部分が完成し、どの部分が失敗しているかを管理できず、同じ場所で無限ループに陥る。
ローカルLLMを単一プロンプトで全体生成に使う手法は早々に破綻しました。そこでORBITでは、アーキテクチャを「能力依存（LLMに頼る）」から「プロセス依存（システムが統括する）」へと根本的に転換しました。
3. ORBITのアーキテクチャ：プロセスによるローカルLLMの最大化
ORBITは、タスクを単一ファイル（200行以内）の単位に分解し、依存関係（DAG）をシステム側で制御します。LLMには「与えられた1つのファイルを作る/直す」という作業を逐次実行させます。中核となるのは以下の6層構造です。
① Planner層 ＆ Scheduler層
spec.jsonから骨格DAG（依存関係グラフ）を自動生成します。Schedulerは、依存が解決されたタスクの中から「失敗リスクの高いもの（外部API依存や非同期処理を含む等）」を優先的に実行します。これにより、手戻りコストの大きいタスクを先に片付け、無駄な再試行を防ぎます。
② Executor層 ＆ Contract Validator
Gemma 4（ローカルLLM）に対し、対象ファイル単体の生成・修正を指示します。この時、アプリ全体のコンテキストは与えず、タスク指示と依存ファイルの型定義のみを注入します。
また、ビルドを実行する前にAST解析による契約検証を行います。これにより、「ファイルは生成されたが関数が一つも定義されていない」といった結合破綻を早期に検出し、無駄なテスト実行をスキップします。
③ Controller層 ＆ Memory層
失敗時の「差分ロールバック」と「リトライ制御」を担います。タスク実行前に対象ファイルのスナップショットを保存し、失敗時はその部分のみを復元してクリーンな状態からリトライさせます。
また、失敗パターンと成功修正パターンを failure_db.jsonl に自動蓄積し、次回の类似エラー時に再利用します。
④ Escalation層：段階的リトライによるコスト抑制
ローカルLLMで解決不能な場合、いきなりクラウドLLMに全権委譲するのではなく、Level 1内を細分化した段階的リトライを行います。
- L1.0: Gemma 4による標準リトライ
- L1.5: DeepSeek V4 ProでStackOverflow DB QA(後述)を要約し、Gemma 4に注入
- L1.7: GLM-5.2（クラウド）がWeb検索とStackOverflow DBから修正方向性を生成し、Gemma 4に注入
- L1.8: ハーネス主導型の視点変更プロンプトでGemma 4に再トライ
- L2/L3: 上限到達時はGLM-5.2によるタスク分割、またはDAG再構築
コード実行本体は一貫してローカルLLMに担わせ、クラウドLLMは「補助」としてのみ使うことで、APIコストの爆発を防ぎます。
4. 検索RAGとしてのStackOverflow QA DB統合
特に注力したのが、オフライン環境・16Kコンテキスト制限下でも機能するRAGの構築です。99GBのStackOverflow Data Dumpから約86万件の高品質なQAペアを抽出し、FTS5全文検索可能なSQLiteデータベース（約5.4GB）としてローカルに構築しました。
エラー発生時、このDBに対してエラーメッセージやAPI名でピンポイント検索を行い、要約スニペットをローカルLLMのコンテキストに注入します。これにより、ネットワーク不要で安定したエラー解決のヒントを得ることができます。
5. ハーネスは「車両」であり、LLMは「エンジン」である
ORBITのようなハーネスをスクラッチで開発していると、正直「ルールベースのデバッガを作っているようなものだ」「実用レベルに達する前にローカルLLMの性能が追い付いてくるのではないか」という疑念を抱くこともあります。実際、現在の30Bクラスでは自力でビルド・テスト・デバッグのループを回すには限界があります。
しかし、私はこのアプローチが将来のAIコーディングのあり方だと確信しています。
ハーネスは「車両」であり、LLMは「エンジン」です。エンジンが非力だからといって、車両のサスペンションやブレーキ、ナビゲーション（DAG管理、ロールバック、RAG）の設計までは無駄になりません。エンジンが良くなれば、モジュールを差し替えることで、より高速に、より少ないトークンでゴールに到達できるようになります。何年先になるか分かりませんが、ローカルLLMの性能向上で、いつかハイブリッド型のハーネスは必ず実用レベルに達します。
一方、どんなに賢いLLMが登場しても、1000行を超えるコードベースを一度に読み込ませればコンテキストは圧迫され、APIコストは跳ね上がります。タスクを単一ファイルに分割し、依存関係の契約だけを渡す「プロセス依存」のアプローチは、LLMが賢くなるほど効率良く正解を出力できるという本質的な価値を持ち続けます。
私はいちおう技術者の端くれでもありますが長年システム企画側の人間だったので、ORBIT自体は「お遊び」レベルで終わるだろうと思っています。優秀な開発者が私のプロトタイプに刺激され、少しでも次世代ハーネス開発の参考にしてくれれば幸いです。
6. おわりに：コスト・パフォーマンス・ベンチマークの必要性
現在のAIコーディングエージェント界隈では、「課題を解決できたか（Accuracy）」ばかりが注目され、「いくらコストと時間をかけて解決したか」という効率性が無視されています。これではベンダーにとって都合の良い「パワープレイ（湯水のようにトークンを使う）」がまかり通ってしまいます。
今後、ユーザー側が自衛するためには、同じ課題・同じモデルで課題解決までに要したトークン料金を比較する「ハーネスのベンチマーク」のような指標が必要不可欠だと考えています。
API再販ビジネスモデルに振り回されることなく、いかに少ないトークンで高い精度を引き出すか。この「コスト効率の極致」を追求するアーキテクチャこそが、次世代の開発者が本当に求めているツールの姿だと私は信じています。
本記事で紹介したORBITの詳細な実装仕様や、実態に即して随時アップデートしています