CIMモデル

クラウド情報モデル (CIM) は、CRM、ERP、マーケティング、サービス、分析システム全体に現れるエンティティの共有語彙を企業に提供することを目的とした、オープンでアプリケーションに依存しないデータモデルです。各ベンダーが独自のオブジェクト名と関係を考案するのではなく、CIM は、あらゆるシステムがマッピングできるサブジェクト領域、エンティティ、および属性の共通セットを定義します。このモデルは、共同データおよびインフラストラクチャプロジェクトの広範なポートフォリオをホストする Linux Foundation の下でオープンソースプロジェクトとして管理されています。

この記事では、CIM がどのように構造化されているか、そのコンポーネントが相互にどのように関係しているか、スーパータイプとサブタイプがどのように機能するか、およびサブジェクト領域がどのように構成されているかについて説明します。また、CIM を導入する際にアーキテクトが直面する実際的な決定（マッピング、ガバナンス、バージョン管理、拡張）と、モデルが他の業界標準と比較してどこに適合するかについても説明します。

重要なポイント

• CIM はビジネス概念を サブジェクト領域 (Subject Areas) に編成し、各領域には エンティティグループ (Entity Groups)、エンティティ (Entities)、属性 (Attributes) が含まれます。これは、スキーマ、テーブル、列に明確にマッピングされる階層です。
• スーパータイプとサブタイプを使用することで、専門化を可能にしつつ、共通の特性（個人または組織である Party）を表現できます。
• このモデルは意図的にアプリケーションに依存しない (application-agnostic) 設計となっており、単一ベンダーの実装ではなく、ビジネス概念を記述します。
• CIM は、例示図とともに 複数の形式 で公開されているため、モデリングツール、コードジェネレーター、ドキュメントなどで同様に利用できます。
• サブジェクト領域の数と範囲は コンソーシアムとコミュニティの貢献に応じて増加します。そのため、導入時にはバージョン管理と変更管理を考慮する必要があります。
• CIM はいくつかの選択肢のうちの 1 つです。適切な選択は、広範なクロスドメインモデルが必要か、それとも特定の業界向けの狭く深い標準が必要かによって決まります。

CIM の構造

CIM は、コンテンツをより簡単にナビゲートして利用できるよう、コンポーネントに編成されています。階層の各レベルは異なる問いに答えるものであり、その階層を理解することがモデルを適切に使用するための第一歩です。

• サブジェクト領域 (Subject Area) — Party など、CIM コンソーシアムによって特定された主要なビジネス概念。各サブジェクト領域には 1 つ以上のエンティティグループが含まれます。サブジェクト領域は「境界づけられたコンテキスト (bounded context)」と考えてください。ある広範なテーマについて、ビジネスが知っておく必要があるすべてをグループ化したものです。
• エンティティグループ (Entity Group) — Account など、サブジェクト領域内の関連エンティティの論理的なグループ。エンティティグループにより、大規模なサブジェクト領域でもナビゲートしやすくなり、チームに所有権を割り当てるための自然な単位が得られます。
• エンティティ (Entity) — Account Contact など、組織が情報を収集する一意のオブジェクト。エンティティは、標準的なデータベーステーブルに相当します。
• 属性 (Attribute) — Account Id や Contact Email など、エンティティの一意の特性。属性は、テーブル内の標準的なデータベースフィールドに相当します。

この 4 レベルの階層は、意図的に馴染みのある構成になっています。リレーショナルモデリング、ディメンショナルモデリング、または実体関係図 (ER図) を扱ったことのあるデータアーキテクトであれば、このパターンをすぐに認識できるでしょう。CIM が提供する価値は、斬新なモデリング手法ではなく、複数の組織やベンダーが合意できる 共有され、事前に調整された名前と関係のセット です。

有用なメンタルモデルとして、サブジェクト領域はおよそスキーマまたはドメイン、エンティティグループはおよそ名前空間またはモジュール、エンティティはテーブル、属性は列であると考えてください。このマッピングは近似的なものです（CIM は概念的および論理的なモデルであり、物理的なモデルではないため）。しかし、CIM を物理的な実装に変換する際に役立ちます。

スーパータイプとサブタイプ

4 つのコアコンポーネントに加えて、CIM の設計ではスーパータイプとサブタイプを使用してエンティティをさらにカスタマイズし、グループ化します。ここで、モデルの表現力が大きく発揮されます。

関連: Boomi AtomSphere — ハイブリッドクラウドとオンプレミスの統合のためのエンタープライズ iPaaS.

