[ITmedia エンタープライズ] AIに分析させる前に整えるべきもの 大阪ガスが目指す「システム」「データ」「メタデータ」の循環

　分析基盤を整え、AIに問い掛ければ答えが返る環境を用意しても、業務で必要な情報が記録されていなければAIは答えを導けない。では、何を記録し、どう分析するかは、誰がいつ決めればよいのか。

　大阪ガスの國政秀太郎氏は、システム開発、データ基盤、業務知識の管理を担う部署が分かれ、工程間で情報が途切れる点にデータ活用の壁を見る。同社は、AI駆動開発基盤「WAAAP」を起点に3つの循環をつなぐ「データ民主化2.0」を構想する。その全貌とは。

本稿は、primeNumberが主催したイベント「primeNumber DATA SUMMIT 2026」（開催日：2026年10月15日）で大阪ガスの國政秀太郎氏（DX企画部 AI推進チーム／ビジネスアナリシスセンター 副課長）が「データ民主化2.0の衝撃：AIと創る『自律型』最強データ駆動組織」というテーマで講演した内容を編集部で再構成したものだ。

　まず國政氏は、データ分析の専門組織が築いてきた基盤と、生成AIを組み込んだ組織変革の構想を紹介した。構想の狙いは、従業員がデータへアクセスできる状態を超え、業務の変化に応じてシステムや分析環境が更新され、人が判断に集中できる組織を実現することにある。同社はこの構想を「データ民主化2.0」と呼ぶ。既存の取り組みの延長に、開発と運用、知識管理を結ぶ仕組みを置く発想だ。

　大阪ガスを含むDaigasグループの事業は、関西のガス供給にとどまらず、電力、海外事業、暮らしやビジネスを支える領域へ広がり、データ活用の対象も多様だ。そうしたグループにおける課題を探し、データ分析を業務の改善へ結び付けるのが、國政氏が所属するビジネスアナリシスセンターの役割だ。同センターは分析結果の提示だけを成果とせず、現場で使われる段階まで関与する。そのため、現場への同行やシステム開発も責任範囲に含まれる。

　こうした実務を支える土台として、2019年ごろから「Google Cloud」で分析基盤の構築に着手した。IoTなどから生じるデータを扱い、BIやアドホック分析、機械学習モデルの開発・運用、アプリケーションの開発まで支える環境を整備した。データの収集・転送ではprimeNumberのクラウドETLサービス「TROCCO」を活用している。データを集積するだけでなく、安く、速く、用途に応じて使える状態にする狙いがあった。

　分析結果を現場の業務に定着させるには、分析環境を充実させるだけでは足りない。そこで同社は、現場の担当者が使う業務アプリケーションを、データ分析と同じ基盤の上で開発し、運用や監視まで担えるようにした。

　開発はグループ会社のメンバーや外部の技術者と併走する体制で進めてきた。基盤で扱えるデータや機能の部品をそろえ、開発標準やCI/CDの仕組みも独自に整えた。その結果、2019～2020年ごろには、分析にとどまらずシステム開発も効率的に進められる手応えを得ていたと國政氏は振り返る。そこへ登場したのが、生成AIとコーディングエージェントだ。同社は既存の基盤とAIの親和性が高いと見て、基盤の発展に乗り出した。

コード生成の先まで支えるWAAAP

　こうして構築したのが、AI駆動開発基盤「WAAAP」（ワープ）だ。國政氏は、2026年6月に公表した社内向けのこの基盤を紹介動画を交えて説明した。着眼点は、AIでコードを書けても、開発環境の準備やテスト、公開まで人手に頼れば、開発全体の流れは速くならない点にある。企画から運用までを1つの基盤でつなぎ、各工程をAIが支援できる形にした。

WAAAPの全体像。企業データとシステム開発を一体化（出典：國政氏の講演資料）

　WAAAPは、4つのサービスとそれらを支える共通基盤で構成される。開発者はまず管理画面でプロジェクトを登録し、開発サーバを申請する。実際の開発は、AIエージェントを組み込んだクラウドの開発環境で進める。テストからデプロイまでは共通のパイプラインが自動で処理し、完成したアプリケーションは専用の実行環境で稼働する。開発のたびに環境を一から用意する手間が省け、業務上のアイデアを動くシステムにするまでの準備を短縮できる。

　開発画面には、要件定義や設計、実装などの作業に対応するカードが並ぶ。担当者が必要な情報を入力すると、手順や知識を組み込んだAIエージェントが作業を実施し、その成果物を次の工程へ引き継ぐ。巧みなプロンプトを書けるかどうかという個人の力量への依存を抑え、必要な作業に入りやすくする工夫だ。講演では、バックエンドと画面の開発を並列で進め、結合やE2Eテストへつなげる流れも紹介された。

　テストや公開にも、全プロジェクトで使える共通のCI/CDを用意した。画面の変更時には本番と隔離した確認環境を設け、業務部門が操作して受け入れ確認できる。公開後の社内認証や接続に伴う準備も基盤側で受け持ち、作ったアプリケーションを従業員が使える状態へ導く。WAAAPは、開発の自動化を利用開始までの工程に広げる仕組みでもある。

　運用面では、障害発生時にAIが原因を分析し、改善案を提示する。分析の精度を左右するのはログだ。そのため、AIが読み取りやすい形でログを出力する仕組みを開発段階から組み込み、AIに尋ねる前に判断材料をそろえておく。

　紹介動画では、開発期間を最大6割短縮した成果なども示した。WAAAP自体もWAAAPで開発しており、モデルやスキルを更新する循環を備える。紹介動画の制作にもAIエージェントを利用したと國政氏は明かした。伝えたい内容を指示してコンテンツ制作をAIへ任せる実践を、基盤の説明そのものに取り入れた形だ。

