Qwen3.6-27Bをローカル推論層として：2週間のマルチエージェントテスト結果

ある開発者が、マルチエージェントオーケストレーターでClaudeをQwen3.6-27Bに2週間置き換え、すべて単一のRTX 3090で実行しました。目的は単純明快で、ローカルモデルが実際のコーディングワークフローにおいて、推論層（リード/マネージャー/サブエージェントループ）として機能するかをテストすることでした。結果は、クラウドコストを削減しようと考えている人にとって貴重な数字を示しています。

セットアップとベースライン

• ハードウェア： RTX 3090、24GB VRAM
• モデル： Qwen3.6-27B（Q6_K量子化、GPU上約22GB）、実効コンテキスト32k
• 推論エンジン： Ollama
• オーケストレーター： 構造化JSON計画、計画承認モーダル、サブエージェント完了後の自動レビューパスを備えたマルチエージェントシステム
• ワークロード： 2つの実際のリポジトリにわたる47のマルチステップコーディングワークフロー

うまくいった点（推論層）

計画生成。 Qwen3.6は、これらのタスクにおいてClaudeとほぼ同程度にマルチステップ計画を生成しました。やや保守的で、不要なリファクタリング提案は少ないものの、プロンプト調整後は約95%の確率で一貫性がありスキーマに準拠していました。残りの5%は、1回の再プロンプトで修正可能でした。

記憶抽出。 6ターンごとのMem0スタイルの事実抽出は問題なく機能しました。QwenはClaudeと同じ事実（例：「ユーザーは「理由」を説明するコメント以外は好まない」）を抽出し、Qdrantにきれいに保存しました。

サブエージェント出力の自動レビュー。 別のQwenインスタンスが最初のインスタンスのコードをレビューしたところ、Claudeのレビューが同じセットで検出したバグの約60%を捕捉しました。積極性は低いものの、有用でコストはかかりません。

問題点

ツールコールの信頼性。 Qwen3.6のJSONツールコール出力には、47タスク全体で約12%の形式エラー率が見られました。Claudeは同じワークロードで約0.5%でした。エラーは不正なJSONではなく、誤ったフィールド名、誤った型、幻覚のツールシグネチャでした。Outlinesやstrict-outputモードを使用するとエラーは減少しましたが、完全にはなくなりませんでした。

長文脈の偏り。 累積セッションコンテキストが約14kトークンを超えると、Qwenは決定を誤って記憶し始めました（例：「あなたはPostgresを使うと言った」と、実際は反対のことを言っている）。実効的な実用限界は約12kトークンで、その後は積極的に要約してリセットする必要があります。

連鎖障害の処理。 サブエージェントが失敗した場合、Claudeのプランナーは通常それを認識して再計画しました。Qwenはサブエージェントが成功したと仮定して後続のステップを生成することがありました。47回の実行中に3回の連鎖的幻覚が発生しました。計画ゲートがあれば壊滅的ではありませんが、なければ問題です。

実用的な意味

開発者の見解：「Qwen3.6-27Bは今日、ローカルマルチエージェントシステムの推論層として実用的です。しかし、実行層としては実用的ではありません。」 ローカル専用エージェントを構築する場合、以下が必要です：

1. ツールコール境界での構造化出力の強制（Outlines、lm-format-enforcer、または推論エンジンのグラマーモード）
2. 計画承認ゲートにより、12%の形式エラーが実際のファイル書き込みに至らないようにする
3. 障害時の再計画ロジック — モデル自体は連鎖障害の処理を信頼できない

12%のツールコールエラーギャップが注目すべき指標です。Qwen3.6か次のローカルモデルがこの指標で約2%を達成すれば、エージェントループにおけるクラウド推論の優位性は大幅に弱まるでしょう。