• スーパータイプ (Supertype) — サブタイプエンティティによって拡張され、類似した概念の共通属性を定義するエンティティ。
• サブタイプ (Subtype) — 別のエンティティを拡張し、そのスーパータイプエンティティから属性を継承するエンティティ。

典型的な例は Party です。Party とは、ビジネスが取引するあらゆる人物または組織を指します。個人 (Person) と組織 (Organization) はどちらも Party であり、名前、識別子、連絡先などの属性を共有していますが、それぞれに固有の属性も持っています。Party をスーパータイプとし、Person と Organization をサブタイプとしてモデル化することで、共有属性の重複を避け、「この商談はこの Party に属する」といった関係性を、どのサブタイプが関与しているかに関わらず一貫して維持できます。

このような継承はデータモデリングにおいて確立された概念であり、Object Management Group の UML や、業界全体で使用されている実体関係の慣習に見られます。CIM を物理的に実装する場合、継承をどのように表現するかを決定する必要があります。

• 単一テーブル (Single table) — すべてのサブタイプを、識別子列 (discriminator column) を持つ 1 つのテーブルに保存します。クエリは簡単ですが、Null 許容列が多くなる可能性があります。
• クラステーブル継承 (Class table inheritance) — スーパータイプ用に 1 つ、サブタイプごとに 1 つのテーブルを作成し、共有キーで結合します。正規化されておりクリーンですが、結合 (join) が必要になります。
• 具体テーブル継承 (Concrete table inheritance) — サブタイプごとに独立した自己完結型のテーブルを作成します。サブタイプ固有のクエリは高速ですが、共有属性が重複します。

普遍的な正解はありません。適切な選択は、クエリパターン、サブタイプの数、および共有属性が同時に読み取られる頻度によって決まります。この決定はすべての下流の統合に影響するため、文書化してください。

私たちの選択: Workato — ビジネスチームが実際に構築できる自動化主導の iPaaS.

CIM サブジェクト領域

主題領域は、コンソーシアムがこれまでにモデル化した主要なビジネス概念を表しています。それぞれが独自の図と形式で公開されており、いくつかの領域には明示的なバージョンマーカー（例：v1.0 や v0.1.1）が付与されており、一部の領域が他の領域よりも成熟していることを反映しています。

Setup（設定） — 顧客、サプライヤー、販売者など、取引する相手を定義します。また、組織が運用するソフトウェアとインフラストラクチャの概念（Software Host、Software Tenant、Software User、Software App、Software Test、Software Service、Software Batch Job、IoT Device）についてもカバーします。

Data Model（データモデル） — 基盤となるモデリング概念そのものです。

Hire（雇用） — 社内のビジネスユニットやワーカーなど、ビジネスの立ち上げに関連するアクティビティです。エンティティグループには、Job Application、Employee、Compensation、Training、Location、Work Territory、Work Reportが含まれます。

Biz Process（ビジネスプロセス） — ビジネスプロセスとビジネス継続性の概念です。

Produce（生産） — 製品や在庫品など、購入、移動、販売する資材の取り扱いです。エンティティグループには、Supplier Product、Inventory Received、Inventory Product、Inventory Transfer、Electronic Media、Purchase Order、Sales Agreementが含まれます。

関連: Matillion — クラウド データ ウェアハウス用に構築されたプッシュダウン ELT.

Market（マーケット） — マーケティングキャンペーンやWebストアなど、製品を宣伝するために使用されるアクティビティです。エンティティグループには、Party Resolution、Privacy Consent、Market Audience、Campaign、Promotion、Trade Event、Ad Buy、Web Siteが含まれます。

Sell（販売） — 見積書や商談の作成など、製品を販売するために使用されるアクティビティです。エンティティグループには、Price Book、Shopping Cart、Quote、Contract、 Opportunity、Opportunity Forecast、Sales Order、Loyalty Program、Competitorが含まれます。

Service（サービス） — ケースやアンケートなど、販売またはサービス提供された製品のサポートを提供するアクティビティです。エンティティグループには、AI Assistant、Asset、Asset Subscription、Web Content、Case、Task、Eventが含まれます。

どこから始めましょうか: Fivetran — 実行し続けるフルマネージドの ELT パイプライン.

Fulfill（履行） — 出荷や返品注文など、顧客への注文を履行するために実行するアクティビティです。エンティティグループには、Fulfillment Order、Shipment、Return Order、Work Order、Work Resource、Work Forecastが含まれます。

