Claude Codeによるデータ分析の民主化とそれを支えるデータ基盤

登壇資料
イベントタイトル：Mobility Night #6 - 「データ基盤から分析活用まで」
URL：https://mobility-night.connpass.com/event/397761/

Transcript

1. Claude Codeによるデータ分析の民主化と それを支えるデータ基盤 2026.07.29 ｜ 株式会社ニーリー Analyticsチーム 大城 渉 1
2. 自己紹介 氏名 大城 渉 ／ Wataru Oshiro 所属 株式会社ニーリー プラットフォーム本部 アナリティクスグループ • SIerに新卒入社後、基幹システムデータ移行プロジェクトなどを経験 • その後コンサルティングファームにITコンサルタントとして転職し、 経歴 データ基盤構築支援などのプロジェクトを推進 • 2025年12月からニーリーにアナリティクスエンジニアとして参画し、 Claude Codeを活用したデータ分析基盤の構築・データ起点での業務改善に従事 その他 自己開示 • 2児の父として、育児と仕事に奮闘中 • 趣味は大学からやっているトライアスロン 2
3. 会社・プロダクト紹介 3
4. 会社・プロダクト紹介 法⼈⾞両向け駐⾞場管理SaaS「Park Direct for Business」 契約/⽀払い などの⼿続き代⾏ 駐⾞場業務を 委託 管理会社 インボイス対応/ 契約などの⼿続き代⾏ 導入企業様 駐⾞場探し 契約代⾏ ⽀払い代⾏ 法令‧税務対応 オーナー 4
5. Executive Summary AIのためのコンテキスト整備により、分析民主化を推進 課題 分析依頼は年 349件・月平均 29件。6名のAnalyticsチームで捌いており、 インサイトを出すスピードが「分析できる人の数」で頭打ちになっていた 打ち手 内製AIツールの機能開発から Claude Code活用にリソースを振り替え、 用語集・分析マスターテーブル・ Skill・検証ガイドで『分析レポートの作り方』を型化し、 最初の一歩はハンズオンで伴走した 成果 事業側メンバーが「クエリ生成 → データ取得 → 分析 → 共有」を自走で完走できる状態に。 下期からマーケティング部門は分析を完全自走で実施する方針になった CEOにも展開。さらに他の経営メンバーにも展開予定 5
6. 1｜課題 分析依頼は年 349件、途切れず来る ——捌くのは 6名 349件 月29件 6名 直近1年の分析依頼（ Jira実数） ほぼ毎営業日 1件以上 Analyticsチームの分析対応人数 月次件数（Jira起票ベース）：25〜37件で高止まり 37 37 35 36 32 29 27 25 26 24 25 16 25/7 8 9 10 11 12 26/1 2 3 4 5 6 6
7. 1｜課題 データモデルとドメインが複雑で Analytics以外の 自走が難しかった データを探せない 正しいSQLが書けない 数字が合わない どのテーブル・カラムに 欲しいデータがあるか分からない 既存類似クエリも見つけられない データモデルが複雑で、 ドメイン知識と SQL力の両方が必 要 同じ指標名なのに、 部署によって集計条件が違う イネーブリング側の Analyticsチームも苦しい 「このカラムの定義は？」という同じ質問への対応が繰り返し発生し、ドキュメント整備は追いつかない。 分析する側も、支える側も、どちらも苦しい構図だった。 7
8. 2｜課題解決に向けてのきっかけ 分析ツールの内製を通じ、 AIの活かしどころがはっきりした 内製ツール「 ANAGMA」 Claude Codeを検証 リソースの再配分 Redash用Chrome拡張として リリース、25名が利用 コンテキストを与えると、 SQL生成→取得→分析→レポートま で一気通貫でできた ツールの機能開発ではなく、 AIが活きる材料の整備に振り切る 適切にコンテキストを与えれば、 アウトカムにつながる分析は Claude Codeで十分実現できる！ 用語集もマスターテーブルも Skillも、MarkdownとBigQuery上の資産。実行 役のツールが替わっても持ち越せる。 だから「作る」ではなく「整える」にリソースを割くのが、 アウトカムへの最善手だと判断した。 8
9. 3｜仕組み ANAGMA＝Claude Codeを中心とした分析の仕組み全体 SQL生成 データ取得 分析・レポート 共有・公開 Claude Codeが用語集・ マスターテーブル定義を参照 bqコマンドで BigQueryに直接実行 Claude Codeで分析し HTMLレポートを生成 PR→レビュー→mainマージで 社内サイトに自動公開 この仕組みを支える 3つの整備（ → 次のスライドから） コンテキスト 用語集 × 分析マスターテーブル AIに言葉とデータの形を教える 型 Skill × 検証ガイド 分析の手順を再現可能にする 循環 レポート共有基盤 ナレッジが次の分析の材料になる 9
10. 3｜仕組み ─ 全体感 ANAGMA＝Claude Codeを中心とした分析の仕組み全体 NL Redashユーザー NL 分析ユーザー NL 社員 SQLに不慣れ・ 分析が主業務でない方 SQLを書ける・分析が主業務の1つの方 （ANA / PdM / RevOps…） 全社の閲覧者 SQL作成に利用 — 簡易な抽出はANAの介在が不要に 高度なデータ抽出・分析・レポーティングに利用 Claude Code AI SQLライター（旧 ANAGMA） データ取得・分析・HTMLレポートまで一気通貫 Redash上のChrome拡張でSQL生成 参照 ＋ CLAUDE.md・共有Skillで分析手順を型化 参照 — どちらも同じコンテキストを読む データカタログ 分析用語集 分析用マスターテーブル Analytics Knowledge Base テーブル定義ドキュメント 指標・ディメンション定義 JOIN済み・日本語ラベル レポート(HTML)の公開・蓄積先 ↺ フィードバックの循環：分析で頻出した未定義語は用語集へ、頻出の指標はマスターテーブルへ追加され、精度が上がり続ける ※ 権限はPIIを含まない分析用データセットに限定。クエリは SELECTのみ・スキャン量上限つき 10
11. 3｜仕組み ─ コンテキスト① AIの間違いを防ぐためのコンテキスト整備を実施 Markdown + Git管理 指標・ディメンションの定義を用語集リポジトリで管理し、 Claude Codeが分析時に参照する Tierで成熟度を明示 Tier1=重要KPIに使える / Tier2=レビュー済み / Tier3=作っただけ。 「用語集にあるから正しい」とは限らないことも明示 定義を書くのは事業側 ビジネス定義のオーナーは事業側。 Analyticsは書式と土台を用意する。「ご 用聞きとお客様」の関係を避ける いまは「気づいた人が PRを投げる」形で回っている 11
12. 3｜仕組み ─ コンテキスト② 言葉を揃えるだけでは足りない、データの形も揃える 複雑なJOINは事前計算済み 分析で頻出する JOINを済ませた分析用マスタテーブルを用意。 利用者も AIもJOINを組み立てる必要がない コード値は日本語名に置換済み 用語集と整合の取れた日本語名で、テーブルの中身がそのまま「社内の言 葉」で読める 用語集に沿って聞けば、ブレない 用語集の言葉で分析依頼を投げれば、テーブル選びや条件指定がブレにく く、精度の高い答えが返る ※ 定義イメージサンプル (dbtモデルとして構築している ) 言葉の定義とデータの形、両方を揃えて初めて精度が出る 12
13. 3｜仕組み ─ 手順の型化 良い分析者の手順を、誰の Claude Codeでも再現する 共有Skill 用語集検索・テーブル検索・ SQL作成・レポート作成。リポジトリをクローンす れば同じフローで分析が始められる CLAUDE.md 参照すべきリポジトリの場所、 bq実行ルール（ SELECTのみ・コスト上限）、 レポート配置ルールを記載 「検証してから」も型にする 使った前提（テーブル・定義・期間）を出させる／件数や粒度を自分の目で 見る／既知の正しい値と突き合わせる 「AIの出力を信用していいのか」への答えを、先に用意しておく 13
14. 3｜仕組み ─ 循環 人のナレッジが、次は AIのコンテキストになる 分析レポート (HTML) レビュー → 公開 人も AIも参照 次の分析の材料に PRを出す 認証付き社内サイトに 自動公開 背景・仮説・結論ごと 過去の分析を読める 似た分析はレポートから 出発できる Redashにはクエリは残るが、 「なぜこの分析をしたのか、何が分かったのか」という文脈が残らない。 レポートとして公開することで、分析の背景・仮説・結論が ストックされ、人にも Claude Codeにも次の材料になる。 14
15. 4｜展開 パイロット 2名から始めて、 3ヶ月で3部門に広げた 4月｜パイロット 開発PdM 2名 × 実業務テーマ SEO競合分析レポート 10本、CS体験パ ターン別のファネル分析などを自分たち で作り切った 5月〜｜定例でハンズオン 週次定例を 「用語集整備＋実データ分析」の ハイブリッドに再設計 実分析で必要になった定義をその場で 登録する方が回る 5〜6月｜横展開 マーケティング・開発 PdM → ファイナンスへ 権限や環境の詰まりも同期の場で その場で解消 相手のスキルに合わせて、広げ方を変える マーケ・開発 PdMはエンジニアリングスキルがあり立ち上がりはスムーズ。 エンジニアリング経験の浅いファイナンスは、作るのは本人・分析結果のレビューは Analyticsが受け持つ形で伴走している。 15
16. 4｜展開 配るより伴走 ——最初の一歩は必ず一緒にやる 配るより伴走 実業務のテーマで始める プッシュではなくプル ガイドは自走の下支えでしかない。最 初の一歩は必ず画面共有で一緒にや る 練習用データではなく、本人が いま困っている分析を題材にする 押し付け型のオンボーディングはし ない。良いレポートを見せて「自分も やりたい」を引き出す 大変だったこと 用語集のカバレッジ。全部を一気に整備するのは早々に諦めて、業務で必要になったものから継続的に足していく方針に切り替えた。「 AIの出力を信 用していいのか」への不安も、検証ガイドを作って終わりではなく、ハンズオンのたびに検証を実演して ケアし続けた。 16
17. 5｜成果 依頼を捌くチームから、自走を支えるチームへ After Before ・分析できるのはAnalyticsチームだけ ・年349件の依頼を6名で捌く ・スピードは「人の数」で頭打ち ・事業側がクエリ生成→取得→分析→共有を最後まで やり切れるように ・パイロット2名で10本超のレポートを公開 ・マーケ・開発PdM・ファイナンスの3部門へ 下期からマーケティング部門は、分析を「完全に自走」で実施する方針に この領域の分析は「依頼するもの」から「自分でやるもの」に変わる ※ 他部門からの依頼は引き続き受けており、依頼件数がどれだけ減るか (=他部門の自走度 )はこれから計測するフェーズ。 事業側起点の分析事例（ SEOで「掲載件数では勝つが検索順位で負けるエリア」の特定 →改善策の検討）も生まれている。 17
18. 6｜まとめ ツールを配るだけでは、データの民主化は起きない 1｜整備 コンテキスト： 用語集とマスターテーブルで、AIに社内の言葉とデータの形を 教えた 手順の型化： Skillと検証ガイドで、手順を誰でも再現できるようにした 循環： レポートがストックされ、人にもAIにも次の材料になる 2｜伴走 1.最初の一歩はハンズオンで一緒にやる。 2.実業務のテーマで、詰まりはその場で解消する。 3.良い事例が、次の「やりたい」を連れてくる。 CEOも自らこの仕組みで分析を実施 今後は、経営層全体にも展開していく予定 今後：「聞けば正しく返ってくる」範囲を広げ続ける ・分析マスターテーブルの拡充が次の本丸。利用頻度の高い領域から「用語集に沿って聞けば高精度に返る」範囲を広げる ・いまの成功モデルを、経営層やセールス・カスタマーサクセスなど次の領域へ 18
19. ニーリー採用情報など
20. Thank you! 20