移送だけじゃない！SAP設定を他環境にコピーする“BCセット”のススメ

当ページのリンクには広告が含まれています。

2025/09/152025/09/16

BC-SET is a powerful workaround for Transport

カスタマイズ設定を本番環境やテスト環境にコピーする手段といえば 「移送（Transport）」だろう。SAPシステムに携わるコンサルタントやエンジニアであれば、移送は日常的に利用しており、誰もが知る存在だ。

しかし、実は移送以外にも設定を他の環境にコピーする方法が存在する。その一つが「BCセット（Business Configuration Set）」である。

BCセットは移送に比べて知名度が低く、存在すら知らないSAPコンサルタントも少なくない。しかし、特定の場面では移送よりも手間が少なく、柔軟且つスピーディに設定を別の環境にコピーできるのだ。

本記事では、BCセットの仕組み から移送との違い、メリット・デメリット、活用できるシーン、そして具体的な操作方法までを徹底解説する。BCセットを使ったことがないコンサルの、引き出しを増やす機会になるかもしれないので、ぜひ最後まで読んでいただきたい。

BCセットとは？

カスタマイズ設定コピーの選択肢を増やす

SAPではカスタマイジング設定を他環境へコピーする手段として、まず「移送」が思い浮かぶだろう。移送依頼にカスタマイジング設定をまとめ、リリースし、対象システムへインポートすることで設定を反映するのが、移送の基本的な流れだ。

一方、BCセットは 特定のカスタマイジング設定内容を、ひとまとめにして保存・再利用する仕組みである。

「設定の保存・再利用」と聞けば、「移送と同じでは？」と思うだろう。しかし、BCセットには移送にはないメリットや運用のしやすさがある。

BCセットの基本概念と特徴

BCセットの特徴は次の通りである。

特定のIMGノードの設定を切り出し「BCセット」として保存し、別の環境に適用できる
- 部分的なカスタマイジング設定の反映が可能
移送のような「リリース」操作は不要
- 保存したBCセットは、そのまま他の環境にコピーして適用可能

移送の場合、カスタマイズ設定した内容は「移送依頼」に集積し、移送依頼をリリースした後、別環境にインポートすることで設定内容をコピーする。

BCセットも設定内容を別の環境にコピーできる点は同じだが、IMGノードおよび、その設定値まで明示的に指定できる。さらに、移送のような「リリース」操作が不要など、「カスタマイジング設定コピーを迅速に行える」のが特徴だ。

SAP Best Practices でも使われている

BCセットは、実はSAP自身も公式に活用している仕組みである。その代表例が SAP Best Practices（SAP-BP）のインストール だ。

SAP-BPには、FI, MM, SD, PP,COなどの主要モジュールでよく利用される設定があらかじめ定義されているが、それらの設定がBCセットとして、まとめて提供されている。BCセットによるカスタマイジングの一括設定は、ゼロからIMGを設定するよりもはるかに効率的である。

ここで重要な概念が 「スコープアイテム（Scope Item）」 だ。

スコープアイテムとは、Best Practices の中で提供される 業務プロセス（業務シナリオ）の構成単位 のことを指す。たとえば、SD（販売領域）であれば「受注から請求まで」といった業務プロセスが、一つのスコープアイテムとして定義されている。

これらのスコープアイテムは、裏側では BCセットを用いて構築されており、SAP-BPのインストール時に選択・適用することで、該当する業務プロセスの設定がSAPシステムに反映される仕組みになっている。

つまり、スコープアイテムは Best Practicesを構成する最小単位 であり、その設定にBCセットが利用されている。これにより、自分たちが必要とするスコープアイテム（裏ではBCセット）を選択することで、迅速にテンプレートシステムを構築できる。

このように、BCセットは「プロジェクトでの便利ツール」にとどまらず、SAP公式の標準提供物（Best Practicesとスコープアイテム）を実現する中核的な仕組みでもあるのだ。

BCセットのメリットとデメリット

BCセットのメリットとデメリットを整理しておく。

メリット

迅速なコピー
IMGで設定した内容をそのままBCセットとして保存し、他クライアントやシステムに即座に反映可能。
柔軟性の高さ
リリースなどの運用承認プロセスを待たずに、自分の権限範囲でスピーディに適用できる。
部分適用が可能
IMGの特定の設定項目だけをコピーできる。

デメリット

依存関係に弱い
移送のような依存関係は考慮されないため、自身で関連する設定を一緒に持ってこないと動作しない場合がある。
知識不足による失敗リスク
T-CDや対象IMGノードを知らないと、正しく作成・適用できない。
設定の「削除」はできない
移送ではできる「削除」が、BCセットではできない。BCセットは設定の「追加」や「変更」に特化しており、不要設定のクリーンアップを伴う場面では、BCセットは使えない。
本番では非推奨
柔軟性が高い＝統制に欠けるため、検証環境や本番環境の構築には向かない。

BCセットと移送の違い

ここでは、「移送」の仕組みとデメリットをあらためて整理しつつ、移送とBCセットの違いを見ていく。

移送とは何か？

移送（Transport）は、SAPシステム間で カスタマイジング設定やアドオンプログラムなどの開発オブジェクトを、検証環境、本番環境へと、確実にコピーするためのSAP標準機能である。

移送プロセスは以下のようになる。

開発者やコンサルタントが 移送依頼（Transport Request） を作成
カスタマイジング設定の内容をその移送依頼に登録
移送依頼をリリース
運用管理者がターゲット環境で移送依頼をインポート

なお、移送について詳しく解説した記事は以下。

移送のデメリット

移送は運用統制に非常に優れている。システムの構成・品質を一貫して保つという点において、絶対的に信頼のおける仕組みだ。

しかし、実務で使っていると、いくつかのデメリットを感じることもある。特に、小規模な設定変更や試行的な作業 においては不便を感じる場面が多い。ここでは移送のデメリットを整理してみる。

手続きが煩雑でリードタイムが長い
移送依頼の作成、リリース、承認、インポートという複数のステップを踏む必要がある。特に運用部門の承認が絡むと、数時間から数日かかる場合もある。小さな設定を反映するだけでも大掛かりになってしまう。
柔軟性の欠如
部分的に設定を反映したい場合でも、移送は「すべてまとめて」が原則。一つの移送依頼（移送依頼番号）に複数の設定をぶら下げるため、「この設定だけ反映したい」という運用ができない。これは、テストやPoCの場面ではオーバースペックになりがちである。
影響範囲が広い
本番環境を含めた複数システムに影響を与えるため、万一誤った設定を移送してしまうとリカバリーに多大な工数がかかる。一部の設定だけ戻すことも難しい。

このように、移送は「統制」や「本番運用」には適しているが、スピードや柔軟性を求められる場面では不向きである。ここにこそ、BCセットを使う余地があるといえる。

BCセットと移送の決定的な違い

BCセットと移送は、どちらも「設定をコピーする」という目的は同じであるが、重視しているポリシーのようなものが異なる。このポリシーの違いは、依存関係のあるパラメータに対する挙動に表れてくる。

たとえば、PP（生産管理）モジュールには「指図タイプ依存パラメータ」というものがある。このパラメータは、その名の通り「指図タイプ」に依存しているため、指図タイプが登録されていないと設定することができない。

では、この「指図タイプ依存パラメータ」の設定において、移送とBCセットではどのような違いがあるのか？
それぞれの挙動から、ポリシーが浮かび上がってくる。

移送：整合性重視

移送の場合、インポート時に依存関係のチェックが行われるため、指図タイプが存在しない環境に、指図タイプ依存パラメータをインポートすればエラーとなる。

このように、移送では設定の不整合は回避されるので、システムを不整合なく、健全に保つことができる。

移送の操作は手間がかかるが、それはシステムの一貫性と整合性を維持することを重視した結果の手間なのだ。

BCセット：スピード重視

BCセットの場合、依存関係のチェックは行われず、パラメータはダイレクトに対象環境に適用できる。この結果、設定の不整合を許容したままシステム環境は構築されてしまい、動作不良が起きたとき、その原因を調査するのに時間がかかってしまう。

これが、BCセットは本番環境構築には向かない大きな理由だ。

その代わり、BCセットは移送のような手間は軽減されるため、スピーディに設定コピーができる。システムの整合性維持は、BCセットを作成するコンサルタントの力量にかかっているといえる。

移送とBCセットの比較

以下の表は、移送とBCセットを実務的観点も含めて比較したものである。

