JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 16, 2026 · 17 min read

SAP IBP 計画バージョン

バージョン — 一般的に計画バージョンと呼ばれ、SAP IBPのUIおよび本記事では単に「バージョン」と表記されます — は、アクティブ化された計画エリアのデータの完全で独立して保存されたコピーまたはスナップショットです。これはフィルター、ビュー、または共有された数値セットへのライブポインタではなく、明示的に作成（コピー）され、ソースの後続の変更を反映するために明示的に再コピーされなければならない、真に独立したデータインスタンスです。単一の計画エリア（IBP-A03-03）には、通常、ベースライン、ワーキング、シミュレーション、コンセンサスといった複数のバージョンが並行して保持されます。本記事では、読者が計画エリアとは何か、およびそのアクティブ化方法（IBP-A03-03参照）をすでに理解していることを前提とし、バージョンオブジェクト自体 — 4つのバージョンタイプ、すべてのコンサルタントが質問されるバージョンとシナリオの違い、バージョン固有データとバージョン非依存データ、そしてバージョンの作成、コピー、削除方法 — について深く掘り下げます。

第1部: バージョン — 基本概念（全モジュール共通）#

1.1 バージョンとは#

バージョンは、作成されるまで独自のデータを持ちません。作成時または最終コピー時点で固定された、ソースとなる計画エリアのデータ（設定に応じてマスタデータおよび/またはキーフィギュア値）の完全なコピーです。バージョンは計画エリアの下位依存オブジェクトであり、同等の設定オブジェクトではありません。バージョンを作成するには、事前に計画エリアが存在し、有効化されている必要があります。

1.2 4つのバージョンタイプ#

4つのバージョンタイプは、技術的に異なる4つのメカニズムではありません。すべてのバージョンは、内部的には同じ方法で構築およびコピーされます。これらはプロセス主導の類型であり、組織が計画サイクルのさまざまな段階で同一のバージョンメカニズムをどのように適用するかに関する命名規則と使用規則です。この類型を正しく理解することは重要です。なぜなら、誰がどのバージョンを編集するのか、また、どの時点でバージョンの数値を「公式」として扱ってよいのかという期待値を設定するからです。

設計原則: これら4つの名称は慣例であり、強制される技術的なカテゴリではありません。顧客が他の目的のために他の名称で追加のバージョンを作成することを妨げるものはありません。内部ソースのNotes行にある注意書き（「計画エリアを実際のデータで稼働させた後、有機的に成長させるものではなく、稼働前にバージョン戦略を策定すること」）が存在するのは、まさにこの命名/目的の設計が意図的な事前決定であり、計画エリアが実際のデータで稼働した後に有機的に成長させるものではないからです。

1.3 組織レベルとデータ階層#

具体的な例を用いたデータ階層

Client (SAP IBP Tenant)
   │
   └── Planning Area "PA-DP01" — Demand Planning Planning Area          (IBP-A03-03)
          │
          ├── Key Figure "KF-DEMAND" — Demand Quantity                    (IBP-A03-01)
          │
          ├── Planning Level "PL-PROD-LOC" — Product x Location            (IBP-A03-02)
          │
          ├── Version "VER-BASELINE" — Approved plan (baseline)            [this article's object]
          │
          └── Planning View "PV-DP-WEEKLY" — Weekly Demand Planning View   (IBP-A03-05)

設計原則: すべてのバージョンは、キーフィギュアや計画レベルと同様に、同一の有効化された計画エリアに独立した兄弟コピーとして直接ぶら下がります（1:N）。いずれも他のバージョンの中にネストされることはなく、データモデルレベルで他のバージョンのバリアントとなる「本当のもの」も存在しません（ベースラインは、構造的に特権的なバージョンではなく、慣習上の真実のソースに過ぎません）。ランドスケープのゾーンCは、代表的なバージョンインスタンスとしてVER-BASELINEのみを示しています。4つのバージョンタイプ（ベースライン、ワーキング、シミュレーション、コンセンサス）とアドホックなシナリオの概念については、ここに示す組織階層上の位置ではなく、この記事の後半セクション（2.1-2.2）で説明します。

1.4 他のマスタデータオブジェクトとの統合#

バージョンは単独では存在しません。これは、計画エリアがすでに有効化されているためにのみ存在し、プランナーが実際に操作するすべてのもの（計画ビュー、シナリオ）は、特定のバージョンの上に構築されています。

パート 2: IBP固有のフィールド詳細#

2.0 IBPオーナーシップの範囲#

凡例: ◎ = 所有者 / 重要

2.1 バージョン設定#

以下は、内部ナレッジベースのバージョン設定テーブルに表示される4つの設定です。これらは、Manage Versions and Scenarios（バージョンとシナリオの管理）アプリ内でバージョンが作成されるときに設定されます。

Notes-row caveat (内部ソース): 「本稼働前にバージョン戦略を策定すること。」バージョン設計（バージョン数、各バージョンの意味、誰がどのバージョンに書き込めるか）は、事前に慎重に計画すべき事項です。計画エリアが本稼働しデータが蓄積された後にバージョン構造を後付けで変更する（特にバージョン固有マスタデータ、セクション2.3を有効にする）ことは、文書化された現実的なリスクを伴います。

2.2 バージョン vs. シナリオ#

この区別は内部ナレッジベースではまったく扱われていませんが、公開されているSAP IBPのドキュメントやコミュニティの議論において、このオブジェクトに関する最もよく聞かれ、実務的に関連性の高い質問の1つです。コンサルタントは常にこれについて質問されるでしょう。バージョンとシナリオはどちらも「what-if」目的に使用できますが、アーキテクチャ的にはまったく異なるメカニズムです。

要約: バージョンは、管理者が管理する、コピーベースの長期計画であり、重厚です。シナリオは、ユーザーが作成する、デルタベースの短期の仮定分析であり、軽量で、バージョンの上に重ねられます。どちらも「what-if」分析に使用できますが、シミュレーションタイプのバージョンとアドホックなシナリオは同じメカニズムではなく、お客様にこのオブジェクトの範囲を説明したり説明したりする際に混同すべきではありません。

2.3 バージョン固有マスタデータ (VSMD)#

デフォルトでは、マスタデータはバージョン非依存です。つまり、計画エリアのすべてのバージョンが同じ製品、ロケーション、顧客マスタ（および属性）を共有します。一方、キーフィギュア（トランザクション/計画）データは、設計上、本質的にバージョン固有です。これは、複数のバージョンを持つことの目的そのものであり、各バージョンが独自のキーフィギュア値を保持するためです。VSMDは、このデフォルトのマスタデータ側を変更するオプション設定であり、ここではデフォルトの動作ではなく、注意が必要な高度なオプションとして提示されています。

2.4 コピー・削除操作#

SAP IBPにおけるバージョンデータの重要な操作は、即時実行可能なワンクリックUIアクションではなく、監査可能でスケジュール可能な計画オペレータジョブとして実装されています。今回のセッションでは、バージョンに対して明確に「マージ」と名付けられた機能を文書化した公開ソースは見つかりませんでした。一般的に2つのバージョンのデータを「マージする」と呼ばれる操作は、実際には、複数のソースコピーを1つのターゲットバージョンに重ね合わせて実行するコピーオペレータとして理解するのが適切です。

前提条件: 3つのオペレータ（コピーオペレータ、コピーバージョンオペレータ、削除バージョンオペレータ）はすべて計画オペレータジョブとして実行されます。完全な実行メカニズム（スケジューリング、モニタリング、ジョブチェーン）については、IBP-A05-01（計画オペレータ、フェーズ4）で説明されています。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction