データ基盤をBigQueryへ移したニトリは、データが増えたことによって一部の人しか恩恵を受けられない状況に陥った。会話型AIで誰でも分析できる環境を目指したが、壁になったのは社内独自の項目名だった。打開策は地道な作業の徹底だった。
この記事は会員限定です。会員登録すると全てご覧いただけます。
データを集めれば、誰もが使えるようになる――。家具販売大手のニトリでは、その期待とは逆のことが起きた。「BigQuery」に集めたデータが膨らむほど、使いこなせる一部の社員だけが恩恵を受ける状況が強まったのだ。
データ基盤構築を担当した同社情報システム改革室の小林桂氏が、この状況をAIで打開しようとした過程を説明した。
本稿は、Google Cloudが主催したイベント「Google Cloud Next Tokyo 26」(開催日:2026年7月30〜31日)でニトリホールディングスの小林 桂(情報システム改革室)が「ニトリが実践するBigQuery分析基盤構築とデータ エージェントの最新活用」というテーマで講演した内容を編集部で再構成したものだ。
ニトリは2021年にデータ基盤刷新の検討を始め、2022年後半にシステムを稼働させた。稼働後も安定運用に向けた整備を続けるとともに、全社的な教育体系づくりや、統計分析とAI活用を担う専門チームの立ち上げといった組織面の施策も並行して進めている。
オンプレミスのデータベースをBigQueryへ移行したことで、システム管理の点では、データ容量の物理制限やインフラ管理の負担から解放された。加えて、一定の抽出技術を持つ一部の社員に対して、自由にデータ分析をできる環境を提供することもできた。
しかし、大量のデータを集約できる環境が整った結果、新たな問題が生じた。「大量のデータが蓄積され、主要なテーブルだけでも2600本程度にまで膨れ上がっている。これまで保存できなかったデータをためられるようになったのはよかったが、データが多過ぎて全容が把握できず、認知の限界ともいえる状況に陥った。その結果、一部の使いこなせる人だけが恩恵を受ける状況を助長してしまった」と小林氏は振り返る。
クラウド移行によるデータ集積環境の整備でインフラ面の制約は解消されたものの、集めたデータを組織全体でどう活用するかという課題が残された。
データ基盤のクラウド移行によって、運用時のコスト面でも課題が浮上した。特に問題となったのが、既存のBIツールとデータベースの相性だ。データ処理量に応じた従量課金制のデータベースに対し、BIツールが複雑なクエリを頻繁に発行し、予期せぬ課金が発生していた。さらに、BIツールのライセンス費用上昇も重なり、運用コストが膨らむ要因となっていた。
対策として、単純に別のBI製品へ乗り換えることは現実的ではなかった。小林氏は「製品を置き換えても総コストはそれほど変わらないことが分かっていた。むしろ、新しいツールの使い方を再教育するなど、やり直しの手間がかかり、入れ替えをする必要性はないという結論に達した」と語る。
そこで情報システム部門はアプローチを変えることにした。従来のBIツールの機能を改めて確認し、単純なデータの可視化に使う「参照機能」と、深い分析のための「探索機能」の2つに分離して再構築する考え方だ。そうすることで、無駄な分析クエリが飛び交うことによるコストを抑え、かつエキスパートには最新の機能を使わせる環境を構築した。
まず参照機能は、事業部門の会議で基礎資料として使う定型レポートやダッシュボードなど、決まった形式の表示を担う。この機能については、BIツールの無駄な内部処理をそぎ落とし、必要な表示機能だけを備えた画面を内製した。
「AIによるコードアシスト技術を活用したことで、短期間で運用を開始できた。既存のBIを置き換えるのではなく、必要な機能だけを新規に薄く作ることにした。会議では、商品開発者の目線に合わせた見せ方が必要な一方、操作はワンパターンにしたいという要求があり、シンプルな操作性を追求した」(小林氏)
もう一方の探索機能では、データのドリルダウンや条件変更といった本格的な分析を、いかに簡単に実現するかが課題だった。
「従来のBIツールでは、探索操作のライセンスが高額で全社配布が難しかったことに加え、操作習得やSQL知識が要求されるため、実際の利用者が限定されていた。今回は、自然言語によってデータを抽出する会話型分析の技術を採用し、コスト削減と同時に、誰でもデータ分析ができる環境を両立させることに挑戦した」(小林氏)
開発チームは、会話型分析による探索機能の実現のため、AIを活用したシステムを検討した。小林氏は、「データ分析の質を向上させるのであれば、ほしいデータを取得する過程はAIに任せるべきだ。そのうえで、AIが抽出した結果を分析し、仮説検証することが人の役割であり、そこに時間をかけなければいけない」と話す。
開発に際して、情報システム部門はまず、現場の販売実績報告会議などにおける質疑応答を調査した。その結果、求められているのは「この商品の前月の売り上げはいくらか」といった一問一答形式の簡潔な回答だということが分かった。質問自体はシンプルだが、短い単語や直感的な表現で発せられるため、システム側には、言葉に表れない質問の意図や社内の専門用語を正しく解釈し、適切なデータを返すことが求められた。
しかし、探索機能のための会話型分析の実現は簡単には進まなかった。既存のBIツールのAI機能や標準的な対話型のAPIを使うだけでは、満足に動作するものを作ることができなかったと、小林氏は言う。
大きな問題だったのが、ニトリ社内のデータベースに保存されているデータの項目名が独自のルールで付けられていたことだった。蓄積された約2600本のテーブルやカラムの命名構造が、AIが理解できるルールで作られていなかったため、狙い通りの回答が得られなかったのだ。
例えば、製品管理のデータベースにある「DELVTO_CRP_KBN」というカラム(項目名)は、「納品先会社区分」を意味する。「英文と、日本語表記をアルファベットにした文字列を組み合わせたような独自の命名ルールで作られた表題を、AIは理解できない。個々の項目が何を意味するのか、背景の説明がなかったため、必要なデータを抽出できなかった」(小林氏)
この課題を解決するため、開発チームは、テーブルやカラムのプロパティ欄にデータの意味や文脈をできる限り細かく記述して、再整備する作業を進めた。データ単体の定義に加え、社内用語集を活用して社内用語を整理し、テーブルやカラムとひも付けた。さらに、テーブル間の関係性やサンプルクエリなどは、AIエージェントを活用して管理する構成を採用した。
この構成により、プログラムロジックとデータ定義の分離が可能となった。小林氏は、「BigQueryエージェントは複数作ることができる。オールマイティーに何にでも対応できる大きなものを作るより、個々の分析用途に特化した小さなエージェントを複数作る方が、タイムアウトの問題を回避できる」と補足する。
社内データの意味付けを実施したことで副次的な効果も生まれた。自然言語によるデータ構造の解説が付いたことで、新任管理者がデータ構造を学ぶ際の資料としても活用できるようになり、既存環境を調査する際の負担も軽減した。
加えて、複雑なデータ加工処理(ETL処理)も、個別データの内容説明が追加されたことで効率化した。既存の処理手順を、Googleの生成AI「Gemini」にプロンプトとして入力すると、その指示内容を基に対象データを抽出、自動で変換し、BigQueryに取り込めるようになった。
小林氏は、「今回のデータ分析基盤再構築で中心となった取り組みは、データに対する文脈(説明情報)を書き加えるという基本的な作業だった。この一つのアクションを徹底したことにより、組織内のデータ活用が、さまざまな面で改善した」と語る。
第1の効果は、現場におけるデータ抽出作業の省力化だ。技術知識を持たないユーザーも、会話型インタフェースで必要なデータを取得できるようになり、抽出にかかっていた時間を本来のデータ分析や仮説検証へ充てることが可能となったことだ。
第2の効果は、システム全容の可視化と担当者の育成促進だ。一部の熟練担当者の頭の中にしか存在しなかったデータ構造の意味や定義がテキスト化されたことで、全容の把握が容易となった。異動してきたばかりの管理者も早期に環境を理解し、自立運用できる基盤が整った。
第3の効果は、将来のシステム拡張を見据えたAI駆動開発への備えだ。大規模な既存システムを改修するためには、プログラムだけでなく、データの構造や意味の理解が欠かせない。データの説明情報を整備したことで、将来AIによるコード生成や改修支援をする際の準備も整った。
「当社はこのデータ整備を、システムをレガシー化させないための施策と位置付けている。レガシー化の原因は、技術の風化ではなく、システムの持つ意味や構造が誰にも分からなくなってしまうことだと考えている」(小林氏)
大量の社内データの整備は、途方もない作業のように思える。だが小林氏は、全てのテーブルやカラムに対して完璧に実施する必要はないと話す。
「利用頻度の高い、重要なものを第1位から第5位くらいまで整備するだけで、十分な効果が得られるはずだ。また、この作業には特別な技術を必要とせず、誰でも着手できる。地道な作業を根気よく積み重ねることが、データ分析基盤の実効性を高める鍵だと思う」と締めくくった。
Copyright © ITmedia, Inc. All Rights Reserved.