AI ネイティブなデータ分析基盤を作った話

はじめに

PKSHA Technology で PKSHA VoiceAgent（以下 VoiceAgent）の SRE をしている三浦です。2026 年 2 月に入社しました。

本記事は、データ分析基盤を構築した話です。データ分析基盤自体はもはや珍しいものでもありませんが、2026 年現在に相応しい手法と構成でできたのではないかと自負しています。

VoiceAgent では、データ量の増加とともに分析環境が限界に近づいていました。PKSHA には Azure Databricks 製のデータ基盤が先にありますが、プロダクト特化の仕組みとして作られていたため、VoiceAgent 向けを新しく作ることにしました。それがデータ分析基盤「Laplace」です。構築の開始から約 1 か月で利用者に開放し、そこから 2 か月運用しています。

この記事の要点

• セルフサービス分析
  • dbt の schema.yml を唯一の定義源とするセマンティックレイヤーを Lightdash で構築した。指標の定義やテーブルの結合はあらかじめ決まっているので、利用者はデータの構造を知らなくても正しい集計にたどり着ける
  • Lightdash の API を包む MCP サーバを用意し、AI クライアントから自然言語で同じ指標を引けるようにした。BI の操作を覚えずに分析でき、根拠 URL で検算できる
• データガバナンス
  • 権限境界を BI 層に置き、PII の列は専用テーブルに切り出して隔離し、user_attributes を持つ人だけに見せる。PII を含まないデータは全員に開放できる
  • 機微情報は既定では誰にも見えない。利用目的と範囲をデータの管理者が確認して承認した人にだけ、期限付きで権限を付与し、期限で自動剥奪する。誰がいつ何を読んだかを監査ログで追え、AI 経由でも PII の値は LLM に返さない
• プロダクト横断
  • インフラをプラガブルにし、設定ファイル 1 枚の追加でプロダクトを受け入れる。dbt と Lightdash もプロダクト単位に分けたので、他プロダクトのデータは見えない
• 1 人月で構築
  • 設計と実装は私 1 人で担い、SQL を含めほぼ全てのコードは Claude Code が書いた。着手から公開までは 1 か月
  • OSS の Lightdash をセルフホストし、不足は小さな周辺ツールで補った。BI や DWH のライセンス費はなく、運用もクラウド利用料の月 1,200 ドル前後で済んでいる

本文では、なぜ作ったのか、何を選んだのか、運用して何が起きたのかを順に書きます。実装の詳細には深入りせず、全体像と設計判断に絞ります。

以前の状態と 3 つの課題

VoiceAgent の分析は、Redash から Aurora のリードレプリカに直接 SQL を投げる形で行われていました。分析基盤と呼べる層はなく、本番 DB のレプリカがそのまま分析対象でした。ログ系のテーブルは大きく、最大のものは約 2.5 TB あります。

この構成には 3 つの課題がありました。

1. 重いクエリが返ってこない。データ量の増加でレスポンスが限界に達していた。
2. ビジネスメンバーが知りたいことを、都度エンジニアに依頼する必要がある。ダッシュボード 1 枚ごとにエンジニアの手が要る。
3. 安全側に倒した結果、データを使える人が限られていた。PII（個人情報）を含むテーブルと含まないテーブルを分けて権限を設定できず、PII を含まない分析でもアクセス権限を絞らざるを得なかった。

課題 3 が厄介で、「権限を絞る」という対処が課題 2 を悪化させます。ここを解かないと、エンジニアがボトルネックのままです。

目指したもの

SRE がなぜ分析基盤を作るのか

SRE としての問題意識が出発点です。データを元に意思決定する文化は、プロダクトの信頼性を高める上で必須だと考えています。そのプロダクトの信頼性を、我々自身や顧客が納得感を持って語れるのか。プロダクトが正しい方向へ進化しているのか。その判断を、勘や声の大きさではなくデータで支えられるのか。施策の ROI をバックデータを元に語れる土台を作りたかった、というのが動機です。

私は前職までで Tableau や Looker を使ったデータ活用プロジェクトに、利用者側と提供者側の両方で関わってきました。その経験から「BI ツールを入れれば使われる」わけではないことは身に染みていました。

AI 時代のデータ分析プラットフォームに必要なもの

データ分析は手段であって目的ではありません。欲しいのは課題の解決で、データはアクションにつながって初めて価値を持ちます。この構造を DIKW モデル（Data → Information → Knowledge → Wisdom）を借りて整理しました。ただし Wisdom は経験や倫理に依存する個人的なもので、プラットフォーム化できません。そこで Wisdom を Insight と Narrative に分解し、最後に Action を置いた 6 層で考えています。

層	何をするか	AI 以前の担い手	AI 以後の担い手
Data	集める（DWH、パイプライン）	Eng	変わらず Eng
Information	定義する（指標名、計算ロジック、関係性を一元管理）	Eng + PdM	重要度が上がる。AI が正しく解釈する土台
Knowledge	整理する（ダッシュボード、ゴールデンクエリ）	作るのは Eng、見るのは全員	人と AI の協働
Insight	得る（探索的分析、「何が起きていて、なぜか」）	データに強く、BI 等のツールに習熟した一部の人	AI が主体
Narrative	語る（示唆をアクションに接続する物語）	PdM / CS	AI がドラフト、人が判断
Action	動く（業務の実行、タスク起票、通知）	全員	定型は AI、非定型は人

AI 以前のボトルネックは、Insight と Narrative の生成が一部の人に依存していたことです。データに強いだけでなく、BI などのツールへの習熟も要るからです。AI 以後の最大の変化は、この Insight 層の民主化です。全員が AI を介して Insight へ到達できるようになります。

そのために不可欠なのが Information 層、つまり指標定義の一元管理です。AI にテーブルの生の列名を渡しても意味はありません。「この列は売上で、前年比はこう計算する」という定義が一箇所に整備されていて初めて、AI は正確な示唆を出せます。セマンティックレイヤーは、AI 時代にはむしろ重要度が上がる層です。

一方で、AI がデータへのアクセスを広げることはリスクでもあります。層ごとにガードレールが要ります。Data 層では見せてよいデータだけを AI に渡す。Insight 層では AI の回答に根拠クエリを添え、検証できるようにする。Narrative から Action では、非定型の判断は人が責任を持つ。

目指す体験は、分析ツールを開くことなく、日常の動線の中で問いを投げて答えを得ることです。利用者が意識するのは問いとアクションだけで、プラットフォームは表に出ません。

Laplace として作ったのは、この 6 層のうち Data、Information、Knowledge の 3 層と、Insight 層の入口（MCP）、それにガードレール（ガバナンス）です。Narrative と Action の支援はこれからですが、そこへ積み上げられる土台として設計しています。

3 つの目標

掲げた目標は 3 つです。

• ビジネスメンバーが使わなければ意味がない。非エンジニアがセマンティックレイヤーの上で、妥当な分析結果を自分で得られること。
• プロダクト横断。新しいプロダクトが、設定を追加するだけで分析を始められること。
• AI から使えること。BI の使い方を知らなくても、自然言語で分析できること。セルフサービス分析のもう 1 つの入口。

2 つ目について補足します。新しく作るなら、せっかくなので他のプロダクトも載せられる形にしたいと考えました。VoiceAgent に特化して得られるものがあるかも検討しましたが、見当たりませんでした。それなら汎用化して、VoiceAgent を最初の 1 プロダクトとして載せればよい。そう考えて、最初から横断前提で設計しました。

横断前提は制約としても働きました。自分たちだけの基盤なら、「便利だから」「最短だから」という理由で突拍子もない構成を力技で通していた可能性があります。横断前提だと、基盤側に特定プロダクトの事情を作り込めません。たとえば CDC（Change Data Capture）で届く最新データと別経路で届く過去データの合流は、基盤側に特殊な取り込みを作らず、dbt のモデルの中で行う方式にしました。この制約のおかげで、データフローとインフラの責務が整理されました。

全体アーキテクチャ

できあがった構成の全体像です。

データの流れは単純で、次の 4 段です。

1. データをまず BigQuery に集める（GCS 経由の push、Datastream の CDC、Glue の直接書き込み）
2. dbt で分析しやすい形に整える（raw → staging → mart）
3. Lightdash で「何をどう集計するか」をセマンティックレイヤーとして定義する
4. 利用者は BI として見るか、MCP 経由で AI から自然言語で使う

1 段目のデータ連携は、設計時はスナップショット中心の想定でしたが、Aurora の課金仕様で想定が外れて CDC が主経路になりました。経緯はコラムに畳んでおきます。

コラム: スナップショット中心のはずが、CDC が主経路になった経緯

想定していたこと

