業務効率が伸びない理由

生成 AI の普及で効率化が期待される一方、現場では効果が伸び悩むことがあります。
僕のチームで見えた課題は「社内前提の共有不足」でした。
この記事では、データカタログ（OpenMetadata）と MCP 連携で「社内の意味」を LLM に安全に渡し、業務支援を安定させる実践を紹介します。

この記事は、僕の現場で得た知見をもとに「なぜ効率が伸びないのか」「どう整備すれば改善するのか」を具体例付きでまとめたものです。

背景・問題情報

同じ用語でも部門で解釈が違い、認識ずれが発生
LLM に社内前提を十分伝えられず、回答精度が下がる

この解決策が「データカタログ」です。信頼できる用語定義や関連情報を体系化し、LLM に安全に渡せる形（MCP）にすると、再説明の手間が減って回答の質もグッと安定します。

データカタログとは

社内のデータ資産を整理し、「意味」を付けて再利用しやすくするための基盤です。ざっくり言うと“社内の共通言語帳”。

どこに何があるか（所在）
何を表すか（意味）
どの程度信頼できるか（品質）
どう使われてきたか（履歴）

を明確にすることで、二重取得・属人化を抑え、意思決定のスピードと精度を上げます。

LLM は社内特有の用語や文脈をそのまま理解できるわけではありません。だからこそ、信頼できる「社内の意味」を整えて LLM に渡す。その橋渡し役がデータカタログです。

データカタログの今

企業のデータ活用が一般化し、データカタログ導入は加速しています。散らばった資産を一元管理し、所在・意味・品質・履歴まで見える化する基盤として注目されています。

導入の背景とトレンド

ガバナンス・民主化・法規制対応（GDPR 等）
クラウド DWH／データレイクの普及に伴う API・LLM 連携の強化
リネージ可視化、自動収集、コラボ機能の重視

日本でも大手企業を中心に導入が進み、用語標準化で体験を平準化する動きが増えています。データカタログは「一覧」ではなく、活用を加速する“知識のハブ”。

なぜ OpenMetadata を採用したか

重視したポイントは以下です。

社内データの可視化と一元管理
所在・意味・用語の整理
LLM 連携（MCP として活用）
マルチクラウド（GCP/AWS）対応
コスト

Google Cloud のサービスである Data Catalog も検討しましたが、僕らの規模では機能過多でコストが課題でした。そこで、OSS で拡張性・バランスが良い OpenMetadata を選びました。

主な特徴

マルチクラウド・多様なソース対応（GCP/AWS/オンプレ）
柔軟なメタデータ管理（データセット、ダッシュボード、パイプライン）
LLM 連携（MCP）と API による自動化
活発なコミュニティとドキュメント
商用製品より導入・運用コストを抑えやすい

コスト

OSS なので初期導入コストをグッと抑えられます。構成も自分たちで決められるため、ムダな出費が出にくいのもうれしいポイントです。

運用は Cloud Run または GKE にデプロイし、バックエンドに Cloud SQL（PostgreSQL）を使っています。今のところ運用コストは、ざっくり月数千円程度で収まっています。

もちろん構成次第でコストは変わるので、自社の運用スタイルに合う形を探すのが良いと思います。

注意点として、Cloud Run は少しクセがあります。とくに MCP 連携などを重視する場合は、GKE のほうが安定しやすいです。
理由は、Cloud Run がリクエストのない時間帯にスケールダウンしてしまい、バックグラウンドジョブ停止の可能性があるためです。
常時起動を求めるワークロードなら GKE を検討すると安心です。

MCP

MCP（Model Context Protocol）により、OpenMetadata のメタデータを LLM に安全に渡せます。標準機能なので自前で連携の仕組みを作る必要がなく、導入ハードルが下がります。

サーバ構成をシンプルに保てるので、運用コスト削減に直結します。

具体的な内容 / ケーススタディ

Dify と MCP 連携

連携周りの設定は下記の記事にまとめました

社内 LLM 基盤（Dify）に OpenMetadata を MCP として連携。用語の意味参照ができるようになり、回答品質が安定。プロンプト作成の確認工数もグッと減りました。

例：IntimateMerger の IM-UID を参照すると、定義・利用目的・関連用語がひとまとめで返ってきます。背景説明を毎回打つ必要がなくなりました。

整備効果：

どこに何のデータがあるか把握しやすい
部門横断の理解が進み、誤用・問い合わせが減る
エンジニアは SQL 生成や他チーム API の把握が楽になる

データベース・ストレージ

OpenMetadata は BigQuery、Cloud SQL、RDS、Athena など主要 DB と連携。メタデータ収集を自動化し、テーブル・列の説明を取り込みます。説明がすでにあれば再入力をほぼ省けます。

上記のように、定期収集で最新状態をキープ。条件を整えておけば、新規テーブルも自動で取り込めます。

用語集（Glossary）

社内用語の定義・利用目的・関連情報を整理。用語にタグを発行して資産へ紐付けることで、意味を横展開できます（例：「顧客 ID」を関連テーブルや列にタグ付け）。
既存ドキュメントからの自動生成もできて、導入が楽です。

整理した用語集は LLM 連携でも活躍し、社内用語の意味を正確に伝えることで回答品質を高めます。

API 情報の登録

自社システムの API を登録し、エンドポイント・パラメータ・レスポンス・利用例を整理。開発者が理解しやすく、チーム連携や API 利用が進みます。OpenAPI はコードの docstring から自動生成できるので、整備もラクです。

登録した API は機能把握を助け、開発効率を高めます。

MCP 連携の全体像

上記のように収集したメタデータを MCP として LLM 基盤（Dify）に連携できます。VS Code から用語定義やテーブル説明へ直接アクセスでき、開発中の参照がスムーズになります。OpenMetadata のメタデータをもとに、LLM が社内用語や構造を踏まえた回答や SQL 自動生成・用語解説などのアプリ開発が進みます。

こうした連携機能が標準で備わっているのも、OpenMetadata のうれしいところです。

注意点

MCP 連携では、JWT トークン設定とアクセス権限の管理に注意が必要です。
適切なロール割り当てとポリシー遵守で安全に連携できます。

初期状態では強めの権限が無期限で付与されている場合があります。必要に応じて見直しましょう。

良かった点

既存（BigQuery 等）の説明を自動取り込みし、再入力工数を削減
Glossary のタグで意味を横展開できる
API 情報登録で機能理解が進む
MCP 連携でエディタや社内 LLM から即アクセス
定期収集で最新状態を維持しやすい

まとめ・結論

OpenMetadata は「資産の可視化」「意味付け」「LLM 連携」をバランス良く実現し、低コストで段階的に育てていけます。
僕らは LLM と OpenMetadata を組み合わせ、営業向けの SQL 自動生成や用語解説アプリを進めています。
現場で“同じ意味を同じ言葉で共有”できる環境を、もっと広げていきたいです。

もしフィードバックや他製品の比較経験があれば、ぜひコメントで教えてください。お待ちしています。🙇‍♂️

参考資料・リンク