日本語

SAPの自律エンタープライズへの賭け:50のJouleアシスタント、200のエージェント、CTOが評価すべきClaude連携

SAP Sapphire 2026の自律エンタープライズスタック図:200の専門エージェントの上に50のJouleアシスタントが配置されている

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

SAPはエンタープライズ顧客に対して、ERPがエージェントのcontrol planeになると宣言しました。これは機能アップデートではありません。スタックの判断です。

マドリードで開催されたSAP Sapphire 2026(5月13日から15日)において、CEO(最高経営責任者)のChristian Klein氏は「自律エンタープライズ」と呼ぶビジョンを発表しました。これはSAPのERP(エンタープライズリソースプランニング)を、エージェント駆動の階層型ビジネス向けオペレーティングシステムとして再構築する全面的なプラットフォーム転換です。SAP Sapphire 2026の基調講演によると、同社は200以上の専門エージェントを基盤に、その上に50以上のドメイン固有のJouleアシスタントを展開します。さらに、ポートフォリオ全体の主要な推論レイヤーとしてAnthropicのClaudeを組み込みます。

SAPの大きな資産を抱えるCTO(最高技術責任者)には、判断が求められます。Jouleが興味深いかどうかではありません。今後5年から7年間、SAP にエージェントオーケストレーション層を委ねるかどうかの判断です。

SAP Sapphire 2026で実際に発表されたもの

SAPが発表したもの

  • 財務、サプライチェーン、調達、HCM(ヒューマンキャピタルマネジメント)、CX(顧客体験)をまたいで200以上の専門エージェントをオーケストレーションする50以上のドメイン固有Jouleアシスタント(SAP Sapphire 2026基調講演)
  • Joule Studio 2.0のデザインタイムアクセスを2026年末まで無料で提供。LangGraphおよびAutoGenスタイルのフレームワークでライブSAPデータに対して構築可能(SAP News、2026年5月)
  • AnthropicのClaudeがSAPのソリューションポートフォリオ全体に組み込まれる「主要な推論・エージェント的能力」となる(SAP Anthropicパートナーシップ拡張)

評価に必要な詳細を正確に把握するため、リリースの内容を具体的に確認しましょう。

アーキテクチャは2層構造のエージェントスタックです。上層には50以上のJouleアシスタントが配置され、それぞれが特定のビジネスドメインに対応しています:財務、サプライチェーン、調達、HCM、CX。各アシスタントはオーケストレーターとして機能し、ビジネスリクエストを分解してその下の200以上の専門エージェントに実行を委ねます。エージェントは個別のタスクを処理します:発注書の更新、給与ワークフローのトリガー、サプライチェーンの異常通知などです。

これらすべての基盤として、SAPが「SAP Business AI Platform」と呼ぶ新たな基盤層があります。これは以前は別々に存在していた3つのものを統合したものです:SAP Business Technology Platform、SAP Business Data Cloud、SAP Business AIです。主張は、AI開発、データアクセス、コンプライアンスのための一元化されたガバナンス環境です。規制業界のCIO(最高情報責任者)にとって、この統合されたガバナンスの物語が発表の最も説得力のある部分かもしれません。

RISEの顧客は、以前のSapphireの報道によると、初年度に3つのJouleアシスタントを契約に含めて取得します。これにより「とりあえず試してみよう」という摩擦が取り除かれます。問いはすぐにスコープと長期的なコミットメントへと移行します。

エージェント数よりもClaudeの組み込みが戦略的に重要な理由

エージェント数が見出しです。Claudeとのパートナーシップが戦略的シグナルです。

Sapphire 2026の発表によると、AnthropicのClaudeはSAPのAI強化ソリューションポートフォリオ全体に組み込まれる「主要な推論・エージェント的能力」となります。つまりClaudeはオプションの追加機能ではありません。JouleとJouleエージェント全体に組み込まれた推論レイヤーです。

多くのCTOにとって、見落としやすい問いが生じます。ERPベンダーに基盤モデルを選ばせたいか?という問いです。

今日のエンタープライズAI戦略のほとんどは、ある程度のモデルの柔軟性を前提としています。一部のワークロードにはAnthropicのClaude、他のワークロードにはOpenAIのモデル、コード生成にはGoogle Gemini、エアギャップ環境にはオープンソースモデルといったように。この柔軟性によって、コスト、パフォーマンス、データレジデンシー、ベンダーリスクを最適化できます。JouleにClaudeが推論レイヤーとして固定されると、Jouleが担当するすべてのワークフローでその柔軟性が失われます。

これはClaudeへの批判ではありません。エンタープライズグレードのエージェント的作業に向いた、強力な推論モデルの一つです。しかし判断はあなたに代わって行われています。そして、モデル非依存のオーケストレーションフレームワークにすでに投資しているCTOにとって、これは構造的な矛盾です。

2つ目の考慮事項もあります。Microsoft Copilotを通じてMicrosoftの推論モデルも利用している場合、またはAnthropicと直接エンタープライズ契約を結んでいる場合、SAP内のClaudeとの関係がライセンス、データ取り扱い、モデル更新について三者間の複雑な会話を生む可能性があります。

