ハルシネーションの課題に直面するトヨタ自動車は、AI活用型のRAG基盤を再設計した。同社が構築した業務特化型の社内検索AI SaaSの全容とは。
この記事は会員限定です。会員登録すると全てご覧いただけます。
車両の開発から販売、アフターサービスまで、トヨタ自動車が展開する業務領域は広く、そこには膨大なドキュメントやナレッジが蓄積されている。技術仕様、過去の案件対応、部品構成、設計指示、もろもろ。全てが日々の業務に不可欠な情報だ。
だが、情報が散在することで、現場の生産性はしばしば阻害される。「社内のどこかにあるはずの資料」がすぐに見つからず、類似事例を調べるのに時間がかかる。そんな現場の声に対し、同社が着目したのが生成AIと検索技術を融合したRAG(Retrieval-Augmented Generation)だ。
過去に実施されたPoC(概念実証)でRAGは有望な成果を見せたものの、実際に業務で活用するとなれば幻覚(ハルシネーション)による誤情報の排除と、根拠の提示が欠かせない。
そこで同社は、「Amazon Bedrock」(以下、Bedrock)や「OpenSearch」「Amazon Cognito」(以下、Cognito)などのスタックを組み合わせ、業務ドメインごとに安全かつ柔軟に運用できる「RAG SaaS」として社内実装。アクセス制御やUI設計にも踏み込み、「安心して使える生成AIのかたち」を模索してきた。
この取り組みの背景、構築アプローチ、設計思想、現場浸透の工夫までをトヨタ自動車の佐井友洋氏(カスタマーファースト統括部 オペレーション DX 改善室)と時津 弘太朗氏(同)が詳細に解説した。
「『ChatGPT』に聞いたけど、どの資料を根拠に出した答えか分からない」そんな声が、トヨタ自動車の業務現場から上がっていた。車両仕様や過去案件、部品構成の照会といった業務には、精密さと再現性、そして出典の明示性が求められるからだ。
カスタマーファースト推進本部では国内外に1.5億台以上存在する保有車両への対応業務を担っており、販売店から寄せられる問い合わせへの回答のために、社内各所に点在するシステムと文書を横断的に検索する必要があった。
部品マスター、設計指示、QA履歴……。それぞれのシステムが別のUI・検索方式を採用しているため、少し表現が違うだけで必要な情報が見つからない場面も多い。この問題を解決する手法として検討されたのが、生成AIにドキュメント検索を組み合わせたRAGだ。
ベクトル検索によって文書から類似情報を抽出し、それを基に大規模言語モデル(LLM)が自然言語で回答する。さらに根拠となったドキュメントの原文やリンクも同時に提示することで、「何を基に答えているか」が明確なシステムを構築できる可能性が見え始めた。
最初に導入されたのは、販売店からの問い合わせを支援する部門だ。試験運用では、回答精度の向上だけでなく、調査業務の工数を前年比34%削減する成果が得られた。
担当者からも「まずRAGに聞くことで調査の取っ掛かりになる」といった前向きな声が集まったという。「従来はキーワードが違うとヒットしなかったのですが、ベクトル検索では意図の近い情報を拾えます。何を聞くかで検索精度が変わるという実感がありました」(佐井氏)
この成功を踏まえ、トヨタ自動車では「複数の業務ドメインにまたがって活用できるRAGの共通基盤化」を構想。属人化せず、かつ業務ごとの独立性も担保できるような「業務特化型RAG SaaS」として再設計がスタートした。
業務特化型RAG SaaSの再構築にあたって、トヨタ自動車が選んだのはAmazon Web Services(以下、AWS)の「CloudFormationテンプレート」「生成AIアプリケーションビルダー」を起点とした迅速な構築アプローチだった。
このテンプレートを活用すると、管理アプリから数クリックでRAG環境を自動生成できる。ベースとなるアーキテクチャには、Bedrockや「Amazon OpenSearch Serverless」「Amazon S3」(以下、S3)、「AWS Lambda」(以下、Lambda)、Cognitoなどの最新サービスが組み込まれ、プロンプト入力から回答生成、出典提示までの一連のフローが整備されている。
しかし、最初は「1プロジェクトごとにRAG環境を複製」する前提であったため、プロジェクト数に比例して運用負荷とコストが膨張する懸念があった。そこで導入されたのが、複数の業務プロジェクトを1つのRAG基盤で処理可能にするマルチテナント型アーキテクチャだ。
その鍵となったのが、メタデータを使って検索対象や表示内容を制限する「メタデータフィルタリング」(「Knowledge Bases for Amazon Bedrock」の一機能)と、AWSのオープンソースUIコンポーネント「Storage Browser for Amazon S3」(以下、Storage Browser)の組み合わせだ。
Cognitoでユーザーごとの所属グループを定義し、S3バケット内でプロジェクト別のディレクトリ構成を採用。OpenSearchインデックスにはディレクトリ名をメタタグとして保持させ、プロンプト実行時にはLambdaがCognitoからユーザー属性を取得し、対象データを動的にフィルタリングする。
「実際に20以上のプロジェクトでRAGを利用していますが、環境は1つのみ。これにより、コストやオペレーション負荷を20分の1に抑えられたのは大きな成果でした」(時津氏)
ファイルのアップロードやドキュメントの差し替えといったオペレーションも、Storage Browserによりユーザー自身がブラウザから実施可能に。これにより、利用部門によるナレッジの自主整備が進むようになり、IT部門の運用負荷が飛躍的に軽減されたという。
構築作業は社内のCCoE(Cloud Center of Excellence)が提供するクラウドプラットフォーム「TORO」(Toyota Reliable Observatory/Orchestration)を通じて実行され、申請から2日程度でセキュリティ要件を満たした本番環境が構築可能となっている。
RAG基盤の整備が進む一方で、トヨタ自動車がもう一つ重視したのが、生成AIのアウトプットをユーザーが「無批判に信じることを防ぐ」ための工夫だった。
現実には、生成AIは正確そうに見える誤情報(いわゆる「ハルシネーション」)を出力することがあり、特に車両開発や顧客対応などの業務においては、誤った情報を根拠に判断することは絶対に避けなければならない。
こうしたリスクに対応するため、トヨタ自動車ではRAGのユーザーインタフェースを「生成回答よりも先に根拠情報を提示する」構成に再設計した。従来のAWSテンプレートでは、生成回答が先に表示され、根拠文書はアイコンをクリックして確認する仕組みだった。しかし、それでは「AIの回答=正解」と受け取られやすく、業務判断に誤解を生む恐れがあった。
トヨタ自動車はこの課題に対応するため、UIを「React」ベースで独自に再構築し、まず出典情報を提示し、そのうえで生成回答を表示するという順序へと変更。情報の信頼性と業務適用性を両立させる工夫を施している。
ユーザーが先に見るのは生成AIが参照した文書そのものであり、生成された回答はあくまでその補足・要約という位置付けになる。この設計によって、「AIがこう言っている」ではなく「この文書にこう書かれている」が出発点となり、ユーザー自身が主体となって判断できるようになった。
システム改善だけでなく、「AIを使いこなす」カルチャーを醸成するための活動も進む。プロンプト作成や文書整備のノウハウを集約した社内ポータルサイトを開設し、ユーザー向けにTipsやガイドを提供。RAGがより高精度に答えられるように、文書表現の見直しやドキュメント構造の最適化といった「ナレッジのUX化」も支援している。
トヨタ自動車では「ハルシネーションはゼロにはできない」という前提に立ち、ユーザーがAIの回答をうのみにせず、根拠を確認する習慣を促す設計を重視している。ある意味では、「AIの出力を信頼しすぎない」前提で使わせることが、リスクを抑えるポイントだ。
このようにトヨタ自動車のRAG活用は、単なる技術導入だけでなく「どうすればユーザーが安心して使えるか」「どのように文化として根づかせるか」までを見据えた生成AI時代の業務デザインの実践例といえる。
本稿は2025年6月25〜26日にAWS(Amazon Web Services)が主催した「AWS Summit Japan 2025」の講演「トヨタ自動車が保有する膨大なデータを活用した業務ドメイン特化型のRAG SaaS」の内容を編集部で再構成したものです。
Anthropicが日本法人を設立 「日本のために、日本と共に」
AWSが日本に2兆円投資する理由 大規模イベントで語られた未来の姿
Claudeに店舗運営任せたら暴走して大赤字になった件 素人丸出しでも光る可能性
IBMのメインフレームがAI時代に息を吹き返しているワケCopyright © ITmedia, Inc. All Rights Reserved.