Claude Codeのアーキテクチャをローカル9Bモデルに適用：主要な知見と最適化手法

実験セットアップと重要な発見

開発者はRTX 5070 Ti（16GB VRAM）を使用し、Ollama（6.6GB）経由でqwen3.5:9bとOpenClawローカルエージェントフレームワークを実行しました。18回のテストと10の最適化の後、重要な発見は、qwen3.5:9bがネイティブな構造化tool_callsを備えている一方で、qwen2.5-coder:14bとqwen2.5:14bは適切なtool_callsではなくコンテンツフィールドにJSONを配置し、追加の解析が必要であることでした。

パフォーマンス比較

モデルパフォーマンス比較：

• qwen3.5:9b：ネイティブtool_calls構造、思考チェーン有効、39 tok/s
• qwen2.5-coder:14b：壊れたツール呼び出し（コンテンツフィールド内）、思考チェーンなし、〜30 tok/s
• qwen2.5:14b：壊れたツール呼び出し（コンテンツフィールド内）、思考チェーンなし、〜35 tok/s

Claude Codeのアーキテクチャからの10の最適化

• 構造化システムプロンプト → 出力品質+600%（A/Bテスト：4件の問題発見 vs 25件以上）
• MicroCompact（ツール結果圧縮） → 80-93%圧縮、11KBから367文字へ
• ハードカットオフ（探索→生成の強制移行） → 9Bモデルが出力を生成せずにファイルを読み続ける探索ループを解決
• think=false → トークン効率8-10倍向上、言語汚染を排除
• ToolSearch遅延ロード → プロンプト空間-60%（229 vs 568トークン）
• 4種類のメモリシステム（ユーザー/フィードバック/プロジェクト/参照） → パーソナライズされた応答
• KVキャッシュフォーク → 単一GPUでは最小限の効果（1.1倍）、vLLMが必要
• 厳格な書き込み規律 → メモリ更新前に検証、メモリ破損を防止
• 並列ブートストラップ → コールドスタート9%高速化
• キャッシュブレーク追跡 → Ollamaは同一プロンプトをキャッシュ（182ms→75ms）

核心的な発見：真の限界は自己規律

最大の発見は、9Bモデルの真の限界が推論能力やツール使用精度ではなく、自己規律——探索をいつ止めて出力を開始すべきかを知ること——にあるということでした。ハードカットオフなしでは、モデルは12ステップ全てをファイル読み込みに使用し、0バイトのレポートを生成しました。ハードカットオフあり：5ステップ読み込み + 1ステップ書き込み = 6080バイトの構造化レポート。

qwen3.5:9bが実際にできること

• 800行のbashスクリプトを読み、実際のバグ（競合状態、非アトミック操作）を発見 — 2分
• 販売フィードバックシステムアーキテクチャを設計 — 8.7KBドキュメントを2.5分で
• 完全なプロジェクト構築（電卓 + テスト + テスト実行） — 28秒
• 10ステップ自律実行：Webスクレイパー作成 → pipインストール失敗 → 回避策発見 → 再試行 → テスト合格 — 人間の介入ゼロ
• 完全なミニファクトリーパイプライン：検索 → 記事執筆 → レビュー → HTML公開 — 2.5分

完全エンジンパフォーマンス

10の最適化全てが単一のPythonエンジン（〜280行）にパッケージ化されました。初回実行結果：

• ブートストラップ：527ms（並列メモリ + モデルウォームアップ）
• 探索：MicroCompactによる5ツールステップ（88%圧縮）
• 生成：1947文字の構造化レポート
• 合計：39.4秒 / APIコストゼロ

うまくいかなかったこと

• 単一GPUでのKVキャッシュフォーク（マルチGPUまたはvLLMが必要）
• システムプロンプト内のステップ予算（モデルは自身の動作に関するメタ指示を無視）
• ツール呼び出しのためのqwen2.5シリーズ（フォーマット問題）

開発者はWSL2 + Ubuntu 24.04でこれを実行し、詳細やエンジンコードの共有に応じる意向です。