クラウド情報モデル

(CIM) は、現代の企業内を移動するエンティティ (パーティ、製品、注文、支払い、およびそれらを結び付ける関係) を記述するための、オープンでアプリケーションに依存しないスキーマです。CIM は、統合ごとにオーダーメイドのデータモデルを作成するのではなく、CRM、ERP、コマースプラットフォーム、および分析ウェアハウスが「販売注文 (Sales Order)」または「製品関係タイプ (Product Relationship Type)」が実際に何を意味するかについて合意できるように、共有ボキャブラリーを提供します。この記事では、モデルを構成するエンティティグループについて説明し、次に 1 つの代表的なエンティティである ProductRelationshipType を掘り下げて、実際に CIM がリレーションシップ、ロール、キーをどのように表現するかを示します。

重要なポイント

• CIM は、エンタープライズデータを エンティティグループ (Party, Product, Sales Order, Payment など) に編成し、一度にすべてではなく段階的に導入できるようにします。
• 各エンティティは、用語 URI (Term URI)、説明、スカラープロパティ、およびリンクプロパティで定義されます。この構造は、JSON-LD、RDF、およびプロパティグラフストアに明確にマップされます。
• ProductRelationshipType などの関係エンティティは ロール (親/子) をエンコードするため、ビジネスロジックをハードコーディングせずにバンドル、オプション、およびカバーリングをモデル化できます。
• このモデルは意図的にアプリケーションに依存しない (application-agnostic) 設計になっています。特定のベンダーがデータをどのように保存するかではなく、データが何を意味するかを記述します。
• CIM の導入は、リップ・アンド・リプレース (全面刷新) ではなくマッピング作業です。既存のシステムを共有用語に合わせ、ギャップを調整します。

共有モデルが重要な理由

エンタープライズ統合には、よくある失敗パターンがあります。それは、すべてのシステムが独自のダイアレクト (方言) を話すことです。Salesforce ではそれを Account と呼び、SAP では Business Partner と呼び、自社製の請求サービスでは Customer と呼びます。各ペア間でポイントツーポイントのマッピングを構築すると、変換の数は関与するシステムの 2 乗で増加し、新しいシステムが導入されるたびにメンテナンスの負担が倍増します。

カノニカルモデル (正規モデル) は、この二次関数的な問題を解決します。各システムを共有モデルに 1 回 マッピングすれば、共有モデルがハブになります。これは、OAGIS (Open Applications Group Integration Specification)、OMG の Common Warehouse Metamodel、および schema.org のコマース用ボキャブラリーなどの標準の背後にあるアーキテクチャ上の考え方と同じです。CIM はその伝統に則っていますが、クラウド時代の相互運用性を対象としており、逆参照可能な URI を持つオープンな用語として公開されています。

実用的なメリットは、データアーキテクトが単一のリファレンスポイントを使用して、「どのシステムがパーティの正本 (authoritative record) を保持しているか？」や「カタログと注文全体で製品バンドルを一貫してどのように表現するか？」といった質問に答えられるようになることです。

エンティティグループの概要

CIM は単一のモノリシックなスキーマではなく、疎結合されたグループのセットです。モデルで定義されているグループには以下が含まれます：

• Account — パーティの商業的な関係のコンテキスト。
• Contact Point — 電話番号、メールアドレス、および同様の連絡手段。
• Lead — まだ適格性を確認していない見込みパーティ。
• Party および Party Role — アクターの一般的な概念と、それが果たす役割 (顧客、サプライヤー、従業員)。
• Payment および Payment Method — お金の移動方法と使用される手段。
• Product Attribute, Product Catalog, および Product — 販売可能で記述可能な商品およびサービス。
• Sales Order とその大規模なサブエンティティファミリー — モデルのトランザクションの中核。
• Shipment — フルフィルメントと物流。

Sales Order グループは群を抜いて粒度が細かく、その理由を理解することは重要です。注文は、価格設定、税金、調整、配送グループ、行ごとのメモなど、ビジネスルールが集中する場所だからです。CIM は、注文を 1 つの幅広なテーブルにするのではなく、Sales Order Product、Sales Order Price Adjustment、Sales Order Tax、Sales Order Delivery Group、Sales Order Payment Summary、Sales Order Change Log など、多くの小さなエンティティに分解します。この分解は意図的な設計上の選択です。これにより、各関心事が独立して進化でき、システムは必要なスライスのみをサブスクライブできるようになります。

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

CIM エンティティの構造

