Jagu'e'r の Meetup に参加して得た Looker 活用推進の活路
koboriデータプラットフォームチームの @kobori です。 先日 Jagu'e'r のデータ利活用分科会主催の Meetup に参加してきました。
今回参加したのは「Looker 活用事例」をテーマとした Meetup です。 昨年 2023 年末に Looker User Group が Jagu'e'r のデータ利活用分科会に統合されたらしいのですが、その後初めての Looker をテーマとした Meetup だったようです。
弊社でも Looker を使用しているのですが、何か Looker を活用していくためのヒントを得られないかということで 7 月に入社した @shuhei と共に参加してきました。 また、今回の Meetup ではありがたいことに弊社にも LT 登壇の機会をいただき、私も Belong における Looker の活用事例をお話ししてまいりました。
Belong での Looker の利用状況
以前 @taketsuru の記事でも触れていますが、弊社では 2023 年の 9 月頃から Looker の導入を開始し、同年の 12 月ごろから本格的な利用を開始しています。 社内の在庫状況や販売状況、価格などのデータをパートナー企業様に連携することを目的に導入いたしました。
Looker では 1 つのインスタンス上でダッシュボードとユーザを管理することができます。 ユーザやグループごとにロールの設定やダッシュボードに対するアクセスを制御することができるため、ダッシュボードごとにユーザ共有設定を行う必要のある Looker Studio と比較すると、パートナー企業様との連携の障壁がグッと低くなりました。
また、Looker ではダッシュボードをコードとして管理することができ、GitHub と連携したバージョン管理も行えるため、ダッシュボード管理の属人性も解消されました。
- 多様な認証方法
- アクセス制御のしやすさ
- ダッシュボードのコード管理とバージョン管理
など、これらは確かに Looker の価値であり利用する上でのメリットであると感じます。 しかし、みなさんご存知の通り Looker は非常に高価なサービスです。 その対価として得られる機能として納得はできるでしょうか？
わざわざ高いコストを払ってまで Looker を選ぶ理由を見つけたい思いで今回の Meetup に参加してきました。
Semantic Layer と Gemini の連携
今回は私を含め 4 名の登壇者により LT が行われました。 下記の通り、Looker の活用事例に関する LT が 3 本と Google Cloud Japan の方による Looker の最新情報が 1 本です。
- Belong で Looker を導入した背景と実際に利用して感じるメリット
- Looker を活用したデータサービスの構築
- Looker の導入事例とそのノウハウ
- Semantic Layer を活用した Looker と Gemini との連携
今回特に印象に残ったのは Google Cloud Japan の方による Looker と Gemini の連携についての LT です。 Semantic Layer と Gemini を組み合わせることで、高精度に自然言語によるクエリを実現できるというお話でした。
今や当たり前のように、あらゆる分野で生成 AI の活用が進んでいます。 自然言語によるデータのクエリも注目される分野の一つです。
自然言語によりデータをクエリすることができれば SQL を使わずに DWH のデータにアクセスできるようになるため、より迅速な意思決定に繋げることができます。 今春に開催された Google Cloud Next '24 でも Gemini for BigQuery が発表され、BigQuery 上でも機能としては自然言語によるクエリが実現されている状況にはあります。 しかし、複雑な SQL の生成には課題が多く、思うようなクエリの生成は難しいというのが現状のようです。 先週 BigQuery において、GUI 操作により SQL を生成できる Table Explorer という機能がリリースされましたが、これも現時点においては生成 AI によるクエリの生成に課題が山積していることを表しているように思えました。
このように課題を抱える自然言語によるクエリですが、間に Semantic Layer を咬ませることで、ある程度複雑なクエリも実現できるようです。 その理由を 2 つ挙げられており、
- Semantic Layer で定義したメタデータを Gemini の Input とするため
- Gemini は SQL ではなくクエリパラメータ (URL) を生成するため
とのことでした。 生成 AI にはコンテキストの理解のみを任せ、複雑な SQL の生成を Semantic Layer と分担することで、一定の精度での SQL の生成を実現できるようです。
生成 AI で直接 SQL を生成する場合、どの句にどのパラメータをどの順序で渡すかなど、様々なことを考慮しながら 1 つのセンテンスを作り上げる必要があります。 一方でクエリパラメータを生成する場合、パラメータ名と Value の組み合わせだけを生成できればよいので、SQL のような複雑性がなく、 生成 AI にとっては問題の難易度が一気に下がるということなのだと思います。
また、単にデータをクエリするだけではなく、可視化の方法まで指定できるようです。 実際に自然言語によるクエリが実現すれば、事業部門の方々によるデータアクセスの障壁が一気に下がり、社内でのデータ活用の幅が一気に拡がりそうです。
Looker Explorer Assistant という Looker Extension を用いることで実現できるそうです。 実際のクエリの正しさはどのように保証されるのかなど気になる部分はあるものの、試す価値は十分あるように思います。
Meetup での気づきと Looker 活用のためのヒント
何を今更と言われてしまうかもしれませんが、Looker の価値を最大限に引き出すためにはやはり Semantic Layer の理解が最重要事項であると再認識しました。 そして同時に Semantic Layer に対する理解不足も痛感しました。
Semantic Layer は「データとビジネスユーザの橋渡し」という表現でよく説明されます。 データに存在する複雑性を Semantic Layer が吸収し、ビジネスユーザは SQL を書かずともデータへのアクセスが可能になります。 Semantic Layer を用いるメリットとして、
- Semantic Layer 上にビジネスロジックが集中することによる社内での指標の統一
- リクエストに応じて動的に SQL を発行する仕組みによる SQL 管理コストの削減
などのガバナンス性やメンテナンス性に関する側面で語られる印象を受けます。 もちろんこれらも重要なメリットではありますが、今回の LT を聞いて、「橋渡し」ができることこそが Semantic Layer の価値なのだと再認識しました。
さらに Looker では、あらゆる操作が Looker API として API 化されています。 Looker API により Semantic Layer の価値が最大限に引き出され、Looker の価値を生み出しているのかもしれません。
今回の事例の中にもありましたが、Semantic Layer があるからこそ Looker を活用したデータアプリケーションや新規サービスも構築できるのだと思いました。
また、今回の Meetup を通して、弊社 Belong はデータ活用をする土台が十分に整った企業であるということにも気づきました。
現在も実際にデータを活用しながら事業を進めていますが、データの価値が十分に理解されている企業文化である印象を私は受けています。 それ故に Looker も導入されたのだと思いますが、BI の導入から苦労している企業が多くある中で、データへのアクセスのしやすさが課題になる弊社はデータプラットフォーム領域のエンジニアとして非常に恵まれた環境であるように思いました。
最後に
今回の Meetup では初めての LT を経験し、また、Looker を活用する上でのヒントも得ることができ非常に有意義な時間となりました。 今回弊社に LT の機会をくださった Google のご担当者様と G-gen 様に感謝申し上げたく思います。
まだまだデータ活用に課題を抱える弊社ではありますが、今回の記事を読んで弊社に興味を持っていただけた方は Entrance Book をご覧ください。