株式会社エブリーの技術ブログ

全450件

2026/07/10

こんにちは。開発1部の村上です。本記事は AIブログリレー 8本目です。エブリーではAIエージェントを社内のあらゆる業務で活用していくことを目指しています。そのAIエージェントたちを支えるのがデータ基盤です。そしてこの基盤を、AIにデータを「読ませる」ためのものから、AIエージェントを「動かす」ためのものへ進化させていきたいと考えています。本記事では、そのために必要なステップを整理します。人のための基盤から、AIエージェントを "動かす" 基盤へこれまでのデータ基盤は、暗黙のうちに「人が使う」前提で設計されてきました。ダッシュボードを見るのも、SQLを書くのも人です。「この売上には手数料が含まれているんだっけ？」という定義の曖昧さも、人が文脈と経験で補完してきました。利用者がAIエージェントに変わると、この暗黙の補完が効かなくなります。さらにエージェントが増えていくことを前提に立つと、基盤は特定の誰かの道具ではなく、すべてのエージェントが立つ共通の足場になります。足場が曖昧なままエージェントを増やすと、曖昧さの解釈がエージェントの数だけ生まれてしまいます。さらにAIエージェント時代のデータ基盤は、データを参照して質問に答えるといった、データを「読める」ようにするだけでは不十分だと考えています。データにもとづいて業務の中で行動するエージェントを支える、つまりAIエージェントを「動かす」ところまでを、基盤の責務として考えていく必要があります。このような基盤には、次の3つのステップがあると考えています。参照できる : あらゆるデータを収集し、AIが参照可能な状態にする（メダリオンアーキテクチャ）解釈を間違えない : 指標や用語の意味を一元定義する（セマンティックレイヤー）行動できる : 業務のオブジェクト・関係・アクションを機械可読にする（オントロジー）順に見ていきます。あらゆるデータを集め、AIが参照できる状態にする最初のステップは、構造化・非構造化を問わずデータを収集し、AIが参照できる状態にすることです。ここで採用しているのがメダリオンアーキテクチャです。メダリオンアーキテクチャは、データをBronze（生データ）、Silver（クレンジング・整形済み）、Gold（ビジネス利用可能）という層に分けて、段階的に品質を昇格させていく設計です。（出典: What is a Medallion Architecture? | Databricks ）ポイントは「きれいなデータを一発で作る」のではなく、生データを捨てずに保持したまま、信頼できる状態へ段階的に到達させることにあります。AIエージェント時代には、この層の分離がもう一つの意味を持ちます。エージェントにどの層を見せるかを制御できることです。品質保証されたGold層だけをエージェントの参照先にすることで、生データの揺らぎに引きずられた回答を構造的に防げます。このステップまで整うと、Text to SQLが動き始めます。「先月のチャネル別売上は？」と聞けばエージェントがSQLを書いて答えてくれる。人が結果を確かめながら使う形であれば、AI活用はここから十分始められます。ただし、「参照できる」と「正しく解釈できる」の間には溝があります。テーブルとカラムが見えることと、その数字が何を意味するかを理解していることは、別の問題だからです。 AIが解釈を間違えない状態にする 2つ目のステップは、セマンティックレイヤーの整備です。指標の定義、ディメンション、シノニム、用語といったビジネス上の意味を、BIツールやエージェントの側ではなくデータ層で一元的に定義します。たとえばCAC（顧客獲得コスト）の定義がエージェント間で曖昧だったとします。すると、事業KPI分析エージェントとマーケティングエージェントが異なる計算式のCACを見て動いてしまう、といったことが起こります。しかもどちらのSQLも正しいため、この食い違いに気づくのは困難です。 Goldに計算済みのCACテーブルを置く手もありますが、CACのような比率指標は計算済みの値を再集計できません。「全チャネル合算では?」と粒度の違う質問が来た瞬間、エージェントはCACの平均を取って間違えます。だから必要なのは計算結果ではなく、計算式の定義です。セマンティックレイヤーは、この定義をデータ層で管理します。Databricksの実装で言えば Unity Catalog Business Semantics がこれにあたります。中核となるmetric viewは、測度（CACの計算式そのもの）と、それを集計するディメンションを分離して定義する仕組みで、SQL・ダッシュボード・エージェントのどこから利用しても、同じ定義から同じ計算が決定的に実行されます。加えて glossaryやdomains といった用語・文脈を整備する機能の発表も続いており、この領域への投資はプラットフォーム側でも加速しています。効果は数字にも表れています。dbtが2026年に再実施したベンチマークでは、Text to SQL単体の精度は最新モデルで64.5%まで改善した一方、セマンティックレイヤー経由ではカバーされた質問に対してほぼ100%に到達しています。モデルの進化だけでは埋まらない差が、定義の一元化で埋まるということです。ここまで整うと、エージェントは指標を正しく計算し、要因を正しく分解できるようになります。「読む」はほぼ完成です。しかし、分析だけではなく行動まで促そうとすると、まだ決定的に足りないものがあります。 AIが行動できる状態にするオントロジーとは何か 3つ目のステップがオントロジーの構築です。このブログリレーの 1本目でCTOも紹介していましたが、オントロジーとは、業務を構成するオブジェクト（顧客、受注、商品...）、その関係、そしてそれぞれに実行できるアクションを、機械可読な形で定義したものです。もともとオントロジーは知識工学の用語で、古典的にはオブジェクトと関係の記述を指します。エンタープライズの文脈ではPalantirがこれを拡張し、オブジェクト・プロパティ・関係というセマンティックな要素に加えて、アクションという「世界を変更する操作」までをオントロジーに含めています（参考: Palantir Ontology ）。業界の現在地この領域は、まさに製品化が始まったところです。Databricksも2026年6月のData + AI Summitで独自のオントロジーである Genie Ontology を発表しました（現在プレビュー）。テーブル・クエリ・ダッシュボードから事業の文脈を自動抽出して生きたグラフを構築するもので、Unity Catalogで定義したセマンティクスがこのオントロジーに供給される構造になっています。アクション定義までは含まないかもしれませんが、オブジェクトと関係の自動構築という意味で同じ方向に進んでいます。複数のエージェントが、同じ地図の上で動く例として、定期購入型のEC（サブスクEC）でオントロジーの一部を考えてみます。構成要素は次の4つです。オブジェクト : 顧客、定期契約、定期受注（第n回の個別のお届け）、商品、在庫引当、配送関係 : 顧客は定期契約を持つ。定期契約は定期受注を生成する。定期受注は商品を含み、在庫を引き当て、配送に紐づく状態 : 定期受注は「受付中 → 出荷確定 → 発送済み」と遷移する。「お届け日の2日前に出荷確定へ移る」という締切の定義もここに属するアクション : 各オブジェクトに対する操作。前提条件・効果・権限がセットで定義される配送先を変更する（前提: 状態が受付中）メニューを差し替える（前提: 状態が受付中、かつ、おまかせコース）次回分の変更を予約する（対象: 定期契約。いつでも可）このオントロジーの上で、複数のエージェントが動くとどうなるか。同じサブスクECで動くCSエージェントと在庫オペレーションエージェントがいるケースを考えます。ここで見たいのは、互いに無関係な2つの出来事です。ある日、CSエージェントには顧客から「配送先を変えたい」という問い合わせが届きます。一方、在庫オペレーションエージェントの側では、入荷遅延によって木曜出荷分の在庫が不足していました。別々のトリガで、2体はそれぞれ独立に動き出します。それぞれの動きを並べるとこうなります。 CSエージェント在庫オペレーションエージェント起きたこと顧客「配送先を変えたい」入荷遅延で木曜出荷分の在庫が不足関係の辿り方顧客 → 定期契約 → 定期受注商品 → 在庫引当 → 定期受注受付中の受注への行動「配送先を変更する」を実行「メニューを差し替える」で欠品を吸収出荷確定済みの受注への行動「次回分の変更を予約する」に切り替え、「次回分から新しい住所にお届けします」と案内引当済みのため対象外。手を付けないこの2体は、会話もしていなければ、仕事の引き継ぎもしていません。起点も違います。片方は顧客から、もう片方は商品から関係を辿り、同じ定期受注オブジェクトに到達しているだけです。そして2体が共通して参照しているのは、定期受注の「状態」と、その状態を前提条件に持つアクションの定義です。顧客対応と欠品対応という別々の業務が矛盾しないのは、「出荷確定後は変更できない」というルールがアクションの前提条件として基盤に一つだけ存在して、両方がそれを参照しているからです。ルールを各エージェントのプロンプトやMCPツールの説明文に書けば済む、と思うかもしれません。実際、エージェントが1〜2体のうちはそれで動きます。しかしそれは定義のコピーです。10体に定義がコピーされた世界では、ルール変更のたびに10箇所の改修が発生し、直し漏れたエージェントは旧ルールで動き続けます。API側で変更を拒否することはできますが、それで防げるのは誤った実行までで、エージェントは「変更できますよ」と案内してから実行に失敗する可能性もあるかもしれません。オントロジーはこの知識を参照に変えます。エージェントが何体いても、参照先は1つです。この構造の強さは、ルールが変わる日にはっきり現れます。出荷締切を前日から2日前に早める、という業務判断が下りたとします。変更するのは基盤上の定義1箇所。その瞬間から、CSエージェントの案内も、在庫オペレーションエージェントの組み替え範囲も、将来作られる何体目かのエージェントの行動も、すべて同時に新しいルールに従います。 3層の上でエージェントを動かすここまでの3ステップを一度に眺めると、こうなります。ステップ1でデータが見える。ステップ2で数字を正しく読める。ステップ3で「何ができて、実行すると何がどう変わるか」が分かる。ここまではCSと在庫オペレーションの2体で見てきましたが、この土台の上には、マーケティングエージェント、予実管理エージェント、と業務ごとのエージェントを並べていけます。全員が同じ指標定義を読み、同じオブジェクトとアクション定義の上で動く。データ収集だけを進めてエージェントを増やすと、指標・フロー・ルールの定義が各エージェントのプロンプトへサイロ化していきますが、3層が整った基盤の上では、すべてのエージェントが同じ世界を見て行動します。エブリーはどう取り組むかエブリーではステップ1にこれまで投資を続けてきており、メダリオンアーキテクチャによる基盤は整いつつあります。ステップ3のオントロジーは技術的にもまだ新しく、すぐに全面適用できる段階ではありません。そこで今期は、ステップ3を意識しながら、ステップ2のセマンティックレイヤーを整備していきます。このステップ2と3は、アプリケーションのコードと人の暗黙知に散在している世界の定義を、基盤上の宣言的で機械可読な一箇所へ引き上げていく作業です。「CACの計算式」も「出荷確定後は変更できない」という定義も、今この瞬間もアプリケーションの実装の中に、そしてオペレーションを担う人の頭の中に存在しています。そして、ここが重要なのですが、この作業はデータチームが外から観測するだけでは完遂できません。「締切を何時にするか」「CACに何を含めるか」は、データの中に答えがある問題ではなく、ビジネスの意思決定そのものだからです。セマンティックレイヤーもオントロジーも、技術の問題である以前に、ビジネスと一緒に定義を決めにいく組織の問題です。だからこそ、このリレーの 1本目でCTOが書いた、エンジニアが事業の中に入ってその基盤を作っていくという話になるのだと思っています。基盤を育てることと、ビジネスと共に定義を決めること。この両方が揃ったとき、データ基盤はAIにデータを読ませる基盤から、AIエージェントを動かす基盤になります。さいごに本記事では、AIエージェントを「動かす」ためのデータ基盤を、参照できる・解釈を間違えない・行動できる、という3つのステップで整理しました。エブリーではこの基盤づくりをこれから本格化させていきます。進捗や学びは、またこのブログで共有していく予定です。エブリーでは一緒に働く仲間を募集中です！エンジニアブログをきっかけに少しでも興味も持っていただけたら、まずはカジュアルに面談しましょう！

SQL, 人工知能, API, アーキテクチャ, 設計, MCP, 組み込み

株式会社エブリー の技術ブログ

コンテンツ

株式会社エブリーの技術ブログ