メタデータ

概要

メタデータ計算機は、データセットがどのように生成、抽出、構成されたかに関する包括的な技術情報を表示します。このゼロコンフィギュレーション計算機は、バージョニング情報、ETL構成、タイムゾーン設定、主要カラムのマッピングなどの重要なメタデータを提供します。

プロセスデータを分析する計算機とは異なり、メタデータはデータセットの技術的基盤—抽出日時、使用されたETLパイプラインのバージョン、タイムスタンプの解釈方法、ケースIDやアクティビティなどのプロセスマイニングのコア概念にマップされるカラム名—を明らかにします。

主な利用例

抽出タイムスタンプと最終更新からデータの鮮度を検証
タイムゾーン設定やローカル時間設定を確認してタイムゾーンの問題をトラブルシュート
コンプライアンスや監査要件のためにデータ由来を文書化
トランスフォーマーのバージョンや設定を検証してETL構成を確認
カスタムスクリプト用のコアカラム名を特定して技術的トラブルシューティングをサポート
開発、テスト、本番など複数環境間のデータセットバージョン管理を追跡

設定

この計算機は設定不要です。データセットからすべてのメタデータを自動的に取得し、包括的なテーブルで表示します。

利用可能な標準フィールドは以下のみです：

Title: 出力の任意のカスタムタイトル（デフォルトは「Metadata」）

Description: このメタデータビューの文脈を提供する任意の説明

例

例 1: 意思決定のためのデータ鮮度の検証

シナリオ: 財務チームが月次ビジネスレビュー会議を準備しており、最新の買掛金データを分析していることを確認する必要があります。古いデータでは支払パフォーマンスについて誤った結論が出る可能性があります。

設定:

Title: "データの鮮度チェック"
Description: "APプロセス - 月次レビュー"

出力:

計算機は、データセットのすべてのメタデータを2列のテーブルで表示します。データ鮮度の主な指標は以下です：

最後に成功したデータ抽出: 2025-10-19 6:00:00 AM
最終抽出からの時間（時間）: 2.5
抽出バージョン: 3.2.1
現在時刻: 2025-10-19 8:30:00 AM
TimeZoneName: Eastern Standard Time
ProcessDisplayName: 買掛金プロセス

洞察: データは今朝6時に2.5時間前に抽出されており、昨日完了した作業に対応していることが確認できます。チームは現在のデータを使用していることを確信して分析を進められます。「最終抽出からの時間」が数日であれば、会議の前にデータ更新を依頼する必要があります。

例 2: タイムゾーンの不一致のトラブルシューティング

シナリオ: ユーザーからプロセスのタイムスタンプがソースのERPシステムで見える時間と一致しないとの報告があります。ビジネスが朝8時開始なのに一部のケースが午前4時に開始しているように見えます。タイムゾーン設定の問題が疑われます。

設定:

Title: "タイムゾーン設定レビュー"
Description: "タイムスタンプ解釈問題の調査"

出力:

メタデータ計算機はタイムゾーン設定を明示します：

TimeZoneName: UTC
IsLocalTime: False
現在時刻: 2025-10-19 12:30:00 PM
Start Time: StartTime
End Time: EndTime
UseDateOnlySorting: False

洞察: データセットはローカル時間ではなくUTC時刻を使用するよう設定されている(IsLocalTime: False)ため、4時間のずれが説明できます。ビジネスは東部標準時 (UTC-4) で運営されているため、データ上では4:00 AMに見える時刻は実際にはローカル時間の8:00 AMに相当します。ETLを東部標準時で再設定するか、すべての時刻がUTCで表示されていることをユーザーに周知する必要があります。これによりプロセスタイミングの誤解やパフォーマンス指標の誤用を防げます。

例 3: 監査コンプライアンスのためのデータ由来文書化

シナリオ: 社内監査チームがすべてのプロセスマイニング分析に使われたデータソース、抽出方法、バージョニングの文書を要求しています。請求処理分析の追跡可能性と信頼性を検証したいとのことです。

