#1 セマンティック概論 Google Cloud Next '26 風音屋 Recap 投影資料 （一部抜粋・調整済み） 2026-06-04 Google Cloud Next ‘26 Recap 株式会社風音屋 横山 翔（Sho Yokoyama） @yuzutas0 SpeakerDeck 公開版 

#2 注意事項 1. 本件は招待制のクローズド勉強会となっております。風音屋の取引先各社、アドバイザー・業務委 託、従業員、講座受講生など、対象者のみに個別案内を差し上げています。 2. 本資料は許諾した範囲内でのみご利用ください。無断転載ならびに複写を禁じます。 3. 本資料に記載されている会社名・製品名などは、一般に各社の登録商標または商標、商品名です。資 料内では ©, ®, ™ マーク等は省略させていただいております。 4. 本資料は特定企業の情報公開や称賛・批判を意図するものではありません。社名が提示されていない ケーススタディやシステム構成は、原則的に複数企業の事例を踏まえたダミー情報となります。 5. 説明を簡略化するために、用語やツールの紹介は厳密な定義に則っていない場合があります。ご自身 や所属チームでの理解・解釈が紹介内容と異なる場合は、適宜読み替えていただけると幸いです。 6. 本資料はGoogle Cloudならびにその関連企業の見解を代表するものではありません。風音屋は Google Cloudの認定パートナー企業であり、発表者はGoogle Developer Expertsに所属しています が、あくまで独立した立場にもとづいて情報発信を行っています。 

#3 風音屋 横山（yuzutas0） リクルートやメルカリにてデータ活用を推進、AWSを経た後、風音屋（かざねや）を創業。広告配 信最適化や営業インセンティブ設計など、データを駆使した業務改善や利益創出を得意とする。 Google社が認定するグローバルの技術エキスパートGoogle Developer Experts、東京大学 経済学 研究科 金融教育研究センター 特任研究員、独立行政法人情報処理推進機構（IPA）にて情報処理技 術者試験委員などを歴任。 データ基盤構築やデータ分析について積極的に情報発信をしており、主な著書・訳書に『実践的デー タ基盤への処方箋』『データマネジメントが30分でわかる本』『アジャイルデータモデリング』が ある。 1,970人が参加するSlackコミュニティ「datatech-jp」、延べ参加者15,640人の勉強会「Data Engineering Study」の立ち上げに関わるなど、日本のデータマネジメント業界ならびにデータエン ジニアリング業界の発展をリードしてきた。 本名は横山翔。静岡県裾野市で江戸時代に名主・牧士を務め、300年前から村のデータを管理してき た横山家の末裔。時代や職種を問わない「本質的なデータマネジメント」のあり方を説く。 

#4 開催概要 ● Google Cloud Next や Google I/O で各Google製品のアップデートが発表されました。 改めてRecap（おさらい）の場を設けてキャッチアップをしていけたらと思います。 ● Google Cloudに関するオンライン勉強会ではありますが、 他のプラットフォームを使う方々のヒントになる話も出てくるかもしれません。 お約束はいたしかねますが、ぜひご検討ください。 

#5 参考資料 ① Google Cloud Next '26 のアップデート概要 https://cloud.google.com/blog/ja/topics/google-cloud-next/google-cloud-next-2026-wrap-up ② BigQuery Graph, BigQuery Measuresのベースとなる論文 https://research.google/pubs/semantic-data-modeling-graph-query-and-sql-together-at-last/ 

