15 万ドルの Looker を HTML ファイルの山で置き換えられるか

多くの企業と同じく、当社も Looker を有償で使っている。年間 15 万ドル、これが Looker の平均ライセンス費用¹で、およそ 300 シート分にあたる。従業員約 500 人、データプラットフォームエンジニアは 3 人。その 3 人が週の大半を費やしているのは、地味な仕事ばかりだ。Snowflake に問い合わせられるデータがある状態を保ち、すでに 2,000 モデルを超えた dbt プロジェクトの面倒を見て、その下で動く Airflow、Airbyte、DataHub、Kubernetes のパイプライン一式を維持する。

今年 2 月、そのうちの 1 人が片手間で HTML ファイルを配信する小さなツールを作った。かかったのは半日。それから 8 か月、週間アクティブユーザーは社内の Looker と同数か、もしかするとそれ以上になり、Looker の利用量は 3 分の 1 減った。

テック系インフルエンサーたちはソフトウェアは死んだと投稿を続け、中にはサブスクを全部解約して vibecode で置き換えたと言う人もいる。AI が B2B SaaS を殺すというのだ。²

SaaS は死んだらしい。ならばエンタープライズ BI ツールも置き換えられるのか。

左図：「self-hosted」と説明された新規 GitHub リポジトリの割合。右図：Hacker News のコメントで「slop」が言及された割合。³

slop は使えるものになった

1 年前、AI の出力の大半は slop だと思っていたし、実際そうだった。我々も「自分のデータと対話する」デモをいくつか作った。テーブルが 4 つしかないおもちゃのようなスキーマなら見栄えはよかったが、我々の規模では一度もまともに動かなかった。SQL はエラーを出さずに実行されたが、数字が間違っていた。エラーが出るよりはるかにたちが悪い。

その後、Opus 4.5 と組み合わせた Claude Code が非常によく使えるようになった。本当に使える。1 月初旬、全社での利用率が急増した。我々のリポジトリで作業でき、我々のツールも使える。しかも、答える前にクエリを走らせて数字を検証できる。賢そうに聞こえる回答を生成するより、はるかに重要なことだ。数週間のうちに、ターミナルを一度も開いたことのなかった財務・オペレーション・マーケティングの人間が一日中プロンプトを書いていた。一夜にして全員がプロンプトを書き、誰もマウスをクリックしなくなった。

ほぼ同じ時期に、Claude が HTML を大量に出力するようになった。分析を頼むと、グラフ付きの単一ファイルが返ってくる。正直に言って、我々の Looker ダッシュボードより見栄えのするページもあった。問題は、それが誰かの Downloads フォルダに置かれたままになることだった。共有するには Slack に投げて祈るしかない。当時 Anthropic は Team と Enterprise 向けの共有可能な artifacts をまだ出しておらず（2026 年 6 月）、我々にはこの新しい種類のダッシュボードを共有する手段が切実に必要だった。

この HTML slop をホストして共有する必要がある

ある日、チームの Maddy が、全部ウェブサーバーに置いて内部ドメインを割り当てればいいと言い出した。その日の終わりまでに、彼女は vibe coding で全部作り上げた。ファイルを S3 に保存し、前に SSO をかけた小さなサービスで、（一応の）テストも付いている。我々のものはもともと全部 Kubernetes 上で動いているので、サービスのデプロイは実質 Terraform module と Helm chart を 1 つずつ足すだけだ。このインフラがすでに揃っていたことが、話をずっと簡単にしてくれた。

彼女は小さな Python スクリプトを書いて Claude plugin としてパッケージした。ユーザーが Claude に HTML を書かせると、スクリプトがそれを（SSO の内側に）プッシュし、社内の誰でもリンクを開けば見られる。当初、ファイルはただの静的 HTML だった。3 月に試しにやってみようということになり、閲覧者自身の Snowflake OAuth token を使うリアルタイムクエリ API を追加した。これが今年いちばんの判断だった。

結局、権限モデルは自分たちで書く必要がなかった。Snowflake にもともとある。何年も保守してきたロール体系がそのまま使える。Snowflake が営業テーブルを読めないと判断すれば、ダッシュボードからも読めない。4 月には、Snowflake OAuth が唯一のログイン手段になった。

皆に好かれている理由は、BI 業界にとっては少し耳が痛い話だ。これらのダッシュボードは、単純に見栄えがいい。

Looker のタイルはただの枠で、グラフの種類は数えるほどしかなく、配色も 1 種類しかない。どれも同じに見える。醜くて、個性のかけらもない。

