LangChain、LangSmith BYOCのベータ版をAzureとGoogle Cloudで提供開始

LangChainは2026年11月3日に発表し、LangSmith Bring Your Own Cloud（BYOC）がMicrosoft AzureとGoogle Cloudでベータ版として利用可能になったと明らかにした。これにより、マネージドデプロイの選択肢がAWS以外にも広がった。AWSではすでに一般提供されている。

BYOCでは、機密性の高いLangSmithのデータとエージェントのデプロイ先を顧客のクラウドアカウント内に保つ。プラットフォームを提供するLangChainは、オーケストレーション、スケーリング、プラットフォームの更新など、データプレーンを管理する。セルフホスト版LangSmithのデータ所在地とネットワーク分離を求めながら、プラットフォーム全体の運用は自社で担いたくない組織を対象としている。

先行して提供が始まったのはAWSだった。LangChainが2026年8月12日に発表したBYOCは、自社のAWSアカウントとVPC内でマネージドデプロイを利用したい企業、特に厳格なデータガバナンス要件を持つチームを対象としていた。

BYOCによるLangSmithの分割構成

BYOCでは、プラットフォームをLangChainが運用するコントロールプレーンと、顧客が所有するデータプレーンに分ける。コントロールプレーンには、認証、組織とワークスペースの設定、請求関連のメタデータ、ハッシュ化されたAPIキー、静的なインターフェースアセットが含まれる。データプレーンには、トレース、プロンプト、データセット、実験、エージェントのデプロイ、ワークスペースのシークレットが含まれる。

組織は、複数のアカウントやリージョンにそれぞれデータプレーンを設け、各データプレーン内にワークスペースを配置できる。この構成により、リージョン、環境、事業部門ごとに分離できる。たとえば、プラットフォームチームが本番環境とステージング環境を別々のAWSアカウントで運用する一方、Azureを標準化している事業部門が独自のデプロイを運用できる。

このモデルにより、セルフホスト版LangSmithに伴うアップグレード作業の負担も変わる。厳格なコンプライアンス境界を設けているチームでは、これまでプラットフォームエンジニアが、ステートフルサービスへのパッチ適用、データベースの設定、スキーマ移行、独自のHelmリリースの調整を行う必要があった。BYOCでは、データを顧客の仮想ネットワーク内に保ったまま、LangChainがスケーリング、スキーマの更新、ランタイム依存関係を管理する。

LangChainによると、AWSの顧客が主なメリットとして挙げたのは、継続的なアップグレード、セルフホスト版のリリースサイクルよりも早くLangSmithの新機能を利用できること、自動スケーリングだった。

クラウドアーキテクチャとセキュリティ上の責任

3つのクラウドすべてで、BYOCのデータプレーン内にManaged Deep Agentsのエンドポイントをサポートしているが、実装には各プロバイダー独自のネットワーク機能とセキュリティ基盤が使われている。

Azureでは、データプレーンは専用の仮想ネットワーク内で稼働し、AKS APIエンドポイントはプライベートに設定される。Helmを通じてIstioとKEDAをデプロイし、イングレスルーティングとイベント駆動型のスケーリングを行う。システムのテレメトリーはAzure Monitorに送られる。LangChainは、AzureでのLangSmith Sandboxesのサポートを近日提供予定としている。Google Cloudのデータプレーンは、提供開始時点で任意のリージョンで稼働できるが、管理はLangSmithの米国コントロールプレーンから行われる。名前空間ごとに範囲を限定したリソース名を使うことで、既存のインフラとの名前の衝突を避けることを想定している。

AWSでは既存のVPCを利用でき、データベースの配置先には顧客が選んだサブネットを指定できる。セキュリティチームはアプリケーションのロールに独自のセキュリティグループを割り当てられるため、データプレーンを既存のイングレスおよびエグレスの検査ポリシーに適合させられる。

AWSでは、2つのPrivateLink接続を介してプレーン間の通信を行い、LangChainがパブリックインターネット経由で顧客環境にアクセスすることはない。機密データに関するリクエストは、ブラウザーまたはクライアントから顧客のデータプレーンに直接送られる。アカウント間のIAMロールにはインフラをプロビジョニングおよび管理する権限があるが、以下への権限は一切ない。 s3:GetObject トレースバケットへの権限も、 rds-db:connect PostgreSQLへの権限も、 elasticache:Connect Redisへの権限もない。

AWSでは、共有責任モデルに基づき、クラウドアカウントのガバナンス、内部接続、アクセス制御ポリシー、顧客側のセキュリティ監視、コンプライアンス管理は顧客が担う。マネージドコンポーネントの運用と更新はLangChainが行う。インシデントのトラブルシューティングでは、顧客が承認した緊急時アクセスが必要になる場合があり、アクセス後には、タイムスタンプ、実施した作業、アクセスしたデータを記載した概要が提供される。

移行とアクセス

セルフホスト版LangSmithから移行する組織向けに、オープンソースの移行ツールは、ユーザーとロール、データセット、実験、プロンプト、アノテーションキューの設定、自動化ルール、ダッシュボード、Fleetのリソースをコピーする。データは移動ではなくコピーされるため、移行元のインスタンスは変更されず、そのまま稼働を続ける。移行ドキュメントによると、手作業が必要な項目も残る。デプロイ済みのエージェントは再デプロイが必要で、Insightsのレポートはインスタンス間で移行されない。また、Fleetの移行では、シークレットの値を再入力し、ユーザーごとのOAuth接続を再接続する必要がある。

トレース、実行、フィードバックは、LangChainが社内ツールを使って運用する別のプロセスで移行される。AWSではトレースの移行がサポートされているが、オープンソースツールではトレースを移行できない。

BYOCの基盤となるTerraformモジュールと移行ツールは公開されている。LangChainによると、データプレーンのLLM Gatewayは、11のプロバイダーのモデルを標準でサポートするほか、OpenAIまたはAnthropic互換のエンドポイントも利用できる。AWS、Azure、Google CloudでBYOCのデータプレーンをプロビジョニングするには、LangChainの営業担当者への問い合わせが必要となる。

企業にとって実務上の効果は、クラウドガバナンスを移管することなく、データの境界をどこに設けるかの選択肢が広がることです。LangChainはより多くの環境でLangSmithを運用できる一方、アカウント制御、監視、コンプライアンス、および移行に関する複数の作業は、引き続き顧客チームが担います。