SAP統合プラットフォーム：ツール、ライセンス、シナリオ

SAPをより広いシステムランドスケープに組み込む作業は、いくつかのピースがどうしても合わないパズルを解いているように感じられることがあります。さまざまなツール、プラットフォーム、データ形式が、それぞれ注目を集めようとします。連携の選択肢が多く、SAP Integration Suiteもその一つで、どれも自社こそ最適だと主張するため、圧倒されてしまうこともあります。プラットフォームの比較に何週間も費やした末に、ライセンスへの影響や負荷時のシステムのレイテンシといった基本的な点を見落としていたと気づくチームを、私は見てきました。

そこで、このページでは状況を整理します。完全にとは言えないかもしれませんが、自信を持って選べる程度には明確にします。SAPの連携プラットフォームを、実務の観点から見ていきます。見るのは次の点です。

実際にうまく組み合わさるツールはどれか
間接利用ライセンスで、どこにつまずきやすいか
SAP Integration Suite、CPI、PI、BTPは、実際にどう比べられるか
SAP純正よりもサードパーティ製ツールのほうが理にかなうのはいつか

すべてのプロジェクトに当てはまる唯一の答えはありません。ただ、ユースケースが固まれば、適切な連携の道筋は、たいてい見えてきます。少なくとも、そう願っています。

1. SAP Integration Suiteの概要

SAP導入が、SAPを立ち上げるだけで終わることはまずありません。多くの場合、SAPをそれ以外のあらゆるものと連携させる作業になります。レガシーシステム、クラウドアプリ、データベース、そして事業が長年頼ってきたあらゆる独自ツールです。

ここで連携が決定的に重要になります。連携は、ランドスケープ全体をつなぎとめることもあれば、何かが壊れるまで誰も気づかない摩擦を静かに生み出すこともあります。

実際には、連携は過小評価されがちです。チームは機能、プロセス設計、テストに集中します。プロジェクトの終盤になって、誰かが気づきます。

重要なデータがリアルタイムで同期されていない
APIの上限に、何週間も前に達していた
間接利用が原因で、ライセンスコストが倍増した
選んだミドルウェアが、負荷時の処理量に対応できない

こうしたことは、最初からはっきり見えるとは限りません。しかし最終的には、スケジュール、予算、さらにはコンプライアンスにまで影響します。

このページでは、その観点からSAP Integration Suiteを見ていきます。プロジェクトの現場で実際にどう動くのか、どんな問題を解決するのか、リスクがどこに潜みやすいのかです。

導入アセスメントを始める SAP連携

2. SAPプロジェクトでよくある連携シナリオ

SAPプロジェクトは、白紙の状態から始まることはあまりありません。既存のシステムが混在した状態から始まります。ドキュメントが整っているものもあれば、ほとんど理解されていないものもあります。連携は、その全体を整合させなければならず、しかも遅れる余裕があまりないことが少なくありません。

ほとんどのランドスケープに共通して現れるパターンがいくつかあります。

SAPと非SAPの接続。いまも使われているレガシーERP、CRM、自社開発のアプリ。
ハイブリッド構成。クラウドサービスとオンプレミスのシステムが混在し、同期を保とうとしている状態。
リアルタイムとバッチ。速いのは良いことですが、確実なほうが勝つことも多いです。
APIベースとミドルウェアベース。状況によっては両方を使います。

SAP Integration Suiteのようなツールは、特にハイブリッド環境やクラウド中心の環境で、こうしたパターンの多くを扱えるように設計されています。ただ、ツールそのものは解決策の一部にすぎません。

SAPを外部のプラットフォームとつなぐことは、形式、セキュリティ、タイミングが邪魔をするまでは、単純に聞こえることが少なくありません。小さな不一致のために何日も足止めされるチームを見てきました。一方はRESTで話し、もう一方はフラットファイルに固執します。

ハイブリッド構成は、最初は柔軟に見えることがあります。実際には、たいてい例外の寄せ集めの上に成り立っています。あるサービスはデータを即座に送り出します。別のサービスはいまも夜間ジョブに頼っています。

リアルタイム連携は、計画段階では誰にとっても魅力的に映ります。しかし、それが成り立つのは、両方のシステムが対応できる場合だけです。常にそうとは限りません。

ミドルウェアは構造を、APIはスピードをもたらします。どちらを選ぶかは、好みよりも、すでに何があるか、そしてチームが現実的に何を運用できるかで決まります。