設定:

Title: "データ由来 - 2025年第4四半期コンプライアンス報告"
Description: "請求処理分析メタデータ"

出力:

メタデータテーブルは包括的な由来情報を提供します：

ProcessDisplayName: 請求処理
TransformerFilename: InvoiceProcessing_SAP_Config.json
TransformerVersion: 2.1.0
Extraction Version: 1.8.3
EngineAttributeVersion: 8.0.2
ProcessAttributeVersion: 3.4.1
最後に成功したデータ抽出: 2025-10-15 11:45:00 PM
Etl Notes: SAP ECC本番システムからの完全抽出
Description: コンプライアンス報告向け2025年第4四半期請求処理
BaseCurrency: USD

洞察: 監査チームはデータがどのように生成されたかを正確に追跡できます：10月15日にSAP ECC本番環境から、トランスフォーマー構成バージョン2.1.0と抽出パイプラインバージョン1.8.3を使って抽出されたことを確認。記録されたバージョンにより承認済みのETLプロセスが使われたことを検証できます。「Etl Notes」には生産環境からのデータであることが明記されており、テストシステムではありません。完全な由来トレースは監査要求を満たします。

例 4: カスタムPythonスクリプト開発のサポート

シナリオ: データアナリストがRでの追加分析用に特定のケース属性をエクスポートするカスタムPythonスクリプトを作成しています。正しいクエリを書くためにデータセットで使われている正確なカラム名を知る必要があります。

設定:

Title: "カラムマッピング参照"
Description: "カスタムスクリプト用コアカラム名"

出力:

メタデータ計算機はコアカラムのマッピングを表示します：

CaseId: PurchaseOrderNumber
Activity: ProcessStep
Start Time: EventTimestamp
End Time: EventTimestamp
Resource: PerformedBy
ExpectedOrder: StepSequence

洞察: アナリストはこのデータセットが標準のデフォルト名ではなくカスタムカラム名を使用していることを発見しました。ケース識別子は「PurchaseOrderNumber」（"CaseId"ではない）、アクティビティは「ProcessStep」（"Activity"ではない）、リソースは「PerformedBy」（"Resource"ではない）に格納されています。これらの正確なカラム名が分かることで、正確なSQLクエリやPythonスクリプトを書けます。この情報がなければカラムが見つからないエラーでスクリプトが失敗します。

例 5: 環境間のバージョン互換性チェック

シナリオ: 組織は開発、テスト、本番の3つのプロセスマイニング環境を運用しています。新しいダッシュボードを本番に昇格させる前に、全環境が互換性のあるデータ抽出パイプラインのバージョンを使っており一貫した挙動が保証されていることを確認する必要があります。

設定:

Title: "バージョン互換性 - 本番環境"
Description: "展開前の検証"

出力:

本番環境のメタデータ：

Derived Attribute Version: 2.3.1
Extraction Version: 1.9.0
ProcessAttributeVersion: 3.5.0
EngineAttributeVersion: 8.1.0
TransformerVersion: 2.2.0

テスト環境（別のMetadata計算機から）との比較：

Derived Attribute Version: 2.3.1 (一致)
Extraction Version: 1.9.0 (一致)
ProcessAttributeVersion: 3.4.1 (不一致 - 本番が新しい)
EngineAttributeVersion: 8.1.0 (一致)
TransformerVersion: 2.2.0 (一致)

洞察: 5つのバージョンのうち4つは完全に一致し、大部分は互換性があります。しかし、本番環境ではプロセス特有の属性バージョンが新しく(3.5.0 vs 3.4.1)、追加または変更されています。テストから本番へのダッシュボード展開前に、テストに存在するが本番で変更された可能性のある属性に依存していないかを確認する必要があります。この事前チェックにより展開失敗を防ぎ、環境間で一貫した分析を保証します。

例 6: 自動ETLパイプラインの状態監視

