LangChain、ガバナンス型エージェント枠組みを発表

ゲートウェイは、エンタープライズ AI におけるランタイム制御プレーンです。あらゆるモデル呼び出し、ツール呼び出し、エージェントの遷移において、ポリシーを実行可能な意思決定に変換します。

ガバナンスが重要な理由

エージェントはすでに生産環境インフラの一部となっています。顧客への回答、コードの作成とデプロイ、社内ナレッジの取得、ビジネスシステム内での実行など、多岐にわたる役割を担っています。自律性が高まるにつれて、中核的なガバナンス課題は、採用速度を低下させることなく、モデル、データ、ツール、プロバイダーを横断するすべての相互作用においてポリシーをどのように適用するかという点にあります。

この問題がますます重要視される背景には、3 つの主要な要因があります。第一に、エージェントワークロードによるトークン消費量の増加により、AI 関連コストの予測が困難になっています。第二に、ビジネス上重要なエージェントは、プロトタイプ段階では必要とされなかった稼働時間や継続性の要件をもたらします。第三に、プライバシー、セキュリティ、および AI に特化した規制により、組織にはポリシーが存在することだけでなく、一貫して適用されていることを証明することが求められています。

規制当局も、エージェント型 AI の急速な成長に対応し始めています。政府は AI の利用方法に関するルールを策定しており、例えば EU AI 法では、AI システムの開発・導入方法を規制し、アプリケーションやユースケースをリスクカテゴリーに分類しています。企業にとっては、これらの規制がコンプライアンス義務となるだけでなく、重大な事業リスクにもなり得ます。違反した場合の罰則も甚大です。

一方、モデル市場は多様化を続けています。最先端モデルを提供する事業者は、より高性能なモデルを高価格で提供し続ける一方で、オープンソースモデルの品質格差は縮小しており、特に チューニングされたエージェントハネス と組み合わせることで、コストを大幅に抑えつつ運用可能です。そのため企業は、複数のモデルを統括し、どのモデルを許可するか、どのタスクを担当させるか、また品質・コスト・レイテンシ・リスクのバランスをどう取るかを決定する必要があります。

LLM ゲートウェイとは、こうした判断を実行するランタイム制御プレーンです。 企業はこれを通じて、以下を一元的に管理できます：

• 利用認証の実施
• 承認済みモデルの選択
• 露出されるコンテキストの最小化
• データおよび支出ポリシーの強制適用
• 障害対応の管理
• 意思決定の根拠となる証拠の保存

トレーシング、評価、モニタリングシステムと連携させることで、ゲートウェイは時間とともにこれらの判断を改善することも可能です。

最大の戦略的メリットの一つは、選択肢の幅が広がることです。チームは、セキュリティやポリシー、テレメトリクスを各アプリケーションで再実装することなく、より優れたモデルを採用し、機能の高いエージェントを構築できます。

ガバナンスの着手点

まず、ガバナンスとは何か。ガバナンスはルールを設定するものであり、ゲートウェイはそのルールを実行する場所です。強力なガバナンスプログラムには、説明責任とリスク管理が不可欠ですが、LLM へのすべてのリクエストに対してこれらのポリシーを適用するのがゲートウェイの役割です。

効果的な運用モデルには、以下の 5 つの要素が必要です。

• ガバナンス: アイデンティティ、所有権、リスクティア、ポリシーの確立
• 意思決定: モデルの選定、リクエストのエスカレーション、必要に応じたフェイルオーバー
• 保護: 各呼び出し境界での制御の実行
• 可視化: ビヘイビアの結果を測定
• 保証: 意思決定の系譜（リンネージ）の維持と時系列による変更管理

組織はそれぞれ異なる状況からスタートします。直近の優先事項は、どの圧力要因に最も直面しているかによって異なります。これらは 3 つの一般的な着手点です。

AI をネイティブに活用する組織では、エージェントの利用が急拡大しているため、トークン利用額の抑制と、その資金がどこで消費され、どのような成果を生み出し、どこで異常行動が見られるかを把握する必要があります。

機密データを扱う組織にとって、まず必要なのは、プロバイダーへのアクセス、データ所在地、保持期間、情報隠蔽、ユーザーおよびワークロードの権限に関する実行可能なルールです。

