こんにちは、ウォンテッドリー株式会社 執行役員 VPoE の要（@nory_kaname）です。

ウォンテッドリーでは、組織規模でのAI活用を進めています。BI Squadとしては「データ分析をAIエージェントに任せ、全社員にデータアナリストをつける」という目標を掲げ取り組んでいます。Slack上で「Devin xxを分析して」と呼びかけることでデータ分析が可能な環境になりました。現時点では、PO（プロダクトオーナー）とPdM（プロダクトマネージャー）、プロダクト開発チームと一部のセールスリーダーが利用可能となっています。

この記事では、それをどう実現したのかを紹介します。

はじめに

ここ数年でAIの進化は凄まじく、データ分析や開発でもAIエージェントの活用が当たり前になりつつあります。しかし、実際に全社のデータ分析にAIを組み込もうとすると、「データへのアクセス（ガバナンスとセキュリティ）」と「データ基盤の開発（デリバリースピード）」という2つの大きな壁にぶつかります。

BI Squadにてデータ基盤のAI活用を進める上で、この2つの課題を切り離して考えました。前提として、ウォンテッドリーではAIの登場以前からデータウェアハウス（DWH）の設計がされており、dbtを用いたデータ整備が進んでいました。この「データ基盤」という土台があったからこそ、今回のAI活用をスムーズに進めることができました。

取り組みの結果、以前の記事でも触れたように、現在ではPO（プロダクトオーナー）やPdM（プロダクトマネージャー）が自らAIエージェントを使って高度なデータ分析を行えるようになっています。今ではさらに広がり、セールス領域にまで浸透しつつあります。

データへのアクセスをどうするか

ウォンテッドリーのプロダクトは、ユーザーの皆様のプロフィールといった個人情報を多く扱うプロダクトです。そのため、「AIにどこまでデータを参照させていいのか？」というセキュリティ・プライバシーの事前設計が何よりも重要でした。

ツール選定と導入可否の検討

当初は、データ分析を支援するAIエージェントとしてツール選定・比較を行おうとしていました。しかし、ちょうど同じタイミングでDevinの「Devin Analytics」が利用可能になったため、まずは試してみようと導入することに決定しました。

しかし、導入を決めて即座にデータをつなぎ込んだわけではありません。まずは以下のような検討とポリシー策定を行いました。

• Devinの利用規約とセキュリティー特性の徹底調査
• データ基盤のデータソースとなるテーブルの精査
• BI SquadとしてのAI利用ポリシーの策定

ガイドラインの策定と法務連携

「AIが参照していいデータ」と「ダメなデータ」の境界線を明確にするため、法務チームと連携することを前提としました。

Devinの利用規約と社内のデータの内容を照らし合わせ、法務へ相談すべき事項を洗い出しました。同時に、社内データに存在する個人情報の棚卸しを実施し、必要な対応をリストアップしました。これらを元に、データ整備をするBI Squadとしての「運用ガイドライン」を策定しました。

セキュアな導入作業（仕組み化と自動化）

法務とのすり合わせを終えた後、実際のデータ基盤側に手を加えます。具体的には、AIエージェントに参照させてはいけないカラム（PII等）のチェックでした。

ここで重要だったのは、「一度チェックして終わり」にしないことです。データ基盤は日々アップデートされるため、「テーブル作成時のセキュリティレビューの仕組み化」と「個人情報混入チェックの自動化」をCI/CD等のパイプラインに組み込みました。これにより、今後の開発でも意図せずAIに個人情報が渡ってしまうリスクをシステム的に防ぐ「守りの仕組み化」が完成しました。

データ基盤の開発をどうするか

Devin Analyticsを安全に使える環境が整ったことで、まずはVisit Tribeのプロダクト開発（PO/PdM）にフォーカスして、AI分析の実験を開始しました。徐々に使われるようになり、いまはなくてはならないものになっています。自らSQLをゴリゴリ書かずとも、自然言語でデータと対話し、データ集計と分析ができる環境となりました。

ここで新しい課題が見え始めます。「Devinで分析したいデータがもっとある。早くDWHにデータを用意してほしい」というデータ基盤側への要望の急増です。

AIで分析可能にするためには、dbtを用いたTransform Layerの整備をMustとしています。圧倒的な開発スピードが求められるようになったBI Squadは、データ基盤の開発環境自体をさらに最適化することにしました。

GitHubリポジトリのAI最適化と「CLAUDE.md」

社内でClaudeの普及を目指していたこともあり、BI Squadも合わせることにしました（それまではCursorを使っていました）。

CLAUDE.md からプロジェクト内のドキュメントを構造的に辿れるように導線を設計し、「データ基盤の開発において、AIエージェントが関与する部分・しない部分」をマップ化して明示しました。これにより、Claudeは迷子にならず、期待通りのスコープで動いてくれるようになります。

AIと協業する開発工程の分解

Claude Codeにdbtの実装を任せるにあたり、開発工程を以下のように分解・定義しました。

• コンテキストの提供
• • 参照するドキュメント、使用するSkill（AIツール）、すでにわかっている課題や制約をAIに提示する。
• 人間の仕事（要件定義）
• • AIに丸投げするのではなく、「ビジネス要件と論理設計をドキュメントとして残すこと」を必須とする。
• AIの仕事（実装）
• • 用意された論理設計ドキュメントをもとに、Claude Codeがdbtのモデル（SQL）やテストを実装する。
• 検証とループ
• • 実装後はローカルで検証を実行。不備があった場合は、AIにエラー内容をフィードバックして工程を戻し修正させる。

このワークフローを確立したことで、BI Squadのメンバーは「要件定義とレビュー」に集中でき、dbtの実装スピードは飛躍的に向上しました。もちろんこの取り組みはまだ未完成であり、現在もPDCAサイクルを回しながらプロンプトやフローの最適化を続けています。

次の図のようなAIエージェントを用いた開発で進めています。

おわりに

FY26のBI Squadは、「『使える数字』で、意思決定を次のステージへ」というオブジェクティブを掲げAI活用に取り組んできました。結果的に、「Devin Analyticsによるデータ分析」と「Claude Codeによるデータ基盤開発の高速化」の2つのことが実現しました。

事前準備としてのdbt基盤があったこと、そしてセキュリティのルール化を徹底したことが、結果的にアグレッシブなAI導入を可能にしました。今後は、さらに分析可能なドメインを広げつつ、AIエージェント同士が連携するような、より高度なデータエコシステムの構築を目指します。