ライオンの「時短90％」内製化術 ABAPを読めない開発者がSAPデータをBigQueryで活用：Google Cloud Next Tokyo 26

ライオンは基幹システムのSAPデータをBigQueryで活用するため、GeminiでABAPやCDS ViewからSQL文への変換に取り組み、初心者エンジニアでも扱えるようにした。SAPの学習にかかる工数を最大90％削減した他、データモデルの再設計とBigQueryエージェントの活用により、経営層向けのアドホック分析にも取り組んでいる。

[山下竜大，ITmedia]

　100年以上にわたり日用品を提供するライオンは、AI活用に向けたデータ基盤「LDP」（Lion Digital Platform）の開発を進めている。基幹システムのSAPデータを「BigQuery」で活用する構想は数年間の試行錯誤を要し、SAP独自の構文であるABAPをSQL文に変換する壁が経験の浅いエンジニアにとって特に高かった。

　この壁を「Gemini」で乗り越えたのが今回の取り組みだ。SAPロジックのSQL変換を実現し、SAP学習にかかる工数を最大90％削減。併せてデータモデルの最適化を進め、「BigQueryエージェント」を使った経営層向けの迅速なアドホック分析にも道を開いている。

　本稿では、ライオンによるSAPデータ活用の取り組みを、SQL変換の工夫からデータモデル再設計、エージェント活用まで解説する。

本稿は、Google Cloud主催の年次イベント「Google Cloud Next Tokyo 26」（2026年7月30〜31日開催）で、ライオンの濱野博友氏と中川碧樹氏が「SAPとGeminiで経営の力を引き出す『AI-Ready』なデータ基盤構築への挑戦」と題した講演を、編集部で再構成したものだ。

生成AIによるSQL変換でSAP学習の工数を最大90％削減

　ライオンは基幹システムにSAPを導入しており、SAPのデータをBigQueryへ連携・分析する仕組みの構築には、数年間の試行錯誤を要していた。課題になったのはSAPのデータをいかにBigQueryに登録し、データ分析に活用するかだ。解決策として、SAPのデータをBigQueryと連携させ、高度なデータ分析やAI活用を迅速に実現するためのブループリント「Google Cloud Cortex Framework」の採用を検討した。

　SAPのデータを利用する場合、SAP標準テーブルであれば差分同期する方法が幾つかあり、その一つがCortex Frameworkだ。同フレームワークは標準データに対して大きな効果を発揮するものの、アドオン開発を含む同社の利用対象テーブルでは全体の70％が活用できなかった。

　デジタル戦略部の濱野博友氏は「SAPの帳票テーブルは、CDS ViewとABAPという2つの言語で実装されています。CDS ViewはSQL文に近い構文ですが、ABAPはSAP独自の構文です。SAPの構文を理解していない初心者エンジニアにとって、どちらの言語もBigQueryで使えるSQL文にスムーズに変換できないことが大きな課題でした」と当時を振り返る。

　課題解決に向け、Geminiを活用したデータ変換の検証を開始した。当初は、CDS ViewやABAPの知見がなく、社内にある概要設計書や詳細設計書などを入力し、SQL文に変換できるかどうかを検証した。しかし仕様書だけでは、帳票データを再現できないケースが多く、ある程度理解したとしても帳票データと一致しなかった。

　「Geminiは、不明な点があると推論して変換するのですが、推論が良い結果をもたらす場合と、そうでない場合があります。そこで仕様書ではなく、ソースコードを利用することで課題を解決しました。また、重複排除のロジックや初期値の設定、クライアント番号など、SAP特有のロジックに関しては、ABAPとSQLの対応関係をプロンプトで指示することで解決しています」

　またPLANモードで事前に見落としや不明点がないか、推論が入っていないかなどを正確に精査することで実装の精度を高めている。さらにSAPから抽出したデータとロジックで再現したデータが完全一致しないと、事業部で数字を活用するときの信頼性に関わることからGeminiで回帰テストも実装した。