#6 本日のアジェンダ メイン登壇者 アジェンダ ① Google Cloud Japan yu-yamadaさん Analytics系サービスのアップデート紹介 ● BigQuery Graph, 同 Measures, 同 Vector Search, Smart Storage などのご紹介 ② Q：風音屋 横山（yuzutas0） A：yu-yamadaさん Google Cloud Next '25 の答え合わせ ● 去年アナウンスされた機能はこの1年でユーザーに普及したのか？ ● 今回の各アップデートが1年後にどのパターンに当てはまりそうか？ ③ Google Developer Experts & メルカリ na0さん ユーザー事例紹介 ④ Google Developer Experts & 風音屋 横山（yuzutas0） セマンティック概論 ● セマンティック、セマンティックレイヤー、オントロジー、ナレッジ グラフ、グラフDBとは何か？について超早口で解説 ⑤ 3名 質疑応答・ディスカッション 当日の進行によっては内容が変更となる場合がございます。あらかじめご承知おきいただけますと幸いです。 

#7 セマンティック概論 

#8 セマンティックとは ● 「情報の意味」を管理するための技術や取り組み。 ○ 「りんご」と「リンゴ」と「林檎」と「アップル」と「Apple」と「🍎」が同じものを指す。 ○ いずれも「食品 > 果物」の配下に位置する。 ● Google検索を行う場合 ○ 「りんご」で検索すると「リンゴ」の記事も出てくる。 ○ 「りんご」「ジュース」で検索すると「アップルジュース」が出てくる。 ○ まるで意味を理解しているような振る舞い＝「セマンティック検索」と呼んだりする。 ● セマンティックWEB ○ WEBページにおける「意味」をコンピュータが処理するための技術。 ○ 例：

1590年 横山政影、小田原城から高野山へ

は「見出し」である。 ● 単語のベクトル化 ○ 大量の文書をもとに、単語・トークン同士の関係性を抽出する手法 ○ 例：king + woman - man = queen 

#9 セマンティックレイヤー（DWH・BI）① ● dbtやLooker、Snowflakeの「セマンティックレイヤー」は「ファクトとディメンションをどう組み 合わせてどのような集計をするのか」を設定ファイルで定義し、参照するための機能。 ● 日付別（ディメンション）の注文総額（ファクト）といった形で集計する。 詳細は『アジャイルデータモデリング』や「データモデリング研修」「K-DEC」を参照。 

#10 セマンティックレイヤー（DWH・BI）② ● 結果として「商品の売上とはこの数値を指す」という定義がなされることになる。 ○ 「意味」を管理するというよりは、 「ファクト＋ディメンションを管理する機能」の延長として 「集計指標の意味が統一される」と捉えるほうが実態に即している。 ○ 「売上シート」と名前をつけて「これが公式の売上だ」と言っているのと実質的には同じ。 ● もともとは「意味」を管理することを目指して「セマンティック」という言葉を使っていた。 ○ 紆余曲折を経て、「データ集計処理の管理場所」という側面が強調されてしまい、現在の形に なっているものと思われる。 ○ 2000年頃のBIツールのセマンティックレイヤー機能が、ストアドプロシージャのようにSQLカ プセル化の役割を果たしていた。今のDWH・BIにおけるセマンティックレイヤーもその延長。 ● 独自シートより会計ツールのが会計処理しやすいのと同じ。専用ツールを使うことに意味がある。 ○ 自前で 「ファクト＋ディメンション」を管理するには、ルールやスクリプトの整備が必要。 ○ 「ファクトとディメンションをどう組み合わせてどのような集計をするか」を設定しているの で、コンテキストを与えられたときに、AIエージェントが解釈をしやすい。 

#11 セマンティックレイヤー（AIエージェント） ● 最近だとAIエージェントにおける「コンテキストレイヤー」とニアリーイコールな使われ方をされる ことが増えている。セマンティックレイヤー（DWH・BI）とは今のところ別物。 ○ 一般的なセマンティック ∋ AIのコンテキスト ≠ セマンティックレイヤー（BI/DWH） ● ざっくり解説 ○ AI推論モデル＝WEB文章等を学習したもの。プロンプトを与えられると推論結果を返す。 ■ 例：学習元「私はパンが好き」→指示「何が好き？」→推論「パンが好き」 ○ プロンプト＝明示的な単発の指示文。 ■ 例：「このメールの返信文を作って」 ○ コンテキスト＝暗黙的に読まれる一連の情報。 ■ 例：プリセットされた「メール返信時のルール」「署名欄の記法」ファイル。 ○ ハーネス＝システムの振る舞いを制御する仕組み。 ■ 例：ユーザーが承認ボタンを押さないとメールソフトへのアクセスができない。 ● コンテキストを整備するための一連の仕組みなどを総称して「コンテキストレイヤー」と呼ぶ。 ○ 例：社員がAIエージェントを使うと自動で「メール返信時のルール」が読み込まれる。 

