2026年6月18日
分散型データ管理時代の命名問題解決 ～RAG 技術を活用したデータベース命名支援アプリの開発～
塩野義製薬株式会社 DX 推進本部データサイエンス部データエンジニアリンググループ２所属の久末です。普段は業務改善のためのアプリケーション開発やこのサイトの運営を担当しています。 —
本記事では、分散型データ管理環境におけるテーブルやカラムの命名ルールを統制する際の課題に対して、RAG（Retrieval-Augmented Generation）技術を活用した命名支援アプリを開発し、品質とガバナンスを両立させるための仕組み作りについてご紹介します。
塩野義製薬では、営業・研究開発（R&D）・会計・人事など各部門が自律的にデータを共有・活用できる「DB-DAO（Database Decentralized Autonomous Organization：自律型データ活用組織）」の構築を進めています。この分散型アプローチにより、各部門が業務に最適化された形でデータを加工・活用できる一方で、新たな課題も顕在化してきました。
最も重要な課題は「命名ガバナンス」です。分散環境では、各部門の担当者が独自の解釈でテーブル名やカラム名を決定するため、表記揺れの拡大や、データの管理者のレビュー工数の増大、さらには既存のデータ資産との不整合といった問題が発生しています。また、当社では自社開発のデータカタログシステムを通じて 1,068 テーブルを管理していますが、論理名などのメタデータの入力率は 65%に留まっているのが現状です。これら二つの課題は、一見別の問題に見えますが、命名プロセスが分離・分断されていることが共通の要因になっています。
そこで私たちは、データメッシュの恩恵を享受しながら品質とガバナンスを両立させるため、命名時点でガバナンスを効かせ、その過程で論理名などのメタデータ入力も促すことを目的に、RAG 技術を活用した「命名支援アプリ」を開発しました。
RAG 技術による解決アプローチ
純粋な LLM アプローチの限界
汎用的な LLM に対して「良いテーブル名を考えて」といった直接的なプロンプトを投げる純粋なアプローチでは、企業固有の命名規則や業界特有の略語、既存システムとの整合性を保つことが困難です。
この手法が抱える根本的な問題は、企業固有の文脈が考慮されない点にあります。
製薬業界における「AE（有害事象）」や「SAE（重篤な有害事象）」といった専門用語は、一般的な文脈とは異なる意味や使われ方を持ちますが、汎用的な LLM ではこうした前提を正確に理解することができません。
汎用的な LLM は、「AE」 を IT 分野における 「Application Error」 やマーケティング文脈での略語として解釈する可能性がありますが、製薬業界では AE は「有害事象」という法規制上も重要な意味を持つ用語です。このように、同一の略語であっても業界ごとに意味が大きく異なる点が、汎用モデルでは正しく扱えない要因となります。
また、既存の数千テーブルとの整合性を保つためには、これまでの組織内部の命名パターンを参照する必要があります。しかし、純粋な LLM は企業固有の情報にアクセスできないため、表記揺れや意味の重複、既存資産との不整合が発生しやすくなります。
RAG 技術による課題解決
そこで私たちが着目したのが RAG 技術でした。
本取り組みにおける RAG の最大のポイントは、汎用的な外部知識ではなく、自社で独自に開発・運用しているデータカタログに蓄積された企業固有の文脈そのものを知識基盤として活用している点にあります。
当社のデータカタログには、1,068 テーブル分のテーブル・カラムの物理名・論理名に加え、業務定義や業界固有の略語といった知識資産が蓄積されています。これらのメタデータをベクトル化し、ユーザーからの命名案と意味的に類似する情報を動的に検索・取得することで、常に企業固有の文脈を踏まえた命名提案が可能になります。
具体的には、ユーザーが入力した内容に対して、データカタログ上の既存テーブルやカラムのメタデータを横断的に検索し、意味的に最も近い事例を自動で抽出します。その命名パターンや業務定義を参考情報として LLM に提示することで、人手で過去事例を調査しながら命名していたデータエンジニアの思考プロセスを再現し、LLM による一貫性のある命名提案を実現しています。
さらに重要なのは、この命名支援アプリ自体が、メタデータ品質を継続的に向上させる仕組みとして機能する点です。本アプリによって命名が統制されるだけでなく、標準化されたメタデータが補完・蓄積されることで、データカタログ上の知識資産はより正確で充実したものになります。その結果、RAG によって参照される情報の質も向上し、命名提案の精度がさらに高まるという正のスパイラルが生まれます。
Snowflake Cortex AI 選択の戦略的意義
技術基盤として Snowflake を採用し、特に Snowflake Cortex AI を選択した理由は、統合データプラットフォームでの一気通貫処理が実現できることです。既存のデータウェアハウス環境内で、データ取得からベクトル化、類似検索、LLM による回答の生成まで全ての処理を完結できるため、データの移行や外部システムとの複雑な連携が不要になり、セキュリティリスクも最小化されます。
従来、ベクトル検索を実装するには専用のベクトルデータベースの構築と運用が必要でしたが、Snowflake Cortex AI では既存のテーブルに EMBED_TEXT_1024 組み込み関数でベクトルカラムを追加するだけで高性能なベクトル検索基盤を簡単に構築できます。これにより開発・運用の複雑さを大幅に軽減し、データエンジニアが慣れ親しんだ SQL ベースでの実装が可能になりました。
本アプリ全体の構成は、事前ベクトル化したテーブル情報を知識ベースとし、ユーザー入力に対してベクトル類似検索によって関連情報を取得し、その結果をコンテキストとして LLM に渡すことで、制約条件を満たす命名案を生成するものです。この設計により、蓄積された業務知識を最大限活用しながら、スケーラブルで運用しやすいシステムを実現しました。
GitHub 公開による知見共有
本記事で紹介した命名支援アプリの実装の詳細は、GitHub にて公開しています。データベース設計、RAG パイプラインの実装、Streamlit アプリケーションのコードなど、システム全体を再現しています。
具体的な実装方法やコードの詳細については、GitHub リポジトリの README をご確認ください。セットアップ手順から各機能の技術的な解説まで、他の組織でも同様のシステムを構築できるよう詳細に記載しています。
終わりに
今回紹介した RAG 技術を活用した命名支援アプリの開発を通じて、既存の命名パターンやメタデータを活かしながら、分散環境下での命名を支援する仕組みの有効性を確認することができました。
私たち塩野義製薬のデータエンジニアの役割は、業務部門が自律的にデータを活用できる環境を整備することです。DB-DAO の実現を目指す塩野義製薬において、データの品質とガバナンスを両立させる仕組みづくりは、まさにその中核となる重要な取り組みです。
このプロジェクトを通じて、SQL という慣れ親しんだ技術スタックで RAG 技術を実装し、これまで個々のデータエンジニアの経験や判断に依存していた命名プロセスを、組織として共有・再利用できる形で支援する仕組みを構築しました。命名支援はその一例に過ぎませんが、メタデータを「管理対象」ではなく「活用される知識資産」として捉え直すきっかけになったと考えています。
私たちの取り組みが、同様の課題を抱える多くの組織にとって、有益な参考事例となることを願っています。
データエンジニアリング人材の募集
データサイエンス部では、 データエンジニアリング職の募集を行っています。
データ関連のスキルやご経験をヘルスケア領域の データ基盤の構築・運用で活かしてみたい方は、 以下のリンクから募集内容の詳細を確認ください。 皆さまからのご応募をお待ちしております。