• 原則は「CDC は最後の手段」。まず日次スナップショットで足りないかを問う
• スナップショットは全件像なので更新と削除が自動で整合し、小〜中サイズのテーブルなら最も軽い
• 各プロダクトがキーレス（Workload Identity Federation）で GCS に Avro を push し、BigQuery は external table で参照する

想定が外れたこと

• Aurora のスナップショットエクスポートは、出力するテーブルのサイズではなくインスタンス全体のデータ量に課金される
• 数 MB のテーブルを 1 つ出すだけでも、数 TB 分を毎回払う。日次で回すと月 1,000 ドル超
• 一方 CDC（Datastream）はソース側の変更量に課金されるため、変更の少ないテーブルはほぼ無料で運べる
• さらに、膨大なログデータの一部に「鮮度 30 分以内、かつ INSERT 後の UPDATE も反映」という要件が出た。スナップショットでは満たせない

結局どうしたか

• Aurora は 200 テーブル弱を全部 CDC に載せ、Datastream が binlog から BigQuery に直接書き込む経路を実質の主経路にした
• CDC で運ぶとコストが見合わない太い列だけは CDC から除外し、Glue が毎時直接書き込む
• スナップショット push は AWS のコスト集約データで現役。他のデータソースや他プロダクトでは今も最初に検討する選択肢
• 学び: 経路を選ぶ軸は鮮度・更新整合・コストの 3 つだが、コストはソース側の課金仕様まで含めて見る

Lightdash は OSS で API も豊富なので、標準機能で足りない部分は周辺ツールで補えます。期限付きの権限付与と条件付きの Slack 通知は、小さな自前ツールとして API の外側に足しました。BI 本体には手を入れていません。

実行基盤は GKE Autopilot の 1 クラスタで、Lightdash、dbt の CronJob、MCP サーバ、周辺ツールがすべてここで動きます。BI のためだけに Kubernetes を置いたわけではなく、自前ツールを増やすたびにデプロイ、キーレス認証（Workload Identity）、公開経路（Gateway API）を使い回せるのが利点です。

プロダクト横断

インフラは Terraform で、プロダクト横断を前提としたプラガブルな構成です。基盤側は汎用エンジンとして固定し、プロダクトの追加や変更は products/<product>/config.yaml という設定ファイル 1 枚に収まります。dbt はプロダクトごとに独立したプロジェクト、Lightdash もプロジェクト単位で招待と権限を分けるので、他プロダクトのデータは見えません。

セルフサービス分析: なぜ Lightdash か

DWH は BigQuery、変換は dbt です。ここは 2026 年時点の定石どおりで、悩みは少なかったので省きます。悩んだのはセマンティックレイヤーと BI です。

要件は次の 4 つでした。

• データ種類ごとの権限制御ができる
• MCP が利用できる
• DWH に直接接続し、独自データ形式を強要しない
• メトリクス定義の一元管理とガバナンスを提供できる

候補は Cube + Metabase、Lightdash Cloud、Lightdash セルフホスト、Looker です。Lightdash Cloud は要件を最も網羅していましたが、この段階では ROI が見合わず却下しました。Looker はエンタープライズ契約が必須で高コストです。Cube + Metabase は OSS で無料、API も MCP 向けに洗練されていましたが、dbt と Cube でセマンティック定義が二重管理になる点が致命的でした。

Lightdash セルフホストを選んだ決め手は、dbt の schema.yml がセマンティック定義の唯一の源泉になり、二重管理が構造的に消えることです。dbt のモデル構造から explore（Lightdash 上の探索単位）が自動生成されるので、定義した join 関係の範囲内でしかクエリできないというガードレールが最初からあります。さらに、利用が全社に広がって ROI が見合えば、dbt 側は無変更で Lightdash Cloud へ移行できる道も残ります。

定義の源泉を 1 つにしたことは、後述する MCP（AI が定義済みの metric だけを使う）とガバナンス（閲覧制御を dbt の meta で宣言する）の前提にもなっています。

データガバナンス: 読んでよいデータを制御する

「使える人が限られていた」という課題への答えです。方針は権限境界を Lightdash 層に置くこと。利用者は Lightdash か MCP 経由でしかデータに触れず、BigQuery を直接読めるのはパイプラインのサービスアカウントとメンテナだけです。BigQuery に人の権限を配らないので、制御の実装が Lightdash の 1 か所に集まります。

