はじめに

普段、プロジェクトで組織向けのBIレポートをよく作成するのですが、近年のAIの台頭もあり、データ利活用に関する問い合わせや相談がますます増えるようになってきました。

データが重要という事自体はこれまでもずっと言われ続けてはいましたが、これまではいわゆる表面的な業務効率化に留まっていた組織も、データの重要性について頭ではなく肌感覚で理解し始めているのだと思います。

いわゆるデータ分析部門や企画部門などの一部の人達だけではなく、より現場に近い領域の人達からもデータに関する意見が多く出るようになってきているのは非常に良い傾向なのではないかと思います。

一方で、BIレポートの作成において日々悩ましく感じていることは、データ利活用に関する要望が増加していく中で「要件を一定落とさざるを得ない」という事です。

というのも、レポートの利用者は様々であるため、組織Aからは「〇〇の切り口で見たい」、組織Bからは「●●の切り口で見たい。〇〇は不要なので削除するか非表示にできるようにして欲しい」と言われたり、同じ組織内でも、Cさんからは「△△の表示もできると嬉しい」、Dさんからは「△△はいらないけれど、□□についてはもう一段深堀りして表示できるようにしたい」など、限られた画面のスペースの中で、あちらを立てればこちらが立たずというものも含め様々な要望が出てきます。

このように様々な要望が出るのは当然の事(むしろ良い事)で、組織レベルでも個人レベルでも業務内容は異なるため、それぞれに見たい観点や粒度感は当然異なります。

全ての要望を踏まえた個別のレポートを作成できればもちろん良いのですが、開発チームの工数は有限かつ、リリース後の運用・保守工数の肥大化も防ぐべきなので、基本的には要望の多い箇所（AND条件）を優先した最大公約数的な形を狙いにいく事になります。

そのため、要件定義のプロセスにおいて、個々人にとっては重要でも共通性の高くない個別要件についてはどうしても諦めてもらう必要があり、結果として出来上がったレポートは、全体の合計値としては最も大きいのですが、各利用者のレベルで見ると、70～80点のレポートになってしまうという事も少なくありません。

ここでセルフBIや市民開発といった話になるのですが、ビジネスユーザーが本当に向き合いたいのはあくまでビジネスの成果であり、データの集計や加工プロセス、SQLの設計ではありません。

やはり餅は餅屋であり、企業のプログラミング研修で誰もがプログラミングができるようにはならなかった事からも明らかなように、一定の知識はもちろんあったほうが良いですが、ビジネスユーザーはやはりビジネス領域に集中すべきでしょう。かなりの時間と工数を割いてプログラミングの基礎はなんとなく理解できるようにはなったけれど、実務レベルには到底及ばず、その分現場感やビジネス領域の解像度が下がっては本末転倒になりかねません。

今回は共通的なBIの特性と市民開発のボトルネックを埋め、組織におけるデータ利活用を更に加速させるためのAIエージェントの活用について検討していきたいと思います。

機能検討

Qiitaは動画を細かく載せられないので、順番が前後してしまいますが先に全体のデモを載せておきます。
※解像度は適宜調節して頂ければと思います

解説は以下に続きます。

データソース設定

今回はサンプルとして以下のようなBigQueryのデータセットを使っていきます。

プロジェクトでよく使うので今回はBigQueryを使っていますが、データベース自体はなんでも構いません。データベースとやり取りするツール(AIエージェントに渡すツール)さえ調整してしまえば良いので、プロジェクトの初期状態や検証段階という事であればExcelやCSV等でも大丈夫です。

フロントUI上からはBigQueryのプロジェクトを選択して、プロジェクトのデータセット・テーブル一覧・カラムを参照できるようにしておきます。コンテキストエンジニアリングの観点でも、AIエージェントに参照させるスコープは、目的に応じて最小化しておくべきなので、データセット・テーブル・カラムレベルで利用するデータを選択できる形にしておきます。

無邪気に全選択にしてもある程度動くとは思いますが、必要以上の情報を渡して品質が向上する事はないため、目的に応じて対象データのスコープは絞ってあげたほうが良いでしょう。データセットの中でも、不要なテーブルやカラムも可能な限り落としておく事で、次の分析過程における品質の向上が期待できます。

また、データ分析の観点では個人情報は不要というケースも少なくないと思うので、後続のレポート作成で誤って個人情報が出力されてしまわないように、対象のカラムは非活性にしておいたほうが良いでしょう。

明らかに個人情報が不要という事であれば、そもそもこのビュー取得の時点で個人情報は落としておく、またはEntraIDで利用者の組織情報を抽出して、必要な組織にだけ動的に出力させるというのも一つかと思います。

ここで選択されたデータが、次の非定型データ分析においてデータソースとして利用されます。

非定型データ分析

先ほど設定したデータソースに対して自然言語でデータ分析を実施していきます。

ユーザーの要望を元に、レポートのアイディアを提案し、必要なSQLを組み立てます。

認識の齟齬とブラックボックス化をなるべく避けるために、実行するSQLを提示して、事前承認を行うユーザー確認のステップを設けています。

今はベースとしてかなりシンプルな形にしていますが、期間や粒度、時系列で出すのか前年比を出すのか、パッと概観できるサマリを優先するのかファクトの一覧を優先するのかなど、実際のユースケースに合わせてどの観点をAIエージェントに確認させるかの設計が重要でしょう。

ただ、ユーザーがデータとインタラクティブに自然言語でやり取りできるので、きちっと事前に要件定義をする必要なく、生成された実際のレポートを見ながら、試行錯誤して自分が欲しいレポートを生成する事ができます。

スポットの分析用途ならこれで良いですし、作成したレポートを再利用したい場合は、「レポート保存」ボタンから保存し、レポート一覧からいつでも参照できるようにしています。

ここで一つ重要になるのは、LLMにはHTMLのテンプレートのみ生成させ、データの埋め込みはプログラム側で実施しているという点です。LLMにデータを渡してレポートを作成しようとした事がある人はわかると思いますが、LLMはあくまでテキストを返してくるので、そのままやると大量の数値データも埋め込んだレポートを返してきます。

単純なサマリだけならいいですが、テーブル表示などデータが多い場合は、LLMのトークン数とコストが大きく上がる上に、レスポンスが非常に遅くなります。

これを避けるために、LLMには基本的にデータを埋め込むHTMLのテンプレートだけ生成させ、レポートの保存時にはHTMLのテンプレートと実行するSQLだけを保存させます。

レポート一覧

データ分析機能で保存したレポートを一覧で参照できる機能です。各レポートの更新ボタンを押せば、いつでもデータソースから最新のデータを取得してレポートの更新ができます。

先ほど説明したように、HTMLテンプレートとSQLを分けて保存しているため、このレポート更新の際はLLMを呼ぶ必要はありません。SQLの実行結果をプログラムでレポートに埋め込むだけになるため、高速に更新ができます。またレポートの展開も踏まえ、エクスポート機能も設けています。

HTMLとSQLを保存しているため、作成したレポートはいつでも微調整可能で、構築コストがそもそも低いので不要になったタイミングでいつでも捨てて良いです。

少人数での利用や特定の期間だけ欲しいレポート、特定の商品やキャンペーンに特化した分析レポートなど、これまでなかなか手が届かなかった領域まで、柔軟性の高いデータの利活用が期待できます。

今後の拡張検討

色々と方向性があるのですが、今後の拡張についても少し検討しておきます。

スキル定義

組織での利用においておそらく最も重要になるのがこのスキルの定義です。

少なくとも以下の3つは検討しておく必要があるでしょう。

レポートデザインスキル（ユースケースに応じたレポートデザイン）
データセット利用スキル（ビジネス観点も含むデータセットの補足・メタ情報、参考SQL等)
分析スキル（組織としての分析観点・切り口のナレッジ化）

