物流DXを支える“意味”の設計：セマンティックレイヤーとAIで挑むデータ基盤/登壇資料（飯塚 大地）

Data Engineering Summit
2025年11月6日（木）11:00〜18:20
https://data-engineering-summit.findy-tools.io/2025

Transcript

1. Confidential 物流DXを支える"意味"の設計： 
 セマンティックレイヤーとAIで挑むデータ 基盤
 Data Engineering Summit 
 登壇資料
 テクノロジー本部CTO室所属 
 dach（飯塚 大地） 

2. 本日お話すること 

3. Copyright Hacobu, Inc. 3 本日お話すること
 弊社は、Google Cloud 上にデータ基盤を構築し、Looker でセマンティックレイヤーを運用・管理している。なぜこのよ うな構成に至り、セマンティックレイヤーが大事であることに気づいたのか。また、どのように開発・管理をしているの かについて、次項の3章に分けて解説する。

4. Copyright Hacobu, Inc. 4 第1章: Hacobu におけるデータ基盤の歩みと課題 
 
 第2章: チームを拡張する開発スタイル 
 
 第3章: セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 
 目次

5. Copyright Hacobu, Inc. 5 自己紹介
 dach（X: @dach_chikin） 
 所属:
 Hacobu Inc. テクノロジー本部 CTO 室 
 経歴:
 SI、ASP、インターネットメディア系、小売系を経て、2024年4月より Hacobu に join。 FRONT、BACKEND、SRE、PM と幅広く経験し、現職ではデータ分析基盤の立ち上げや運 用の経験を活かし、データエンジニアとして物流ビッグデータにチャレンジ中。 普段はチキ ン南蛮エンジニアとして、ユーザーに多大に支えてもらいながら勉強会コミュニティ Easy Easy (完全に理解したTalk)を運営中。
 趣味:
 コミュニティ運営、トレーニング、ご飯
 顔写真やアイコン
6. 第1章
 Hacobu におけるデータ基盤の歩みと課題

7. Copyright Hacobu, Inc. 7 Hacobu におけるデータ基盤の歩み 
 Hacobu “と” データ

8. Copyright Hacobu, Inc. 8 Hacobu におけるデータ基盤の歩み 
 Hacobu が挑む領域は”物流”。様々なステークホルダーや業界固有のオペレーションなど、業界の構造課題が存在 する。
 画像引用元: https://speakerdeck.com/hacobu/hacobu-company-deck
9. Copyright Hacobu, Inc. 9 Hacobu におけるデータ基盤の歩み 
 Hacobu は物流情報プラットフォームを提供し、共通のデジタル基盤として物流情報を繋ぎ、蓄積されたビッグデータ を活かすことで、社会課題の解決に挑みます。
 画像引用元: https://speakerdeck.com/hacobu/hacobu-company-deck
10. Copyright Hacobu, Inc. 10 顧客へのデータ活用の取り組み例 
 2025/1/27、 MOVO Berth に複数拠点の横断分析ができる「拠点横断アナリティクス」機能をリリース。 引用: https://hacobu.jp/news/13649/
11. Copyright Hacobu, Inc. 11 顧客へのデータ活用の取り組み例 
 本社・拠点双方の視点に基づく分析基盤 として、統一されたKPIで複数拠点のパフォーマンスを比較し、全体の課題を把握できる。また、 多様化している顧客の課題に対するアプローチとして「顧客に応じた」ダッシュボードを提供しているため、個社それぞれのレベルやニーズに応じ た分析ができる。
12. Copyright Hacobu, Inc. 12 顧客へのデータ活用の取り組み例 

13. Copyright Hacobu, Inc. 13 Hacobu におけるデータ基盤の歩み 
 データ基盤の歩み

14. Copyright Hacobu, Inc. 14 Hacobu におけるデータ基盤の歩み 

15. Copyright Hacobu, Inc. 15 Hacobu におけるデータ基盤の歩み 

16. Copyright Hacobu, Inc. 16 Hacobu におけるデータ基盤の歩み 
 アナリスト参画 

17. Copyright Hacobu, Inc. 17 Hacobu におけるデータ基盤の歩み 
 月
 UU数
 表示数
 データ基盤立ち上げ後、社内に向けて BI によるデータ提供を開始。
 データアナリストによる丁寧な利活用サポート（1on1でレクチャ、丁寧なヒアリングなど）を実施し、利用者数が線形で 増加する結果に繋がった。

18. Copyright Hacobu, Inc. 18 サポート施策が功を奏し、利用者が増加。その副次効果で、問い合わせや依頼が急増。アナリストに一極集中するこ とで、データ利活用での「ラストワンマイル」問題が発生。この資料における「ラストワンマイル」とは、「エンドユーザー に対し、分析要件を満たすデータを提供する最後の区間」と定義。
 Hacobu におけるデータ基盤の歩み 

19. Copyright Hacobu, Inc. 19 Hacobu におけるデータ基盤の歩み 
 徐々に
 「ラストワンマイル問題」 
 が発生し始める 
 データエンジニア参画 
 データ利活用の 
 利用シーンが増加・拡大 

20. Copyright Hacobu, Inc. 20 Hacobu におけるデータ基盤の歩み 
 データ基盤の利用増加に対し、データチームの人的リソースを増強。アナリストに一極集中していた負荷を分散。そ れにより、ラストワンマイル問題が緩和された。

21. Copyright Hacobu, Inc. 21 Hacobu におけるデータ基盤の歩み 
 さらなる利用ニーズに応えるため、dbt の導入などのアーキテクチャ刷新、データレイクの導入、データソースの増強 などを実施。利活用が浸透してきたこともあり、データ利活用への期待がさらなる高まりをみせた。

22. Copyright Hacobu, Inc. 22 社内のデータ利活用を支えていた Looker Studio が、ビジネスメンバーの可視化（ダッシュボード）に対する具体的な イメージを補強。自社のプロダクトデータを用いて顧客提供することで、より Data Driven Logistics を促進していきた い、という流れの中から顧客提供型 BI の開発が始まった。
 Hacobu におけるデータ基盤の歩み 

23. Copyright Hacobu, Inc. 23 Hacobu におけるデータ基盤の歩み 
 顧客提供型 BI は Looker を用いて構築。Looker を用いたことで、署名付き埋込ダッシュボード提供・編集可能な個 社別ダッシュボード管理・セマンティックデータモデルの構築、を3人月程度で実現。
 （詳細：「拠点横断アナリティクス」リリースまでの3ヶ月/登壇資料を参照）

24. Copyright Hacobu, Inc. 24 Hacobu におけるデータ基盤の歩み 
 「ラストワンマイル問題」 
 再発
 分散型データ組織へ 

25. Copyright Hacobu, Inc. 25 Hacobu におけるデータ基盤の歩み 
 しかし、再びデータチームのリソースが圧迫。「ラストワンマイル」問題が再発。
 今後もデータ利用ニーズの増加のたびに、同じ状態になることが予期される。人的リソースの増強以外でも、再現性 のある問題の解決方法が求められた。
 

26. Copyright Hacobu, Inc. 26 解決策の一つとして、データチーム以外にデータチームの一部責務を各部署に委譲。データチームのボトルネックが 緩和された。また、AI が伴走することで、従来はデータチームに聞かなければわからない問題にも一部対応ができる ようになった。
 Hacobu におけるデータ基盤の歩み 

27. Copyright Hacobu, Inc. 27 
 第1章まとめ: 
 
 1. データ基盤立ち上げ後、サポート施策により社内での利活用が増加し「ラストワンマイル問題」発生
 2. 人員増加を行い一時的に解消したが、ニーズの増加により上記問題再発
 3. データチームの責務の一部を各部署に委譲し、上記問題に対応
 Hacobu におけるデータ基盤の歩み 

28. Copyright Hacobu, Inc. 28 分散型データ組織へシフトすることで、ラストワンマイル問題に対応。
 シフトをするためになにをしたのか、開発はどう変わったのかを振り返る。
 チームを拡張する開発スタイル 
 Next: 第2章 チームを拡張する開発スタイル　→
29. 第2章
 チームを拡張する開発スタイル

30. Copyright Hacobu, Inc. 30 チームを拡張する開発スタイル 
 改めて、「ラストワンマイル問題」とはなにか

31. Copyright Hacobu, Inc. 31 チームを拡張する開発スタイル 
 この資料における「ラストワンマイル」とは、「エンドユーザーに対し、分析要件を満たすデータを提供する最後の区 間」と定義する。つまりラストワンマイル問題とは、エンドユーザーが分析に必要なデータ提供を待っている問題と言 い換えられる。
 データチームがボトルネックで 
 データ利活用が遅延する問題 

32. Copyright Hacobu, Inc. 32 チームを拡張する開発スタイル 
 チームの状態からなぜ起きていたのかを分析する

33. Copyright Hacobu, Inc. 33 2024年4月 ~ 現在に至るまで、データチームメンバーは2名しかいない。どちらも全く違うキャリアを歩んできた者同士 で得手不得手がバラけている。そのため、お互いの得意領域を最大限活かす状態を維持することを基本戦略として いる。
 チームを拡張する開発スタイル 

