LLMトレーシングツールが今、AIゲートウェイを構築している理由

2026年、LangSmith、Langfuse、Opik、Braintrustはいずれも、モデルプロバイダーの手前にゲートウェイを追加した。主な理由は制御にある。トレーシングツールができるのはモデル呼び出しの記録だけだが、ゲートウェイなら呼び出しを止められる。

異なる役割を担っていた2つのツール

この2年間、多くのチームは大規模言語モデル（LLM）アプリケーションの運用に、別々のツールを2つ使っていた。アプリケーションとモデルプロバイダーの間にはゲートウェイが置かれ、プロバイダーのAPIキーを管理し、プロバイダー間のAPI形式を変換して、失敗した呼び出しを再試行していた。この用途では、オープンソースのプロキシであるLiteLLMが広く使われるようになった。アプリケーションのそばにはLangSmithやLangfuseなどのトレーシングツールがあり、モデル呼び出し、ツール呼び出し、検索の各ステップを記録することで、エンジニアがエージェントの動作を把握できるようにしていた。

この役割分担には理にかなった理由があった。ゲートウェイには高速性とあらゆるプロバイダーのAPIへの対応が求められる一方、トレーシングツールには使いやすいインターフェース、大容量データを保存する仕組み、アプリケーションコードをラップするSDKが必要だからだ。Langfuseは現在も、すべての呼び出しをプロキシ経由でLangfuseに送るLiteLLM Proxyとの連携を含む、2つのツールを使う構成を案内している。2026年、トレーシングツールのベンダー各社は、自らゲートウェイの構築に乗り出した。

6カ月間に相次いだ4つの発表

LangChainは2026年5月にLangSmith LLM Gatewayのプライベートベータを発表し、7月30日にパブリックベータとして公開した。その後、このゲートウェイはLangSmithのクラウド持ち込み型導入環境にも組み込まれた。Braintrustは従来のAIプロキシを非推奨とし、ユーザーに新しいゲートウェイを案内した。このゲートウェイはプレビュー版で、一般提供が始まるまでは無料で利用できる。Cometは、OpenAI形式のリクエストを受け付けるベータ版エンドポイントとしてOpik LLM Gatewayを公開した。11月4日、LangfuseはLangfuse Cloudとセルフホスト環境の両方で、AI Gatewayのパブリックベータを開始した。このゲートウェイはMITライセンスで提供され、Rustで開発されている。

機械学習ライフサイクル管理ツールとして始まり、トレーサーではなかったMLflowは、より早くからAIゲートウェイを提供しており、予算アラートや利用上限にも対応している。

ゲートウェイ自体は以前から使われており、運用に伴うリスクもよく知られている。新しいゲートウェイを提供しているのは、これまでモデル呼び出しの記録を事業の中心としてきた企業だ。そして今、各社はすべての呼び出しをまず自社のゲートウェイに通そうとしている。

予算管理にリクエスト経路が必要な理由

トレーシングツールがモデル呼び出しを記録するのは、プロバイダーが応答し、トークンの料金が発生した後だ。その記録があれば支出額のグラフは作成できるが、トレーシングツールで支出を止めることはできない。チームの予算を守ること、モデルをブロックすること、プロンプトから秘密情報を取り除くことは、いずれもリクエストがプロバイダーに届く前に確認する必要がある。それができるのは、リクエスト経路上にあるコンポーネントだけだ。

LangChainはローンチ記事でこの主張を展開している。同社によると、チームは別個のゲートウェイ、ガードレール製品、可観測性ツールを組み合わせており、問題を未然に防ぐにはリクエスト層でポリシーを適用する必要があるという。同社のゲートウェイは、予算超過につながる呼び出しに対して、プロバイダーに転送する代わりにHTTPステータスコード402を返す。

1つの接続先ですべての呼び出しを記録

2つ目の理由は、対象範囲の広さだ。SDKが記録できるのは、計測処理を組み込んだコード経路だけである。その範囲外では、エージェントの失敗が見過ごされやすい。ノートパソコン上のスクリプト、ノートブック、コピーしたAPIキーを使うコーディングエージェントの呼び出しは、記録に残らない。プロバイダーのキーを管理するゲートウェイなら、プロバイダーへの別経路がないため、すべての呼び出しを把握できる。

