SAP AI Core でできること：機能・アーキ・技術詳細の整理

TL;DR

• SAP AI Core の正体: SAP BTP 上で動く Kubernetes ベースの AI / ML 実行基盤で、古典 ML と生成 AI の両方を同じ基盤で運用できるサービスです。
• 実行エンジンは Argo Workflows: ML パイプラインの定義・実行は CNCF 配下の Argo Workflows（Kubernetes 上で DAG 形式のワークフローを実行する OSS）を採用し、YAML テンプレートで宣言的に書きます。
• 生成 AI は Generative AI Hub 経由: 外部 LLM（Azure OpenAI / AWS Bedrock / Google Vertex AI 等）への統一 API、Grounding、Templating、Data Masking、Content Filter を Orchestration Service が単一パイプラインで提供します。
• RAG は HANA Cloud Vector Engine と接続: SAP データを Embedding モデル（テキスト等を数値ベクトルに変換するモデル）でベクトル化し、HANA Cloud Vector Engine に格納して LLM プロンプトに根拠を与える構成が標準です。
• Agent は Joule Studio / Cloud SDK for AI: ロウコード（Joule Studio）とプロコード（SAP Cloud SDK for AI、LangGraph / AG2 / CrewAI 統合）の 2 経路で Agent を構築し、A2A / MCP プロトコルで相互運用します。

要点サマリ表

項目	内容
何の話	SAP AI Core でできること、アーキ全体像、Argo Workflows / Generative AI Hub / RAG / Agent の技術詳細
結論	AI Core は「BTP 上の Kubernetes」+「Argo Workflows による ML 実行」+「Generative AI Hub による LLM 統一 API」の 3 層構造として理解するとブレない
影響範囲	SAP CoE / BTP 開発チーム / 拡張開発（CAP / Joule）/ ML エンジニア（カスタムモデル訓練）
私の評価	標準的なクラウドネイティブ基盤（K8s + Argo）を採用しつつ、SAP データへの Grounding が固有価値。汎用 ML プラットフォームの代替ではなく SAP データ × AI の専用基盤として位置付けるのが現実的

背景・経緯

SAP AI Core は、SAP BTP 上で AI / ML のライフサイクル全体を実行する基盤サービスとして提供されているコンポーネントです。Sapphire 2026 で打ち出された Autonomous Enterprise / Joule Agents の構想を実現する際の、実行レイヤ（Compute / Orchestration / Model Hosting） を担う位置付けと考えられます。

BTP の AI 関連サービスは「AI Foundation」と総称され、その中に AI Core（実行基盤）、AI Launchpad（運用 UI）、Generative AI Hub（生成 AI 統一 API）、Document Information Extraction 等の AI Business Services が含まれます。AI Core はその中で「Compute と Orchestration を提供する縁の下の力持ち」です。

過去 1 年で生成 AI 需要が急増し、AI Core は当初の ML lifecycle 管理サービスから Generative AI Hub を内蔵する形に拡張されました。これにより、Azure OpenAI や AWS Bedrock 等の外部 LLM を SAP 環境から 統一 API で利用できる ようになっています。

AI Core は Hyperscaler 中立を掲げており、内部実行基盤として AWS / Azure / GCP 上の Kubernetes クラスタを利用しますが、利用者から見れば「BTP の 1 サービス」として抽象化されています。Argo Workflows をベースとした設計のため、外部の OSS ML スタックとの相互運用も想定されています。

本題の詳細

主要用語の定義（曖昧さの解消）

「LLM」「AI モデル」「Agent」のような用語は文脈次第で大きく意味が変わるため、本記事で使う定義をここで固定します。以降の章では太字キーワードが初出した時点で都度参照できるよう、12 用語を一覧化しました。

AI Core でできること（機能リスト）

AI Core が提供する機能を、扱う AI モデルの種類別に整理すると次の通りです。