CIM のすべてのエンティティは同じ形状に従っており、これによりモデルをプログラムで消費する際の予測可能性が高まります。2 つの製品が なぜ 関連しているかを記述するエンティティ ProductRelationshipType を例に考えてみましょう。

• 用語 URI (Term URI) — http://cloudinformationmodel.org/model/ProductRelationshipType。これは概念のグローバルに一意な識別子です。URI であるため、逆参照して RDF/JSON-LD グラフで直接使用できます。
• 説明 (Description) — 「バンドル、オプション、カバーリングなど、製品が関連する理由」。これにより、このエンティティが関係のインスタンス自体ではなく、タイプ または 分類 であることがわかります。
• スカラープロパティ (Scalar Properties) — データを保持するプリミティブフィールド。
• リンクプロパティ (Link Properties) — 他のエンティティへの参照。ProductRelationshipType にはリンクプロパティがありませんが、それ自体が有益な情報です。つまり、これはハブではなく、制御された語彙であるリーフエンティティであることを意味します。

スカラープロパティは以下の通りです：

プロパティ	用語 URI	範囲	必須	説明
id	.../model/id	guid	yes	主キー
parentProductRole	.../model/parentProductRole	string	yes	関係における最初のロール。例: “Consists of”
childProductRole	.../model/childProductRole	string	yes	関係における 2 番目のロール。例: “Component of”

id が GUID であることは意味のある慣習です。これは、システム間で調整することなく識別子がグローバルに一意であることを意味し、異なるクラウドでレコードが作成され、後でマージされる場合にまさに求められる仕様です。

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

ロールを用いた関係のモデル化

ProductRelationshipType の最も示唆に富む部分は、ロールプロパティのペアです。製品関係には方向性があり、CIM は単一の不透明な “type” 文字列ではなく、2 つの名前付きロールを使用してその方向性を捉えます。

バンドルについて考えてみましょう。「スターターキット」は「ルーター」と「ケーブル」で構成されています。CIMの用語では次のようになります：

• 親製品 (parent product) は、parentProductRole で記述される役割を果たします。例えば、「～で構成される (Consists of)」などです。
• 子製品 (child product) は、childProductRole で記述される役割を果たします。例えば、「～の構成要素 (Component of)」などです。

両方の役割を type の文字列として保存することで、再利用可能な定義が得られます。実際の製品間リンクはいくつでも同じ ProductRelationshipType 行を参照できるため、語彙を小さく一貫性を保ちながら、関係のインスタンスを多数保持できます。これは古典的な正規化パターンであり、関係の タイプ をその インスタンス から分離するものです。

この説明では、バンドル (bundle)、オプション (option)、カバーリング (covering) という3つのフレーバーを明示的に挙げており、これはモデルがカバーしようとしている商用セマンティクスの範囲を示唆しています：

• バンドル — ユニットとしてまとめて販売される製品（親が子で「構成される」）。
• オプション — 基本製品に関連付けられた選択肢またはアドオン。
• カバーリング — 別の製品を包んだり保護したりする製品。保険や保証の文脈で一般的です。

役割の語彙を決定する方法

parentProductRole と childProductRole は自由形式の文字列であるため、モデルが正確な文言を規定することはありません。この柔軟性はメリットであると同時にリスクでもあります。いくつかの実践的なルールを挙げます：

1. 管理された語彙を選択し、固定する。 役割フレーズの小さなセット（「～で構成される」/「～の構成要素」、「～へのオプションアドオン」/「～のオプションを持つ」など）に合意し、文書化してください。フリーテキストは表記の揺れ（ドリフト）を招きます。
2. 役割を対称的にし、双方向から読みやすくする。 良いテスト方法は、関係をどちらの端から声に出して読んでも意味が通じるかを確認することです。
3. 役割にビジネスロジックを詰め込まない。 役割に条件付きの動作が必要な場合、そのロジックは文字列の中ではなく、利用するアプリケーション側に持たせてください。
4. 語彙をバージョン管理する。 役割を追加する場合は、アドホックな挿入ではなく、移行パスを伴うスキーマ変更として扱ってください。

実践的なCIMの導入

カノニカルモデルの採用はマッピングの規律であり、移行ではありません。実行可能な手順は以下の通りです：

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