Interact（対話） — エンドユーザーまたは他のシステムとのエンゲージメントを追跡するアクティビティです。エンティティグループには、Engagement、Conversation、Appointment、Software Event、Data Connector、Data Movement、Loyalty Journey、Loyaltyが含まれます。

Finance（財務） — 支払い、請求書、経費報告書など、社内の財務情報を追跡するアクティビティです。エンティティグループには、Budget、Invoice、Payment Method、Payment、Credit Memo、Financial Ledger Account、Forecast、Calendar、Tax Policyが含まれます。

Analyze（分析） — パターン、製品の使用状況、データの移動、データの変更、顧客満足度の分析など、データの分析に関連するアクティビティです。エンティティグループには、AI Model、AI Application、IoT Device Use、Data Lineage、Blockchain、Survey、Loyalty、Journalが含まれます。

主題領域が 運用 上の懸念事項（Sell、Fulfill、Service）と 分析 上の懸念事項（Analyze、Finance）の両方に及んでいることに注目してください。その幅広さこそが重要な点です。共有モデルが最も価値を発揮するのは、データがトランザクションシステムにあるかデータウェアハウスにあるかにかかわらず、同じ顧客、製品、または注文を一貫して記述できる場合です。

CIM と他の標準のどちらを選択するか

CIM は企業における唯一の共有モデルではありません。いくつかの確立された標準がその範囲の一部と重複しており、成熟したアーキテクチャでは複数の標準が併用されることがよくあります。決定において重要なのは、単に「勝者」を選ぶことではなく、モデルの幅広さとガバナンスを直面している課題に適合させることです。

標準	主な焦点	代表的な強み	CIM との違い
CIM	クロスドメインのビジネス概念	CRM/ERP/マーケティング/サービスを幅広く、アプリケーションに依存せずカバー	ドメインを横断する共有の傘として設計されている
OMG Common Core Ontologies / UMLベースのモデル	概念モデリング表記と上位オントロジー	厳格な形式意味論	CIM はより直接的にビジネス指向である
業界固有のモデル（例：小売、ヘルスケア、金融などのバーティカル）	特定のセクターの深いカバー	バーティカル内での精度	CIM は深さよりも幅を優先している
ベンダーデータモデル（CRM/ERPプラットフォーム）	単一製品のオブジェクト	その製品との緊密な統合	CIM は設計上、ベンダーニュートラルである

実用的な経験則：

• 多くのシステムやベンダー間で共通の語彙が必要な場合は、CIM のような広範なモデルが適しています。
• 深く規制された業界固有のセマンティクスが必要な場合は、通常、バーティカル標準の方がより正確です。その場合は、境界部分で CIM にマッピングさせることができます。
• 単一ベンダーのエコシステム内で統合している場合は、そのベンダー独自のモデルで十分かもしれませんが、それでは次のベンダーへの接続には役立ちません。

現実世界で最も一般的なパターンは、ハブアンドスポーク アプローチです。CIM（または別のカノニカルモデル）を中央に配置し、各ソースシステムをそこにマッピングします。これは、マスターデータ管理におけるカノニカルデータモデルの原理や、ラルフ・キンボールがディメンショナルモデリングで普及させた「適合ディメンション（conformed dimension）」の考え方と同じ原理です。

CIM 導入のための実践的なガイダンス

共有モデルの採用は、技術的な取り組みであると同時に組織的な取り組みでもあります。いくつかの決定が、その取り組みが報われるかどうかを左右します。

限定的な範囲から始めてください。 すべてのシステムを一度にすべての主題領域にマッピングしようとしないでください。価値の高いドメインを1つ選択し（顧客データと商談データは広く重複しているため、Party と Sell が一般的な開始点となります）、マッピングをエンドツーエンドで実証してください。

拡張ポリシーを早めに決定してください。 CIM はコンソーシアムや貢献とともに成長するように設計されていますが、組織では必然的にモデルでまだ定義されていない属性が必要になります。カスタム属性を標準属性と明確に区別し、後で調整できるように、ローカル拡張の規約（例：名前空間プレフィックス）を確立してください。

バージョン管理を最優先事項として扱ってください。 サブジェクト領域には、モデルが進化していることを示す v1.0 や v0.1.1 などのバージョンマーカーが付与されています。ビルド対象のバージョンを固定し、変更を追跡し、移行を計画してください。これは、あらゆる依存関係に適用するのと同様の規律です。