その上で「誰がどのデータを読んでよいか」は、Lightdash の user_attributes（ユーザーごとに持たせる属性値）で制御します。制御の単位は 2 つです。

• テーブル隔離。dbt の meta で required_attributes を宣言したテーブルは、その user_attributes を持つ人にだけ見える。持たない人には、テーブルの存在ごと見えない。
• 行レベルセキュリティ（RLS）。user_attributes の値を生成 SQL のフィルタへ注入し、「CS 担当者には担当テナントの行だけを見せる」のように行を絞る。

どちらも定義は dbt の schema.yml に置くので、誰が読んでよいかがセマンティック定義と同じ場所、同じ Git 管理に載ります。

PII への適用: 3 段構え

最初の適用先は PII で、3 段構えで守っています。

段	何をするか
ハッシュ化	raw には全列を持ち込み、staging で結合や識別に必要な PII 列（メール・電話・IP・氏名）はソルト付きの決定的ハッシュに置き換える。必要のない PII 列は staging に持ち込まない
ハッシュ化せずに使う PII 列	元のテーブルから切り出して <table>_pii という専用テーブルに隔離し、user_attributes を持つ人にだけ見せる
事後監査	BigQuery の INFORMATION_SCHEMA.JOBS を dbt でマート化し、誰が・いつ・どの PII テーブルを・どんな SQL で読んだかを追う

BigQuery の Policy Tags による列レベル制御は採りませんでした。列単位のタクソノミー管理と IAM 運用が重く、カジュアルに使える基盤という方針に合わないためです。テーブル隔離と user_attributes と事後監査で、露出の最小化と説明可能性を軽い運用で満たしています。

ハッシュを決定的にしているのは、同じ連絡先からの複数回の利用を同じ主体として集計できるようにするためです。ソルトは基盤側だけが保持し、ハッシュ値だけから元の値は復元できません。

権限は申請して期限付きでもらう

機微情報のテーブルは、既定では誰にも見えません。見えるのは、申請して承認を受けた人だけです。承認するのはデータの管理者で、申請された利用目的と範囲がデータの扱いとして問題ない場合にだけ許可します。

この流れを人手で回す運用は続かないので、前述の周辺ツールの 1 つとして付与ツールを用意しました。申請 → データ管理者が承認 → 期限付きで user_attributes を付与 → 期限到来時に自動剥奪 → 履歴を監査に残す、までを自動化しています。

付与の履歴は append-only の監査ログとして BigQuery に毎時スナップショットされます。クエリ監査のマートと突合すると、「誰に・いつ・どの user_attributes が付与されていて、その間に PII テーブルへどんなアクセスがあったか」を 1 枚のダッシュボードで追えます。

これで、PII を含まない mart は全員が自由に使え、機微情報は承認を経た人だけが期限付きで使う、という形になりました。

AI からのセルフサービス分析: MCP サーバ

利用者にビジネスメンバーを含むため、各自がローカルで MCP サーバを起動する運用は強要できません。基盤側で HTTP サーバとしてホストするのが前提です。Lightdash 公式にも組み込みの MCP がありますが、Enterprise Edition の機能です。今回は OSS のセルフホストで小さく始める方針なので、MCP も OSS の @lightdash-tools/mcp をベースにコードを取り込み、自前で用意しました。この基盤のガバナンスと運用に合わせて、PII ガード、根拠 URL の同梱、周辺ツールとの連携などを追加実装しています。認証は利用者ごとの OAuth で、MCP 側に独自の権限は作っていません。人間と AI が同じ権限境界とガバナンスを通ります。

たとえば Claude Code に次のように頼みます。

すると、このダッシュボードが Lightdash 上にできます。KPI、日次トレンド、曜日と時間帯のヒートマップ、用件の Top 10、通話フローのサンキー図まで、定義済みの指標だけで組まれています。

AI に PII を読ませない

MCP は利用者ごとの認証なので、user_attributes による境界はそのまま適用されます。しかし権限を持つ人が AI 経由で PII を引くと、値が LLM に渡ります。そこで MCP のクエリ実行ツールに PII ガードを入れました。コンパイル済み SQL の FROM や JOIN が *_pii テーブルを参照していたら、クエリは実行しますが行の値は返しません。成否、行数、Lightdash で開ける URL、SQL は返すので、本人は Lightdash で値を確認でき、分析は止まりません。

この判定を信頼できるのは、*_pii という命名、data_class: pii というラベル、required_attributes の 3 点の整合を dbt 側の CI lint で強制しているからです。人間向けの目印であると同時に、MCP サーバが遮断判定で使う契約でもあります。