• 記録システム (systems of record) のインベントリを作成する。 エンティティグループごとに、どのシステムが正本（権限を持つか）であるかを決定します。例えば、PartyはCRMに、ProductはPIMに、Sales OrderはERPに存在するかもしれません。
• 各ソースをCIM用語にマッピングする。 「ソースフィールド → CIMプロパティ」の対応表を作成します。ソースに相当するものがない場合はギャップとして、CIMに相当するものがない場合は拡張として記録します。
• 識別子を調整する。 CIMのGUID規則により、通常はネイティブキーとCIMの id 値の間のクロスウォーク（対応表）を維持することになります。
• シリアル化を選択する。 CIMのURIベースの用語はJSON-LDやRDFに自然にマッピングされ、リレーショナルテーブルやプロパティグラフにもきれいに変換されます。このモデルは特定のストレージ技術を強制しません。
• 語彙をガバナンスする。 追加した役割文字列、列挙型、拡張は最も変動しやすい部分であるため、変更管理下に置いてください。

有用なメンタルモデルは、CIMを インターチェンジ (interchange) スキーマとして扱い、運用ストアを 記録システム (system of record) として扱うことです。すべてのアプリケーションにネイティブモデルを放棄させるのではなく、境界において共有モデルを公開し、消費することを求めるのです。

注意点とトレードオフ

どのようなカノニカルモデルにもコストが伴い、CIMも例外ではありません。

• 抽象化には代償がある。 業界を横断できるほど汎用的なモデルは、個別の業界に完璧に適合することはありません。拡張機能の追加が必要になると想定してください。
• Sales Orderグループは重い。 きめ細かな分解は強力ですが、それはより多くの結合 (join) とマッピングすべきエンティティが増えることを意味します。シンプルな注文フローを持つチームは、サブセットのみを採用する場合もあります。
• 自由形式の役割文字列にはガバナンスが必要。 前述の通り、parentProductRole と childProductRole の柔軟性は、それを運用する規律があって初めて価値を持ちます。
• オープンモデルは進化する。 CIMはコミュニティ指向であるため、用語は時間の経過とともに追加または洗練されます。特定のバージョンに固定し、変更を意図的にレビューしてください。

このトレードオフは、本質的に 特定のシステムへの忠実性 と システム間の移植性 の間の古典的な選択です。CIMは移植性を最適化しており、相互運用性が目標である場合にはそれが正しい選択となります。

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

よくある質問

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

クラウド情報モデルは、パーティ、製品、注文、支払いなどのエンタープライズデータのための共有エンティティと用語を定義する、オープンでアプリケーションに依存しないデータモデルです。共通の語彙を提供することで、異なるクラウドシステムやオンプレミスシステムが、個別のポイントツーポイントマッピングを作成することなくデータを交換できるようにします。

ProductRelationshipType は何に使用されますか？

ProductRelationshipType は、2つの製品が関連している 理由 （例えば、バンドル、オプション、カバーリングなど）を定義します。親の役割と子の役割を保存することで、方向性を持つ製品間リンクが、リンクごとにセマンティクスを繰り返すのではなく、再利用可能な共有定義を参照できるようになります。

なぜCIMは主キーにGUIDを使用するのですか？

id プロパティにGUIDを使用することで、中央での調整なしに識別子をグローバルに一意にできます。これは、レコードが異なるシステムで作成され、後でマージされるマルチクラウドおよびマルチベンダー環境において、衝突を効果的に回避するために重要です。

CIMはデータベーススキーマですか、それともデータ交換フォーマットですか？

物理的なデータベーススキーマではなく、概念モデルおよびインターチェンジモデルとして理解するのが最適です。URIベースの用語はJSON-LD、RDF、リレーショナルテーブル、またはプロパティグラフに自然にマッピングされるため、アーキテクチャですでに使用している任意のストレージ技術で実装可能です。

CIMはOAGISやschema.orgなどの他の標準とどのように関連していますか？

CIM は、これらの取り組みの目標である「相互運用性のための共通語彙」を共有していますが、クラウド時代のエンタープライズ統合を対象としており、オープンで参照解除可能な用語として公開されています。実際には、パートナーが要求する場合、エッジ部分で CIM を他の標準にマッピングして利用できます。

モデル全体を一度に採用する必要がありますか？

いいえ。CIM は疎結合のエンティティグループに編成されているため、必要なグループ（例えば Party や Product）から採用し、後で拡張することが可能です。ほとんどのチームは、統合において最も課題となっているエンティティから着手し、そこから徐々に拡大していきます。

詳細資料

• 販売注文 — Wikipedia
• リソース記述フレームワーク (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — Web上の構造化データのための共通語彙