[SAPUI5] 安定稼働を実現する！バージョンアップ対応方針の策定

この記事をSNSでシェア!

2026年5月29日

はじめに

株式会社ＫＹＯＳＯでは、SAP BTP（Business Technology Platform）上でのSAP Fioriアプリケーション開発や、お客様のシステムの安定運用を支える技術支援を幅広く行っています。

SAP Fioriアプリケーションの”SAPUI5”は、HTML5ベースのUIフレームワークであり、現在のSAPエコシステムにおけるUX（ユーザーエクスペリエンス）の中心を担っています。しかし、SAPUI5の各バージョンには「保守期間」が設定されており、この管理を怠ると「ある日突然、アプリケーションが動かなくなる」という深刻なリスクを招くことがあります。

本記事では、SAPUI5のバージョンの仕組みから、安全にアップデートを完了させるための標準作業フローまで、最新の情報を交えて詳しく解説します。

SAPUI5バージョンの基本構造と「保守期限」の重要性

まず、SAPUI5のバージョンがどのように構成されているかを正しく理解することが、運用設計の第一歩です。

バージョン番号の構成

SAPUI5のバージョンは、[メジャー].[マイナー].[パッチ] という3つのセグメントで管理されています。

メジャーバージョン：アーキテクチャの根本的な変更を伴う更新です。
＊2026年5月現在、「1」のみであるため、本記事ではバージョンアップ対応の考慮対象外とします。
マイナーバージョン：機能追加が行われるバージョンです。定期的に**長期保守バージョン（Long Term Maintenance Version）**が設定されます。
パッチバージョン：原則として機能追加は含まれず、バグ修正や脆弱性対応（セキュリティパッチ）が目的です。

「End of Cloud Provisioning (EoCP)」のリスク

SAP BTP上でUI5アプリを稼働させる場合、通常は**CDN（Content Delivery Network）**経由でライブラリを取得します。

ここで最も重要な概念が、End of Cloud Provisioning (EoCP) です。保守期限が終了し、このEoCPに達したバージョンはCDNから削除されます。

CDNから削除されるとどうなるか

該当バージョンを指定しているアプリケーションは、ライブラリの読み込みに失敗し、

その瞬間にすべてのアプリケーションが起動不可能になります。古いパッチバージョンも順次整理の対象となるため、細心の注意が必要です。

UI5バージョンを保守切れの状態のまま放置すると、該当UI5バージョンがCDNから削除され、それと同時にそのバージョンをご利用のUI5アプリケーションがすべて動かなくなります。

お使いのバージョンが現在どのような保守ステータスにあるかは、以下のSAP公式サイトで確認が可能です。

SAPUI5 Version Overview（公式サイト）https://ui5.sap.com/versionoverview.html

バージョン指定方針の比較検討：どちらを選択すべきか？

パッチに対するバージョンアップを検討する際、manifest.json等で「どの粒度まで指定するか」によって、その後の運用スタイルが大きく変わります。「マイナー指定」と「パッチ指定」のメリット・デメリットを比較し、プロジェクトに最適な判断を行う必要があります。

比較項目	マイナー指定（例: 1.XX）	パッチ指定（例: 1.XX.YY）
セキュリティ	◎ 常に最新最新パッチが自動適用されるため、脆弱性対応が早い。	△ 手動依存手動で更新しない限り、古いパッチの脆弱性が残る。
挙動の安全性	〇良好パッチ更新はバグ修正が主だが、稀にUIに影響が出るリスク。	◎ 完璧完全に固定されるため、テスト済みの挙動を100%維持できる。
サイクル	◎ 長期マイナーの保守終了まで長期間利用可能。	× 短期パッチごとのEoCPは約１年。
テスト・作業負荷	◎ 低負荷マイナーのバージョンアップを行う場合は調査、修正、テストを行う必要があるが、パッチに対しては自動更新のため低負荷。	× 高負荷 EoCPに向けた調査、修正、テストが定期的に必要。

判断のポイント：安定性か、運用コストか

どちらの指定方法を採用するかは、システムの性質によって判断が分かれます。

「マイナー指定」が適しているケース：バージョンアップ対応の運用コストを最小限に抑えたい場合や、常に最新のセキュリティ状態を維持することを優先する場合に適しています。
「パッチ指定」が適しているケース：ミッションクリティカルな業務システムなど、わずかな表示崩れや挙動の変化も許容できず、自社のテストサイクルで安全性を完全にコントロールしたい場合に適しています。

パッチレベルでの指定（固定）を行っている場合、そのパッチの提供終了予定日（EoCP）を常に意識しなければなりません。期限が迫っている場合は、パッチ指定を継続してのバージョンアップ対応にて安全性を取るか、あるいは運用負荷軽減のためにマイナー指定へ切り替えるか、プロジェクトの状況に応じた意思決定が必要です。

バージョンアップの標準作業フロー

いずれの指定方法を選択する場合でも、新しいバージョンへの移行時には以下の4つのフェーズで進めることを標準化しています。

① 計画・調査フェーズ

Version Overviewを確認し、ターゲットとなるバージョンを選定します。同時にリリースノートを確認し、利用中のライブラリ（sap.m等）で更新や変更がないか変化点分析を行います。

② 修正フェーズ

manifest.json の minUI5Version を書き換えます。また、利用している各ライブラリを最新の推奨バージョンへ調整する等の修正を実施します。

③ 検証フェーズ（検証環境）

検証環境へデプロイし、変化点分析で抽出したライブラリの影響箇所や、主要な業務シナリオを中心に動作確認（回帰テスト）を行います。問題が発生した場合修正を行います。

④ 本番適用フェーズ

テスト完了後、本番環境へ適用し、最終的な疎通確認を行って作業完了となります。

設定の具体例

manifest.json でバージョンを記述する際の記述例です。

{
 "sap.ui5": {
    "dependencies": {
      "minUI5Version": "1.XX.YY",
      "libs": {
        "sap.m": {},
        "sap.ui.core": {},
        "sap.ushell": {}
      }
    }
  }
}

最後に

SAPUI5のバージョン管理について、解説いたしました。

前述した通り、パッチ固定のまま放置することは、EoCP（CDNからの削除）による「ある日突然のシステム全停止」という致命的なリスクを抱え込むことになります。

「自動更新で手間を省くのか」「手間をかけてでも絶対的な安定を維持するのか」それぞれのメリット・デメリットを理解し、ビジネス要件に合わせた方針を策定することが重要です。

実際のプロジェクトでも、まずは「パッチ固定」の状態で安全性を最優先したバージョンアップを確実に完了させ、その後に運用の安定性やコスト（上記比較表の項目）を改めて天秤にかけ、次のフェーズで「マイナー指定」へと切り替えるか否かを判断する、というステップを踏んだ事例があります。

本記事が、皆様のシステムの安定稼働に向けた検討の一助となれば幸いです。
最後までお読みいただきありがとうございました。

投稿者プロフィール

増田駿也: 2021年入社、BS事業部所属。

現在はSAP BTP上でのSide-by-Side拡張開発に携わっており、SAP Fioriを活用した開発案件を担当しています。

社内のアプリケーションの開発基盤標準化や、社外活動の参加にも積極的に関わり、ナレッジの共有を通じてチーム全体のスキル向上にも貢献したいと考えています。

ブログ