#12 社内コンテキストを管理・集約する 日々の仕事で人間は「非構造化データ」を無意識のうちに処理している。 ● ビジネスモデル、事業計画、沿革、創業者の口癖 ● お客様の声（VoC）、契約理由・解約理由、クチコミ・評判 ● 稟議ワークフローのメモ欄、会計ソフトのメモ欄 ● 体制図、会議体、関係者一覧、Aさんとの会話のコツ ● カレンダー、メール、チャット ● 業務マニュアル、作業手順書、作業記録 ⇒先輩社員が新入社員に口伝で引き継ぐような知見をドキュメント化し、AIのインプットにする。 ● 新入社員向けの「これを読んでおけ」リスト ● オンボーディング資料 ● ◯◯業務 虎の巻 ● Bさんの自分用メモ（部署の全員が参考にしている） リリース記録_201704XX リリース作業手順書 インフラ環境一覧 View Controller Model Jenkinsログイン情報 リリース記録_201705XX リリース記録_201706XX L 全体広報 L ビジネス　# 戦略、KGI/KPI L リソース　# ヒト、モノ、カネ、情報（新規メンバーのJoinメニューやエンジニアレジュメは「ヒト」の下） L システム　# アプリやインフラの構成など（あくまでもロゼッタストーン） L 施策　　　# プロダクト・システム・プロセスを改善する施策 L 運用　　　# カスタマーサポート、プッシュ通知の配信、インフラ保守といった個別作業 L プロセス　# 立案から価値創出までのバリューストリーム（→ KPTを通して改善する） L イベント　# 定期的な打ち合わせや指標確認（→ 組織全体で可視化すると重複や無駄が目立つようになる） L 個人　　　# Inbox代わり 

#13 コンテキストがなければデータ分析にならない 遊園地のデータ分析を任せると？ ● AIエージェント：なぜか休日なのに売上が0になっているぅううううッ！ ○ 担当者：その日、休園日や……。 ● AIエージェント：なぜか平日なのに売上が急増しているぅううううッ！ ○ 担当者：その日、開園10周年イベントや……。 ● AIエージェント：昨年度の売上は◯億円です！ ○ クエリ：WHERE year_month BETWEEN ‘2025-04’ AND ‘2026-03’ ○ 担当者：うち6月決算や……。 こうした課題に対する従来のアンサーは「メタデータ管理」や「データカタログ製品」だった。 ● さらに現在では「メタデータの調査・入力の業務をAIエージェントにやらせる」「グラフ形式でオン トロジーを管理する」といったアップデートが生じている。 ● とは言え、上記のようなケースであれば、大掛かりなことをする必要はない。自社の概要を.mdファイ ルに書いておくだけで回避可能ではある。 

#14 メタデータ管理 ● 業務用語集 ○ その業務に固有の用語をまとめたもの。 ○ 関連情報として業務の概要や流れ、登場人物や担当部署、利用アプリケーションを書き出す。 ● ディレクトリ／カタログ ○ 影響範囲を調査するときなどにシステムやデータを探すための目録。 ● データディクショナリ（辞書） ○ データの項目名やテーブル構造、説明文などが記入されている。 