検討すべきアプリケーション間連携のシナリオ

1. SAPと非SAPの連携

SAPは、SalesforceやOracle、業界特化型のツールなどのプラットフォームと接続する必要がよくあります。こうした連携が、重要な業務システムとプロセスの連続性を保ちます。

SAPとサードパーティ製プラットフォームの間で、構造化されたデータ交換を可能にする
認証、項目マッピング、変換レイヤーが関わる
SAP展開の間も、既存の業務ワークフローを維持するのに役立つ

2. ハイブリッドランドスケープ（オンプレミス / クラウド）

SAPのお客様の大半はハイブリッド環境で運用しています。オンプレミスのSAPシステムがクラウドプラットフォームと共存しているため、データの整合性と事業の俊敏性には連携が欠かせません。

SAP ECCまたはS/4HANAを、SuccessFactorsやAribaなどのクラウド製品とつなぐ
異なるプロトコルとセキュリティモデルを橋渡しする
レイテンシや同期の問題を避けるため、強力なガバナンスが必要

3. リアルタイム連携とバッチ連携

リアルタイム連携とバッチ連携のどちらを選ぶかは、システムの能力、データ量、業務上のニーズで決まります。すべてのプロセスが、即時のデータ同期から同じように恩恵を受けるわけではありません。

リアルタイムは、受注の作成や在庫の更新といったトランザクションに適している
バッチは、価格、マスタデータ、履歴の一括ロードなど、大量のデータセットに向いている
ほとんどのランドスケープでは、プロセスの重要度に応じて両方を使う

4. APIベースの連携

APIベースの連携では、アプリケーション同士が軽量なプロトコルで直接通信できます。クラウドネイティブなサービスや現代的な開発環境によく適しています。

SAPをモバイルアプリ、ポータル、マイクロサービスとつなぐのに最適
展開は速いが、厳格なバージョン管理とセキュリティ対応が必要
SAP API ManagementとODataサービスと組み合わせて使われることが多い

5. ミドルウェアベースの連携

ミドルウェアは、SAPを複数のシステムと連携させるための中央の管理ポイントを加えます。オーケストレーション、メッセージキューイング、データ変換を通じて、複雑さの管理に役立ちます。

複数のシステムがSAPとやり取りするランドスケープで使われる
一元的なモニタリングとエラー処理を提供する
例：SAP PI/PO、SAP Integration Suite、MuleSoft、Dell Boomi

6. 組み合わせ型のアプローチ

ほとんどの企業は、APIとミドルウェアの両方の戦略を組み合わせて使っています。このハイブリッドなモデルは、システム上の制約、チームのスキル、長期的なサポートの必要性に適応します。

直接的な連携方式とマネージドな連携方式を組み合わせる
将来の拡張やツールの変更に対する柔軟性をもたらす
連携を技術面と業務面の両方の優先事項に合わせるのに役立つ

3. SAP Integration Suiteの概要

SAPの連携では、適切なSAP Integration Suiteを選ぶことが、多くのチームが思う以上に重要です。この判断は、機能や速度にとどまりません。スケジュール、サポートモデル、さらにはライセンスにも影響します。連携が失敗したからではなく、プラットフォームが事業の動き方に合っていなかったために、プロジェクトが行き詰まった例を見てきました。

SAPは複数の連携オプションを提供しています。古いもの、新しいもの、そして思われている以上に重なり合うものがあります。どのツールを使うかをめぐって議論になることもよくあります。もちろん、状況によります。何をつなぐのか。データをどう動かす必要があるのか。チームが何を知っているのか。

すべてをカバーするツールはありません。どれにもトレードオフがあります。ただ、それぞれがどこに最も適しているかを理解すれば、全体像が見えてきます。

最も広く使われているSAPの連携プラットフォームを、SAPの売り込み方ではなく、実際のプロジェクトでどう使われているかに基づいて、手短に整理します。

SAPの連携プラットフォーム

1. SAP PI / PO（Process Integration / Orchestration）

PI/POは、長年にわたり、オンプレミスのSAP連携の標準でした。メッセージ変換、ワークフロー、各種プロトコル変換を扱います。信頼性は高い一方で、変化の激しい環境ではやや重く感じられます。それでも、複雑なバックエンドのロジックを扱う場面では、きちんと役目を果たします。