• ML lifecycle 管理（古典 ML / カスタム LLM）: データ準備、訓練、評価、デプロイ、推論、監視までの一連を Argo Workflows ベースで管理します。カスタム LLM の自前訓練 もここに含まれます。
• Generative AI Hub（汎用 LLM への統一 API）: Azure OpenAI / AWS Bedrock / Google Vertex AI 等の 外部プロバイダ LLM、および SAP-built モデル（Embedding 含む）への呼出しを単一 API で抽象化します。
• Grounding / RAG（Embedding + Vector Store）: SAP HANA Cloud Vector Engine と組み合わせ、SAP データを参照源として LLM 回答に根拠を与えます。
• Orchestration Service（パイプライン制御）: Templating、Data Masking、Content Filter、Grounding を 単一のリクエストで連結できる制御層を提供します。
• AI Agent 実行（Joule Agents / BYOA）: Joule Studio で構築したロウコード Agent、または SAP Cloud SDK for AI で実装したプロコード Agent を実行・登録します。
• 多テナント / Hyperscaler 中立: AWS / Azure / GCP の Kubernetes 上で動くマルチテナント基盤で、利用者は Hyperscaler 選定の詳細を意識せずに利用できます。

アーキテクチャ全体像

AI Core のアーキテクチャは、上位の BTP サービス層 から下位の Hyperscaler Kubernetes 実行層 までが多段に積まれる構造です。Reference Architecture の図解からは、CAP アプリケーションが入口となり、Generative AI Hub の Orchestration Service が外部 LLM と HANA Cloud Vector Engine を統合的に呼び出すフローが標準として示されています。

flowchart TB
CAP["CAP App / BTP Application"]
AICore["SAP AI Core (BTP Service)"]
GAIHub["Generative AI Hub<br/>(Orchestration / Grounding / Templating)"]
AILaunch["AI Launchpad (UI)"]
HANA["HANA Cloud Vector Engine"]
K8s["Hyperscaler Kubernetes<br/>(AWS / Azure / GCP)"]
Argo["Argo Workflows (DAG 実行)"]
ExtLLM["External LLM<br/>(Azure OpenAI / Bedrock / Vertex AI)"]
CAP -->|REST / SDK| GAIHub
AILaunch -.-> AICore
GAIHub --> AICore
AICore --> K8s
K8s --> Argo
GAIHub -->|統一 API| ExtLLM
GAIHub -->|Grounding / RAG| HANA

中央の Generative AI Hub が「Harmonized API」を提供し、利用者は LLM プロバイダの違いを意識せずに済む点が特徴と考えられます。下層の Kubernetes / Argo Workflows は ML Pipeline 実行や Agent ホスティングを担当します。

ML Pipeline Workflow（技術詳細）

ML Pipeline Workflow は AI Core の中核機能で、Argo Workflows をベースに ML 学習・推論パイプラインを宣言的に定義 します。ここでの「モデル」は主に古典 ML（決定木 / XGBoost 等）、または自前訓練するカスタム LLM を想定します。

主要な概念は次の 3 つです。

• Scenario: ユースケース単位の論理的なまとまり（例: 「顧客解約予測」）。複数の Executable を持ちます。
• Executable: Argo Workflows の WorkflowTemplate に相当する YAML 定義 で、実行するコンテナ・入力・出力・パラメータを記述します。
• Configuration: Executable に具体的なパラメータ値・データソースを束ねた実行設定で、これを Execution として起動します。

Kubeflow Pipelines との比較では、Argo Workflows の YAML が共通基盤 なので、SDK 層を差し替えれば移植可能と公式コミュニティが説明している点が技術的に重要です（取得失敗ソースだが計画段階の事実確認に基づく）。

flowchart LR
S["Scenario<br/>(顧客解約予測)"] --> E["Executable<br/>(Argo WorkflowTemplate YAML)"]
E --> C["Configuration<br/>(パラメータ + データソース)"]
C --> X["Execution<br/>(Argo Workflow 実行)"]
X --> M["Model Artifact<br/>(Object Storage)"]
M --> D["Deployment<br/>(推論エンドポイント)"]

