Google Cloud Next Tokyo ’25_AI に業務の意味を教えるオントロジー入門

AI に業務の意味を教える オントロジー入門 対話型データ分析で AI の判断を曖昧にしないためには どうすれば良いのか？ Proprietary

イワオ カズマサ 岩尾 一優 株式会社 MBK デジタル 執行役員 CTO Google Developer Experts / Google Cloud Google Cloud Next Tokyo Proprietary

株式会社 MBK デジタル 企業のデータ活用 / AI 活用を支援 データ活用戦略の策定から、業務データの分析、データ基盤・ 分析環境の整備、生成 AI / AI エージェントの実装までを 一気通貫で支援しています。 対話型データ分析・ AI エージェント活用 自然文でデータを扱う体験を、業務で使える形にするために、 データ・業務用語・判断ルールをつなぐ設計と 実装に取り組んでいます。 Google Cloud Next Tokyo Proprietary

発表サマリー 対話型データ分析で AI の判断を曖昧にしないためには、 AI に業務の意味を教える必要があります。 本日は、 1. なぜそれが必要なのか 2. 何を整理すればよいのか 3. Google Cloud でどう実装するのか をお話しします。 Google Cloud Next Tokyo Proprietary

01. なぜ今、業務の意味の 話をするのか？ Google Cloud Next Tokyo Proprietary

AI は個社ごとの業務を知らない 自然文でデータを使えるようになり、 AI がデータに直接アクセスする場面が増えている。 ただし、AI が賢くなっても、 その会社で使われる言葉や判断基準 までは自動では分からない。 だからこそ、データを渡す前に、業務の意味を渡す必要がある。 Google Cloud Next Tokyo Proprietary

同じデータでも、前提が違えば答えは変わる 例：P1 障害 INC-2048 で、今すぐ連絡すべき顧客 は？ 解釈 A 解釈 B 解釈 C 影響を受ける顧客を広く見る 法人顧客だけに絞る 優先連絡順まで固定する → A社・C社・D社 → A社・C社 → C社・A社 データは同じでも、前提と優先順位が違えば答えは変わる。 だから、言葉・データのつながり・判断ルールを先に整理する。 Google Cloud Next Tokyo Proprietary

前提を 3 つに分けて整理する 言葉 「今すぐ連絡すべき顧客」 とは誰か データの つながり 障害から顧客まで、 どのデータをたどるか 判断ルール 優先連絡の対象と順番を どう決めるか この発表では、この 3 つを軸に、AI の判断を曖昧にしない方法を見ていく。 Google Cloud Next Tokyo Proprietary

02. 業務の意味を、 軽量なオントロジー として整理する Google Cloud Next Tokyo Proprietary

オントロジー = 業務判断の前提をそろえるための軽量な知識モデル ここでは、学術的な定義ではなく、 実装で使うための整理として扱います。 指標の定義（セマンティックレイヤー）に、 用語とデータのつながり・判断ルールまで含めたもの、と 捉えてください。 言葉 Google Cloud Next Tokyo + データのつながり + 判断ルール Proprietary

まず、曖昧な言葉を定義する 今すぐ連絡すべき顧客 障害対応優先顧客 （曖昧な言葉） （定義された業務用語） 人によって解釈が変わる 連絡・対応の優先対象として、 条件を満たす顧客 曖昧な言葉を、Knowledge Catalog 上の業務用語として定義する。 Google Cloud Next Tokyo Proprietary

障害から顧客まで、 データのつながりを整理する 顧客 Customer 契約 Contract サービス Service 障害 → コンポーネント → サービス → 契約 → 顧客 → 担当者 この順番でたどることで、障害時に連 絡すべき顧客と担当者を特定する。 ポイント 担当 CSM CSM 障害 Incident コンポーネント Component 実装では、このつながりを BigQuery Graph として扱う ※BigQuery Graph は Preview Google Cloud Next Tokyo Proprietary

「今すぐ連絡すべき顧客」の 判断条件を固定する 正式用語 障害対応優先顧客 このデモでは、 5 つの条件で 「障害対応優先顧客」を 定義する。 指定した障害について、以下の条件をすべて満たす法人顧客。 B2B 顧客である 有効契約を持つ ポイント 契約更新まで 60 日以内 実装では、この条件を 検証済みクエリ として固定し、 BigQuery のエージェントが質問 をそのクエリへつなぐ。 対象障害が P1 かつ OPEN 契約サービスが、障害の影響を受けるコンポーネントに依存している Google Cloud Next Tokyo Proprietary

整理した意味を、 役割ごとに Google Cloud へ実装する 言葉を定義する つながりをたどる 判断を固定する 自然文で使う Knowledge Catalog BigQuery Graph 検証済みクエリ BigQuery のエージェント 定義・関連語・公式データとの 対応 障害から顧客までの 到達経路 5 条件で絞り込むクエリを固定 質問を受け取り、 検証済みクエリにつなぐ 言葉・データのつながり・判断ルールを分けて実装することで、それぞれを個別に検証・変更・版管理できる。 契約サービスが、障害の影響を受けるコンポーネントに依存している 言葉 判断ルール + データのつながり + Google Cloud Next Tokyo → 根拠つきの回答 Proprietary