SAP間連携やレガシーとの連携に適している
IDoc、BAPI、RFC、SOAPなどをサポートする
ECCベースの環境やハイブリッド構成でよく使われる

2. SAP CPI / Integration Suite

SAP CPIは適応力が高く、クラウドファーストとハイブリッドのランドスケープ向けに設計されています。特にSAPに不慣れなチームにとって、始めやすいのが特徴です。構築済みのiFlowは役に立ちますが、本格的なカスタマイズにはやはり時間がかかります。新規のS/4HANAプロジェクトの大半では、これがたいてい標準の選択肢になります。

クラウドとハイブリッドの連携をサポートする
再利用できるコンテンツパッケージとアダプターを含む
SAP Integration Suiteのライセンスモデルの一部

3. SAP API Management

データの実際の移動よりも、ガバナンスに重きを置いたツールです。API Managementは、誰が、どの条件で、何にアクセスできるかを制御するのに役立ちます。配送車というより、正門のようなものだと考えてください。パートナーや社内の利用者にAPIを公開するときに便利です。

トラフィック制御、スロットリング、認証に使う
SAPのAPIを外部アプリに公開する際に役立つ
CPIやその他のバックエンドツールを補完することが多い

4. SAP BTP Integration Services

CPI、API Management、イベント処理などを含む、より広い傘のような位置づけです。ツールを管理する中心的な場所が得られますが、個々のツールは今もある程度独立して動作します。価値は、それらがまとめられ、ゆるやかに統合されている点にあります。

複数のSAP連携コンポーネントを組み合わせる
SAP BTPコックピットから一元的にアクセスできる
複数のツールが混在する連携ランドスケープで役立つ

5. SAP Data Intelligence

Data Intelligenceは、データをプラットフォームをまたいで構造化されたパイプラインで流す必要があるときに使います。トランザクションというより、分析寄りの用途です。日々のプロセスフローに含まれない、データレイク、機械学習ツール、その他の外部ソースとSAPをつなぎます。

プラットフォームをまたぐデータのオーケストレーションに焦点を当てる
分析や機械学習のスタックと統合される
高頻度のトランザクションではなく、データパイプラインに最適

6. 適切なツールの選び方

唯一の「最良」のプラットフォームはありません。適切なツールは、何を連携するのか、連携の規模、どれだけの柔軟性が必要かで決まります。チームがすでに使い慣れているものかどうか、という問題になることもあります。それも判断材料です。

ツールではなく、ユースケースから始める
ライセンス、スキルの確保しやすさ、サポートモデルを評価する
多くの場合、複数のツールが並行して使われる

SAPと連携するサードパーティ製の連携プラットフォーム

1. Dell Boomi

Dell Boomiは、ローコードのクラウド型プラットフォームで、迅速な展開と再利用できる連携を必要とする組織によく適しています。構築済みのコネクタでSAPに接続し、リアルタイムとバッチの両方のワークフローを効果的に処理します。

実装を早めるローコードのインターフェース
SAPを、クラウドアプリ、CRM、レガシーシステムとつなぐ
ハイブリッドのニーズを持つ中堅企業に適している

2. MuleSoft

MuleSoftは、SAPにとどまらない大規模な連携ニーズを持つ企業でよく使われます。API主導の接続性と、充実した開発者体験を提供します。SAPコネクタは強力ですが、うまく設定するには最初により多くの労力が必要になることがあります。

柔軟なサービス設計を可能にするAPIファーストのモデル
SAPを、より広いエンタープライズアーキテクチャに組み込む際に使われる
複雑なシステムや分散したシステムにより適している

3. Informatica

Informaticaは、データ負荷の高い環境で真価を発揮します。ETL、マスタデータ管理、分析を中心とした連携でよく選ばれます。SAPとの直接連携もサポートされていますが、ほかのプラットフォームに比べると、リアルタイム性への重点は通常、低めです。

大量のデータ移動とクレンジングに最適
レポーティングやMDMのユースケースで、SAPと組み合わされることが多い
成熟したBI環境を持つ組織に向いている

4. サードパーティ製プラットフォームを使う場面

特に複数のシステムが混在するランドスケープでは、SAP純正のツールが合わないこともあります。サードパーティ製のツールは、より良いコネクタ、よりシンプルなインターフェースを備えていたり、単に社内の既存の慣行に合っていたりするかもしれません。