シナリオ: データエンジニアリングチームが毎晩実行するETLジョブが午前6時までにプロセスマイニングデータを更新する必要があります。オペレーションチームはログファイルを確認せずにパイプラインの正常実行を即座に確認する方法を求めています。

設定:

Title: "ETLパイプライン状態"
Description: "夜間抽出監視 - オーダー・トゥ・キャッシュ"

出力:

メタデータ計算機は以下を表示：

最後に成功したデータ抽出: 2025-10-18 5:45:00 AM
最終抽出からの時間（時間）: 26.5
抽出バージョン: 1.9.0
Etl Notes: 増分抽出が正常に完了
現在時刻: 2025-10-19 8:15:00 AM

洞察: 「最終抽出からの時間」が26.5時間を示しており、前日の朝の抽出であるため、今朝は抽出に失敗していることが分かります。オペレーションチームは直ちに調査し、データベース接続のタイムアウトが原因で昨晩の抽出が完了しなかったことを発見。朝早くにこれを見つけることで、ビジネスユーザーが古いデータを見て判断を誤る前に再抽出を実行できます。この監視がなければ古いデータに基づく誤った運用判断のリスクがありました。

出力

メタデータ計算機は2列の単一テーブルで、利用可能なすべてのデータセットメタデータを表示します。

テーブル構造:

Name: 各メタデータプロパティまたは設定の名称

Value: そのプロパティに対応する値

情報のカテゴリ

メタデータは複数の論理グループに整理されています：

バージョニング情報:

Derived Attribute Version: 派生属性スキーマのバージョン
Extraction Version: ETL抽出のバージョン識別子
ProcessAttributeVersion: プロセス特有属性スキーマのバージョン
EngineAttributeVersion: エンジン属性スキーマのバージョン
TransformerVersion: 使用されたデータトランスフォーマーのバージョン

プロセス構成:

ProcessName: 内部プロセス識別子
ProcessDisplayName: 読みやすいプロセス名
BaseCurrency: 金銭計算で使用される通貨

時間設定:

TimeZoneName: データセットのタイムゾーン設定
IsLocalTime: タイムスタンプがローカル時刻か（UTCではないか）
現在時刻: タイムゾーン設定に基づく現在時刻
UseDateOnlySorting: イベントを日付のみでソート（時間を無視）するか

コアカラムマッピング:

CaseId: ケース識別子のカラム名
Activity: アクティビティのカラム名
Start Time: 開始時刻のカラム名
End Time: 終了時刻のカラム名
Resource: リソースのカラム名
ExpectedOrder: 期待する順序のカラム名

ETL構成:

TransformerFilename: トランスフォーマー/設定ファイル名
Order Event Algorithm: イベント順序付けアルゴリズム
最後に成功したデータ抽出: 最後のETL実行成功タイムスタンプ
最終抽出からの時間: データの経過時間
Etl Notes: ETLプロセスに関する注記
Notes: データセットの一般的な注記
Description: データセットの説明

出力内容の理解

データ鮮度: 「最終抽出からの時間」を確認してデータが最新かを判断します。24〜48時間以上であればETLパイプラインの問題を調査する必要があります。

タイムゾーンの解釈: 「TimeZoneName」と「IsLocalTime」の組み合わせによりタイムスタンプの表示方法が決まります。IsLocalTimeがFalseの場合、TimeZoneNameの設定に関わらずすべてUTCで表示されます。

バージョントラッキング: すべてのバージョンフィールド（Extraction Version、TransformerVersionなど）は、どのETLパイプラインとスキーマバージョンでデータが生成されたかを追跡し、環境間の問題解決に重要です。

カラム名: コアカラムマッピングはデータセットで使用されている実際のカラム名を示し、デフォルト名と異なる場合があります。抽出時にカスタムマッピングが設定されていた可能性があります。

Null値: プロパティによっては、抽出時に情報がなかったり設定されていなければ空欄や「Unknown」と表示されることがあります。

本ドキュメントはmindzie Studioプロセスマイニングプラットフォームの一部です。