はじめに：現場の業務判断を迷わせる「ビジネス向け生成AI」

生成AIの登場以降、大規模言語モデル（LLM）は目覚ましい進化を遂げ、自然な文章を生成できるようになりました。現在では、思考整理の壁打ちやドキュメント作成など、業務の一部を効率化するツールとして定着しています。さらに近年では、複雑なタスクを自律的に遂行する「AIエージェント」の実装も進んでいます。

しかし、多くの企業が生成AIを個人の業務効率化から、全社の業務プロセスを担う「エンタープライズAI」へとスケールアップさせようとした際、共通の「高い実装の壁」に直面します。それは、どれほど優れた言語処理能力を持つモデルであっても、「自社の業務の文脈（コンテキスト）」を理解していなければ、実際のビジネスプロセスを任せられないという現実です。

一般的な生成AI（LLM）は、分かりやすい言葉でそれらしい回答を組み立てることは得意です。しかし、企業の現場で求められるのは、単なる文章の確からしさではなく、以下のような「厳密なファクトと組織固有のルール」に即した判断です。

• 「この発注先は、社内の特命購買の規程に合致しているか？」
• 「現在の在庫状況や直近の取引実績から見て、この納期と価格は妥当か？」
• 「この申請は、組織の職位や資本関係上、誰の承認ルートを通すべきか？」

従来の生成AI導入では、回答の精度を高めるためにマニュアルやFAQなどの社内文書をベクトル化して検索させる「RAG（検索拡張生成）」が広く使われてきました。しかし、文書を部分一致で引き当てるだけの検索では、刻一刻と変動する取引実績値などの数値データや、複雑に絡み合う組織・取引先の関係性までは捉えきれません。

生成AIを本番の業務プロセスに組み込み、真のエンタープライズAIとして価値を発揮させるためには、AIを社内の事実とルールに正しく接地（グラウンディング）させる「コンテキストに基づく推論（Contextual Reasoning）」が不可欠です。

本稿では、エンタープライズAIが業務判断を下すために必要な「3つのデータモデル」を整理し、それらを統合するデータアーキテクチャについて解説します。

コンテキスト推論を支える「3つのデータモデル」

エンタープライズAIが現場の業務コンテキストを正しく理解し、適切な業務判断やアクションを下すためには、性質の異なる「3つのデータモデル」を組み合わせる必要があります。

1. ベクトル（非構造化データ）：意味と意図の理解

社内規程、業務マニュアル、過去の提案書、契約書といった「文章」を数値化（埋め込み：Embedding）したデータです。
キーワードの完全一致だけでなく、「文脈や意味の近さ」で類似度検索できるため、生成AIに対して以下のような判断材料を提供します。

• 「特命購買が認められる例外条件は何か」
• 「過去の類似プロジェクトでは、どのようなスコープ定義を行っていたか」

主に自然言語で書かれたポリシーや業務ナレッジを参照する際に機能します。

2. ナレッジグラフ／プロパティグラフ（ネットワークデータ）：関係性とルールの把握

組織階層、承認ルート、取引先の系列関係、サプライチェーン、製品構成（BOM）といった「要素同士のつながり（リレーションシップ）」を表現するデータです。
表形式や単純な文書検索では把握しづらい、複雑なネットワーク構造を探索するために用います。

• 「この申請は、部門の決裁権限規程に照らして誰の承認が必要か」
• 「この取引先は、親会社やグループ企業を含めるとどのような資本関係にあるか」

エンタープライズAIが業務プロセスを進めるうえで、「関係性や手続きの妥当性」を担保する役割を果たします。

3. リレーショナル（構造化データ）：確定したファクトデータ

基幹システム（ERP）などに格納されている、売上実績、受発注残、在庫数、最新単価、勘定科目といった「厳密な数値／コード」です。
あいまいさを一切排除した、現在進行形の確定事実（ファクト）を提供します。

• 「直近3ヶ月における対象品目の平均購入単価はいくらか」
• 「現在、倉庫に引き当て可能な実在庫がいくつ残っているか」

