Planning の全体像と試験範囲

この章の結論

• Planning は、予算・予測・シナリオ分析のための EPM Cloud の製品です。Fusion ERP のモジュールではなく別の環境（別 URL・別のロール・別のアップデート）で動きます。ERP は実績を記録し、Planning は計画と見通しを作ります。Planning は仕訳を作りません。
• アプリケーションはキューブとディメンションで作ります（計算エンジンは Essbase）。作成時に Custom、Modules、Sales Planning、Strategic Workforce Planning、Cash Forecasting などから選びます。Modules は Financials・Workforce・Capital・Projects・Strategic Modeling の 5 つで、事前構築のフォーム・計算・ダッシュボードが付きます。
• 実績は Data Integration で Fusion GL から取り込みます。予算・予測は、フォーム・ルール（Calculation Manager、Groovy）・承認で回します。自動化は EPM Automate と REST API、予測は Auto Predict・IPM Insights などの AI 機能です。
• 試験 1Z0-1080-26（Oracle Planning + AI 2026 Implementation Professional）は 50 問・90 分・合格 68%（Oracle 日本語サイトの一覧）です。公式の出題範囲は取得できなかったため、このサイトでは 9 分野で出題します。

モジュールの役割と位置づけ

Planning は、**予算（Budget）・予測（Forecast）・シナリオ分析（What-if）**を行う製品です。Fusion ERP が「何が起きたか」を記録するのに対し、Planning は「これからどうするか」を数字にします。R2R の終点である GL の実績を取り込み、計画と比べて差異を分析し、次の計画に反映します（R2R：記帳から決算・連結・EPM まで）。

業務	目的	Planning での実現（例）
予算	年度の目標を部門・製品・勘定に配分し、承認して確定する	シナリオ「予算」、バージョン「作業中」「確定」、承認
予測（ローリング予測を含む）	実績を踏まえて着地見込を更新する	シナリオ「予測」、実績の取込、Auto Predict
シナリオ分析	前提を変えた複数案を比較する	バージョンの複製と比較。長期は Strategic Modeling

Planning は Fusion ERP とは別の製品です（EPM Cloud の全体像）。

観点	Fusion ERP（GL など）	Planning（EPM Cloud）
環境	Fusion アプリケーションの環境	EPM Cloud の別の環境（別 URL）
データの持ち方	リレーショナルな表。SQL・BIP・OTBI で参照	Essbase のキューブ。SQL では直接参照しない
ロール	ジョブロール・データロール	Service Administrator、Power User、User、Viewer とアクセス権限
アップデート	四半期（26A〜26D）	「年.月」形式（例：25.05、26.09）

アプリケーション構造（キューブ・ディメンション）

Planning は「組織」ではなく、キューブとディメンションでアプリケーションを作ります。この節が「使用する組織」の代わりです。

• キューブ：Essbase のデータベースです。入力と計算に使うブロック・ストレージ（BSO）と、大量データの集計・報告に使うアグリゲート・ストレージ（ASO）があります。Modules を選ぶと、モジュールごとの専用キューブが作られます（例：Financials のキューブ名・プランタイプ名は OEP_FS。公式チュートリアルで確認）。
• ディメンション：データを切る軸です。標準ディメンションと、アプリごとのカスタム・ディメンションがあります。

ディメンション	役割	メンバー例（架空）	Fusion 側の対応（例）
Account	計画する項目。勘定タイプ（収益・費用・資産・負債・資本・保存仮定）を持つ	売上高、人件費	COA の勘定科目セグメント
Entity	計画の単位（会社・事業部・部門）。承認の階層にも使う	JP01 サンプル商事、営業本部	会社・部門のセグメント値
Scenario	目的別の区分	実績、予算、予測	なし（EPM 側で定義）
Version	同じシナリオ内の版	作業中、確定	なし（EPM 側で定義）
Period・Years	月・四半期と年度の時間軸	4月〜3月、FY27	会計カレンダー・会計年度
カスタム	製品、プロジェクト、地域など	Product、Project	製品・プロジェクトのセグメント

多通貨のアプリでは Currency ディメンションも加わります。Custom と Modules では、多通貨は simplified multicurrency で作成します（公式ガイドで確認）。キューブやディメンションの上限数は、サービスとアプリケーションの種類で異なるため、公式のガイドで確認してください。

Planning アプリケーションの構成例（架空）