34. Copyright Hacobu, Inc. 34 開発は各自が Backlog に積んだタスクをそれぞれがいい感じに消化していくスタイル。
 Backlog に積まれる前に、タスクの属性から暗黙的にどちらが対応すべきかを決めている。
 チームを拡張する開発スタイル 

35. Copyright Hacobu, Inc. 35 チームを拡張する開発スタイル 
 ラストワンマイルが発生する要因は、端的にいうと「キャパシティオーバー」である。再発した際には、チームで分散し ていたものが、分散出来ない状態に陥ることで再発していた。

36. Copyright Hacobu, Inc. 36 チームを拡張する開発スタイル 
 つまり、「入力量」が「処理可能量」を超えた場合に「キャパシティオーバー」する。「入力量の制限」もしくは「処理可能 量の拡張」、あるいはその両方を行うことでラストワンマイルへの対処が可能となると考えた。
 処理可能量 
 入力量

37. Copyright Hacobu, Inc. 37 チームを拡張する開発スタイル 
 2025年からの開発

38. Copyright Hacobu, Inc. 38 「ラストワンマイル」問題の要因となっているそれぞれの課題に対して打ち手を実施。
 
 入力量の制限 
 　方針：　データチームに流入する前に解決することで、対処可能な量を維持する
 　対策：　「集中型データ活用組織」から「分散型データ活用組織」へのシフト
 
 
 処理可能量の拡張 
 　方針：　処理能力を最大化及びチームで平準化する
 　対策：　全ての工程に AI ツールを適切に活用することで、処理短縮・並列処理化
 
 チームを拡張する開発スタイル 

39. Copyright Hacobu, Inc. 39 チームを拡張する開発スタイル 
 各部署に「データ活用担当」を設置。「集中型」の組織体制から「分散型」のデータ活用組織にシフトすることで「入力 量の制限」を実現。データ活用担当のサポートにデータチームと AI で対応。継続支援可能な状態で、各部署が自走 可能な状態となった。
 データチームがボトルネックで 
 データ利活用が遅延する問題 
 1on1形式でのデータ分析レクチャー などで成長した面々 

40. Copyright Hacobu, Inc. 40 AI 伴走型の分散型のデータ活用組織へシフトしたことで、問い合わせ件数はピーク時の「約50%」ほどに減少。
 チームを拡張する開発スタイル 

41. Copyright Hacobu, Inc. 41 チームを拡張する開発スタイル 
 AI ツールを開発に導入、活用プロセスの検証・整備を進めることで「処理可能量の拡張 」を実現。AI 活用による能力 の最大化を持続可能な状態とするため、プロンプトの整備・アップデートや利用ツールの使い分けなどのプロセス整 備に特に力を入れた。
 個人の処理能力を AI によってスケール 

42. Copyright Hacobu, Inc. 42 現時点（2025年11月時点）で、各工程にて利用している具体的なツールは以下である。
 ツールの選択肢は沢山あるが、選定する際は「セットアップが簡単」で「操作が GUI ベース」であり「課金体系がシン プル」であるものをなるべく選定するようにしている。
 チームを拡張する開発スタイル 
 ビジネスメンバー 
 も利用している 

43. Copyright Hacobu, Inc. 43 調査
 • 「社内コンテキストの調査」なら Notion AI
 • 「考えを整理しながら調査」なら ChatGPT
 • 「コードの調査」なら Devin Search
 チームを拡張する開発スタイル 

44. Copyright Hacobu, Inc. 44 設計・実装・テスト 
 • 「少ない試行回数で実装可能な程度の開発」なら Devin
 • 「ウォーターフォール開発が必要な程度の開発」なら Cursor
 
 チームを拡張する開発スタイル 

45. Copyright Hacobu, Inc. 45 Review 
 • 「タイポ」や「コンテキストが要らないコードの一般的なルールチェック」なら Github Copilot
 
 チームを拡張する開発スタイル 

46. Copyright Hacobu, Inc. 46 
 第2章まとめ: 
 
 1. データ利活用の「ラストワンマイル問題」は「キャパシティオーバー」によって起こる
 2. 「入力量の制限」への対策として「分散型」データ活用組織へとシフト
 3. 「処理可能量の拡張」への対策として AI ツールを開発に導入。活用プロセスを平準化
 チームを拡張する開発スタイル 

