全社員向けAI導入と今後のデータ基盤 - ハウテレビジョン技術ブログ

株式会社ハウテレビジョンのData And Analyticsチームにいるデータエンジニアです。

最近では、全社対象にClaudeを導入し、BigQuery MCPやGA4 MCPを経由して社内データを活用した分析促進する取り組みをしています。今日は、Claudeを導入したことでの恩恵や課題についてお話しできればと思っています。

なぜClaudeを導入したのか

2025年4-5月時点で全社AI導入を検討する際、主要なAIエージェントを比較検討いたしました。

比較検討のポイント

検討の段階で重視したのは、以下の3点でした。

データ分析能力: 統計分析の提案・実行、結果の解釈や洞察の質
データ可視化機能: チャート作成とインタラクティブな編集
社内データ連携: 非エンジニアでも容易にセットアップできること

Claudeを選んだ3つの決め手

1. データ分析における洞察の質

実際に社内データを用いた検証において、Claude Desktopは単なる集計にとどまらず、分析結果のまとめ、可視化、将来的な示唆出しまで一貫して提供してくれました。

統計分析の提案や結果の解釈において、ビジネスに活かせる洞察を得られる点が、当社の評価では他のAIエージェントより優れていると判断しました。

2. Artifact機能による可視化とドキュメント化

ClaudeのArtifact機能(公式ドキュメント)は、当社にとって特に価値の高い機能でした

多様なチャート生成: 棒グラフ、折れ線グラフ、散布図などを、データに応じて適切に生成
動的なパラメータ変更: 生成されたチャートのパラメータをインタラクティブに調整可能
ドキュメント保存: 分析結果をPDFなどの形式で保存し、社内共有が容易

Artifact機能はClaude 3.5 Sonnetと共に発表された機能で、メインチャットとは別の専用ウィンドウで、実質的で独立したコンテンツを表示・編集できます。バージョン管理機能により、分析の変遷を追跡することも可能です。

3. MCPによる社内データ連携の容易さ

最も重要な決め手となったのが、Model Context Protocol (MCP) のサポートでした。

Model Context Protocol (MCP) とは

MCPは、Anthropic社が2024年11月25日に発表した、AIシステムと外部データソースを接続するためのオープンスタンダードです(出典)。MCPの登場により、AIエージェントが社内データに安全にアクセスできる標準化された方法が確立されました。

重要なポイント: 2025年4-5月の選定時点では、MCPをサポートしていたのはClaudeのみでした。

OpenAIは2025年3月にMCPサポートを発表
Google DeepMindは2025年4月にMCPの採用を表明

つまり、評価時点ではOpenAIとGoogleはMCPのサポートを発表したばかり、または発表前の段階であり、実質的にClaudeが唯一の選択肢でした。

他のAIエージェントの状況

ChatGPTは、Advanced Data Analysis機能により優れたデータ分析機能を持っていました(出典)。CSVやExcelファイルをアップロードしての分析、Google DriveやMicrosoft OneDriveからの直接ファイル読み込みが可能です。

しかし、BigQueryなどの社内データベースへの接続については、RAG(Retrieval-Augmented Generation)やAPIを使った独自実装が必要であり、全社員が手軽にセットアップできる仕組みではありませんでした。

Geminiについては、Gemini in BigQueryという機能が存在します(出典)。これはBigQuery内で直接Geminiを使用してSQL生成やデータ分析を支援する機能ですが、あくまでBigQueryのWeb UIやAPI経由で使用するものです。Claude Desktopのように、デスクトップアプリから社内データベースに直接接続できる標準化された仕組みではありませんでした。

まとめ

当社がClaudeを選択した理由をまとめると

データ分析における洞察の質: 統計分析の提案・実行から、結果の解釈や将来的な示唆まで一貫して高品質
Artifact機能: 優れた可視化・ドキュメント化により、分析結果の社内共有が容易
MCPによる社内データ連携: 非エンジニアでも簡単にセットアップできる標準化されたプロトコル

特にMCPは、評価時点でClaudeのみがサポートしており、全社展開において決定的な優位性となりました。

MCPによる社内データ連携の実現

導入したMCPサーバー

Claudeを社内データと連携させるため、以下の2つのMCPサーバーを導入しました

BigQuery MCP: 社内のBigQueryデータベースへのアクセス
GA4 MCP: Google Analytics 4のデータへのアクセス

これらのMCPサーバーは、オープンソースのコミュニティ実装をベースとしています。BigQueryについては複数の実装が公開されており(LucasHild/mcp-server-bigquery、ergut/mcp-bigquery-serverなど)、GA4についても同様に複数の選択肢があります(harshfolio/mcp-server-ga4、ruchernchong/mcp-server-google-analyticsなど)。

カスタマイズと最適化

OSSの実装をそのまま使用するのではなく、以下のカスタマイズを施しました

セキュリティ面の強化

接続可能なデータセットをパラメータで制限
サービスアカウントによる認証
データウェアハウス側でのマスキングとポリシー設定