#15 メタデータのラベル付け 統制語彙 　トップダウンのアプローチ。管理者が社内データと整合的なラベルを付ける。 　L シソーラス 　　　同じ意味、似た意味、包含関係、上位・下位をまとめたもの。 　　L 同義語リスト 　　　　似た意味の言葉をまとめたもの。 　　L オントロジー 　　　　語彙の関係性をツリー状にまとめたもの。 　　　L タクソノミ 　　　　　階層構造を持った分類。大カテゴリ＞中カテゴリ＞小カテゴリなど。 フォークソノミー 　ボトムアップのアプローチ。利用者が必要に応じてラベルを自由に付ける。 ※実務だと「公式ラベル」（統制語彙）と「通常ラベル」（フォークソノミー）を組み合わせて、 　一定の基準を満たしたら「通常ラベル」から「公式ラベル」に昇格させるなど、両者のメリットを活かす工夫が可能。 

#16 データカタログ ● メタデータの管理ツール。データを検索したり、データの特徴や注意点を調べることができる。 ● タグやキーワードの入力ルールを定めて、社内に普及させることが活用のポイントとなる。 https://open-metadata.org/ Open Metadata で記載内容の承認 https://docs.getdbt.com/docs/collaborate/documentation dbt docs でテーブルや列の説明を表示 

#17 オントロジー（従来） 元々はオントロジーと呼ばれていたのはこういうやつ https://www.jfe-tec.co.jp/jfetec-news/61/5p.html 

#18 オントロジー（最近） 現状のベンダー製品で実際に作れるのはこういうやつ https://cloud.google.com/blog/ja/products/data-analytics/introducing-bigquery-graph?hl=ja 

#19 オントロジー管理の歴史 ● 基本は国語辞典や社史編纂のような作業。GoogleやIndeedなど「検索機能」が売上を支えるメインの サービスでないと、取り組みを着手・継続することが難しかった。単発検証レベルで終始しがち。 ● 2000年代はWebで民主的に意味を紐付け＆解釈するための取り組みが模索された。Wikipediaでは ユーザーが自由に記事のカテゴリを編集したり、カテゴリ同士の親子関係をまとめたページを作るこ とができる。世界中のインターネットユーザーで国語辞典を共同編集することで「中央集権では投資 を続けられない」という課題を解消した。 ● 2010年代はDeep LearningやLLMのように、膨大な文書データをベクトル化して一括処理するような アプローチが主流になった。わざわざ人間がデータを1つ1つ入力・管理しなくても、膨大なテキスト 情報からITシステムに解釈・予測させることが可能になった。 ● 2024年頃からRAGがブーム。生成AIモデルがWEBコンテンツをもとに一般的なオントロジ（に相当し うる情報：リンゴ＝Apple＝🍎∈果物∈食品）を内部的に持っているため「1から国語辞典を作る」ス テップを省略し、自社特有の情報を上乗せすることで社内検索システムを構築できる。「生成AIの持 つ一般的な知識」＋「自社特有の情報」を組み合わせるアプローチが現在の主流。 

#20 オントロジー vs データモデル（バックエンド開発）① オントロジー特有の表現やメリットもあるのだが、現状の各ベンダー製品が実現しようとしている内容は どちらかというと2000年代のバックエンド開発におけるデータモデル（ER/クラス図/UML/DDD）では？ http://www.happiese.com/system/dataorient.html 

#21 オントロジー vs データモデル（バックエンド開発）② ● このくらいの粒度・抽象度で「ER/クラス図/UML/DDD」をドキュメント管理するとベスト？ ● 未成熟な専用ツールを使わなくても、AIエージェントに markdown + mermaid（またはplantuml） を出力させてGit管理させる（データ分析ではそれを読ませる）だけなら、今日から始められるはず。 https://little-hands.hatenablog.com/entry/2022/06/01/ddd-modeling 

#22 Why Now? 近年のオントロジーへの注目は、Palantirの取り組みが発端 ● データを統合・活用するプラットフォームを提供している ○ 例：イラン空爆や要人暗殺SaaSで良くも悪くも話題に… ○ オントロジー管理に注力している ● FDE（めっちゃ仕事デキる人）が現場に入り込む ○ 業務・システムのAsIsを読み解く = オントロジーが充実 ○ 業務・システムのToBeを描き、装着する https://www.palantir.com/explore/platforms/foundry/ontology/ 