規制が厳しい業界では、自社の統制機能が実際に機能しているという証拠が最優先されます。ポリシーのバージョン管理、評価結果、監査ログはすべて、この信頼性を支える要素となります。

しかし、採用が進むにつれ、企業は最終的にこれら三つの要素をすべて必要とします。すなわち、行動の可視化、ランタイムでの意思決定に対する制御権、そしてシステムが意図通りに稼働しているという保証です。

統制の基盤

ゲートウェイがポリシーを適用できるのは、それが堅牢な基盤の上に成り立っている場合に限られます。土台となるプラットフォーム自体にセキュリティ上の欠陥があれば、その上に構築されるルーティングやポリシーロジックの量では補えません。エージェントのトラフィックを統制する前に、まずそのエージェントが動作する環境を管理する必要があります。

セキュリティ

エージェントのガバナンスは、エンタープライズインフラに期待されるすべての要件を引き継ぎます。保存時および転送時の暗号化、顧客とプラットフォーム提供者間の明確な責任分担モデル、そして独立したセキュリティ検証です。これは当然の前提条件です。

認証とアイデンティティ

エージェントおよびその運用担当者は、他のエンタープライズシステムと同様の方法で認証を行う必要があります。

これには、SAML や OIDC を介したシングルサインオン（SSO）が含まれます。また、新しい従業員が手動のチケットや事後対応を待たずに自動的にアクセス権を取得できる「即時プロビジョニング」も有効な手段です。

ユーザーのアイデンティティを組織の ID プロバイダーに統合し、個別のログインシステムから切り離すことで、ユーザーのアクセス権剥奪（デプロビジョニング）は単一の操作で完了します。複数のツールにまたがるチェックリスト作業が不要になるのです。

監査ログ

重要な AI の相互作用すべてについて、その事実を証明できる必要があります。監査ログには、誰がワークロードを実行したかやポリシーを変更したかだけでなく、適用されたポリシーのバージョン、生成された結果、および使用されたツールやプロバイダーの情報も記録されるべきです。

これらの証拠を安全に保存するためには、保持期間とアクセス権限に関するポリシーを整備しておくことが不可欠です。

ユーザー管理

アクセス制御は、複数の粒度レベルで機能する必要があります。ロールベースのアクセス制御（RBAC）を利用すれば、組織全体の方針を設定する権限や、財務・規制関連データを表示する権限など、継承された権限を持つロールを割り当てることができます。

SCIM や同様の標準規格を用いれば、ユーザーのプロビジョニングとデプロビジョニングを自動化できます。これにより、従業員の入社、異動、退社に合わせてロールの付与、更新、取り消しを自動で行うことが可能になります。

プロバイダーシークレット

API キーを管理する最もリスクの高い方法は、必要なすべてのエージェントにキーを埋め込むことです。

プロバイダーのシークレットは、1 つの集中管理場所に保存し、一度だけ登録するのが理想です。また、必要な特定のチームにのみアクセス権限を制限すべきです。キーのローテーションが必要な場合も、各エージェントやアプリケーション内で個別に追跡して変更するのではなく、一元化された場所で一度だけ更新すれば十分です。

データ分離

大規模組織では、すべてのチームがすべてのトレース、データセット、またはエージェント実行履歴を見られるべきではありません。

チームとワークスペースは隔離され、各ユーザーが自らの責任範囲に関連する情報にのみアクセスできるようにする必要があります。組織全体で過去にログされたすべての情報を閲覧できるわけではありません。

データ所在地

規制業界や特定の地域においては、データ所在地（データレジデンシー）は重要なコンプライアンス要件です。組織によっては、ベンダープラットフォームのデフォルトのインフラ範囲とは異なる、特定の地理的領域またはインフラ範囲内でトレースやその他の運用データを保存・処理する必要がある場合があります。

これらの機能はすべてを組み合わせることで、ゲートウェイの信頼性を高め、セキュアなエンタープライズプラットフォーム上で運用するための基盤となります。

何をガバナンスすべきか

組織はまず、実際にガバナンスの対象とする範囲を明確に定義する必要があります。

LLM の呼び出し、ツールの呼び出し、MCP の呼び出し、およびエージェント間（A2A）の相互作用は、それぞれ異なるリスクとガバナンス要件を伴います。

LLM の呼び出しにより、個人情報がプロバイダーのログに漏洩する可能性があります。ツール呼び出しが機密性の高いシステムレコードに対して実行されるリスクもあります。MCP 呼び出しでは、データが組織のインフラ境界外へ送信される恐れがあります。さらに、エージェント間での相互作用によって、不正なコンテキストがエージェントチェーンを横断して伝播する可能性も否定できません。

LLM ゲートウェイを選択する前に、組織はこれらのインタラクションのうち、どのものを制御・監視する必要があるかを明確に定めるべきです。

エージェントにおいて最大のリスクは、モデルが何を言うかではなく、エージェントが何を実行できるかにあります。

したがってガバナンスはコンテンツフィルタリングを超え、行動の制御へと拡張されなければなりません。具体的には、どのツールを呼び出せるか、どのような権限が付与されるか、そしていつ人間による承認が必要となるかを定義する必要があります。

ガバナンスの実装方法

ゲートウェイ構築の真のコストを評価する

基本的な転送レイヤーを構築するのは比較的容易です。しかし、その周囲に制御機能を構築し、調整し、維持し続ける作業は時間がかかるものです。

ガードレールは慎重にチューニングする必要があります。重要な情報に対して誤検知（偽陽性）が発生しないようにするためです。ゲートウェイを重要インフラとして運用するには、プロバイダーとの継続的な連携、キャッシュ・バッチ処理・推論トークンの正確な課金管理、モデルの廃止対応、そして信頼性の高い監査証跡の確保が求められます。

組織が問われるべきは、本番環境での制御プレーン（コントロールプレーン）を運用する長期的なコストとリスクを引き受けるかどうかです。

エージェントスタックにガバナンスを組み込む

スタンドアロンのゲートウェイはポリシーを強制できますが、なぜその呼び出しが発生したのか、エージェントの次の行動は何だったのか、あるいは途中で明示的なポリシーに合格・不合格となったのかといった背景を説明することはできません。

しかし、トレーシング（追跡）、評価、モニタリングと連携させたゲートウェイであれば可能です。

支出ポリシーによってリクエストがブロックされた場合、その違反は検査可能なトレーシング内に記録されます。チームはツールを切り替えることなく、なぜポリシーが発動したのかを理解し、アプリケーション側かポリシー側のどちらを変更すべきかを判断できます。

エージェントスタックとの統合により、ゲートウェイはエージェントのパフォーマンス継続的な改善も可能になります。評価を通じて、より小型のモデルや短いプロンプト、あるいは異なるポリシーを採用しても品質が維持できるかどうかを判断できます。エージェント開発ライフサイクル の他の要素と連携したゲートウェイであれば、すべての呼び出しを即座に活用可能な情報に変換できます。

導入をシンプルかつ一元管理で

標準的なモデルトラフィックにおいては、導入は base_url の差し替えから始めれば十分です。既存のクライアント設定をプロバイダ直結からゲートウェイ指向に変更するだけで、追加のコード変更なしに動作します。

この切り替えは中央集権的に管理できるため、個々の従業員が手動で対応する必要がありません。一元設定により導入を加速でき、各チームが個別にガバナンスを実装する必要もなくなります。

本番負荷下でのゲートウェイの信頼性維持

回復力と障害時の挙動

ゲートウェイは重要なパス上に位置するため、単一障害点になってはいけません。信頼性を確保するにはプロバイダのフォールバック機能だけでなく、タイムアウト設定、ロードバランシング、そしてワークロードのリスクに応じた明示的なフェイルオープン/フェイルクローズ動作が不可欠です。ゲートウェイによるガバナンスの有効性は、トラフィックを確実に通過させる能力にかかっています。

Fallbacks

プロバイダの障害、モデルの廃止、そして最悪のタイミングでのレート制限。これらに対応するため、ゲートウェイには「次にどうするか」を定義した回答が必要です。リクエストが完全に失敗する場合もあれば、自動的にセカンドモデルへフォールオーバーする場合もあります。バックアップモデルとして有効とみなされるのは、ポリシー上同等である場合に限られます。つまり、データ処理、居住国（レジデンシー）、安全性に関する要件を同じく満たしていることが条件です。この違いこそが、問題なく継続的なサービスを提供できる企業を見分ける基準となります。