WorkflowTemplate の中身は Kubernetes Pod の定義で、コンテナ image、リソース要求（CPU / GPU）、入出力 artifact（S3 / Azure Blob 等）、依存関係（DAG）を記述します。AI Core SDK（Python）から Scenario / Executable / Configuration / Deployment を REST API 経由で操作できます。

Generative AI Hub（技術詳細）

Generative AI Hub は AI Core 内の 生成 AI 専用機能群 で、外部 LLM プロバイダへの統一アクセスと、関連する付帯機能（Grounding / Templating / Data Masking / Content Filter）を Orchestration Service として統合提供します。ここでの「モデル」は外部プロバイダ提供の汎用 LLM、および SAP-built の Embedding モデルが中心です。

公式 Reference Architecture の表現を借りれば、Orchestration は次のような 1 リクエストで複数機能を連結できる構造です。

The Orchestration module combines content generation via a Harmonized API with essential functions: Grounding, Templating, Data Masking, Content Filtering.

（Orchestration モジュールは Harmonized API による生成と、Grounding・Templating・Data Masking・Content Filtering を統合する、という旨です）

RAG の典型構成は次の流れです。SAP HANA Cloud の Vector Engine が Embedding ベクトルの索引・検索 を提供し、LLM プロンプトに retrieval 結果が注入されます。

二次情報 SAP Generative AI Hub: RAG on SAP Data with HANA Cloud Vector Store (Part 4 of 6)

1. SAP データ（製品マスタ / ナレッジ等）を Embedding モデルでベクトル化し、HANA Cloud Vector Engine に格納
2. ユーザー質問を同じ Embedding モデルでベクトル化
3. Vector Engine で類似度検索（コサイン類似度等）し、関連文書 Top-K を取得
4. Orchestration Service に「質問 + retrieval 結果 + system prompt テンプレート」を渡す
5. Templating が完成プロンプトを組立て、Content Filter が NG ワード等を除外
6. 外部 LLM（Azure OpenAI 等）に Harmonized API 経由で送信
7. 応答をデータマスキング適用後、CAP アプリケーションに返却

Knowledge Graph Engine との連携も Reference Architecture に明記されており、Triplestore / RDF / SPARQL を使った構造化知識の利用も可能と説明されています。Vector による意味検索と Graph による関係推論を組み合わせるパターンが想定されています。

Agentic AI 実装パターン

AI Agent は LLM 単体ではなく、Tool Use（Function Calling）+ 状態管理 + 多段推論を組み合わせた仕組みです。SAP BTP では Golden Path 公式ドキュメントが 2 つの実装経路を提示しています。

**ロウコード経路（Joule Studio）**は、Visual development で Agent instruction を定義し、Tool（SAP Build Process Automation / REST / OData API 等）を構成、ワークフローを GUI でオーケストレートします。AI Core が自動実行管理し、Joule に即時登録されるため、ビジネスアナリスト寄りの利用者が想定対象です。

**プロコード経路（SAP Cloud SDK for AI）**は、LangGraph / AG2 / CrewAI 等の 既存 Agent フレームワーク との統合を前提とした実装です。CAP との組み合わせでエンタープライズ要件（認証 / 監査 / 拡張性）に応えやすい点が訴求されています。両経路とも Generative AI Hub の Orchestration Service を呼び出します。

公式 Golden Path には次の説明もあります。

Multi-step reasoning: Configuration-driven orchestration with planning, RAG and tool chaining.

（多段推論は planning・RAG・tool chaining を構成駆動で組み立てる、という旨です）

A2A プロトコル（Agent-to-Agent）と MCP（Model Context Protocol）が相互運用基盤として位置付けられており、外部 Agent と SAP Agent の双方向呼出しが想定されています。Joule Agents との連携では、プロコード Agent は BYOA（Bring Your Own Agent）パターンで A2A エンドポイント経由 Joule に登録できます。

比較・代替手法

AI Core を主要な競合 ML / AI プラットフォームと比較すると、SAP データ連携の深さと LLM 統一 API（Harmonized API） が固有の差別化軸として浮かびます。

