AIのリスクは、AIの中にはない

以前在籍していた開発会社で、OLAPツールの開発に携わっていたことがある。OLAPとは、データを複数の軸で自在に切り替えながら分析する仕組みだ。売上を時間軸で見る。地域別に見る。商品カテゴリで切る。それらを掛け合わせて、どの地域のどの時期にどの商品が動いたかを瞬時に把握する。経営判断のための道具であり、私たちはその力を信じてツールを作り、クライアントに提案していた。

だが提案の場には、必ずぶつかる壁があった。デモンストレーションで多次元分析の画面を見せ、軸の切り替えがいかに速いか、集計の柔軟性がいかに高いかを説明する。クライアントは感心した顔で頷く。そして最後にこう言う。「面白いですね。でもそれ、Excelのピボットテーブルでもできますよね？」。この一言で、場の温度が二度ほど下がるのを何度経験したかわからない。

技術的には明確な差がある。OLAPはデータを事前に構造化し、数千万件の規模でも瞬時に集計軸を切り替えられる。ピボットテーブルでは重くて止まるような分析が、ストレスなく回る。だがクライアントの手元にあるのは、たいてい数万行のExcelファイルだ。その規模ならピボットテーブルで十分に事足りる。ツールの性能差は、データの規模が一定を超えて初めて意味を持つ。そしてその規模に達している中小企業は、現実にはそう多くなかった。OLAPが真価を発揮するのは、数百万件、数千万件のデータを複数の軸で高速に回転させるときだ。だがそんなデータ量を持つ会社はそもそも分析基盤への投資も進んでいる。本当にOLAPを必要としている会社には売れるが、本当に必要かどうか微妙な会社にも売ろうとしていた——あの頃のIT業界には、そういう構造的な無理があった。

IT業界にはプロダクトアウトの体質がある。技術的に実現できることを形にし、それを必要としているはずだと信じて市場に出す。私たち自身がそうだった。作る側はツールの可能性に目が向く。だが使う側が見ているのは、今日の業務を今日のうちに終わらせること——その一点だ。この温度差を何十回もの提案の中で味わいながら、ひとつだけ確信を持つようになったことがある。ツールの性能は、入力されるデータの質を超えない。どれほど優れた分析エンジンも、コード体系がバラバラで入力ルールが統一されず欠損だらけのデータの前では無力だ。

数百万件のデータを「使える形」にする仕事

ツールを作る側にいた私が、やがてデータを扱う側に回った。全国にチェーン店を展開する会社に在籍していたとき、CRM——顧客関係管理の一環として、数百万件のDMデータの整理を担当した。BtoCのダイレクトメール営業だ。

データは存在していた。だが「使える状態」にはなかった。同一の顧客が異なる表記で複数登録されている。「株式会社」と「(株)」が混在し、同じ会社なのに別の顧客として二重にカウントされている。引っ越して住所が変わっているのに更新されていない。購買履歴が店舗ごとに別々のフォーマットで管理されていて突合できない。名前の漢字が旧字体と新字体で揺れている。電話番号にハイフンが入っているものと入っていないものが混在し、名寄せの障害になる。こうしたデータを一件ずつ確認し、統合し、欠落を補い、重複を除去する。華やかなところは何もない。地味で、膨大で、誰からも褒められない仕事だった。だがこの工程を飛ばしたままツールを入れている会社を、開発会社にいた頃に何社も見てきた。だから私には、この作業の意味がわかっていた。

整理されたデータにツールを通せば、どの地域のどの年代がどの商品に反応しているかが見えてくる。反応率の高いセグメントにDMを集中させれば、発送数を減らしても成果は上がる。だが整理されていないデータに同じツールを通せば、ノイズまみれの数字が返ってくるだけだ。ツールは忠実に動く。入力されたものをそのまま処理する。ゴミを入れれば、ゴミが出てくる。

後年、BtoBの事業会社でも顧客データの整理に携わった。業種が変わっても構造は同じだった。取引先のデータが部署ごとにバラバラに管理され、同じ会社に別の営業が別のアプローチをかけている。名寄せもされていない。ある取引先が三つの部署にそれぞれ別の名前で登録されており、三人の営業が同時期に別々の提案を持ち込んでいた——という笑えない話もあった。CRMツールを導入したが、使いこなせている社員はごく一部で、大半にとっては「高い名簿管理ソフト」でしかなかった。ツールの機能は豊富だった。顧客の接触履歴を記録し、商談のステージを可視化し、受注確度を自動でスコアリングする。だがそのすべてが、正確なデータの入力を前提としていた。ツールの価値はデータの質に従属する。これは開発会社で学んだことの、使う側からの追体験だった。

名前が変わるだけで、同じことが繰り返される

2011年頃から、「ビッグデータ」という言葉がIT業界を席巻した。データが多ければ多いほど勝てる。Hadoopを導入すれば自動的にイノベーションが起きる。当時の私はすでにOLAPとCRMの両方を経験していたから、この熱狂を冷めた目で見ていた。データの量は本質ではない。整理されていない大量のデータは、整理されていない少量のデータよりも始末が悪いだけだ。

案の定、大量のデータを蓄積したはいいが分析できる人材がおらず、「データレイク」と名付けたはずの貯蔵庫がいつの間にか「データスワンプ（沼）」に変わった——そんな話が業界のあちこちから聞こえてきた。データサイエンティストを採用すれば解決する、という安直な期待もあった。だがデータサイエンティストが力を発揮するには、分析に耐えうる品質のデータが必要だ。入力ルールが統一されておらず、コード体系が部署ごとに異なり、欠損値が放置されたデータを渡されても、彼らにできることは限られている。ツールは動いている。サーバーは回っている。だがデータの質を誰も管理しておらず、使う側もデータから何を読み取りたいのかが定まっていない。OLAPのときと同じだ。CRMのときと同じだ。ツールの名前だけが新しくなる。

そして今、AIだ。ChatGPTがすごい。生成AIで業務効率化。AIエージェントが自律的に判断する。技術の進化は本物だ。だがツールを作る側にいた人間から見れば、構造は何ひとつ変わっていない。ツールの性能がどれだけ上がっても、入力するデータの質が追いつかなければ、出力の質は上がらない。

前回のコラムで紹介したAI事業者ガイドラインは、AI利用に伴うリスクとして、誤った情報の生成、差別やバイアスの再生産、個人情報の漏洩、過度な依存といった問題を挙げている。ニュースでも繰り返し報じられているから、聞き覚えはあるだろう。AIが嘘をつく。AIが差別する。AIが機密を漏らす。こう書き並べると、AIという新しい技術が新しいリスクを生み出しているように見える。

だがOLAPもCRMもビッグデータも作る側にいた人間として言わせてほしい。これらは「AIのリスク」ではない。正確に言えば、AIの中にあるリスクではない。

誤った情報が出てくるのは、入力が曖昧だからだ。「売上を上げるには」と漠然と聞けば、漠然とした答えが返る。OLAPに「なんかいい分析をして」と言うのと同じことだ。差別的な出力は学習データの偏りが一因だが、その出力を検証もせずに意思決定に使う側の問題でもある。偏ったCRMデータで分析すれば結果も偏る——これはAI以前からずっと同じ構造だ。機密情報の漏洩に至っては、入力してはいけないデータを入力した、それだけの話だ。ツールの欠陥ではない。データ管理の不在だ。

そしてAIへの過度な依存。出力の質を自分で評価できなくなることの帰結だ。OLAPの分析結果をそのまま報告書に貼り付け、数字の意味を自分の頭で考えることをやめた管理職を、私は何人も見てきた。グラフが綺麗に出力されれば、それだけで分析が完了したかのように錯覚する。だがグラフの背後にある前提——集計期間、サンプルの偏り、外れ値の処理——を確認しなければ、その数字は嘘をつく。ツールが出した答えが正しいかどうかを判断できるのは、ツールではなく人間だ。AIでもそれは変わらない。

土が死んでいれば、種の品種は関係ない

農業に喩えてみる。画期的な新品種の種を手に入れた。収量は従来品種の倍。病害虫にも強い。だが畑に出てみたら、土壌は痩せ、石だらけで、排水も悪い。何年も手入れされず、雑草の根が土の中で絡み合っている。この状態で種の品種を議論しても仕方がない。「この新品種は遺伝子組み換えで危険かもしれない」と騒ぐ前に、まず畑を耕せ。土が死んでいれば、どんな優秀な種を蒔いても育たない。話はそれからだ。

AIも同じだ。ChatGPTの性能は日々進化していく。だが入力するデータが整理されていなければ、出てくるものもそれなりにしかならない。ガイドラインが警告するリスクの多くは、種の品種の問題ではない。土壌——つまり、自社が扱っているデータの質と、それを扱う人間の理解の問題だ。

ガイドラインのリスク一覧を見て、「AIは怖い」と感じた人がいるかもしれない。だがリスクの大半は、AIの中にはない。AIに何を入力し、出力をどう使うか。リスクはいつも人間の側にある。OLAPの時代も、CRMの時代も、ビッグデータの時代も、そうだった。ツールの名前が変わるたびに新しいリスクが語られるが、壊れる場所はいつも同じだ。入力と、理解。この二つが欠けたまま、ツールだけが新しくなっていく。

次回は、そのリスクの中でも最も身近な話——情報漏洩とセキュリティの問題を取り上げる。かつてWinnyで日本中が騒然となった時代を覚えている人には、既視感のある話になるはずだ。