Rate limits and alerts

プロバイダのレート制限は、下流での障害やユーザー体験の低下を引き起こす可能性があります。ゲートウェイ内でレート制限を適用することで、組織は必要に応じて代替モデルへルーティングし、制限に達するのを回避できます。また、これらの制限はエージェントの健全性を示す有用な指標でもあります。もしエージェントが定期的にレート制限に抵触し始めたら、それは何らかの問題を抱えている兆候かもしれません。

ゲートウェイは、利用状況やポリシーの閾値に近づいた場合、あるいは到達した場合にチームへ通知すべきです。これにより、チームは支出を先回りして管理し、予算内に収めることが可能になります。

Price accuracy

プロバイダは頻繁に料率を変更します。キャッシュ読み取り、推論トークン、バッチ価格など、新たな料金 tiers を追加することもあります。単にその時点での料金を正確に保つだけでなく、ワークロードの実効価格がいつ変更されたかをチームが把握できる必要があります。これを早期に検知できれば、システム全体をコスト効率よく稼働させることができます。

モデルへのアクセス

Anthropic、OpenAI、Google、AWS Bedrock などの主要プロバイダーやホスト、さらに OpenAI 互換エンドポイント経由のオープンウェイトモデルなど、一般的なモデルエンドポイントをビルトインでサポートしています。これにより、組織はエージェントワークロードに対して柔軟な対応が可能になります。例えば、アプリケーションを再構成することなく、コストのかかるワークロードをより安価なオープンウェイトモデルへルーティングすることも可能です。

AI コストとモデル選択のガバナンス

企業では、年間の AI 予算が数ヶ月で使い切られてしまうリスクがあります。これは開発者個人レベルでも同様です。無人で動作するコーディングエージェント、リトライループに陥ったエージェント、あるいはスコープが不適切なバッチジョブを実行しているエンジニアが一人いれば、誰も気づかないうちに単一のセッションで数千ドルの請求が発生する可能性があります。

支出管理

支出ポリシーは組織の構造を反映したものであるべきです。制限は、組織全体、事業部門、チーム、API キー、あるいは個別ユーザーレベルで適用できます。

また、API キーは、目に見えにくい利用状況の側面を追跡する実用的な手段としても機能します。キーが特定のサービスやエージェントに紐づくことが多いため、クライアントやワークロードごとに 1 つずつキーを割り当てることで、別途追跡システムを構築することなく、利用状況を監視し上限を設定することが可能になります。

ポリシーは日次、週次、月次の制限として階層的に設定でき、デフォルトのポリシーを設定することで、各チームやワークロードを個別に構成する手間を大幅に削減できます。

モデルルーティング

モデルルーティングは、ポートフォリオ管理の一形態です。多くの人がこれを「簡単なプロンプトを低コストなモデルに送る手段」と捉えがちですが、実際には各タスクに適した承認済みモデルを割り当て、品質・レイテンシ・コスト・リスクの要件を満たすための仕組みでもあります。

小規模または特化型のモデルはルーティングや分類といった限定的なタスクを処理し、より高性能なモデルは深い推論が必要な作業に回すことで、リソースを最適配分できます。

コンテキスト効率性

トークン使用量は、エージェントが各ターンで送信するコンテキストの量によって大きく左右されます。コンテキスト効率性を高めることは、不要な情報を最小化し、コストとレイテンシを削減すると同時に、機密データの露出リスクを抑えることを意味します。

この文脈では統合システムが極めて重要です。トレーシング（追跡）機能はチームがコンテキストの膨張を特定する助けとなり、評価（evals）によって安全に削除できるコンテキスト量を把握でき、変更後の品質低下を検知するにはモニタリングが役立ちます。

支出ポリシーは単なる財務管理ツールではありません。ポリシー違反が急増することは、エージェントに何らかの問題が生じている最初の兆候であることが多く、エンジニアがその原因を調査するきっかけとなります。適切なアラート設定があれば、この手法は特に効果的です。

ランタイムにおける機密データの保護

