Newsfeed / OpenRouter COO: エージェントが本当に本番環境に投入される方法
AI Day·January 28, 2026

OpenRouter COO: エージェントが本当に本番環境に投入される方法

OpenRouterのChrisが共有するエージェント採用データ: ツールコール率が1年で5倍に急増し、推論トークンが出力の50%を占める。何が実際に機能しているのか。

OpenRouter COO: エージェントが本当に本番環境に投入される方法

OpenRouterの1兆トークンが明かすエージェント採用

OpenRouterの共同創業者兼COOであるChrisは、ユニークな視点を持つ立場にいます。70以上のクラウドプロバイダー全体で毎日1兆以上のトークンを処理する中で、OpenRouterはAIが実際にどのように使われているのかを目撃しています。デモではなく、実験でもなく、スケールでの実際のワークロードです。

データが物語る明確なストーリー: エージェントはもはや理論的なものではありません。本番環境に投入されています。

ツールコーリング爆発: "5%未満から25%を大きく超える範囲に。そしてこれは急速に上昇しています。" Anthropicモデル単体で見ると、APIコールの中でツール要求で終わる割合が12か月間で5倍に急増しました。これは本番環境に展開されているエージェントの「排気署名」です。

SLAの瞬間: 2025年7月頃に何かが変わりました。Chrisは思い出します: "突然、顧客はSLAとアップタイムについての質問をし始めました... これは非常に強い指標です。これらのものが企業グループのテストから本番環境に移行したことを示しています。そしてダウンすると、それが重要になり始めます。"

推論トークンが今支配している: 1年前は、推論モデルは本番環境に存在しませんでした。今、OpenRouterが見るすべての出力トークンの50%は内部推論トークンです。エージェントは行動する前に考えています。

なぜモデルミックスが新しい標準になったのか

最も成功しているエージェントは単一のモデルを使用しません。異なるタスクのために複数のモデルを使用しています:

計画用のフロンティアモデル: Claude、GPT-4、Geminiは「判断呼び出し」を処理します。文脈を理解し、次のステップを計画し、ニュアンスが必要な決定を行います。

実行用の小規模モデル: QwenやMiniMaxのような安価で高速なモデルがツールコール自体を処理します。Chrisは説明します: "彼らはツールコール要求を実行するために、そして実行するために、より小さな特別なモデルを使用しています。判断の観点からはそれほどスマートではありませんが、非常に正確で、ツール使用に非常に優れています。"

このパターン(最高のものを使って理由を考え、高速なもので実行する)は、本番環境のエージェントが品質とコストの両方をどのように管理するかです。

誰も話さない推論品質の問題

ここに反直感的なことがあります: 同じモデルの重みでも、異なるクラウド上では異なる結果を生み出します。

OpenRouterのベンチマークは、同じモデルが以下を持つことができることを明らかにしました:

  • プロバイダー全体で異なる精度スコア
  • 異なるツール呼び出し頻度
  • 本番パフォーマンスで意味のある差異

"なぜ同じモデルと同じスマートさを持つ、全く同じモデルが異なる状況でツールを異なる方法で使用することを選択するのでしょうか?" 答えは推論スタックの実装方法の微妙な違いにあります。量子化、サービス提供インフラストラクチャ、APIハンドリングです。

これがOpenRouterが「Exactoエンドポイント」を作成した理由です。ツールコーリング精度についてベンチマークされたプロバイダーのみを含むルーティングプール。エージェントの場合、推論品質はモデル品質と同じくらい重要です。

創業者がエージェント構築で犯した最大の間違い

創業者が何を間違えるのか聞かれたとき、Chrisの答えは予想外でした: 彼らはオプション性のために構築していません。

"12か月で何が必要になり、推論がどこから来るのか、どのようなモデルが必要になるのかを予測することは非常に難しいです。"

解決策は今日完全なモデルを選ぶことではありません。明日モデルを切り替えることができるインフラストラクチャを構築することです。1つのプロバイダーにロックされているエージェント:

  • 新しいフロンティアモデルがドロップしたときのテストができない
  • ユースケースが証明されたら、より安いモデルにダウングレードできない
  • プロバイダーが停止したときにフェイルオーバーできない

エンタープライズエージェントが実際に必要なもの

スケール時でエージェントを展開するチームの場合、Chrisは重要な関心事を特定しました:

アップタイムとフェイルオーバー: 本番環境のエージェントはダウンできません。期間。これはマルチプロバイダールーティング、自動フェイルオーバー、および実際の監視を意味します。

データポリシーの明確性: "彼らのデータセンターはどこにありますか? 彼らは実際にGPUを所有していますか、それとも異なるデータセンターでリースされているGPUを持っていますか? 復号化はどこで起こっていますか?" エンタープライズセキュリティチームは答えが必要です。

バースト容量: エージェントはスケジュールで実行されます。夜間バッチジョブ、定期的なワークフロー。スパイクの多いワークロードのためにコミットされた容量を購入することは機能しません。共有インフラストラクチャは機能します。

AIエージェント構築チーム向けの4つのテイクアウェイ

  • ツール呼び出しはエージェント署名 - ツール呼び出し率を測定していない場合、エージェント採用を測定していない
  • フロンティアと特別なモデルをミックス - 推論に最高のモデルを使用し、実行に高速なモデルを使用
  • 推論品質は大きく異なる - 同じモデルでもプロバイダー間で異なる動作が可能。あなたの特定のユースケースをベンチマークしてください
  • 完璧さではなくオプション性のために構築 - モデルの風景は毎月変わります。ロックインが本当のリスクです

AIパワーの組織にとってなぜこれが重要なのか

OpenRouterのデータは私たちが見てきたことを確認しています: 長時間実行されるエージェントはここにあります、そしてそれらを機能させるインフラストラクチャパターンが明確になっています。

シフトは単なる技術的なものではありません。それは運用的です。顧客がSLAについて質問を始めるとき、ツール呼び出し率が1年で5倍になるとき、推論トークンが出力の50%に達するとき... それはスケール時の本番環境採用です。

組織の質問はエージェントを展開するかどうかではありません。それはエージェントを実際に機能させるインフラストラクチャを構築する方法です: マルチモデルルーティング、推論品質監視、および風景の進化に適応する柔軟性。

Related