47. Copyright Hacobu, Inc. 47 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 AI を活用することで、チームとしての処理能力が拡張された。
 しかし、ハレーション(誤った情報)が混じると思い通りに進まない。
 データ基盤として、どのような打ち手を取ることが出来るだろうか。
 Next: 第3章 セマンティックレイヤーと Hacobu におけるこれからの挑戦　→
48. 第3章
 セマンティックレイヤーと Hacobu におけるこれからの挑戦

49. Copyright Hacobu, Inc. 49 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 「正しい回答」をするプロセスについて考える
 （データ基盤的なアプローチの範囲で）

50. Copyright Hacobu, Inc. 50 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 AI に限らず、人間でも「回答がずれる」ことはある。しかし人間の場合、依頼者にとって本当に必要としている情報（本 質的な回答）を渡せるように「状況、ニーズを特定する具体的なコンテキストや要素 」をヒアリング、もしくは依頼者の 背景情報を読み取ることで「解像度」を高めて回答をしている。

51. Copyright Hacobu, Inc. 51 AI で推論する際も人間と同じ程度に精度を高めたい。「状況、ニーズを特定する具体的なコンテキストや要素 」がわ かれば同じになると、仮定するならば、分析に利用される「ビジネス用語」を「データ定義」として変換（= セマンティッ クレイヤー ）し、コンテキストを理解できる状態にする必要がある。「セマンティックレイヤー 」でビジネスのコンテキス トを与え、誤った推論を防げるのでは。
 
 セマンティックレイヤーと Hacobu におけるこれからの挑戦 

52. Copyright Hacobu, Inc. 52 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 セマンティックレイヤーの設計

53. Copyright Hacobu, Inc. 53 「ビジネス用語」を「データ定義」として変換するのは存外難しい。設計には色々なやり方があるかと思うが、Hacobu では以下の点に注意しながらセマンティックレイヤーを設計している。
 
 
 1. 「単位」を明確にする 
 
 2. 「定義」を明確にする 
 
 3. 「解釈がブレない言葉」を使う 
 
 セマンティックレイヤーと Hacobu におけるこれからの挑戦 

54. Copyright Hacobu, Inc. 54 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 データの「粒度」や「主語」となる「単位」を明確にする ことで、データ項目としてどのような単位での出力になるかの期 待値を揃える。データ項目が「どのビジネスイベント」の「なんの粒度」におけるデータであるかを明確にする。

55. Copyright Hacobu, Inc. 55 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 「定義」を明確にする ことで、対象のデータ定義の出力に対する期待値がブレなくなる。「ビジネス用語」を「データ定 義」として変換する前に事前にコンテキストを図や文章で記述を行い、解釈を揃える。
 作業①
 10:00 11:00 12:00 13:00 現場到着
 待機
 作業②
 待機
 現場撤収
 ①
 ②
 ③
 定義が明確にないと、 解釈に幅が出る

56. Copyright Hacobu, Inc. 56 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 「解釈がブレない言葉」を使う ことで解像度を高め定義したデータが運用された後も認識がずれないようにする。意 味が直感的にわかる日本語を使うことが非常に重要である。ただし、名称が抽象的すぎると一見すると分かりやすい が、解釈の余地が生まれ認識がぶれやすいため、名前をつける際は具体なケースをきちんと理解することが重要と なる。
 6/1 6/2 6/3 6/4 作業実施①
 予約
 作業実施②
 予約
 作業実施③
 予約
 作業実施④
 予約
 稼働日が
 6/2~ 6/3 
 の実績がみたい
 記録⑤
 対象はどれ？ 

57. Copyright Hacobu, Inc. 57 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 「解釈がブレない言葉」を使う ことで解像度を高め定義したデータが運用された後も認識がずれないようにする。意 味が直感的にわかる日本語を使うことが非常に重要である。ただし、名称が抽象的すぎると一見すると分かりやすい が、解釈の余地が生まれ認識がぶれやすいため、名前をつける際は具体なケースをきちんと理解することが重要と なる。
 
 6/1 6/2 6/3 6/4 作業実施①
 予約
 作業実施②
 予約
 作業実施③
 予約
 記録④
 予約
 作業開始日 が
 6/2~ 6/3 
 の実績がみたい
 作業実施⑤

58. Copyright Hacobu, Inc. 58 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 セマンティックレイヤーの構築

59. Copyright Hacobu, Inc. 59 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 Hacobu ではセマンティックレイヤーの構築に Looker を用いている。セマンティックレイヤーの構築経験がなくとも、 Looker のプラクティスに添ってセマンティックレイヤーの構築が可能。
 

