Joule Agent 業務組み込み:3 領域の Custom Agent 設計
SAP Sapphire 2026 で発表された Joule Agent 200+ と新しい Joule Studio を、経理 / 調達 / SCM の 3 業務領域でどう組み込むかを Function Calling とアーキパターンの観点で整理し、標準 Agent と Custom Agent の採用判断軸を CoE 視点で提示します。
TL;DR
- Sapphire 2026 で発表: SAP は Joule Agent を 200 体超 投入し、Joule Assistant 50 体超 を 5 業務領域(Finance / Spend / SCM / HCM / CX)で順次展開すると公表しました。標準 Agent だけで多くのユースケースを覆える状況に変化しています。
- 新しい Joule Studio が登場: Pro-Code 開発者向けに LangGraph / CrewAI / AG2 等の主流フレームワーク + VS Code / Cursor を受け入れる構成へ拡張され、Low-Code(Joule Studio のビジュアル開発)と Pro-Code(SAP Cloud SDK for AI)が併存する Golden Path が示されました。
- 業務組み込みの基本形は 4 層: 「Joule Work(UX) → Joule(Orchestration) → Agent(標準 or Custom) → Function Calling(業務 API)」という 4 層構成が公式 Reference Architecture に明示されています。本記事ではこの 4 層を 3 業務領域に当てはめます。
- 経理 / 調達 / SCM の業務例: 経理は Autonomous Finance 文脈の請求マッチング、調達は Joule Q&A + 承認フロー、SCM は 在庫アラート → 補充提案 → 承認 の Custom Agent シナリオを設計します。SCM 例は私が組んだ仮想シナリオである旨を本文中で明示します。
- 採用判断軸: 標準 Agent を起点に、業務特殊性が高い領域だけ Custom Agent を追加する 二層運用 を推奨します。Function Calling 設計は SAP 標準 API カタログ起点、Pro-Code は CoE 集約、Agent Builder は業務ユーザー降ろし、が私の整理です。
要点サマリ表
| 項目 | 内容 |
|---|---|
| 何の話 | Joule Agent 200+ と新しい Joule Studio を、3 業務領域(経理 / 調達 / SCM)でどう業務組み込みするか |
| 結論 | 標準 Agent を起点に Custom Agent を段階追加し、Function Calling は SAP 標準 API から設計するのが安全 |
| 影響範囲 | SAP CoE / Center of Excellence 全般、特に AI Agent 採用方針と開発体制(Pro-Code / Low-Code 二層運用) |
| 私の評価 | 条件付き採用。標準 Agent は積極導入、Custom Agent は保守コストを織り込んだ ROI 評価が必須 |
背景・経緯
SAP は 2026 年 5 月の Sapphire 2026 で「Autonomous Enterprise(自律型企業)」のスローガンを掲げ、その実装手段として Joule Agent 200 体超 + Joule Assistant 50 体超 を 5 業務領域に投入すると発表しました。直前まで「Joule = Copilot 的な対話 UI」というイメージが強かったところに、業務横断で動く Agent 群 が大量に積まれたことになります。
ここから次の論点は明確に「実際に業務にどう組み込むか」に移ります。標準で 200+ Agent が提供される世界では、CoE / Center of Excellence の関心は「Agent をゼロから作る」よりも「どの標準 Agent を採用し、どこを Custom Agent で埋めるか」の使い分け設計に変わります。本記事はこの観点で 経理 / 調達 / SCM の 3 業務領域 を題材に整理します。
私が本記事を書く動機は、SAP AI スタック 4 部作の最終回として「業務適用視点」を補完することです。Sapphire 2026 視点・BDC データ視点・AI Core 実行レイヤ視点は別記事で扱いましたが、業務組み込みの アーキパターンと判断軸 は別途まとめる価値があると考えました。
ただし読者には 公式実装事例の限界 を先に共有しておきます。Sapphire 2026 のキーノートで紹介されたのは Takeda(最大 10% 生産性向上)/ H&M Group / Aeropuertos Argentina(16% コスト削減)/ Levi Strauss(1,000+ Agent 稼働、受注処理を 2-5 日から 20-30 分に短縮) といった早期顧客事例で、業務領域別の Agent 詳細実装は概ね「coming months」の段階です。本格的な業務組み込み事例は 2026 H2 以降に出てくる と見るのが現実的で、本記事の Custom Agent 設計は 公式 Reference Architecture と私の業務知識の組合せ で構築しています。
本題の詳細
5.0 Joule 周辺用語の定義
Joule まわりは Sapphire 2026 で名称・スコープがアップデートされたため、まず本記事で扱う 8 用語を整理します。
5.1 業務組み込みのアーキパターン(共通)
業務組み込みの基本形は公式 Reference Architecture が定義する 4 層 に集約できます。すなわち (1) Joule Work が UX を提供し、(2) Joule が Orchestration / Routing を担い、(3) Agent(標準 or Custom)が個別タスクをこなし、(4) Function Calling が業務 API を叩く という構造です。Agent の通信プロトコルは A2A(Agent2Agent) と MCP(Model Context Protocol) の組合せで、外部 Agent 連携は A2A、業務能力への意味的アクセスは MCP が担います。
flowchart TB User["業務ユーザー"] JouleWork["Joule Work (UX レイヤ)<br/>会話型 / Spaces / MCP / A2A"] Joule["Joule (Orchestration)<br/>Planning / Routing / Memory"] StdAgent["標準 Joule Agent<br/>200+"] CustomAgent["Custom Joule Agent<br/>Joule Studio で開発"] FC["Function Calling 層<br/>(Tools / APIs)"] S4["S/4HANA<br/>Finance / Logistics"] Ariba["SAP Ariba<br/>Procurement"] SF["SuccessFactors<br/>HCM"] BDC["SAP Business Data Cloud"] AICore["SAP AI Core +<br/>Generative AI Hub"] User --> JouleWork JouleWork --> Joule Joule --> StdAgent Joule --> CustomAgent StdAgent --> FC CustomAgent --> FC FC --> S4 FC --> Ariba FC --> SF FC --> BDC StdAgent -.推論.-> AICore CustomAgent -.推論.-> AICore
この 4 層構造はあらゆる業務組み込みで共通です。Pro-Code(SAP Cloud SDK for AI)と Low-Code(Joule Studio のビジュアル開発)は同じ層を別アプローチで開発する だけであり、Reference Architecture は両者を「相補的なパス」と位置付けています。
Pro-Code は Java / Python / TypeScript のタイプセーフな抽象化を提供し、LangGraph / CrewAI / AG2 / Smolagents といった主流フレームワークを受け入れます。一方の Low-Code はビジュアル開発で エージェント指示・ツール構成・ワークフローのオーケストレーション を組み立て、SAP AI Core 上のマネージドランタイムで実行されます。どちらで作っても Joule への自動登録経路があり、エンドユーザーから見れば違いは見えません。
5.2 業務例 1: 経理 / Cash Application
経理領域では Autonomous Finance のスコープに含まれる 入金消し込み(Cash Application) が代表ユースケースです。入金データ(銀行明細)と債権(売掛金)を AI で突合し、自動で消し込み仕訳を起こす 処理は古くから機械学習で取り組まれてきた領域で、Joule Agent 化することで「例外ケースを会話で詰める」UX が加わります。
本領域の Joule Agent は私が確認できた公式情報の範囲では「Cash Application Agent」という個別命名は明示されていません(Sapphire 2026 のキーノート上では業務領域別の Agent 詳細は概ね「coming months」段階)。ただし 入金消し込みの自動化は SAP S/4HANA Finance の既存ソリューション + Joule の組合せ で実現可能であり、Function Calling 経由で S/4HANA Finance API を呼ぶ構造は公式 Reference Architecture と整合します。
sequenceDiagram autonumber participant U as 経理担当 participant JW as Joule Work participant J as Joule participant A as Cash Application Agent participant S4 as S/4HANA Finance API participant LLM as AI Core / GenAI Hub U->>JW: 「未消込の入金を確認したい」 JW->>J: intent 解析 J->>A: ルーティング A->>S4: 銀行明細 + 売掛残を取得 S4-->>A: データ返却 A->>LLM: マッチング候補生成 (推論) LLM-->>A: 候補 + 信頼度 A->>JW: 候補一覧表示 U->>JW: 「3 件目を承認」 JW->>A: 承認イベント A->>S4: 消し込み仕訳 POST S4-->>A: 完了
この構造で重要なのは、LLM 単体ではマッチングを完結させない ことです。LLM は「候補 + 信頼度の説明文」を作る役割に限定し、実際の仕訳起票は Function Calling 経由で S/4HANA の標準 API を呼ぶ設計が安全です。学習データに含まれない最新の請求番号体系・税コード・通貨レートを LLM が幻覚で埋めてしまう事故を避けるためで、これは Reference Architecture が示す「Grounding + Tool Use」の典型実装です。
CoE 観点では、本領域は 標準 Joule Agent を起点に採用 すべき領域だと私は考えます。理由は (1) 入金消し込みは業界横断で構造が似ており標準化しやすい、(2) 既存の SAP Cash Application(機械学習版)の延長線上にある、(3) Custom 化しても会計監査トレース要件が厳しく独自実装は割に合わない、の 3 点です。
5.3 業務例 2: 調達 / Procurement Q&A + 承認フロー
調達領域は Joule Q&A(カタログ検索・契約条件参照)+ 承認フロー起動 の組合せが業務組み込みの王道パターンになります。SAP Ariba のカタログ・契約データを RAG で参照しつつ、社内ポリシーに基づく承認ルートを Joule から起動するイメージです。
このシナリオは 公式 Reference Architecture(A2A + MCP 構成)の典型ユースケース で、Joule が Orchestration を、Procurement Agent が個別タスクを、Function Calling 層が Ariba API と社内承認ワークフローを叩く 4 層構造に綺麗にはまります。
flowchart LR U["購買要求者"] J["Joule"] PA["Procurement Agent"] RAG["RAG: Ariba カタログ /<br/>契約条件 / 社内ポリシー"] Ariba["Ariba API"] WF["承認ワークフロー<br/>(BTP Build Process Automation)"] Mgr["承認者"] U -->|"PC 100台が必要"| J J --> PA PA --> RAG RAG --> PA PA -->|候補提示| U U -->|選択 + 申請| PA PA -->|発注前申請| Ariba PA -->|承認依頼| WF WF --> Mgr Mgr -->|承認| WF WF -->|承認完了| Ariba
Function Calling の定義は公式 Reference Architecture が A2A プロトコル + MCP で標準化を進めていますが、本記事公開時点では具体的な YAML / JSON スキーマは GitHub の Reference Implementation for A2A-Compliant Pro-Code Agents on SAP BTP with Joule Integration に集約されている段階です。実装の細部は当該リポジトリのサンプルを参照する想定で、CoE としては 「どの SAP 標準 API を Function として登録するか」のカタログ管理 が初期の主作業になります。
具体的には (a) Ariba Catalog Search API、(b) Ariba Purchase Requisition API、(c) Build Process Automation のワークフロー起動 API の 3 本が最初の Function 候補です。これらは全て SAP API Business Hub に公開されており、SAP Destination Service 経由で安全に Function Calling 層に接続できます。
5.4 業務例 3: SCM(仮想シナリオ・公式実装事例ではありません)
SCM 領域では 在庫アラート → 自動補充提案 → 承認 という、SAP S/4HANA Supply Chain + Joule + Business Data Cloud をつなぐ Custom Agent を仮想的に設計します。標準 Joule Agent でも近いものは出てくると予想しますが、業務固有の安全在庫ロジック・サプライヤ選定ルール を組み込む場面は Custom Agent の出番になります。
設計の柱は次の 3 ステップです。第一に Trigger は BDC(Business Data Cloud)からのイベント とし、在庫水準が閾値を下回ったタイミングで Agent が起動します。第二に Reasoning は Generative AI Hub に委譲し、過去の発注実績・リードタイム・サプライヤ評価をプロンプトに織り込んで補充案を生成します。第三に Action は Function Calling 経由で S/4HANA の購買発注 API を呼び、人間の承認後にだけ発注を確定します。
Joule Studio での構築ステップは以下のように整理できます。(1) Agent Skeleton 生成(Joule Studio の Visual Builder か SAP Cloud SDK for AI のテンプレートから開始)、(2) Function Catalog 登録(Destination Service で S/4HANA / BDC への接続を定義し、Function を YAML スキーマで宣言)、(3) Instructions / Prompt 設計(補充ロジック、安全在庫の取扱い、ハルシネーション抑止策)、(4) RAG 接続(過去発注履歴ベクトルを HANA Cloud Vector Engine から検索)、(5) Joule Registration(A2A で Joule に登録、Joule Work から呼べる状態にする)、(6) Approval Step(Build Process Automation で承認フローを挟む)。
コミュニティ Building an Agentic AI System with SAP Generative AI Hub も Generative AI Hub 上の Agent 実装ハンズオンとして公開されていますが、本記事執筆時に WebFetch では 403 が返ったため、内容は同シリーズの GitHub サンプル(SAP-samples/generative-ai-codejam、Jupyter Notebook 12 演習 + Agent 拡張モジュール)から間接的に確認しました。SCM の仮想シナリオもこのサンプル構成(Generative AI Hub + AI Core + HANA Cloud Vector)を骨格にしています。
CoE 観点では、SCM Custom Agent は 「業界・自社特有の在庫ロジックを抱えるかどうか」 で採用判断が分かれます。汎用的な MRP / DRP の延長で済む業務は標準 Agent を待つ方が安全、自社固有の制約(多階層 BOM・特殊保管条件・季節変動の独自モデル等)を抱える業務は Custom Agent の優先度が上がる、というのが私の整理です。
5.5 採用判断軸(標準 Agent vs Custom Agent)
ここまでの 3 業務例を踏まえて、標準 Joule Agent と Custom Joule Agent の採用判断軸を 5 軸で整理します。業務特殊性が低い領域は標準、業務特殊性が高い領域は Custom が原則です。ただし Custom には保守コスト・SAP 標準アップデートへの追随コストが必ず付きまといます。
| 判断軸 | 標準 Joule Agent | Custom Joule Agent |
|---|---|---|
| 業務特殊性が低い(標準業務) | ○ ○ 第一選択 | × × 不要 |
| 統治オーバーヘッド(監査・権限) | ○ ○ SAP 提供のガバナンス | △ △ 自前で監査ログ・権限設計 |
| 開発期間 | ○ ○ ほぼゼロ(設定のみ) | × × 数週間〜数か月 |
| 保守コスト(リリース後) | ○ ○ SAP が保守 | × × 自社で改修・テスト継続 |
| SAP 標準アップデート追随 | ○ ○ 自動 | △ △ 標準 API 変更時に都度修正 |
| 業務固有ロジック組込 | × × 困難 | ○ ○ 自由 |
比較・代替手法
Custom Joule Agent の代替手法として、自前で LangChain / LangGraph を組む / Microsoft Copilot Studio / Salesforce Agentforce といった選択肢があります。SAP データを主戦場にするなら Joule 系が有利ですが、マルチクラウド前提のグランドデザインだと検討余地が出てきます。
| 軸 | Custom Joule Agent | LangChain / LangGraph 自前 | Microsoft Copilot Studio | Salesforce Agentforce |
|---|---|---|---|---|
| SAP データ密接性 | ○ ◎ ネイティブ | △ △ Destination Service 経由で可 | △ △ コネクタ経由 | × × 別物 |
| 学習コスト(既存スキル流用) | △ △ Joule Studio 固有 | ○ ○ OSS 知識流用可 | ○ ○ M365 知識流用可 | ○ ○ Salesforce 知識流用可 |
| SAP 標準アップデート追随 | ○ ○ SAP が同期 | × × 全部自前 | × × コネクタ依存 | × × 別ベンダー |
| 多 LLM プロバイダ対応 | ○ ○ GenAI Hub 経由で複数 | ○ ○ 自由 | △ △ Azure OpenAI 中心 | △ △ Salesforce 提供 LLM 中心 |
| 主たる差別化 | 4 層アーキ + A2A / MCP 標準 | フレームワーク自由度 | M365 統合 | CRM 統合 |
私の整理では、SAP データを主戦場にする業務領域は Custom Joule Agent が第一選択、マルチクラウドかつ M365 / CRM が主戦場なら Copilot Studio / Agentforce、研究開発・PoC で純粋に AI Agent を組みたい場合は LangChain / LangGraph 自前 がそれぞれ合理的です。Joule Studio Pro-Code は LangGraph / CrewAI / AG2 も受け入れるため、「Pro-Code Joule Studio = OSS フレームワークの SAP 統合版」 と捉えると Custom Agent と OSS 自前の境界は実は薄くなっています。
私の考察
ここからは私(reeei)個人の判断軸を述べます。SAP CoE 実務者として Custom Agent の採用方針を組むなら、標準 Agent を起点に、業務特殊性が高い領域だけ Custom Agent を段階追加する のが王道だと考えます。Sapphire 2026 で 200+ Agent が予告された以上、ゼロから自前構築する Custom Agent は確実に減ります。逆に 「標準でカバーされる業務は積極的に標準を採る」 という意思決定が CoE の最初の仕事になります。
二点目に、Function Calling 設計は SAP 標準 API カタログから始めるべき と考えます。Reference Architecture が示すように、Function Calling 層は「Tools / APIs」の層であり、ここに何を積むかで Agent の能力は決まります。SAP API Business Hub に公開されている OData v4 / SOAP API のうち、業務インパクトの大きいものから順に Function 化 することで、後発の Custom Agent も同じカタログを再利用できます。Function カタログ = CoE の資産 という発想です。
三点目に、開発体制は二層運用 が現実解です。Joule Studio Pro-Code(SAP Cloud SDK for AI)は CoE 内エンジニアに集約、Joule Studio の Low-Code ビジュアル開発 / Agent Builder は業務ユーザーに降ろす、という分業です。Pro-Code は型安全性・テスト容易性・性能最適化が強みなので難易度の高い Agent を、Low-Code は業務ロジックの素早い反映が強みなので業務ユーザー側の Agent を、それぞれ担います。
その上で、Custom Joule Agent を CoE で採用するかという問いに対する私の最終判断は次のとおりです。
参考リンク
- 2026 SAP Sapphire Keynote: Powering the Autonomous Enterprise(2026-05-13)
- 2026 SAP Sapphire Keynote: Making AI Value Real Today(2026-05-15)
- Announcing New Joule Studio(2026-05-13)
- Build AI Agents on SAP BTP (Golden Path)
- Agentic AI & AI Agents (Reference Architecture)
- Pro-Code AI Agents on SAP BTP
- Building an Agentic AI System with SAP Generative AI Hub
- SAP-samples/generative-ai-codejam
関連する記事
SAP Business Data Cloud:構成・特長・今後の活かし方
SAP Business Data Cloud(BDC)の概要・Datasphere/SAC/SAP Databricks/HANA Cloud など主要コンポーネントの役割分担・Sapphire 2026 で再定義された autonomous enterprise の trusted knowledge core としての今後の役割と活かし方を整理しました。
SAP Sapphire 2026 キーノート総括:Autonomous Enterpriseと世界の反応
SAP Sapphire 2026 キーノートで打ち出された Autonomous Enterprise・Joule Agents 200+・Joule Work・Industry AI 26 業種・RISE/GROW コミットメントを公式情報で整理し、アナリスト・テック系メディア・LinkedIn・市場の muted reaction まで含めて世界の反応を一括で読み解きます。
SAP AI Core でできること:機能・アーキ・技術詳細の整理
SAP AI Core は BTP 上の AI 実行基盤として、Kubernetes と Argo Workflows をベースに ML / 生成 AI を統合管理します。本記事では機能リスト・アーキ全体像・Generative AI Hub / RAG / Agent の技術詳細を整理します。