AI に「売上とは何か」を教えるのは、エンジニアではなく業務と経営の仕事だ

登壇したのは、Google Cloud データアナリティクス事業本部 データアナリティクスセールス 部長の五十嵐彬氏だ。

五十嵐氏は、BI（ビジネスインテリジェンス）ツールの会社 Looker の出身だ。2019年、日本での立ち上げに合わせて入社した。その3か月後、Google Cloud による Looker の買収を、フェイスブックのニュースで知ったという。まさに寝耳に水。小さな会社を大きくしようと入ったら、急に大きな会社の一員になっていた。

Google Cloud データアナリティクスセールス 部長の五十嵐彬氏

AI エージェントの時代に、何が変わるのか

本題は、AI の進化を振り返るところから始まった。以前は、その都度人が指示を出して動かす必要があった。それがいまは、目的やゴールをエージェントに伝えれば、その目的に向かって自律的に動く形に変わってきている。

では、AI エージェントは何でできているのか。五十嵐氏は、人の体にたとえて4つの部品に分けた。

• 脳（モデル）：考える力。Gemini などの大規模言語モデル（LLM）
• 手足（Skills）：ツールを動かす、SQL（データベースに問い合わせるための言語）を書く、レポートを作るといった実行の力
• 骨格（ハーネス）：計画し、実行し、確かめる流れを回す仕組み。権限や安全装置もここに入る
• 接地（コンテキスト）：業務用語の意味、データの在りか、指標の定義

このセッションの主役は、4つ目の接地だという。五十嵐氏のたとえはこうだ。優秀な新卒に、手順書と社内ルールを渡したとする。それでも、社内での売上の定義や、どこにどんなデータがあるかを知らなければ、仕事はこなせない。

同じ「売上」が、部門で違う

例に挙がったのは、EC サイトの「先月の売上」だ。マーケティング部門に聞くと、1.2億円。注文が入った時点で数え、クーポンを引く前の、税込みの金額だ。経理部門に聞くと、0.98億円。配達が終わったものだけを数え、返品を除いた、税抜きの金額だ。どちらも「売上」としては正しい。だが AI は、どちらの定義を使えばよいか分からない。そのため、経理が聞いているのに、マーケティングの数字を返してしまうことが起きる。これも、いわゆるハルシネーション（AI がもっともらしい誤りを言うこと）だ。

スライドの結論は、「原因はモデルではなく、『売上とは何か』がデータ側に書かれていないこと」だった。

同じ「売上」でも、部門によって定義が違う

これは大事だ。まず言葉を揃える。AI 以前に、人の組織の中で「売上」の定義が揃っていなければ、AI はどちらかを当て推量で選ぶしかない。

人が読む基盤から、AI が動く基盤へ

では、どうすればよいのか。五十嵐氏が示したのが、データ基盤の考え方の転換だ。これまでのデータ基盤は、人、つまりアナリストが読むためのものだった。これからは、AI が理解し、行動するためのデータ基盤が要る。その条件は3つある。

• 境界のないデータ：どのクラウドにあるデータも、移さずにつないで読める
• 意味（セマンティック）：「売上」とは何か、といった指標や用語の定義
• 知識（オントロジー）：顧客、商品、取引などがどうつながっているかという、知識の地図

この3つを企業の規模で提供する設計が、SOAP Architecture だ。SOAP とは、Semantic and Ontology Agent Platform、つまり「意味と知識を土台にしたエージェント基盤」の頭文字である。

言い換えれば、データに「辞書」と「地図」を付けておく設計だ。人のアナリストなら、表の裏にある事情を経験で補える。AI にはそれができない。だから、暗黙の了解をデータの側に書き出しておく。

ここは、本当に大事だ。筆者も個人的に、もっと学びたいと思った。

カタログは「AI の辞書と地図」

SOAP の柱の一つが、Knowledge Catalog（ナレッジカタログ）だ。五十嵐氏はこれを「AI の辞書と地図」と表現した。中身は、ビジネス用語集、顧客と契約と請求のようなデータ同士の関係（オントロジー）、データがどこから来てどう加工されたかという系譜、データの品質、そして誰が見てよいかという権限だ。AI は問い合わせの前にまずここを読み、「この会社で顧客とは何か」「どの表が正しいのか」を解決してから答える。

本当に、このオントロジーの分解と設計こそが大事だ。「顧客」とは何か、どの表が正しいのか。それを決めるのは技術ではなく、業務を知る人の仕事である。

セマンティックレイヤーは「計算式集」