サンプル商事株式会社 予算アプリ
  ├ 入力用キューブ（BSO）：予算・予測の入力と計算
  ├ レポート用キューブ（ASO）：集計と分析
  ├ 標準：Account / Entity / Period / Years / Scenario / Version
  ├ カスタム：Product、Department
  └ 補助：Smart List、別名テーブル（日本語・英語）、置換変数（現在年度・現在月）

密・疎、キューブの分け方、データロードは アプリケーション設計 で説明します。

主要な業務プロセス

1. 準備：会計カレンダー、シナリオ・バージョンを用意し、置換変数（現在年度・現在月）を更新します。
2. 実績の取込：月次で Fusion GL の残高を Data Integration で取り込みます。
3. 予算編成：本社が方針を示し、部門がフォームや Smart View で入力します。ルールで計算し、承認ユニットで承認して確定します。
4. 予測（ローリング予測）：実績の確定後に着地見込を更新します。Auto Predict などで基準値を作り、現場が補正します。
5. シナリオ分析：バージョンを複製して前提を変え、結果を比較します。
6. 差異分析と報告：予算・実績・予測の差異を、Smart View や Narrative Reporting で共有します。
7. 期末・年度更新：バージョンを確定して編集を止め、年度を追加し、スナップショットでバックアップします。

日本企業での典型的な運用例（設計の一例）

「秋から年度予算を編成 → 毎月の GL クローズ後に実績を取り込む → 月次の予実会議で差異を確認 → 四半期ごとに着地見込を更新」という運用が多く見られます。実績の取込日、入力の締切、承認の期限は、要件定義で先に決めます。

マスタデータ

マスタ	内容	作成場所・UI	移行手段
ディメンションとメンバー	Account、Entity、製品などの階層と属性	Dimensions（管理画面）	importMetadata、EDM
Smart List・別名・置換変数	入力の選択肢、表示名、年度・月の変数	各管理画面	スナップショット
アクセス権限	メンバー・フォーム・ルール単位の権限	アクセス制御	スナップショット
フォーム・ルール・ダッシュボード	画面と計算の定義	フォーム、Calculation Manager	exportSnapshot、importSnapshot

作成順序は、アプリケーション作成（ビジネスプロセス・カレンダー・通貨）→ ディメンション → Scenario・Version・変数 → セキュリティ → 実績ロード → フォーム・ルール → 承認 → テストです。メタデータを変えたら、キューブをリフレッシュします。

複数の EPM アプリで階層をそろえるときは、EDM でマスタを一元管理して配信する設計があります。EDM と Groovy ルールで Planning にメタデータを取り込む公式チュートリアルがあります（EDM）。

他モジュールとの連携

タイミング	連携先	流れるデータ	仕組み
月次（GL クローズ後）	Fusion GL → Planning	勘定残高（実績）	Data Integration。Oracle General Ledger を接続元に登録し、COA のセグメントをディメンションへマッピング
計画の確定後	Planning → Fusion GL	予算・予測	書き戻しの対応範囲は公式ガイドで確認
月次	FCC（連結）	実績・連結結果	EPM アプリ間のデータ連携。範囲は公式で確認（FCC）
報告	Narrative Reporting	管理レポートのデータ	EPM のデータソース接続（Narrative Reporting）
人員データ	人事システム → Workforce	従業員データ	対応するデータソースは Data Integration のガイドで確認

詳細は EPM データ統合 を参照してください。会計の記録は ERP（SLA → GL）で、Planning は仕訳を作りません。取込の前に GL の期間を締めて転記を済ませ、取込後は GL の試算表と合計を照合します。

標準機能とアドオン

要件	標準での実現	アドオン・拡張が必要になりやすい点
予算・予測の編成	Modules の事前構築コンテンツ、または Custom	モジュールにない勘定体系・計算
独自の計算	Calculation Manager のルール	動的な制御・外部呼び出し：Groovy
承認	承認ユニット	社内の稟議システムとの連携：REST、OIC
予測	Predictive Planning、Auto Predict、IPM Insights	独自のモデル：Bring Your Own ML
連携	Data Integration、EPM Automate、REST	変換が複雑なファイル連携：OIC など

拡張を作る前に

まず Modules の事前構築コンテンツで満たせないかを確認し、足りない部分だけを Custom や Groovy で補います（Fit to Standard。標準機能とアドオンの考え方）。Custom は自由度が高い反面、設計とテストの負担が大きくなります。

ベストプラクティス