SAP資産の大きいCTOが答えるべき3つの問い

SAPのJouleを水平型エージェントプラットフォームと比較するための3問フレームワーク

これをSAP深度テストと呼びましょう。Jouleを主要エージェントcontrol planeにすべきか、専門的な統合対象にとどめるべきかを判断する3つの問いです。

問い1:深度。エンタープライズデータとワークフローのうちSAP内にあるのは何%か?

4,000人規模の製造業者がSAP S/4HANAを財務、調達、設備保全、サプライチェーンで運用しているケースを考えてみましょう。業務上重要なワークフローの70%がSAPネイティブであれば、Jouleアシスタントはおそらく最も効率的なパスです。データはすでにそこにあります。統合もすでに存在します。これらのシステムすべてに対して水平型エージェント統合を構築するには時間、費用、継続的なメンテナンスが必要です。

しかし、SAPが財務と調達を担当しているが、収益エンジンがSalesforceで動き、顧客データがSnowflakeにあり、HRワークフローがWorkdayにある企業では状況が変わります。エージェントオーケストレーションの問題は本質的にクロスシステムです。SAPのJouleはSAPドメインのタスクに最適化されています。クロスシステムの問題は解決せず、エージェント層の主導権をJouleに与えるとギャップが生まれます。

目安:SAPワークフロー集中度が40%未満の場合、Jouleは水平プラットフォームが主導権を持つ対象システムとして最もよく機能します。60%を超えると、Jouleがより実際的なcontrol planeになり得ます。

問い2:モデルのロック。Claude推論のハードコードは許容できるか、それともモデル非依存のオーケストレーションが必要か?

AIポリシーがすでにモデルの柔軟性を要件として規定している場合、JouleのClaude統合は機能ではなく制約です。その制約を文書化し、SAPドメインのワークフローに対して許容可能であることの承認を取得し、SAP外のすべてに対して別のモデルガバナンスプロセスを維持する必要があります。

すでにエンタープライズ契約でAnthropicの顧客であれば、Claude統合が実際に物事をシンプルにする可能性があります。管理するベンダー関係が一つ減ります。

問い3:重複。SAP隣接ワークフローにすでに触れている水平型エージェントプラットフォームは何か、そして最初の競合はどこで発生するか?

ここが評価が具体的になる部分です。財務チームにMicrosoft 365 Copilotを展開しているグローバルサプライチェーン企業のCTOは、ほぼ即座に重複に直面します。Jouleは財務ワークフローエージェントの主導権を主張し、MicrosoftのAgent 365プラットフォームはExcelとTeamsの統合を通じて同じ領域を主張します。ServiceNowは調達承認で重複します。SalesforceのAgentforceはSAPのJouleポートフォリオにも含まれるCXワークフローに触れます。

始める前にすべての重複を解決する必要はありません。しかし、コミットする前に最初の競合を特定する必要があります。それが関係を定義するものになります。

このような評価について他の実践者がどのように考えているかは、ガバナンスギャップ:リーダーが職場のAIについて誤解していることおよびAIコパイロット対AIエージェント:違いを理解することの重要性をご覧ください。

Joule Studio 2.0が購入か自社開発かの判断に与える意味

Joule Studio 2.0は2026年6月に出荷予定です。エグゼクティブレベルのエージェント戦略の会話とは別に、プラットフォームエンジニアリングチームが個別にレビューする必要があります。

SAPはJoule Studioをライブなビジネスデータに対してカスタムエージェントとアシスタントを構築するための開発環境として位置づけています。LangGraphおよびAutoGenスタイルのフレームワークをサポートしており、エンジニアが一から独自のビルドシステムを習得することなく、既存のエージェント開発パターンをSAP環境に持ち込めます。

価格設定のシグナルは意図的です。デザインタイムアクセスは2026年末まで無料で、フェアユース制限の下でAI支援の開発が含まれます。SAPは、本番利用に課金する前に採用を促すための先行コスト障壁を取り除いています。典型的な「まず定着、後から拡大」の戦略です。

実際的な意味:エンジニアは6月からSAPデータに対して予算の議論なしに構築を開始できます。概念実証には有益です。しかし、GA(一般提供開始)の価格設定、本番環境の制限、サポート条件が、構築したものが移行可能かどうか、あるいは退出する場合に技術的負債を生むかどうかを決定します。

プラットフォームチームへの重要な問い:Joule Studioで構築したエージェントは移植可能か?ベンダーを切り替えるかハイブリッドアーキテクチャを構築する場合、SAP環境の外でも動作できるか?LangGraph/AutoGenの互換性は有望です。無料期間が終わる前に移植可能性を明示的に確認してください。

このような判断を評価するより広いフレームワークについては、AIワークフォース戦略のエグゼクティブ意思決定フレームワークおよび「節約された時間」を超えたAI ROIの測定をご覧ください。