エンタープライズAIが下す判断の根拠となる「定量的・客観的な裏付け」を担います。

なぜこの3つのデータモデルを統合しなければならないのか

なぜ「ベクトル（非構造化データ）」「ナレッジグラフ／プロパティグラフ（ネットワークデータ）」「リレーショナル（構造化データ）」という3つの異なるデータモデルが必要なのか。その理由は、エンタープライズAIが業務判断を下す現場の意思決定が、「どれか1つのデータモデルだけでは決して成立しない構造」になっているからです。

単一モデルでは業務判断が完結しない

従来の生成AI活用や単一のアプローチでは、それぞれ以下のような限界に突き当たります。

• ・ベクトル検索（文書RAG）だけの場合
  購買規程やマニュアルなどの「ルール」は引けます。しかし、「現在の在庫数」や「今期の取引累計額」といった基幹システムの確定数値は参照できず、さらに「誰の承認印が必要か」という組織構造も追えません。結果として、一般論のアドバイスにとどまり、具体的な発注判断は下せません。

• ・リレーショナル（RDB・ERPデータ）だけの場合
  最新の在庫数や過去の発注単価といった「数値のファクト」は正確に把握できます。しかし、なぜその価格で合意したのかという「契約書の特記事項」や、例外処理を認める「社内規程の文脈」を読み解くことはできません。

• ・ナレッジグラフ（関係性データ）だけの場合
  サプライヤーの系列関係や、組織の決裁ルートといった「つながり」は正確に探索できます。しかし、その取引における具体的な金額データや、添付された見積書の詳細テキストまでは保持していません。

このように、現実のビジネス判断とは「規程（ベクトル）を理解し、数値（リレーショナル）を確認した上で、組織・取引関係（グラフ）に沿って処理を進める」という、3つのモデルの連携によって初めて成り立っています。どれか1つでも欠ければ、業務を任せることはできません。

「分散データベース」が招くデータエンジニアリングの崩壊

この3つのモデルを連携させようとした際、従来のシステム設計で陥りがちな罠が「データモデルごとに別々の専用データベースを用意すること」です。

• ・文書検索用に「ベクトルデータベース」を立てる
• ・組織や関係性分析用に「グラフデータベース」を立てる
• ・トランザクション処理用に「リレーショナルデータベース」を使う

このように専用DBを乱立させ、それぞれに基幹システムからデータを抽出・複製（ETL）して連携させる構成をとると、データエンジニアリングの現場では深刻な課題が発生します。

1. データの鮮度低下とレイテンシの悪化
   基幹データが更新されても、別DBへのバッチ転送やインデックス再構築にタイムラグが生じ、AIが「古い在庫数」や「過去の承認ルート」をもとに誤った判断を下すリスクが生じます。
2. ガバナンスとセキュリティの崩壊
   ERP側で厳密に設定されていた「閲覧権限」や「行レベルセキュリティ」が、外部のベクトルDB等へコピーされた瞬間に失われ、機密情報の漏洩リスクが高まります。また、AIの回答根拠を追うためのデータリネージ（系統）追跡も極めて困難になります。
3. 二重管理による運用コストの増大
   データパイプラインが増え続けることでシステムの保守負荷が跳ね上がり、PoC段階では動いても本番運用に耐えられなくなります。

つまり、エンタープライズAIの実装で真に求められているのは、単に3つのコンテキストを用意することではありません。これら異なる特性を持つデータを、「同一のデータ基盤上で、データの移動や無駄な複製を行わずに、瞬時に横断照会できるアーキテクチャ」を確立することなのです。

SAP HANA Cloudが実現する「マルチモデル統合アーキテクチャ」

前章で整理した「3つのデータモデルを、データの移動や複製を行わずに単一基盤で扱う」という難題に対し、極めて強力な回答となるのがSAP HANA Cloudです。

SAP HANA Cloudは、単なる高速なインメモリ・リレーショナルデータベース（RDB）ではありません。ひとつのデータベースエンジンの中に、高度な分析を可能にする複数のデータ処理エンジンを内包した「マルチモデル・データベース」です。

