リソース

「リソース」ページは、クラウド情報モデル (CIM) を理解、導入、または貢献したいすべての人にとってのエントリポイントです。CIM は、The Linux Foundation の管理下にあるオープンソースのアプリケーションに依存しないデータモデルであり、ビジネスエンティティの共有ボキャブラリを定義することで、各統合チームが独自のスキーマを再構築することなく、クラウドシステムとオンプレミスシステムがデータを交換できるようにします。このページには、CIM を評価するために必要なアーティファクト、サポートされる形式、モデルが格納されているリポジトリ、および参加するためのチャネルがまとめられています。

重要なポイント

• CIM は、製品やデータベースではなく、ベンダー中立の共有データモデルです。複数のアプリケーションがマッピング可能なエンティティ、属性、および関係を記述します。
• 主要な技術資産は CIM GitHub 組織にあり、モデル定義とツールはバージョン管理され、オープンライセンスで提供されています。
• CIM は複数の標準形式で表現されているため、特定のシリアル化に縛られることなく、さまざまなツールチェーンで利用可能です。
• プレゼンテーション、FAQ、およびニュースページは、技術的な詳細を検討する前に、ビジネスケースを構築し、ステークホルダーの質問に答えるための最短ルートです。
• 貢献は GitHub リポジトリと貢献者用ウェブフォームを通じて行われます。モデルは単一ベンダーのロードマップではなく、コミュニティのレビューを通じて進化します。

クラウド情報モデルとは実際には何なのか

CIM は「カノニカルモデル（標準モデル）」として理解するのが最適です。これは、既に運用しているシステムの間に位置する、ビジネス概念（顧客、アカウント、注文、製品、連絡先、およびそれらの間の関係）の中立的で合意された表現です。すべてのアプリケーションに他のすべてのアプリケーションの方言を話させるのではなく、各システムを一度だけ CIM にマッピングすることで、CIM がインターチェンジポイント（交換点）となります。

これは、エンタープライズ統合で繰り返し登場するアーキテクチャパターンであり、ポイントツーポイントマッピングのメッシュではなく、ハブアンドスポーク型のカノニカルスキーマを採用するものです。概念的には、ドキュメント向けの OASIS Universal Business Language (UBL)、ビジネスメッセージ向けの Open Applications Group Integration Specification (OAGIS)、ウェブスケールのボキャブラリ向けの schema.org などの取り組みに関連しています。CIM の際立った特徴は、アプリケーションに依存せず、ほとんどの企業が実際に運用している「クラウド＋オンプレミス」の現実に合わせて設計されている点です。

実用的なメリットは、マッピングのスプロール（乱立）が減少することです。n 個のシステムがあり、それぞれが互いに通信する必要がある場合、マッピング数は n² のオーダーになります。カノニカルモデルを導入すれば、作業はシステムごとに1つ、計 n 個のマッピングへと削減されます。この削減こそが、CIM を採用するための核心的な経済的根拠です。

CIM プレゼンテーション

CIM プレゼンテーションは、社内で導入の根拠を構築する際に推奨される最初のアーティファクトです。アーキテクト、データガバナンス責任者、ビジネススポンサーなど、多様な聴衆に見せることを想定して設計されており、共有モデルの動機、CIM が定義する範囲、および既存の統合環境にどのように適合するかが網羅されています。

次のように活用してください：

関連: Fivetran — 実行し続けるフルマネージドの ELT パイプライン.

• エグゼクティブおよびスポンサー向け： マッピングのスプロール問題とベンダー中立性の議論を主軸にします。このプレゼンテーションでは、CIM を「リプレース（刷新）」ではなく「リスク軽減」として位置づけています。
• アーキテクトおよびエンジニア向け： コンテキストを把握させるために使用し、その後すぐに実際のモデル定義がある GitHub リポジトリへ誘導します。
• ガバナンスおよびコンプライアンスのステークホルダー向け： 所有権、バージョン管理、およびモデル変更のレビュー方法についての議論を開始するために使用します。

プレゼンテーションは会話のきっかけであり、仕様書ではありません。それをオンランプ（導入路）として扱い、リポジトリを信頼できる唯一の情報源（Source of Truth）として扱ってください。

CIM フォーマット

CIM は、単一の独自のシリアル化ではなく、複数の標準と形式を意図的にサポートしています。これは、エンタープライズのツールチェーンが不均一であるためです。モデリングツール、ETLプラットフォーム、APIゲートウェイ、ドキュメント生成ツールによって、それぞれ好まれる表現が異なる場合があります。