　指示はプロンプト集に登録し、GitHubで共有することで、チームのメンバーが同じプロンプトを書けるように工夫した。これにより、新卒メンバーでも比較的短期間でプロンプトの書き方をキャッチアップできた。

　今回、開発したのはSAPからデータを抽出し、BigQueryに登録して、「Looker」で分析データを事業部に共有する仕組みだ。SAP GUI for Windows（バージョン 7.60）で、ABAPやCDS ViewのソースコードをGitHubに登録し、GitHub Copilotでプロンプトを入力してDataform CLIでSQL文に変換することで、BigQueryのELT処理をオーケストレーションする仕組みも構築した。

BigQueryとLookerで分析データを事業部に共有（出典：濱野氏、中川氏の講演資料）

　GeminiによるSQL変換の効果を、濱野氏は次のように語る。「対象となる帳票の種類にもよりますが、SAPのテーブル仕様書やABAPのコードなどをゼロから学習すると1〜3カ月かかります。これに比べGeminiによる効果は、学習にかかる期間を数日〜1週間程度に短縮できるので、最大90％の工数削減が期待できます。効率化された時間をエージェント開発やBI開発に有効利用することで事業に新たな価値を創出できます」

複雑なSAPロジックの解読時間をいかに削減するか

　当初はSAPデータをLookerでダッシュボード化することが目的だったが、可視化を進めるにつれて新たな課題やニーズが浮き彫りになった。例えば活用面では、頻繁な要件変更にも柔軟に対応できる構造や、会話分析エージェントがスムーズにデータを参照できるデータモデルの設計が求められた。

　開発面では、複雑なSAPのロジックを解読する時間を削減するために、テーブルを再利用する必要があった。また、BigQueryとLookML間で、テーブル定義が分散してしまうことも課題の一つだった。

　デジタル戦略部の中川碧樹氏は「改善前のデータモデルでは、生データをBigQueryで加工して、Lookerでダッシュボードを作って可視化していましたが、中間テーブルやBIテーブル、LookMLモデルの定義が開発者に依存していました。テーブルも大福帳（全てのデータを横長に持つ形式）で、エラーや変更対応が発生したときの影響範囲や工数が不透明でした。また、会話分析エージェントは、データを分析するためにどのテーブルを使用すべきかがあいまいで、準備が整っているとは言えない状況でした」と話す。

　新しいデータモデルでは、開発者依存から脱却し、中間テーブルやBI用テーブル、LookMLで定義する内容や場所を明確化した設計に変更した。最終出力として、会話分析エージェントの追加も想定している。ポイントは「中間テーブルのスタースキーマ化」「指標テーブルの作成と後続への連携」「メタデータ付与」「Assertionによるデータ担保」の4つだ。

新しいデータモデルでは開発者依存から脱却（出典：濱野氏、中川氏の講演資料）

中間テーブルのスタースキーマ化

　元となるSAPテーブルは第3正規形に正規化されており、階層構造や複雑なロジックを含んでいる。さらに、同一テーブルを多様な可視化に使い回すケースも多く、その都度複雑なロジックを解析・開発するのは、工数面から見ても現実的ではなかった。

　そこで同じテーブルを使うケースでは、スタースキーマとして単純化した中間テーブルを再利用することで、開発者がSAPロジックを一から解析する必要がなくなり、工数を削減できるようにした。開発者依存だった中間テーブル定義を標準化できる利点がある。

指標テーブルの作成と後続への連携

　整備したスタースキーマをBIで直接利用する選択肢もあったが、ライオンでは「指標テーブルの作成と後続への連携」というアプローチを採用した。スタースキーマ化された中間テーブルから、分析指標ごとに切り出して細分化した指標テーブルを作成する。BI用テーブルは、BIの要素ごとに指標テーブルをUnion all（縦方向に結合）することで定義する。BigQueryエージェントも、指標テーブルを参照することでテーブルごとの関係を疎結合にしている。