チームがすでに外部のプラットフォームのトレーニングを受けているとき
SAPが、はるかに大きなアーキテクチャの一部にすぎないとき
リアルタイム、ローコード、または高度なデータ連携が必要なとき

5. ライセンスとコストの要因

ライセンスは、プラットフォームによって大きく異なります。SAPのツールは、既存のサブスクリプションに連携機能が含まれていることが多くあります。サードパーティ製のツールは柔軟性がある一方で、価格モデルは、取引量やユーザー数に応じて急速に膨らむことがあります。

トランザクション量とコネクタ数に基づいてコストを評価する
すでにライセンスを持つSAPの機能との重複に注意する
ライセンス料だけでなく、TCOを考慮する

6. 連携の保守とサポート

サードパーティ製のプラットフォームは、異なるサポートモデルを必要とすることがあります。ベンダーの手厚い支援があるものもあれば、社内のスキルに大きく依存するものもあります。初期の立ち上げ速度だけでなく、長期的な保守も判断に含めるべきです。

ベンダーのSLAとアップデートサイクルを確認する
社内の知見、または外部コンサルタントの必要性を織り込む
ガバナンス、バージョン管理、セキュリティアップデートを計画する

4. SAP Integration Suiteで適切なコンポーネントを選ぶ

完璧な連携ツールはありません。あるSAPプロジェクトでうまくいったものが、別のプロジェクトでは余計な負担を生むこともあります。SAP Integration Suiteで適切なコンポーネントを選べるかどうかは、取り組んでいるランドスケープと、連携にかかる負荷の種類で決まります。技術面、運用面、そして時には政治的な面の負荷です。

まず、いくつかの基準で候補を絞り込みます。

システムランドスケープ：関係するシステムはいくつか。すべてSAPか、クラウドと非SAPのツールが混在しているか。
レイテンシの要件：データは即時に動く必要があるか、遅延は許容できるか。
拡張性：新しいシステムは頻繁に追加されるか。標準化よりも柔軟性が重要か。
ボリューム：移動するのは1時間に数件か、1分あたり数万件か。

プラットフォームがさまざまなニーズにどう対応するかの、おおまかな見取り図です。

SAP間 - PI/POまたはCPI
クラウド間 - CPI、MuleSoft、Boomi
API管理 - SAP API Management、MuleSoft
大量のETL - Informatica、SAP Data Intelligence
複雑なオーケストレーション - PI/PO、MuleSoft、BTP Integration Services

5. Oracle、Microsoft、SalesforceとのSAP Integration Suite

現実のSAPランドスケープで、SAPが単独で動いていることはまれです。多くの環境には、Oracle、Microsoft、Salesforceのような、大規模で事業上重要なプラットフォームが含まれています。それぞれに固有の連携課題があります。技術的なもの、構造的なもの、そしてライセンスのグレーゾーンに入るものです。

1. SAP ↔ Oracle（ERP、HR、SCM）

SAPとOracleは、大規模な企業で共存していることがよくあります。一方が財務を、もう一方がサプライチェーンやHRを管理します。両者に確実にデータを共有させる作業は、特にデータモデルが想定以上に異なる場合、最初は進みが遅く感じられることがあります。

Oracleのテーブルは、APIやステージングレイヤー経由で公開する必要があることが多い
SAPは通常、IDocを送るかBAPIを使うため、変換が必要になる
タイミングが鍵：バッチ処理のウィンドウが同期の遅れを招くことがある
Oracleのアプリが自動的にSAPのプロセスを起動する場合、間接アクセスのリスクがよく生じる

2. SAP ↔ Microsoft（Azure、Power Platform、M365）

MicrosoftとSAPは、多くの人が思う以上に多くの場面で接点があります。Power BIがSAPからデータを取得する場合でも、Teamsがライブ状態のKPIを表示する場合でも、接続は増えています。ただし、連携には慎重な設定が必要です。スムーズな部分もあれば、そうでない部分もあります。

Azure Logic AppsはSAPのAPIを呼び出せるが、認証情報は慎重に管理する必要がある
Power Platformはコネクタを提供するが、複雑なフローにはカスタム関数が必要になることがある
Microsoft 365（Excelなど）は、SAPのデータをオフラインで編集し、後で同期し直すのによく使われる。この構成は、追跡していないと、知らぬ間にライセンスの問題を生むことがある