比較項目	移送（Transport）	BCセット（Business Configuration Set）
主な用途	開発環境から本番環境への正式な設定反映手段	設定の再利用・テンプレート化
操作の手間	移送依頼の作成 → リリース → インポートと、工程が多い。	設定内容を直接作成・適用できる。作業者自身で即時反映可能。
作業時間の目安	小規模な設定でも上記の操作が必要で、数分～数時間かかる。承認プロセスも加わればリードタイムはさらに長くなる。	数分程度で設定をコピー可能。
担当者の関与レベル	開発者／コンサルタントが移送依頼を作成し、運用管理者が承認・インポート。複数担当者が関与。	コンサルタント自身で作成・適用可能。原則1人で完結。
利用する場面	プロジェクトの全場面検証環境／本番環境の構築など、正式な設定を反映するとき統制が必須の環境	開発環境、プロトタイプ、PoC、教育用環境部分的に設定をコピーしたい時統制よりも、作業効率を優先するフェーズ

BCセットの操作方法

BCセットを作成および適用するためのトランザクションコードは以下である。

BCセットの登録･変更・照会： SCPR3
BCセットに記録されている設定内容を対象のクライアントに適用する: SCPR20

BCセットの作成方法

T-CD: SCPR3 を開始し、メニュー「ビジネスコンフィギュレーションセット」->「登録」を選択。
次図のように、BCセット／テキストに名称を入力する。

BCセットは次の３つの中から選択できる。

BCセット化できるオブジェクト	説明
IMG階層	IMGノード（T-CD: SPRO, SIMG）と設定値を選択してBCセットを作成する
BCセットのセット	登録済みのBCセットから、設定項目と設定値を選択し、BCセットを作成する
移送依頼	登録済みの移送依頼から、IMGノードと設定値を選択してBCセットを作成する

なお、以下に示す手順は「IMG階層」を選択した場合の例である。

「SAP完全版IMG」が表示される。このタイトルからわかる通り、表示されるIMG階層は、T-CD: SPROまたはSIMGで表示されるIMGメニューと同じである。
このIMGメニューから、設定を保存したいIMGノードと、その値を選択していく。複数のIMGノードと値を、連続して選択することが可能だ。

選択を終えたら、[保存]ボタンを押下する。
「オブジェクトディレクトリエントリ登録」が表示され、「パッケージ」を入力するよう促されるが、正式なオブジェクトでなければ「$TMP」と入力して保存すればよい。

これでBCセットの登録は完了である。

BCセットを使った設定の反映方法

T-CD: SCPR20 を起動。
メニュー「ビジネスコンフィギュレーションセット有効化」を選択。

移送依頼を指定する画面がポップアップするので、移送依頼を指定する。

「有効化オプション」画面が表示される。データの上書きを行うかどうかなどを聞いてくるが、基本的にデフォルトのままでOK。[Enter]を押下して続行する。

「有効化は正常に完了しました」というメッセージが表示されれば、適用は完了である。

BCセットを再利用する

BCセットの範囲

BCセットは同一環境（同一サーバ）内で有効である。あるクライアントで登録したBCセットは、同一環境内であれば、別のクライアントからも参照可能である。

BCセットのダウンロード／アップロード

登録済みのBCセットは、メニューから「ダウンロード」を選択することで、ファイルとしてダウンロードできる。また、ダウンロードしたBCセットファイルは別環境に「アップロード」して再利用することが可能だ。

移送依頼もファイルとして保存できるが、まったく別の環境にインポートしようとすると整合性チェックに引っかかりエラーとなるケースが多い。これは移送が、同じプロジェクト内での構成管理と整合性維持に重点を置いているためである。

一方のBCセットは、カスタマイジングテーブルにダイレクトに設定値を登録する仕組みなので、良くも悪くも整合性チェックは緩い。このため、別環境であっても設定内容を導入しやすい。

BCセットを運用に組み込むポイント

環境によって使い分ける

移送とBCセットを使い分けるポイントは以下。

移送：統制の効いた本番向けの手段。通常はこちら。
BCセット：柔軟で小回りの効く補助的な手段。開発環境で使える。

環境別のベストプラクティスを整理した表は以下。統制重視の検証環境／本番環境の構築は移送に限る。
一方、生産性を重視する場面では、BCセットを積極的に利用できる。

環境	適した手法	理由
Sandbox / Demo / 教育環境	BCセット	スピード・自由度重視。頻繁なリセットや試行錯誤に向く。
開発環境（DEV）	BCセット + 移送	個人開発や試行錯誤はBCセット、正式な設定は移送依頼にまとめる。
検証環境（QA）	移送（原則）	本番を想定した統制環境のため、移送で設定内容をコピーする。
本番環境（PRD）	移送のみ	ガバナンス・監査対応・変更管理のため、移送が必須。