1. 単一基盤に統合された3つのエンジン

SAP HANA Cloudは、エンタープライズAIのコンテキスト推論に必要な3つの機能をすべて同一環境内で提供します。

1. ベクトルエンジン（Vector Engine）
   社内文書やマニュアルの埋め込み（Embedding）ベクトルをテーブルの列として直接保持し、コサイン類似度などの高速な類似検索を実行します。

2. グラフエンジン（Graph Engine）
   組織階層、承認ルート、サプライチェーンなどのネットワーク構造をプロパティグラフやナレッジグラフとして格納し、ノード間の最短経路や到達可能性をインメモリで高速探索します。

3. リレーショナルエンジン（Relational Engine）
   SAP HANAが誇るカラム型インメモリ処理により、基幹業務の膨大な受発注や在庫トランザクションをリアルタイムに集計・検索します。

2. 最大の強み：「In-place（データが存在するその場）」での処理

SAP HANA Cloudを採用する決定的な価値は、これら3つの異なるモデルを「まったく同じデータベースインスタンス内（In-place）」で同時にクエリできる点にあります。

外部の専用ベクトルDBやグラフDBにデータを同期・転送する必要はありません。
たとえばSQLの1つのクエリの中で、「ベクトル検索で抽出した関連マニュアル」と「トランザクションテーブルの最新在庫データ」、さらに「グラフエンジンによる承認ルート」をJOIN（結合）して処理することが可能です。

これにより、以下の実務的メリットがもたらされます。

1. データ鮮度の担保（ゼロETL）
   基幹データが更新された瞬間、AIはその最新の数値を参照できます。バッチ転送の遅延による判断ミスが起きません。
2. エンタープライズレベルのセキュリティ継承
   SAP HANA Cloudが備える堅牢なユーザー権限、ロール制御、データマスキングがそのまま適用されるため、AIが権限外のデータを取得する事故を根本から防ぎます。
3. データリネージ（系統）と監査性の維持
   どの元データレコードを根拠にAIが判断を下したのか、データベースのトランザクションレベルで追跡・説明が可能です。

3. 【業務シナリオ】自律型調達エージェントの処理フロー

このマルチモデル処理が、実際の業務現場でどのように機能するのか。「購買・調達業務を支援するAIエージェント」を例に見てみましょう。

1. 【ベクトル検索】
   ユーザーからの「サプライヤーX社への追加発注を進めたい」という要求に対し、ベクトルエンジンが社内の「購買ガイドライン」や「契約書特記事項」を検索し、特命購買の適用条件を抽出する。
2. 【リレーショナル照会】
   同時に、リレーショナルエンジンが基幹テーブルから「X社の直近3ヶ月の取引実績」「現在の発注残」「最新の単価」をミリ秒単位で照会・検証する。
3. 【グラフ探索】
   さらに、グラフエンジンが組織マスタと承認規程を辿り、今回の発注金額と組織階層に合致する「正式な承認ルート」および「X社のグループ資本関係（リスクチェック）」を割り出す。

これら3つの処理が単一プラットフォーム内で瞬時に行われ、AIエージェントは「社内規程に準拠し、最新数値を反映し、適切な承認ルートを提示した精度の高い発注計画」を自律的に導き出すことができます。

ビジネスデータファブリックとClean Coreにおける位置づけ

前章で解説したSAP HANA Cloudのマルチモデル処理能力を、全社レベルの業務変革へとスケールさせるための鍵が「ビジネスデータファブリック」と「Clean Core（クリーンコア）戦略」です。

どれほど高性能なデータベースであっても、業務コンテキストの「意味定義（セマンティクス）」が抜け落ちていたり、ERPのコアシステムを複雑に改修してしまっては、持続可能なエンタープライズAI運用は成り立ちません。

1. SAP DatasphereとSAP HANA Cloudの役割分担

エンタープライズAIを支えるデータ基盤では、ビジネスセマンティクスを統制するSAP Datasphereと、高性能な物理処理を担うSAP HANA Cloudが協調して動作します。

