EDM：マスタデータ（ディメンション）の統制と配信
モジュールの役割と位置づけ
Section titled “モジュールの役割と位置づけ”EDM は、複数のシステムに散らばるマスタを「変更の入口を一つにして、承認を経て、各システムへ配信する」仕組みです。扱うのは取引や残高ではなく、勘定科目・会社・部門・製品といったディメンション（データの切り口）とその階層・属性です。GL の COA と、Planning や FCC のメンバーが食い違うと、残高の取込でマッピングエラーが出て、連結や予実の数字が合いません。EDM は入口を一つにしてこれを防ぎます（共通マスタデータの設計）。
| 役割 | 内容 | 主な機能 |
|---|---|---|
| 統制 | 変更を申請・検証・承認し、履歴を残す | リクエスト、ワークフロー、ポリシー、検証、監査 |
| 整合 | 複数アプリのマスタを揃え、差異を見つける | サブスクリプション、比較、重複排除 |
| 配信 | 確定したマスタを各システムへ渡す | インポート・エクスポート、接続、Extract |
Fusion GL でも COA の値とツリーは直接管理できます（COA・元帳）。EDM はその上流に置いて承認と配信を担わせる選択肢で、GL の仕組みは変わりません。提供形態は、スタンドアロンのサービスと、EPM Enterprise Cloud Service 内でレコード数に制限のあるビジネス・プロセスです（EPM Cloud の全体像）。オンプレミスの DRM から移行する公式ガイドもあります。
使用する組織（EDM ではアプリケーション構造）
Section titled “使用する組織（EDM ではアプリケーション構造）”EDM に法的エンティティ・BU・元帳のような Fusion の組織設定はありません。アプリケーション構造を設計し、Fusion の会社（貸借一致セグメント）や部門は、ディメンションのノードで表します。
| 要素 | 内容 | 例（架空） |
|---|---|---|
| アプリケーション（Application） | 管理対象のシステム。登録（register）か作成で用意する。種類は Fusion GL、E-Business Suite GL、Planning・FreeForm、FCC、EPCM、Tax Reporting、Universal | サンプル商事の Fusion GL アプリ |
| ディメンション（Dimension） | データの切り口。Fusion GL ではセグメント | 勘定科目、部門 |
| ノード・タイプ（Node type） | ノードの種類と、持つプロパティの定義 | 勘定科目 |
| ノード（Node） | マスタ 1 件。Fusion GL では値（Value） | 科目 411000 |
| プロパティ（Property） | ノードの属性。直接指定・継承・式による導出（derived）の値がある | 名称、勘定タイプ |
| ノード・セット／階層セット | ビューポイントが参照するノードのまとまり（リスト用と階層用）／階層（親子関係）の定義 | 勘定科目階層 |
| ビューポイント（Viewpoint） | ユーザーがノードを操作する画面 | 科目の階層ビューポイント |
| ビュー（View） | ビューポイントをまとめる入れ物。登録時にデフォルト・ビューができる | 経理用ビュー |
Universal は、他のすべてのビジネス・アプリケーションと連携するためのオープンなインタフェースです。ワークフローの説明には、1 つのアプリケーションを扱う application view と、複数のアプリケーションにまたがる関連変更を扱う maintenance view が出てきます。
ビューポイントとデータチェーン
Section titled “ビューポイントとデータチェーン”見えるノードと階層はデータ・チェーンで決まります。
階層：ビューポイント → ノード・セット → 階層セット → ノード・タイプ（1 つ以上）リスト：ビューポイント → ノード・セット → ノード・タイプ（1 つ以上）ビューポイントには、編集できるプロパティ、実行できるアクション（Add・Insert・Move・Remove・Delete・Reorder）、プロパティの表示ラベルを設定します。Reorder は、階層セットが custom sort order を許可しているときだけ選べます。「説明は直せるが、科目コードの変更と移動はできない」ビューポイントを現場向けに作れます。
Fusion GL との対応
Section titled “Fusion GL との対応”| EDM | Fusion GL |
|---|---|
| ノード／ディメンション | 値（Value）／セグメント（Segment） |
| リスト・ビューポイント | 値セット内の値の一覧 |
| 階層ビューポイント | ツリー・コード内のツリー・バージョンの関係 |
GL アプリケーションを登録すると、ディメンション・ノード・タイプ・リスト・ノード・セット（セグメントと値セットに対応）、ビューポイント・階層ノード・セット・階層セット（ツリーとツリー・バージョンに対応）、アプリケーションとデフォルト・ビューが作られます。登録には Application - Create ロールが必要で、登録者には、そのアプリケーションとデフォルト・ビューの Owner 権限が自動で付きます。
リクエストとワークフロー
Section titled “リクエストとワークフロー”変更はリクエストで行います。リクエストはアイテム（変更 1 行）の集まりで、アイテムは検証・承認・コミットが一括です。ステージは 4 つです。
| ステージ | 内容 | 備考 |
|---|---|---|
| Submit | 作成、アイテム編集、コメント、割当、共同作業、送信 | 下書きは Draft |
| Approve（任意） | 承認者が Approve・Enrich・Push back・Reject | approval policy で有効 |
| Commit（任意） | コミッターが Commit・Push back・Reject | commit policy で有効 |
| Closed | 履歴の照会 | notification policy は Commit 完了後に適用 |
- 送信時に検証と制約（Validations and Constraints）が走り、ポリシーがなければそのままコミットされてビューポイントが更新されます。approval policy は application・dimension・hierarchy set・node type の単位で設定でき、複数が並行して実行されます。設定項目（承認者の指定など）は、公式の Configuring Policies で確認してください。
- Push back は送信者へ戻して再送信させる操作（状態は Pushed Back）、Reject は完全終了、Recall は送信者だけが送信後（In Flight・Blocked・Future Dated）に引き戻す操作です。
- Enrich は、approval policy で有効にすると、承認者が承認前にアイテムを追加・削除・編集できる機能です。
- 四つの目の原則で、既定では送信者は承認者から除外されます。
- Blockout period は Owner か Metadata Manager が設定します。期間中のリクエストは Closed の直前で Blocked のまま保持され、アクティブなビューに反映されません。期間後に検証し、エラーなしなら Closed、ありならワークフローへ戻ります。
サブスクリプション
Section titled “サブスクリプション”ターゲット・ビューポイントがソース・ビューポイントを購読すると、ソースの変更と同じ変更をターゲットに行うリクエストが自動生成されます。たとえば Planning・FCC のビューポイントが GL のビューポイントを購読すれば、GL に追加したコスト・センターが、両方へのリクエストになります。
| 設定 | 内容 |
|---|---|
| Actions・Top Nodes・Node Conditions | 購読を絞る（Add・Insert・Move・Property Updates・Remove／階層のトップノード／例：勘定タイプが Asset） |
| Auto-submit／Manual submit | 生成したリクエストを自動送信するか、担当者が送信するか |
| Bypass Approvals | 自動送信で全アイテムが有効なら、Approve を飛ばして Commit へ進む |
| Assignee・Create Standalone Request | 担当者。同じ担当者のリクエストは統合され、後者を有効にすると単独にする |
| Node Type Converter | ノード・タイプが違うときの変換。Copy・Force Copy・Transform |
- 変換できないアイテムはスキップされます。全アイテムが有効で Auto-submit なら送信されて Completed、そうでなければ Draft のまま担当者へ通知されます。
- 統合リクエストの条件は、ソースのビューが同じ、ターゲットのビューが同じ、担当者が同じ、Create Standalone Request が無効、の 4 つです。複数のサブスクリプションが絡むとき、全部で Bypass Approvals が有効なら Commit へ進み、1 つでも無効なら全アイテムが承認の対象です。
- Copy は、対象プロパティがソースで更新されたときだけ値をコピーし、継承・指定・導出の値は対象外です。Force Copy・Transform は、ノードがアクションに関わっていればコピー・変換します。
- ビューポイントやディメンションをアーカイブすると、関連するサブスクリプションは無視されます。
公式ガイドの Compare and Rationalize の項目に、ビューポイントを並べて表示してノードの位置を揃える機能、ノード・関係・プロパティの比較、アプリケーションをまたぐ比較、重複ノードの排除があります。導入時は、既存マスタを取り込んで比較し、差異を解消してから EDM を正にします。手順はリリースにより異なるため、公式で確認してください。
主要な業務プロセス
Section titled “主要な業務プロセス”新規勘定科目の新設（架空の例）
- 経理担当（申請者）が、EDM でリクエストを作成します。新ノード（科目コード
411500）を階層上の位置を指定して Add／Insert し、名称・勘定タイプなどを入力します。 - 送信すると検証が走ります。approval policy に従い、経理責任者が承認します（申請者本人は承認者になれません）。commit policy があればコミッターが Commit します。
- サブスクリプションが、Planning・FCC のビューポイント向けリクエストを自動生成します。Auto-submit と Bypass Approvals を設定したものはコミットまで進みます。
- Fusion GL へは、エクスポートした内容を GL でロードし、勘定科目階層を公開します。EPM へは、接続またはファイル（EPM Automate の
exportDimensionなど）で配信します。 - Data Integration のマッピングを確認し、残高の取込を試します。
組織改編は、Move・Remove をまとめた 1 つのリクエストで行い、多数の変更はファイルから作ります（Loading Changes From Files）。4 月 1 日付の変更には将来日付（Future Dated）の状態があり、事前に申請・承認できます（設定方法は公式で確認）。決算期間は blockout period で変更を保留します。導入時は、GL の値セットとツリー、EPM のディメンションを取り込み、比較で差異を解消して EDM を正にします。
マスタデータ
Section titled “マスタデータ”| マスタ | 内容 | 作成場所・UI | 移行・配信手段 |
|---|---|---|---|
| アプリケーション・ディメンション・ノード・タイプ | 管理対象と構造 | EDM（登録または作成。Application - Create） |
GL は取込ファイルから登録 |
| ノード（マスタ本体） | 科目、部門、製品など | リクエスト、ビューポイントのロード | importDimension、loadViewpoint、ファイルからのリクエスト |
| ビュー・ビューポイント・階層セット | 見せ方と階層 | EDM のビュー設定 | 登録で自動作成、または手動 |
| ポリシー・検証・サブスクリプション | 承認、入力規則、伝播 | EDM の設定 | 画面 |
| 接続・ユーザーとロール | 取込元・配信先、権限 | 接続、EPM 共通のアクセス制御 | assignRole など |
作成順序：ロール → アプリケーション（GL は先に値セットとツリーを用意）→ 既存マスタの取込と比較 → ビューポイント・検証 → ポリシー・blockout period → サブスクリプション → 接続・エクスポート・自動化 → 各システムでの直接編集の制限。ポリシーやサブスクリプションは、対象のノード・タイプ・階層セット・ビューポイントが先にあることが前提です。
他モジュールとの連携
Section titled “他モジュールとの連携”| 連携 | データ | 手段 |
|---|---|---|
| EDM → Fusion GL | COA の値セットの値とツリー | エクスポート → GL でロード → 勘定科目階層を公開 |
| Fusion GL → EDM | 同上（導入時・再同期） | フラットファイル（直接インポート不可） |
| EDM → EPM アプリ | ディメンション（メンバー・階層・属性） | サブスクリプションで各アプリのビューポイントへ反映 → 接続・ファイル・EPM Automate で配信 |
| EDM ↔ 外部システム | 任意のマスタ | Universal アプリケーション、Extract、ビューポイントのロード、REST、Oracle Integration |
Fusion GL（COA の値セット・ツリー） の公式シナリオは、次の順です。
- GL で値セットと（階層があれば）ツリーを用意し、EDM に GL アプリケーションを登録します。
- GL のセグメント（値セットとツリー）を含むフラットファイルを EDM に取り込みます。GL からの直接インポートはできません。ファイルの扱いには、Fusion の UCM へアップロードする権限（例：Financial Application Administrator ジョブ・ロール）が前提です。
- EDM でリクエストによりデータを変更し、エクスポートして、GL サービスでロードします。
- 勘定科目階層を公開します。階層を使うレポートなどに新しい親子関係を反映するための手順で、忘れやすい点です（COA・元帳）。
ファイル形式、Fusion 側のロード手順とジョブ名は、公式の Detailed Steps で確認してください。このページでは確認できていません。
EPM には、Planning・FreeForm、FCC、EPCM、Tax Reporting それぞれの連携の章があります。Planning は、手動のエクスポート／インポート、EPM Automate、Groovy ルールの 3 通りの公式チュートリアルがあります。EDM が運ぶのはマスタで、残高は Data Integration で取り込みます。順序は、マスタ配信 → マッピング更新 → 残高の取込です（FCC、Planning も参照）。
標準機能とアドオン
Section titled “標準機能とアドオン”| 要件 | 標準でできること | 足りないとき |
|---|---|---|
| 申請・承認 | リクエスト、各ポリシー、Enrich | 社内の申請システムとの連携（Oracle Integration、REST） |
| データ品質 | 検証と制約、式によるカスタム検証 | 外部の検証サービスの呼出し（External Custom Validations） |
| 属性の計算 | 導出プロパティ、式、コンバーター | 複雑なら外部で計算して取込（保守に注意） |
| 他アプリへの伝播 | サブスクリプション、エクスポート、接続 | Oracle Integration による配信・通知 |
Fit to Standard では、まず標準のポリシー・検証・サブスクリプションで業務ルールを表せるか確認します。式の独自ロジックは、EPM 共通の月次更新のたびに再テストが要り、保守が増えます（標準機能とアドオンの考え方）。
ベストプラクティス
Section titled “ベストプラクティス”- 正を EDM に一本化し、GL・Planning・FCC の画面からの直接編集をロールで制限します。逆方向の更新は作りません。
- データ・オーナーごとに approval policy を作ります（勘定科目は経理、部門は経営企画など）。四つの目は既定のまま使い、例外は理由を決めて明示します。
- 検証を先に作り（コードの桁数、必須属性、親子の制約）、承認者が内容の判断に集中できるようにします。
- リクエストは業務上の意味でまとめます。アイテムは一括で承認されるので、「科目の新設＋配置＋属性」を 1 つにし、無関係な変更を混ぜません。
- Bypass Approvals は、承認済みマスタの機械的な伝播に限ります。統合リクエストに無効なものが 1 つあると、全アイテムが承認の対象になります。Auto-submit のリクエストは Draft で滞留しうるため、通知と確認を運用に入れます。
- 自動化は専用のサービス・アカウントで行い、パスワードは
encryptしたファイルか秘密管理から渡します。
日本での導入の考慮点
Section titled “日本での導入の考慮点”次は、確認できた範囲の整理です。
- 日本語：画面とガイドの日本語対応の範囲は確認できていません（公式サイトに Translated Books のページはありますが、EDM のガイドが含まれるかは未確認）。コードと日本語の名称をプロパティで分ける設計が一般的で、ファイルは UTF-8 を推奨します。
- 勘定科目体系：科目・補助科目・部門コードの体系が確立した会社が多く、日本基準と IFRS の併用や、管理会計用の集約階層もあります。EDM には同じノードから別の階層を作る機能（Creating Alternate Views and Viewpoints）があるため、用途別の階層を検討できます。
- 組織改編と決算：4 月 1 日付の改編は、Fusion のツリー・バージョンの有効日（COA・元帳）と EDM の Future Dated を組み合わせ、事前に申請・承認します。決算期間は blockout period を検討します。
- 内部統制：申請者・承認者・履歴は、リクエスト履歴や監査（Audit）で確認できます。J-SOX の証跡として足りるかは、監査人と運用設計で確認してください。
- EPM 共通の月次更新があります（
skipUpdateは下の表）。連携先とは、テスト同士・本番同士で組みます。 - 日本の会計基準向けのテンプレートなど、EDM 固有の日本向け機能は、確認した範囲のガイドに記載がありません。
実装リファレンス
Section titled “実装リファレンス”EPM Automate
Section titled “EPM Automate”EDM の環境のコマンド一覧にあるものです。引数と終了コードは、各コマンドの公式ページで確認してください。
| コマンド | 用途 |
|---|---|
login・logout・encrypt |
接続と切断。encrypt でパスワードやリフレッシュ・トークンを暗号化して保存 |
importDimension |
ファイルから EDM のアプリケーションにディメンションをインポート |
exportDimension |
ディメンションを、ステージング領域か、接続で定義した先の環境へエクスポート |
extractPackage |
複数の Extract を 1 回で実行し、結果を 1 つの ZIP にまとめる |
loadViewpoint・loadDimensionViewpoint |
ロードファイルからビューポイントにデータをロード（後者は定義済みのロードを使う） |
uploadFile・downloadFile・listFiles・deleteFile |
ファイル操作 |
exportSnapshot・importSnapshot |
Migration コンテンツのスナップショットの作成と取込 |
assignRole・addUsers |
CSV によるロールの割当、ユーザーの一括作成 |
skipUpdate |
月次更新の適用を最大 3 サイクル連続でスキップするよう Oracle に要求（要求の削除も可） |
自動化の組立て例は、login（認証情報は環境変数や秘密管理から渡す）→ uploadFile → importDimension → exportDimension → downloadFile → logout です。コマンドの用途からの一例で、公式の手順ではありません。ログインの書式は EPM データ統合 の例を参照してください。
REST API・インポート／エクスポート
Section titled “REST API・インポート／エクスポート”公式の REST API for Oracle Fusion Cloud Enterprise Data Management で、タスクを自動化できます。リソースは階層構造で、GET は取得、POST は作成またはオペレーションの実行、PUT は更新、DELETE は削除です。エンドポイント、認証、非同期ジョブの扱いは、公式の REST ガイドで確認してください（概要ページのみ確認）。
取込元・配信先の環境は、アプリケーション接続・グローバル接続（Creating Application Connections、Creating Global Connections）で定義します。ディメンションの出入りは importDimension・exportDimension、抽出は Extract、ファイルからの投入は Viewpoint Loads です。
試験対策ポイント
Section titled “試験対策ポイント”- 対応試験：Oracle Enterprise Data Management Cloud 2026 Implementation Professional（1Z0-1086-26）。EDM 模擬テスト で演習できます。
- 形式：日本オラクルの認定試験一覧（2026 年 10 月確認）に 2026 年版の行はありません。2025 年版（1Z0-1086-25-JPN）は 50 問・90 分・合格 68%（2026/10/30 に配信終了）で、本サイトは暫定でこの値を使います。差分試験（1D0-1086-25-D-JPN）は 25 問・60 分で、別に以前のバージョンの試験の合格が必要です。
- 分野（このサイトの整理。公式の出題範囲は未確認）：概要とアプリケーション構造、ビューとビューポイント、リクエストとガバナンス、サブスクリプションと比較、インポート・エクスポートと連携、運用・自動化。
- 覚えること：データ・チェーン（階層は 4 段、リストは 3 段）、4 ステージとポリシーの対応、Push back・Reject・Recall の違い、blockout period を設定できるロール、サブスクリプションの設定と統合リクエストの条件、GL は直接インポート不可でロード後に階層を公開、
importDimension・exportDimension・extractPackage・loadViewpointの違い。 - 判断ポイント：「承認を省いて伝播」→ Auto-submit と Bypass Approvals（無効が 1 つでもあれば全アイテム承認）。「複数アプリにまたがる承認」→ maintenance view か、サブスクリプションをトリガーにした承認。
公式ドキュメント
Section titled “公式ドキュメント”本サイトは学習目的で個人が作成した非公式の教材であり、Oracle Corporation およびその関連会社とは関係ありません。内容の正確性は保証しません。最新の仕様・試験範囲は必ず公式ドキュメントと Oracle University の情報で確認してください。
模擬テストの問題は公開されている出題範囲（Exam Topics）と公式ドキュメントをもとに独自に作成したもので、実際の試験問題ではありません。
Oracle、Java、MySQL は Oracle Corporation およびその子会社、関連会社の米国およびその他の国における登録商標です。その他の製品名・会社名は各社の商標です。
© 2026 Fusion ERP 実装ラボ