#23 EA（エンタープライズ・アーキテクチャ） ● 業務プロセス、データ、情報システム、テクノロジーインフラストラクチャのAsIsとToBeを整理する ためのフレームワーク。 ● DMBOKのデータアーキテクチャは、EAの「データアーキテクチャ」に由来するキーワード。 https://www.ntt-tx.co.jp/column/yasuda_blog/20151102/ 

#24 「子どものお弁当を作ろう！」を業務とみなした場合のEA（仕事でも同じように各業務を整理する） EAの成果物のイメージ ビジネス アーキテクチャ アプリケーション アーキテクチャ データ アーキテクチャ テクノロジー アーキテクチャ レシピ動画 を見比べる 料理を 決める 通販サイトで 器具を買う スーパーで 材料を買う 材料が あるか？ 料理 する 食べて もらう ・食べ残し ・食べる速さ ・感想を聞く 振り返り 器具が あるか？ 動画視聴 データ 通販注文 データ POS注文 データ 電気 利用量 食事記録 Youtube iOSアプリ 通販サイト スーパーの POSレジ 電気 メーター 紙の手帳 Youtube サーバDB 通販サイト DB POS会社 DB 電力会社 DB 紙の手帳 

#25 オントロジー（？） ● Palantirの言うオントロジーは「（EAを含めた）AIのコンテキスト」を補完するツールキットとして の「データモデル（バックエンド開発）」という表現が近いかも？ ● 人々が「うちもオントロジーを整備しなきゃ」と言い出し、各ベンダーがその期待に応えようとして 提供している「オントロジー機能」は、従来の（ツリー構造・グラフ構造の）「語彙管理」と 「データモデル（バックエンド開発）」を両取りしようとして中途半端になっているような状態？ ● どちらにせよグラフ構造で管理することになる＆インターフェース設計の問題ではある（今後改善が 期待できる）ので、土台となるグラフDBの進化がキーであることは間違いない。 https://www.jfe-tec.co.jp/jfetec-news/61/5p.html https://www.palantir.com/explore/platforms/foundry/ontology/ 

#26 グラフとは① ノード（◯）とエッジ（→）で表現される構造のこと パスタ お前 俺 美味しい 作った 一目惚れ 幾千の星 目を閉じれば 見える 雲 かすめる かすめない 家庭的 な女 タイプ has / belong 

#27 グラフとは② 横山の論文（東京大学CARF・内閣府） https://kazaneya.com/888f29b582ea43928544a9b9a0ad6e6e ● 消費者ノード（◯） ● 飲食店ノード（◯） ● 支払いエッジ（→） ○ COVID-19 パンデミックの前後で細くなる ○ 飲食店の利用が減ったことが分かる こういった関係性を分析できるツールキット。 同様に、取引グラフから与信・市場予測したり、 コミュニティ分割（似たグループをまとめる処理）で 商品のレコメンドを行ったりすることができる。 ※実務では計算量を抑えるため、隣接行列に置き換えるほうが近年の主流アプローチと言えるかも……。 

#28 ネットワーク分析 こういった手法を「ネットワーク分析」と呼ぶ。 右の書籍はPythonでソースコードを動かしながら 主要手法を学ぶことができるので、数式が苦手な人にもオススメ。 「この本を BigQuery Graph でやってみた」記事が出ると最高？ AIエージェントに聞きながら再現してもらえば同じことか。 ただ、企業のビッグデータを扱う場合、 Python & Networkx ではサーバスペックが足りなくなるので （バカでかいサーバを立てるとデイリー数万円が消し飛ぶ） 専用のグラフDBを導入するのが理想ではある。 

