PKSHAが1人月・月1200ドルで構築したAIネイティブデータ基盤の全貌

• 事実と背景：PKSHAが1人月でdbtとLightdashを軸にした新データ基盤「Laplace」を構築し運用開始。
• 技術的変革：dbtの定義を唯一の源泉とするセマンティックレイヤーと、AIから自然言語で叩ける自作MCPサーバを統合。
• 現場への影響：非エンジニアがBIやAI経由で安全にセルフ分析可能になり、機微情報は期限付き自動剥奪でガバナンスを担保。

開発現場でよくある光景だ。朝一番、Slackに「ダッシュボードの読み込みが終わりません」というCSからの悲鳴が届く。本番データベースのリードレプリカにRedashから直接重いSQLが投げられ、2.5TBに膨れ上がったログテーブルが悲鳴を上げている。クエリはデッドロック寸前、データベースのCPU使用率はスパイクし、インフラ担当者は冷や汗を流しながらプロセスをキルする――。

PKSHA TechnologyのVoiceAgent開発チームが直面していたのも、まさにこの「データ量の増加に伴う分析環境の限界」という生々しい課題だった。従来はRedashからAuroraのリードレプリカに直接SQLを投げる構成だったため、重いクエリが返ってこず、ビジネスメンバーが知りたいことを都度エンジニアに依頼する「人間API」状態が発生。さらに、個人情報（PII）の制御が難しく、安全側に倒した結果としてデータを使える人が極端に制限されるという悪循環に陥っていた。

ここで重要なのは、単に「BigQueryにデータを移行してクエリを速くしました」というインフラの引っ越し話ではない。なぜSRE（Site Reliability Engineering）がデータ分析基盤を作るのか、という思想の確立である。私は、データを元に意思決定する文化こそが、プロダクトの信頼性を高める上での大前提であると考える。システムの可用性やエラー率といったメトリクスを、勘や声の大きさではなく、誰もが納得できるバックデータで語れるか。この問いに対するSREとしての回答が、今回のデータ分析基盤「Laplace」の構築だったのだ。

これは、日本国内で東京ガスが「データメッシュ」への大転換を図り、中央集権的なデータボトルネックを解消しようとしている動向とも深く共鳴する。データを一部の専門家やエンジニアの専有物から解放し、ドメイン知識を持つ現場に分散・民主化していく。そのためには、エンジニアが都度SQLを書いてダッシュボードを作るスパゲッティな運用を根本から破壊しなければならない。安全側に倒しすぎて「誰もデータに触れない」という本末転倒なセキュリティロックを解除し、攻めと守りを両立する新たなアーキテクチャが必要だったのだ。

「BIツールを導入したが、結局誰も使わずに放置されている」――これはデータ活用プロジェクトにおける最大の「無限ループ」だ。なぜ使われないのか。それは、非エンジニアにとって、データベースのテーブル構造や複雑なJOIN条件を理解してSQLを組み立てることが、あまりにも高い障壁だからである。

この課題を解決するために、Laplaceが選択したのは「dbt」と「Lightdash」を組み合わせたセマンティックレイヤーの構築である。セマンティックレイヤーとは、いわばデータベースと利用者の間に挟む「翻訳辞書」だ。dbtの schema.yml を唯一の定義源（Single Source of Truth）とし、指標の定義やテーブル間の結合関係をあらかじめコードとして定義しておく。これにより、利用者はSQLを書くことなく、Lightdash上で「売上」や「前年比」といったビジネス用語を選択するだけで、裏側で安全かつ正確なクエリが自動生成される。

選定にあたっては、Cube + Metabase、Looker、Lightdash Cloudなどの競合を徹底的に比較検討した。その意思決定のプロセスを以下の表にまとめる。

Lightdashのセルフホストを選んだ最大の決め手は、dbtの定義と完全に同期する点だ。定義の二重管理は、エンジニアリングにおける最大の悪（DRY原則の違反）であり、将来の技術負債に直結する。dbt側で定義したモデル構造から、Lightdashの探索単位（explore）が自動生成されるため、定義された結合関係の範囲内でしかクエリできないという強力なガードレールが最初から手に入る。これこそが、AI時代にデータ基盤が備えるべき「Information層」の理想像であると私は確信する。

AIネイティブ時代において、データ分析の主役は人間からAIエージェントへとシフトしつつある。米国におけるAI駆動GTM（Go-To-Market）の最前線や、NECが推進する「AI Platform Service」の動向を見ても、AIが社内データにアクセスして自律的にインサイトを導き出す流れは不可避だ。しかし、ここで我々エンジニアの前に立ちはだかるのが「セキュリティとガバナンス」という巨大な壁である。

