概要
https://zenn.dev/calloc134/articles/claude_o4mini_search_attempt_failed
詳細内容
## Claude Codeの中身をo4-mini & 検索機能にしてみたかった (できなかった)
https://zenn.dev/calloc134/articles/claude_o4mini_search_attempt_failed
著者はClaude CodeのバックエンドをOpenAIのo4-miniモデルと検索機能に置き換えようと試みたが、ストリーミング仕様の不一致により失敗した経緯を報告する。
[[AIエージェント, LLM連携, APIプロキシ, ストリーミングAPI, 開発ワークフロー]]
この記事では、Claude Codeの基盤モデルをOpenAIのo4-miniに切り替え、さらにWeb検索機能を統合しようとした試みが失敗に終わった経緯が詳細に述べられています。著者は、Claude Codeが提供する`ANTHROPIC_BASE_URL`と`ANTHROPIC_AUTH_TOKEN`環境変数を活用し、プロキシサーバーを介してOpenAIのResponses APIへリクエストを転送するアプローチを採用しました。これは、従来のCompletion APIとは異なり、Web検索をサポートするResponses APIの特性を活かす狙いがありました。
しかし、HonoとTypeScriptを用いてプロキシを実装したものの、特にツール呼び出しの挙動において問題が発生しました。o4-miniがClaude Codeの特定のプロンプトに一貫して従わず、ツールを適切に利用せずにユーザーにコマンド実行を指示するケースが見られました。また、o4-miniのコーディング能力がClaudeに劣る可能性も指摘されています。
この失敗の主な原因として、両APIのストリーミング仕様に関する理解不足が挙げられています。OpenAIのストリーミング応答が階層的な構造を持つことなど、細かな仕様の違いが連携を困難にしたようです。この試みは、異なるLLM間の連携や、エージェントのツール利用における複雑性、そしてAPIのストリーミング仕様の重要性を浮き彫りにしています。
---
**編集者ノート**: Webアプリケーションエンジニアの視点から見ると、この記事はLLMを組み合わせたエージェント開発の現実的な課題を提示しています。異なるLLMのAPI仕様、特にストリーミングやツール呼び出しの挙動の違いは、単なるプロキシでは吸収しきれない複雑性を持つことが明らかになりました。これは、将来的に複数のLLMを組み合わせて最適なエージェントを構築しようとする際に、APIの標準化や共通のインターフェースの重要性が増すことを示唆しています。
現状では、特定のLLMに最適化されたエージェントフレームワーク（例: Claude CodeがClaudeに最適化されているように）を利用する方が、安定性とパフォーマンスの面で優位性があるでしょう。しかし、長期的には、LLM間の互換性を高めるための抽象化レイヤーや、より柔軟なプロキシ技術が進化すると予測します。これにより、開発者は特定のLLMに縛られず、用途に応じて最適なモデルを動的に選択・組み合わせる「LLMアグリゲーション」が一般化するでしょう。この動きは、エージェント開発の自由度を飛躍的に高め、より高度な自動化ワークフローの実現を加速させると考えられます。
```