ガイド · 組織の文脈
人とエージェントが使える文脈の構築方法。
Understanding Layerは、「組織の中で、このデータは何を意味するのか」というシンプルな問いから始まります。このガイドは、その問いを業務、システム、セキュリティの各チームが共同でレビューできるモデルに変えます。
共通の言葉でエンティティを定義
同じ顧客、資産、イベントが、複数のシステムで異なる識別子を持つ場合があります。まずエンティティの定義と、各属性の正本となる情報源を合意します。組織全体を一度にモデル化するのではなく、文脈の不足が判断や実行を遅らせている1つの業務フローに焦点を当てます。
判断に影響する関係を追加
資産一覧だけでは、所有者や障害が影響する業務は分かりません。所在地、保守担当、依存先などの関係を追加します。各関係は実務上の問いに役立ち、組織が認識し信頼する人や情報と照合できる必要があります。
例:資産のインシデント
例として設備故障が報告されると、文脈モデルが設備を拠点、保守責任者、既存の作業指示書に関連付けます。新たなタスクを作るか、進行中の作業に情報を追加するかの判断に役立ちます。判断は引き続き、合意したルールと権限に従います。
情報源、意味、操作を区別
元システムが記録を保持し、Understanding Layerが意味と関係を定義します。エージェントは文脈を使って回答や操作案を提示し、管理機構が実行可能な範囲を決めます。この分離により、データ品質、定義への異議、権限不足のどこに問題があるか把握できます。
情報の鮮度と矛盾を確認
人の役割変更、資産の拠点移動、システム変更に伴い、組織の文脈も変わります。モデルの更新担当者と、情報源の矛盾への対処を定義します。古い関係や出所不明の値に基づくなら、流暢な回答だけでは十分ではありません。
最初のマップに含めるべきもの
最初の有用なマップには、ビジネス上の問い、絞り込んだエンティティ、必要な関係、正本となる情報源が含まれます。責任者と、目指す判断または操作も加えます。どの部分をエージェントに利用させるか決める前に、実例と例外を業務担当者と確認します。
次のステップ
どの問いに、より多くの組織の文脈が必要ですか?
業務フローを1つ選び、理解に必要なエンティティと関係を特定します。