【実験レポート】Googleドライブでメダリオンアーキテクチャを適用した簡易版データレイクハウスを構築する

AI活用が本格化するにつれて、社内に蓄積された契約書・提案資料・議事録・チャットといった非構造化データをどう扱うかが、実装上の重要なテーマになっています。

こうした情報を整える設計としてデータレイクハウスが提唱されていますが、実装事例の多くはBigQuery・Databricks・Snowflakeといった専用基盤を前提としており、コスト・運用面からみて現実的ではありませんでした。

本記事では、Deflag社が、Googleドライブとメダリオンアーキテクチャ（Bronze/Silver/Gold）を組み合わせて簡易的なデータレイクハウスを試験的に構築した実験を、設計判断・3層の中身・Claude連携・アクセス権限の運用まで公開します。

Googleドライブで簡易版データレイクハウスを構築しようと考えた背景

まず、社内でのデータレイクハウス構築の出発点となった問題意識は、次の3つでした。

1つ目は、業務のなかで情報を探す時間の長さです。
契約書がGoogleドライブのどこに保管されているか、過去の似た提案がNotionのどのページにあるか、方針の議論がSlackのどのスレッドで交わされたか。
これらの情報はどこかに残っていますが、必要なときに引き出すのに時間がかかっていました。

2つ目は、社内で共有されている考え方や判断基準を、AIに参照させたいという要望です。
「Deflagらしい提案の書き方」「これまでの判断の理由」「業界ごとの当社の見方」といった、明文化されていない社内の共通理解は、AIに直接聞いても答えが返ってきません。
会話・議事録・提案書に分散しているこれらの情報を、AIから参照できる形に集める必要がありました。

3つ目は、定量データと定性データの活用状況の差です。
売上・案件・行動ログといった定量データは、すでにAIから参照できる状態に整っていました。
これらの数値は、いま構築している非構造化データの基盤と同じ仕組みのなかに組み込んでおり、閲覧権限を持つメンバーだけが参照できるようにしています。
一方で、契約書・提案資料・議事録・チャットといった定性データはツールごとに分かれたままで、AIからまとまった形で扱える状態にはなっていませんでした。

記事で扱う3つの前提概念

実際の実装方法に入る前に、記事内で登場する重要な概念の説明をします。

データレイクハウスとは

データレイクハウスは、構造化データと非構造化データを1つの基盤で扱えるデータ保管・分析の方式です。
従来のDWH（データウェアハウス）は表形式の構造化データを、データレイクは形式を問わない大量データを、それぞれ得意としてきました。
データレイクハウスは、両者の得意な領域を1つの基盤に統合した設計として提唱されています。

関連記事：データレイクハウスとは

メダリオンアーキテクチャとは

メダリオンアーキテクチャは、データをBronze層・Silver層・Gold層の3つに分けて、段階的に品質と用途を上げていく設計パターンです。
Bronzeには生データを、Silverには整形・クレンジング済みのデータを、Goldにはビジネス用途に整えたデータを配置します。

関連記事：メダリオンアーキテクチャとは

コンテキストレイヤーとは

コンテキストレイヤーは、データそのものに加えて、「この数値は何を意味するか」「誰の定義に基づくか」「どのルールで使ってよいか」といった文脈を、AIに明示的に渡すための層です。
データ量や品質だけを整えても、AIは業務の文脈を読み取れないため、この層を独立して用意する考え方が広がっています。

関連記事：コンテキストレイヤーとは

「自社ならどう実現するか」を考えた設計判断

一般に提唱されるデータレイクハウスの構成は、専用基盤（BigQuery・Databricks・Snowflakeなど）を前提とした重厚な設計が中心です。
そのまま自社に持ち込むと、初期費用と運用負荷が実験の速度に見合いません。
専用基盤への投資よりも、手元にある既存ツールで動かしながら学ぶほうが、設計判断と検証のサイクルを速く回せると考えました。

最初に行ったのは、社内のデータがどこに、どんな形で存在するかの整理です。
当社の場合、主な保管先は次の4つでした。

• Googleドライブ（契約書・提案資料・請求書・スライドなどのドキュメント）

• Notion（プロジェクト情報、社内ドキュメント、案件メモ）

• Slack（リアルタイムの議論、決定、共有）

• HubSpot（顧客情報・案件情報のCRMデータ）

このうち、AIから参照するための入口をどこに置くかで、Googleドライブを選びました。
理由は3点あります。

1つ目は、全社員がすでにGoogleアカウントを持っていて、Googleドライブが日常的に使われていることです。
新しい基盤を導入する場合の学習コストと運用切替のコストが、この時点でゼロになります。

2つ目は、Googleドライブのファイル共有権限が、そのままアクセス制御として使えることです。
フォルダ・ファイル単位で設定されている共有権限が、後述するClaude連携でもそのまま反映されます。権限設計を業務用とAI用で二重に持たなくて済みます。

3つ目は、ClaudeとGoogle Driveの公式コネクタを提供していることです。
追加のMCPサーバや自作の検索基盤を用意しなくても、Claude側からドライブ内のファイルを直接参照させられます。詳細は記事の後半で扱います。

これらの理由から、Googleドライブを集約先とし、そのなかにデータレイクハウスの基盤設計で推奨されているメダリオンアーキテクチャの3層を配置していく方針を採りました。

実際の層構成｜Bronze / Silver / Gold層

Bronze層｜各システムに存在する生データ

Bronze層は、加工前の生データを置く層です。
当社の場合、Bronze層の置き場所は、データの所在によって4つに分けています。

もともとGoogleドライブにあるファイル：
契約書・提案資料・請求書・議事録は、これまでと同じフォルダに置かれたまま、その場所がBronze層として扱っています。
コピーを作ることはせず、移動も改名も削除もしていません。

Slackの会話：
対象チャンネルの会話を日次でテキスト化し、AI用フォルダのなかに用意したSlack専用の保存先へ、チャンネル別・日付別のファイルとして書き出しています。
個人情報はマスクしたうえで取り込んでいます。
ドライブの外にある情報を扱うために、ここではコピーを作る形をとっています。

Notion：
ページ単位で取り込み、1ページにつき1つのファイルとして書き出しています。
あわせて、全ページを1つにまとめた索引ファイルも用意しています。
ドライブの外にある情報のため、Slackと同じくコピーを作る形をとっています。
Notionはもともとページがmarkdown形式で扱えるため、形式を変換する処理は挟んでいません。

HubSpot：
取引・会社・連絡先といったオブジェクト単位で、それぞれ1件につき1つのファイルとして書き出しています。こちらも全レコードをまとめた索引ファイルを別に用意しています。
案件のステージや状況が分かる項目を中心に取り込み、取引金額などの機微な数値や、連絡先の氏名・メールアドレスは取り込みの対象から外しています。

いずれの場合も、各システム側を正の情報源とし、取り込んだ側は同期時点のスナップショットとして扱います。各システム側で編集された内容は、翌日の同期で反映される構成です。

Silver層｜各所のデータのラベル情報をGoogleドライブ一箇所にまとめる

Silver層は、Bronze層のファイル1つひとつに対して、それが何の情報なのかを記述したラベルファイル（markdownまたはJSON）を1つ作る層です。
ここが構築作業の中心であり、AIの回答精度を最も左右する部分でした。

ラベルファイルには2つの見出しがあり、その下に合計23の項目が並びます。

このうち、AIの回答を大きく変えた項目が4つあります。

意思決定
この項目は、会社としてこれまで何をどう判断してきたかを、AIが参照できる状態にすることが目的でした。
意思決定を記録しておくと、判断が残っているデータだけに候補が絞られ、後述のGold層で案件ごとに「いつ・何を・なぜ決めたか」として束ねられます。
過去に似た状況で自社がどちらを選んだかを検索できるため、AIの回答は一般論ではなく、これまでの判断に沿ったものになります。
それまで当たり障りのない要約しか返ってこなかった問いに、実際の判断とその理由が返るようになりました。

検索上の役割
そのファイルが集計や記録の元データなのか、判断の根拠として引ける資料なのか、作業中の素材なのか、ロゴや写真といった制作物なのかを区別します。質問に対して、AIがどのファイルを優先して読むべきかが決まります。

時系列上の扱い
過去の一時点の記録なのか、現在の状態を示すものなのかを区別します。
古い提案書を最新の状況として答えてしまう事故は、この項目で防いでいます。

