動画記事 · LangChain
LangSmith のマルチテナント対応デプロイを実現する
動画の文字起こしと公開情報をもとにAIで要約・構成しています。 正確な発言は元動画と時間位置で確認してください。
まず要点
LangSmithデプロイメントにカスタム認証ハンドラーを実装し、Supabaseなどのプロバイダーと連携させることで、ユーザーごとのスレッド分離と権限管理を実現するマルチテナント構成の構築方法を解説する。
LangSmith で実現するマルチテナント認証:数行のコードで企業級セキュリティを構築する方法
LangChain が提供する LangSmith のデプロイメント機能に、本番環境で必須となる「ユーザーごとのリソース分離」と「権限管理」を実装する方法が解説されました。これまで API キー一つで全ユーザーがアクセス可能だったデフォルト設定から、Supabase などの認証プロバイダーと連携させることで、数行のコード追加だけで安全なマルチテナント環境を構築できる仕組みです。
なぜ本番環境では「マルチテナント化」が必要なのか?
LangSmith のデプロイメントには、エージェントの作成やスレッド管理など 30 以上の API エンドポイントが用意されています。しかし、デフォルトの状態ではこれらの機能は「ワークスペースに紐付いた LangSmith API キー」によってのみロックされます。
これは開発環境や個人利用では問題ありませんが、本番環境で複数のユーザーが同じエージェントを利用するケースには致命的な欠陥があります。
デフォルト設定のままでは、ユーザー A が作成したスレッドや会話履歴を、権限のないユーザー B も閲覧・操作できてしまいます。これはセキュリティ上好ましくなく、多くのユースケースで「他者のリソースへのアクセス制限」が求められます。
例えば、ある企業が LangSmith エージェントを社内で展開する場合、営業担当者が顧客の会話履歴を見られる一方で、開発担当者はそのデータにアクセスできないといった分離が必要になります。LangChain は、この複雑な認可基盤を自前で構築する必要をなくし、既存の認証システムと組み合わせるだけで実現可能であることを示しています。
3 層構造で動く認証アーキテクチャ
マルチテナント化を実現する仕組みは、以下の 3 つの要素が連携することで成り立っています。
- クライアントアプリ: ユーザーがログインし、アクセストークンを取得します。
- 認証プロバイダー(例:Supabase): トークンの検証とユーザー情報の管理を行います。
- LangSmith エージェントサーバー: リクエストに含まれるトークンを検証し、権限に基づいてリソースへのアクセスを制御します。
ユーザーがログインすると、認証プロバイダーからクライアントへトークンが発行されます。その後、クライアントが LangSmith デプロイメントに対して API を呼び出す際、このトークンを HTTP ヘッダーに付与して送信します。サーバー側ではそのトークンを検証し、ユーザーの ID やロール(権限)を特定。これに基づいて「どのリソースにアクセスできるか」を判断します。
コードで実装するカスタム認証ハンドラー
この仕組みの実装は、驚くほどシンプルです。LangGraph の設定ファイル langgraph.json と、独自の認証ロジックを記述した auth.py を用意するだけで済みます。
1. 設定ファイルの指定
まず langgraph.json で、デプロイメントが参照すべき認証ハンドラーを指定します。ここでは auth.py ファイルを指し示すことで、LangSmith がカスタムロジックを読み込むようになります。
{
"agent": {
"path": "deep_agents:deep_agent",
"auth": "auth"
}
}2. カスタム認証ロジックの実装(auth.py)
auth.py ファイルでは、LangGraph SDK が提供する Auth クラスを利用して、以下の 3 つのデコレーターを定義します。
get_current_user: ユーザーの認証を行うハンドラーです。リクエストからトークンを取得し、Supabase に問い合わせることで現在のユーザー ID やロール(例:admin, user)を返します。この情報は、その後の権限判断やメタデータ付与に利用されます。auth_on: すべてのリソース操作(スレッド一覧の取得など)で自動的に実行されるデコレーターです。ここで重要なのは、ユーザー ID をリソースのメタデータ(所有者情報)として書き込む処理です。これにより、ユーザーがスレッド一覧を要求した際、システム側が「自分が所有するスレッドのみ」をフィルタリングして返すようになります。フロントエンド側に追加ロジックは不要です。auth_on_crons_create: 特定の操作(例:cron ジョブの作成)に対して権限ベースのアクセス制御を適用します。例えば「admin ロールを持つユーザーのみが cron を作成可能」といったルールを実装できます。
重要な点は、カスタムミドルウェアを追加したり、すべてのリクエストで手動でデータベースクエリを実行する必要がないことです。デコレーターを数個定義し、ユーザー ID をメタデータに付与するだけで、細粒度の権限管理とマルチテナンシーが自動的に機能します。
フロントエンドとの連携と動作確認
実装後は、フロントエンド側でアクセストークンを適切にデプロイメントへ伝播させる必要があります。Supabase を使用している場合、ログイン時に取得したアクセストークンを HTTP リクエストのデフォルトヘッダーとして設定するだけです。
// app.tsx の例:アクセストークンをヘッダーに付与
const client = createClient(
process.env.SUPABASE_URL,
process.env.SUPABASE_ANON_KEY,
{ auth: { persistSession: true } }
);
// トークン取得後、LangSmith API リクエストに含める
headers.set('Authorization', `Bearer ${token}`);この状態でローカル環境でテストすると、以下の挙動が確認できます。
- ユーザー A がログインし、エージェントと対話してスレッドを作成する。
- ユーザー B(別のアカウント)でログインしても、ユーザー A の作成したスレッドは表示されない。
- ユーザー B は自分専用の新しいスレッドを作成できるが、他者のデータにはアクセスできない。
この状態を langgraph deploy コマンドでクラウド上にデプロイすると、同様の分離機能が本番環境でも保証されます。Supabase プロジェクトの構成を変更せずとも、同じ認証フローで動作するため、開発コストも大幅に削減できます。
まとめ:企業向け AI アプリケーションの標準プラクティスへ
LangChain のこの機能は、エンタープライズ向け AI アプリケーションが直面していた「セキュリティ要件を満たすためのハードル」を劇的に下げました。複雑な認可基盤をゼロから構築する必要はなく、Supabase や Auth0 などの既存認証プロバイダーと組み合わせるだけで、安全でスケーラブルなマルチテナント環境を数行のコードで実現可能です。
これは、AI エージェントが企業内に広く展開される未来において、標準的なセキュリティプラクティスを確立する重要な一歩と言えるでしょう。
Original Source
元動画で発言を確認
プレイヤーは必要になるまで読み込みません。YouTubeのCookieと通信も再生を選ぶまで開始しません。
時間位置から根拠を確認
章や引用を選ぶと、元動画をその位置から再生します。