Langfuseはこの考え方を中心にゲートウェイを構築している。ゲートウェイのドキュメントによると、ゲートウェイキーはユーザーまたはサービスアカウントにひも付けられ、チーム名やコストセンターなどのメタデータを付与できる。プロバイダーの認証情報を保持するのはゲートウェイだけであり、各認証情報で呼び出せるモデルは管理者が承認する。LangSmithは、Claude Code、Codex、Gemini CLIを自社のゲートウェイ経由で接続するための設定手順を公開している。これらのエージェントは、アプリケーションのトレーシングコードの範囲外にある開発者のマシンからモデルを呼び出す。

トレーサーに組み込まれたゲートウェイがもたらすもの

トレーシングツールのベンダーは逆の主張もしている。つまり、単体のゲートウェイだけでは不十分だという。Langfuseのローンチ記事によると、単体のゲートウェイで数えられるのはトークン数とコストだけだが、自社のゲートウェイを使えば、各呼び出しを完全なトレースの一部として記録できる。LangfuseのゲートウェイはW3Cのtraceparentヘッダーを受け付けるため、経由した呼び出しはアプリケーションがすでに開始したトレースに加わる。デフォルトで記録されるのは利用状況とコストであり、プロンプトや応答の内容は記録されない。

これが、ゲートウェイをトレーサーに組み込むことを支持する最も有力な技術的根拠だ。単体のゲートウェイに見えるのは、生成結果の平坦な一覧にすぎない。一方、トレーサーにはSDKを通じてエージェントのツール呼び出しや検索ステップがすでに記録されているため、ゲートウェイ経由の各呼び出しをその構造の中に位置付けられる。

ベンダー自身は明言していませんが、商業的な側面から見ることもできます。ゲートウェイを運用する事業者は、プロバイダーのキーと利用額レポートを管理します。財務チームやプラットフォームチームが確認するのは、その利用額レポートです。そのため、ゲートウェイはトレースビューアーよりも置き換えにくくなります。LangSmithとLangfuseはすでに、この立場をそれぞれ異なる形で活用しています。LangSmithはGateway Creditsを販売しており、これを使えば顧客は自社のプロバイダーキーを使わずに、Kimiなどのホスト型モデルを呼び出せます。一方、LangfuseのFAQには、トークンの再販売は行っていないと記載されています。

ベータ版ゲートウェイでまだできないこと

これらのゲートウェイは登場して間もなく、各ベンダーも自社製品の制約を説明しています。現在、Langfuseのゲートウェイが対応しているのはOpenAIとAnthropicのみで、Amazon Bedrock、Google Vertex AI、Google AI Studioは今後の対応予定に含まれています。プロバイダー間のフェイルオーバーや、チーム、ユーザー、キーごとの厳格な利用額上限は計画されていますが、まだ提供されていません。当面、ゲートウェイが提供するのは利用額ダッシュボードとアラートです。ドキュメントには、レート制限やレスポンスのキャッシュについての説明もありません。

LangfuseのゲートウェイはAPI形式間の変換に対応していないため、OpenAIクライアントから呼び出せるのはOpenAIのモデルに限られます。セルフホスト版は公式のプロバイダーURLのみを呼び出すため、現時点ではAzure OpenAI、Bedrock、社内プロキシは利用できません。Cometは、Opikゲートウェイを開発とテスト向けに設計したものと説明しています。Braintrustは、自社ゲートウェイの価格をまだ発表していません。

LangSmithのゲートウェイは、すでに他の製品より多くの機能を備えています。ドキュメントでは、フェイルオーバー、利用額制限、レート制限、データポリシーが現行機能として挙げられており、OpenAI Chat Completions、OpenAI Responses、Anthropic Messagesの各形式を受け付けます。フェイルオーバーとレート制限は5月時点では今後の対応項目に挙げられていましたが、ベータ期間中に実装されました。製品全体には、現在もベータ版と表示されています。