• 設計：最初に「何を・どの粒度で・誰が入力するか」を決めます。ディメンションは必要最小限にし、入力用と報告用でキューブを分けます
• 移行：環境間の移行はスナップショットで行います。実績取込のマッピングは、Fusion 側の COA の変更と一緒に管理します
• テスト：年度の切替、承認の昇格・却下、ルールの実行時間、実績取込と GL 試算表の照合を確認します
• 運用：デイリーメンテナンスの時刻とジョブが重ならないようにし、変更前にスナップショットを取ります

よくあるアンチパターン

• フォーム全体を毎回再計算するルールを作り、保存に時間がかかる
• Entity にコストセンターまですべて入れ、承認の階層が深くなりすぎる
• 巨大な Groovy スクリプトを 1 本だけ作り、保守できなくなる
• 実績取込の期間のマッピングを GL のカレンダーと合わせず、別の期間に入る

日本での導入の考慮点

Planning に固有の日本向けローカライズ機能の有無は、今回の調査では確認できていません（2026 年 10 月）。次の表は日本の商習慣から出てくる設計上の論点です。

論点	検討の観点
会計年度（4 月始まりなど）	カレンダー（開始月・期間）は作成時に決める。作成後の変更可否は公式で確認
期中の組織変更	Entity 階層の変更と、過去データの読み替え（旧組織別と新組織別の比較）
当初予算・修正予算・見込	Scenario と Version の使い分け。確定後のロックの運用
事業部制・カンパニー制	Entity 階層を組織図に合わせるか、管理会計の階層にするか
国内外の子会社	多通貨（simplified multicurrency）、FCC との連携
稟議・承認の文化	承認ユニットの階層、承認の期限、代理の運用ルール
日本語のメンバー名	別名テーブルに日本語名・英語名を持たせる。コード体系（桁数・全角半角）

実装リファレンス

確認できたものだけを載せています。載っていないものは、各公式ガイドで確認してください。

EPM Automate（主なコマンド）

コマンド名は Working with EPM Automate（G45306-08、2026 年 10 月 1 日版）の目次で確認しました。runBusinessRule・runPlanTypeMap・runIntegration・runPipeline は、各コマンドのページで書式まで確認しました。ほかのコマンドの引数は公式ガイドで確認してください。

コマンド	用途	備考
login、logout	サインイン・サインアウト	認証方式（パスワード、OAuth）は公式で確認
uploadFile、downloadFile、listFiles	ファイル操作	データ・スナップショットの受け渡し
importMetadata、exportMetadata	ディメンション・メタデータ	変更後はキューブをリフレッシュ
importData、exportData	データのロード・エクスポート
runBusinessRule、runRuleSet	ルール・ルールセットの実行	runBusinessRule RULE_NAME [PARAMETER=VALUE]。runBusinessRule は 1 つのルールだけを実行し、ルールセットは runRuleSet
refreshCube、clearCube	キューブのリフレッシュ、クリア
runIntegration	Data Integration の統合の実行	書式は EPM データ統合
runPlanTypeMap	ジョブ種別 plan type map のジョブを実行し、BSO から ASO、または BSO 間でデータをコピーする	runPlanTypeMap JOB_NAME [clearData=true|false]。clearData の既定は true（小文字で指定）。Service Administrator のみ。データマップとの関係は公式で確認
exportSnapshot、importSnapshot	スナップショットの出力・取込	環境間の移行、バックアップ
runDailyMaintenance、setDailyMaintenanceStartTime	デイリーメンテナンスの実行・開始時刻
autoPredict	Auto Predict の実行	ガイドでは Hybrid Essbase 有効時

EPM Automate は Linux・UNIX・macOS では JDK 21 が必要です（17 もサポート。2026 年 10 月版のガイド）。

runBusinessRule の実行時プロンプト（RTP）は Period=Q1 Entity=USA のように名前と値の組で渡します。ルールに定義された名前と完全に一致しないプロンプトは無視され、値を省略すると既定値が使われます。実行できるのは Service Administrator と、ルールの Launch 権限を持つ Power User です。複数の値を渡す書式は、公式の「Specifying Multiple Values for a Parameter」で確認してください。

ルール実行とスナップショット取得の骨格（名前は架空の例）