コピーではなく、マッピングしてください。 CIM は概念的かつ論理的なモデルです。パフォーマンス、インデックス作成、およびデータを消費するシステムのアクセスパターンを考慮せずに、物理スキーマを直接生成したいという誘惑に抵抗してください。モデルを使用して意味を整合させ、その上でワークロードに合わせて物理ストレージを設計してください。

マッピングをガバナンスしてください。 ソースシステムと CIM 間のマッピング自体が資産です。バージョンを管理し、レビューし、所有権を割り当ててください。データ統合分野のツール（ETL および ELT プラットフォーム、データカタログ、リネージュツール）は、各属性がどこから発生し、どのように流れるかを追跡するのに役立ちます。これはまさに、Analyze サブジェクト領域が Data Lineage などのエンティティで想定している種類のメタデータです。

コミュニティに参加しましょう。 CIM はオープンソースでコンソーシアム主導であるため、あなたが見つけたギャップは、他の人も見つけたギャップであることがよくあります。提案するエンティティや属性をプロジェクトに還元することは、善良な市民としての行動であると同時に、長期的なメンテナンス負担を軽減する方法でもあります。

フォーマット、ダイアグラム、および利用方法

CIM 設計は、例示的なダイアグラムを含め、ドメインごとに複数のフォーマットで利用可能です。これは、対象者によってデータモデルの利用方法が異なるため重要です。

• アーキテクトは、構造を検討するためにダイアグラムとリレーションシップビューを必要とします。
• エンジニアは、コード生成、スキーマ検証、またはマッピングツールに投入できる機械可読な定義を必要とします。
• アナリストとスチュワードは、各エンティティと属性がビジネス用語で何を意味するのかを説明するドキュメントを必要とします。

複数のフォーマットで公開することは、導入の障壁を下げるための意図的な設計上の選択です。共有モデルを評価するときは、お使いのツールチェーンが実際に取り込めるフォーマットで提供されているかを確認してください。PDF としてのみ存在するモデルは、構造化された定義を持つモデルよりもはるかに有用性が低くなります。

よくある質問

クラウド情報モデル (CIM) とは何ですか？

クラウド情報モデルは、オープンでアプリケーションに依存しないデータモデルであり、Party、Account、Sales Order などの共有ビジネス概念を定義することで、異なるクラウドシステムとオンプレミスシステムが共通の語彙を使用してデータを交換できるようにします。これはサブジェクト領域、エンティティグループ、エンティティ、および属性で構成されており、The Linux Foundation の下でオープンソースプロジェクトとして管理されています。

CIM のスーパータイプとサブタイプの違いは何ですか？

スーパータイプは、サブタイプエンティティによって拡張されるエンティティであり、類似した概念に共通する属性を定義します。サブタイプは別のエンティティを拡張し、そのスーパータイプの属性を継承します。たとえば、Party をスーパータイプとし、Person と Organization をサブタイプとすることで、共有属性は一度だけ定義され、特化した属性はサブタイプに保持されます。

CIM はデータベーススキーマとどのように関係しますか？

CIM は概念的かつ論理的なモデルであり、物理スキーマではありません。そのエンティティはデータベーステーブルに、属性はフィールドに類似しているため、変換は直感的に行えますが、モデルをそのままコピーするのではなく、独自のクエリパターンに基づいて物理ストレージ（インデックス作成、パーティショニング、非正規化）を設計する必要があります。

CIM は業界固有のデータ標準に代わるものですか？

いいえ。CIM は広範でクロスドメインである一方、垂直標準（バーティカル標準）は深く、セクター固有です。多くの組織は、CIM を中心の標準モデルとし、業界標準やベンダーモデルをそのエッジでマッピングさせるハブアンドスポークアプローチを採用しています。

CIM サブジェクト領域にバージョン番号があるのはなぜですか？

v1.0 や v0.1.1 などのバージョンマーカーは、モデルが進化していること、および一部のサブジェクト領域が他の領域よりも成熟していることを示しています。バージョンの固定、変更の追跡、および移行の計画は、共有ライブラリやスキーマに適用するのと同様の依存関係管理の規律です。

CIM が定義していない属性はどのように処理すればよいですか？

カスタム属性が標準属性と明確に区別できるように、名前空間プレフィックスなどの文書化された拡張規則を確立してください。その後、このモデルはコンソーシアムとコミュニティの貢献によって成長するように設計されているため、そのギャップをプロジェクトに還元することを検討してください。