もう一つの柱が、セマンティックレイヤーだ。五十嵐氏はこれを「計算式集」と呼んだ。ビジネスの指標をどう計算するかを、一度だけ定義しておく。たとえば「売上＝金額－値引き」。税込みか税抜きか。いつの日付で計上するのか。AI は問い合わせのたびにここを通るので、ダッシュボードと同じ数字を返す。先の例で言えば、ダッシュボードが0.98億円なら、AI も0.98億円と答える。この点を、五十嵐氏は「決定論的に」SQL を生成すると表現した。同じ問いには、いつも同じ結果が返る、という意味だ。

場所を知る × 計算を知る

2つを組み合わせると、こうなる。「先月の関西の売上は？」と聞かれたエージェントは、まずカタログに聞きに行く。次にセマンティックレイヤーが、どの式で、どの表をつなぎ、どの単位で集計するかを示す。こうして返ってくるのは、根拠付きの正しい数字だ。

カタログがなければ、AI は「間違った場所」を見る。セマンティックがなければ、「間違った計算」をする。

場所を知る × 計算を知る

このチャートは、とても大事だ。AI の答えが間違うとき、原因は「場所」か「計算」のどちらかにある。そう切り分けられるだけで、対策の打ち方が見えてくる。

ただ、ここで一つ疑問がある。知り合いのエンジニアに聞くと、こうした設計は DDD（ドメイン駆動設計）の領域で難しく、ノンエンジニアには学べないという。本当にそうだろうか。DDD はもともと、エンジニアが業務の専門家と一緒に、共通の言葉を作るところから始まる考え方だ。「顧客とは何か」「売上はいつ計上するのか」を一番よく知っているのは、業務の側である。モデルを書き起こすのはエンジニアでも、何を書くかを決めるのはノンエンジニアの仕事だ。むしろ業務を知る人こそ、オントロジーとセマンティックの考え方を学ぶべきだと思う。

検証：SOAP はエージェントを賢くするのか

では、実際に効果はあるのか。Google Cloud は社内で検証した。条件の違う2つのエージェントを用意し、同じ仕事をさせて比べる。

• A：LLM ＋ SOAP。表や列の説明といった従来の情報に加えて、SOAP で詳しい背景と集計の仕様を渡す
• B：LLM のみ（SOAP なし）。渡すのは、従来の表や列の説明だけ

題材は、EC サイトを模した公開データ「theLook eCommerce」。5つのタスクを、それぞれ20回ずつ実行した（2026年9月の社内検証）。

この検証は、とても面白い。同じモデルで、渡す文脈だけを変えている。

デモ：成功率は0％と100％

デモでは、SOAP なしと SOAP ありのエージェントを同時に走らせた。使ったモデルは、軽量版の「gemini-3.1-flash-lite」だ。問いは、経理部が定めた「2024年度 EC 決算・収益認識および返品コスト控除ルール」に従うものだ。主要5か国の監査調整後の純売上高、純営業利益、純営業利益率を、国別に出す。SOAP なしの側が使えるのは、表と列の説明だけ。SOAP ありの側は、Knowledge Catalog に加え、Google ドキュメントの規定書まで参照できる。

結果は一目瞭然だった。SOAP ありのエージェントは、Knowledge Catalog から売上と財務規定に関わる情報を絞り込んで取り出し、SQL を1回実行しただけで答えを出した。かかった時間は7.51秒だった。正しい数値6つとすべて一致し、成功率は100％だった。

SOAP なしのエージェントは、データの構造を調べるために何度も問い合わせを重ね、遠回りをした。SQL の実行は8回に及び、30秒を超えていた。しかも、出した答えは6つの数値すべてが誤りで、成功率は0％。経理部のルールを知らないまま、完了と出荷済みの注文をそのまま足し上げてしまったからだ。

全体の結果：精度は平均29％から95％へ

5つのタスクを20回ずつ回した、全体の結果も示された。

• 正しく答えられた割合（精度）：SOAP ありは平均95.0％、SOAP なしは平均29.0％
• 使ったトークン（AI が処理する文字の量で、利用料の元になる）と、問い合わせ1,000件あたりのコスト：SOAP ありは、なしの3分の1から6分の1
• 答えが返るまでの時間：SOAP ありは、なしの5分の1から7分の1

SOAP による文脈の供給で、精度、コスト、速度のすべてが大きく改善した

五十嵐氏によれば、高性能なモデルで比べても、SOAP ありの方が精度は上がり、SOAP なしではトークンの消費が大きくなるという。もっとも、これは Google 自身の社内検証で、題材も公開データだ。自社のデータでどこまで再現できるかは、それぞれ確かめる必要がある。

