環境管理・四半期アップデート・テスト

環境は本番とテストが 1 つずつ契約に含まれ、必要に応じて開発／追加テスト環境を購入します。設定と拡張は必ず非本番で作り、決められた移行手段で本番へ移します
本番からテストへのリフレッシュ（P2T）は、データ・設定・BI カタログなどをコピーします。一方、他環境への接続先、資格証明、スケジュール済プロセス、通知はコピーされません。リフレッシュ後のチェックリストが欠かせません
四半期アップデートはテスト環境に先に適用され、2 週間後に本番に適用されます。この 2 週間で、主要シナリオ・連携・帳票・セキュリティの回帰テストを終えます
移行手段は対象ごとに違います：設定データ（構成パッケージ）、画面の構成（マイグレーション・セット）、VBS の拡張（VBS からデプロイ）、BI（カタログのアーカイブ）、OIC（プロジェクトのエクスポート）

全体像

環境の種類とプロジェクトでの役割

環境の種類	用途	契約上の扱い
本番（Production）	日々の業務	環境ファミリーに 1 つ
テスト（Test）	結合テスト、移行リハーサル、受入テスト、アップデートの事前検証	本番ごとに 1 つ含まれる
開発／追加テスト環境（Development/ATE）	拡張・連携の開発、単体テスト、教育	別途購入
デモ（Demonstration）	架空の会社のデモデータでの評価・教育	別の契約が必要

プロジェクトでは、環境ごとに役割を決めます。設定の正となる Gold 環境を置く、本番稼働後は 1 つの環境を本番前環境として頻繁にリフレッシュし障害調査に使う、などです。四半期アップデート、リフレッシュ、移行リハーサル、テスト期間、本番切替を 1 枚にまとめた**環境計画（Environment Plan）**を早めに作り、更新し続けます。

環境リフレッシュ（P2T・T2T）

リフレッシュは、移行元の環境の最新のバックアップを移行先の環境にコピーする操作で、Oracle Cloud Console からセルフサービスで実行します。本番からテストへのコピーを P2T（Production to Test）、非本番どうしを T2T（Test to Test）と呼びます。

主な制約	内容
移行先	本番とデモ環境は移行先にできない
リリース	移行元と移行先で、バージョンとパッチ・レベル（月次・例外の更新を含む）が一致している必要がある
頻度・予約	移行先は 7 日に 1 回まで。最大 90 日先まで予約できる
禁止期間	移行先のメンテナンスの 5 日前から、メンテナンス開始の 1 日後までは実行できない
所要時間	通常は最大 48 時間程度。その間、移行先は使えない（移行元には影響しない）

コピーされるもの・されないものは次のとおりです。

コピーされる	コピーされない
Fusion のデータ（取引・設定）	他の環境への接続先 URL（Topology Manager のデータ）
添付ファイル、連携ファイル（WebCenter Content）	ESS のプロセスのパラメータとインスタンス
サンドボックスやフレックスフィールドなどの構成（MDS）	ホームページの通知（承認依頼を含む）
BI のカタログ全体	SSO の資格証明、セキュリティの資格証明と鍵
ユーザー（アイデンティティ・ストア）	MFA の登録状況

データマスキングは別契約のオプションで、有効にするとリフレッシュ時間が延びます。移行先の言語パックは、移行元の言語パックで上書きされます。

リフレッシュの影響と対応

連携先の URL：他の環境への接続先はコピーされません。テスト環境の接続先を確認し、外部システム側（OIC の接続を含む）がテスト環境を向いていることも確認します
認証情報：SSO・MFA・資格証明はコピーされません。SSO の設定、連携用ユーザーのパスワード・証明書・OAuth の設定を確認します。本番のユーザーとロールがテストに入るため、テストでの閲覧者を見直します
スケジュールの停止と再登録：ESS のプロセスはコピーされず、移行先で投入済みだったプロセスも削除されます。テスト環境で必要な定期ジョブを再登録し、本番向けの処理（支払ファイルの送信、外部への連携）を動かさないことを確認します
メール送信の抑止：本番の取引先・従業員のメールアドレスがテストに入ります。ワークフロー通知はテスト用の 1 つのアドレス（BPM Worklist の Test Notification Email Address）に集約するか、BPM のワークフロー管理者が通知を停止します。BI Publisher のバースティングや定期レポートの配信先、取引先への通知も確認します
承認テスト：承認依頼の通知はコピーされないため、承認のテストは新しく起票した取引で行います

四半期アップデートの流れ

更新月の前：Readiness（What's New・Feature Summary）を確認 → テスト計画 → 必要なら P2T（禁止期間の前に）
第 1 金曜：テスト環境を更新 → 2 週間：回帰テスト・新機能の評価・オプトインの判断
第 3 金曜：本番環境を更新 → 本番での動作確認（スモークテスト）→ 結果の記録

更新の前に、サンドボックスは公開するか削除します。作業途中のものは、更新後に新しいサンドボックスでやり直します
メンテナンス中はスケジュール済プロセスが動きません。メンテナンス中に予定されていた定期ジョブは、終了直後に実行されます
開始前の猶予（5 分）の後、実行中のプロセスは一時停止されるか取り消されます。長時間かかるジョブは直前に投入せず、実行中のものは保留（Hold）にして終了後に再開することが推奨されています
スケジュール済プロセスの画面には、メンテナンスの 3 時間前からメッセージが表示されます。表示中は新たにプロセスを投入しません

回帰テストの戦略

2 週間で終えるために、毎回実行する「固定の回帰セット」と、Readiness から選ぶ「変更箇所のテスト」を組み合わせます。

