はじめに

こんにちは！開発エンジニアのクリスです！

Google Cloud Next Tokyo 26 に参加してきました！今回は Day 1 のカスタマー セッション「ニトリが実践する BigQuery 分析基盤構築とデータ エージェントの最新活用」のレポートをお届けします。

「お、ねだん以上。」でおなじみのニトリが、長い年月をかけて BigQuery のデータ分析基盤を育ててきた軌跡と、データ エージェントを使った「SQL レスなデータ探索」という最新の挑戦まで語られるセッションです。データ活用の「定着」に悩む組織は多いと思いますので、その実践例を学べる貴重な機会でした！

セッション概要

タイトル：ニトリが実践する BigQuery 分析基盤構築とデータ エージェントの最新活用

登壇者：

  • 小林 桂 氏（株式会社ニトリホールディングス 情報システム改革室）

日時・会場：Day 1（7 月 30 日）15:00 – 15:30 / Room 4（セッション ID：D1-DA-04）

公式カタログの紹介文は以下のとおりです。

ニトリが 2021 年から 5 か年計画で推進する BigQuery データ分析基盤の軌跡と直近の挑戦を公開。分析定着化や AI 適用を経て、現在は BigQuery パイプラインによる ETL 移行や BI 内製化を進行中。さらに Conversational Analytics API やデータ エージェントを用いた「SQL レスなデータ探索」など、誰もがデータを活用できる環境を目指す進化の歩みを紹介します。

データ分析基盤構築の歩み

セッションは、一本の時系列を示したスライドから始まりました。そこからデータ サイエンティストの立ち上げがあり、スライド上で黄色くハイライトされた期間が BigQuery への移行期間にあたります。

溜まりに溜まったデータ

その結果、データは着実に溜まっていきました。2026 年時点の規模がこちらです。

  • テーブル数：2,600 本
  • 論理容量：470 TB

数字だけでもう「うわぁ……」となりますが（笑）、この規模を運用しながら育ててきたという事実が、このあとの話すべての土台になっています。

BigQuery が解決してくれたこと

BigQuery への移行によって解決したのは、大きく次の 2 点だそうです。

  • 運用分担の削減：基盤の面倒を見るための負担を減らせた
  • アドホック分析環境の提供：その場で自由に問いを立てて分析できる環境が手に入った

それでも残っていた 2 つの課題

とはいえ、移行がゴールではありませんでした。残っていた課題として挙げられたのが次の 2 つです。

  • 相性の悪い BI ツール：ライセンス費が増加していく
  • 増え続けるデータ：種類が増え、テーブル同士の関連性が複雑になってきた

「基盤は整った。でもその上で使う道具と、増えすぎたデータそのものが次の問題になる」。ここ、規模が大きくなった組織なら必ず通る道じゃないでしょうか。

BI 環境の課題と対策 ― 「乗り換える」のではなく「分ける」

まず向き合ったのが、BI ツールをどうするかという問題です。

ここで出された結論が個人的にとても納得感がありました。

BI ツールを「お着替え」しても、結局コストと再教育がかかる、というものです。

「相性が悪いなら別のツールに乗り換えればいい」と考えたくなるところですが、乗り換えコストと、全社員に使い方を教え直すコストが待っている。それに、ライセンス費用のコスト問題も解決されず。

そこで採られた方針が、乗り換えではなく分解でした。

BI ツールの機能を「参照機能」と「探索機能」に分散し、シンプル化して自分たちで開発する。

汎用の BI ツールが持つ多機能さをまるごと抱えるのではなく、自分たちが本当に必要としている機能だけを 2 つに切り分けて内製する。結果としてコスト削減につながる、という筋書きです。「万能なものを買う」から「必要なものを作る」への転換ですね。

実装結果：参照と探索、2 つのアプリ

では実際に何が作られたのか。ここからが実装のパートです。

機能 実装内容 担う役割
参照機能 AI コードアシストで開発した特化ダッシュボード 決まった指標を素早く見る
探索機能 Conversational Analytics API を使った会話型分析 自然言語で問いを立て、クエリとグラフを生成する

参照機能：AI コードアシストで作った特化ダッシュボード

ひとつめは、用途を絞り込んだ専用ダッシュボードです。汎用 BI の画面ではなく、見たいものを見るためだけのダッシュボードを AI コードアシストで開発した、という話でした。

探索機能：会話でクエリを書き、グラフを描く

そしてふたつめが、いよいよ本セッションの目玉である会話型分析です。Conversational Analytics API でクエリを生成し、グラフまで描く。まさに「SQL レスなデータ探索」ですね。

構成はどちらもシンプル

興味深かったのは、この 2 つがどちらも似たような構成で、簡単に開発できたと語られていたことです。登場するコンポーネントは次のとおりでした。

  • Cloud Run：アプリケーション本体
  • BigQuery：データの参照先
  • Firestore：アプリ側のデータ保持
  • Conversational Analytics API：会話型分析の頭脳

マネージド サービスを組み合わせるだけで、BI ツールの代替になる仕組みが立ち上がってしまう。構成図を見て「あ、これなら手が届くかも」と思わされました。

「抽出は AI、人は分析」 ― 誰でも使える環境をどう作ったか

ここからが本題です。セッションで一番刺さったのが、この「抽出は AI、人は分析」というフレーズでした。

データを取り出す作業（＝ SQL を書く仕事）は AI に任せて、人間はその先の分析に集中する。言葉にすると当たり前に聞こえますが、要件整理からリリースまでのプロセスでは、それを実現するために次の 2 点が求められたそうです。

  • クイックに、短い質問であっても意図と前提を理解して回答すること
  • 誰でも使えるように設計すること

短い質問でも意図を汲む、というのがポイントですよね。現場から飛んでくる質問って、だいたい短いですから（笑）。