文脈は、使うほど賢くなる

ここで話は、「なぜ Google Cloud か」に移った。データ、計算、文脈の3つで「Google ならでは」の理由を説明した。正直に言えば、この後半はやや製品紹介の色が濃かった。

このうち文脈について、スライドは「文脈は、使うほど自己学習し、賢くなる」と掲げた。用語集やカタログは、作った瞬間から古くなる。人の手では維持しきれず、AI の接地がだんだん弱くなる。そこで Knowledge Catalog を、作って終わりの目録ではなく、常に動き続ける「文脈のエンジン」にした。エージェントの問い合わせ履歴や、表が実際にどうつながれて使われているかから、関係を自動で学び、Gemini が説明文を書く。スライドによれば、データのエラーとハルシネーションは60％減った。

文脈層は「使うほど自己学習し、賢くなる」

ただし、ここは一歩引いて読みたい。AI が学べるのは、データが実際にどう使われているかだろう。「売上は税込みで数えるべきか、税抜きで数えるべきか」といった、どうあるべきかの判断までは学べないと思う。使われ方そのものが間違っていれば、間違いも学んでしまうおそれがある。自己学習は、業務を知る人の仕事を消すのではなく、「書く」から「確かめて承認する」へ変えるのだろう。

デモ：借換ローンを、分析から成果まで

最後のデモは、架空の「さくら未来銀行」が舞台だ（データはすべて合成）。高金利のカードローンを使っている顧客に、低金利の借換ローンを勧めるキャンペーンを、分析から成果の確認まで、ひとつなぎで回してみせた。

最初の依頼は、わざと雑にした。「高金利のカード残高を、新しい低金利の借換フリーローンに乗り換えると得する顧客を探して」。どの表を使うかも、何をもって「高金利」とするかも指定していない。それでも Gemini は、Knowledge Catalog にある定義や根拠を確かめながら、迷わずに分析を進める。対象を6万5,458人と割り出した。

正直に言えば、このデモに「わあ」と驚く場面は少なかった。ただ、それこそが狙いなのだろう。このデモの価値は、何かが起きることではなく、何も起きないことにある。雑な依頼でも、AI が表を取り違えず、定義を勝手に作らず、毎回同じ正しい数字を返す。先の検証デモが SOAP なしとありで、0％と100％という劇的な差を見せたのに対し、こちらは「あり」の側だけを見せている。だから地味に映る。AI は確率で答える道具だ。同じ問いでも、聞くたびに答えが揺れうる。揺れてはいけない数字を扱う仕組みは、地味であるほど正しいのかもしれない。

取材を終えて

正直に言えば、複数のクラウドをまたいでデータをつなぐ話は、いくつもの事業を抱える大企業のものに聞こえた。だが、このセッションの本質はそこではないと思う。

「売上」の数え方が部署で違う。どの数字が正しいかは、担当者に聞かないと分からない。大事な規定は PDF の中に眠っている。これは社員が数十人の会社にもある光景だ。むしろ中小企業ほど、定義はシステムではなく、社長やベテラン社員の頭の中にある。

ノンエンジニアの筆者にとって、このセッションは技術の話に見えて、実は業務の話だった。AI が数字を間違える原因は、モデルの賢さではない。「売上とは何か」「顧客とは誰か」「どの表が正しいのか」が、組織の中で決まっていないことにある。デモで SOAP なしのエージェントが0％だったのは、計算が下手だったからではなく、経理部のルールを知らなかったからだ。

部署ごとに「売上」の数え方が違うのには、たいてい理由がある。それぞれの目標や評価が、その数え方と結び付いているからだ。言葉を揃えることは、評価の物差しを揃えることでもあり、IT 部門だけでは決められない。最後に裁定するのは経営である。

ノンエンジニアが明日からできること

全社のデータ基盤から始める必要はない。身近なところからできることを、筆者なりにまとめておく。

• 部署ごとに数字が食い違う会議や報告を、1つだけ選んで、そこから始める
• 自部署でよく使う言葉（売上、顧客、解約など）の定義を書き出し、ほかの部署とすり合わせる
• 主な指標の計算ルール（いつ計上するか、何を含めるか）を文章にする
• そのデータを誰が見てよいか、定義を誰が決め、変わったとき誰が直すのかを決める

モデルは次々と入れ替わる。会社に残るのは、こうした定義とルールと判断の積み重ねだ。エンジニアに任せきりにせず、業務を知る人と経営が、その主役になるべきだ。

開催概要

出典：Agentic AI Summit '26 Fall 公式ページ