まずレポートデザインスキルについてですが、組織とユースケースによって好まれるレポートのデザインはどうしても異なります。

コーポレートカラーはもちろんですし、抽象度の高いレポートが良いのかファクトが追える詳細なレポートが好まれるのか、立体感のあるデザイン性の高いレポートが良いのかシンプルで簡素なレポートのほうがむしろ好まれるのかなど様々です。出先での移動中などスマホ利用が多いのであれば、スマホ用のビューかレスポンシブを優先すべきでしょう。

プロンプトで微調整できるようにはしておいたほうが良いものの、初手で良い物(自分が欲しい物)が出てくるかどうかは工数削減の重要なポイントになるので、組織に応じたレポートのスキルは洗練させていく必要があるでしょう。

続いてデータセットの利用スキルです。データセットはあくまで数値のデータは保持していますが、データの意味は保持していません。

例えば「売上」と言っても定義は様々で、実際は売上を計算する場合は、カラムAとカラムBを足す必要がある、カラムCが0の場合は、カラムDの値を使うなど、データの利用時には必ず考慮すべき事項が発生します。このように各データセットを利用する際の意味にあたる情報をスキルとして定義してあげる必要があり、特に複雑になる場合は、利用するSQLのサンプルなども用意しておいたほうが良いでしょう。

ここはビジネス側の要求と社内データ基盤の構造をよく理解している人材が必須で、このスキル定義がないとAIも迷う事が多く、手戻りやプロンプトによる追加の指示が多くなってしまうでしょう。

これは非常に優秀なデータサイエンティストを採用して、とりあえずデータベースだけを渡しても、そもそもこの組織では何が求められているのか、このデータの意味は何なのかがわからないと仕事を進められないのと同じ事です。

もう一つ重要になるのが分析スキルです。組織としての分析観点や切り口のナレッジなどもスキルとして定義してあげると良いでしょう。仮説を立て、データを分析しながら仮説を検証するという事を繰り返すわけですが、当然1人では限界があります。そのため、過去有効だった分析観点や切り口などを整備して、組織全体で再利用できるようにしておき、LLMに分析をサポートしてもらうのが良いでしょう。

デフォルト状態のLLMに純粋に分析を依頼するだけだと一般論になりがちですが、このナレッジ自体が組織の資産として競争力の強化に繋がるはずです。これまではナレッジをドキュメントで整備してもその再利用が難しいという課題がありましたが、AIがその再利用を後押ししてくれます。

データソースの拡充

今回はTextToSQLによるデータベースからの分析をメインにしていますが、社内のドキュメント情報を参照させたり、社外のデータソースなども含めた最終レポートを作りたいというケースももちろん出てくるかと思います。

ただ、とりあえず何でも繋げばアウトプットの質が上がるかというとそんな事はなく、むやみにソースを追加するとAIのコンテキスト汚染に繋がるのでここはむしろ慎重に進めた方が良いでしょう。

データソースの追加と利用におけるスキル定義はセットになるので、とりあえず必要そうなものを一通り足してから取捨選択していくアプローチより、一つずつ洗練させながら追加していくアプローチが最終的には速いかと思います。

データソースをとりあえず追加する事自体は簡単なのでやりたくなってしまいますが、トレードオフについては正しく認識する必要があり、少なくとも、もしかしたら使うかもしれないからという理由でデータソースをMCPで大量に追加するというのはNGで、この辺りも自社のビジネスとユースケースをよく理解した人材による目利きが必要になるでしょう。

AIの観点でも、目的から逆算して必要な情報が含まれている最小限のソースを渡すほうが精度が出やすく、まだまだ試行錯誤が多い領域で着実に進めていくために、ビッグデータの時の二の舞にならないようにすることが重要かと思います。

BI不要論について

この手の話をすると「もうBIはいらないのでは？」という話が必ずといっていいほど出るので、正解はないのですが、ここで私見を述べておきたいと思います。

まず基本的にゼロイチの議論は往々にして間違いであり、AIとBIについても役割分担という事になるかと思います。