想定質問意図
そのファイルがどういう問いに答えるためのものかを記録します。
数値や指標を調べるための資料なのか、取引や商流を確認するための資料なのか、といった区分です。

ラベルを付ける対象は、いまのところ5系統に分かれています。
ファイル単体、フォルダ全体、Notionページ、議事録、HubSpotの案件情報です。
対象によって記録する項目を変えており、たとえば議事録なら参加者・議題・決定事項・アクション項目を、Notionページならデータベースの属性やステータスを、それぞれ本文とは別に切り出して保持しています。

財務情報などの定量データも、同じ経路を通しています。
 売上・原価を管理しているスプレッドシートも、非構造化データと同じようにドライブ上の生データとして扱われ、同じ形式のラベルファイルが1つ作られます。
違いは、ラベルに入る値だけです。
「検索上の役割」を数値の出どころ、「時系列上の扱い」を現在の状態、「想定読者」を限定と設定することで、AIは同じ仕組みのなかで数値と文書のデータを区別して扱えます。

Gold層｜ラベル別の索引と意思決定の記録

Gold層は、Silver層のラベル情報を再編成して、業務上の問いに答えられる形に整えた層です。Gold層もmarkdown群で構成しています。

Gold層の中心になっているのは、Silver層にあるラベル別で分類したファイル名の一覧です。
Silver層のラベル項目を1つ選び、その値ごとにファイルを分類した一覧を、主要なラベル項目ごとに用意しています。
顧客名で分類した一覧、文書種別で分類した一覧、更新時期で分類した一覧というように、現在17種類あります。

AIは質問を受けると、この一覧でファイルの候補を絞ってから、個別のラベルやデータを読みにいきます。
「A社の直近の提案資料」という質問であれば、顧客名の一覧と文書種別の一覧と時期の一覧を重ね合わせて数件まで絞り、そのうえでデータにあたります。
ドライブ全体を検索するのではなく、先に候補を狭めるための仕組みです。

その他にも、Gold層には次のようなデータも置いています。

• 意思決定の記録：会議の議事録やSlackの議論から、重要な判断とその根拠を抽出して蓄積

• 会社ごとのタイムライン：顧客企業ごとに、初回接点・提案・契約・更新・課題対応などの時系列イベントを一元管理

• 定点レポート：週次・月次の全社の動きのまとめ、注意が必要な案件の一覧、契約更新の期日管理などを、あらかじめ集約したレポートとして用意

• リネージ（データがどこから来たかの記録）：Gold層のファイル1件ごとに、それがどのファイルのどこから作られたかを記録。ドライブのファイルとNotionのページの対応関係も、ここで保持。

さらに、Gold層にはコンテキストレイヤーの機能も含めています。
「この数値の定義は何か」「この判断はどのルールに基づくか」といった、AIに渡す前提情報も、Gold層のmarkdownとして記述しています。
層を別に立てずGold層に統合しているのは、Claudeから呼び出す際に参照する場所を1つにまとめるためです。

Databricksが提唱する原型では、Gold層はビジネス用途に整えたデータを置く層と定義されており、当社ではその考え方を踏襲したうえで、コンテキスト情報の格納先としてもGold層を使っています。（出典: What is medallion architecture? — Databricks）

Claudeから /ask-lakehouse で呼び出す運用

Claude公式Google Driveコネクタ経由でGold層を参照

Claudeが提供している公式のGoogle Driveコネクタを当社のClaude環境で有効化し、Gold層のフォルダを参照先として設定しています。
呼び出しは、社内で共有しているカスタムスラッシュコマンド /ask-lakehouse で行います。

追加でMCPサーバを構築したりせず、GoogleドライブとClaudeの標準機能だけで呼び出せる構成にしています。

Googleアカウント連携でアクセス権限を自然に担保

Claudeの公式ヘルプセンターでは、Google Workspaceコネクタについて「Claudeは接続したGoogleアカウントで見られる情報にしかアクセスできない」と明記されています（出典: Use Google Workspace connectors — Claude Help Center）。

