データレイクハウスを自分で作って分かった、AI-Ready化の本当の難所

前に、散らかった会社の情報をAIが読める形に束ねた話を書きました。
「あの案件、どうなってたっけ」を探す時間を消すために、会社の情報をまるごと一つの土台にした話です。

関連記事：散らかった会社の情報を、AIが「Deflagのやり方」で考える土台にした話

今回は、その続きです。どう作ったかを詳細に書きました。

先に結論を言うと、一番大変だったのは技術ではありませんでした。
データを「AI-Ready」つまり、AIが使える状態にする作業の本丸は、もっと地味なところにありました。

なぜ「倉庫」でも「湖」でもなく、レイクハウスなのか

まず、言葉の整理を少しだけ。

会社のデータをAIに使わせようとすると、置き場所の選択肢が大きく3つ出てきます。

一つは、データウェアハウス（DWH）。
売上や顧客数のような、きれいに表になった数字を貯める場所です。
整っているけれど、議事録や提案書のような「文章」はそのままでは入りません。

もう一つが、データレイク。
とにかく何でも貯める場所です。文章も画像も入るけれど、貯めるだけなので、そのままではAIも人も使いこなせません。

私たちが作ったのは、その間の子であるデータレイクハウスでした。
数字（顧客管理や財務）も、文章（Drive・Notion・Slack）も、同じ一つの場所に束ねて、しかも「使える形」にしておく。
倉庫の整い方と、湖の何でも入る広さを、一つにしたものです。

なぜこれを選んだか。
うちの場合、知りたいことの答えが、いつも数字と文章の両方にまたがっていたからです。
「あの案件、いくらで、どう決まったか」を知りたいときに、金額は顧客管理に、決めた背景はSlackに、資料はDriveにある。
数字だけでも、文章だけでも、答えになりません。全部がつながっている場所が要る。だから、レイクハウスでした。

仕組みは、3つの層を積むだけ

作りの骨格は、そんなに複雑ではありません。情報を3つの層で積んでいます。
「メダリオン」と呼ばれる、データを段階的にきれいにしていく型を、文章のような「かたちの決まっていないデータ」にも当てはめたものです。

1つ目は、原本の層。
会社の元ファイルをそのまま置きます。一切書き換えません。

2つ目は、ラベルの層。
1つのファイルにつき1枚、AI用の「ラベル」を作ります。何が書いてあるか、どの顧客のどの案件か、今どの段階か。

3つ目は、知識の層。
ラベルを束ねて、横断の知識にします。案件ごとの決定の時系列、勝ってきた提案の共通点。

この3層の話は前の記事に書いたので、ここでは要点だけにします。
大事なのは、元ファイルには一切触っていないこと。散らかったものを片づけたのではなく、AI用の地図を別に一枚、上から重ねただけです。

そして、時間を一番溶かしたのは、この真ん中の「ラベル」でした。

本当の難所は「ラベルの設計」だった

AIにファイルの中身を読ませて、要約させて、適切なラベルを貼らせる。
言葉にすると一行ですが、これがなかなか決まりません。

最初は、ありきたりなラベルを貼っていました。
「これは誰の・どの案件の資料か」「提案書か、議事録か、契約書か」「今も生きている情報か、古いか」。資料を整理するなら、まあこんなものだろうという感じです。

ところが、いざAIに質問を投げると、答えられないことが次々と出てきました。

たとえば「うちが勝ってきた提案の共通点は？」。
これに答えるには、そのファイルに意思決定が含まれているか、案件がどの段階（提案・契約・納品）にあるかが分かっていないと、拾えません。
最初のラベルには、その軸が付与されていませんでした。

最初のラベルだけで「勝ちパターンは？」と聞くと、AIは提案書を種類でかき集めて、「提案書が何件あります」くらいの、当たり障りのない答えを返してきました。間違ってはいないけれど、何の役にも立たない。

なので、色々とラベルを考えて、足しました。
例えば、「意思決定を含むか」「案件のどのフェーズか」というラベル。
さらに「その案件は受注できたのか」も分かるようにしました。
すると、AIは「受注まで進んで、そこに意思決定が残っている案件」だけを拾って、そこから共通点を並べられるようになりました。
元々、当たり障りのなかった答えが、使えるものに変わっていった瞬間です。

「あれが足りない、これが足りない」を、何度も繰り返しました。
ラベルは、一度では決まりません。作っては質問を投げ、答えの薄さに気づいて、また足す。その往復でした。

気づいたのは、ラベル設計＝「先に問いを決める」ことだった

繰り返しているうちに、順番が逆だと気づきました。

ラベルを先に決めて、あとから使い道を考えるのではない。先に「AIにどんな問いを投げたいか」を決めて、その問いに答えるために必要なラベルを逆算する。これが正しい順番でした。

「勝ちパターンを知りたい」なら、意思決定と結果のラベルが要る。
「この案件、今どうなっている」なら、フェーズと最終更新のラベルが要る。問いが先、ラベルが後。

これは、私にとって、ものすごく既視感のある作業でした。

私はずっとプロダクトを作ってきました。
プロダクト作りは、コンセプトやユーザーの要望という「問い」に近いものから始めて、それを具体の機能に落としていく仕事です。
「ユーザーは何を叶えたいのか」を先に定めて、そこから必要なものを逆算する。要件定義、と呼ばれる作業です。

AI-Ready化のラベル設計は、これとほとんど同じでした。
「AIに何を答えさせたいか」を先に定めて、そこから必要なメタデータを逆算する。データの要件定義、と言ってもいいかもしれません。

だからこの土台は、ツールを入れれば勝手にできあがるものではありませんでした。
事業を分かっていて、いい問いを立てられる人が真ん中にいないと、そもそも組み上がらない。

判断は、人間が握ったまま

もう一つ、設計で決めたことがあります。

AIが「これは意思決定っぽい」と拾ってきた情報を、そのまま確定にはしない。
あくまで候補として置いておき、人間が確認して初めて、正式な記録に昇格させる。

自動で拾うところまでは、AIの仕事。
でも「これは確かに、うちが決めたことだ」と認めるのは、人間の仕事にしてあります。前に、集めて気づくのはAI、決めて動くのは自分だと書きました。
ラベルの設計にも、同じ線を引いています。

AI-Ready化は、ツールより「問いを立てられる人」から

もし自社で同じことをやってみたいなら、順番はツールが先ではありません。

まず、会社のことと構造を分かっていて、「AIにこう聞きたい」という問いを持っている人。
その人がいれば、レイクハウスは小さく始められます。1つの案件、数十ファイルからでいい。

逆に、そこが空いたまま立派な基盤だけを作っても、返ってくるのは当たり障りのない答えばかりになります。
「AI-Ready」という言葉は、つい「データを全部AIに読ませれば準備完了」と聞こえます。
でも本当の準備は、その手前にありました。何を問うかを決めて、その問いにデータをそろえることです。

技術は、あとからついてきます。難所は、いつも問いのほうにありました。

deflagをもっと知りたい方へ

🌐 コーポレートサイト → https://deflag.net
𝕏 X（Twitter） → https://x.com/nakamae__deflag
📝 note → https://note.com/nakamae_deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a