　「全てのデータを横長にもつ大福帳テーブルを利用した設計と、指標テーブルを利用した疎結合の設計を比較すると、大福帳テーブルは集計可能な軸が複数存在するため、AIエージェントによる間違った分析が発生する可能性があります。一方、指標テーブルは、集計可能な軸が単一、または少ないので間違った分析は発生しにくくなっています。コスト最適化の面でも、指標テーブルは粒度が小さいのでスキャン量が少なくて済むことが利点です」（中川氏）

メタデータ付与

　既存設計を改善してテーブルを疎結合に保つようにしたが、AIレディな基盤づくりや精度の高い会話分析を実現するには、単にテーブル設計を整えるだけでは不十分だ。そこでメタデータ付与が重要になる。Lookerのセマンティックレイヤー構築を進める一方で、BigQueryエージェントの活用に向け、Dataplex（Knowledge Catalog）によるメタデータの付与も実施している。

　中川氏は「テーブルや各項目の説明を持たせたBigQueryのテーブルを参照するだけでも一定の結果は返ってきます。ただ、テーブルに直接書けない社内用語や類義語をメタデータとして定義しておくことで、より自然で精度の高い会話分析が可能になると期待しています」と話す。

Assertionによるデータ担保

　どれほどテーブルやメタデータが整っていても、データの正しさや信頼性の保証は不可欠だ。そこで同社が導入したのが、Assertion（アサーション）によるデータの信頼性担保だ。Dataformの標準機能であるAssertionを活用してテーブルの整合性をチェックし、データの正確性を担保している。

　中川氏は「Assertionによるデータ担保には、経営層に誤った意思決定をさせない他、データに対する不信感からダッシュボードが使われなくなることを防ぐ狙いもあります」と話す。

データモデルの整備でText to SQLの準備が着実に前進

　生成AIの活用に関連して、BigQueryエージェントを使用して、経営指標や会計エージェント、アドホックな分析エージェントを開発している。経営指標・会計エージェントは、ユーザー対話形式のあいまいな質問に対しても、柔軟かつ自由度の高い回答を得られる活用を想定している。

　例えば、プロンプトを指定せずテーブルを連携しただけでは、簡素な説明とともにデータ全体を網羅した結果が返るだけにとどまる。表示される図表も冗長で、サマリーも表面的なものになりがちだ。一方、適切なプロンプトを設定すれば回答の質が向上し、時系列グラフなどを用いた視覚的にも理解しやすい回答が得られる。ただし、プロンプトの設計によって出力精度が左右されるため、今後の継続的な整備が重要となる。

プロンプトを設定すると回答の質が向上（出典：濱野氏、中川氏の講演資料）

　アドホックな分析エージェントは、予測が難しい外部要因が発生する昨今、経営層が環境の変化に合わせた意思決定をするために必要になる。例えば、ある外部要因により、需要が大きく減少した場合、経営層は減少がいつ回復するか、インパクトはどれほどかをいち早く把握し、最適な経営戦略を立案する必要がある。そのための情報を得られるダッシュボードを作成しても、出来上がったときには既に状況が変化していることが多い。

分析エージェントはデータがそろっていれば頼もしい存在（出典：濱野氏、中川氏の講演資料）

　中川氏は「予測と出力をアドホックな分析エージェントに解析させることで、経営層の求めている回復見込みやインパクト情報を含む回答を得られます。アドホックな分析エージェントは、データがそろっていれば分析から出力まで任せられる頼もしい存在だと感じました」と話す。

　今後の展望を中川氏は、次のように話している。「データモデルの整備が進んだことで、会話分析が可能になるText to SQLの準備が着実に整っています。今後は対象データもさらに拡大させていく予定です。一方、ビジネスコンテキストやプロンプトは、改善の余地があり、引き続き整備していきます。AIによる回答の精度を検証できる環境構築にも注力します。課題を1つずつクリアすることで、エージェンティックAIとAIレディなデータ基盤が完成し、経営の意思決定を支える強力なパートナーになると確信しています」