この仕様が、当社の運用に強く影響しています。
チームメンバーは各自のGoogleアカウントでコネクタを接続しているため、Claudeを介した検索でも、そのメンバーがドライブ上で共有権限を持っていないファイルにはアクセスできません。
契約情報のように役職・関係者を限定したいドキュメントも、通常のGoogleドライブ共有権限を設定するだけで、Claude経由での取り扱いにも同じ制御が反映されます。

業務用のGoogleドライブとAI側で権限を二重に管理する必要がなくなり、実装と運用の負荷が下がりました。リソースが限られる状況では、この二重管理を避けられることの効果は大きいと感じています。

チームが日常的に使っている3つの用途

構築後、社内メンバーが /ask-lakehouse を使う場面は、大きく次の3つに落ち着いてきました。

• 案件の最新情報の確認: 「A社の直近の議事録と提案内容を、意思決定の経緯とあわせて出してください」といった問いで、Gold層のタイムラインと会話ログを横断して確認します。

• 提案資料の叩き・方向性確認: 「この業界向けに、過去の提案から使えそうな構成と論点を教えてください」といった問いで、Silver層のラベル経由で過去資料を集約します。

• 社内既存コンテンツの確認: 「このテーマの資料や記事は、社内にすでにあるか」「記事のネタになりそうな社内の動きはあるか」といった問いで、Gold層の切り口別ラベルを検索します。

いずれも、以前は複数のツールを行き来して人が調べていた作業です。
データレイクハウスの構築で情報の場所と粒度を揃えたことで、Claudeが一度に応答できる範囲が広がりました。

なお本記事も、社内の実装内容をこの /ask-lakehouse で確認しながら執筆しています。

ラベルを運用しながら更新していく仕組み

本記事の構成は、2026年7月時点の実装内容です。
完成形ではなく、運用しながら育てている途中の状態を公開しています。

とくにラベルの設計は、業務の変化とともに更新が必要になります。
案件の種別が増えれば新しいラベル項目を追加し、使われないラベルは統合または削除します。
ラベルを付ける対象の5系統も、いまはこの区切りで運用していますが、実際の呼び出しパターンを見ながら増減していく想定です。

この更新も勘に頼らないための仕組みも入れています。
/ask-lakehouse が質問に答えるたびに、その質問と、どんなラベルがあれば一度で答えられたかを1件ずつ記録しています。
記録は日次の処理でまとめられ、ラベルの追加候補として一覧に並びます。
そして、その候補を人が確認して承認したものだけが、翌日以降のラベルに反映されます。
候補が自動でラベルに追加されることはありません。

結果として、使えば使うほど「いま足りていないラベル」が具体的に溜まっていく状態になっています。
実際に並んでいる候補には、受注に至った要因、商談がいまどちら側の対応を待っているか、その案件を事例として公開できる状態かといった項目が挙がっており、いずれも実際の業務の問いから出てきたものです。

Gold層の意思決定の抽出も、いまは半自動で抽出しています。
会議の議事録やSlackの議論から、どの発言を意思決定として拾うかの判断は、まだ人の手が入っています。ここは呼び出し頻度と精度を見ながら、自動化の割合を上げていく余地があります。

データ量が増えたり、外部連携先が広がったりして、Googleドライブで扱いきれなくなる場面が来る可能性はあります。
その時に専用基盤への移行を検討する選択肢は残しつつ、いまはGoogleドライブ上で動かして学ぶことを優先しています。
「小さく始めて動かしながら学ぶ」ためには、既存のツールで実装のスタートを切ることに実利があると考えています。

なお、本記事で構築の中心だと述べたラベル設計について、なぜそこが難所になるのか、どういう順番で考えるべきなのかは、構築者本人が別の記事で書いています。
あわせて「データレイクハウスを自分で作って分かった、AI-Ready化の本当の難所」もご覧ください。

構築者紹介

中前 秀太（Deflag CPO / CAO / CIO）

高専卒業後、筑波大学大学院を修了。コロプラでゲームプランナーとして新人賞を受賞したのち、MolaTectaを創業。ベーシックではPLG型SaaS事業の開発部長を務めたのち、Deflagに参画。プロダクト戦略・開発の推進、UX設計、データ分析領域を担当しています。

𝕏 X（Twitter） → https://x.com/nakamae__deflag
📝 note → https://note.com/nakamae_deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a