AIで作れるとは。「動く」と「使える」の大きな差

DeflagでCROをしている岩瀬です。

先日、あるお客様との打ち合わせで、こう聞かれた。

「AIでデータ基盤って、もう作れるんですよね？」

聞けば、APIやMCPでいろんなツールをつないでしまえば、散らばったデータをAIが勝手に整理して、名寄せして、統合してくれる。設計や要件定義だって、AIに任せられる。そういう話をどこかで聞いたのだと言う。

私はその場で、少しだけ言葉を濁した。

「……一定は、できると思います。ただ」

この「ただ」の続きを、その打ち合わせではうまく言い切れなかった。
帰り道でずっと、あの濁りの正体は何だったんだろう、と考えていた。

今日は、その濁りを言葉にしてみたいと思う。

まず認めたい。AIは「作る作業」を、確かにやれる

最初に、お客様の言っていたことを頭ごなしに否定はしない。

むしろ、かなりの部分は本当だと思っている。

APIやMCPを前提にすれば、あちこちのツールに散らばったデータをAIがつなぎにいく。
列の意味を推測して名寄せの候補を出す。テーブルの設計案や、要件定義のたたき台を書く。
こういう「作業」は、実際にAIがやれるようになってきた。

数年前なら、専門のエンジニアが何週間もかけていたことが、指示ひとつで下書きまで出てくる。これは素直にすごいことだと思う。「AIでデータ基盤を作れる」という言葉は、この部分だけを見れば、確かに嘘ではない。

だから私は「できない」とは言わなかった。

言えなかったのは、その先だ。

でも、現場で見た景色は少し違った

実際に手を動かした現場で、私が何度か見た景色がある。

一言でいうと、こうだ。

動きは、確かだった。でも、アウトプットが正しくなかった。

処理はきれいに走る。エラーも出ない。AIはちゃんと指示通りに、データをつないで、整形して、それらしい結果を返してくる。画面の上では、何も問題が起きていないように見える。

ところが、出てきた中身をよく見ると、業務的に意味がずれている。
つなぎ方は合っているのに、つないだ結果が「現場の実態」とは違うものになっている。

具体を少しぼかして言うと、こういうことが起きる。

ある会社の情報が、片方の台帳では正式名称で、もう片方では略称や旧社名で入っている。
人間なら「これ、同じ会社だよね」と一目で分かる。
でもAIは、表記が違えば別のものとして扱うか、
逆に似ているというだけで本来別の会社を一つにまとめてしまう。
処理としては何も間違っていない。指示通りに、忠実に、名寄せをしている。
ただ、その結果が現場の実感と食い違う。

厄介なのは、これが「壊れた形」では出てこないことだ。
エラーで止まってくれれば、まだ気づける。
でもAIのアウトプットは、たいてい「それらしく整った形」で出てくる。
整っているから、正しいように見えてしまう。よく見ないと、ずれに気づけない。

「動く」と「正しい」は、違う。
そして、正しくないものは、結局のところ現場では「使えない」。

ここが、あの日私が濁した「ただ」の正体だった。AIがやってくれるのは「動かすこと」であって、「正しいこと」を保証してくれるわけではない。
動いたからといって、正しいとは限らない。
むしろ、きれいに動いてしまうぶん、ずれていることに気づきにくい。
そして、正しくないデータの上でどれだけAIを動かしても、その示唆は業務で使えるものにならない。

技術的に動くかどうかと、業務的に正しく使えるかどうかは、別のレイヤーの話なのだと思う。

話が噛み合わない理由は、二つの話が混ざっているから

なぜこの手の会話は噛み合いにくいのか。

自分の中で整理していくと、「AIでデータ基盤を作れる」という一言に、
本当は二つの別々の話が混ざっているからだ、と気づいた。

一つは、実装の話。
つなぐ、整理する、名寄せする、設計の下書きをする——いわば「作る作業」の話だ。

もう一つは、データの話。
出来上がった基盤の中身が、業務として「正しいか」どうかの話だ。

この二つを分けずに一緒くたにするから、「できる」「いや難しい」がすれ違う。
分けてみると、立ち位置はわりとはっきりする。

• 実装の話（作る作業）は、AIで一定「動く」。ここは、これからどんどん進む。

• データの話（中身の正しさ）は、動くこととは別問題で、今のところ人の確認が外せない。

お客様が見ていたのは前者で、私が濁ったのは後者だった。
同じ「データ基盤」という言葉を使いながら、指しているレイヤーが違っていたわけだ。

