JinJin48

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

July 19, 2026 · 19 min read

SAP Service Cloud インストールベース

SAP Service Cloud におけるインストールベースとは、「顧客の拠点に設置されたアイテムの階層的な配置」です。これは、ワークリストから手動で作成されるコンテナレコードであり、他のオブジェクトが直接、または相互に接続してアタッチされます。インストールベース自体のフィールドテンプレートには、親ポインタフィールドや保証フィールドは一切含まれていません。この特性は、機能場所、製品設置ポイント、および登録製品に存在する確認済みのParent Installed Base UUIDフィールドと組み合わさることで、インストールベースを固定された2分岐モデルの中間点ではなく、柔軟な多階層ツリーのルートにしています。また、保証とは異なり、インストールベースは、専用の「ケースインストールベース」サブエンティティを介して、ケースから直接かつファーストクラスの参照を持つ4つのオブジェクトタイプの1つです。この記事では、その構造を正確にマッピングし、インストールベース作成時に入力される顧客およびパーティロールフィールドをカバーし、命名の衝突やドキュメンテーションのギャップが、インストールベースを使用した構築方法を変更すべき箇所を指摘します。

パート 1: インストールベース — 中核概念（全モジュール共通）#

1.1) インストールベースとは#

インストールベースは、「この顧客にはどの製品と拠点が属し、それらはどのように階層的に構成されているか」という1つの問いに答えるために存在します。SAP Service Cloudはこれをコンテナレコード（インストールベース）で実現します。このレコードは、他の明細レベルのオブジェクトが直接、または相互に接続されるための基点であり、自身が他の何かに接続しに行くレコードではありません。機能範囲説明書によれば、インストールベースは「顧客別または製品別」のどちらの方向からも表示可能であり、これは特定の顧客の拠点に実際に設置されている製品を保持するあらゆる明細の集約ポイントとして機能することと一致しています。

名称の衝突 — “インストールベース” は、SAPポートフォリオ内の他の場所で少なくとも2つの無関係なものを意味します。 このオブジェクトは、以下のものと名前以外に共通点はありません。(1) SAP S/4HANA（オンプレミス）および従来のECC「インストールベース管理（CS-IB）」 — これはプラント保全/カスタマーサービスのアプリケーションコンポーネント（テーブル IBIB）であり、設備、機能場所、シリアル番号付き品目をツリー制御の保守画面で共通のインストールベースにグループ化します。その際、「設備、機能場所、またはシリアル番号付き品目は、同時に1つのインストールベースにのみ存在できる」という厳格な制約があります。このオンプレミスオブジェクトは、従来の SAP CRM サービス（WebClient、IB5x 範囲のトランザクション）とも歴史的に共有されています。そして (2) SAP Field Service Management 独自の「アセット/インストールベース」概念。これは、サービスオーダーのスケジューリング/ディスパッチコンテキストのために、独自のクラウドデータモデルとREST APIで管理されています。これらは両方とも、用語は共通ですが、SAP Service Cloud Version 2のインストールベースオブジェクトとはアーキテクチャ的に異なる製品です。衝突ではありません: チケットベースの前身製品である SAP Cloud for Customer (C4C) には、ここで調査されたものと機能的に同じインストールベースの概念があります。これは、SAPのケース/チケットベースのクラウドサービス世代（C4C → SAP Sales and Service Cloud → SAP Service Cloud Version 2）をまたがる直接的な製品系統であり、別の同名の概念ではありません。

1.2) 顧客タイプとパーティロールのバリエーション#

作成時、管理者は「顧客のタイプ」のみを、説明、取引先、連絡先とともに選択します。しかし、完全なフィールドテンプレートでは、5つの異なるパーティロールスロットが公開されており、各スロットは独立して法人取引先または個人顧客を指すことができます。間違ったロールが設定されたり（ビジネスで実際に必要なロールが未設定のままになったり）すると、請求書が誤ったエンティティにルーティングされたり、フィールドサービスの訪問が誤ったサイト連絡先に対してスケジュールされたりします。

設計原則: インストールベース作成時に入力されたプライマリ取引先または個人顧客は、自動的に支払元、請求先、出荷先にはなりません。これらの各ロール（所有者を含む）は、同じレコード上で個別に入力されるフィールドペアであり、基本となる取引先/コンタクトのペアのみが必須です。

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

データ階層の具体例（テナントレベル；SAP Service Cloudには、この上位に会社コード/プラントのスコープ設定はありません）

Client (SAP Service Cloud Tenant)
   │
   └── Account "ACC-77410 — Acme Manufacturing K.K." (base customer party role)
          │
          └── Installed Base "IB-40210 — Acme Mfg, Yokohama Plant, Packaging Line 2"
                 │        (ROOT — its own field template carries no Parent-* field
                 │         and no Warranty field; it is never the referencing/child
                 │         side of any relationship)
                 │
                 ├── Functional Location "FL-8801 — Packaging Robot Cell"
                 │        (Parent Installed Base UUID = IB-40210)
                 │        │
                 │        └── Product Installation Point "PIP-3305 — Motor Drive Unit"
                 │                 (Parent Installation Point UUID = FL-8801 — illustrates
                 │                  that an Installation Point can nest under a Functional
                 │                  Location instead of directly under Installed Base)
                 │
                 └── Registered Product "RP-90215 — Serial# CNV-2024-118"
                          (Parent Installed Base UUID = IB-40210 — attached directly,
                           the other supported nesting pattern)