この分野で一般的に関連する形式ファミリーには以下が含まれます：

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

• 人間によるレビューや設計ワークショップ向けの 実体関係（ER）および概念表記
• API およびアプリケーション利用向けの JSONベースのスキーマ表現
• セマンティックおよびナレッジグラフのユースケース向けの RDF およびオントロジー形式の表現
• データウェアハウスおよび ETL パイプライン向けの リレーショナルおよび表形式のマッピング

設計原則は「移植性」です。オープン形式で表現されたモデルは、標準的なツールによって変換、差分抽出、バージョン管理、および検証が可能です。組織で CIM を評価する際に問うべきは、「どの形式を使用しているか」ではなく、「ツールが必要とする形式の間で、損失なくモデルを往復（ラウンドトリップ）させることができるか」です。形式変換によってリレーションシップのカーディナリティや属性制約が密かに失われる場合、それは早期にテストすべき重大な統合リスクとなります。

どの形式を採用するかを決定する方法

以下のクイック決定ガイドを参照してください：

主な消費者が…	推奨される表現…	注意点…
アプリケーション/API 開発者	JSON スタイルのスキーマ	フラットな JSON によるリレーションシップ・セマンティクスの喪失
データウェアハウス / ETL チーム	リレーショナルまたは表形式のマッピング	多対多の関係にブリッジテーブルが必要になる点
ナレッジグラフ / セマンティック チーム	RDF/オントロジー表現	ツールの成熟度とクエリパフォーマンス
設計およびガバナンス ワークショップ	概念/ER 表記法	図と機械可読モデルとの間の乖離（ドリフト）

最後の行が最も一般的な失敗パターンです。チームが美しい図を維持していても、それがバージョン管理されたモデルと一致しなくなることがあります。図はリポジトリのアーティファクトから生成するか、少なくともそれらと整合性を保つようにしてください。

CIM ニュース

「CIM ニュース」セクションでは、外部の報道（発表、アナリストのコメント、コミュニティの寄稿）を集約しており、プロジェクト外部で CIM がどのように受け止められているかを確認できます。これは、主に2つの理由で有用です。

まず、サードパーティによる検証が得られます。共有モデルの採用を提案する場合、プロジェクト独自のマーケティングを引用するよりも、独立した報道を引用する方が説得力があります。第二に、コアドキュメントではカバーされていない可能性のある、現実世界での導入事例や統合パターンが明らかになります。

ニュース報道は批判的に読んでください。発表では、実際に導入された本番環境での利用状況ではなく、意図やパートナーシップについて説明されることがよくあります。「組織Xが取り組みに参加した」ことと、「組織XがシステムYの本番環境でCIMを運用している」ことを区別してください。前者は一般的ですが、後者こそが「構築か採用か（build-vs-adopt）」の決定において重要な証拠となります。

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

CIM GitHub 組織

GitHub 組織は、実体（substance）が存在する場所です。技術的な読者にとって、ここが最も重要な目的地となります。ここでは以下のような内容が見つかります：

• モデル定義 — CIMを構成するエンティティ、属性、関係、および制約。
• ツール — モデルからアーティファクトを検証、変換、生成するためのスクリプトとユーティリティ。
• バージョン管理と履歴 — モデルがどのように進化し、なぜそうなったかを示すコミット履歴。
• Issueとディスカッション — 提案、質問、決定の作業記録。

いくつかの実践的な習慣を取り入れることで、リポジトリはより有用になります：

• デフォルトブランチを追跡するのではなく、リリースまたはタグにピン留めしてください。そうすることで、プロジェクトの途中でマッピングが変更されることを防げます。
• 関心のあるエンティティを採用する前に、そのコミット履歴を読んでください。1年間に3回変更されたフィールドは、その領域が不安定であることを示唆しています。
• 各リポジトリの ライセンスを確認してください。オープンソースプロジェクトでは、ツールとモデルコンテンツでライセンスが混在している場合があります。
• 曖昧な点についてはIssueを立ててください。 関係のカーディナリティ（多重度）が不明確な場合、その曖昧さはすべての下流チームに悪影響を及ぼします。早期に提起することで、全員にとってモデルが改善されます。

