LangGraph と LangSmith を活用した Lyft のセルフサービス AI エージェントプラットフォーム構築事例

![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0f309a0e77b5e3544965e5_Lyft-customer-support-blog.png) ## 主なポイント - Lyft は、顧客の問題を最もよく理解している人々の近くでエージェント開発を行いました。オペレーションチーム、VoC（Voice of Customer）責任者、プロダクトマネージャーがプロンプトと設定を通じてエージェントを定義できるようにしたことで、MLE（機械学習エンジニア）がすべての反復処理を管理する必要を減らすことができました。 - ルーター型マルチエージェントアーキテクチャは、複雑な顧客ワークフローのサポートに役立ちました。Lyft は LangGraph を使用して、ライダーとドライバーのリクエストを専門的なサブエージェント間でルーティングし、安全性チェック、状態管理、ハンドオフをフロー内に組み込んでいます。 - 本番環境での品質は、評価、モニタリング、プロンプトの規律に依存します。Lyft は LangSmith をトレーシング、ダッシュボード、LLM-as-a-judge（LLM を裁判官として用いた評価）に使用していますが、チームが发现したのは、構造化されたプロンプト記述がエージェントの信頼性における最大の要因の一つになったことです。 *これは、SCX データサイエンスおよび MLE チームが非技術的なドメインエキスパートでも AI エージェントをリリースできるマルチエージェント顧客サポートシステムを構築した Lyft の友人たちからのゲスト投稿です。機械学習エンジニアの Akshay Sharma がリーダーを務めました。ご協力ありがとうございます。* ## TL;DR LangGraph を活用して洗練されたマルチエージェントシステムをオーケストレーションすることで、Lyft は顧客サポート業務を変革し、ライダーとドライバー向けの数百万回のインタラクションを管理しています。私たちの「セルフサービス」プラットフォームは、LangGraph のサブグラフアーキテクチャと LangSmith の堅牢なトレーシングおよびモニタリングツールを統合しており、非技術的なドメインエキスパートが AI エージェントを独自に開発・改善できる環境を提供します。この転換により、LLM-as-a-judge（LLM を判事として用いた）評価システムによる自動化された高基準の維持を保ちながら、*エージェントの開発期間を約 6 ヶ月から数週間へと劇的に短縮*しました。 ## Lyft の目標：エージェントの反復を迅速に、かつ安全に アカウントアクセス、損害請求、課金レビュー、収益に関する紛争など、多数のカテゴリーにおいて、Lyft の AI Assist はライダーとドライバー向けの顧客サポートを管理しています。私たちの取り組みは 2023 年に始まりましたが、当初のプロセスは労働集約的でした。各 AI エージェントの開発には、機械学習エンジニア（MLE）およびエンジニアリングチームから数ヶ月にわたる専念した作業が必要でした。私たちはライダーとドライバー向けのエージェントを順次リリースし効率化に成功しましたが、全体としてのペースは依然として大きなボトルネックとなっていました。 2026 年までに、既存の運用モデルは、新たなユーザーセグメント、追加の問題タイプ、自律型車両への対応などによって引き起こされた持続不可能な需要増に直面していました。開発サイクルは、ドメインエキスパートがワークフローの動作を定義し、それを MLE（機械学習エンジニア）がツール設定とプロンプトに変換するという、遅く反復的なループに依存していました。この往復のレビュープロセスでは、トレースを確認し、問題を指摘し、コードを調整するために、エージェントごとに数週間の協働が必要でした。その結果、顧客の問題について最も深い理解を持つ人々が、技術的な仲介者なしで解決策を実装することができませんでした。 これにより、私たちは決定的な問いに直面しました：運用チーム、VoC（Voice of Customer）責任者、プロダクトマネージャーが、自然言語を用いてエージェントを直接構築・改善できるでしょうか？私たちの目標は、学習とデプロイメントの加速のために、日常の反復プロセスから技術的な仲介者を排除することでした。重要なのは、このセルフサービスへの移行が、経験、精度、安全性に関する厳格な基準を損なってはならないということです。すべてのエージェントは、手動で設計されたシステムと同様の品質を満たす必要がありました。 ## アーキテクチャ：LangGraph に基づくマルチエージェントシステム ## The Router Multi-Agent Pattern Our system follows LangGraph's[router multi-agent architecture](https://docs.langchain.com/oss/python/langchain/multi-agent/router). A meta agent acts as a stateful router: it classifies the incoming request and uses Command(goto=...) to dispatch to the appropriate specialized subagent. Each subagent is a full LangGraph StateGraph, registered as a subgraph node in the meta agent. ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a163d057c5a37ac3248d4eb_image6.png) We run separate router instances for riders and drivers. When a rider contacts support, the meta agent routes to the rider_intent subagent, which classifies across rider-specific intents (e.g. lost items, charge disputes, trip issues). For drivers, it routes to the driver_intent subagent, which handles driver-specific intents (e.g. earnings, account access, damage claims). If the intent agent determines during a conversation that the user needs a more specialized agent, it uses Command(goto=..., graph=Command.PARENT) to hand control back to the meta agent, which re-routes to the appropriate specialist, for example, jumping from the driver intent agent to the damage claim agent mid-conversation. Each subagent, regardless of specialization, follows a consistent node pattern: ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a163d27b3647bdaa8dbaa82_image2.png) これにより、2 つの重要な特性が得られます。第一に、**安全性はあらゆる局面で並列的に実行されます**。悪意ある意図の検出と安全性の問題検出は、LLM の推論が行われる前に、LangGraph の Command(goto=[...]) ファンアウト機能を通じて同時に実行されます。第二に、**サブエージェントはモジュール化されており、個別にデプロイ可能です**。新しいエージェントを追加する場合は、新しいサブグラフを定義し、メタエージェントに登録するだけです。 ## 専門型エージェントと設定可能型エージェント 私たちはエージェントを2 つのカテゴリに分類しています: **専門型エージェント (Specialized agents)** は、複雑でリスクの高いワークフローのために MLE によって手動で構築されます。例えば、当社の損害請求処理エージェントは、画像処理、不正検出、多段階分類、および低コードアプローチでは対応が難しい自動化呼び出しの支援を行います。 **設定可能型エージェント (Configurable agents)** はセルフサービス層です。これらは、内部構成サービスに保存された JSON 構成ファイルからランタイム時に初期化され、プロンプトは LangSmith の Prompt Hub から取得されます。ドメインエキスパートが構造化テンプレート（役割、範囲、ワークフローフェーズ、コンテンツガイドライン）に従ってプロンプトを作成し、ConfigurableAgent クラスが残りの処理を担当します：グラフの構築、ツールのバインディング、安全性ゲート、および状態管理です。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a170da5876668f21a99e943_Screenshot%202026-05-27%20at%208.27.16%E2%AF%80AM.png) # 設定可能なエージェントは起動時に動的に読み込まれます for configurable_agent in load_configurable_agents(): self.configurable_subagents[configurable_agent.config.intent] = configurable_agent # それぞれがメタエージェントのサブグラフとして登録されます for configurable_subagent in self.configurable_subagents.values(): graph_builder.add_node( configurable_subagent.config.intent, configurable_subagent.get_state_graph() ) graph_builder.add_edge(configurable_subagent.config.intent, "finalize") これは、プロダクトマネージャーがドライバーの税金に関する質問用などの新しいエージェントを定義する際、プロンプトと JSON 設定（config）を書くだけで済むことを意味します。機械学習エンジニア（MLE）によるコード変更は不要です。プラットフォーム側でグラフ構築、ツール実行、チェックポイント保存、トレーシング、および安全性の確保が自動的に処理されます。 ## DynamoDB を用いた状態永続化 多ターン会話には耐久性のある状態管理が必要です。私たちは LangGraph の BaseCheckpointSaver インターフェースを実装したカスタム DynamoDBSaver（DynamoDB セーバー）を構築し、メモリー内の仮定に依存することなく、ターンを超えた永続的な会話状態を実現しました。各チェックポイントには、グラフの状態全体、実行メタデータ、および親チェックポイントへの参照が保存されており、本番環境での会話の再生、デバッグ、および状態の検査が可能になります。 ## LangSmith: トレースから本番モニタリングへ ## すべてのエージェントのターンを追跡する すべての環境（開発、ステージング、本番）におけるすべてのエージェント呼び出しは、LANGSMITH_TRACING=true を設定することで LangSmith へ追跡されます。各トレースには、実行されたノード、LLM が目にした内容、呼び出されたツール、トークン使用量、および各ステップのレイテンシなど、グラフの実行全体が記録されます。 フィルタリング用のランタイムメタデータを作成するユーティリティを使用して、トレースにカスタムメタデータ（ユーザータイプ、エージェント名、意図、会話 ID）を追加します： # メタデータは LangSmith へ流れ込み、フィルタリングとデバッグに利用されます tags = build_langsmith_metadata( agent_name=self.name, user_type=context.user_type, interaction_id=context.interaction_id ) これは非常に役立っています。ドライバーが混乱する応答を報告した場合、正確なトレースを引き出して各ノードの入力/出力を確認し、問題が意図分類、ツール実行、あるいは最終的な LLM 応答のいずれにあるかを特定し、数時間以内に修正できます。 ## LLM-as-a-Judge 評価パイプライン エージェントをトラフィックの 100% に展開する前に、必ず評価パイプラインを通過する必要があります。そのプロセスは以下の通りです： - 小規模な本番展開（5–10%）— エージェントが低ボリュームで実際のトラフィックを担当します。 - 本番トレースのサンプリング — 実際の会話を評価データセットとしてキャプチャします。 - LLM-as-a-Judge 評価器の実行 — LangSmith の Prompt Hub から共有されるジャッジプロンプトテンプレートを使用し、エージェント固有のメトリクスを拡張して適用します。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a1640a58a423e2209c3cc1a_lyft-image.png) 私たちのベースライン評価指標（すべてのエージェントに適用）: ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a170db5566fbd119b4c9fc6_Screenshot%202026-05-27%20at%208.27.37%E2%80%AFAM.png) その後、各専門エージェントに対してドメイン固有の指標を追加します。例えば、コア収益エージェントは、そのエージェントが関連するポリシーに従ったか逸脱したか、あるいは非論理的または一貫性のない推論を用いたかどうかを確認します。 評価者は、LangSmith のマルチターン評価器（multi-turn evaluator）を使用して本番環境のトレース上で自動的に実行されます。スレッドフィルター（例：ラン名が ride_earnings）とサンプリングレートで構成されており、初期展開時は高い値から始まり、信頼性が高まるにつれて徐々に低下します。 ## 本番監視ダッシュボード 本番環境にあるすべてのエージェントには、以下の項目を追跡するクローンされた LangSmith の監視ダッシュボードが用意されています: - ランボリュームとエラーレート — 予期しないスパイクや障害が発生していないか？ - p50/p95 レイテンシ — エージェントはリアルタイムサポートに必要な速度で応答しているか？ - トークン使用量 — コストは予算内に収まっているか？ - ツール呼び出し成功率 — 外部 API 統合は健全に動作しているか？ - LLM-as-a-Judge（LLM を裁判官として用いた評価）スコアの推移 — 品質は向上傾向にあるか、低下傾向にあるか？ また、LangSmith の指標に基づいて PagerDuty アラートを設定しています。エラーレートが 5% を超えるか、15 分ウィンドウ内で p95 レイテンシが 10 秒を超えた場合、オンコールのエンジニアに自動的にアラートが送信されます。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a163ea158c990e73354e873_image5.png) ツール別のエラー率の例チャート（本番環境の監視ダッシュボードの一部） ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a163ecd4c48bf55fd4e756e_image1.png) 本番環境で実行される、カスタム（エージェント固有）メトリクスを用いた LLM Judge 評価。ヒント：不正確でアクションに結びつきにくいスコアではなく、バイナリ出力（True/False または Pass/Fail）を使用してください。 ## 厳しい教訓：ボトルネックはインフラストラクチャではなくプロンプトの質 非技術系のチームメンバーに対してエージェント構築を開放した当初、最も困難な部分はプラットフォーム自体がツールバインディングを正しく実装することや、グラフ内のエッジケースを処理し、状態管理を行うことだと考えていました。しかし、それは誤りでした。 最も困難だったのは**プロンプトの質**です。ドメインエキスパートは自らの扱う問題タイプについて深く理解していましたが、その知識を LLM が確実に従う指示へと翻訳する方法を常に知っているわけではありませんでした。私たちは、ハッピーパス（通常の成功ケース）では見事に機能する一方で、エッジケースでは崩壊してしまうエージェントを目撃しました。あるプロンプトでは、運転手が運賃に異議を唱えた場合にエージェントが取るべき行動は定義されていても、会話の途中で運転手が話題を変えた場合の対応については何も記述されていないことがありました。あるいは、トーンセクションで「共感的であれ」と指示していても、それが具体的に何を意味するのかを規定していないため、LLM が毎回異なる解釈をしてしまうこともありました。 翻訳全文 失敗のモードは驚くほど一貫していました：スコープ外の定義の欠如（そのためエージェントはツールを持たない質問に答えようとし）、曖昧な分岐ロジック（明確なエントリまたは終了条件のないフェーズ）、そして紙面上では良く聞こえるが、大規模言語モデル（LLM）に過度な即興の余地を与えていた漠然としたコンテンツガイドラインです。 私たちはこの課題に二つの側面から取り組みました。 **第一に、構造化されたプロンプト記述フレームワークです。** 五つの必須コンポーネントを持つテンプレートを作成しました：アイデンティティ（このエージェントは誰か、どのようなユーザータイプか、どのトピック領域を扱うか）、主要な目的（曖昧な「支援」や「処理」ではなく具体的な動詞）、スコープ（対象範囲と非対象範囲の両方、および明確なルーティングアクション）、フェーズ別ワークフロー（エントリ条件付きの番号付きステップ、すべての if/else に対する分岐、各フェーズごとの終端アクション）、そしてコンテンツガイドライン（抽象的な原則ではなく、具体的な「行うべきこと」「行わないべきこと」ルールと例文）。これに、アクティベーション前に必ず通過させる必要があるレビューチェックリストを組み合わせました。例えば、「すべてのフェーズに終了条件はあるか？」「ツールが利用できない場合の指示はあるか？」といった項目です。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a163ef517c8da9aa491a2ee_image7.png) 翻訳全文 **第二に、プロンプトの自動検証です。** 私たちは、Git を基盤としたプロンプトリンティングパイプラインを構築しており、これはあらゆるプロンプトが本番環境に到達する前に実行されます。ドメインエキスパートがビルダー UI でプロンプトの記述を終えると、設定リポジトリに対してプルリクエストが開かれます。その後、CI パイプラインが 2 つの層のチェックを実行します。まず、構文エラーのあるテンプレート変数、重複した意図スラッグ、スペルミスなどを検出する高速な静的ルールです。次に、プロンプトインジェクション脆弱性、矛盾する指示、会話フローに出口がない構造的な行き止まりを検出する LLM 駆動のルールが続きます。すべての違反はマージをブロックします。著者には UI 内でインラインフィードバックが表示され、機械学習エンジニア (MLE) を巻き込むことなく自身で問題を修正できます。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a163f08c91006400bc43fa1_image3.png) これらすべての背後にある重要な洞察は、**プロンプトをコードのコメントではなく、製品仕様として扱う**ことです。プロンプトがより明示的であればあるほど、エージェントの一貫性は高まります。そして、品質上の問題を、実際の顧客が一度も出力を見る前に、できるだけ早く検出すればするほど、システム全体の改善スピードは速くなります。 ## 結果 セルフサービス型エージェントプラットフォームの立ち上げ以降: - エージェント開発期間：最初のドライバーエージェントでは約 6 か月かかっていましたが、新しい構成可能なエージェントでは約 2 週間に短縮されました。 - エージェントのカバレッジ：生産環境で複数の課題タイプをカバーする構成可能なエージェントが増加しており、いくつかの専門化されたエージェントも稼働しています。 - 評価カバレッジ：生産環境にあるすべてのエージェントに対して、ライブトレース上で実行される「LLM-as-a-Judge（LLM を裁判官として活用する）」パイプラインが自動化されています。 - 品質：LangSmith の評価指標に基づいて設定した幻覚防止ガードレールにより、幻覚や矛盾の発生率が 20% 減少しました。 - 運用効率：エンジニアリングチーム以外の多くのメンバーが、現在、エージェントを独自に構築・反復できるようになりました。 - AI 解決率：セルフサービスプラットフォームを使用していくつかのエージェントをリリースして以来、16% 向上しています。 ## 次のステップ このプラットフォームをさらに推進するために、私たちは以下の領域を検討しています： - プロンプトリンティングパイプラインの完成 — 上記で説明した Git ベースの CI 検証は現在開発中です。完全に展開され次第、すべての設定可能なエージェントプロンプトは、本番環境に到達する前に自動的な静的解析と LLM（大規模言語モデル）によるチェックを通過し、一般的なエラーについては MLE（機械学習エンジニア）の手動レビューが不要になります。 - モックおよびシミュレーションインフラ — エージェントビルダーが本番トラフィックにデプロイする前に、合成された会話やモックされたツールレスポンスに対してテストできるシミュレーションレイヤーを構築し、新しいエージェントのフィードバックループを劇的に短縮します。 - ペアワイズ評価 — LangSmith のペアワイズ注釈キュー（Pairwise Annotation Queues）を活用して、リリース前に人間によるレビューとプロンプト改訂の A/B テストを実施します。 - 対象地域およびユーザータイプの拡大 — プラットフォームをヨーロッパの Freenow カスタマーや、自動運転車サポートシナリオにも展開していきます。 - より深い評価の自動化 — サンプリングベースの評価から、すべての本番トレースに対する継続的なスコアリングへ移行し、プロンプトの劣化に関する自動アラートを設定します。 ## 関連コンテンツ ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0f012b2ff304b9a169e892_blue-57%20characters%20max.png) LangChain Open Source（オープンソース） LangGraph ## トークンストリームからエージェントストリームへ ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0f01c040ee659bfdddd9ab_T04F8K3FZB5-U097E05JJAF-a7911e89a90d-512.jpeg) ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0f023b0b549b4726b62469_T04F8K3FZB5-U0AQPTH37EV-d045574c58b6-512.png) C. Bromann, N. Hollon 2026 年 5 月 21 日 9 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0e9744f0232c559869a96b_auth-proxy-sandboxes.png) LangSmith ## LangSmith エージェントサンドボックスのネットワークアクセスを Auth Proxy がどのように保護するか ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a049238d738c101a93b1560_Mukhil.jpeg) Mukil Loganathan 2026 年 5 月 21 日 9 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0b0ffdf203491984cb01ce_everything-we-shipped.avif) 企業アナウンスメント LangSmith ## Interrupt でリリースしたすべての新機能 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69e0003a1af368dfae13c23c_jacob-talbot.png) Jacob Talbot 2026 年 5 月 14 日 11 分 ## エージェントが実際に何をしているかを確認する LangSmith は、エージェントエンジニアリングプラットフォームとして、開発者がすべてのエージェントの意思決定をデバッグし、評価の変更を行い、ワンクリックでデプロイできるように支援します。

LangGraph と LangSmith を活用した Lyft のセルフサービス AI エージェントプラットフォーム構築事例

背景や根拠まで確認しますか？

調べる

選ぶ

サイト