#!/usr/bin/env bash
set -euo pipefail
# 認証情報は環境変数から読む（EPM_USER、EPM_PASSWORD、EPM_URL）
epmautomate login "$EPM_USER" "$EPM_PASSWORD" "$EPM_URL"
epmautomate runBusinessRule MonthlyAggregation Entity=JP01   # RTP を持つルールの例
epmautomate exportSnapshot Backup_20261016
epmautomate downloadFile Backup_20261016
epmautomate logout

REST API

ルールの実行は、POST /HyperionPlanning/rest/{api_version}/applications/{application}/jobs へのジョブの投入です（公式の例は v3）。本文の項目は jobType（Rules か RULES）、jobName（ルール名）、parameters（実行時プロンプトの JSON。Calculation Manager に既定値がなければ必須）で、Service Administrator か、ルールの Launch 権限を持つ Power User が実行できます。レスポンスの項目とジョブ状態の取得は、公式の Execute a Job で確認してください。認証方式はリリースにより異なります。

REST API でビジネスルールを実行する例（架空の名前）

curl -s -u "$EPM_USER:$EPM_PASSWORD" -H "Content-Type: application/json" \
  -X POST "$EPM_URL/HyperionPlanning/rest/v3/applications/$EPM_APP/jobs" \
  -d '{"jobType":"RULES","jobName":"MonthlyAggregation","parameters":{"Entity":"JP01"}}'

試験対策ポイント

対応する試験は EPM Planning 模擬テスト（1Z0-1080-26：Oracle Planning + AI 2026 Implementation Professional）です。問題数 50 問・90 分・合格ライン 68% は、Oracle 日本語サイトの認定試験一覧（日本語試験 1Z0-1080-26-JPN）で確認した値です。一覧の注記では、リンクのない 2026 年版は 10 月下旬のリリース予定とされています。旧版（1Z0-1080-25）は 2026 年 10 月 30 日に配信終了です。差分試験 1D0-1080-26-D-JPN（25 問・60 分・合格 68%・無償）は、認定に旧バージョンの試験への合格も必要と脚注にあります。公式の Exam Topics は取得できなかったため、分野はこのサイト独自の区分です。受験前に公式ページで最新の出題範囲を確認してください。

分野（このサイトの区分）	主な内容	対応ページ
全体像とビジネスプロセス、Planning Modules	EPM Cloud、作成オプション、5 つのモジュール	本ページ、設計
ディメンション・メタデータ・キューブ設計	標準ディメンション、密・疎、BSO と ASO	設計
データのロードと統合	Data Integration、importData、データマップ	本ページ、設計
フォーム・Smart View、ビジネスルール	複合フォーム、Calculation Manager、Groovy、RTP	フォーム・ルール
承認とセキュリティ、予測と AI	承認ユニット、ロール、Auto Predict、IPM Insights	フォーム・ルール
運用管理と自動化	EPM Automate、REST、スナップショット	本ページ

覚えておきたい判断ポイントです。

• Planning は EPM Cloud の製品で、Fusion ERP とは別の環境です。GL の実績は Data Integration で取り込みます
• 作成オプションは Custom、Modules、Sales Planning、Strategic Workforce Planning、Cash Forecasting、サンプル（Vision）、スナップショットからの Migrate です。FreeForm は 26.09 以降、FreeForm ビジネスプロセスから作ります
• Strategic Modeling は、Custom では作成時の選択か後からの有効化ができます。スナップショットのインポート後は、アーティファクトが含まれる場合を除いて有効化できません
• ルールの実行は EPM Automate の runBusinessRule か、REST のジョブ（jobType は RULES）です。メタデータを変えたらキューブをリフレッシュします

公式ドキュメント

• About Planning Modules and Strategic Modeling（Administering Planning Modules）
• Creating an Enterprise Performance Management Enterprise Cloud Service Application
• Selecting the Application Type
• EPM Features with AI
• Working with EPM Automate（PDF）
• REST API for Enterprise Performance Management Cloud
• Integration Process Description（EPM Data Integration）
• Oracle 認定試験一覧（日本語）

関連ページ

• アプリケーション設計（キューブ・ディメンション・モジュール）
• フォーム・ビジネスルール（Groovy）・承認・AI 予測
• EPM Cloud の全体像と Fusion ERP との関係
• EPM データ統合（Data Integration・EPM Automate・Fusion GL 連携）
• R2R：記帳から決算・連結・EPM まで
• 連結決算（FCC）の全体像と試験範囲
• Narrative Reporting：レポート・パッケージと管理レポート
• EDM：マスタデータ（ディメンション）の統制と配信
• 標準機能とアドオンの考え方