RAG用データの整備手順：更新頻度・権限・来歴を決める
参照したAIgram
目次
概要
RAG（検索拡張生成）は、生成AIに社内データを参照させて回答させる仕組みです。ただし、参照させるデータが整っていなければ、RAGは正しく機能しません。東京エレクトロンは、複数のデータベースとETL（データ収集・変換）ツールで構成されていた従来のデータ基盤をAzure Databricksへ統合し、16システムのデータを15分サイクルで収集・整備する体制を作りました。2025年4月からはこの基盤をRAGのデータ基盤としても使い始めており、アクセス管理の統合、精度評価の統一、データフローの可視化が評価されていますAzure DatabricksでRAG基盤と即時データ活用。この事例から、RAG用データを整備するときに決めておくべき3つのこと、更新頻度・権限・来歴が見えてきます。
複数のデータベースとETLツールに分かれた運用がRAG用データ整備の妨げになっていた
東京エレクトロンの従来のデータ基盤は、複数のデータベースとETLツールで構成されていました。この構成では運用管理が極めて煩雑になり、データを十分に活用できないまま、個人のスプレッドシートの中に埋もれてしまうケースも少なくありませんでした。
RAGにデータを渡す前提として、まずデータがどこにあり、どう更新されているかを把握できている必要があります。データがシステムごとにばらばらに管理されていると、この把握自体が難しくなります。東京エレクトロンの事例は、RAG導入以前の段階で、まずデータ基盤を一本化する必要があったことを示しています。
16システムのデータを15分サイクルで収集する更新頻度の設計
Azure Databricksへの統合により、東京エレクトロンは16システムのデータを15分サイクルで収集・整備できるようになりました。これによってフレッシュなデータをほぼリアルタイムで活用できるようになっています。
RAGが古いデータを参照し続けると、回答も古い情報のまま更新されません。どのくらいの頻度でデータを取り込み直すかは、業務上どの程度の鮮度が必要かによって決まります。東京エレクトロンが15分サイクルという具体的な数値を定めていることは、更新頻度を曖昧にせず、明確な基準として設計したことを示しています。
RAG活用でアクセス管理を統合できる点が評価される
東京エレクトロンでは、2025年4月にRAGのデータ基盤としての活用が始まりました。RAGでの活用にあたっては、アクセス管理を統合できることと、精度評価を統一できることが高く評価されています。
RAGは、社内のさまざまなデータを横断して検索・参照します。そのため、もともと部門やシステムごとに異なっていたアクセス権限を、そのままの形でRAGにも反映できるかどうかが問われます。権限がばらばらのまま統合されていないと、本来見えるべきでない情報が回答に混ざるおそれがあります。データ基盤をAzure Databricksへ一本化したことで、アクセス管理を統合できる点が評価されたことは、RAG導入の前提条件を整えるうえで重要な要素だったと言えます。
メダリオンアーキテクチャで品質を整えデータの流れを可視化し来歴を追いやすくする
東京エレクトロンは、メダリオンアーキテクチャという段階的にデータの品質を高めていく設計でデータを整えています。そして、データ基盤をAzure Databricksへ統合したことで、データの流れが可視化しやすくなり、データフローの設計・実装も容易になりました
。
RAGが誤った回答をした場合、その原因がどのデータに由来するのかを追えることが重要です。データがどこから来て、どんな加工を経て今の形になっているのかという来歴が分からなければ、原因の特定も修正もできません。データの流れを可視化できる基盤を整えたことは、RAG運用後に必要となる来歴管理の土台を先に作っていたことを意味します。
結論
東京エレクトロンの事例は、RAG用データを整備する際に更新頻度・権限・来歴という3点を具体的な仕組みとして決めていく手順を示しています。まず煩雑だった複数システムのデータ基盤をAzure Databricksへ統合し、16システムのデータを15分サイクルで収集する更新頻度を設計しました。次に、RAG活用にあたっては、アクセス管理を統合できることが高く評価されています。さらに、メダリオンアーキテクチャでデータ品質を段階的に整え、データフローを可視化することで来歴を追いやすくしました。東京エレクトロンは今後、Azure Databricksをコアとした「AI Data Platform」を全社標準のデータ基盤にしていく計画であり、この整備の順序は、これからRAGを社内データで使おうとする組織にとっても参考になる進め方です。