対象	内容	優先度
主要な業務シナリオ	P2P・O2C・R2R の代表パターン（締め処理を含む）	高
連携	REST・FBDI・BICC・OIC の正常系と主要なエラー	高
セキュリティ	カスタムロール、データアクセス、職務分掌	高
拡張	VBS、フレックスフィールド、承認ルール	高
既定で有効になる変更	Feature Summary で既定有効とされた機能	高
帳票・分析	カスタムの BI Publisher・OTBI	中〜高

API の疎通確認や主要画面の操作は自動化し、毎回同じ手順で実行できるようにします。

構成・拡張の移行手段

対象	移行手段	ポイント
設定データ（FSM のタスク）	セットアップデータのエクスポート／インポート（構成パッケージ）	出力と同じ方法で取り込む（FSM）
ページの構成、Application Composer、参照タイプ、デプロイ済みフレックスフィールドなど	構成の移行（Migration のマイグレーション・セット）	公開済みのサンドボックスの内容が対象。移行先を移行元に登録すると差分だけ移せる
VBS の拡張	VBS から本番へデプロイ	マイグレーション・セットには含まれない
BI のカスタム（OTBI・BI Publisher）	BI カタログのアーカイブ／アンアーカイブ	カスタムの成果物はカスタム用フォルダに保存して管理
OIC	プロジェクトのエクスポート（.car）、パッケージ（.par）、統合（.iar）	接続の資格証明は移行先で設定。インポートは既存のリソースを置き換えない
セキュリティ（カスタムロールなど）	別の手順で移行	マイグレーション・セットには含まれない（セキュリティ設計）

マイグレーション・セットには、プロファイル・オプション、ロールとロール階層、個人設定（パーソナライズ）、削除の操作は含まれません。OTBI の成果物は、プロファイル・オプション Business Intelligence in Configuration Set Migration Disabled が No の場合だけ含まれます。

運用監視のポイント

対象	確認すること
スケジュール済プロセス	Ready（同時実行の上限待ち）・Wait・Blocked（非互換）の滞留、長時間の Running、30 分を超える Canceling
定期ジョブの所有者	無効化されたユーザーが投入した定期ジョブは実行されない。退職・異動の前に再登録する
取込と連携	FBDI・REST・OIC のエラー、インターフェース表の残件
BICC の抽出	抽出ジョブの成否と所要時間
承認・通知	滞留している承認、届いていない通知
アップデートと環境	Readiness、オプトインの期限、メンテナンスとリフレッシュの予定

スケジュール済プロセスの調査では、Status Details タブで非互換によるブロックを、Process Details タブでログとパラメータを確認します。子プロセスを持つジョブは階層表示（Hierarchy）で見ます。

コード例

リフレッシュ後のチェックリスト（YAML の例）

refresh: P2T
target: TEST
checks:
  - id: ENDPOINT
    task: 外部システム・OIC の接続先がテスト環境を向いているか確認
  - id: CREDENTIAL
    task: SSO・連携ユーザーのパスワード／証明書・OAuth 設定を確認
  - id: SCHEDULE
    task: テスト環境の定期ジョブを再登録（本番向けの送信ジョブは登録しない）
  - id: EMAIL
    task: ワークフロー通知をテスト用アドレスに集約、BIP の配信先を確認
  - id: ACCESS
    task: テスト環境で本番データを閲覧できるユーザーを見直す
  - id: EXTENSION
    task: VBS 拡張・サンドボックスの状態を確認し、作業中の拡張を再デプロイ

アップデート後の疎通確認（モック API での練習）

このサイトの練習用モック API（練習用 API プレイグラウンド）で、スモークテストの型を練習できます。実機では URL と認証情報を差し替えます。

#!/usr/bin/env bash
set -euo pipefail
: "${BASE:?BASE を設定してください}"   # 例：https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05
: "${API_USER:?}" "${API_PASSWORD:?}"    # モックでは learner / welcome1

check() {
  local name="$1" url="$2" code
  code=$(curl -s -o /dev/null -w '%{http_code}' -u "$API_USER:$API_PASSWORD" "$url" || true)
  if [ "$code" = "200" ]; then echo "OK  $name"; else echo "NG  $name (HTTP $code)"; fi
}

check "請求書の検索"     "$BASE/invoices?limit=1&onlyData=true"
check "仕入先の検索"     "$BASE/suppliers?limit=1&onlyData=true"
check "ジョブ状況の照会" "$BASE/erpintegrations?finder=ESSJobStatusRF;requestId=2101234"

実務では、結果をファイルに残し、NG の場合にリトライや通知を行うように拡張します。

落とし穴とベストプラクティス

環境計画に、四半期アップデートの日付と禁止期間を最初に書き込みます
リフレッシュ後のチェックリストを手順書にして、毎回同じ手順で実施・記録します
移行は手段ごとの台帳（何を・いつ・どの手段で・誰が）で管理し、本番への反映を追跡できるようにします
回帰テストの結果と、オプトインの判断（採用・保留）をリリースごとに記録します

試験対策ポイント

OIC 模擬テスト：プロジェクトとパッケージのエクスポート／インポート、移行後の接続の設定
Redwood 模擬テスト：VBS の拡張をテストから本番へデプロイする流れ
GL・調達などの実装試験：セットアップデータのエクスポート／インポート、サンドボックス、新機能のオプトイン
覚えるべき用語：環境ファミリー、P2T・T2T、禁止期間（ブラックアウト）、マイグレーション・セット、構成パッケージ、サンドボックスの公開