本節はコンプライアンスフレームワークの対象となる組織や、機密データを扱うケースに適用されます。こうした状況では、データ保護は任意のインフラストラクチャではなく、規制当局による監査やデータ侵害時の開示時に企業を守るための必須基盤です。

企業がAIシステムを統制する上で、以下の規制が重要な役割を果たしています。

これらの規制がすべての企業に一律適用されるわけではありません。コンプライアンス要件が増えるごとに、コストやレイテンシ、運用の複雑さが増すため、制御は慎重かつ意図的に導入する必要があります。

ガイドレール（ガードレール）の仕組み

ガイドレールとは、LLM プロバイダに送信されるリクエスト内に特定のパターンが含まれているかを判定する論理層です。 評価対象に応じて、検出手法は「パターンベース」または「モデルベース」のいずれかになります。

パターンベース検出は、社会保障番号、クレジットカード番号、メールアドレス、API キーなど、規則的で予測可能なフォーマットに対して効果を発揮します。これらの形式は、大幅なコスト増やレイテンシを招くことなく、正規表現（regex）やルールベースで確実に検出できるケースがほとんどです。

一方、モデルベース検出は、固定されたパターンに従わない情報を扱うのに適しています。名前、場所、政治的・宗教的な所属などは、文脈を理解しないと「Ivy Apple」が人名なのか果物の名前なのかを判断できません。これは個人情報（PII）に限らず、プロンプトインジェクションやジャイルブレイク試行、根拠のない出力など他のガードレールにも適用されます。これらは毎回異なる形で現れるため、文脈の理解が不可欠です。

ガイドレールはリスクを低減しますが、ゼロにはできません。パターンベースの制御では未知のフォーマットを見逃す可能性がありますし、モデルベース検出は確率的な性質を持つため、誤検知（偽陽性）や見落とし（偽陰性）が発生する余地があります。

そのため、ガードレールは明確なデータとツールの境界によって強化されるべきです。重大なアクションは、コンテンツ検出のみに依存するのではなく、決定論的な制限や人間の承認に基づいて行われる必要があります。

結論

エージェントはもはや単なる実験段階のツールではなく、本番環境のインフラとして定着しつつあります。これらは巨額の予算を消費し、機密データや重要なツールの運用に関わり、ダウンタイムや誤った動作が直接的なビジネス損失につながるワークフローを支えることが増えています。

そのため、ガバナンスはもや各チームが個別に適用する承認手続きやポリシーの寄せ集めではいられません。

LLM ゲートウェイは、モデルへのアクセス、コンテキスト、コスト、障害、ポリシーの実行をエージェント全体で統制するためのランタイム制御プレーン（実行時制御層）として機能します。

その戦略的価値は単なる集中化を超えています。プロバイダー、価格、機能が変化する中でも、アプリケーションとモデルの不安定性を分離しつつ、企業のコントロール力を維持できる点にあります。

ガバナンスは、現在の特定のモデルに企業を縛り付けるためのものではなく、変化をより安全に行えるようにするためのものです。

ゲートウェイでの判断がトレーシング（追跡）、評価、モニタリングと連携していれば、企業は自社のルーティング、コンテキスト、ポリシーの選択が、期待される品質、経済性、リスク管理体制を実現できているかを継続的に検証できます。

これが LangSmith LLM ゲートウェイの前提です。チームがエージェントの追跡、評価、監視を行う同じプラットフォームで、ガバナンスも実行されます。これにより、あらゆるモデル呼び出しが「管理され」「可視化され」「継続的に改善可能な意思決定」へと変わります。

*AI ガバナンスの専門家と話し合い、LangSmith LLM ゲートウェイについて詳しく知りたい方は、チームにご連絡ください。

関連コンテンツ

概念ガイド

LangSmith

エージェントには専用のコンピューターが必要。安全に与える方法。

Amy Ru

2026 年 7 月 15 日

12 分

LangChain

LangSmith

観測性と評価

コーディングエージェントの請求額が倍増。その対策は？

Amy Ru

2026 年 7 月 2 日

6 分

LangSmith

コーディングエージェントの支出を予測可能にする方法

Martha Janicki

2026 年 6 月 15 日

5 分

エージェントの実際の動作を確認する

エージェントエンジニアリングプラットフォーム「LangSmith」は、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできる機能を備えています。