3つの循環で業務とデータの変化をつなぐ

　國政氏は、データを収集・加工して整え、SQLやコードを書けない従業員もBIなどで分析できるようにした段階を「データ民主化1.0」と位置付ける。この段階では、業務上の意味や現場の例外、指標の定義、判断の注意点といった知識を、人の分析担当者が補ってきた。そのため、知識の更新や再利用が担当者個人に依存しやすいという。

　データ民主化2.0では、整備したデータに加え、業務の目的や定義、制約といった業務知識と、分析の手順や適用条件といった分析スキルを、AIが参照できる形で継続的に管理する。その上でAIエージェントが分析を担い、業務担当者は意思決定に集中する。國政氏はこの姿を「全社員にAI分析エージェントという部下を配置する」と表現する。

　実現するためには、システム開発、データパイプライン、メタデータパイプラインという3つのループ（循環）を連動させる必要がある。起点は業務要求や要求仕様書だ。そこには業務の目的や制約、評価すべき指標が含まれる。システムの設計と並行して、何を測り、どのデータで評価するかを決めれば、分析仕様や必要な知識も早い段階から準備できる。システムができてデータが蓄積した後に、分析部門へ相談する従来の順序を変える発想となる。

　國政氏は、3つの循環がどう連動するかを、修理業務を想定した例で説明した。顧客宅を訪れて機器を修理する業務では、訪問のたびに出張費用がかかる。そのため、担当者が1日でできるだけ多くの訪問先を回れるよう、システムで訪問ルートや人員の割り当てを計算する。この業務で重視される指標の一つが、訪問した当日に修理を終えられた割合（修理完了率）だ。当日に終わらなければ再訪問が必要になり、その分の費用がかさむ。

　ところが、完了率が下がったことはシステムのデータから分かっても、当日に終えられなかった理由を現場で入力する欄がなければ、原因を探るデータは残らない。AIに分析を依頼しても、記録されていない原因は導き出せない。

　この例を3つの循環に当てはめると、起点は「未完了の理由を現場で記録する」という業務要求になる。システム開発の循環では、WAAAPがこの要求を基にシステム仕様書を更新する。作業報告フォームには未完了理由の入力欄を加え、データベースにも項目を追加する。データパイプラインの循環では、新しい項目を分析基盤へ取り込むため、スキーマを追加し、データの転送や加工の処理を修正する。メタデータの循環では、完了率と未完了理由の関係を分析する方針を定め、未完了理由の意味や用途、要因分析の進め方を知識やスキルとして登録する。

システム開発、データ、メタデータを循環させるイメージ（出典：國政氏の講演資料）

　これらは、データがたまる前の段階である程度準備できる。分析しやすいデータマートもあらかじめ作っておけば、データがたまった時点で、業務担当者はAIに問い掛け、原因の把握と改善策の検討にすぐ取り掛かれる。

　ただし國政氏は、この連動の実現は容易ではないと話す。多くの組織では、3つの循環を担う部署が分かれている。システム開発はシステムを統括するチームが、データパイプラインはデータ基盤を運用するチームが担う。メタデータの管理には明確な担い手がおらず、担うとすれば分析担当者になる。要求仕様書に書かれた情報は、チームをまたぐたびに伝わりにくくなる。國政氏は、新しいツールを導入するだけではこの分断は解消しないとし、部署間の情報の受け渡しを仕組みでどう解決するかを、同社としても挑戦すべき課題に挙げた。

分析AIの活用と専門家の役割の変化

　國政氏によると、WAAAPが現在担っているのは、システム開発の循環と、要求仕様書から分析に使う用語やスキルを生成する工程までだという。残るのは、業務担当者の問いを受けて実際に分析するAIだ。同社は分析AIもWAAAPで開発しようと、2025年ごろから取り組んだ。しかし、テーブルの結合や集計を含むSQLの生成は結果が一定せず、分析の品質がばらつくことに苦労したという。

　そこで國政氏が紹介したのが、primeNumberのAIデータプラットフォーム「COMETA」だ。同社はいち早く導入し、社内で利用者が増えているという。分析メンバーだけでなく営業担当者にも好評で、BIで2週間ほどかけて作っていた分析が、3回のやりとりで完成した例もあった。國政氏が評価するのは、用語集やテーブル間の関係を把握した状態で分析を始められる点だ。必要な文脈がそろっているため、生成されるSQLの品質が高く、誤りも起きにくいという。

　繰り返し確認する指標は、毎回プロンプトを入力する手間を避けるため、プレビュー版を利用しているBI機能でダッシュボードにする考えだ。ただし國政氏は、メタデータの保守や更新が滞れば循環は回らず、COMETAも生かし切れないと指摘する。現時点の役割分担は、システム開発の循環と分析用メタデータの生成をWAAAPが、データパイプラインをTROCCOが、分析をCOMETAが担う形だ。

　國政氏が目指すのは、業務部門が背後の循環を意識せずに済む状態だ。新しいKPIを加えたい、現場から新たなデータを集めたいといった要求を出せば、要求仕様書を起点にシステムとデータ、メタデータが更新される。業務担当者はAIと共に分析し、意思決定に集中できる。

　こうした話をすると、データサイエンティストやエンジニアは不要になるのかと問われることが多いという。國政氏はこれを否定する。目指すのは循環のさらなる自動化であり、無人化ではない。基盤を構築するプラットフォームエンジニアリングや技術的なレビューは人が担い、ループごとに人のレビューを通す。データサイエンティストやエンジニアは今後、これらの循環を仕組み化し、自動化する仕事に力を注ぐと國政氏は語った。