LLM が妥当なチャートを作れるようにする工夫

実際に使ってもらうと、LLM が「正しく動くが分析としては微妙」な結果を出す場面が目立ちました。データが取れることと、妥当な分析が出ることは別です。利用側で見つかった落とし穴は、クライアント側のスキルに頼らずサーバ側へ組み込んでいます。Claude Code でも Slack bot でも同じ品質にするためです。やったことは 4 つあります。

チャート種別ごとに「向いている分析」を添える

チャート種別の一覧を返すツールに、Lightdash で使える 10 種類の型ごとに、どんな分析に向くかの tips を持たせました。時系列なら折れ線、構成比なら積み上げ、といった判断を LLM がその場で参照できます。

チャート設定のオプションを Lightdash 本体のソースから埋める

Lightdash の公式ドキュメントは UI 機能の説明が中心で、チャートをコードで定義するときのキー名や enum 値がほとんど書かれていません。LLM が設定を推測して誤り、意図しない見え方になることが続きました。そこでデプロイしているバージョンのソースから、全 10 型の設定キーと取りうる値、軸ソートの実仕様、series の構造、参照線や凡例の指定方法を抽出し、ツールの返り値に持たせました。

結果に根拠 URL と SQL を同梱する

データ行と一緒に、Lightdash でそのまま再現できる URL と compiled SQL を返します。ツールが URL を返さないと、クライアントの LLM が誤った URL を組み立てて提示する事故が起きました。以後はチャートやダッシュボードを返す全ツールに URL を同梱し、URL を自作しないよう説明文に書いています。

応答を LLM 向けに整形する

Lightdash の REST 応答は UI 用で、LLM が使うラベルや説明は 1 割ほど、残りは構造の冗長性です。大型の explore では 1 応答が 256 KB に達してコンテキストを圧迫していました。構造を削って意味を残す方針のもと、サーバ側で整形しています。未知のフィールドで失敗したときは候補を同梱して返し、往復 1 回で自己修正できるようにしています。

1 人で作る: コードはほぼ全部 LLM が書いた

この基盤の構築は、私 1 人と Claude Code で行いました。利用者側のメンバーには要望やフィードバックで積極的に関わってもらいましたが、設計と実装は 1 人です。コードは SQL を含めほぼ全て Claude Code に任せ、私自身はコードを書いていません。dbt のモデルとセマンティック定義は、Claude Code がプロダクトのリポジトリと Notion を探索し、どのテーブルが何を持つかを整理したうえで、そのまま生成しました。Aurora の全テーブルを mart に出し、そのために作った dbt モデルは staging と mart を合わせて 577 本です。dbt リポジトリの実装コミットはほぼ全てが Claude との共著です。

LLM に任せる代わり、仕組みで縛ることにしました。

• PII 命名の CI lint、Terraform のユニットテスト、MCP の差分スモークテスト
• コミット本文に「なぜ・実測値・トレードオフ」を残す運用
• 構築フェーズは計画ファイルを唯一の正とし、作業前に読み、終了時にロードマップ・進捗・決定ログを更新する。決定の撤回も決定ログに残す（100 件超）

人が守る規約は破綻しうる、という考えは設計にも通しています。たとえば dbt はモノレポの中でプロダクトごとの独立したプロジェクトとしました。dbt のモデル名はプロジェクト内でグローバルに一意で、同名モデルがあれば parse がエラーになります。命名規約で避けるのではなく、プロジェクト境界を名前空間の境界にして、衝突を仕組みで防いでいます。

結果

2 か月運用した時点の数字です。

項目	値
社内ユーザー	29 名
ダッシュボード	32 枚
コンテンツ閲覧	4,500 回超
月額コスト	約 1,150〜1,250 ドル

Redash では返ってこなかった重いクエリの問題は、BigQuery に集めた時点で解消しています。Redash で運用していた主要なダッシュボードは Laplace へ移行済みです。請求に使う課金件数のような間違えられない数字は、元の SQL との一致を検証してから置き換えました。

「ビジネスメンバーが使わなければ意味がない」に対しては、プロダクトの利用状況、解約リスク、課金集計といった業務側のダッシュボードが、エンジニア以外の手で作られるようになりました。

PdM からは「Laplace なしでの施策検討には戻れない」、CS からは「顧客への改善提案に Laplace が欠かせない」という言葉をもらいました。