• ・SAP Datasphere：全社の「ビジネスセマンティクス」と仮想統合を司る
  ERP（S/4HANA）をはじめとするSAPシステムや非SAPシステムのデータに対し、基幹業務特有のコンテキスト（勘定科目の意味、組織マスタの関連性、通貨換算ロジックなど）を損なわずにモデル化します。データを物理的に移動・コピーすることなく仮想統合（フェデレーション）し、全社で一貫した「データプロダクト」としてAIや分析基盤に公開する役割を担います。

• ・SAP HANA Cloud：高性能な「データ永続化」と「マルチモデル演算」を実行する
  AIやデータ集約型ワークロードが求める超高速なインメモリ処理基盤を提供します。Datasphereが定義したビジネスコンテキストを受け継ぎつつ、ベクトル埋め込みの永続化、高速類似検索、グラフ探索、複雑な計算ビューの実行といった重い演算を一手に引き受けます。

この両者が組み合わさることで、AIエージェントは「SAPの業務コンテキストを正確に理解した状態」で、極めて高速な推論とアクションを実行できるようになります。

2. Clean Core戦略を維持するためのデータアーキテクチャ

現在、多くの企業が取り組む「Clean Core（ERPの標準化維持）」においても、このアーキテクチャは決定的な役割を果たします。

AI活用や高度な業務自動化を推進する際、S/4HANAのコア内部にカスタムテーブルや独自のアドオンプログラム（ABAP開発）を乱立させることは、将来のバージョンアップやクラウド移行を阻害する最大の要因となります。

Clean Coreの原則に従い、ERPのコアは標準機能のまま維持しつつ、データ連携と業務ロジックの拡張を外側の「SAP Datasphere × SAP HANA Cloud」層に集約します。さらに、その上に位置するSAP Business AI PlatformやJoule Studioを通じてAIエージェントを構築・展開します。

これにより、基幹システムの標準性と保守性を完全に保ったまま、現場が求める柔軟で高度な自律型AIエージェントをスピーディに稼働させることが可能になります。

おわりに：AIをビジネスで活かす「データアーキテクチャ」の確立へ

生成AIやAIエージェントの進化により、「自律的に判断し業務を遂行するシステム」は現実のものとなりつつあります。しかし、どれほど優れた基盤モデルを採用しても、社内のデータアーキテクチャが整っていなければ、現場の意思決定を委ねることはできません。

本稿で解説したように、エンタープライズAIの成否を分けるのは、モデル単体の言語処理能力ではなく、「ベクトル（非構造化データ）」「グラフ（関係性データ）」「リレーショナル（構造化ファクトデータ）」という3つのデータモデルを、同一基盤上でいかに統合して提供できるかにあります。

専用データベースの乱立によるデータのサイロ化やガバナンスの崩壊を避け、SAP HANA Cloudのマルチモデル処理とSAP Datasphereによるセマンティクス管理を組み合わせる。この「Clean Core」に準拠したデータ基盤こそが、AIをビジネスの文脈に正しく接地（グラウンディング）させ、PoCの壁を越えて実務で価値を創出する確かな道筋となります。

実践に向けた第一歩

エンタープライズAIの実装は、必ずしも全社一括の大規模刷新から始める必要はありません。

まずは、社内規程（非構造化データ）と基幹トランザクション（構造化データ）の両方を参照しなければ判断できない、単一の高付加価値業務（特命購買の判定、予実差異分析、納期リスクの検知など）を特定することをお勧めします。

焦点を絞った具体的な業務でコンテキスト推論の再利用可能なデータモデルを確立し、効果を検証しながら段階的に適用範囲を広げていく。この確実なステップこそが、真のデータドリブン経営を実現し、企業の競争力を高めるエンタープライズAI実装の最短ルートとなるはずです。

グランバレイは、創業以来、SAP導入企業のデータドリブン経営を支援してきました。
近年急速に進化するエンタープライズAIやAIエージェントの領域においても、机上の空論にとどまらないデータエンジニアリングの現場視点とClean Core戦略に基づき、企業独自のコンテキストに沿った高精度なデータ基盤の構想・設計・実装を支援します。