RAG を本番運用している当事者が「ETL と従来型 RAG は捨てられる」と語ったトヨタのセッションに参加しました #AWSreInvent
こんにちは、製造ビジネステクノロジー部の若槻です。
自動車産業や製造業では、日々更新される情報やドメイン固有の知識を、その分野の専門家ではない人が扱う場面が多くあります。車両の仕様やトリムごとの違い、開発ツールの API、規格や社内の手順書といったものです。正確な情報が社内のどこかには必ずあるのに、必要としている人がそこに辿り着けない、という構図はあちこちで見かけます。
ここに効いてくるのが、提供するデータを AI エージェントから呼び出しやすい形にしておくこと、つまり MCP サーバー化です。データを持っている側が MCP で口を用意しておけば、使う側は自然言語で聞くだけで済みます。
例えば、AWS の Japan Blog に dSPACE ControlDesk の操作を対象にした事例が出ています。
ControlDesk は SIL/HIL シミュレーションによる ECU 開発で使われるツールですが、その API リファレンスやサンプルスクリプト、現場で試行錯誤しながら蓄積した操作手順を MCP サーバーのナレッジとして持たせるという構成です。Kiro から自然言語で指示を出すと、そのナレッジを参照して Python コードが生成されます。記事では効果として「API 知識不要で操作可能」「新しいメンバーのオンボーディングコストを大幅に削減できます」と書かれていて、まさに冒頭の構図に対する回答になっています。
また dSPACE 自身も、自動車開発に対して以下のような取り組みを始めています。
2026 年 8 月 3 日の発表で、MCP 経由で AI アシスタントを dSPACE のツールに直接つなぎ、要件の解釈・仕様の精緻化・ソフトウェア開発の支援・シミュレーションの準備までを支援するというものです。「AI は、エンジニアリングのワークフローの外側で独立して機能するのではなく、ワークフローそのものを支援することで最大の価値を発揮します」という一文が、この流れを端的に表していると思います。
ちなみに補足ですが、dSPACE については最近ブログを書きました。AWS Summit Japan 2026 のブースで見た、QNX Cabin と dSPACE VEOS Player を AWS 上で組み合わせるデモのレポートです。
さて、こうした自動車のナレッジ基盤の MCP 化について、AWS re:Invent 2025 のセッション How Toyota Built an AI Platform that Revolutionizes the Dealer Experience (IND320) を現地で聞いていたのですが、ブログ化できていませんでした。今回はこのセッションをレポートします。
セッション概要
タイトル
How Toyota Built an AI Platform that Revolutionizes the Dealer Experience (IND320)
登壇者
- Bryan Landes, Sr. Global Solutions Architect, Amazon Web Services
- Stephen Ellis, Sr. Manager, AI Strategy and Delivery, Toyota Motor North America
- Stephen Short, Sr. Engineer, Toyota Connected North America
セッション冒頭。AWS の Bryan Landes 氏が導入を担当
日時
2025/12/3
セッション概要原文
In this session, Toyota Connected North America and Toyota Enterprise AI showcase how they transformed dealer operations using Amazon Bedrock and Claude to create an intelligent assistant that answers complex vehicle questions in seconds. The system now serves 2,300+ dealerships with instant, accurate vehicle expertise and handles 7,000+ monthly dealer interactions across multiple Toyota models and years, leveraging Amazon Bedrock, OpenSearch Serverless, and Amazon EKS for enterprise-scale performance.
登壇は 3 名で、AWS の Bryan Landes 氏が導入、Toyota Motor North America（以下 TMNA）の Stephen Ellis 氏が全社の生成 AI 推進体制、Toyota Connected North America（以下 Toyota Connected）の Stephen Short 氏が実装の詳細、という分担でした。Toyota Connected はトヨタ傘下の独立会社で、ソフトウェア開発と技術検証を担う組織とのことです。
Toyota Connected の紹介パート
動画
レポート
解こうとした課題 — 客のほうが詳しい
Ellis 氏が挙げた課題設定が具体的で分かりやすかったです。
ディーラーに来る客は、来店前に YouTube や掲示板で相当に調べ込んでいます。氏が例に出したのは新型スープラで、掲示板では歴代モデルとの差異が延々と議論されている。その状態の客が来店して「なぜ新型を買うべきなのか」と聞いてくる。
営業担当が返せるのは「売りたいから」くらいで、結局その場でスマホを取り出して検索し始めることになる。トリムごとのエンジンの違いのような、社内には正確な答えがあるはずの質問で、です。
そこで、製造・販売・マーケティングが持つ製品データを 1 つのパイプラインに集めて、自然言語で聞ける形にしてディーラーに配るというのがこのシステムの出発点です。
Short 氏によれば、アシスタントが答えるのは車両仕様・価格・トリム・アクセサリーといった情報で、対応範囲は北米トヨタの 2023〜2026 モデルイヤーの全車種。設計方針として次の 2 点が強調されていました。
- トヨタ公式のデータソースだけを参照する。LLM の世界知識に自社製品を語らせない
- 回答には必ず出典を付ける
バージョン 1 は自前の RAG
現行システム（バージョン 1）の構成がこちらです。
バージョン 1 の全体構成。左が TMNA 側、右が Toyota Connected 側（IND320 の 27:50 のスライドより）
処理の流れを追うと次のようになります。
- フロントエンドからのリクエストを Route 53 と WAF で受け、Lambda@Edge と Entra ID で認証・認可
- ECS 上の intent router が「どの車種の話か」を判定。ただしその推論の前に、セキュリティチームが内製した prompt guard に必ず通す。プロンプトインジェクションなどを検知・ブロックするための仕組み
- フロントエンドとは WebSocket をつなぎ、会話履歴は DynamoDB で管理
- リクエストは Cloudflare 経由で Toyota Connected 側へ。RAG 本体は EKS 上
- SageMaker で埋め込みを生成し、OpenSearch Serverless のベクトル DB に対してセマンティック検索
- Bedrock 上の Anthropic のモデルで推論
- 推論ログは SQS と Lambda を経由して MongoDB へ
細かい工夫として、埋め込みを作るのは直近のクエリだけではなく、直前 5 ターン分を加重平均しているという話がありました。新しい発話ほど重みを大きくして、文脈を保ちつつ話題の移り変わりに追随させる狙いです。検索で引くのは車種あたり 30 文書で、これを唯一の情報源として回答を生成します。
もう 1 点、Toyota Connected 側から見ると RAG アプリケーションは完全にステートレスで、会話管理はすべて TMNA 側の責任、という切り分けになっていました。
法務要件がアーキテクチャを決めている
このセッションで印象的だったのは、法務チームからの要求が実装をかなり具体的に規定していたことです。
要求はシンプルで、アシスタントの回答には文脈に応じた免責事項（disclaimer）を必ず含めること。ところが元データは巨大な JSON で、その中に免責事項がコードとして埋まっている。コードを拾って、対応する一字一句変更してはならない免責文にマッピングする必要があります。燃費や Toyota Safety Sense の機能をどう表現するか、といった言い回しの縛りもあったそうです。
「LLM に触らせてはいけないテキスト」をどう出力に混ぜるか。ここで採られたのが stream splitting という手法でした。
システムプロンプトで例示（in-context learning）を与えて、LLM の出力ストリームを 3 つに分割させます。
| ストリーム | 中身 | 扱い |
|---|---|---|
| メイン出力 | フロントエンドにそのまま表示される本文 | LLM が生成 |
| 免責事項コードのリスト | この回答で出すべき免責事項の識別子 | LLM はコードを選ぶだけ |
| 画像 ID のリスト | この回答で見せるべき車両画像の識別子 | LLM は ID を選ぶだけ |
アプリケーション側は出力ストリームを読みながら区切り文字を検出して状態を切り替え、コードと ID を回収します。そのうえで、免責文の本文と画像 URL・メタデータは、サービスが持つマッピングから引いてストリームに載せる。つまり免責文と画像 URL は一度も LLM を通らないわけです。
「LLM に生成させてよいもの」と「絶対に改変されてはいけないもの」を、出力の段階で物理的に分離する設計です。規制の厳しい領域で生成 AI を本番に出すときの型として、そのまま参考になると思いました。
JSON を自然言語に翻訳する ETL
ここが後の伏線になります。
元データは製品情報の巨大な JSON です。トリムコードや MSRP、説明文などが内部的なマッピングで入り組んでいて、そのままではセマンティック検索に載らない。そこで取られたのが、JSON のチャンクを Bedrock で自然言語の要約に翻訳し、その要約に対して検索をかけるというアプローチでした。あわせて元の生データも一緒に保持しておき、これを出典表示に使います。
その ETL パイプラインがこちらです。
Extract + Transform の構成。Step Functions が Glue スクリプト群をオーケストレーションする（IND320 の 30:30 のスライドより）
- Extract：トヨタの API サーバーから対象車種のデータを取得して S3 へ
- Transform：ここが最も重い。JSON をチャンク分割し、Bedrock で自然言語要約を生成する。スループットを稼ぐため並列化してあり、同時に約 30 車種を処理できる
- データ品質チェック：LLM の出力は非決定的なので、要約が正しいことは誰も保証してくれない。そこで価格やトリムの提供有無といった重要項目について、要約の内容を検証する工程を挟む
- Load：EventBridge にイベントを発行し、dev / stage / prod それぞれの Lambda を起動。Systems Manager からパラメータを取り、ETL の開始タイムスタンプを名前にした新しいインデックスを OpenSearch に作って取り込む
ロードが終わってもまだ使えません。非決定性がある以上、新しいデータセットが期待どおりの性能を出すか分からないからです。そのために評価エンジンが用意されていました。
- TMNA 側が 1 車種分の golden set（人手で正しさを確認した Q&A ペア）を提供する
- それを元に、任意の車種について合成テストセットを生成する
- 生成したテストセットで、デプロイ済みの RAG アプリケーションを叩く
- 出力を council of LLM（複数の LLM による評価）にかけ、定義済みの指標で採点する
ここまで通って初めて、インデックスのエイリアスを新しいインデックスに切り替える。RAG アプリケーションはエイリアス越しに参照しているので、無停止でデータのバージョンを差し替えられるという仕組みです。
さらに本番稼働中も、Q&A ペアを Bedrock で「質問の分類」と「法務ガイドラインへの適合度」の 2 軸で評価し、結果を MongoDB に入れてレポート画面を作り、法務チームと共有しているとのことでした。
ここまでが、きちんと作り込まれた RAG 基盤の姿です。
そして「これ全部いらないかもしれない」
バージョン 1 を運用するなかで見えてきた課題として、Short 氏が挙げたのは主に 2 つでした。
1 つは データの陳腐化。ETL の工程はご覧のとおり重く、しかも毎年の新モデルイヤー切り替え時には上流データの変更頻度が跳ね上がる。変更のたびに取り込み直しと評価のやり直しが必要になる。氏はこれを「a real problem」と表現していました。
もう 1 つは アクションへの要求。「近くのディーラーの在庫を調べたい」といった、参照だけでは済まない要望がビジネス側から出てきた。バージョン 1 のアシスタントにはできないことです。
そこで Strands SDK で自前のエージェントと MCP サーバーを作って検証してみたところ、出てきた結論がこれでした。
「Key finding – we can drop our ETL and traditional RAG」（IND320 の 38:30 のスライドより）
Key finding – we can drop our ETL and traditional RAG
Enabled by MCP + LLM Advancements
MCP と LLM の進歩によって、エージェントをデータに直接つなげられるようになった。だから ETL パイプラインと従来型の RAG をまるごと落とせる——という主張です。
言われてみれば当たり前にも聞こえます。ただ、これを言っているのが、自然言語要約からデータ品質チェック、合成テストセット、council of LLM による評価、エイリアス切り替えまで作り込んで本番稼働させている当事者である、というのが重みだと思いました。作った本人が「もう要らない」と言っている。
そしてこの判断が効くのは、陳腐化しないからです。ETL を挟む限り、データの鮮度はパイプラインの実行間隔に縛られます。エージェントが MCP 経由で API を直接叩くなら、その瞬間の値が返ってくる。同じ口から在庫照会のようなアクションも生やせる。
つまり、データを MCP で取得可能にしておくと、検索できる形に加工したデータを別途持たなくてよくなるわけです。ETL で作っていた自然言語要約もベクトルインデックスも、元データのコピーである以上、作った時点から古くなっていきます。エージェントが API を直接叩けるなら、そもそもコピーを作らずに済みます。
なお、氏は手放しで楽観してはいません。「PoC やデモは簡単だが、エージェント基盤を設計して本番に持っていくのは難しい」とはっきり言っていて、難所として認証・認可の設計、トラフィックに追随するオートスケーリング、コンテキストとセッションの分離保証を挙げていました。
バージョン 2 — AgentCore 上のエージェントと MCP サーバー
その難所を埋めるものとして採用されたのが Amazon Bedrock AgentCore です。バージョン 2 の目標構成がこちら。
バージョン 2 の目標構成。intent router が orchestrator に置き換わり、右側がエージェントと MCP サーバーになる（IND320 の 43:30 のスライドより）
バージョン 1 からの差分として説明されたのは次の点です。
- intent router を orchestrator に置き換える。orchestrator は Toyota Connected が構築する agent registry と連携する。registry は「認証済みクライアント → そのクライアントが使えるエージェント」のマッピングで、リクエストが来たら適切なエージェントにルーティングする
- バージョン 1 で intent router が使っていた外部 LLM の呼び出しをやめ、Bedrock に寄せる
- エージェントは Strands agents として AgentCore Runtime にデプロイ。Product Expert Agent（バージョン 1 の機能に相当）と Product Support Agent（顧客の車両に関する問い合わせ対応）の 2 種類
- 各エージェントに、仕事に必要なツールを提供する MCP サーバーを組み合わせる
MCP サーバーのホスト先には 2 つの選択肢があり、使い分けの理由が明快でした。
- Product Support MCP → AgentCore Gateway。素直にこれで足りる
- Product Expert MCP → AgentCore Runtime。こちらはトヨタの API を叩くので、レスポンスキャッシュが必須要件。カスタマイズが必要なため Runtime にデプロイする
AgentCore の各サービスについては、Short 氏が「demo から production に持っていくときに私が抱えていた懸念の多くに、そのまま対応する作りになっている」と評価していました。Runtime は Firecracker ベースの VM で既定で分離されており、サーバーレスでスケールし、インフラ運用の負担が小さい。Identity はマルチエージェント・マルチ MCP 環境での inbound / outbound 認証を引き受ける。Memory は会話管理を単純化する、という整理です。
そのうえで、Memory の使い方として面白い裏技が紹介されていました。AgentCore Memory を分散キャッシュとして使うというものです。
- MCP サーバーのツール呼び出しにデコレータを被せる
- 関数シグネチャと引数を連結して SHA-256 でハッシュ化し、キャッシュキーにする
- そのキーで AgentCore Memory のイベントメタデータを引く。ヒットすればメタデータから値を返し、ミスなら外部 API を叩いて結果をキャッシュする
ここで実装上のハマりどころが 1 つ共有されていて、AgentCore Memory の高レベルクライアントが持つ list_events にはイベントメタデータでのフィルタ機能が無い。低レベルクライアントには同等の関数にフィルタ機能があるので、そちらを直接呼ぶ必要があるとのことでした。また、MCP サーバーの異なるセッション間でキャッシュを共有するには、actor ID とセッション ID（またはエージェント ID）を固定値にしておく必要がある、という注意も添えられていました。
セッションのまとめがこちらです。
まとめ。ローンチ目標は 2026 年 Q1（IND320 の 47:50 のスライドより）
TMNA 側の推進体制も参考になる
実装の話に入る前の Ellis 氏のパートも、組織の話として面白かったので触れておきます。
TMNA の enterprise AI チームは、全社の生成 AI の CoE（Center of Excellence。専門知識を一箇所に集約して全社に展開する横断組織のことです）として作られたチームです。ただし、構成員がほぼ全員エンジニアという点が一般的な CoE と違うそうです。やっていることは大きく 2 つで、既存プラットフォームに組み込む形の AI アクセラレータを作ることと、新しいユースケースを掘って AI teammate を作ること。
方針として build → configure → buy が挙げられていました。ChatGPT が API で使えるようになった時点では製品が存在しなかったので、まず自分たちで作った。作って要件が固まったら、既存プラットフォームに組み込める製品を探して configure に移る。それが SaaS やパートナー経由で提供されるようになったら buy に切り替える。理由は明快で、「トヨタは自動車メーカーであって、UI/UX の会社でもソフトウェア開発の会社でもない」からです。
導入事例として挙がっていたのが契約書分析です。30 万件の契約に対して、アナリストが年 3 万件を処理できていた状態を、2 年前に生成 AI で一本化した。1 人あたり 15〜17 時間の削減に加えて、失効条項の見落としで払い過ぎていた分のような発見もあったそうです。
変更管理についての一言も残しておきます。「完璧な版は存在しない。作れた版を出して、学びに基づいて改善する」。製造業では全部を計画して derisk してから着手したくなるが、生成 AI でそれをやると毎日遅れていくだけだ、と。
セッション終了時、質疑応答の様子
おわりに
冒頭で、自動車産業や製造業では日々更新される情報を専門家ではない人が扱う場面が多い、という話をしました。dSPACE ControlDesk の事例は、それを API リファレンスや現場の操作手順を MCP サーバーのナレッジにすることで解いていました。今回の IND320 は、同じ課題をすでに RAG で解いていた側が、その RAG ごと MCP に寄せていくという話だったと思います。
そこで出てきたのが「ETL パイプラインと従来型の RAG はまるごと落とせる」という判断でした。データを持っている側が MCP で口を用意しておけば、それを検索できる形に加工して持ち回る層は要らなくなる。
もっとも、これがどんなデータにも当てはまるのかは、まだ分かりません。MCP で叩ける API がそもそも存在しないデータもあれば、検索できる形に加工しておくこと自体に意味があるデータもあるはずです。
バージョン 2 のその後
ローンチ目標は 2026 年 Q1 でした。その後どうなったのか探してみたところ、2026 年 3 月 24 日に AWS が公開した顧客事例の動画が見つかりました。セッションと同じ Stephen Short 氏が話しています。
2 分ほどの動画ですが、セッションからの差分が 3 点ありました。
- セッション中では名前が出てこなかったのですが、このアシスタントは Engage というプラットフォーム上の Ask Engage という機能でした
- バージョン 1 はすでに 1,800 以上のディーラーに展開済みとのことです（セッションの公式概要は 2,300 以上のディーラーとしていて、数が合っていません）
- バージョン 2 については、AgentCore Runtime でエージェントを、AgentCore Gateway で MCP サーバーを動かし、AgentCore Memory を共有キャッシュとして使うことで、バージョン 1 の機能を再現・拡張できていると述べています
ただし、バージョン 1 の置き換えが完了したとは言っていません。「今日のバージョン 1 のシステムを置き換え・再現しようとしている（looking to replace and replicate）」という言い方なので、この時点ではまだ移行の途上と読むのが自然です。ETL と従来型 RAG を実際に捨てきれたのかどうかは、本記事の執筆時点（2026 年 8 月）の公開情報では確認できませんでした。
参考
本記事に掲載したスライドの画像はいずれもセッション動画からの引用です（2026 年 8 月 13 日取得。© 2025 Amazon Web Services, Inc.）。
同じ re:Invent 2025 のセッションレポートとして、以下も書いています。
以上
