LangSmith LLM ゲートウェイ：エージェントライフサイクルに組み込まれたランタイムガバナンス
LangChain は、エージェントと LLM プロバイダー間に配置され、コスト制限の適用や PII の自動除去を行う「LLM Gateway」を LangSmith ベータ版として発表し、運用ガバナンスの実装を劇的に簡素化した。
キーポイント
ランタイムガバナンスの統合
エージェントと LLM プロバイダー間にゲートウェイを配置し、リクエストがモデルに到達する前にコスト制限や機密情報（PII）の除去を実行する。
単一ツールでの可視化と対応
ポリシー違反が発生した際、別々のダッシュボードやログを参照せず、LangSmith 内のトレースから問題の原因特定から修正までを一貫して行える。
最小限の設定変更での導入
インフラの追加不要で、base_url の書き換えとシークレット設定を行うだけで、1 行の変更でゲートウェイ機能を有効化できる。
影響分析・編集コメントを表示
影響分析
この発表は、LLM アプリケーション開発における「観測（Observability）」と「実行制御（Enforcement）」の断絶を解消し、セキュリティとコスト管理をデプロイ後の運用段階ではなく、ランタイムで自動的に保証する新たな標準を提供します。特に大規模なエージェントシステムや企業向け AI 導入において、インフラ構築の手間なくコンプライアンスと予算管理を実現できる点は、実用化の障壁を大きく下げる重要な進展です。
編集コメント
LLM アプリケーションの運用リスクを「事後対応」から「事前防止」へ転換する、実務的なセキュリティレイヤーの登場です。特に LangChain エコシステム内での導入が極めて容易な点は、即座に現場適用できる価値があります。
重要なポイント
- LLM Gateway は、エージェントと LLM プロバイダーの間に位置し、リクエストがモデルに到達する前に支出制限を適用し、個人識別情報（PII: Personally Identifiable Information）を削除します。これにより、事後のログ記録ではなく、問題の発生源で阻止することが可能になります。
- ガバナンス機能は、あなたがすでに作業を行っている場所に存在します。ポリシー違反は LangSmith 内で追跡可能なイベントとして表面化するため、ツールを切り替えることなく、ブロックされたリクエストからトリガーとなったトレース、そして修正へとスムーズに移行できます。
- セットアップは一行の変更で完了します。ベース URL を LangSmith Gateway エンドポイントに置き換え、プロバイダーキーをワークスペースのシークレットに追加し、ポリシーを UI で設定するだけです。別個のインフラストラクチャは不要です。
本日、LangSmith LLM Gateway のプライベートベータ版をリリースします。これは、LangSmith 内でエージェントの構築、観測、評価を行う場所そのものに組み込まれたランタイムガバナンスレイヤーです。
LangSmith LLM Gateway は、エージェントとそれらが呼び出す LLM プロバイダーの間に位置し、コスト制限を適用し、リクエストがモデルに到達する前に機密データを削除します。ポリシーが発火すると、イベントは別個のダッシュボード、監査ログ、またはツールを必要とすることなく、直接 LangSmith 内に流れます。ブロックされたリクエストから、それをトリガーしたトレース、そして修正までを、一つの製品内で完結させることができます。
観測と実行のギャップ
これが実務においてどのように見えるか説明します。コーディングエージェントが夜間にリトライループに陥り、朝には 10,000 回の LLM（大規模言語モデル）呼び出しを実行してしまい、請求書が四桁の金額になっているというケースです。
顧客サポートエージェントが社会保障番号を含む返金リクエストを処理しました。その番号は現在、LLM プロバイダーのログやトレースデータに保存されており、応答を消費したあらゆる下流システムにも存在している可能性があります。
これらは例外的事例ではなく、本番環境でエージェントを実行する際の日常茶飯事です。観測（Observability）機能は「何が起きたか」を教えてくれますが、問題が発生する前にそれを防ぐためには、リクエスト層でポリシーを実行する必要があります。これまで、両方を実現するには、別個のゲートウェイ、ガードレールプラットフォーム、観測スタックを組み合わせ、何か問題が起きた際にこれら 3 つ全体にわたってシグナルを相関させる必要がありました。Agent Gateway は、これらをすべて LangSmith の内部に統合します。
今日ベータ版として提供されている機能
LLM ゲートウェイは、企業が最初に必要とすると私たちに伝えてきた制御機能を搭載してリリースされています：
支出制限： 組織、ワークスペース、ユーザー、または API キーのレベルで堅牢な上限を設定できます。上限に達すると、エージェントには明確なエラーメッセージと共に HTTP 402（Payment Required）レスポンスが返されます。
支出の可視化: ワークスペース、ユーザー、API キーごとのリアルタイムコスト集計。月末の予期せぬ請求書はもうありません。
PII（個人識別情報）およびシークレットの検出: 機密データは、モデルに到達する前またはトレースに書き込まれる前に、リクエストとレスポンスからマスキングされます。エージェントは実行を継続し、機密データの伝播は防止されます。
トレースの連続性: ゲートウェイ経由のプロキシ呼び出しは、エージェントの他のトレースと同じ LangSmith ワークスペースに表示されます。ゲートウェイを介したルーティングにより、観測可能性が分断されることはありません。
LangSmith Engine 統合: ポリシーイベントは LangSmith Engine でトリージョン（選別）の対象となります。製品から離れることなく、違反事項をクリックしてそれを生成したトレースに遷移できます。
監査ログ: ゲートウェイ内のすべての管理アクションがログ記録されます。コンプライアンスおよびセキュリティチームは、別途監査パイプラインを構築することなく完全な記録を取得できます。
階層型強制: 組織レベル、ワークスペースレベル、ユーザーレベル、または API キーレベルで適用可能であるため、ポリシーが必要な場所に集中させることができます。
セットアップは意図的に地味に設計されています
LangSmith API キーを使用して、エージェントを LangSmith Gateway エンドポイントに向けます。プロバイダーの API キーをワークスペースのシークレットに追加します。LangSmith UI でポリシーを設定します。これがセットアップ全体です。
base_url を置き換えるだけです。コードはそのまま維持できます。
ビルド、観測、評価と同じ画面でのガバナンス
ほとんどのガバナンスツールは、ポリシー用の別コンソール、アラート用の別ダッシュボード、調査用の別フローなど、独自のインターフェースで設定・利用されます。この形状は、ガバナンスがチームの主要な焦点である場合に機能します。しかし、すでに別の場所でエージェントの構築、観測、評価を行っている場合、これはより大きな負担となります。
LLM Gateway は LangSmith で設定されます。ブロックされたリクエストは LangSmith 内の追跡可能なイベントです。マスキングされた PII（個人識別情報）の一致は、その発生元となった正確なトレースにクリックして遷移できるシグナルです。そこから、エージェントが何を行っているかを確認し、システムプロンプトやツール設定を更新し、製品を離れることなく既存のテストセットに対して再評価を行うことができます。
LangSmith をすでに利用しているチームにとって、これはツールの削減、コンテキストスイッチの減少、そしてその原因を説明するトレースデータの隣に到着するポリシーイベントを意味します。検出、調査、および修復は、エージェントが構築される同じ画面で行われます。
ガバナンスはどこに存在すべきかを選ぶ
エージェントガバナンス市場は急速に形成されており、現在のほとんどのツールはいくつかの形状のいずれかに分類されます：
- ネットワーク層ゲートウェイは、レート制限、ルーティング、トラフィックガバナンスなど、強力なインフラストラクチャ制御を提供します。LLM 呼び出しを他の API トラフィックと同様に扱うことを最優先する場合は、これらが適しています。ただし、ポリシーが発火した際にデバッグのためにトレースコンテキストが得られず、ポリシーの調整も AI の特性を意識したものではないというトレードオフがあります。
- スタンドアロンのガードレールプラットフォームは、小規模な評価モデルを基盤とした洗練された評価とポリシーを提供します。エージェントの変化に合わせてこれらのモデルを調整し、そのエコシステムをエンドツーエンドで採用する覚悟がある場合に適しています。ただし、エージェント、トレース、評価が2つの場所に分散することになり、第2の観測面（オバザビリティサーフェス）の維持が必要になるというトレードオフがあります。
- データプラットフォームガバナンス層は、データカタログやレイクハウスを拡張して AI ワークロードをカバーします。チームがすでにそのプラットフォームに深く組み込まれている場合に適しています。ただし、そうでない場合、導入することは機能追加ではなく移行を意味するというトレードオフがあります。
LLM Gateway は、エージェントが実際に構築・実行される場所であるエージェントフレームワーク自体にアンカーされています。このアンカーこそが、ポリシーイベントをトレース、評価、ダッシュボードと同じワークスペースへ流し込むことを可能にします。また、これにより、エージェントの進化に伴って正確性を保つために別個のファインチューニングループや評価モデルの監視が必要となることなく、実際の生産環境におけるエージェントの振る舞いに基づいてポリシーを調整することが可能になります。
もしあなたのチームのエージェントがすでに LangSmith に存在しているなら、これはあなたに離脱を求めないガバナンス層です。
ここでの方向性
今回の発表では LLM コールについて取り上げますが、エージェントはそれ以上のことを行います。LangSmith Agent Gateway は、必要なすべてのランタイムポリシーに対する中央制御プレーンとして構築されており、今後予定されている機能は以下の通りです。
- より深いセキュリティコントロール：PII やシークレットの検出を超え、外部モデルへの呼び出しや生産システムへのアクセスを伴うエージェント特有のリスク全体をカバーします。
- 柔軟な適用方法：ポリシーが発火した際にもエージェントが稼働し続けるよう、ハードブロックを行う前に段階的なロールアウト、モデルのフォールバックと置換、そして生産環境を崩壊させずに行動を制御するためのレート制限を提供します。
- ツールおよび MCP ゲートウェイ：LLM コールのみに限定されず、ツール呼び出し、エージェント間通信、MCP サーバーとの相互作用にも、同じ適用プリミティブが適用されます。
現在、エージェントガバナンスは主にエージェントシステムの上に追加されています。私たちはこれが長期的な最適な形であるとは思っていません。エージェントの構築、観測、評価を行う同じ製品こそが、それらが実行するルールを強制すべきです。LLM Gateway はその始まり地点となります。
関連コンテンツ
LangSmith
LangSmith Engine の紹介
Ben Tannyhill
2026 年 5 月 13 日
5 分
LangSmith
SmithDB を紹介します：エージェントの可観測性のためのデータレイヤー
Ankush Gola
2026 年 5 月 13 日
11 分
LangSmith
LangSmith Context Hub のご紹介
Harrison Chase
2026 年 5 月 13 日
8 分
エージェントが実際に何をしているかを確認する
LangSmith は、開発者がエージェントのすべての意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるためのエージェントエンジニアリングプラットフォームです。
原文を表示
Key Takeaways
- LLM Gateway sits between your agents and LLM providers — it enforces spend limits and redacts PII before requests reach the model, stopping problems at the source rather than just logging them after the fact.
- Governance lives where you already work — policy violations surface as traceable events inside LangSmith, so you can go from a blocked request to the triggering trace to a fix without switching tools.
- Setup is a one-line change — swap your base_url to the LangSmith Gateway endpoint, add your provider keys to workspace secrets, and set policies in the UI. No separate infrastructure required.
Today we’re launching LangSmith LLM Gateway in private beta. It’s a runtime governance layer that lives where you already build, observe, and evaluate your agents in LangSmith.
LangSmith LLM Gateway sits between your agents and the LLM providers they call. It enforces cost limits and redacts sensitive data before requests reach the model. When a policy fires, the event flows directly into LangSmith without requiring separate dashboards, audit logs, or tools. You can go from a blocked request to the trace that triggered it to the fix, all in one product.
The gap between observability and enforcement
Here’s what this looks like in practice. A coding agent gets stuck in a retry loop overnight, and by morning it’s made 10,000 LLM calls and you have a four-figure invoice.
A customer support agent processes a refund request that includes a social security number. The number is now sitting in an LLM provider’s logs, in trace data, and possibly in any downstream system that consumed the response.
These are not edge cases, but instead are the daily reality of running agents in production. Observability tells you what happened, but stopping these problems before they happen means enforcing policies at the request layer. Until now, getting both meant stitching together a separate gateway, a guardrails platform, and an observability stack, then trying to correlate signals across all three when something went wrong. Agent Gateway puts both inside LangSmith.
What’s in beta today
LLM Gateway ships with the controls enterprises have told us they need first:
Spend limits: Set hard caps at the organization, workspace, user, or API key level. When a cap is hit, the agent receives a 402 response with a clear error.
Spend visibility: Real-time cost rollups by workspace, user and API key. No more month-end surprise invoices.
PII and secrets detection: Sensitive data is redacted from requests and responses before it reaches the model or is written to a trace. The agent keeps running and the sensitive data does not propagate.
Trace continuity: Every gateway-proxied call appears in the same LangSmith workspace as the rest of your agent’s traces. Routing through the gateway does not fragment your observability.
LangSmith Engine integration: Policy events surface in LangSmith Engine for triage. Click through from a violation to the trace that produced it without leaving the product.
Audit logging: Every administrative action in gateway is logged. Compliance and security teams get a complete record without standing up a separate audit pipeline.
Layered enforcement: at the organization, workspace, user or API key level so you can focus policies where they are most needed.
Setup is intentionally boring
Point your agents at the LangSmith Gateway endpoint using your LangSmith API key. Add your provider API keys to workspace secrets. Set policies in the LangSmith UI. That is the entire setup.
Swap the base_url. Keep your code.
Governance on the same surface as build, observe, and evaluate
Most governance tools are configured and consumed in their own surface, such as a separate console for policies, a separate dashboard for alerts, a separate flow for investigation. That shape works if governance is the team’s main focus. However, it poses a heavier lift if the team is already building, observing, and evaluating agents somewhere else.
LLM Gateway is configured in LangSmith. A blocked request is a traceable event in LangSmith. A redacted PII match is a signal one can click through to the exact trace that produced it. From there, you can see what the agent was doing, update the system prompt or tool configuration, and re-evaluate against your existing test sets without leaving the product.
For teams already on LangSmith, this means fewer tools, fewer context switches, and policy events that arrive next to the trace data that explains them. Detection, investigation, and remediation happen on the same surface where agents are built.
Choosing where governance should live
The agent governance market is forming fast, and most tools today fall into one of a few shapes:
- Network-layer gateways give you strong infrastructure control, like rate limiting, routing, and traffic governance. They're a good fit if your priority is treating LLM calls like any other API traffic. The trade-off is that when a policy fires, you don't get the trace context to debug why it fired, and policy tuning isn't AI-aware.
- Standalone guardrails platforms give you sophisticated evaluation and policy, often built on small evaluation models. They're a good fit if you're willing to adopt their ecosystem end-to-end and tune those models as your agents change. The trade-off is that your agents, traces, and evaluations now live in two places, and you're maintaining a second observability surface.
- Data-platform governance layers extend a data catalog or lakehouse to cover AI workloads. They're a good fit if your team is already embedded in that platform. The trade-off is that if you aren't, adopting one is a migration, not a feature add.
LLM Gateway is anchored to the agent framework itself, the place where agents are actually built and run. That anchoring is what lets policy events flow into the same workspace as traces, evaluations, and dashboards. It is also what allows us to tune policies on your real production agent behavior without the need for separate fine-tuning loops or monitoring evaluation models to keep them accurate as your agents evolve.
If your team’s agents already live in LangSmith, this is the governance layer that doesn’t ask you to leave.
Where this is going
Today's launch covers LLM calls, but agents do more than that. LangSmith Agent Gateway is built to be the central control plane for every runtime policy you need, and here's what's on the way:
- Deeper security controls: moving beyond PII and secrets detection to cover the full surface of risks that come with agents calling external models and touching production systems.
- Flexible enforcement: softer rollouts before hard blocks, model fallbacks and substitution to keep agents running when a policy fires and rate limits to shape behavior without breaking production.
- Tool and MCP gateways: the same enforcement primitives apply to tool calls, agent-to-agent calls and MCP server interactions — not just LLM calls.
Today, agent governance is mostly added on top of an agentic system. We don’t think that’s the right long-term shape. The same product where agents are built, observed, and evaluated is the product that should enforce the rules they run under. LLM Gateway is where we start.
Related content
LangSmith
Introducing LangSmith Engine
Ben Tannyhill
May 13, 2026
5
min
LangSmith
We built SmithDB, the data layer for agent observability
Ankush Gola
May 13, 2026
11
min
LangSmith
Introducing LangSmith Context Hub
Harrison Chase
May 13, 2026
8
min
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み