# ドメインエキスパートにエージェントを作らせる：Lyftのエージェント構築プラットフォーム - 番組: [The Data Exchange with Ben Lorica](https://ai-curator.jp/podcasts/shows/cmv3z5c0q000m5o10xxr4slsk)（Ben Lorica） - 元のタイトル: Let Domain Experts Build the Agents - 配信日: 2026年10月22日 - 長さ: 54分 - 要約作成日: 2026年10月22日 - トピック: [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#LLM評価（Eval）](https://ai-curator.jp/topics/LLM%E8%A9%95%E4%BE%A1%EF%BC%88Eval%EF%BC%89) [#プロンプト設計](https://ai-curator.jp/topics/%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88%E8%A8%AD%E8%A8%88) [#ガードレール](https://ai-curator.jp/topics/%E3%82%AC%E3%83%BC%E3%83%89%E3%83%AC%E3%83%BC%E3%83%AB) [#マルチエージェント](https://ai-curator.jp/topics/%E3%83%9E%E3%83%AB%E3%83%81%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#RAG](https://ai-curator.jp/topics/RAG) - URL: https://ai-curator.jp/podcasts/cmvjg3hhu00025r0zgedf87y7 ## 要約 Lyftの機械学習エンジニアAkshay Sharma氏とスタッフ・アプライドサイエンティストNick Ung氏が、非技術者のドメインエキスパートが顧客向けAIエージェントを作れる社内プラットフォームについて語った。プロンプトの作成は専門家が担い、エンジニアはツール、ガードレール、評価基盤を提供する。プロンプトリンター、エンジニアのレビュー、オフライン評価、トレース分析など多層の関門を設けている。最後に他チームへの実践的な助言も共有された。 ## ポイント - ドメインエキスパート（プロダクト担当者など）がプロンプトを書いてエージェントを作る。エンジニアやMLエンジニアが翻訳役を務めていた従来の開発時間を短縮し、エンジニアがボトルネックになる状況を避けることが狙い。 - プロンプトリンターが、ツール名参照などの構文・構造を決定論的ルールで、フェーズの終了条件などの振る舞いの矛盾をLLMで検査する。本番反映前にはエンジニアのレビューも入る。 - 悪意ある入力の検知やハルシネーション検知などのガードレールはプラットフォームに組み込み済みで、専門家は意識しなくてよい。 - 評価は、専門家によるステージング環境での手動テストの後、データサイエンティストによるオフライン評価（タスク仕様、モック出力、合成ユーザーによる再生）、必要に応じてオンラインA/Bテストという複数のゲートを通る。 - 本番トレースはデータの源泉であり、エラー分析から評価指標を作る。評価は共有インフラであり、競争優位になると強調された。 - LangGraphを使いつつハーネスは自社構築し、ロックインを避ける方針。コスト削減のためオープンウェイトモデルの活用や微調整も検討中。 ## 章立て - [00:00] **プラットフォームの狙いと成果** — 非技術者がエージェントを作れるようにする目的と、開発期間短縮という最大の成果を説明している。 - [04:09] **専門家向けの仕組みとガードレール** — MCPツールを専門用語抜きで参照させる工夫、エスカレーション設計、プロンプトリンターとエンジニアのレビューを紹介している。 - [07:17] **エージェントの複雑さと評価ゲート** — 顧客向けの比較的単純なエージェントを専門家が作る理由と、手動テストからデータ駆動評価までの段階を語っている。 - [16:16] **時系列ロジック、ルーティング、モデル選定** — ツールの前提条件の扱い、ルーターの役割、オープンウェイトモデルや小型分類モデル活用の可能性を議論している。 - [26:09] **サブエージェント、安全性、メモリ** — 専門家製はシンプルなReActループであること、悪意検知の内蔵、DynamoDBやベクトルDBの利用を説明している。 - [31:32] **評価の深掘り** — タスク仕様に基づくオフライン再生環境、合成ユーザー、トレース分析、共有評価基盤への進化を述べている。 - [42:42] **他チームへの助言** — プロンプト品質、評価の重視、他社に盲従しないこと、ロックイン回避、ミスを前提とした設計、マルチエージェントの慎重な導入などが語られた。 ## 解説記事 配車サービスのLyftで、顧客向けAIエージェントを「ドメインエキスパート自身に作らせる」プラットフォームが開発されている。The Data Exchange with Ben Loricaの本エピソードでは、MLエンジニアのAkshay Sharma氏とスタッフ・アプライドサイエンティストのNick Ung氏が、その設計思想と運用上の工夫を語った。 #### 狙いは「エンジニアがボトルネックにならないこと」 対象となる顧客はドライバー、ライダー、ドライバー志望者である。Sharma氏によれば、約1年前からカスタマーサポート向けにエージェントを作り始めたが、専門エージェントごとにオーケストレーション、ツール、プロンプトを結び付ける作業が重く、MLエンジニアやソフトウェアエンジニアが専門家の知識をAI向けに「翻訳」する必要があった。 新プラットフォームでは、日常的にチケットを見て顧客の困りごとと望ましい解決を熟知している人々が、主にプロンプトのテキストを書いてエージェントを作る。ビジュアルなワークフローツールはなく、プロンプトが中心だという。Ung氏は、エンジニアが一日中チケットを眺めたくはないとして、自分たちがボトルネックから外れる意義を述べている。最大の成果は開発時間の短縮だと説明された。 #### 自由と guardrail の両立 専門家にMCPなどの用語は説明せず、「エージェントが参照できるツール名をプロンプトに書けば調べてくれる」という共通言語だけを与える。安全関連や不正、アカウント停止といったAIが扱うべきでない案件では、人間へエスカレーションする指示の書き方も部品として用意する。 品質面では「プロンプトリンター」が要となる。ツール名の誤参照や構造を決定論的ルールで検査し、各フェーズに終了条件があるかといった振る舞いの一貫性はLLMが確認する。そのうえで、ステージングや本番へ進む前にエンジニアやデータサイエンティストがレビューする。悪意ある入力の検知やハルシネーション検知は、ユーザー入力ごとに動くML側の機能としてプラットフォームに組み込まれており、専門家は意識する必要がない。 また、ツール間の前提条件（ライド情報の取得にはライドIDが必要など）は、ツールのdocstringと決定論的チェックで扱う。IDがなければLLMノードがユーザーにライド選択を促す仕組みだ。 #### 複数の関門を通す評価 専門家が作るのは、当面は複雑さの低いエージェントで、「ゴールデンパス」と少数のエッジケースが明確なものだ。評価は段階的で、専門家が社内アプリのシミュレーターでステージング上の流れを手動テストし、次にデータサイエンティストが過去の会話などを使ったデータ駆動の評価（決定論的チェッカーとLLMジャッジ）を行う。変更の大きさに応じてオンラインA/Bテストも実施する。 Ung氏が強調したのは、顧客向け用途ではオフライン評価が単純な分類問題のようにいかない点だ。そこで各評価をタスク仕様として扱い、初期発話、利用可能なツール、ユーザーに関するデータ、ツール呼び出しのモック出力を定義して、会話全体を再生できる環境を作る。本番データと合成データを混ぜて評価セットを育て、シミュレーション用のユーザーLLMも、丁寧すぎると評価が易しくなるため実際のLyftユーザーらしく振る舞わせるという。 効率の悪い経路（余計な質問、誤ったツール呼び出し）は、期待される軌跡との照合やツール呼び出し単位のチェックで評価する。本番トレースのエラー分析から問題パターンを見つけて指標や評価プロンプトに落とすのが出発点で、トレースはファインチューニングや継続改善の源泉にもなる。評価基盤は共有インフラとして育ち、初期の「ステージングで試して本番に出し、皆でトレースを見守る」状態から自動化が進んだと語られた。 #### アーキテクチャとモデル戦略 ルーターは顧客の問題を専門エージェント、RAGによる知識ベース回答、人間のエージェントのいずれかに振り分ける。情報が足りなければ聞き返す必要があるため、分類器とチャットボットの両面を持つ。Ung氏らは、ここやLLMジャッジを小型で構造化出力の速い分類モデルで置き換えればコストや遅延を下げられる可能性を示した。 モデル面では、コスト増を背景にフロンティアLLMが過剰な箇所をオープンウェイトモデルに置き換える検討中であり、ポリシー学習が中心の狭い領域では小型モデルのファインチューニングも視野に入れる。基盤にはLangGraphを使いつつ、ハーネス、状態スキーマ、ステートマシンは自社で構築している。チェックポイントにはDynamoDB、長期記憶にはS3やSQL、RAGにはAWS上のベクトルDBを使い、チャンク戦略などを改善中だという。専門家製のエージェントはLLMとツールのシンプルなReActループで、サブエージェントを生成する複雑な構成はより高度な内部エージェントに限られる。 #### 他チームへの助言 助言は次のとおり。プロンプト品質は想像以上に重要になる。評価は競争優位であり、後回しにすると盲点になる。他社の流行に盲従せず、自社の問題と1〜2年後の基盤像を考える。技術スタックはモデル非依存に保ち、ロックインを避ける。Lorica氏は、エージェントはミスをする前提で復旧を設計すること、ツールを増やしすぎないこと、マルチエージェントは小さく始めることを挙げ、評価はモデル単体でなくハーネス全体に対して行うべきだと付け加えた。Ung氏はこれに対し、エージェントには厳密なif-thenに縛らずむしろ自律性を与えるべきだという立場を示した。 #### まとめ この事例の示唆は、非技術者にエージェント開発を開放する際、エンジニアの役割が「作る」から「安全に作れる環境を用意する」へ移る点にある。リンター、レビュー、段階的評価、組み込みのガードレールという多層構造は、権限委譲を行う日本企業の現場にも参考になる。評価をモデル単体ではなくハーネス全体の問題と捉え、本番トレースを資産として回す姿勢は、エージェント運用を考える際の具体的な指針となるだろう。 > この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: The Data Exchange with Ben Lorica「Let Domain Experts Build the Agents」