例えば、LLMが出てきた時にRPA不要論もよく出ましたが、APIもデータベース接続も不可でGUIしか使えないシステムからデータを抜くにはRPAを使うしかありません。AIに画面認識させるというのも一つの手ですが、明らかに決まりきった手順をAIに毎回判断させて再現させようとしても、速度やコスト、安定性の面で明らかに筋が悪いので、RPAやスクレイピングツールなどのロジックで組んだほうが良いでしょう。

BIに関していえば、これまでBIが使いにくかった非定型の分析や一過性の可視化、個人利用などの範囲ではAIを上手く使うのが良いと思います。一方で、個々人がAIで同じような分析をしたり、レポートを試行錯誤して個別に作るのは無駄なので、組織として必須になる箇所は高品質な形でBIレポートを作りこんだほうが良いかと思います。

KPI定義の統制、監査対応、財務報告、権限管理・公開範囲の統制、再現性の保証やSLA付きのレポーティングなど、いわゆる品質と信頼性が重要視される範囲においてはBIを使うべきかと思います。

AIのメリットでもあり、デメリットでもある点として、多少間違っていてもそれなりにレスポンスをしてしまうという所があります。BIはプログラムなので、データが壊れていれば確実にエラーとして出してくれます。

またBIの場合は、売上はどのように計算するかという事をエンジニアがデータを理解・定義して実装するというプロセスを挟みますが、AIの場合は売上に該当しそうなカラムを使って勝手に出してくる可能性があります。一見良さそうなレポートに見えても計算方法が違っていたり、NULLや欠損値なども適当に処理してしまう可能性もあります。この辺りが先ほど、データセットのスキルの定義が必須と言及した理由になります。

この領域に限らずですが、AIの柔軟性と信頼性はトレードオフなので、対象のユースケースによって、BIを使うのかAIを使うのかの見極めが必要になります。

また、おそらく全てAIでやろうとすると、結局のところ行レベルセキュリティやログ出力、権限管理や開発環境と本番環境の分離、レポーティング機能などを作りこむ事になり、いつの間にかBIツールの再開発をしているという事になりかねません。極端なゼロイチの話をするのではなく、特性に合わせて上手く使いこなしていく形が賢明かと思います。

私自身は、目的が達成できればそもそも手段は問わないので、BIもAIも適材適所で使い続けていくつもりですが、むしろAI活用で期待している事の一つにBIの開発プロセスの効率化があります。

というのも、BIの企画・要件定義の段階で困るのが、ユーザー側もどういうレポートが欲しいのか最初は明確に説明できないという事です。多くの場合は、ざっくりとしたイメージをもらって、こちらでレポートのプロトタイプを見せ、フィードバックをもらいながら形にしていくというサイクルを何度か繰り返します。

これはある種仕方のない話で、実際にレポートを見てみないとユーザー側としてもなかなか具体的にイメージできないためです。ユーザーのざっくりとしたイメージをプロトタイプで再現してみると、思ったより配色が悪かったり、強弱がなく見えづらかったり、ここはカード型で合計を切り出して表示した方がいいなというケースや、最初から全て表示するのではなくフィルタで選択できたほうがいいなど、デザインにそもそも正解はないので、基本的には当初のユーザーからもらったサンプルと最終成果物のデザインは異なる形になります。

このプロセスは非常に重要なのですが、開発側としてもユーザー側の言語化できていない要素も汲み取りながら(時に大きく外して失敗しながら)、プロトタイプをぶつける形になるので、対応工数も相応に大きくなります。

ここでAIエージェントを使い、例えば、ユーザー側で先に試行錯誤しながら作成したレポートイメージを共有してもらえれば、最初の段階からかなり解像度高く進める事ができ、双方のコミュニケーション効率が上げられるでしょう。また、場合によっては画面共有してディスカッションしながら1時間で画面イメージを一緒に作ってしまうというのもありかと思います。