固定タイルをやめ、自由に HTML を書けるようにした。プロンプトを何度も調整し、納得のいく見た目にできるようにした。ユーザーはこれを気に入った。4 月にメールと Slack へのエクスポート、5 月にパラメータを追加すると、週間アクティブユーザーは 3 月の 23 から 6 月には 136 まで増えた。経営陣が互いにリンクを送り始めた。ユーザーはさらに独自の使い方を見つけていった。こちらが想定もしなかった用途を開拓し、ダッシュボードをスケジュールで自動再生成させ、ボタンを追加し、BI ツールなら絶対に許さないような奔放なデザインやインタラクションを作り込んだ。

この段階のセキュリティはひどかった。本当にひどい。ダッシュボードの JavaScript はユーザーのセッションと同じオリジンで動き、権限管理は一切なく、従業員全員がすべてのダッシュボードを読めた。ほぼ巨大な XSS 脆弱性で、どのダッシュボードも開いた人の権限でコードを実行し、その人になりすましてデータを持ち出せた。分かっていたが、それでもリリースした。社内ツールで VPN と SSO の内側にあり、他にこれを実現できるものがなかったからだ。

よし、なら本気でやるか

うちのチームでは「いっそ BI ツールを自作しよう」がしばらくネタになっていた。それが数か月続いて、さすがにこれはまずいぞと気づいた。自分たちでも口にするのが恥ずかしいセキュリティモデルの上に、何か月も vibe-coding を積み上げてしまい、社員の半分がそれを使っていた。冗談はやめて、真面目に話をした。BI ツールを作ろう。白板の前に立ったのは、主にセキュリティモデルをどう直すかを見極めるためで、ついでに捨ててはいけないものを揃えておくためでもあった。同じ S3 bucket のままで、移行はしない。すでに使っている人に問題を起こさない。リリースはこれまでと同じくらい簡単に。

全員が同意した点が一つある。誰でも今まで通り一言投げれば任意の HTML を上げられる。レビューの工程も、テンプレートも、使えるコンポーネントのホワイトリストもない。これはこれからも守る。

人と自分のダッシュボードの間に制限を一つ足すたびに、その人は Downloads フォルダに追い返される。

本当に重要なガバナンスはもともと上流、つまり dbt モデルと Snowflake のロールで済んでいる。だからダッシュボード自体は好きにやればいい。緩くても、速くても、見栄えが良くても構わない。

解決すべき問題は 4 つ。

スクリプトの山をコネクタ一つに。 アップロード用スクリプトは 2 つの repo と 1 つのプラグインにコピーされ、どれも少しずつ違っていた。それを全部、全社向けのリモート MCP コネクタ一つに置き換えた。これで claude.ai、Claude Code、Claude in Slack、そして自社の分析 agent が同じツール群を呼ぶことになる。コネクタは Snowflake の token をそのまま下流に渡し、API 側は SELECT CURRENT_USER() で本人確認をする。AI がアップロードしたものは必ず下書きになり、誰かが Publish を押さないといけない。

すべてのダッシュボードを敵とみなす。 ここは本気で詰めて考える必要がある。この製品は設計上ほぼ XSS そのもので、誰でも JavaScript をアップロードでき、それが同僚のブラウザで実行される。審査はなく、その同僚が CFO かもしれない。XSS は製品そのものだから塞ぐことはできない。だからこそ、XSS が何にも手を届かせないようにするのが我々の仕事になる。セキュリティモデルが「敵とみなす」から出発するのはそのためだ。各ダッシュボードは別オリジンのサンドボックス iframe 内で動き、cookie には触れず、厳格な CSP の下に置かれる。通信できる相手は親ページだけで、postMessage 経由で通信する。親ページはメッセージの送信元を検証し、セッションを付けて API を呼ぶ。コンテンツトークンの有効期限は 1 時間で、1 つのダッシュボード、1 人の閲覧者、1 つのホストに対してのみ有効だ。

サンドボックスが守るのはブラウザだ。それとは別にメタデータサービスも構築していて、こちらは各ダッシュボードの新バージョンを非同期で読み取る。HTML 全体と Snowflake クエリを抽出し、ページがどのスクリプトを読み込み、どこへデータを送っているかを調べたうえで、一連のルールがその事実に判定を下す。ほとんどのルールは報告のみで、dbt モデルを経由せず生データを直接読んでいるダッシュボード、バージョンが固定されていないスクリプト、90 日間誰も開いていないダッシュボードを洗い出す。一部のルールはその場でブロックできる。ここでは誰も使っていないパッケージ由来のスクリプトや、WebRTC 接続がそれにあたる。WebRTC は CSP では止められない漏えい経路だ。ブロックされたダッシュボードは読み込まれず、閲覧者には警告が表示され、承諾しない限りページは動かない。

