この記事のポイント
- JouleとJoule Studioは別物。Joule＝業務ユーザー向けの会話型AIコパイロット、Joule Studio＝Skill／Tool／Agentを自作する開発環境です
- 実行は「発話 → Intent／Agent → Skill → Tool → CAP → S/4HANA」の一本道。Joule自身は業務データベースを持ちません
- CAPが取引先・品目・購買組織・プラント・価格・権限の6項目を検証し、LLMから基幹システムへの直接アクセスを遮断します
- 金額が承認しきい値を超えたらBuild Process Automationで人の承認を挟みます。Human-in-the-loopは後付けではなく設計要件です
01WHAT JouleとJoule Studioは何が違うのか——入口と開発環境
JouleはSAPが提供するAIコパイロットで、業務ユーザーが自然言語でSAPのデータや処理にアクセスするための対話型インターフェースです。「10日以上遅延している購買発注を見せて」といった照会も、「取引先V100向けの購買発注ドラフトを作って」といった登録系の依頼も、同じ入力欄から受け付けます。ただしJoule自身は業務データベースではありません。回答や実行に必要な情報は、必ず後続のバックエンド機能を呼び出して取得します。この前提が、以降の設計理解の土台になります。
Jouleとは：業務ユーザーが話しかける「入口」
Jouleの価値は、SAPの画面遷移やTコードを知らなくても、業務の意図をそのまま伝えられる点にあります。従来は複数のFioriアプリを行き来していた確認作業が、1回の問い合わせにまとまります。Jouleは会話型の入口としての役割に徹しており、権限のないデータを見せることはありません。
またJouleは、SAP Build Work Zoneと組み合わせて使われる場面が増えています。Work ZoneはFioriアプリ、CAPアプリ、サードパーティアプリ、そしてJouleを1つの入口に束ねる統合ポータルです。ユーザーはWork Zoneに1回ログインし、そこからFiori画面・Joule・承認タスク・自作アプリを同じ操作感で行き来できます。
Joule Studioとは：Jouleを拡張する開発環境
Joule Studioは、Jouleの標準機能では足りない処理を追加するための開発・オーサリング環境です。開発者はここでSkill（業務処理の単位）、Tool（呼び出すAPI）、Agent（複数のToolを組み合わせて推論する処理）を作成し、Jouleから呼び出せるようにします。
つまり関係は「Joule＝利用者向けの窓口」「Joule Studio＝その窓口に自社の処理を足す工房」です。標準のJouleで足りる範囲はそのまま使い、自社固有の調達ルールや承認フローを足したいときにJoule Studioへ入る、という使い分けになります。
Skill・Tool・Agentの3層構造
拡張の構成要素は3つあり、責務がはっきり分かれています。Skillは「何をするか」を表す業務処理の単位、Toolは「どのAPIを呼ぶか」という具体的な接続先、Agentは「どのToolをどの順で使うか」を状況に応じて決める推論役です。
たとえば遅延購買発注を一覧する場合、SkillはGetDelayedPurchaseOrders、ToolはGET /api/purchase-orders/delayed、その先のCAPがS/4HANAのOData APIを呼びます。1つのSkillに1つの責務を持たせると、テストと権限管理が容易になります。
用語補足：Intent（インテント）
Intentは「ユーザーが何をしたいのか」を表す意図の分類です。実行シナリオでは、発話から intent＝CreatePurchaseOrder、supplier＝V100、material＝M100、quantity＝100 といったパラメータが抽出されます。Intentの抽出はLLMが担い、その後の検証と実行はCAP以下の決定的な処理が担う。この分担が安全設計の基本になります。
02POINTS Jouleを自社業務に拡張する5ステップ
実際に手を動かす順序は、業務の絞り込みから始めて、最後に入口へ配置する流れになります。いきなり全体を設計しようとすると、Intentの分類も権限も決まらないまま作業が膨らみます。
- 業務プロセスを1つに絞るまずは「遅延購買発注の確認」のように対象業務を1つに限定します。範囲を広げるほどIntentの分類と権限設計が複雑になるため、最初の1本は読み取り系の単機能に絞るのが定石です。
- CAPで業務APIを作るAIから直接S/4HANAを触らせず、CAPに業務サービス層を用意します。この層でAPI抽象化・入力検証・権限チェック・エラー処理をまとめて担当させ、Destination Service経由でOAuthの資格情報を管理します。
- Joule StudioでToolを登録する作成したCAPのエンドポイントをToolとして登録します。ToolはAPIの接続情報を持つだけの薄い層にし、業務判断はCAP側に残すのが保守性の観点で有利です。
- SkillとAgentを定義するSkillに業務上の意味づけ（例：GetDelayedPurchaseOrders）を与え、複数の情報を突き合わせる場合はAgentとしてToolの呼び出し順を委ねます。状況に応じてToolを選ぶ動的な処理はAgent、承認・転記のように手順が固定の処理はWorkflowに寄せます。
- Work Zoneへ配置し、承認フローをつなぐ最後にWork Zoneの画面からJouleに到達できるようにし、金額などの条件で承認が必要な処理はBuild Process Automationへ流します。承認しきい値・通知先・差し戻し時の扱いまで決めておくと、本番運用で止まりません。
最初の1本は「読み取り専用」から
いきなり登録系の処理から始めると、検証も承認も一度に必要になり、検証に時間がかかります。まずは照会系のSkillを1本通し、Intentの抽出精度・CAPの応答速度・権限の通り方を確認してから登録系へ広げる進め方が現実的です。
03INSIGHT 「Block supplier.」を直接実行させない設計
Joule拡張で最も重要な設計判断は、「どこまでAIに任せ、どこから人とワークフローに渡すか」です。象徴的な例が「Block supplier.（取引先をブロックして）」という指示です。ユーザーがこのように発話しても、それをそのままS/4HANAの更新APIへ流してはいけません。
正しい流れは、Recommendation（AIの推奨）→ CAP Validation（業務検証）→ Approval Workflow（人の承認）→ S/4 Update（S/4HANAの更新）です。AIは推奨までを担い、更新の実行権限は持ちません。この境界を引くことで、ハルシネーションやプロンプトインジェクションの影響が基幹データの更新に直結することを防げます。
この考え方は、AI Agentと従来のWorkflowの役割分担として整理できます。Agentは目的から逆算してToolを選び、結果を見て次の行動を決めるため、動的な情報収集や推薦に向いています。一方で、承認・コンプライアンス・財務統制・転記のように手順と統制が固定された処理はWorkflowの領分です。実務では Agent → Workflow → Human → Transaction の順に受け渡す構成が基本になります。
たとえばSupplierRiskAgentというAgentを作る場合、getSupplier()・getOpenPO()・getDeliveryHistory()・getQualityIssue()・getInvoiceHistory()という5つのToolを持たせ、情報を集めて分析し、推奨を生成する役割を担わせます。重要なのは、この5つがすべて参照系であり、更新系のToolを持たせていない点です。取引先を止めたいという判断が出たとしても、実行は承認フローを経由します。
CAPの役割もここで効いてきます。CAPはAIの体験と基幹システムの間に入る統制された業務サービス層で、API抽象化・業務検証・認可・オーケストレーション・統合・エラー処理を担当します。これにより、LLMがS/4HANAへ無制限にアクセスすることを構造的に避けられます。土台となるAI CoreとGenerative AI Hubの関係はSAP AI Core／Generative AI Hubとは？BTP上でLLMを安全に使う仕組みで、CAP側の実装はSAP BTP CAP入門で詳しく解説しています。
データ保護も同じ構造で考えます。Identity → Authorization → Tool permission → CAP authorization → Destination／OAuth → Backend authorization → Audit の順に統制を積み、最小権限の原則を守ります。加えて、最新の自社データを回答に反映させるにはRAG（検索拡張生成）で信頼できる文脈を実行時に渡す必要があります。Foundation modelは顧客固有の最新データを本来知らないためです。S/4HANA本体側の拡張と役割を分けたい場合はSAP RAPとは？ABAP RESTful Application ModelでS/4HANA本体を拡張する、機密データを外部に出さない構成はローカルLLMで実現する、安全なSAP×AI活用も参考にしてください。
承認しきい値は先に決める
購買発注ドラフトの作成のような処理でも、金額が承認しきい値を超えればBuild Process Automationによる人の承認が必要になります。しきい値の設定を後回しにすると、テスト時に「誰がどの条件で承認するのか」が決まらず、検証が止まります。業務ルールの棚卸しは、Skillの設計と同じタイミングで行ってください。
豆知識：ドラフト作成と転記は別物
実行シナリオの応答は「Purchase order draft 4500012345 has been created and submitted for approval.」、つまり作成されたのは購買発注のドラフトで、状態は承認待ちです。AIが扱うのは下書きまでで、確定転記は承認後にS/4HANA側のAPIが実行する。この分担が、AIを業務に使うときの現実的な落としどころになります。
まとめ
- Jouleは業務ユーザー向けの会話型AIコパイロット（入口）、Joule StudioはSkill／Tool／Agentを自作する開発環境
- 実行モデルは 発話 → Intent／Agent → Skill → Tool → CAP → S/4HANA の一本道で、Joule自身は業務DBを持たない
- Skill＝業務処理の単位、Tool＝APIの接続先、Agent＝複数Toolの呼び出し順を判断する推論役
- CAPが検証・認可・抽象化を担い、LLMからS/4HANAへの直接アクセスを遮断する
- 更新系は Recommendation → CAP Validation → Approval Workflow → S/4 Update の順に人を挟む
- 統制は Identity → Authorization → Tool permission → CAP authorization → OAuth → Backend → Audit の7段で積む
04FAQ よくある質問
JouleとJoule Studioの違いは何ですか？
Jouleは業務ユーザーが使う会話型のAIコパイロットで、Joule StudioはそのJouleに自社固有のSkill・Tool・Agentを追加するための開発環境です。利用者向けの窓口と、拡張を作る工房、という関係で覚えると分かりやすくなります。
AIは購買発注を直接作成できますか？
技術的には作成APIを呼び出せますが、AIの解釈と取引の統制は分離すべきです。AIは依頼の理解とパラメータの収集を担い、CAPが業務データと権限を検証し、金額などの条件に応じてBuild Process Automationが人の承認を挟んでから、S/4HANAのAPIが最終処理を行います。
AI CoreやGenerative AI Hubとの関係はどうなっていますか？
AI CoreはBTP上のAIランタイムとライフサイクル管理の基盤で、Generative AI Hubはその中の統制されたLLMアクセス層です。競合する2つのサービスではなく、土台とその機能という関係です。Joule側の拡張はCAPを通じてこの土台に接続します。
プロンプトインジェクションはどう防ぎますか？
LLMに更新系の権限を渡さないことが第一の防御です。そのうえでToolの権限を参照系に限定し、CAPで認可と入力検証を行い、更新はワークフローと人の承認を経由させます。すべての呼び出しを監査ログに残し、想定外のTool呼び出しを検知できる状態にしておきます。
出典・参考
- SAP Help Portal — SAP Joule（SAP） https://help.sap.com/docs/JOULE/
- Joule Studio（SAP Developers） https://developers.sap.com/concepts/joule-studio/
- SAP Help Portal — SAP AI Core（SAP） https://help.sap.com/docs/sap-ai-core
- Generative AI Hub（SAP Developers） https://developers.sap.com/concepts/generative-ai-hub/
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-21）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。