いわゆるワイヤーフレームとは違い、裏側は実際のデータソースに繋がっているので、数値も含め実物相当のレポートができ、この時点で外れ値などの想定外の考慮事項に気づくかもしれません。

AIエージェントを使いながらレポートのイメージがまとまってしまえば、あとはBIレポートとして実装して品質を作りこみ、組織に公開すれば良い形になります。AIは70～80点までのプロトタイプ作成は非常に速いので、ここで上手くAIを使って初速を出せば、後続プロセスも効率的に進められます。このように要件定義の段階での擦り合わせの解像度が高められれば、最終成果物の品質も高くなるのではないでしょうか。

逆に「これはBIで対応するのは少しToo muchだけど、やらないわけにもいかないな。。」というケースは、AIエージェントでレポートを作成してしまって、生成されたHTMLテンプレートとSQLをチェックして十分であれば、あえてBIで再開発する必要もありません。更新時にLLMを使用しない形にすれば再現性は担保されるからです。

これから色々と模索していく形になるかとは思いますが、AIかBIかの議論ではなく、データの利活用を推進するソリューションとして、AIという新たな武器も使えるようになったと捉えるのが最も良いかと思います。

AIエージェントの活用によるデータドリブンの促進

ここからはAIエージェントをどう活用していくのか、組織利用において促していきたい効果と方向性について検討したいと思います。

1. 組織全体でのデータ基盤整備に対する意識の向上

ここまでアプリケーションレイヤの話を中心にしてきましたが、組織において最も重要なイシューは「そもそも必要なデータ基盤がちゃんと整備されているか」という事です。

結局のところ、優秀なAIエンジニアやBIエンジニアがいても、元データの品質が非常に低かったり、そもそもデータがアナログでデジタル化されていないという事であれば、当然データ分析もレポート作成も実施することはできません。逆に、データ基盤が非常に高品質に整備されている状態であれば、標準的なAIエンジニアやBIエンジニアでも、前者のケースより品質の高いレポートが作れるでしょう。

データ側が含んでいる問題をアプリケーション側のAIで吸収するというのは非常に効率が悪いので、AIのアウトプットの品質を上げたければ、AIの処理を見直すのではなく、まずデータ自体の品質を上げる必要があります。データセットのスキル定義が大事と言いましたが、理想はスキル定義なしでもAIがデータベースを見て直感的に操作できる状態を作る事です。

一方で、利活用の出口が見えない状態から「データの品質が大事」とだけ言われても、ユーザー側としてもピンと来ないでしょうし、経営層からみてもデータ基盤への投資予算を先に割り当てるという判断もなかなか難しいでしょう。

そのため、まず今回のようにAIエージェントによるデータの可視化環境を提供することによって、現状の組織のデータ基盤の状態がデータエンジニア以外にも可視化されます。

プロトタイプの展開段階で一定の好反応を得られれば、ユーザーが使っていくうちに、

「こういうデータは出せないの？」⇒「そのデータはシステムから連携されていないので出せないです」

「なんか数字がずれている気がするんだけど。。」⇒「時々入力されていない日があるようで、そこが欠損値になっています」

「これ同じ物のはずなのに何で別々のデータで出るの？」⇒「マスタが整備されておらず、各組織で独自にIDが発行されているためです」

というように、組織のデータ環境の課題が徐々に浮き彫りになってきます。

このように、実際に見える形として課題が浮き彫りになってくると、「データの品質が重要」というイシューに一気に臨場感が出てきます。

正直、現場の方達からすればデータを適切に入力するというのは面倒な事ではあるのですが、自分の対応した結果が明確に可視化され、組織に共有されるという状態になるとデータ入力に対する意識の高さの醸成にも繋がるかと思います。その重要性の意識が更に高まれば、「やはり上流からの品質担保が重要なので、入力段階からシステム連携して自動化しよう」という話にも繋がるかもしれません。