03. 定義した意味を BigQuery の エージェントで使う Google Cloud Next Tokyo Proprietary

BigQuery のエージェント Conversational Analytics in BigQuery 自然文の質問を、 業務の文脈に基づく分析結果へつなぐ インターフェース Google Cloud Next Tokyo Proprietary

エージェントが回答するまでの流れ 1 2 3 自然文の質問を受け取る 用語集と手順を参照し、質問の意味をそろえる エージェントがやること ● 質問の言い換えを吸収する ● 業務用語の意味を参照する ● 実行すべき検証済みクエリを選ぶ ● 質問に含まれる障害 ID や 対応する検証済みクエリを選ぶ いつ時点で判定するかを、 クエリの入力値として渡す 4 質問からパラメーターを抽出してクエリに渡す 判断条件はエージェントがその場で考えるのではなく、検証済みクエリに固定する。 Google Cloud Next Tokyo Proprietary

<project_id> <project_id> エージェントに 登録するもの <project_id> A ナレッジソース B 手順 C 検証済みクエリ D 用語集 参照するデータ 振る舞いを誘導する指示 判断ロジックを固定するクエリ 業務用語の意味 エージェントには、 参照データ・手順・検証済みクエリ・用語集 Google Cloud Next Tokyo を登録する。 Proprietary

検証済みクエリと入力パラメーターを定義する クエリが受け取る入力パラメーター @incident_id @as_of_date <project_id> @as_of_date は、 契約更新日までの日数を計算する基準日。 エージェントは、質問からこれらの値を 抽出し、検証済みクエリに渡す。 Google Cloud Next Tokyo Proprietary

質問から入力を抽出し、検証済みクエリに渡す ユーザーの質問 検証済みクエリの入力 INC-2048 で、 今すぐ連絡すべき顧客は？ @incident_id = INC-2048 理由と担当 CSM も教えて。 基準日: 2026-07-30 @as_of_date = 2026-07-30 エージェントは、質問から必要な値を取り出し、検証済みクエリに渡す。 Google Cloud Next Tokyo Proprietary

つながりの判定は、検証済みクエリの中で行う 検証済みクエリ 通常の SQL 条件 BigQuery Graph つながりをたどる B2B 顧客である 契約サービスから障害影響コンポーネントまでの、直 有効契約（ ACTIVE） 接・間接の依存関係をたどる。 契約更新まで 60 日以内 対象障害が P1 / OPEN 顧客属性や契約状態は SQL 条件で絞り込み、 サービスとコンポーネントの依存関係は BigQuery Graph でたどる。 Google Cloud Next Tokyo Proprietary

エージェントは、定義済みルー ルに基づいて回答する C社 1 担当 CSM 鈴木 葵 契約更新まで 21 日 対象サービス Reporting API A社 2 担当 CSM 山田 花子 契約更新まで 45 日 対象サービス Analytics Enterprise 優先順位は、エージェントが考えたものではなく、 検証済みクエリに定義したルールによって決まる。 Google Cloud Next Tokyo Proprietary

回答には対象顧客だけでなく 根拠と再現方法も含める 回答に残るもの 正式用語 障害対応優先顧客 判定根拠 契約 / 更新日 / サービス / 障害状態 影響経路 どのサービスが、どの障害に関係したか 再現方法 rule_version / as_of_date / evidence_selection_policy 検証済みクエリの返却列とエージェントの手順で、 同じ判断を再現できる情報を回答に含める。 Google Cloud Next Tokyo Proprietary

AI に任せるのは業務判断ではなく、橋渡し 固定したもの 正式用語 対象条件 入力 @incident_id / @as_of_date 検証済みクエリ 判定根拠 再現方法 AI に任せたもの 質問の言い換え吸収 入力の取り出し 回答文の組み立て 読みやすい説明 最終的な業務判断はルールとして固定し、自然文との橋渡しを AI が担う。 定義した範囲の外では推測で答えず、検証済みクエリを追加しながら、答えられる範囲を育てる。 Google Cloud Next Tokyo Proprietary

1 AI に答えさせたい業務質問を 1 つ決める 2 その質問で使う正式用語を決める 3 必要なデータのつながりを整理する 4 対象条件と優先順位をクエリに固定する 5 エージェントから、 そのクエリを呼び出せるようにする 6 根拠と再現方法を回答に残す CLOSING まずは 1 つの業務質問を 再現できる判断にする AI に業務の意味を教える第一歩は、 全社のオントロジーを作ることではなく、 1 つの業務質問を再現できる形にすること。

Thank you 本資料はこちらで公開予定 → Proprietary