「GPT-4oとClaude、どちらを使うべきか？」はAI Agent開発者が最もよく聞く質問の一つです。しかしこの質問自体に問題があります：「最良のLLM」が存在するという前提を置いていますが、実際の最良のLLMはAgentが何をしているか・資金量・必要な応答速度・受け入れられる推論コストによって異なります。
LLMを選ぶのは「最も強力なものを選ぶ」のではなく、あなたの具体的なタスクに対してコスト × 速度 × 品質の三角形の最適なバランスポイントを見つけることです。この記事は、感覚や流行に頼らず具体的な基準で選択できるよう、実用的なフレームワークを提供します。
どのLLMがあなたのAgentに適しているかを評価するには、4つの次元で同時にスコアリングする必要があります：
次元1：推論品質（Reasoning Quality）。Agentのタスクは複雑ですか？多段階の計画・条件判断・曖昧な情報下での意思決定が必要ですか？これらのタスクには高い推論能力を持つLLM（Claude Opus・GPT-4o・Gemini 1.5 Pro）が必要です。Agentが「外部データを分類して固定アクションをトリガーする」だけなら、低推論能力の小型モデル（GPT-4o mini・Claude Haiku）で十分で、コストは10〜20倍安くなります。
次元2：Context Windowサイズ。Agentは推論サイクルごとにどれだけの情報をContextに入れる必要がありますか？DeFiモニタリングAgentは20のプロトコルの現在の状態・24時間のPnL履歴・完全な戦略説明を同時に保持する必要があり、100Kトークンを超えることも珍しくありません。現在の主流モデルの最大Context Window：Gemini 1.5 Pro（100万トークン）・Claude Opus（200K）・GPT-4o（128K）。
次元3：応答速度（Latency）。Agentは時間的に敏感なシナリオで動作しますか？アービトラージAgentは100ミリ秒以内に推論を完了してトランザクションをトリガーする必要があるかもしれませんが、1日1回実行される利回り最適化Agentは30秒の推論時間を待てます。大型フロンティアモデル（Claude Opus・GPT-4o）の推論レイテンシは通常10〜30秒；小型モデル（Haiku・GPT-4o mini）は1〜3秒で完了します。
次元4：ツール呼び出しの信頼性（Function Calling Reliability）。Agentはツール呼び出しを正しくフォーマットするLLMの能力に依存します。推論能力は強くてもツール呼び出しのフォーマットが不安定なLLMもあります。推奨：デプロイ前に実際のツールセットで50〜100回の推論サイクルを実行し、ツール呼び出しフォーマットエラー率を追跡します（理想的な目標：2%未満）。
Context Windowサイズは推論ごとのコストと直接相関しており、Agent選択において最も過小評価されているコスト要因の一つです。
AgentがContextに50Kトークンを必要とし、1日48回の推論サイクル（30分ごと）を実行すると仮定します：
Claude Opus 4を使用（入力$15/百万トークン）：50,000 × $15/1,000,000 × 48 = $36/日 = $1,080/月。
Claude Haikuを使用（入力$0.25/百万トークン）：50,000 × $0.25/1,000,000 × 48 = $0.60/日 = $18/月。
タスクがHaikuで完了できるなら、月$1,062の節約になります。しかしHaikuの推論品質が不十分で週1回の誤操作を引き起こすと、損失はこのコスト差をはるかに超えます。
この計算は反直感的な原則を示しています：高い推論能力を必要としないタスクに高価なモデルを使うのは二重の無駄です——API費用を余分に払い、システムの応答速度を遅くします。正しいアプローチ：Agentのサブタスクを推論複雑度でレイヤー分けし、高複雑度タスクにはフロンティアモデルを、低複雑度タスクには小型モデルを使います。
実用的なハイブリッドアーキテクチャ：OrchestratorレイヤーにClaude Opusを使って戦略的推論を行い、データ収集サブAgentにClaude Haikuを使ってデータ整理とフォーマットを行います。これにより、システムの平均トークンコストが60〜80%削減され、重要な意思決定の推論品質は維持されます。
LLM選択において、速度・品質・コストの3つを同時に最適化することはほぼ不可能です。Agentにとって「妥協できない」次元を明確にする必要があります：
速度が妥協できない場合（ミリ秒応答のアービトラージAgent・リアルタイム意思決定システム）：最小のモデルを選び、推論品質のトレードオフを受け入れます。最適化方向：Contextを短縮・起動時に複雑な推論を事前計算してキャッシュ・ストリーミング出力を使用。
品質が妥協できない場合（高資金量の投資決策Agent・複雑な条件判断が必要なガバナンスAgent）：フロンティアモデルを選び、高コストと低速を受け入れます。最適化方向：CoT（Chain of Thought）を使用・高不確実性シナリオでは積極的に人間の確認を要求・完全なContextを保持。
コストが妥協できない場合（低収益・高頻度の監視Agent）：小型モデルを選び、複雑な推論タスクを複数の単純なサブタスクに分解します。最適化方向：プロンプトエンジニアリングで出力フォーマットを予測可能に・Semantic Cacheで重複するLLM呼び出しを削減・最大日次推論回数を制限。
Agentのコアタスクタイプ別の具体的なLLM推奨：
DeFi利回り最適化Agent（1日1回、レート比較+リバランス）：OrchestratorにClaude SonnetまたはGPT-4o mini、サブAgentにClaude Haikuを使用。フロンティアモデルは不要——ロジックは明確で、小型モデルで確実に完了でき、単純な数値比較にフロンティア価格を払う必要はありません。
オンチェーンガバナンス提案分析Agent（週数回、複雑な提案の理解と要約・推奨の生成）：フロンティアモデル（Claude OpusまたはGPT-4o）が必要です。理由：ガバナンス提案は通常複雑な法律/技術的言語を含み、暗示的な意味とリスクを正しく理解するために高い推論能力が必要です。
アービトラージ実行Agent（ミリ秒応答、価格差が現れたらトリガー）：LLMは実行パスにあるべきではありません。アービトラージ実行は通常純粋なコードロジックであり、LLM推論は不要です。LLMをアービトラージ実行パスに置くと、レイテンシによってすでに機会は消えています。
ソーシャル監視+オンチェーン応答Agent（Twitter/Discordのセンチメント監視、センチメント変化時にポジション調整）：センチメント分析には小型モデル（GPT-4o mini）、ポジション調整の意思決定には中型モデル（Claude Sonnet）+人間確認ゲートを使用。
LLM選択のミスは隠れたコストです——バグのようにすぐにクラッシュするのではなく、毎月数百ドルの不必要なAPI費用を発生させたり、比較テストなしに小型モデルで解決できるタスクにデフォルトでフロンティアモデルを使ったりします。
実行可能な選択ワークフロー：まずAgentのすべての推論ステップを列挙し、各ステップの複雑度をスコアリング（1〜5点）します。次に、3点以上のステップにはフロンティアモデルをテストし、1〜2点のステップには小型モデルで完了できるかをテストします。テスト時には出力品質だけでなく、ツール呼び出しフォーマットエラー率も評価します。デプロイ後は毎月のLLM API費用トレンドを監視します。
最終的に、LLMはAgentの魂ではなくエンジンです。必要なエンジンは、車がどれだけ速く走る必要があるか・どれだけ重い荷物を運ぶか・どれだけ遠くまで走るかによって決まります——高ければ良いのではなく、最も適切なものが良いのです。