ID と権限は Snowflake に任せている。 すべてのクエリは閲覧者自身のトークンで実行される。ダッシュボードを共有しても、データへのアクセス権まで共有したことにはならない。これはセキュリティ上の利点であり、同時に手間を省く利点でもある。データ権限を自前で作ったり保守したりする必要がまったくなかったのは、ログインする全員が、もともと正しいロールを持つ Snowflake ユーザーだからだ。

コンテンツ管理。 こちらは vibe coding で 1 週間ほどで書き上げた。設計はほとんどしていない。スペース、フォルダ、共有は Google Drive をそのまま踏襲した。誰もが Google Drive の使い方を知っているからだ。viewer、editor、owner があり、権限はフォルダツリーを下へ継承し、最も強い権限が有効になる。バージョンはコンテンツハッシュで保存し、あるバージョンを復元するとドラフトが得られる。ほかに検索、いいね、スケジュールエクスポート、HR システムから毎時同期するチームがある。セキュリティモデルと比べてみてほしい。頭を本当に使ったのは、ほぼそこだけだ。

開発には数週間かかった。そして作り上げた。

そこから広まった。人々は Slack のスレッドで @Claude を呼び、ダッシュボードを受け取るようになった。うちのアナリスト agent は自分のダッシュボードを公開するし、CI から直接公開するリポジトリもあり、大半は自分の Claude から公開している。だからどのダッシュボードにも、多かれ少なかれ作った人の性格が出ている。今ではどこにでもある。

325 コミット、約 74,000 行のコード（うち 20,000 行はテスト）、Claude のトークン代は約 $6.4k。

これがこちらの全請求額だ。8 か月、エンジニア 3 人が空き時間に作り、何人かの友人が PR をくれた。コードの大半は Claude が書いた。我々は白板に絵を描き、さんざん議論し、すべてをレビューした。

ダッシュボード 1 枚あたり $0.50、これは BI にとって何を意味するのか

Looker の利用量は徐々に減っているのであって、一気に崩れたわけではない。すべてを移行したわけではない。まだ Looker を使っているチームもあるし、代替のないダッシュボードもある。実際に新しいやり方へ移行させたのは、ダッシュボードを 1 つ作るコストが下がったことだった。では、どれくらい安くなったのか。エンジニアの時間ではなくトークンに払うとなると、定量化しやすいのが利点だ。

ここではアナリスト agent を基準に使う。正確に計測できる構築者だからだ。実行ごとにトークンとコストが記録され、リリースはそれを生成した実行までたどれる。

最初の質問から最終的なページまで、ダッシュボード 1 つあたりおよそ 100 万トークンを agent が消費することがわかった。Opus 5.5 に移行してから、ダッシュボード 1 つのコストは約 $2.50\text{か}\text{ら}$0.50 程度に下がった になった。agent の仕事は変わっていない。トークンが安くなっただけだ。ここが要点で、いまやソフトウェアを作るコストとはトークンのコストであり、その価格は下がり続けている。

BI ツールとは要するにクエリをグラフに変えるツールであり、いまやグラフ 1 枚のトークン代はおよそ $0.50 で済む。その部分に 15 万ドルのライセンス料を払うのは、なおさら筋が通らない。

自前で作るか、買うか

2 月の最初のコミットから今日までの、プロジェクト全体の請求額は次のとおりだ。

今は自前のデータベースを持ち、AWS 上で動かしているので、年間およそ $6k\text{か}\text{か}\text{る}\text{。}\text{こ}\text{れ}\text{に}\text{機}\text{能}\text{追}\text{加}\text{の}\text{た}\text{め}\text{に}\text{使}\text{う}Claude\text{の}\text{費}\text{用}\text{が}\text{加}\text{わ}\text{り}\text{、}7\text{月}\text{以}\text{降}\text{は}\text{月}\text{お}\text{よ}\text{そ}$1.3k。年間 $20k\text{と}\text{し}\text{て}Looker\text{の}$150k と並べると、この $20k の大半は、現状維持ではなく、我々自身が新しいものを作るために使っている。