立ちはだかった壁：人間にすら読めないカラム名

そして、ここで大きな課題が語られました。単純に API を有効化しただけでは、まったく実用にならないというのです。

原因のひとつが、テーブル名・カラム名のネーミング スキームの不一致でした。スライドで示された実例がこちらです。

  • EST_BNKT_ID
  • DELVTO_CRP_KBN

……人間でも解読が難しいヘッダーが散見される、と。長く動き続けているシステムのテーブルって、本当にこうなりますよね。

対策 1：テーブルにひたすら解説を書く

ではどうしたか。解決策は、驚くほど地道なものでした。

テーブルの詳細に、ひたすら解説を書く。

テーブルのプロパティに説明を書いておけば、AI がそれを読んでくれる。つまり、人間向けのドキュメントを書く作業が、そのまま AI 向けの入力になるわけです。銀の弾丸があるわけではなく、この地道な整備こそが効くというのは、聞いていて妙に励まされました。

対策 2：セマンティック レイヤーと用語集で「関連性」を渡す

ただ、1 つのテーブルを説明できても、それだけでは足りません。複数テーブルの関連性も、AI との会話のコンテキストとして渡せるようにする必要があります。

そのために採られたのが次のアプローチです。

  • BigQueryのエージェントを作成する（テーブル同士の関係を、AI が扱える形で定義する）
  • 社内用語や区分値を Knowledge Catalog の「用語集」で整備し、実際の BigQuery のテーブルに関連付ける

「区分値」まで用語集に載せて紐付ける、というのがリアルですよね。KBN が何を表すのかは、社内の人間の頭の中にしかない知識です。それを外に出してカタログに載せる作業は、AI のためであると同時に、組織の暗黙知を形式知に変える作業そのものだと思いました。

BigQuery Agent で動作確認し、アプリ化する

ここまで整備したうえで、BigQuery Agent で動作を確認し、実際のアプリケーションに仕立てていったそうです。

そして、このパートで一番おもしろかったのがここ。

できあがったアプリが実際に生成するクエリは、BigQuery に適した書き方の、人間が書くより難易度の高いクエリになっていたというのです。登壇者ご本人が「勉強になった」とおっしゃっていました。AI に SQL を任せたら、自分より上手な SQL が返ってきた ― これ、なかなか痛快な話じゃないですか（笑）。

派生効果：既存データがナレッジになった

さらに、狙っていなかった副産物もありました。既存データを検索できるようにしたことで、そのデータ自体がナレッジ化されたという効果です。

どこに何のデータがあるのか分からない、という状態から、聞けば答えが返ってくる状態へ。整備した情報が、分析だけでなく組織の資産として効いてくるのは嬉しい誤算ですよね。

ETL 環境の課題と対策 ― AI が解説できる状態へ

最後は ETL の話です。

課題は、難読なデータの引き継ぎが難しいこと。前のセクションと同じ根っこの問題で、書いた人にしか分からない処理が積み上がっていく状況ですね。

これに対する方針は明快でした。AI が解説できる環境にする。

具体的な移行の流れはこうです。

  1. Gemini CLI などにプロンプトで指示を出す
  2. 出力されたファイルを Dataform 形式で BigQuery に貼り付ける
  3. BigQuery パイプラインへ移行させる

既存の難読な処理を、AI の力を借りて「読める形式」に置き換えていく。ETL の移行というと気が重くなる作業の代表格ですが、こういう進め方があるのかと視野が広がりました。

今後の活動

セッションの締めくくりとして、今後の取り組みが 3 つ挙げられました。

  • AI 駆動開発の確立
  • 現行システムの改修
  • レガシー化しないシステムへ

システムのアップデートとともに、ドキュメント整備や暗黙知をなくすという「レガシー化されないシステム」を作るということで、当たり前のような話ですが、どの組織でもありがちな課題ですね。

まとめ

今回のセッションのポイントを、3 つに整理してみます。

  1. BI は「乗り換える」のではなく「分けて作る」。ツールを載せ替えてもコストと再教育は消えない。必要な機能を参照と探索に切り分けて内製すれば、シンプルかつ低コストで実現できる。
  2. データ エージェントは、API を有効化しただけでは動かない。難読なカラム名、テーブル間の関連性、社内用語や区分値 ― これらをテーブルの説明・セマンティック レイヤー・用語集として整備して初めて、AI は意図を汲んで答えられるようになる。
  3. 整備の効果は分析だけに留まらない。AI のために書いた解説がそのまま組織のナレッジになり、生成されるクエリは人間の書くものより質が高い。「抽出は AI、人は分析」という分担が現実になっている。

さいごに

スライドだけ追っていると、すいすい進んだ話のように見えるかもしれません。ですが、実際には何十年も本番で使われ続けているデータベースとシステムの更新・移植です。これは本来、とてつもなく大きなリスクを伴う仕事ですよね。

そのストレスを激減させたのが AI だった、というのが私の一番の学びでした。ほぼミスのないコード、システムの理解、テーブル同士の関係の把握 ― これらを AI が支えてくれるからこそ、短期間でのデータ整備と、属人化しない仕組みと、誰でも使える分析基盤が同時に成立したのだと思います。

そしてもうひとつ。データを構造化して説明を書く、ただそれだけで AI が分析できるようになるという点です。地道な整備作業に見えて、そこから派生する効果は倍増する。この投資対効果は、自分の担当領域でもすぐに試せそうだと感じました。

ちなみにセッションの締めの一言は、「元気があればたぶんできる」でした。「たぶん」が付いているのが最高に正直で面白かったのですが（笑）、数年の積み重ねを語り切ったあとのこの言葉には、しっかりモチベーションをもらいました。

最後までお読みいただき、ありがとうございました！