SAPとAzureの接続性は向上していますが、ハイブリッドのモデルでは今も強力な認証が必要です。特にオンプレミスのシステムが絡む場合はそうです。

3. SAP ↔ Salesforce（顧客データ、受注、サポート）

Salesforceは、ほぼ常に顧客と接する側のシステムです。SAPはバックエンドを担います。この二つをつなぐ作業は、たいてい、顧客レコード、受注ステータス、サービス履歴の同期です。

こうしたフローには、SAP CPIかMuleSoftがよく使われる
オブジェクトモデルが異なる：Salesforceのほうが柔軟で、SAPのほうが厳格
SalesforceのAPIレート制限が、大量データの同期を止めることがある
ライセンスを持つユーザーなしでSalesforceがSAPのトランザクションを起動すると、間接アクセスのライセンスリスクがある

こうした接続は、単純に見えることもあります。しかし、ボリュームが増えたり、プロジェクトの途中でプロセスが変わったりすると、複雑さが表に出てきます。こうした例外に早めに備えておく手間が、無駄になることはまずありません。

CPI連携

6. 間接利用ライセンスとは？

間接利用ライセンスが問題になるのは、SAP以外のシステムが、裏側でSAPとやり取りする場合です。誰もSAPに直接ログインしていないのに、業務プロセスはSAPに依存しています。よくある例が、SAPのユーザーが画面に一切触れないまま、SalesforceがSAPに受注を自動で作成するケースです。これも該当します。

SAPはこれを「間接アクセス」と呼びます。これは重要です。ユーザーがSAPをまったく目にしなくても、ライセンスの対象となる事象と見なされるからです。

これに対応するため、SAPはデジタルアクセスモデルを導入しました。焦点を、ユーザーから伝票に移すものです。

典型的なきっかけには、次のようなものがあります。

サードパーティ製のポータルが、SAPに受注を送り込む
モバイルアプリが、API経由で在庫レベルを確認する
ボットが、ログインせずに顧客データを更新する
CRMが、リアルタイムでSAPから価格を取得する

どこに線があるのかは、常に明確とは限りません。ただ、別のシステムに代わってSAPが何かを処理しているなら、確認する価値があります。

7. ライセンスとコンプライアンスの考慮事項（直接と間接）

SAPプロジェクトでは、ライセンスの問題は終盤に表面化しがちで、連携に関する判断がすでに下された後になることもあります。しかし、重要です。多くの人が思う以上に重要です。特に、サードパーティ製のシステムが、指名ユーザーなしでSAPを読み書きし始める場合はそうです。

核心の問題は、たいてい直接アクセスと間接アクセスの違いに行き着きます。直接アクセスは単純です。指名されたSAPユーザーがログインしてプロセスを起動し、その操作にライセンスが適用されます。一方、間接アクセスは、外部のシステム（Salesforce、独自開発のポータル、場合によってはボットも）がバックグラウンドでSAPとやり取りするときに生じます。それでも、SAPの規約上は利用と見なされることがあります。

これに対応するため、SAPはデジタルアクセスモデルを導入しました。ユーザー単位で課金する代わりに、間接アクセスで作成された特定の伝票タイプの件数を数えます。対象には、受注、請求書、在庫移動などが含まれます。紙の上では、より明確です。実際には、いまもグレーゾーンが残っています。

コンプライアンス上のリスクは、善意で作られた自動化から生じることがよくあります。たとえば、次のようなものです。

ユーザーログインなしでSAPから価格を取得するモバイルアプリ
SAPに顧客レコードを自動で作成するCRM
1時間ごとに在庫レベルを確認するスケジューリングツール

これらはどれも便利です。しかし、適切に追跡して報告していないと、ライセンス上のリスクにさらされる可能性があります。

コストを管理する方法はあります。SAPは、伝票ベースのライセンスへ移行する企業向けに、Digital Access Adoption Program（DAAP）のインセンティブを用意しています。リスクがどこにあるかを追跡するために、利用状況のモニタリングツール（SAP Passportや外部のログ取得ツール）を導入している企業もあります。

監査は、また別の話です。技術的なものも、商業的なものも、その両方もあります。予測しやすい監査もあれば、そうでないものもあります。いずれにしても、先手を打っておくほうが、不意を突かれるよりも費用が少なくて済む傾向があります。

