自動化スタックをMCPサーバーとローカルLLMに置き換えた実践経験

セットアップとハードウェア

開発者は、デュアル3090構成のマシンでQwen 2.5 32B（量子化版）とLlama 3.3 70Bを併用しています。各自動化タスクには専用のMCPサーバーが割り当てられ、モデルが呼び出せるツールを公開しています。これは、人間ではなくLLMが利用するAPIのような機能を果たします。

うまく機能した点

• コードレビュー自動化: MCPツールを介してモデルにgit diffを指し示すことで、ロジックバグ、エラーハンドリングの欠落、競合状態など実際の問題を検出できます。シニア開発者のレビューの約70%の品質で機能します。
• ログ分析とアラート: MCPサーバーはELKスタックに接続し、モデルが異常パターンを監視します。Grafanaアラートが発動する前に3件の本番環境の問題を検出しました。重要なのは、システムにとって「正常」な状態について十分なコンテキストを提供することです。
• ドキュメント生成: モデルはMCPファイルツールを通じてコードベースを読み取り、APIドキュメントを生成・更新します。週に数時間を節約でき、出力品質も実際に優れています。

まだ機能しない点

• 多段階推論チェーン: 3〜4回以上のツール呼び出しを連続して必要とするものは、モデルが元の目標のコンテキストを失い、軌道から外れ始めます。小さなコンテキストウィンドウはこれをさらに悪化させます。思考連鎖プロンプトは役立ちますが、根本的解決にはなりません。
• リアルタイム意思決定: 70Bモデルのレイテンシにより、時間制約のあるタスクには使用できません。コードレビューパイプラインはPRごとに2〜3分かかるため、非同期ワークフローには適していますが、リアルタイムアプリケーションには役立ちません。
• 創造的問題解決: ローカルモデルは、トレーニングデータに十分に反映されていないアプローチを必要とするタスクに苦戦します。APIモデル（Claude、GPT-4）はこの点で顕著に優れています。

重要なアーキテクチャの教訓

• MCPサーバーはステートレスに保つこと。モデルにツール呼び出しを通じて状態を管理させ、サーバー側のセッションでは管理しないでください。
• 再試行ロジックはMCPクライアントに組み込み、サーバーには組み込まないでください。モデルは約5%の確率で不正な形式のツール呼び出しを行います。
• モデルが予期しない動作をした際のデバッグのために、すべてのツール呼び出しと応答をログに記録してください。
• 下流システムが利用するものには構造化出力（JSONモード）を使用してください。自由形式のテキスト出力はデバッグの悪夢です。