60. Copyright Hacobu, Inc. 60 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 Looker はコード管理が可能な BI であり、LookML という Looker モデリング言語を用いてコーディングする。LookML 自体が、セマンティックデータモデルを作成するための仕組みである。Views で定義したデータ項目を Model で定義 した結合条件に基づいて、ダッシュボードや Explore に出力を行う。
 画像引用元: LookMLの用語と概念 | Looker | Google Cloud 

61. Copyright Hacobu, Inc. 61 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 dbt-labs の jaffle_shop を拝借させていただいた具体例をもとに、LookML でデータ定義を行う。
 画像引用元：GitHub - dbt-labs/jaffle_shop-dev: The dev version of jaffle shop
62. Copyright Hacobu, Inc. 62 dbt-labs の jaffle_shop を拝借させていただいた具体例をもとに、LookML でデータ定義を行う。
 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 view: fct_orders {
 dimension: order_id { 
 primary_key: yes
 label: “注文番号”
 type: number
 sql: ${TABLE}.order_id ;; 
 } 
 (中略)
 measure: sum_total_credit_card_amount { 
 label: “クレカ決済額” 
 type: sum
 sql: ${credit_card_amount} ;; 
 }
 measure: sum_total_credit_card_amount { 
 label: “請求金額”
 type: sum
 sql: (${credit_card_amount} + ${bank_transfer_amount}) 
 - (${coupon_amount} + ${gitt_card_amount}) ;; 
 } 
 }

63. Copyright Hacobu, Inc. 63 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 Hacobu では、LookML のディレクトリ構成は dbt ベストプラクティスをベースとしたレイヤーに基づいて管理を行って いる。Model ファイル内に全て記述することも可能であるが、1ファイルにすべての責務が混在することでコード量が多 くなり複雑化していくため、保守性が低くなる。
 依存関係

64. Copyright Hacobu, Inc. 64 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 セマンティックレイヤーの活用例とHacobu におけるこれからの挑戦

65. Copyright Hacobu, Inc. 65 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 Looker で定義したセマンティックデータモデルは、Looker 内部での利用は当然として、API 連携によって、様々な場 所から参照することも可能である。「顧客提供型 BI （拠点横断アナリティクス）」では Looker で作成したダッシュボー ドを署名付き埋め込み表示することで、セマンティックレイヤーにて定義されたデータ項目を利用している。

66. Copyright Hacobu, Inc. 66 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 「AI Lab」は Looker で作成した Query を間接的に利用することで、共通定義されたデータ項目を利用している。

67. Copyright Hacobu, Inc. 67 Looker でセマンティックデータモデルを充足させて行くことで、 AI プロダクトや活用ニーズが高まったときに、シーム レスに対応ができるようになると考える。また、Looker は MCP 対応も可能であるため、既存利用している AI ツール に繋ぎこみすることも可能。AI ワークフローツールなどに連携すれば、更に利活用の幅も広がるのでは。
 
 
 セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 画像引用元: GitHub - googleapis/genai-toolbox: MCP Toolbox for Databases is an open source MCP server for databases. 

68. Copyright Hacobu, Inc. 68 
 第3章まとめ: 
 
 1. 回答の精度を上げるためにコンテキストが必要
 2. Hacobu では Looker を用いてセマンティックレイヤーを構築することで対応
 3. セマンティックレイヤーを充足させていくことで、さらなるニーズを満たす可能性がある
 Hacobu におけるデータ基盤の歩み 

69. まとめ

70. Copyright Hacobu, Inc. 70 第1章: Hacobu におけるデータ基盤の歩みと課題 
 1. データ基盤立ち上げ後、サポート施策により社内での利活用が増加し「ラストワンマイル問題」発生 
 2. 人員増加等の体制強化、システム強化を行い一時的に解消したが、ニーズの増加により上記問題再発 
 3. LLM や周辺技術の進化により状況は大きく変化し、上記問題が解消。次なるフェーズへ 
 
 第2章: チームを拡張する開発スタイル 
 1. AI ツール利用前は個人の能力に依存する状態であり、「人的リソース追加 = スケール」であった 
 2. 「分散型」データ活用組織へとシフト後、AI が伴走することでより効果的に流入抑制可能に 
 3. 利用シーンに応じてツールを使い分けることやチームでの活用プロセスの共有が重要 
 
 第3章: セマンティックレイヤーと Hacobu におけるこれからの挑戦 
 1. 回答の精度を上げるためにコンテキストが必要 
 2. Hacobu では Looker を用いてセマンティックレイヤーを構築することで対応 
 3. セマンティックレイヤーを充足させていくことで、さらなるニーズを満たす可能性がある 
 まとめ