1. SalesforceがSAPで受注を作成する

営業担当者がSalesforceに案件を入力すると、Salesforceが受注データをSAPに自動で送ります。SAPのユーザーはログインしませんが、バックエンドで伝票が作成されます。

問題点： 受注が間接アクセスで生成されており、SAPのデジタルライセンスの対象になる。
対策： SAPのデジタルアクセスモデルを使ってこれらを伝票として数えるか、指名されたSAPユーザーのワークフロー経由で起動する形に作り直す。

2. 独自開発のポータルがSAPから価格を読み取る

一般向けまたはパートナー向けのWebポータルが、API経由でSAPから取得したリアルタイムの価格を表示します。SAPの認証は使われていません。

問題点： 価格データへのアクセスが指名ユーザーを迂回しており、追跡できない状態でSAPのバックエンドが公開されている。
対策： SAP API Management経由にアクセスを集約し、適切なユーザー認証またはクォータ制御を適用する。

3. モバイルアプリが在庫の有無を確認する

倉庫のチームは、SAPに直接ログインせずに、SAPの最新の在庫を照会するモバイルアプリを使っています。

問題点： データには間接的にアクセスしており、ボリュームや頻度によっては、ライセンス上の責任が生じる可能性がある。
対策： モバイルユーザーにライセンスを付与するか、アクセスが伝票ベースのライセンスのしきい値に収まるようにする。

4. Eコマースプラットフォームが請求書を作成する

オンラインでの購入が、SAPへの請求書の自動転記につながります。プロセスは完全にシステム間で完結し、SAPのユーザーは関与しません。

問題点： 間接的に行う場合、請求書の作成はSAPのデジタルアクセスモデルのもとでライセンスの対象となる事象である。
対策： 請求伝票をデジタルアクセスのライセンス数に含め、ボリュームの推移を監視する。

5. HRシステムが従業員データをSAPに書き込む

サードパーティ製のHRソフトウェアが従業員のマスタデータを管理し、バッチジョブでSAP HCMを更新します。

問題点： ライセンスを持つSAPユーザーなしでマスタデータを作成することは、データの処理方法によっては規約違反になる可能性がある。
対策： これらがライセンス対象の伝票と見なされるかをSAPに確認し、利用状況の追跡を導入するか、指名ユーザー経由で処理する。

6. BIツールがSAPから定期的にレポートを取得する

Power BIやTableauのようなレポーティングプラットフォームが、スケジュールに従ってODataまたはJDBC経由でSAPのテーブルに接続し、データを静かに取得します。

問題点： 認証されていない場合や、ユーザーにライセンスがない場合、頻繁なデータ抽出はアクセスポリシーに違反する可能性がある。
対策： 承認されたレポーティング用ユーザー経由にアクセスを集約するか、ライセンスを適切に追跡するSAP認定のアナリティクスコネクタを使う。

8. 私にできること

SAPとデジタルトランスフォーメーションに25年携わり、キックオフから本稼働までのプロジェクトも、誰も語らない混沌とした中盤も見てきました。最初から指揮を執ることもあります。状況が思わぬ方向に傾いたときに、立て直しのために呼ばれることもあります。

どちらの場合も、私の役割は同じです。事業が本当に必要とするものと、システムが実際に提供できるものを結びつけることです。専門用語は使いません。水増しもしません。ここにあるのは理論ではありません。現場で何年も、実際のプレッシャーのもとで実際の問題を解決してきた経験から形づくられたものです。

要件の収集

9. 連携のベストプラクティス

プロジェクトの初期には、連携とは、たいてい動かすことを意味します。データを一つのシステムから別のシステムへ移し、いくつか項目にチェックを入れて、次へ進みます。しかし、本当の難しさは後で現れます。何かが静かに壊れたとき、あるいは、そもそもインターフェースがどう設定されたのかを誰も覚えていないときです。

ベストプラクティスとは、硬直した標準に従うことではありません。避けられるリスクを減らすことです。より強力な認証を使うことや、規模が大きくなる前にモニタリングを整えることを意味する場合もあります。ときには、その時点で必要と感じる以上にドキュメントを残す、というだけのこともあります。

長期にわたって連携を健全に保つのに役立つことがいくつかあります。

OAuth2、SAML、X.509などの安全なプロトコルを使う
フローが単純に見えても、モニタリングを設定する
再利用や拡張ができるiFlowやAPIを作る
仕組みと、障害時の対処をドキュメント化する