CTOチームのための60日間SAP Joule評価プラン

今月中にスタック全体の決定を下す必要はありません。しかし、デフォルトでその決定に漂流してしまうことは避ける必要があります。以下はあなたが主導権を保つための60日間の評価構造です。

1日目から10日目:SAP資産のマッピング

エンタープライズアーキテクトに、どのビジネスプロセスがSAPネイティブで、どれがクロスシステムかを具体的に文書化させます。大まかなワークフロー集中度の割合を割り当てます。この一つの数字が下流の判断のほとんどを左右します。これがなければ、Jouleの会話は理論的なままです。

11日目から20日目:既存エージェントプラットフォームコミットメントの監査

Microsoft Agent 365、Salesforce Agentforce、ServiceNow AI、またはSnowflake Intelligenceで、SAPのJouleスコープのワークフローにも関わる契約、パイロット、または本番デプロイをすべて確認します。重複をマッピングします。最初の競合ポイントを特定します。これは何かをキャンセルすることについてではありません。現状を把握することについてです。

21日目から30日目:モデルロックのレビュー

AIポリシーでモデルの柔軟性が明示的な要件となっている場合、JouleのClaude統合がJouleが担当するSAPドメインのワークフローに対して許容可能であることを法務チームとセキュリティチームから書面で確認を得てください。許容可能でない場合は、先へ進む前にカーブアウトや別のアーキテクチャが必要です。

31日目から45日目:Joule Studio 2.0の概念実証

無料のデザインタイムアクセスを使用して、実際のSAPワークフローに対して一つの狭いエージェントまたはアシスタントを構築してください。リスクは低いが本質的に代表的なものを選んでください。財務レポートの更新、調達状況の通知、またはHRオンボーディング状況の更新が良い候補です。目的は本番デプロイではありません。移植性テストです:エンジニアがその環境で作業できるか、そして必要であれば構築したものを他の場所に持ち出せるか?

46日目から60日目:スタック判断メモ

CTOリーダーシップチームへの1ページのメモを作成します:SAP資産の割合、重複マップ、モデルロック評価、概念実証の結果、そして以下の3つのパスの一つの推奨。

パスA:SAPドメインワークフローの主要エージェントcontrol planeとしてのJoule、クロスシステムオーケストレーションには水平プラットフォーム(Microsoft、Salesforceなど)。

パスB:主要エージェントcontrol planeとして水平プラットフォーム、API統合による対象システムとしてのJoule。

パスC:6ヶ月判断を保留、モニタリング継続、再評価の期限を設定。

パスCは具体的な待機理由がある場合にのみ正当化されます。デフォルトにしないでください。

この投資ケースを取締役会に説明する方法については、誇張なしで取締役会にAIワークフォース投資を語る方法およびAIエージェントとセールスパイプライン:誇張、現実、実際に機能していることをご覧ください。


よくある質問

Joule Studio 2.0が一般提供開始になるまでコミットを待つべきか?

デザインタイムアクセスは2026年6月に出荷され、年末まで無料です。本番環境へのコミットなしにその期間中に意義ある概念実証を実施できます。完全なGAを待つリスクは、SAP営業チームが評価を完了する前にJouleアシスタントの契約会話を加速させることです。ビジネスの判断が更新交渉中にデフォルトで行われないよう、今すぐ技術的なレビューを始めてください。

JouleはSAP隣接業務でMicrosoft Copilotの代替になるか?

自動的にはなりません。重複は完全ではなく部分的です。MicrosoftのCopilotとAgent 365はMicrosoft 365層で動作します:Teams、Excel、SharePoint、Outlook。JouleはSAPデータとプロセス層で動作します:財務トランザクション、調達承認、サプライチェーンイベント。競合ゾーンは両方が同じワークフローに触れる場所です。実際には存在しますが、最初に見えるより狭い範囲です。当面は両方が必要で、両者の間に明確なハンドオフポイントを設定することになるでしょう。月末決算をSAP経由で行いながらTeamsで調整している財務チームが最も明確な重複シナリオです。

経営陣の承認から1つのJouleアシスタントの本番環境までの現実的なタイムラインは?

契約に3つのアシスタントが含まれているRISEの顧客は、範囲を絞り込み専任のプラットフォームエンジニアリングリソースがいれば、90日から120日で本番環境に1つを導入できます。主な変数は、データガバナンスのレビュー(規制業界の場合は特に)、既存エージェントプラットフォームとの統合テスト、アシスタントを使用するビジネスチームへの変更管理です。最初から広範な展開を試みる企業は行き詰まる傾向があります。1つのアシスタント、1つのドメイン、1つのチームから始めてください。


さらに詳しく

About the author

Victor Hoang

Victor Hoang

Co-Founder, Rework.com

Victor Hoang is Co-Founder and CMO of Rework. He spent 12+ years scaling B2B SaaS growth, building a lead engine that generated over 1 million leads and $10M+ in annual recurring revenue. Today he builds AI agents and MCP servers into Rework's products to empower customers across growth and operations. He writes about what actually works.