システム・オブ・レコード（SoR）

システム・オブ・レコードとは？

システム・オブ・レコード（SoR）とは、正式に特定の種類のビジネスデータにおける権威ある情報源として指定された情報システムです。特定のドメインのデータが作成、更新、統制、維持され、公式な参照先となる場所であり、不一致が発生した場合に他のシステムが従う基準となります。

簡単に言えば、SoRは単一の信頼できるデータのバージョン（人事記録、デバイスインベントリ、財務取引など）を提供し、特定のドメインについて、他のすべてのシステムがそのSoRに従うことで、組織全体の一貫性、監査可能性、信頼性を確保します。

システム・オブ・レコードが重要な理由

組織はシステム・オブ・レコードを活用してデータオーソリティを確立します。これは、自動化、分析、そして現在ではAIを、リスクではなく信頼できるものにするための基盤です。システム・オブ・レコードは、権威ある運用データの業界標準の枠組みであり、情報が長期にわたり一貫性、持続性、信頼性を維持できるようにします。

• データの一貫性を確保：単一の権威ある情報源を定義することで、ツールやチーム間で矛盾した情報や古い情報が生じるのを防ぎます。
• コンプライアンスと監査を支援：システムや担当者が変わっても、規制対象データの追跡可能性、持続的な状態、説明責任を維持します。
• 信頼性の高い自動化、レポート、AIを実現：下流システムやAIエージェントが、推測されたデータや確率的なデータではなく、信頼され統制された情報に基づいて動作できるようにします。
• 不一致を解決：不一致が発生した際にどのシステムが優先されるかを明確に定め、運用と意思決定における曖昧さを排除します。

先進的な組織は、それぞれ特定のドメインに範囲を限定した複数のシステム・オブ・レコードを運用し、企業全体で信頼性、確実性、自動化を拡張しています。

AI時代にSoRが重要な理由

AIはデータを処理し、インサイトを生成し、アクションを推奨できますが、AIだけで真実を確立することはできません。明確に定義されたシステム・オブ・レコードがなければ、AIは分断され一貫性のない入力に基づいて動作し、不一致を解消するどころか増幅してしまいます。推奨の信頼性は参照するデータの信頼性に依存し、AIはアクションを提案できても、成果、コンプライアンス、監査に対する責任を担えないため、説明責任も損なわれます。

適切に定義されたシステム・オブ・レコードは、AIが依存する信頼できる事実の基準を提供します。実際に存在する資産、所有者、コンプライアンス状況、相互関係の経時的な変化を明確にします。また、AIが信頼性高く推測または再構築できない、持続的な状態、関係性、依存関係、履歴コンテキストを保持します。

組織にシステム・オブ・レコードがない場合、分析、AIの出力、レポート、運用ツールは、現実についての相反する複数の解釈、信頼できない推奨、運用リスクと規制リスクの増大へと陥ります。AIは意思決定を加速しますが、システム・オブ・レコードはその意思決定を安全で、説明可能で、監査可能なものにします。

システム・オブ・レコードに関連する用語や別名は？

システム・オブ・レコードと併用されたり、混同されたりする近い概念の用語がいくつかあります。

• ソース・オブ・トゥルース（SoT）：しばしば同じ意味で使われますが、「ソース・オブ・トゥルース」は正式に統制されたシステムではなく、プロセスやデータセットを指す場合があります。
• マスターデータシステム：企業の中核エンティティ（顧客、製品、資産）に対して一般的に使用されます。
• ゴールデンレコード：権威あるデータ成果物であり、SoRによって生成または維持される検証済みのデータインスタンスです。
• システム・オブ・エンゲージメント／システム・オブ・インサイト：権威あるデータの維持ではなく、ユーザーインタラクションや分析に重点を置く対照的なシステムです。

システム・オブ・レコードは実際にどのように使われますか？

実際の環境では、システム・オブ・レコードは企業全体ではなく、ドメインごとに定義されることが一般的です。例：