これらの対応が急を要することはまれです。しかし後になって、何時間も節約できます。ときには何日分にもなります。

1. すべての連携ポイントを保護する

セキュリティへの対応は後回しになりがちで、たいてい本稼働の直前になります。しかし、その時期が最も修正しにくいのです。シナリオに応じて、OAuth2、SAML、または証明書を使います。静的な認証情報を使う場合は、きちんと記録してローテーションします。設定ファイルに置いたまま、誰も忘れないことを期待してはいけません。

外部だけでなく、エンドツーエンドで暗号化を使う
データのリスクに応じて認証プロトコルを選ぶ
トークンの有効期限と更新を早い段階でテストする

2. 最初からモニタリングする

モニタリングは、インシデントが起きた後に追加されることがよくあります。しかし最も効果を発揮するのは、何かが壊れる前からそこにあるときです。最小限のログでも役に立ちます。大事なのは派手なダッシュボードではなく、何が、いつ、なぜ失敗したのかを把握することです。それがなければ、小さな問題でも原因の追跡に何時間もかかることがあります。

失敗とタイムアウトのアラートを設定する
応答時間とリトライ回数を記録する
利用できる場合は、既存のSAPのモニタリングを使う

3. 目先ではなく再利用を前提に設計する

目の前の問題を、ハードコードした手早い修正で片づけたくなる気持ちは分かります。しかし、場当たり的な対応は、後で必ず摩擦を生みます。再利用できるiFlow、共通の変換ロジック、パラメータ化した入力は、プロセスが変化するときに時間を節約します。プロセスは、ほとんど必ず変化します。

可能な限りテンプレートを使う
マッピングのステップにビジネスルールを入れない
ロジックとトランスポートレイヤーを分離する

4. 運用を意識してドキュメント化する

ドキュメントは、設計フェーズで止まりがちです。しかし、サポートチームに必要なのは図だけではありません。エンドポイントが止まったとき、あるいは項目が欠けているときに何が起きるのかを知る必要があります。優れたドキュメントは、チケットが起票される前に、そうした疑問に答えています。

リトライのロジック、障害時の処理、バージョン情報を含める
上流と下流のシステムについての前提を記述する
フローが変わるたびにドキュメントを更新し続ける

5. 責任者を明確にする

誰も担当していないことに誰かが気づくまで、何か月も動き続ける連携があります。それが失敗したとき、誰もが、他の誰かが見ているはずだと思い込んでいます。これは避けてください。責任者を決めます。非公式でも構いません。この一手が、ほとんどの技術的な対策よりもダウンタイムを減らします。

フローやインターフェースごとに、責任の所在を定める
責任者がログとツールにアクセスできるようにする
責任者を、オンボーディングと引き継ぎのドキュメントに含める

6. 稼働開始だけでなく、変化を前提に作る

インターフェースは固定されたものではありません。項目は変わります。APIはバージョンが上がります。ボリュームは増えます。フローが硬直しすぎていると、小さな変更でも壊れます。今は要件が安定して見えても、最初から調整を見込んで計画してください。

マッピングと設定にバージョン管理を使う
既知の制限と制約を明確に文書化する
リリースサイクルの中で連携フローをレビューする

10. 総コストとROIの考慮事項

連携プロジェクトは、技術的な目標から始まることがよくあります。システムをつなぎ、データを同期し、動かすことです。しかし、その下では、コストが多くの人が思う以上に大きな役割を果たしています。最初のライセンス費用だけではなく、後から表れる種類のコストです。ワークロードが拡大するとき、要件が変わるとき、あるいは回避策が恒久化したときです。

SAP CPIのようなクラウドツールは、初期のうちはコスト効率が高く見えるかもしれません。ハードウェアは不要で、構築も早く済みます。しかし、従量課金のため、ボリュームに応じてコストが上がる可能性があります。PI/POのようなオンプレミスの選択肢は、価格は安定していますが、インフラの負担がついてきます。

さらに、サードパーティ製のプラットフォームがあります。それぞれ独自のライセンスモデルを持ち、ユーザー単位で課金するものもあれば、トランザクションやコネクタ単位のものもあります。積み重なっていきます。

ですから、ROIの観点から連携を見るということは、「今いくらかかるか」を問うだけでは足りません。先を見ることです。これはどう拡大していくのか。そして、変更が必要になったとき、誰が費用を負担するのか。