#29 グラフDB いわゆるリレーショナルデータベースはグラフ処理が苦手とされている。 「ノードA」→「ノードB」→「ノードC」と多重参照するときに、回数不定形のループ処理が必要になる。 この処理に特化したのがグラフDB。 1レコードごとに「ノードA」「エッジ」「ノードB」列を持つ。 ただし、これまでは専用のDBシステム（例：Neo4j）を運用保守できる人が必要だったり、 メインDBとは別のインスタンス（Amazon Neptune）を管理するコストがかかるので、 業務利用のハードルが高かった。 BigQuery Graphでサーバレス提供＆コンソールSQL操作が可能になると、活用の幅が広がる…はず！ 

#30 ナレッジグラフがグラフ構造である必然性 意味やナレッジを正確に表現しようとするとグラフ構造になる。 人間やAIに「AさんはBさんちの犬が好き」と伝えると 「AさんとBさんの仲が良い」「Aさんは犬全般が好き」といった 「そんなこと言ってないよ」という誤解をされることがある。 「AさんはBさんちの犬が好き」という言葉を与えられたときに 右のようにグラフ構造（ツリー構造）で正確に表現すると、 こうした誤解を防ぐことができる。AさんとBさんの関係性はNullです！ 　　　⇓ AIエージェントが正確にナレッジを処理するためには グラフ構造で表現することが最も効果的（高性能）と言える。 ただし、運用できるか？システムが使いやすいか？は別論点。 https://yuzutas0.hatenablog.com/entry/2026/02/10/213000 | 家庭学習で国語力を養わないと企業の人材育成では難しいという記事。 

#31 「資料間の矛盾」や「主張の違い」もグラフで表現できる 例： ● 天照大神（日本の太陽神）が閉じこもった「岩戸隠れ」の伝承が「古代の日食」を指すと言う説。 ● 具体的に「どの年代」の「どの地域」で起きた日食なのかは論者・論文によって主張が異なる。 https://x.com/yuzutas0/status/2040448874985468087 | そのうち「歴史研究ｘAI活用」のKindle書籍を出版するかも。 

#32 コンテキストの立体構造 ビジネスに置き換えると… ● 営業とサポートで課題意識が異なる場合（観点・視点の違い） ● 後から過去の施策分析が誤りだと判明した場合（過去補正・経年変化） など、当然ながらコンテキストは立体構造になる。 こうした観点までグラフ形式で管理し、AIエージェントが考慮・解釈できるようになると、 一気に「人間の意思決定者」の見え方に近くなる（はず）！ まぁでもこれをわざわざユーザー側が定義するのか、AIモデルの内部挙動に取り込まれるのかで言うと、 後者のほうが圧倒的に幸せだとは思いますけどね。 そうしたアプローチも（もちろん）既に模索されています。 例：Microsoft Research の GraphRAG など。 

#33 メタデータ まとめ：直近のAnalytics業務におけるセマンティック議論の全体像 クエリ履歴 よく使われる テーブル同士 の関係性 グラフ データ カタログ ゴールデン クエリ （サンプル SQL） AIエージェント が分析 社内 ドキュメント 分析レポート （過去蓄積） セマンティック レイヤー整備 （Dim / Fact） 黄：従来からある 橙：ちょい前から普及 赤：最近のやつ オント ロジー 源泉DBの ER / DDL エージェントスキル エージェントスキル エージェント スキル セッション裏で10分で書き殴ったやつなので色々と変だったらゴメンナサイmm 

#34 おわりに 

#35 データエンジニアリングを楽しもう！ データエンジニアリングは、いわば総合格闘技です。 データの重要性が日々増していく時代、世界中で誰もが困っている課題に立ち向かっていく仕事です。 エンジニアリングの面白さ（そして難しさ）が詰まった、やりがいのある分野です。 この発表が皆様の業務に少しでもお役に立てたら嬉しく思います。 

#36 ご清聴ありがとうございました 改善サイクルを回し、今日よりも良い明日を。 https://kazaneya.com/contact