そもそも Looker を買ったとき、我々が手に入れたのは 4 つだった。グラフを描く UI、権限モデル、セマンティックレイヤー、そしてホスティング先。今は Claude がグラフを描き、ダッシュボードは 1 つずつ作っている。

Snowflake には元々権限があり、dbt にはセマンティクスがあり、HTML ファイルを数個ホスティングするのに月およそ 500 ドルかかる。

これらを差し引いて残るのは、15 万ドルの請求書だ。

これは我々だけの話ではない。堅実な老舗企業が、非常に高価な分析サブスクリプションを解約する例を、最近よく耳にする。Amjad Masad はPlatformer にReplit での同じ経験を語っている。データウェアハウスを本番の Postgres につなぎ、レポートを自分たちで作れるようになった時点で、彼らは「分析プロダクトの大半を解約または縮小した」という。

我々の場合、既存の技術スタックの上にダッシュボードツールを自前で作るコストは、Looker に払う額のほんの一部で済んだ。我々にとって重要なものは、もともと dbt と Snowflake の中にあった。モデル、権限、データだ。Looker はその上に載って、それらをダッシュボードに変えていた。置き換えられるのはまさにこの層だと分かった。

上の請求額には、最大のコストがまだ含まれていない。我々自身だ。エンジニア 3 名が 8 か月。しかもデータプラットフォームチームがもともと抱えていたすべての仕事——パイプライン、dbt プロジェクト、データウェアハウス、Kubernetes クラスタ、オンコール——の片手間でやった。そのどれも止めてはいない。正直な工数は出せない。この時間は他のあらゆる仕事に分散しているからだ。専任のチームを雇ってやる必要があるなら、話は変わってくる。

土台としてしっかりしたプラットフォームがあり、それをよく知るチームがいるなら、残るのはほぼ Claude の時間だけであり、Claude の時間は安い。

線引きは規模だと思う。AWS と Snowflake が売っているのは、誰も vibe-code できないものだ。データセンター、PB 級の価格で提供されるストレージ、何百万もの他の顧客がコストを分担してくれるおかげで安い計算資源。BI は特に脆いと感じる。その価値の多くは——少なくとも我々にとっては——ダッシュボードを組み立てて見せることにあるからだ。Claude は今、それを数セントでやる。真の規模の優位性を持つ製品は別だが、より多くの企業が BI スタックの一部を自前で置き換え始めても、驚きはしない。

Claude Dashboards はどうなのか？

Anthropic は 10 月 8 日にベータ版の Claude Dashboards をリリースした。この記事の公開の 1 週間前だ。ならば当然、待ってそれを買えばよかったのではないか、という疑問が浮かぶ。

待つことはできなかった。我々が着手したのは 8 か月前で、当時それは存在しなかった。もし今日ゼロから始めるなら、正直なところ、まずそれを検討するだろう。AI ネイティブで、Looker のようなレンダリングの問題もない。チームに今何もないなら、それを選ぶのがおそらく正解だ。

我々にとって、ダッシュボードは一部にすぎない。このツールはすでにチームの既存の働き方に組み込まれている。我々の agent コントロールプレーン、分析プラットフォーム、Slack につながり、さらに自前で組んだワークフローも多数ある。Claude Dashboards がその一部をカバーできたとしても、それらをつなぎ合わせる方法は結局自分たちで解決するしかない。しかも機能が変わり、価格が上がれば、それに追随するしかない。

答えは同じだ。自社の業務に合ったソフトウェアが必要で、それを動かすプラットフォームと専任のチームがすでにあるなら、自分で作ればいい。ただし、製品の堀が規模そのものである場合は別だ。

Footnotes

1. Vendr が Coefficient 経由で公表した355 件の Looker 取引の平均額 15 万ドルと一致する。 ↩

2. そのうちのいくつかの投稿：AI Is Killing B2B SaaS（2026 年 2 月、729 件のコメント）、AI agents are starting to eat SaaS（2025 年 12 月）、SaaS is just vendor lock-in with better branding（2025 年 6 月）、Every SaaS business will become a harness around a model（2026 年 10 月）、そして反対の立場をとる why SaaS isn't doomed（2026 年 7 月）。 ↩

3. どちらの線も 2023 年初を 1 倍の起点とし、3 か月の平滑化を施している。GitHub については、self-hosted を名乗る新規リポジトリを、実のある説明を持つ新規リポジトリと比較した。今の GitHub はボットが作った空のリポジトリであふれているからだ。Hacker News については、slop に言及したコメントを、その月の全投稿と比較した。 ↩