サプライチェーンやプロベナンス（由来）に関する厳格な要件を持つ組織は、他のサードパーティ依存関係をレビューするのと同様に、ライセンス、メンテナンス活動、貢献者の多様性、リリースの頻度などの観点からリポジトリをレビューしてください。単一のメンテナに依存しているモデルは、広範な組織的支援があるモデルとは異なるリスクプロファイルを持ちます。

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

よくある質問

クラウド情報モデル（CIM）は購入できる製品ですか？

いいえ。CIMはオープンソースのデータモデル（定義とサポートするアーティファクトのセット）であり、The Linux Foundationの下で管理されています。自社システムをCIMにマッピングし、公開されたモデル定義を使用することで採用します。モデル自体にライセンス料はかかりません。ベンダーがCIMをサポートまたは組み込んだ製品を構築することはありますが、モデル自体は商用製品ではありません。

CIMを使用するために、既存のシステムを置き換える必要がありますか？

いいえ、それこそがポイントです。CIMは、システム間の正準交換モデル（canonical interchange model）として機能するように設計されています。アプリケーション、データベース、ウェアハウスはそのまま保持し、各システムからCIMへのマッピングを構築します。これは漸進的に行えます。まず単一の高価値な統合から始めて、時間をかけてカバー範囲を拡大することが可能です。

CIMを利用するには、どのフォーマットを使用すべきですか？

利用者に依存します。APIおよびアプリケーションチームは一般的にJSONスタイルのスキーマ表現を好みます。ウェアハウスおよびETLチームはリレーショナルまたは表形式のマッピングを好みます。セマンティックおよびナレッジグラフチームはRDF/オントロジー表現を好みます。重要なテストは「ロスレス・ラウンドトリップ（無損失の往復変換）」です。確定させる前に、フォーマット間の変換によって関係性と制約が維持されることを確認してください。

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

これらは隣接する問題領域を扱っています。UBLやOAGISは、当事者間で交換されるビジネス「ドキュメント」や「メッセージ」に重点を置いていますが、CIMはアプリケーションがマッピングする共有の「エンティティモデル」を重視しています。実際にはこれらは補完的に利用できます。正準エンティティモデルがあることで、ドキュメント標準にどのようにデータを投入するかが明確になります。一方がもう一方を置き換えると考えるのではなく、特定のユースケースにおける重複を評価してください。

CIMに貢献するにはどうすればよいですか？

貢献は主にCIM GitHub組織（Issue、プルリクエスト、ディスカッション）および、本サイトからリンクされているコントリビューター用Webフォームを通じて行われます。モデルはコミュニティによってガバナンスされているため、提案はオープンにレビューされます。まずは小さなことから始めてください。曖昧な定義を明確にするか、明確な根拠を持って不足している属性を追加することから始め、大規模な構造変更を提案する前にメンテナと協議してください。

技術者以外のステークホルダーはどこから始めればよいでしょうか？

まずCIMプレゼンテーションとFAQを確認し、次に「CIM in the News」をざっと読んでサードパーティの文脈を把握してください。これにより、モデル定義を読み込まなくても、導入の動機と語彙を理解できます。パイロット導入する統合候補が決まった段階で技術チームを参加させ、GitHubリポジトリに基づいて作業を進めてもらってください。

参加とさらなる学習

共有モデルの採用は、技術的な取り組みであると同時に組織的な取り組みでもあります。最も成功しているCIMイニシアチブは、まず単一の境界が明確な統合（現在2つのシステム間で脆弱なカスタムマッピングが必要な箇所など）から始めて、正準モデルアプローチを証明し、その後拡大する傾向があります。ガバナンスが重要です。社内のCIMマッピングを誰が所有するのか、モデルバージョンのアップグレードをどう扱うのか、ビジネス定義間の競合をどう解決するのかを早期に決定してください。

スチュワードシップとオープンガバナンスの背景については、Wikipediaの Linux Foundation を参照してください。関連する標準化作業については、OASIS Universal Business Language や schema.org が、正準モデルアプローチを比較する際の有用な参照点となります。セマンティックモデリングをより深く掘り下げるには、オントロジー形式の表現の基礎となるRDFおよびOWL仕様を公開している World Wide Web Consortium (W3C) を参照してください。

本サイトのナビゲーションを使用して、プレゼンテーション、FAQ、フォーマットドキュメント、ニュースまとめ、GitHubリポジトリにアクセスしてください。また、モデルの形成に参加する準備ができたら、コントリビューター用Webフォームをご利用ください。