このようにして、入力フェーズからの品質担保、データクレンジング、データベース基盤整備のサイクルの活性化が進めば、AIやBIの品質や開発効率も高まり、データ利活用の更なる促進が期待できるでしょう。

2. データバリデーションのサポート

繰り返しになりますが、最も重要なのはデータ基盤の整備であるため、データのバリデーションプロセスや課題の可視化もAIでサポートするというのは有効な手段になるかと思います。

例えば、データ基盤にAIを繋ぎ、以下のような観点でチェックさせます。

ディメンジョンとファクトが綺麗に分離されているか
データセット/テーブル/カラムの名前と実際に持っているデータの内容が整合しているか
プロジェクト間で重複するテーブルがないか（二重管理のような形になっていないか）
本来マイナスであるはずのない値やゼロであるはずのない値が入っていないか
前後のデータから見て、明らかな飛び値や異常値のようなデータが含まれていないか
データセット全体の内容から判断して、どのようなデータが不足しているか、または粒度に問題がないか

実際にはビジネス視点でのチェック観点が更に入るかと思います。データベース基盤の整備は一過性のものではなく、放置すれば入力データの質の低下も含め、徐々に品質が下がっていってしまいます。

そのため、静的チェックだけではなく、AIも活用した意味的な観点でのバリデーションも定常プロセスとして実施し、データの品質を担保しておくことで、BIやAIを含め、あらゆるアプリケーションのアウトプットの品質の向上が期待できます。

この点はチェック観点を常にブラッシュアップしながら、自動レポーティングさせる形が望ましいのではないかと思っています。プログラムベースの静的チェックだけでなく、意味的なチェックもできるようになるのは大きな利点かと思います。

3. ネクストアクション支援

LLMの最大の長所であり、BIとの最も大きな違いの一つは自然言語が扱えるという点だと思います。

データの可視化や分析はそれ自体には価値はなく、いかに具体的なアクションに結び付いたか、その行動を促せたかという事が最も重要になります。

BIの場合は、閾値との比較や増加減などについての表現はするものの、数値ベースのレポートを見て、その解釈をするのはあくまで人間になります。

つまり、レポート ⇒ 解釈 ⇒ アクションの流れにおいて、レポートと解釈の間をどう埋めるかが常にBIの課題になるのですが、ここを自然言語を扱えるAIで支援できればアクションに繋がる確率の向上が期待できます。

そのため、従来型のレポートに加えて、事象の分析観点や示唆出し、改善案などもAIで補足する事で、解釈の初動の負荷を下げる事ができます。

データソース拡張の文脈でも少し話しましたが、例えば営業領域であれば、新規契約件数の減少、解約率の上昇などがレポートで出た場合、数値だけ見ると「何が起きているんだ？」となるかもしれませんが、商談情報の議事録データなども見にいく事で、数値では表現しきれなかった原因分析を含めた、データの解釈とアクションまでスムーズに繋ぐ事ができるかもしれません。

これはある種当たり前の話で、部下にデータ分析を依頼した際に、数値だけまとめたレポートで報告されたら「確かにデータは綺麗にまとまってるけど、この後どうするべきかまで考えて提案して欲しいな。。」と内心言いたくなるのと同じ話です。

AIが使えるという事を前提にして、このネクストアクション支援までの拡張を視野に入れる事も、重要な論点の一つになるかと思います。最終的には業務プロセス全体を踏まえたUX設計の中にBIとAIを当てはめていくという形になるかと思います。

まとめ

今回は、AIエージェントによる非定型データ分析と組織のデータ利活用促進の可能性について検討しました。

AIはデータ基盤の整備、可視化・分析からネクストアクションの検討も含め、データ利活用のプロセス全体を支援する可能性を持っています。

まずはデータをユーザーに見える形にすること(臨場感を与える事)、そしてデータ基盤を整備し、データの品質を高めていくことが重要で、組織やユースケースに合わせたスキルの定義を含め、実際はかなり地道なプロセスになるかと思います。

今後のAIエージェント活用検討の一助になれば幸いです。