負荷テストからは、別の種類の課題が見えてきます。Langfuseのゲートウェイ、LiteLLM、AcruxCoreをセルフホスト環境で比較したベンチマークでは、Langfuseのゲートウェイが呼び出しごとに加えるレイテンシは、LiteLLMより小さいことが分かりました。しかし、Dockerのデフォルト設定では、同時に処理する1,000ストリームのうち739件で失敗しました。プロセスが、Dockerのデフォルトであるオープンファイル数の上限1,024をそのまま使用していたためです。LangfuseのComposeファイルに1行追加するだけで、この問題は解消しました。

こうしたベータ版と比べると、長年にわたって単独のゲートウェイとして提供されてきたLiteLLMは、100を超えるプロバイダーに対応し、仮想キー、利用額の追跡、ガードレール、負荷分散、管理ダッシュボードをすでに備えています。またLiteLLMは、リクエスト処理をPythonからRustへ移行しています。Rust AI Gatewayはベータ版で、LiteLLMチームは、Anthropic形式の/v1/messagesリクエストを12月1日までにRustでエンドツーエンド処理できるようになり、レイテンシを約20分の1にできると見込んでいます。MLflowやAcruxCoreなど、一部のオープンソースプラットフォームは、ゲートウェイとトレーシングをすでに1つの製品にまとめて提供しています。

分けておくべき理由

ゲートウェイをトレーサーに統合すると、コストが生じます。最大の問題は、両者が密接に結びつくことです。ゲートウェイが独立していれば、チームはログ記録のコールバックを変更するだけで、トレーシングベンダーを切り替えられます。一方、トレーサーがゲートウェイも兼ねると、各サービスのベースURL、キー、モデル識別子もすべて変更しなければなりません。たとえばLangfuseでは、モデル識別子をcredential:modelの形式で記述します。

トレーサーは、実行時の依存先にもなります。トレーシングのバックエンドが停止すると、チームはトレースを失います。ゲートウェイが停止すれば、モデル呼び出しが失敗します。ゲートウェイを運用するトレーシングベンダーには、今や重要なインフラに求められる稼働率が必要です。

セキュリティベンダーも、リクエスト経路における同じ立場を求めています。Palo Alto Networksは、独立型ゲートウェイであるPortkeyの買収を2026年5月に完了し、同社のPrisma AIRSプラットフォームにおけるAIゲートウェイとして位置づけました。セキュリティチームは、可観測性ツールの内部ではなく、自らの管理下にゲートウェイを置きたいと考える場合があります。また、ゲートウェイは攻撃者の標的にもなっています。3月に発生したLiteLLMのサプライチェーン侵害がその一例です。

チームが選ぶ際のポイント

まず、モデルを呼び出す前に何を行う必要があるかを、チームで洗い出すとよいでしょう。必要なのが可視性だけなら、リクエスト経路の外にトレーサーを置けば十分で、実行時の依存先も増えません。予算管理、キーのポリシー、モデルの承認も必要であれば、何らかのゲートウェイが必要です。

次に確認すべきなのは、プロバイダーへの対応状況です。本番環境で呼び出すプロバイダーとAPI形式をすべて書き出し、Azure OpenAIやBedrockも含めたうえで、その一覧を各ゲートウェイの今後の対応予定ではなく、現時点での対応状況と照らし合わせるべきです。

すでにLiteLLMを運用しているチームは、ベータ版ゲートウェイが不足している機能を提供するまでは、移行する理由がほとんどありません。トレーサーのゲートウェイが主に追加するのは、ゲートウェイ経由の呼び出しをエージェントのトレースに含められることです。その利点が移行に見合う必要があります。新たに導入するチームは、1社のベンダーが両方を提供している場合でも、ゲートウェイを独立したレイヤーとして維持できます。ベースURLとキーを1つの設定モジュールにまとめておけば、後から移行する際にコードを変更せず、設定の変更だけで済みます。

これらのゲートウェイの大半はベータ版またはプレビュー版とされているため、制約は急速に解消されていくでしょう。まだ決着していないのは、一般的な企業でリクエスト経路を誰が管理するのかという問題です。可観測性チームなのか、独立型ゲートウェイを運用するプラットフォームチームなのか、それともセキュリティチームなのか。今年、LangSmithとLangfuseは独自のゲートウェイを構築し、Palo Alto Networksはゲートウェイを買収しました。それでも、多くのシステム構成では、リクエスト経路は依然としてLiteLLMを経由しています。