Case "CS-500311 — Conveyor motor overheating, packaging line down"
     ── references ──> Installed Base "IB-40210"
          (direct field-level link via the "Case Installed Bases" subentity —
           Installed Base ID field)

設計原則 — インストールベースは、固定された2階層モデルの1つの枝ではなく、柔軟なツリー構造の唯一のルートである。 機能場所、製品設置ポイント、および登録製品は、それぞれ3つの親ポインタフィールド（親インストールベースUUID、親登録製品UUID、親設置ポイントUUID）を保持しており、実際にはそのうち1つだけが設定される。つまり、3つのアイテムタイプはいずれも、インストールベースの直下、または別のアイテムの1階層下に直接ネストできる。セットアップガイドの作成手順では、機能場所、登録製品、および製品設置ポイントを、主にレコードが表示されるタブによって区別される、より広範な「設置ポイント」概念のUIレベルの「カテゴリ」として位置付けており、これは十分に裏付けられたニュアンスではあるが、他の場所で単一の統一的な技術的記述によって完全に相互確認されているわけではない。

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

Installed Base（インストールベース）は単独で存在するわけではありません。これは、柔軟な品目ツリーがアタッチされるコンテナであり、パーティロールのアンカーであるAccount（取引先）とその請求先/出荷先バリアントが参照するものであり、Case（ケース）から直接参照される唯一の4つのオブジェクトタイプの1つです。

真の直接関係であり、否定すべき誤解ではありません。 保証に関する関連記事で判明したように、Case（ケース）には保証への直接的なフィールドレベルのリンクはありません。一方、インストールベースはその逆です。「Case Installed Bases（ケースインストールベース）」サブエンティティは、データモデルレベルにおいて、Caseと機能場所、製品取付ポイント、登録製品との直接リンクと同じ構造ファミリーに属する、実際に確認された第一級のリンクです。インストールベースが、その内包するアイテムを介して間接的にのみCaseに到達すると想定しないでください。インストールベースには独自の直接参照が存在します。

カバレッジギャップ — インストールベース自体に対するS/4HANAレプリケーションの確定シナリオはありません。 インストールベースの作成に関する文書化されたガイダンスはすべて、手動によるアプリ内ワークリストアクションのみを説明しています。特定の実装において、インストールベースが自動化されたS/4HANAレプリケーションによって一般的に作成されると断言しないでください。顧客固有の統合が存在しないという絶対的な主張ではなく、文書化されたデフォルトとして手動作成を扱ってください。

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

2.0) SC所有権の範囲#

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1) 基本識別情報 & ステータス#

これらのフィールドは、これがどのインストールベースであるか、および現在アクティブかどうかを確定します。以下のすべてのパーティロール、アドレス、および割当フィールドは、これらが設定されて初めて意味を持ちます。

2.2) 顧客および取引先ロール#

これらのフィールドは、セクション1.2で紹介されたように、インストールベースを正しい顧客、およびビジネス上必要な場合は別の所有者、支払者、または出荷先に関連付けます。

2.3) 住所と位置情報#

これらのフィールドは、品目階層が実際に存在する物理的な拠点を記録します。つまり、このインストールベースに対してケースが起票された際に、フィールドテクニシャンが派遣されるロケーションです。

2.4) サービス割当#

![インストールベースのサービス割当フィールドを示す積層図: サービス技術者チーム、担当プランナー、サービス技術者、責任者]

これらのフィールドは、ケースがサイトに対して起票された際に、そのサイトの責任者を決定します。これらを誤って設定すると、ケースルーティングルールの設定が評価される前の段階で、作業が誤ったチームにルーティングされてしまいます。

2.5) ケース連携（ケース稼働ベースサブエンティティ）#

これらの2つのフィールドは、インストールベース自体ではなく、ケース側のリレーションシップに存在します。しかし、これらはケースにインストールベースへの直接的で第一級の参照を提供する実際のメカニズムであるため、本記事のフィールドレベルの範囲に含まれます。

前提条件: このサブエンティティは、確定済みの「ケース機能場所」「ケース登録製品」「ケース製品設置ポイント」の各サブエンティティと構造的に同一の形式です。これら4つの品目/コンテナタイプはすべて、それぞれ独自のケース直接結合サブエンティティを持ち、ケースにリンクするために他のオブジェクトを経由する必要はありません。

2.6) 作業区とアクセス制御#

このバッチ内の他のマスタデータオブジェクトと同様に、インストールベースのワークリストへのアクセスは、インストールベースレコード自体のフィールドではなく、ビジネスロールの割当によって完全に管理されます。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction