企業のAI活用は、「使われていない情報」こそが価値──MSでのグローバル開発経験を持つフライウィールCTO・波村氏が指摘する、日本企業が抱えるデータ整備の課題

波村AIそのものの性能が問題なのではありません。多くの企業で、AIに渡す前提の情報が“整っていない”ことが問題なんです。

波村ここでいう“整っていない情報”とは、たとえば次のようなものを指します。「部門ごとに分散するExcel」「更新頻度の低い共有ドキュメント」「検索が困難なチャット履歴」」など──。

これらの情報は、社内に存在こそしていても、「どこにどんな状態で存在しているのか」が可視化されていないために、必要なときに必要な情報を呼び出すことができなくなっているんです。

つまり、「情報は“ある”が、“使えない”」ということですね。

波村“情報を検索して取り出す部分”と、“AIが推論して答えを出す部分”。その“あいだ”を設計できていない企業が、実はものすごく多いんです。

波村先の記事でもお伝えしましたが、日本企業の中でもエンタープライズになると、数百におよぶデータベースが社内に点在しているケースもしばしば見受けられます。たとえば、あるメーカーでは300以上のデータベースが存在しており、こうした統合プロジェクトは多くの企業で試みられてきましたが、技術的・組織的な困難から、想定した成果が出ないケースも少なくありません。

波村企業内で活用しているシステムが多様であればあるほど、すべてのデータを一つの環境に統合すること自体が困難なんです。なぜなら、データ自体を無理に統合しようとすれば、コストはもちろんのこと、そのデータの破綻リスクも背負ってしまうからです。

そこで僕らは、各データベースは“そのまま”に、仮想的な索引・インデックスを付与するアプローチを採用しました。

企業内で、ある人が「自社の◯◯を知りたい」と思ったときに、インデックスを通じて関連するデータがどこにあるのか推定し、必要な情報を的確に抽出・提示する──。この、情報を壊さずそのままの形で整える仕組みが、多くの日本企業のAI・データ活用を動かす肝、“AI時代のデータ基盤”になると確信しています。

波村裏側ではどんなことが起きているかというと──。

たとえば、ある企業で「小売業における顧客の売上がどのように推移しているのか」を知りたいとします。ですが、社内には部門ごとに異なるデータベース（DB）が存在しており、データの保存形式や取得方法も統一されていない。そのため、データを横断的に取得する際には、ユーザーが自然言語で入力したリクエストを、システムが自動でSQLクエリ*やAPIコール*などの適切なアクセス手段に変換し、必要な情報にたどり着けるよう設計しています。

*データベースから情報を取り出すための特別な命令文

*アプリケーション同士をつなぐインターフェースに、データ要求する操作

そうして必要なデータを取り出し、さらにデータ同士を組み合わせて、ユーザーが理解して活用できる情報（グラフやマップなどのUI）に整えてアウトプットしているんです。

波村一昔前の技術では、たとえば「小売業における顧客の売上がどのように推移しているのか」を知りたくても、システム側がユーザーからの“検索”や“リクエスト”を正しく理解すること自体が技術的に難しかったんです。もちろん、まったくできなかったわけではありませんが、ここまで精度高く理解できるようになったのは、ChatGPTのような大規模言語モデル（LLM）が登場してから。

強力な検索技術とデータ処理能力、加えてLLMに軸をおいた生成AIを駆使して情報を変換し、企業情報に精通した専属データアナリストのように価値ある情報を抽出して見える化する──これは従来の検索よりもさらに“一段上のレベルの技術”だと自負しています。

波村実は、どの情報を、どの文脈で、どの粒度で引き出せるか──という検索体験を意識して設計する発想は、Microsoft時代から磨いてきたものでした。

フライウィールのデータ基盤ソリューションは、今でこそ国内では珍しいアプローチになったと思っていますが、構想を描きはじめた当初から、「これが実装できれば、企業現場に大きなインパクトを与えられるはずだ」という確信はありましたね。

ただ、そうは言ってもChatGPTが登場するまでは実現方法が見えていなかった。なので、ChatGPTが出てきたことでゲームのルールが変わり、私も構想を具現化する上で一気に流れが向いてきたなと感じています。

とはいえ、ChatGPT以前の時代には、その実装手段がなかなか見えてこなかった。生成AIの進化によって「検索と推論のあいだ」を埋める技術が現実味を帯び、ようやく実現への道筋が開けたんです。

波村2000年代前半当時、まだ世の中に出ていなかった C#というプログラミング言語の開発から私のキャリアが始まりました。ところが、いざ現場に入ると仕様書が存在しておらず、「とにかく書け」と指示がくるんです……（笑）。仕様を議論するよりも、動くものをはやく作るという文化で、当時は時間を忘れて開発に没頭し、ソースコードを更新し続けるような世界でしたね。

また、当時のビル・ゲイツには「Think Week（シンク・ウィーク）」という習慣があって、年に2回ほど1人でどこかにこもり、200万枚くらいの提案書を読む時間を設けていたんです。

波村その提案書は、社員なら誰でも応募することができたので、僕も応募してみました。たしか最終選考前まで進んだ覚えがあります。

当時提案した内容は、AIを使ったテストの自動化に関するものでした。AIによる自動化は今でこそ注目されている分野ですが、2000年代の当時では誰も取り組んでいなかったと思います。時代を少し先取りしすぎましたね。

波村C#やTypeScript（タイプスクリプト）などのプログラミング言語をつくったことで有名な世界的な言語デザイナー、アンダース・ヘルスバーグ氏が率いるデザインチームに入ることができたことは、大きな財産となっています。

2000年代初期の開発環境であるTurbo Pascal（ターボパスカル）*やDelphi（デルファイ）*などもつくっていたデンマーク出身のエンジニアなのですが、週に2回ほど、彼がどうやって新しいアイデアを形にしていくのかを間近で学ぶ機会がありました。彼はビル・ゲイツ氏にプレゼンをしたこともあるような人（ビル・ゲイツに直に提案できるのは、優秀なアーキテクトや世界的な有名人などの一握りだった）で、アイデアの研ぎ澄まし方が素晴らしかった。

*1980年代〜90年代前半に流行した、プログラミング言語「Pascal」の開発環境

*Turbo Pascalをさらに進化させて、「Windowsアプリケーション」をビジュアルで素早く作れるようにした開発環境

波村まず「これは他の技術でも再現できるか？」と我々に問いながら、ひたすらシンプルな形に削ぎ落としていくんです。「このソリューションでしか表現できない言葉まで具体化せよ」「他の手段で代用できるようなら、そのアイデアは本質ではない」といった考え方です。

チーム全員がその美学のもとで開発を進めるんですが、今思えばなかなかストイックでした。アイデアを持っていってプレゼンしては、手厳しいフィードバックを受けるんです。極端な話、彼にスライドを映した時点で「スライドはいらない。今目の前のホワイトボードに自分の言葉で書いてみろ。その言語化ができないなら、帰ってくれ」とバッサリ切られるような環境でした。ですが、そこでの経験や考え方があったからこそ、今の挑戦があることは間違いありません。

たとえば「AIでデータをどうやって活用するのか？」というテーマでも、「このやり方でしかできないのか？」「他社や他の技術でもカバーできるのではないか？」と、とことん考えて研ぎ澄ましていきました。その結果、Gmailの検索やGoogle Driveの検索、SharePointの検索など従来の検索サービスではカバーしきれなかった『Conata®』を生み出すことができたんです。

波村従来の国内開発現場では、エンジニアが上流で決められた仕様を受け取り、実装に専念する役割にとどまりやすい傾向がありました。

でも、本来エンジニアは「コードを書く」ことだけが役割じゃないはずです。現場の業務構造を読み解き、ゴールに向かって“どう設計すべきか”を考え抜く存在であるべきだと思っています。

波村「データを整理したい」とか「データ活用を進めたい」というのは、あくまで出発点にすぎません。真に問われるのは、“データを活かして自社をどう変革したいのか”というビジョンではないでしょうか。

つまり、情報を整えること自体が目的ではなく、そのビジョンを実現するための設計が求められているんです。

波村私たちフライウィールが目指しているのは、“情報を探すこと”に時間を奪われるのではなく、“意味のある行動”に時間を使える状態をつくることです。

企業内に散らばる膨大なデータソースから、業務目的に沿った情報だけを横断的に探索し、わかりやすく提示してくれる。この構想を現実に変えるために開発されたのが、先にも挙げた『Conata Data Agent』となるわけです。

波村AIは情報が整っていないと、正しく機能できません。だからこそ、まずは“情報が業務に沿って引き出せる状態”をつくる。それができて初めて、AIも、人間の意思決定も、正しく動き出していくんですよね。