翻訳者ノート
こんにちは！コンテンツチームの加藤です。
SAPのデータをAIエージェントに使わせたいと考えたとき、「SAPのMCPサーバーを自分たちで作るか、マネージド型に任せるか」で迷う方は多いのではないでしょうか。本記事は、SAP BTP上でSAPのMCPサーバーを構築する手順を一通り追いながら、その判断材料を整理したものです。日本版では、オンプレミスのECC・S/4HANAをつなぐ構成と、kintoneやExcelと併用する環境の考え方を独自に加えています。 |
SAPには、受発注や在庫をはじめとする業務の中核データが集まっています。ただ、そのSAPにAIエージェントを直接つなごうとすると、セキュリティ・権限・連携の複雑さという課題にすぐ突き当たります。しかも、エージェントを増やすたびに個別の接続を作っていけばその負担は積み上がる一方です。
こうした状況で、AIクライアントとSAPのデータを標準的な方法でつなぐ仕組みがModel Context Protocol（MCP）です。本記事では、SAPのMCPサーバーを構築し、保護し、デプロイする手順と、AIクライアントとの接続方法を順に解説します。
あわせて「自前で作るか、マネージド型に任せるか」を判断するための材料も整理しました。社内に開発と運用を担えるエンジニアがいて細かく作り込みたいなら、このまま手順のセクションへ進んでください。
構築と保守の手間を抱えたくない場合は、先に最後のセクション「自前で抱えずにSAPとAIをつなぐには？」を読んでみてください。そのうえで手順を眺めると、どこを省けるのかが見えやすくなるはずです。ガバナンスを効かせながらマネージド型でSAPをAIエージェントにつなぐ全体像は、SAPをAIエージェントにセキュアに接続する方法でも解説しています。
SAPとAIの連携はMCPで何が変わる？
MCPを使うと、AIアプリケーションとSAPなどの業務システムを1対1で個別につなぐ必要がなくなります。AIアプリとシステムがそれぞれMCPに一度ずつつながれば済むので、作って保守すべき連携の数そのものが減ります。
MCPがない場合、AIアプリケーションは利用するシステムごとに専用の連携を作り込む必要があります。
AIアプリケーションが「M」個、システムが「N」個あれば、必要な連携は最大でM×N本になります。MCPはこれをM+N本に減らします。
各アプリケーションはMCPに一度つなぐだけで済み、各システムも自分の機能をMCP経由で一度公開すれば済むからです。たとえばClaude・ChatGPT・Cursorの3つのAIクライアントから、SAP・kintone・Salesforce・Excelの4つを使うとしましょう。個別に連携すれば12本ですが、MCPなら7本です。あとはプロトコルが両者のやり取りを受け持つので、連携の構築・保守・拡張がずっと楽になります。
SAPのMCPサーバーはどんな仕組みで動く？
このM+Nモデルは、ホスト・クライアント・サーバーの3つの要素で成り立っています。ホストはAIアプリケーションそのものです。ホストの中にあるMCPクライアントが、個々のMCPサーバーとの接続を保っています。サーバー側は、AIが「ツール」として使えるデータや操作を公開する役割です。
SAPの場合、このツールはODataのエンティティセットとCRUD操作に対応づけられます。ツールごとに目的と入力がはっきり決まっているので、モデルは「何ができて、いつ呼べばよいか」を判断しやすくなります。
1つのMCPサーバーで、SAPの広い範囲をまとめて公開することもできます。たとえばSAP Cloud Integration向けのコミュニティ製MCPサーバーは、SAP Cloud Integration OData V2 APIを利用しています。ここには32個のエンティティセットがあり、そのすべてをMCPツールとして自動で公開しています。エンティティセットごとにコードを書く必要はありません。
なお、SAP向けのMCPサーバーには、本記事が扱うODataエンティティセット型とは別に、SAP GUIの画面操作を自動化するタイプも存在します。前者はAPI経由で業務データそのものにアクセスするのに対し、後者は画面上の操作を代行する仕組みで、対象とする課題が異なります。本記事は、情シス・SE向けにデータ統合・API連携を軸としたアプローチを扱います。
SAPのMCPサーバーの構築前に何を決める？
SAPのMCPサーバーを安定して動かせるかどうかは、着手前の計画でほぼ決まります。複数の部署が同じSAPデータを参照する場合や、監査対応が求められる業種であれば、この段階の設計がなおさら重要になります。まず、エージェントがアクセスするSAPインスタンスと関連システム、そして必要なデータを洗い出してください。そのうえで、ユースケースごとにリアルタイムの照会が要るのか、もっと単純なワークフローで足りるのかを見極めます。可能であれば1つのサーバーに集約しておくと、ガバナンスやツールの挙動を管理しやすくなります。
着手前に押さえておきたいのは次の3点です。
システムの棚卸し：対象となるAPI・エンドポイント・エンティティセット・セキュリティ要件を一覧にします。
ユースケースの定義：どのワークフローにリアルタイムデータが必要か、エージェントにどんな操作をさせるかを決めます。
アプローチの選択：ゼロコードの仕組みで足りるのか、カスタムロジックが必要なのかを判断します。
対象のSAPがSAP BTP（SAP Business Technology Platform）上にあるのか、オンプレミスのECCやS/4HANAなのかも、この段階で確認しておきましょう。接続経路が変わるためです（後述）。全体の設計やガバナンスの考え方は、企業環境でMCPを導入する手順で詳しくまとめています。
開発環境はどう準備する？
計画が固まったら、開発環境を用意します。ゼロコードのアプローチで必要なのは次の3つだけです。
package.jsonを作成し、odata-mcp-proxyを依存関係に加えてstartスクリプトを追加します。続いてパッケージをインストールし、バージョン管理を初期化してください。最後に、この環境から必要なSAPエンドポイントに到達できるかを確かめておきます。
設定ファイルはどう設計する？
ランタイムが入ったら、中心的な役割を担うのは設定ファイルです。APIの内容を1つのJSONファイルに書くと、odata-mcp-proxyがそこからツールを生成します。apis配列の各エントリは、1つのバックエンドに対応しています。エントリごとに、destination・pathPrefix・csrfProtectedフラグ・エンティティセットの一覧を持たせます。
{
"name": "cpi",
"destination": "CPI_DESTINATION",
"pathPrefix": "/api/v1",
"csrfProtected": true,
"entitySets": ["IntegrationPackages", "IntegrationDesigntimeArtifacts"]
}
各SAPエンティティセットは、一覧取得・単体取得・作成・更新・削除・関連レコードの取得といった操作のMCPツールとして自動で公開されます。
エンティティセットには分かりやすい名前を付け、各操作が何をするのかを書き残しておきましょう。この設定ファイルはバージョン管理に置いてください。モデルが適切なツールを選びやすくなり、チームもガバナンスや監査のために変更履歴を追えるようになります。
認証と権限はどう設計する？
MCPツールはSAPのデータを読むだけでなく、書き換えることもできます。だからこそ、アクセス制御はデプロイ前に決めておく必要があります。SAP BTPでは、その多くを設定で扱えます。
xs-security.jsonでは、OAuthスコープとロールテンプレート（viewer・editor・adminなど）を定義します。ユーザーには、必要な権限だけを渡すようにします。
CSRF保護は、公開するAPIに合わせて設定します。SAP Cloud IntegrationのようなOData V2サービスとREST APIでは、求められるCSRFの扱いが異なる場合があります。すべてのエンドポイントに同じ設定を当てはめず、サービスごとに確認してください。
最後に、OAuthスコープ・テナント設定・ロールの割り当てを、自社のセキュリティ要件と監査要件にそろえます。
情報システム部門の管理者から見ると、MCPは開発者の道具である前にガバナンスの論点です。「どのエージェントが、誰の権限で、どのデータに触れたのか」を後から説明できる状態にしておく必要があります。監査や規制への対応が求められる業種であれば、この点は特に注意したいところです。スコープとロールの設計を、セキュリティ担当と一緒にレビューしておくと安心ではないでしょうか。MCPサーバー特有の脆弱性と対策の全体像は、MCPサーバーの脆弱性対策ガイドも合わせて参考にしてください。
ビルドとローカル検証はどう進める？
設定とセキュリティが整えば、ビルドはすぐに終わります。ゼロコードのサーバーを構成するファイルは、JSONの設定ファイル・デプロイ記述子・セキュリティ定義の3つだけです。ツールはodata-mcp-proxyのランタイムが生成するので、こちらが用意するのはこの設定だけです。ビルドとデプロイは次の2つのコマンドで済みます。
npm run build:btp
npm run deploy:btp
ただし、いきなりデプロイせずに、まずローカルで試してください。環境変数かdefault-env.jsonで接続情報を渡し、ローカルで動作を確認します。確認するのは、認証が通るか、CSRFトークンが正しく扱われるか、各CRUDツールが期待どおりの結果を返すかの3点です。
SAP BTPへはどうデプロイする？
設定が済んだら、プロジェクトをマルチターゲットアプリケーション（MTA）としてSAP BTP Cloud Foundryにデプロイします。BTP上のサーバーは、安全な接続とアクセス制御のためにプラットフォームのサービスを利用できます。
Destination service：SAPシステムへの接続先と認証情報 (クレデンシャル) を管理します。
XSUAA：認証とロールベースのアクセス制御（RBAC）を担います。
Connectivity service：SAP Cloud Connectorを通じて、オンプレミスのシステムへのアクセスを提供します。
SAP S/4HANAをはじめとするSAPのサービスには、Destinationを使ってサーバーをつなぎます。デプロイでよくつまずくのは、Destinationの設定漏れ・CSRF設定の誤り・割り当てたロールと合っていないOAuthスコープの3つです。
本番の前に実際のBTP環境へ早めにデプロイして試し、こうした設定の問題をつぶしておきましょう。なお、Connectivity serviceの「オンプレミスへのアクセス」は、国内のSAPユーザーにとって特に大事なポイントです。次のセクションで詳しく見ていきます。
オンプレのECC・S/4HANAはどうつなぐ？
オンプレミスのECCやS/4HANAも、SAPのMCPサーバーにつなげます。SAP Cloud ConnectorとBTPのConnectivity serviceを組み合わせ、SAP本体は社内に置いたまま、BTPをMCPサーバーの実行場所として使う構成です。
ここまでの手順は、SAP BTPのクラウド環境を前提にしていました。一方で国内には、SAP ECCやオンプレミス版のS/4HANAが今も基幹業務を支えている企業が少なくありません。日々の商談でお客様から伺う話でも、「うちはBTPネイティブではないが、関係あるのか」という疑問はよく出てきます。オンプレミスのSAPにつなぐ場合の流れは次のとおりです。
社内ネットワークにSAP Cloud Connectorを置く：Cloud Connectorは、社内側からBTPのサブアカウントへ接続します。外部から社内への受信ポートを開ける必要はありません。
公開する範囲を絞る：Cloud Connector側で、BTPから到達できる社内システムとURLパスを明示的に許可します。
オンプレミス向けのDestinationを作る：BTPのDestinationでプロキシタイプを「OnPremise」に指定します。Cloud Connector経由で、社内のSAPへ到達させる設定です。
ODataサービスの公開状況を確認する：ECCやオンプレミスのS/4HANAでは、SAP Gateway経由で必要なODataサービスが公開されているかを確認します。odata-mcp-proxyの設定ファイルは、このODataサービスを前提に書くことになります。
基幹システムをインターネットに直接さらさずに済むので、セキュリティ部門とも合意を取りやすいでしょう。ただし、Cloud Connectorの運用・監視と社内ネットワーク側の許可設定は、情報システム部門が引き続き担うことになります。この点は、自前で構築する場合の負担として最後のセクションで改めて整理します。
AIクライアントからはどう接続する？
MCPサーバーが動き出したら、次はAIエージェント側にクライアントが必要です。クライアントがサーバーに接続し、そのツールを呼び出します。MCPクライアントの接続方式は、ローカルのサーバーならstdio、リモートのサーバーならStreamable HTTPの2つです。
以前のSSE（server-sent events）を使うHTTPトランスポートは、2025-03-26版のMCP仕様で非推奨になりました。2025年中の後続の改訂では、完全に削除されています。デプロイ前に、クライアントとサーバーの両方がStreamable HTTPを使っているかを確認してください。なお、Streamable HTTPも内部ではSSEのストリームを使っています。単独のトランスポートとしては廃止されていても、SSEという言葉を目にするのはそのためです。
Chainlit・LangChain・Praison AIといったフレームワークは、MCPとの連携に対応しています。そのため、設定する内容はたいていサーバーのエンドポイント・トランスポート・認証の3点です。接続できれば、エージェントは公開されたツールを使って、SAPのデータを照会できます。複数ステップのワークフローも、そのまま実行可能です。
運用で押さえておきたいポイントは？
サーバーを公開した後も、安全で安定した状態を保つにはいくつかの習慣が欠かせません。
できる範囲で集約する：アクセス方法と管理をそろえたい場合は、関連するSAPとSAP以外の連携をCData Connect AIのようなガバナンスの効いたMCP層にまとめます。
設定はシンプルに保つ：カスタムコードを足すより、設定ファイル・CLIツール・ロールテンプレートで済ませます。
定期的に監査する：スコープとロールを見直し、エンドポイントを監視します。元になるAPIが変わったら、そのたびにCRUD操作を再テストします。
どれも一度決めれば終わりではなく、SAP側やAPIの変更に合わせて回し続ける作業です。
SAPのMCPが向く業務・向かない業務は？
MCPが力を発揮するのは、AIエージェントが実行時にSAPのリアルタイムデータや操作を必要とする場面です。たとえば、注文状況の確認や現在の在庫の照会がこれにあたります。SAPと他のシステムのデータを組み合わせたワークフローを、最後まで進めることもできます。SAP HANA上のデータをClaudeから直接扱う構成例は、ClaudeでSAP HANAのデータをリアルタイム活用する方法で画面つきで紹介しています。
反対に、静的な文書・バッチ処理・索引検索で足りる業務にはあまり向きません。
SAPのMCPのよくある用途は次のとおりです。
営業担当がAIエージェントに「A社への今月の出荷状況は？」のように尋ねると、最新のSAPデータをもとに答えられます。
受注確認や在庫照会のように複数システムにまたがる業務ワークフローを、統制を効かせたままエージェントに任せられます。
誰がどのデータに触れたかを記録する既存のアクセス制御やデータプライバシーの管理は、AIのワークフローにもそのまま適用されます。
kintoneやExcelと併用する環境ではどう考える？
SAPとkintone、Excelを併用しているなら、最初から同じMCP層でまとめて扱う設計をおすすめします。データソースごとに別々のMCPサーバーを作ると、権限と監査の管理も分散してしまうからです。
ここまではSAP単体をAIにつなぐ話でした。ただ、国内の製造業やサービス業では、SAPだけで業務が完結している企業はむしろ少ないのではないでしょうか。SAPの基幹データの横で、現場の申請や案件管理は国内で広く使われるSaaSのkintoneで回しています。月次の集計や予実管理は、Excelのファイルで手作業でまとめています。私たちがお客様から伺う環境でも、この組み合わせは珍しくありません。
この状態でSAPのMCPサーバーだけを作り込むと、AIに渡せるのはSAPのデータだけです。kintoneやExcelのデータも使わせたくなれば、別の接続を用意する必要があります。権限と監査も、それぞれ別々に管理することになります。冒頭のM×Nの問題が、SAPの外側でもう一度起きてしまうわけです。kintone側だけを先に検討したい場合は、公式・OSS・マネージド型を並べたkintone MCP Serverの選択肢比較が判断材料になります。
3つのデータソースは性質が異なるため、MCPで扱う際に気を付ける点も変わります。
データソース | 位置づけ | MCPで扱う際のポイント |
SAP（ECC・S/4HANA） | 受発注や在庫などを管理する基幹システム | ODataサービスとロールの設計。オンプレミスならCloud Connector経由の経路を用意する |
kintone | 現場の申請や案件管理に使われる国内SaaS | アプリごとに設定した権限を、AIからのアクセスでも崩さない |
Excel | 手作業で更新する集計・管理ファイル | ファイルの置き場所と更新のタイミングをそろえ、どの版をAIに読ませるかを決める |
CData Connect AIは、SAPに加えてkintoneやExcel Online（SharePoint・OneDrive上のExcel）にも接続できます。これらを1つのMCPエンドポイントから、まとめてAIに公開できます。データソースごとにMCPサーバーを作り、権限を別々に管理する手間を省けるのがこの構成の利点です。
うまく動かないときはどこを確認する？
トラブルが起きたときは、たいてい次のどれかが原因です。
症状 | 考えられる原因 | 対処 |
BTPへのデプロイが失敗する | Destinationの設定漏れ、またはMTAの設定誤り | Destinationとmta.yamlを確認して再デプロイする |
CRUDツールの呼び出しが失敗する | csrfProtectedフラグの誤り、またはエンティティセットの設定ミス | OData V2とRESTの違いに合わせてCSRFを設定し、エンティティセットを見直す |
認証エラーが出る | スコープとロールの不一致 | xs-security.jsonのスコープを、割り当てたロールに合わせる |
クライアントからツールが見つからない | トランスポートまたはエンドポイントの不一致 | トランスポート（stdioかStreamable HTTPか）とサーバーのエンドポイントを確認する |
MCPをデバッグするときは、エージェントのワークフロー全体を動かす前に、ツールを1つずつ単体で試してください。MCP連携のエラー対応の大半は、設定・認証・クライアント接続のどの層で失敗したのかを切り分ける作業です。
SAPのMCPはこれからどこへ向かう？
国内企業でのMCP導入が進むにつれて、現場で求められる内容も変わってきています。リアルタイムのデータアクセス、ガバナンスの強化、デプロイの簡素化は、多くの企業がこれから重視していくポイントになるでしょう。特に金融・製造業のように監査対応が求められる業種では、「どのエージェントがどのデータに触れたのか」を後から説明できる体制づくりが、導入の前提として問われる場面が増えていくと考えられます。
もう一つの大きな流れは、SAPと他のシステムを組み合わせた業務ワークフローへの広がりです。たとえば、受注確認はSAP、現場の承認申請はkintone、月次の予実管理はExcelというように、1つのタスクの中でエージェントが複数システムのツールを渡り歩く形です。こうしたワークフローが複雑になるほど、ツールの定義・権限・ガバナンスをシステムをまたいで一貫させる重要性は増していきます。今後の方向性については、2026年が企業向けMCP導入の節目になる理由（英語記事）も参考にしてください。
よくある質問
MCPとは何ですか？
MCP（Model Context Protocol）は、AIクライアントとSAPなどの業務システムを標準的な方法でつなぐプロトコルです。システムごとに個別の連携を作る代わりに、AIアプリケーションが「M」個、システムが「N」個あった場合の連携数を、M×N本からM+N本に減らせます。
SAPのMCPサーバーを作るのにカスタムコードは必要ですか？
必ずしも必要ありません。odata-mcp-proxyのようなプロキシランタイムを使えば、JSONの設定ファイルを書くだけで、エンティティセットごとのツールと操作が自動で生成されます。独自の業務ロジックを組み込みたい場合にだけ、カスタムコードを検討すれば十分です。
MCPとデータのレプリケーションやセマンティック検索は、どう使い分ければよいですか？
リアルタイムの照会や、状況に応じて動くAIエージェントのワークフローにはMCPが向いています。静的なデータ・バッチ処理・大量の索引を前提にした検索が中心なら、レプリケーションやセマンティック検索を選ぶ方が適しています。
自前で抱えずにSAPとAIをつなぐには？
ここまでの手順を、改めて振り返ってみてください。SAPのMCPサーバーを自前で構築すれば、細部まで自分たちで制御できます。その代わりに、開発・デプロイ・認証・セキュリティ・継続的な保守のすべてを、自分たちで背負い続けることになります。Destinationの設定・スコープとロールの設計・Cloud Connectorの運用・APIが変わるたびのCRUD再テストは、どれも一度で終わる作業ではありません。
そこまでの作り込みが必要ないなら、CData Connect AIというマネージド型の選択肢があります。Connect AIは、ChatGPT・Claude・CursorといったAIクライアントに、リモートMCPエンドポイントを提供します。このエンドポイント経由で、SAPのリアルタイムデータへ統制されたアクセスが可能になります。認証・権限・監査は一元管理されます。パススルー権限によるアイデンティティファーストのセキュリティにより、AIからのアクセスも利用者の権限の範囲に収まります。実際に、AI SaaSを手がけるテクノロジー企業の導入事例では、SAPを含む複数の基幹システムへの接続をMCPベースの標準インターフェースに統一したことで、データ統合にかかる期間を数か月単位から1週間未満へ短縮できています。
本記事で扱ったインフラの多くを自分たちで持たずに、SAPデータへの統制されたアクセスを実現できます。なお、AWSのAgentCore経由で提供されるSAP向けMCPサーバーのように、クラウドベンダー各社もマネージド型の選択肢を提供し始めています。CData Connect AIが差別化されるのは、SAPだけでなくkintoneやExcelといった国内でよく使われるSaaS・ファイルも、同じMCP層でまとめて扱える点です。オンプレミスのSAPについても、社内に置くエージェントからアウトバウンド通信だけでつなぐConnect Gatewayが用意されています。オンプレのPostgreSQLやSQL Server、SAPへの接続の仕組みは、Connect Gatewayの使い方で詳しく解説しています。
SAPのデータを安全にAIエージェントへつなぐ
SAPのMCPサーバーの構築・認証・保守を自前で抱える必要はありません。CData Connect AIなら、リモートMCPエンドポイント経由でSAPのリアルタイムデータをClaudeやChatGPTに届けられます。権限と監査も一元管理できます。
無料トライアルを始めて、まずは自社のSAP環境をAIクライアントにつなぎ、チームで使い勝手を確かめてみてください。