LLMに社内の個人情報（PII: Personally Identifiable Information）をそのまま渡すわけにはいかない。Laplaceでは、権限境界をBigQueryではなくBI（Lightdash）層に一本化し、利用者はLightdashまたは自作のMCP（Model Context Protocol）サーバ経由でしかデータに触れない設計にした。その上で、PIIの保護には以下の「3段構え」の鉄壁のガードレールを敷いている。

• 1. 決定的ハッシュ化: rawデータからstagingに移行する際、メールアドレスや電話番号などのPIIはソルト付きの決定的ハッシュに変換。元の値を隠蔽しつつ、同一主体としての集計・分析を可能にする。
• 2. テーブル隔離と属性制御: どうしても生値で使う必要があるPII列は、元のテーブルから切り離して <table>_pii という専用テーブルに隔離。Lightdashの user_attributes（ユーザー属性）を持つ特定の承認者にしかテーブルの存在自体を見せない。
• 3. クエリ監査マート: BigQueryの INFORMATION_SCHEMA.JOBS をdbtでマート化し、「誰が・いつ・どのPIIテーブルを・どんなSQLで読んだか」を完全に可視化する。

さらに、AIクライアント（Claude Codeなど）から自然言語でデータを引くためのMCPサーバを自作し、そこにも「PIIガード」を組み込んだ。コンパイルされたSQLが *_pii テーブルを参照している場合、クエリ自体は実行するが、行の値はLLMに返さず、人間が直接LightdashのURLを開いて確認するよう促す。また、LLMが「動くが、見栄えが最悪なグラフ」を作るのを防ぐため、チャート種別ごとのTipsをAPIの返り値に持たせ、Lightdashの内部ソースから抽出したチャート設定オプションをLLMに参照させる工夫も泥臭く実装した。人間とAIが同じガバナンスの境界線を共有し、安全にデータを探索できる環境。これこそが、AIネイティブなデータ基盤の真骨頂だ。

しかし、華々しい成果の裏には、深夜の障害対応にも似た冷や汗ものの失敗談が隠されている。本番環境の全テーブルに対してCDC（Change Data Capture）を横展開した直後、BigQueryの課金が1日で330ドル（月換算で約1万ドル）相当まで急騰したのだ。

原因は、BigQueryのCDC仕様に対する私の設計ミスだった。DatastreamがbinlogからBigQueryに変更を書き込んだ後、BigQuery側のバックグラウンド処理が max_staleness（鮮度設定）の間隔ごとに変更をテーブルへ反映（マージ）する。この反映処理は、どのパーティションに変更が当たるか事前に分からないため、毎回テーブル全体をフルスキャンする。更新が絶え間なく発生する巨大なテーブルで、この反映処理が頻繁に走った結果、1日の読み取り量が43.5 TiBに達してしまったのだ。

私は即座に、業務上本当にリアルタイムな鮮度が必要なのかを再検討した。結果、分単位の鮮度が必要なテーブルは存在せず、課金の95%を占めていた上位5テーブルは日次更新で十分であることが判明した。テーブルごとに max_staleness を緩めた結果、読み取り量は1日0.3 TiBへと激減し、コストはピーク時の100分の1以下に収まった。この手痛い教訓から得た学びは、データパイプラインの経路を選ぶ際、単にデータの鮮度や整合性だけでなく、「ソース側およびDWH側の課金仕様まで含めたトータルコスト」を設計段階で見極める重要性だ。

現在、LaplaceはGKE Autopilot上でLightdash、dbtのCronJob、MCPサーバをすべてホストし、月額約1,200ドルという極めて合理的なコストで安定運用されている。設計・実装は私1人、コードのほぼすべてをClaude Codeが書くという「1人月」での超高速立ち上げは、LLMとの協働がもたらす開発プロセスのパラダイムシフトを証明した。

最後に、我々エンジニアに問いかけたい。「あなたのチームのデータ基盤は、AIが自律的に探索できるほど、美しくモデリングされているだろうか？」

AIに生のテーブルを丸投げして「よしなに分析してくれ」と頼む時代は終わった。AIが正しくデータを解釈するための「セマンティックレイヤー」をコードとして定義し、ガバナンスのガードレールを敷くことこそが、これからのエンジニアの主戦場である。明日から取り組むべき処方箋は明確だ。まずは、散らかったデータベースの命名規則を統一し、dbtによるモデリングを1から見直すこと。AIに仕事を奪われるのを恐れるのではなく、AIが最も効率よく働ける「データ環境の整備者」へと、我々のキャリアをシフトさせていこうではないか。