（おまけ）失敗談: CDC で 1 日 330 ドルを焼いた

運用を始めた直後に冷や汗をかいた話も書いておきます。CDC を本番の全テーブルに横展開した直後、BigQuery の課金が 1 日 330 ドル相当まで跳ねました。CDC のコストは Datastream の料金だけで見積もっていて、見落としが 2 つありました。

見落とし 1: BigQuery 側の反映処理がテーブル全体を読む

Datastream は BigQuery に変更を書き込んだあと、BigQuery 側のバックグラウンド処理が max_staleness（鮮度設定）の間隔ごとに保留中の変更をテーブルへ反映します。この反映処理は、どのパーティションに変更が当たるか事前に分からないため、パーティションで範囲を絞れません。クラスタリングも通常のクエリにしか使われません。つまり反映のたびにテーブル全体を読み、オンデマンド課金ではその読み取り量が課金されます。これは BigQuery の CDC の仕様として明記されていて、見落としていたのは私の設計です。

被害が大きくなったのは、巨大で、かつ更新が絶えず流れ込むテーブルでした。テーブルが大きいほど 1 回の反映が重く、更新が止まらないので反映が繰り返されます。INFORMATION_SCHEMA.JOBS で見ると、読み取り量はピークの日で 43.5 TiB に達し、その 95% は上位 5 テーブルでした。

対処は鮮度設定の見直しです。分単位の鮮度が要るテーブルはなく、読み取り量の 95% を占めていた上位 5 テーブルは日次で足りるものでした。テーブルごとに業務上必要な鮮度まで max_staleness を緩めた結果、読み取り量は 1 日 0.3 TiB 前後で落ち着き、ピーク比で約 1/100〜1/150 になりました。

見落とし 2: Datastream 側の流量が太い JSON 列で膨らんでいた

Datastream の課金はソース側の変更量 × 行サイズで決まり、上の反映処理とは独立です。実測すると、流量の 86% が 1 テーブルに集中し、その行サイズの 6 割は 2 つの JSON 列でした。MySQL の binlog は ROW 形式だと UPDATE でも全列のフル行イメージを運ぶので、太い列があるテーブルは更新のたびに列全体が流れます。

この 2 列を含む 7 列は、PII 混入列として staging に持ち込まないと決めていた列でした。raw には全列を入れる設計ですが、staging で捨てると決まっている列を raw まで運んでも使い道がなく、コスト面の利点が大きいので、例外として Datastream の除外設定でソースから出る時点で省きました。前述の Glue 経路は、この除外した列を別の経路で運ぶために生まれたものです。

結果

BigQuery 側は、ピークの水準が続けば月 1 万ドル近くになる計算だった読み取り課金が、月 70 ドル前後に収まりました。Datastream 側は月 400 ドルほど減り、raw に PII を持ち込む量も減りました。合わせて月 1 万ドル規模の削減です。再発防止として、Cloud Billing の予算アラートを全体、BigQuery、Datastream、GKE の 4 本張り、以後は月次でコストを見ています。

今後

次のプロダクトがすでに名乗りを上げています。プロダクト側のバックログの都合で実際に載るのは少し先ですが、config.yaml を 1 枚足して dbt プロジェクトを 1 つ切る手順で受け入れる想定です。

また、活用をさらに促進する施策として、Game Day を企画しています。調査や改善のお題を出し、ビジネスメンバーを巻き込んで Laplace で調べ、どんなアクションにつなげるかまでをイベント形式でやる想定です。Laplace で何ができるかを体験で理解してもらい、日常の利用につなげたいと考えています。

マルチクラウドからの push は雛形のみで、実際のプロバイダは AWS だけです。Lightdash Cloud への移行は、利用が全社に広がって ROI が見合う段階の選択肢として残しています。

おわりに

振り返ると、最も効果的だった指針はセマンティック定義を 1 か所に集めることでした。この原則で BI が決まり、AI は定義済みの指標だけを使うので分析が安定し、PII の遮断も命名とラベルの整合という単純な契約で済みました。

もう 1 つ、コードを書かずに基盤を立てるには、LLM に任せる範囲と同じだけ仕組みで縛る範囲を広げる必要がありました。人が守る規約ではなく、破ったら落ちる CI とテストにしておけば、LLM が書いたコードを安心して積み上げられます。

同じように分析基盤を立てようとしている方の参考になれば幸いです。