1. クラウドとオンプレミスのコスト

SAP CPIのようなクラウドプラットフォームは、構築が早く、インフラコストも低く抑えられますが、価格は利用量に応じて増えることが多くあります。PI/POのようなオンプレミスのツールは、先行投資がより多く必要ですが、特にハードウェアがすでにある場合は、長期的なコストの安定性が得られることがあります。

クラウド：サブスクリプション型で、メッセージ単位または接続単位であることが多い
オンプレミス：CAPEXの比重が大きく、継続的なライセンス費用は低い
価格は、システムのボリュームとITの規模によって決まる

2. SAP CPIのライセンスによる影響

SAP CPIは、段階制の従量課金モデルを採用しています。メッセージ量とスループットに基づいて課金されます。低から中程度のシナリオでは予測しやすいのですが、トラフィックが多い場合や最適化されていないフローでは、コストが急激に増えることがあります。

開始時の段階は、通常、月額1,000ユーロから2,000ユーロ程度から始まる
大量のメッセージや標準外のアダプターには追加料金がかかる
コストを先手で管理するため、月ごとに利用状況を追跡する

3. サードパーティ製ミドルウェアの価格

MuleSoft、Dell Boomi、Informaticaは、コネクタ単位、ユーザー単位、トランザクション単位など、さまざまな価格モデルを採用しています。基本価格は手頃に見えるかもしれませんが、規模を拡大すると、新たな料金の発生につながる上限に突き当たることが少なくありません。

MuleSoft：ライセンス＋APIボリューム＋コアパック（年間約18,000ドル以上）
Boomi：連携プロセス、コネクタ、またはユーザーの段階ごと
Informatica：ETLのボリュームとプラットフォームサービスによってコストが決まる

4. 時間の経過とともに生じる変更コスト

初期の構築コストは、全体の一部にすぎません。変更（新しいエンドポイント、更新されたマッピング、業務ルールの変更）は、特に硬直した環境では、追加のライセンス費用や開発費用を招くことがあります。

複雑なランドスケープでは、年間15～30%の変更コストを見込む
よりモジュール化されたプラットフォームは、変更時の摩擦を減らす傾向がある
カスタマイズには、ライセンスの拡張やコンサルティングが必要になることがある

5. サポートと保守のコスト

サポートは、コストの見積もりで見落とされがちです。SAP CPIには基本的なサポートの段階が含まれていますが、応答時間とSLAは異なります。サードパーティ製のツールは、より迅速なサポートを提供するかもしれませんが、その分の費用がかかるか、追加のサービス契約が必要になります。

SAPのサポートは、既存のエンタープライズ契約に紐づく
サードパーティ製のツールは、サポートとして年間でライセンス料の15～20%を請求することがある
システムが複雑になるほど、社内のサポート需要も増える可能性がある

6. 構築後を含めたROIの評価

本当のROIには、導入時だけでなく、時間の経過にわたる保有コストが含まれます。安価なプラットフォームは柔軟性に欠けるかもしれませんが、高価なツールは、後でダウンタイムや変更の手間を減らしてくれるかもしれません。稼働開始時点だけでなく、ライフサイクル全体で評価してください。

ライセンス、保守、サポート、変更のコストの合計を織り込む
ROIは、プロジェクトのフェーズだけでなく、2～3年の期間で見積もる
失敗した連携や遅延した連携のコストを、潜在的なリスクとして含める

よくあるご質問

お客様の多くは、SAP導入を初めて検討するとき、同じような疑問の周りを行き来します。

ご自身にも、いくつか思い当たるかもしれません。実際にどれくらい時間がかかるのか、いくらかかりそうか、システムが本稼働した後にどんなサポートが必要か。もっともな疑問です。

そこで、推測に任せるのではなく、明快で率直な回答をまとめました。何が見込めるのか、厄介な部分がたいていどこに現れるのかを、より掴みやすくするためです。

まずはご連絡ください

1. SAP CPIとは何ですか？

SAP CPI、つまりCloud Platform Integrationは、SAP Integration Suiteの一部です。主にクラウド環境やハイブリッド環境で、SAPと非SAPのシステムをつなぐ役割を担います。ミドルウェアだと考えてください。ただし、分散したランドスケープ向けに作られています。

次のものが含まれます。