AIによるブラウザ操作の自動化でオレオレBIを丸裸にする
AI要約
BIの仕様把握は労働集約的で、特にAPIが存在しないBIは厄介だ。Claude CodeやCodexでブラウザ操作を自動化し、BIの仕様をメモ化していくアプローチについて書く
はじめに
みなさんは「オレオレBI」に苦しめられたことはありませんか？私は何度もある。「オレオレBI」とは、指標やデータソースの仕様がブラックボックス化しているBIのことだ。
- BIの元になっているデータがどこから来たのかわからない。何かのクエリなのか、テーブルなのか？
- （クエリだった場合）このあらゆるSQLのプラクティスに反しているクエリを読むのは… 発狂するほど大変だ。しかも大量にある。最近はAIがSQLを読んでくれるようになったが、クエリの中身はGUIからしか読めないから、ブラウザ操作で全てのクエリを引っ張ってこないといけない。全体像が掴めず、何個あるかわからないのも辛い。
- この折れ線グラフの指標は何を表しているのか。ディメンションは？メジャーは？フィルターは？
- そもそも何のために存在しているのかわからない。
反・オレオレBIのアンサーとしてBI as Codeの考え方が生まれてきたわけだが、諸々あって採用には至らず悩んでいた（後述）。そしたら別のソリューションがあることに気がついた。ブラウザ操作がネックなら、ブラウザ操作を自動化すれば良いのではないか？
前提
- APIが公開されていたり、CLIが存在していたり、MCP ServerがあったりするBIを利用している方には役に立たない手法です。幸せになってください。
- リスクがあり、危険性を伴う手法です。ご利用は自己責任で
AIによるブラウザ操作の自動化でオレオレBIを丸裸にする
やり方は単純で、AIにブラウザ操作を行わせ、BIの仕様を把握させ、メモに起こしてもらうだけだ。
- Claude CodeやCodexはブラウザ操作を行える
- 情報が必要になるたびに操作させると時間が長くかかるため、メモ化させておく
- ただしメモは腐るため、定期的に更新させる
実際にはこんな感じだ。
ユースケースは以下のような感じだ
- データソースの仕様を把握する。データソースで利用されているカスタムSQLや、テーブルを把握する
- 指標の定義を把握する
- 可視化で利用されているディメンションやメジャー、フィルターの条件を把握する
- 権限操作を自動化する
現代のブラウザ操作の自動化にはろいろ手段がある。思いつく限りの手段を載せておく。
| ツール名 | 特徴 |
|---|---|
| Chrome DevTools MCP | 認証情報を引き継がせたいときに楽にできる |
| Playwright CLI | ちょっと操作が重い |
| agent-browser | サクサク動くが、よく混乱している |
| browser-use | まだ試せていない。早いらしい |
| Claude in Chrome | Claudeでサクッと |
個人的には、安定的に動かしたいならChrome DevTools MCP、高速に動かしたいならagent-browserが良かった。とはいえ半年後にはまた情勢も変わっていそうではある。自分の環境に合うものを自分で選べばいい。
おわりに
そんなめんどくさいことをしなくても、ちゃんとAPIがあるBIを使えばいいのでは？
俺もそう思うよ
補足: BI as Codeの欠点について・Lookerに対する批判
BI as CodeはBIの仕様をコード化することで、仕様把握の問題を解決しようとするアプローチだ。そしてBI As Codeのパイオニアと呼べる存在がLookerである。BI as Code自体はアプローチであり、LookerはそのImplementationの一つである。
アプローチそれ自体が問題を解決することはない。アプローチの実践が問題を解決するのである。我々が評価・検証可能なのはアプローチの実践だ。
私はBI最近Lookerを利用していて、BI as CodeのImplementationには注意が必要であると考えるようになった。ただコード化するだけでは不十分なのだ。
- LookMLのコードは学習コストが高い
- BI as Codeの「Code」にあたる部分が、Lookerの場合はLookMLと呼ばれる独自言語である
- LookMLはSQLを抽象化したクエリ言語であるため、SQLの知識がない人にとっては非常に難解であり、学習コストが高い。SQLの知識を持っていても、LookMLの独自の構文や概念を理解する必要があるため、習得には時間と労力が必要である。
- 「コーディングが難しいなら、AIによるコーディングの補助があるからいいやろ」と思うじゃん？（次に続く）
- LookMLのコーディングをする際は、AIによる補助が期待できない
- LookMLのコードはAIがあまり学習していないため、AIによる補助はあまり期待できない。AIによるコーディング支援能力は言語により異なるのである。LookMLは残念ながら、AIの補助が聞きやすい言語ではない。
- そもそもVSCodeなどのローカルエディタも使えないので、ブラウザ独自のエディタぐらいしか開発の手段がない。なお、このエディタの使い勝手は最悪そのものである
- GoogleはLookMLのAIによる補助を提供すると発表しているが、実際に触ってみて、そのコーディング補助能力は… あってもなくても変わらないレベルだった。
- LookerはBIの作り手を一極集中化させる
- BI as CodeでBIを作るためには編集者権限が必要になる。
- Lookerの場合、編集者権限は閲覧社権限に比較すると非常に高価である。したがって、全員に付与するのは難しい。
- 1, 2と合わせると、Lookerはその仕組み上、BIの作り手を一極集中化させるようになっている。専門知識を持った人がBIを作る組織体制を前提としている。
- 分散された体制を志向する組織にとっては、Loookerは相性が悪い。
- 逆に、BIの作り手を大量確保できる組織には相性がいいのかもしれない
とまぁ、BI as CodeのImplementationの一つであるLookerはNot for everyoneな訳である。組織に適したBIを選ぶことが重要である。良い学びになった。