2026年9月18日(金)、キーウォーカーのユーザー会「データエンジニアリング祭り」を開催しました。テーマは、Tableauダッシュボードの“裏側”にあるデータ基盤です。
普段ご支援しているお客様に、「データを使える状態にする」仕事を知っていただく回として企画しました。当日は弊社データエンジニアによる考え方の紹介と5本の事例LTのあと、お客様同士の交流会を行いました。 交流会では4つのテーブルに分かれ、利用中・検討中のデータ基盤や来年度以降の取り組みについて、業界を越えて情報交換いただき、予定時間いっぱいまで盛り上がりました。
本記事では当日の発表内容をダイジェストでお届けします。自社のデータ基盤づくりを考える際の参考になれば幸いです。
目次
- はじめに ―「データが使えない」を分解する
- キーウォーカーのデータ分析基盤整備の考え方 ― AIが「使える」データにするために
- データエンジニアリング事例LT
- 基盤を意識しないことが、基盤の価値
- データドリブン経営カンファレンス2026
- おわりに
はじめに ―「データが使えない」を分解する
オープニングで投げかけたのは、「データはあるのに、なぜ使えないのか」という問いです。
「使えない」の正体は、データが生まれてから業務で使われるまでのどこかに潜んでいます。
- 発生：そもそもデータ化・入力されていない（紙やExcel管理、必要な項目を取っていない）
- 収集：システムや部門に散在し、集められない（APIがなく手作業で収集）
- 統合：顧客IDや商品コードがシステムごとに違い、つながらない
- 整備：定義や品質、更新頻度が不明で信頼できない
- 分析：BI（データを可視化・分析する仕組み）や分析人材がなく、見られない
- 活用：見て終わりで、業務や意思決定に使われない
たとえば営業管理・販売管理・Web・Excelにそれぞれデータがあっても、「顧客Aの売上と営業活動とWeb行動をまとめて見たい」となると、データをつなぐ作業が必要になります。 また、「売上」の定義が部署ごとに違う、TableauとExcelで数字が合わない、誰がどう加工したか分からない、といった状態では、ツールがあっても安心して判断に使えません。
DWH（分析用にデータを集約する保管基盤）やETL（データを取り出し、加工して格納する処理）、Tableau Prep、データモデルは、どれも「信頼できる数字」をつくるための投資だ、というのがメッセージでした。
Tableauのダッシュボード開発は、この6段階でいえば⑤⑥の「最後のステップ」です。
一方で、その手前の①〜④、つまり「データを使える状態にする」ご支援も多く、そこで活躍しているのが弊社のデータエンジニアです。
キーウォーカーはダッシュボード開発を起点に、データ基盤構築やデータマネジメント、活用を根付かせる体制づくりまで一貫してご支援しています。
この日はその①〜④の取り組みを中心にご紹介しました。
このテーマは、10月29日開催の「データドリブン経営カンファレンス2026」でも取り上げます (詳細はこちら)
キーウォーカーのデータ分析基盤整備の考え方 ― AIが「使える」データにするために
ここで取り上げたのは、「社内データを使ったAI活用が、なぜPoC（本格導入前に実現性や効果を確かめる検証）から先に進まないのか」というテーマです。
AI活用の品質を左右する、データの状態
「社内データに自然言語で質問したい」「AIエージェントに業務を任せたい」という期待は高い一方で、現場では「聞くたびに違う数字が返ってくる」「社内用語が通じない」「もっともらしいが誤った回答が出る」といったことが起きています。AIの設定や仕組みだけでなく、参照するデータの品質や定義も確認すべきポイントです。
BIでは、人がグラフを見て「この値はおかしい」と気づき、確認や補正を行うことができます。一方、AIの回答を業務処理や意思決定につなげる場合、データの不備や解釈のずれを見逃すと、その影響が後続の処理に及ぶおそれがあります。たとえば、取引先名の表記揺れが別顧客として扱われたり、欠損値がゼロとして処理されたりすると、集計結果が実態とずれてしまいます。
AI活用を進めるうえでも、データ品質の確保と、回答・処理結果を検証する仕組みが欠かせません。
データを整え、そのうえに「意味の層」を置く
では、どう整えればよいのでしょうか。講演では、データを「生のまま残す（Bronze）」「整える（Silver）」「使う形にする（Gold）」の3段階で扱う「メダリオンアーキテクチャ」の考え方を紹介しました。 基幹システムやSFA（営業活動を管理・支援するシステム）のような表形式のデータだけでなく、契約書や議事録、図面といった非構造化データも、形式に応じた処理を行いながら、段階的に整備する考え方です。
さらに重要なのが、その上に置く「意味の層」です。「売上」は受注金額か出荷金額か、税込か税抜か。「今期」は4月始まりか。社内でしか通じない略称は何を指すのか。 こうした指標の定義や用語、業務ルールを明文化することで、質問の解釈や集計のばらつきを抑え、一貫した回答につなげやすくなります。 指標や計算ルールを共通化する仕組みが「セマンティックレイヤ」、業務上の概念とその関係を整理する仕組みが「オントロジー」です。
ただし、定義を整えるだけで回答の正しさが保証されるわけではありません。 自社の業務に即した定義を整え、実際の質問と回答を照らし合わせて検証することが重要です。既存のダッシュボードの計算式やTableau Prepの整形ロジックは、その定義を整理するたたき台になります。
全社一括ではなく、1つのユースケースから
最後のポイントは進め方です。全社のデータ棚卸しから始めると、対象が広く、効果を確かめるまでに時間がかかることがあります。 業務インパクトとデータの入手しやすさを踏まえて、ユースケース（具体的な活用場面）を1つ選び、その範囲のデータ整備からAIの回答・処理結果の検証までを一巡させます。 そこで整えた定義やパイプライン（データを収集・加工・提供する一連の処理）は、別のユースケースでも再利用できる部分があり、段階的な展開の土台になります。
AIに向けたデータ整備の進め方は、冒頭でご紹介した10/29開催のカンファレンスでも内容をアップデートしてご紹介します。ユーザー会に参加できなかった方も、ぜひご視聴ください (詳細はこちら)
データエンジニアリング事例LT
後半は、実際のプロジェクトを担当したエンジニアによる5分間のLTです。基盤の「選定」から「内製化」まで、フェーズの異なる事例が並びました。ここでは、5つの事例をご紹介します。
事例1：「どの基盤を選ぶか」から一緒に決める
課題：データ基盤の製品選定では、性能だけでなく、将来の拡張性やコスト、運用のしやすさまで見据える必要があります。この事例では、業務で使う人と管理する人の両方の視点から、選定基準を整理しました。
対応：Databricks・Microsoft Fabric・Snowflake・BigQuery・Redshiftの5製品を候補に、性能・セキュリティ・コスト・使い勝手などの評価軸をお客様とすり合わせ、トライアルを行いました。
成果・今後の計画：比較・検証を経て、導入する製品を決定しました。今後は、基幹システムを対象にした小規模な構成から始め、現場システムの統合や故障予測へと段階的に広げる計画です。
事例2：部門ごとにバラバラな数字を1つに
課題：複数の基幹システムに加え、BtoC（個人向け事業）とBtoB（企業向け事業）で売上データの置き場所が分かれていたため、全社横断で売上や利益を分析できない状態でした。人によって参照するデータが違い、どの数字を判断の基準にすべきかも分かりにくくなっていました。
対応：BigQueryに全部門のデータを集約し、全社で共通の参照元となるSSoT（Single Source of Truth）を目指して、統合基盤づくりに着手しました。構築の過程で、部門ごとに売上が税込・税抜で異なる、原価の持ち方が異なるといった実態が見え、担当者の方と定義をすり合わせました。
成果：データを集めるだけでなく、お客様自身のビジネスロジックの再整理にもつながっています。基盤づくりを通じて、全社で数字を見るための共通認識を整える取り組みです。
事例3：データを取る仕組みをゼロから、小さく始める
課題：スマートウォッチで取得した睡眠データをTableauで見える化したい、というPoCのご相談です。分析に必要なデータを取得する仕組み自体がありませんでした。
対応：AWS上に取得・加工の仕組みをゼロから構築しました。将来の別用途の分析も見据え、生データ・整形データ・表示用データを段階的に分けるメダリオンアーキテクチャを採用しています。また、サーバーの管理をクラウド側に任せるサーバーレス構成とし、運用負担とコストを抑える設計を目指しました。
成果：Tableauで可視化するためのデータ取得・加工の基盤を整えました。処理を段階ごとに分けることで、障害時の原因を切り分けやすく、別の分析用途にも展開しやすい構成にしています。PoCの段階でも、将来の利用を見据えて小さく始められる事例です。
事例4：手作業とブラックボックスからの脱却
課題：マネジメント層が毎回手作業で指標を集計しており、データはあちこちに散在していました。引き継がれたExcelを使い回すうちに、計算方法が担当者自身にも分からなくなっていたそうです。
対応：Google Cloud上に、元データ（Excel・PDF・会計システムのCSV）を格納し、OCR（画像や文書から文字を読み取る処理）やフォーマット調整を経てBigQueryに蓄積、Tableauで可視化するまでを自動で流す仕組みを構築しました。計算ロジックを再整理し、運用ルールのレクチャーも行いました。
成果：Boxにファイルを置くことで、指標を自動更新できるようになりました。手作業の集計を減らすとともに、特定の担当者だけに依存せず、共通の手順で運用できる状態を目指した取り組みです。
事例5：「見える化」の裏側を、お客様が回せる形に
課題：ダッシュボードは弊社の支援で以前から動いていましたが、その裏側は月1回の手作業更新でした。現場は週次で数字を見たいのに更新が追いつかず、データを加工できる人も限られていました。
対応：既存のダッシュボードは止めずに、裏側の仕組みをSnowflakeとワークフローに段階的に差し替えました。3か月ごとにフェーズを区切り、最初から内製化を前提に研修計画も組み込みました。
成果：更新は週次・日次で自動化され、数字の根拠も設計書から追えるようになりました。取り組みの最終段階では、お客様の担当部門が構築を主導し、現在は情報システム部門が本番運用を担っています。
事例から見えた、データ基盤が効く3つの場面
業種や規模、取り組みの段階は異なりますが、5つの事例には共通するポイントがありました。
- 数字の定義を揃える：部門やシステムごとの違いを整理し、共通の参照元を設けることで、数字の根拠を確認しやすくします。
- 手作業を減らす：ファイルの格納やスケジュール実行を起点に更新を自動化し、繰り返しの集計作業や属人化を減らします。
- あとから広げやすくする：生データ・整形データ・利用目的に応じたデータを分け、用途の追加や変更に対応しやすい構成をつくります。
これらは、生成AIで社内データを活用する際にも重要な土台です。
基盤があるだけでAIの回答品質が保証されるわけではありませんが、参照するデータの定義・品質・更新状況を把握できることは、回答の検証や改善を進めるうえで役立ちます。
基盤を意識しないことが、基盤の価値
講演の締めくくりは、Microsoft Fabricの紹介です。 冒頭で強調されたのは、どんな基盤を作るにしても、大切なのは「その基盤が業務ユーザーの判断と行動にどうつながるか」だという点でした。
業務ユーザーは、データ基盤そのものを使いたいわけではありません。欲しいのは、必要な数字を迷わず、安心して判断に使える状態です。 ところがデータや管理が分断されていると、利用者はデータの所在や定義、更新時刻、権限といった基盤側の事情まで確認しなければなりません。 講演では、買い物・カード・銀行・証券が別サービスでも、共通のIDでつながっていれば一つの圏内として使える、というたとえで説明されました。
Microsoft Fabricは、データの収集・保存・加工・管理・分析を一つの流れでつなぐデータ活用基盤です。
講演では、基幹システムやCRM（顧客情報や顧客との関係を管理するシステム）、Excelなどのデータを「つなぐ」、共通指標をPower BIで確認し、追加の質問にはAIエージェントを活用する「使う」、TeamsやExcel、Outlookといった普段の業務の場へ「広げる」という流れが紹介されました。
単なるデータの保管にとどまらず、関連サービスとの連携により、整備したデータをMicrosoft 365の業務の場につなげられることがポイントです。
ただし、実現できる範囲は利用するサービスやライセンス、権限設定などによって異なります。第一歩としては、1つの業務を対象に、データの参照・回答を中心とするAIエージェントから小さく検証することを勧めていました。
ただし、Fabricがすべての企業に最適とは限りません。 Microsoft 365を全社で使い、Teams・SharePointが業務に定着している企業や、データ基盤の新設・刷新時期にある企業では、統合のメリットを検討しやすいでしょう。 一方で、Tableauや既存DWHが安定運用されている環境や、複数のクラウドを組み合わせるマルチクラウドを重視する企業では、既存環境との役割分担や移行コストを慎重に整理する必要があります。
Fabricでも、それ以外の基盤でも、データの「出口」を最初から設計に組み込むことが重要です。 誰が何を判断したいのか、どのデータをどの形で届けるのか。製品の機能だけでなく、利用者の業務から考えることが、基盤を実際の活用につなげる鍵になります。
データドリブン経営カンファレンス2026
「データが使えない理由」と「AIに向けたデータ整備の進め方」の2講演は、内容をアップデートして、10月29日(木)開催のオンラインイベント「データドリブン経営カンファレンス2026」でもお届けします。 自社の課題を整理したい方や、社内の方と一緒に理解を深めたい方は、ぜひご参加ください。
| ユーザー会での講演 | カンファレンスでのセッション |
|---|---|
| はじめに ―「データが使えない」を分解する | SESSION 01（10:40〜11:00） 「データが使えない」とは |
| キーウォーカーのデータ分析基盤整備の考え方 ― AIが「使える」データにするために | SESSION 06（12:40〜13:00） AIが「使える」データにするために 〜データ整備の現実的な進め方〜 |
テーマは、「意思決定に使えるデータ」と「使えないデータ」の境界線。
全12セッションを通じて、生成AI時代のデータ基盤づくりや、データ活用の現場の取り組みをご紹介します。
- 日時：2026年10月29日（木）10:30〜15:40
- 開催形式：オンライン／参加無料（事前申込制）
- 見逃し配信：開催後1週間、全12セッションを視聴可能
気になるセッションだけの視聴も可能です。詳細・無料のお申し込みはこちら。
おわりに
ご参加いただいた皆さま、お越しいただきありがとうございました。そして、この記事をここまで読んでくださった皆さまも、ありがとうございます。 「自社ならどこから始めればいいだろう」「今のTableau環境の裏側を整えたい」と思ったら、まずはお話を聞かせてください。まだ具体的な計画がなくても、課題を整理するところから一緒に考えていければと思います。
キーウォーカーでは、データ基盤の選定・構築から運用定着・内製化までご支援しています。 詳しくはデータ分析基盤サービスをご覧ください。 ご相談はお問い合わせフォームからお気軽にどうぞ。
この記事の著者：君島千尋