• HRプラットフォームは、従業員IDと雇用ステータスのSoRとなる場合があります。
• ERPシステムは、財務データのSoRとなる場合があります。
• IT運用プラットフォームは、資産、エンドポイント、または構成状態のSoRとして機能する場合があります。

Ivanti Neurons Platformは、ITとセキュリティ全体にわたる資産、エンドポイント、構成状態のシステム・オブ・レコードとして機能し、チームが自動化と問題解決に活用できる信頼された運用データを提供します。

ITにおけるシステム・オブ・レコードの例

• CMDB → 構成アイテムとその関係性のSoR
• ITAMプラットフォーム → ハードウェア／ソフトウェア資産の所有権とライフサイクルのSoR
• ITSM→ インシデント、問題、変更、サービスリクエストのSoR
• IDプロバイダー（IdP） → ユーザーIDとアクセス権限のSoR
• HRIS → 従業員記録のSoR（多くのITプロビジョニングの上流）
• 財務ERP → コスト、契約、ライセンス権限のSoR

システム・オブ・レコードとデータオーソリティは同じものですか？

いいえ。密接に関連していますが、これらの概念が答える問いは異なります。

SoRは「公式データはどこに保存され、維持されているのか？」という問いに答えるもので、データが存在する場所に基づきます。一方、データオーソリティは「誰が、または何が、そのデータを定義、検証、統制する権限を持つのか？」という問いに答えるもので、「真実」を公式に宣言し維持する権限を持つ主体を示すガバナンスと信頼の指定です。

データオーソリティについて詳しく読み、ガバナンスの役割、ポリシー、認証プロセスが、公式データが保存されている場所だけでなく、ソースが信頼される理由をどのように決定するのかをご確認ください。

システム・オブ・レコードはどのように誤用または誤解される可能性がありますか？

信頼性を確保するには、明確な範囲とガバナンスが不可欠です。

• ソース・オブ・トゥルース（SoT）との混同：SoRはシステムを指す一方、SoTはデータまたはプロセスを指す場合があります。
• マーケティング上の過剰な主張：一部のプラットフォームは、データを管理・維持しているからではなく、単に連携しているという理由だけで「SoR」であると主張します。
• リアルタイム性の曖昧さ：SoRはバッチ処理またはほぼリアルタイムで動作する場合がありますが、常に「ライブ」であるとは限りません。ほぼリアルタイムのダッシュボードを、権威あるシステムと混同しないでください。

システム・オブ・レコードを指定する際のベストプラクティス

• 主要なデータドメインごとにSoRを割り当てる：複数のシステムが同じ役割を主張しないようにします。
• 慎重に統合する：下流システムが「公式」データを変更しないようにします。
• 同期し、統制する：データ遅延、更新サイクル、整合性チェックに関するポリシーを設定します。

効果的なシステム・オブ・レコードの特徴

• 明確な所有権：ドメインごとに1つのシステム、1人の責任あるオーナーを設定します。
• データ整合性の管理：検証、バージョン管理、監査証跡を備えます。
• 設計段階から権威性を確保：上流システムが迂回せず、このシステムに流れ込むようにします。
• API経由でアクセス可能：下流システムにプログラムによって提供できる必要があります。
• 統制された変更管理：更新は定義されたプロセスを通じて行われます。
• 可観測で監査可能：データの系譜と来歴が透明であることが必要です。

システム・オブ・レコードを指定し実装する方法

データドメインをマッピングする（資産、構成、ユーザー、サービス、インシデント、ライセンス）。

1. ドメインごとに1つのSoRを指定する—明示的に指定し、文書化します。
2. オーナーとスチュワードの役割を割り当てる。
3. 統合パターンを定義する—上流システムがSoRにどのようにデータを供給し、下流システムがどのように利用するかを定義します。
4. ガバナンスと変更管理を確立する。
5. 測定し、徹底する—監査、KPI、ドリフトの是正を行います。