この二つがなぜ混ざりやすいかというと、前者の進歩が目に見えて速いからだと思う。
作る作業がどんどん自動化されていくのを見ていると、「じゃあ中身の正しさも、そのうちAIが担保してくれるだろう」と地続きに考えたくなる。
でも、私の実感では、この二つは地続きではなく、別々の階段だった。
作る作業の階段を何段のぼっても、中身を正しくする階段が自動でのぼれるわけではない。

中身の「正しさ」に、何が要るのか

では、後者——中身の正しさには、具体的に何が要るのか。

ここは私の個人的な思いつきではなく、Deflagとして整理している見解とも重なる。少しだけ、その中身を紹介したい。

AIがデータを使って「正しく」示唆を出すためには、データを一箇所に集めるだけでは足りない。少なくとも、次の三つが要る。

一つ目は、整備されたデータそのもの。
品質と鮮度が担保されていて、信頼して参照できる状態になっていること。ゴミが混じったまま統合しても、AIはそのゴミごと、それらしく処理してしまう。

二つ目は、コンテキスト。
業務用語や指標の定義だ。社内の資料では、こんな言い方をしている——「AIの分析は嘘をつく」。たとえば「売上を分析して」と頼んでも、AIはそれを商談実績から数えればいいのか、支払い履歴から数えればいいのか、自分では判断できない。人間なら暗黙に共有している「うちの言葉の意味」を渡しておかないと、動いても正しくならない。

三つ目は、ガードレール。どのデータをAIに読ませてよくて、どこから先は読ませてはいけないのか。参照範囲や権限をどう制御するのか。これを支えるのがガバナンスとセキュリティの考え方で、外せない。

このあたりが、あの日私が言いかけて飲み込んだ「ただ」の中身だった。整備されたデータ、うちの言葉の定義、そして読ませてよい範囲の線引き。この三つは、少なくとも今は、人が関わって確かめる工程が要る。

だから私は「AIで作れますよ」とは言い切れなかったし、逆に「まだ無理です」とも言いたくなかった。作る作業は進む。でも、中身を正しくする工程は、まだ人の手が要る。そういう、少しだけ歯切れの悪い立ち位置なのだと思う。

とはいえ、線は動いていく

ここまで書いておいて、最後にひっくり返すようだが。

「人の確認が要る」と言い切ってしまうのも、私は少し違うと感じている。

というのも、何がどこまでAIに任せられて、どこからが人の仕事として残るのか——その線は、正直なところ、試してみないと分からないからだ。
去年できなかったことが、今年は普通にできている。そういう場面を、この一年でいくつも見てきた。

だから私が持っていたい構えは、二つを同時に、というものだ。

懐疑と、実験を、同時に持つ。

「AIで全部できる」と決めつけて丸投げもしないし、「どうせ人がやるしかない」と決めつけて試すことをやめもしない。できると決めつけず、できないとも決めつけず、その線を自分の手で確かめにいく。小さく試して、動いた結果が正しいかを人の目で見て、任せられる範囲を少しずつ広げていく。

具体的には、いきなり全社のデータで壮大な基盤を組もうとしないことだと思う。
まずは一つの業務、一つのデータの塊で試す。
AIにつながせて、整えさせて、出てきたものを人が見る。
そこで「動いたけど、ここは正しくなかった」というズレを一つずつ拾っていく。そのズレこそが、自社にとって「どこに人の確認を挟むべきか」を教えてくれる地図になる。
最初から完璧な線を引こうとするより、ズレを拾いながら線を描いていくほうが、結局は早い。

この進め方は地味だ。一気に自動化される華やかさはない。
でも、動いてしまうものを疑いながら、任せられる範囲を実測していく
——この地道さが、いまAIとデータを扱ううえでいちばん効くのだと感じている。

矛盾しているようだが、この矛盾を抱えたまま進むのが、今のいちばん現実的な構えなのだと思う。

おわりに

あの打ち合わせで私が濁した「ただ」を、ここまでで少しは言葉にできた気がする。

AIでデータ基盤は作れる。でも、「動く」と「使える」は違う。
作る作業は任せられても、中身を正しくして「使える」状態にする工程には、まだ人の確認が要る。そしてその線は、試しながら動いていく。

たぶん、この記事を読んで一番リアルに響くのは、実際に自社のデータと格闘している方だと思う。そういう方の頭の中では、きっと今、こんな問いが動き始めているのではないだろうか。

——なるほど。で、うちの場合、どこに人の確認を挟めばいいんだろう。

その問いが浮かんだなら、この記事はちゃんと役目を果たせたのだと思う。
答えは、会社ごとに、データごとに違う。
だからここで一般解を書くよりも、その問いを持って現場のデータを見に行くほうが、きっと早い。

もし、その線引きを一緒に考えてみたいと思う場面があれば、いつか一度、お話ししてみたい。