パフォーマンスの最適化: オリジナルのMCPサーバーでは、トークン消費が過剰になる問題がありました。これに対して以下の対応をしました。

ツール定義の最適化: 提供するツールの種類を削減し、機能を統合
ツールロジックのリファクタリング: より効率的な実装に書き換え
不要な中間処理の削除: 冗長なステップを省略

これにより、トークン消費を抑えつつ、複雑なSQLクエリの自動生成を実現しました。

MCPサーバーの機能

これらのMCPサーバーは、以下のような強力な機能を提供します

自然言語でのクエリ実行: ユーザーが質問すると、Claudeが適切なSQLを自動生成して実行
集計関数の自動使用: SUM、COUNT、AVG、GROUP BY、Windows関数など、プロンプトに応じた複雑な集計も可能
読み取り専用アクセス: SELECTクエリのみ実行可能で、データの安全性を確保

例えば、「先月のアクティブユーザー数の推移を教えて」という質問に対して、Claudeは自動的に

適切なテーブルを選択
日付範囲を指定したSQLを生成
集計を実行
結果を分かりやすく整形して返答(+Artifact作成や示唆だし)

という一連の処理を行います。

MCPBによる簡単インストール

MCPサーバーの導入にあたり、最大の課題は非技術者でも簡単にセットアップできる仕組みをどう作るかでした。

従来の課題

通常、MCPサーバーをClaude Desktopに接続するには、claude_desktop_config.jsonファイルの手動編集が必要です(参考)。これは以下のような作業を伴います

JSONファイルの場所を見つける(macOSとWindowsで異なるパス)
正しい形式でサーバー設定を記述
コマンドラインツールのパスを指定
認証情報の設定

技術者にとっても手間のかかる作業であり、非技術者にとってはハードルが高すぎるものでした。

MCPBによる解決

そこで、私たちはMCPB (MCP Bundles) を活用した自動セットアップの仕組みを構築しました。

MCPBは、Anthropic社が開発したMCPサーバーのパッケージ形式です(GitHub: anthropics/mcpb)。Chrome拡張(.crx)やVS Code拡張(.vsix)に似た仕組みで、MCPサーバーとその依存関係を1つのアーカイブファイルにまとめることができます。

MCPBファイルの構造

bundle.mcpb (ZIPファイル)
├── manifest.json      # 必須: バンドルのメタデータと設定
├── server/            # サーバーファイル
│   └── index.js       # メインエントリーポイント
├── node_modules/      # バンドルされた依存関係
└── package.json       # NPMパッケージ定義

セットアップの流れ

作成したMCPBファイルを配布
ユーザーはClaude Desktopを開く
「拡張機能」→「インストール」から、MCPBファイルをドラッグ&ドロップ
完了！

重要な特徴

claude_desktop_config.jsonへの影響なし
Windows/Mac両方に対応する単一ファイル
Node.jsやPython環境は Claude Desktop側で用意済み
コード管理が可能なため、バージョン管理や継続的な改善が容易

劇的な効率化

この仕組みにより、セットアップ時間を30分~1時間から約5分に短縮することができました。

従来は

設定ファイルの場所を説明
JSONの編集方法を説明
認証情報の設定を説明
トラブルシューティング対応

MCPBでは

「このファイルをドラッグ&ドロップしてください」

たったこれだけです。

さらに、社内向けにNotionでセットアップガイドをまとめ、誰でも迷わず導入できる環境を整備しました。

Claude導入で見えてきた課題

Claudeを導入し、社員がより簡単にデータ分析を行えるようになったことは大きな成果でした。しかし、同時に新たな課題も浮き彫りになりました。

AIエージェントが明らかにしたデータ品質の問題

AIエージェントが社内データに直接アクセスできるようになったことで、これまで見過ごされがちだった集計データの品質問題が顕在化したのです。

具体的には以下のような問題が発生しました

1. クエリロジックの誤り

同じ指標を取得するためのクエリであっても、作成者によって異なる結果が返されることがありました。これには2つの原因があります。

一つ目は、単純なクエリの誤りです。SQLの記述ミスやテーブル結合の誤りなど、人的エラーに起因するものです。

二つ目は、ドメイン固有のルールの扱いの誤りです。弊社では就職活動をする学生がターゲットですが、留年や大学院進学などで卒業年が変わるケースがあります。この「卒業年の変動」というドメイン特有のルールを適切に扱わないと、同じ学生を重複してカウントしてしまったり、逆に見落としてしまったりします。

2. Claudeが生成するクエリの精度課題

Claudeが社内データにアクセスして分析を行う際、以下のような課題が見られました

正しいテーブルにアクセスできない
ドメイン特有のビジネスルール（卒業年の変動など）を実現することが困難

これらの課題は、LLMによるSQL生成の研究でも指摘されています。Text-to-SQLタスクを扱った研究によれば、最良のモデルでも複雑なクエリに対して約20%のエラー率があり（出典）、複雑な企業システムやデータベースでは、高度に複雑なスキーマ、AIによる幻覚、誤った列名、誤解されたスキーマなどの課題により、正確な結果を生成することがさらに困難となります（出典）。

3. 人間の暗黙知への依存

Claude導入前は、基本的にデータチームがデータ抽出を行っていたため、ドメイン知識や経験から不整合を補正できており、誤りを抑制できていました。しかし、AIエージェントは文字通りデータを解釈します。人間であれば経験や文脈から補正できていたデータの曖昧さや不整合が、そのまま分析結果の信頼性に影響を及ぼすことになったのです。

Andrew Ng（スタンフォード大学AI教授、DeepLearning.AI創設者）は「もし私たちの作業の80%がデータ準備であるならば、データ品質を確保することが機械学習チームにとって最も重要なタスクである」と述べています（出典）。まさに、AIエージェントの導入によって、この言葉の重要性を実感することになりました。

背景

データ品質の問題は以前から存在していました。しかし、限られた人数でデータ分析を行っていた時は、分析者の暗黙知や経験によってカバーされていたのです。

AI研究においても、不完全で誤りのある、または不適切なトレーニングデータは、信頼性の低いモデルにつながり、最終的に貧弱な意思決定を生むことが実証されています（出典）。

AIエージェントは人間のような文脈理解や暗黙知を持たないため、データの品質問題がダイレクトに結果に反映されてしまうのです。

AIエージェント時代に求められるデータ基盤

この経験から、AIエージェントに寄り添ったデータ基盤の必要性を痛感しました。

AIが理解しやすく、高品質なデータを提供するためには、データ基盤そのものの見直しが必要です。具体的には

明確で一貫性のあるスキーマ設計
AIが適切なテーブルとカラムを選択できるよう、スキーマを明確に定義する必要があります
ドメインルールのデータモデルへの組み込み
「卒業年の変動」のようなビジネスルールを、AIが理解しやすい形でデータモデルに組み込む必要があります
データの定義と粒度の統一
部署間でデータの解釈が異なることがないよう、組織全体で統一された定義を持つ必要があります

今後の展望:スタースキーマ導入による基盤改善

データ基盤改善プロジェクトの開始

Claude導入によってデータ品質の課題が顕在化したことを受け、現在、私たちはデータ基盤の改善プロジェクトに取り組んでいます。その中核となるのがスタースキーマの導入です。

スタースキーマとは

スタースキーマは、Ralph Kimball氏が1996年の著書『The Data Warehouse Toolkit』で体系化したデータウェアハウスのモデリング技術です(出典)。

中心に事実テーブル(Fact Table)を配置し、その周りを次元テーブル(Dimension Table)が取り囲む構造は、まさに星(Star)のような形状をしています(出典)。

主な特徴

シンプルな構造: 事実テーブルを中心に次元テーブルが放射状に配置されるため、テーブル間の関係が明確で理解しやすい
高速なクエリ: 非正規化された構造により、複雑なJOINを最小限に抑えられる
データの一貫性: 次元テーブルで共通の定義を持つことで、組織全体でデータの整合性が保たれる

出典

AIエージェント時代のデータ基盤として

私たちがスタースキーマを選択した理由は、AIエージェントがデータを解釈しやすい構造だと考えたからです。

探索するテーブルの明確化 事実テーブルと次元テーブルという明確な役割分担により、AIがどのテーブルを参照すべきか判断しやすくなると期待しています。
集計工数の削減 非正規化された構造により複雑なJOINが減少することで、AIが生成するクエリもシンプルになり、応答の揺れが少なくなるのではないかと考えています。
一貫したデータ定義 次元テーブルによる共通定義により、どの部署、どのユーザーがAIを通じてデータにアクセスしても、同じ結果が得られることを目指しています。

ただし、これらは現時点での私の仮説であり、実際に効果があるかは今後の運用を通じて検証していく必要があります。

dbtとBigQueryを使った実装

現在、以下の技術スタックで実装を進めています

BigQuery: データウェアハウス
dbt (data build tool): データ変換・モデリング

dbtを使用することで、SQLでデータ変換ロジックを記述し、バージョン管理やテストを行いながら、スタースキーマを構築しています。

MCPとの統合を見据えた設計

スタースキーマ導入にあたって、MCPとの統合も考慮しています。

star_schema層の作成 既存のmart層とは別に、star_schema層を作成し、MCPサーバーのデータセット制限パラメータをこの層だけに設定することで、AIがアクセスするデータ範囲を明確にする設計を検討しています。これにより、AIが参照すべきテーブルが明確になり、より正確なクエリ生成が期待できます。

ドメイン固有MCPサーバーの検討 将来的には、汎用的なBigQuery MCPサーバーだけでなく、ビジネスドメイン固有のルールや計算ロジックを含んだ独自MCPサーバー(例:how_domain_mcp)の作成も検討しています。これにより、ビジネスロジックをクエリではなくMCPサーバー側に実装することで、より柔軟な対応が可能になると考えています。

Claude Desktop向けには、MCPB(MCP Bundle)形式での配布も検討中です。