表: SAP AI Core と他 4 ベンダーの比較。SAP 以外の記述は各社一般公開情報からの整理であり、SAP との位置付けを概況把握するための比較表です。実際の選定時は各社の公式仕様・料金・統合範囲を個別に確認してください。

ベンダー	SAP データ連携	多 LLM 統一 API	k8s ベース	料金モデル	SAP ロックイン	主たる差別化
SAP AI Core	○ 深い（HANA / BTP 統合）	○ あり（Orchestration）	○ あり（Argo）	△ BTP 従量	△ 中（Argo OSS で逃げ道）	SAP データ × Generative AI の統合
Azure Machine Learning	× 浅い（要連携実装）	△ 同社 LLM 中心	○ AKS 連携可	従量 + 予約	○ 低	Azure OpenAI とのネイティブ統合
AWS SageMaker	× 浅い（要連携実装）	△ Bedrock 経由	○ EKS 連携可	従量	○ 低	AWS 全サービスとの統合・スケール
Google Vertex AI	× 浅い（要連携実装）	△ 同社 LLM 中心	○ GKE 連携可	従量	○ 低	Gemini ファミリと AutoML
Red Hat OpenShift AI	× 浅い（要連携実装）	× なし（ユーザー実装）	○ あり（OpenShift）	サブスク	○ 低	オンプレ / マルチクラウド統一基盤

SAP AI Core の差別化は「SAP データへの Grounding」と「Harmonized API で外部 LLM を吸収」の 2 点に集約されます。一方で純粋な ML 訓練性能・GPU スケール・MLOps 機能の豊富さでは、Hyperscaler のフラッグシップ ML サービスに正面から競合できる位置にはないと考えられます。

私の考察

私は SAP CoE 業務観点で AI Core を評価するとき、「BTP 外の汎用 ML プラットフォームの代替」ではなく「SAP データ × AI の専用基盤」として位置付ける のが現実解だと考えています。理由は 3 つあります。

第一に、SAP データへの Grounding が AI Core 固有の価値だからです。HANA Cloud Vector Engine と Generative AI Hub の Orchestration がネイティブに繋がっており、SAP のマスタ / トランザクションを参照源とした RAG を最短経路で組めます。他クラウドの ML プラットフォームから SAP データを参照するなら、Integration Suite 経由で別途データパイプラインを敷く必要があり、運用負荷が増えます。

第二に、Argo Workflows ベースであることが「ロックインへの逃げ道」を残している点です。AI Core の WorkflowTemplate は CNCF 標準の Argo YAML なので、最悪のケースでも別の K8s 環境に持ち出しやすい構造です。一方で Generative AI Hub の Orchestration Service は SAP 固有の Harmonized API なので、Agent / RAG 実装をここに寄せすぎると移行コストは上がります。私の判断軸では「訓練 / 実行は Argo に寄せ、Orchestration の固有 API 依存は最小限に」とすると、将来の選択肢を確保しやすいと感じます。

第三に、汎用 ML プラットフォームとの並存判断です。研究開発・大規模 GPU 訓練・最新の Foundation Model 試験的利用は Hyperscaler 純正（SageMaker / Vertex AI 等）に分離し、AI Core は SAP 業務データを使った生成 AI 機能の本番運用に絞る、という分担が現時点では合理的と考えています。Sapphire 2026 後の Joule Agents 展開が進むほど、AI Core の存在価値は「Joule の実行基盤」として強化されていくと予想されます。

参考リンク

• What Is SAP AI Core?
• Generative AI on SAP BTP (Reference Architecture)
• Build AI Agents on SAP BTP (Golden Path)
• SAP AI Core is All You Need | Workflow, Configuration, and Shakespeare Language Model Training
• Transform Kubeflow Pipelines into Argo Workflows for SAP AI Core
• SAP Generative AI Hub: RAG on SAP Data with HANA Cloud Vector Store (Part 4 of 6)
• Building an Agentic AI System with SAP Generative AI Hub
• SAP-samples/ai-core-samples