「DMSは意味は分かる。SCTもやってることは分かる。なのに、いざ設問で正しい公式用語が口から出てこない」——これ、私がAWS SAP（Solutions Architect Professional）の学習でいちばん長く引きずった弱点でした。知識がないのではなく、掴んだ概念に公式ラベルが貼り付かない。本記事は、DB移行のDMSとSCTの違い・使い分けを整理しつつ、その「分かるのに出てこない」を絵→語源で突破した実体験を書きます。移行は私の自己診断で最弱（診断0.2）だった分野です。
1. まず結論：同種はDMS単独、異種はSCT＋DMS
検索で来た方が最初に欲しいのはここだと思うので、判別を先に置きます。DB移行の道具選びは、実は「引っ越し先のDBが、同じ種類か・違う種類か」の1点でほぼ決まります。
| 移行パターン | 例 | 使う道具 |
|---|---|---|
| 同種（homogeneous） | MySQL → Aurora MySQL | DMS 単独（変換が要らない） |
| 異種（heterogeneous） | Oracle → Aurora PostgreSQL | SCT ＋ DMS（先に変換 → 運搬） |
ポイントは順番です。異種は「変換屋（SCT）を先に入れてから、運搬（DMS）」。同じ種類のDBへ移すだけなら間取りを変える必要がないので、SCTは不要でDMSだけ。この一枚を持っておけば、要件文に「Oracleから」「PostgreSQLへ」と別種名が並んだ瞬間にSCTを足す、と反射で選べます。
2. DMSとSCT、それぞれ何屋なのか（例えで掴む）
用語を貼る前に、まず絵で役割を掴みます。私はこの順番（絵が先・名前は後）にしてから定着が変わりました。移行はぜんぶ「引っ越し」の比喩で統一しています。
- DMS（Database Migration Service）＝DB引っ越し専門業者。DBを稼働させたまま運ぶのが仕事。止めずに運べるのが最大の売り。
- SCT（Schema Conversion Tool）＝間取り変換屋。引っ越し先の家の間取りが違う（＝DBの種類が違う）とき、荷物が収まるように間取りを変換してから運び込めるようにする。
だから異種移行は「変換屋が先に入って間取りを直し、そのあと運送業者が荷物を運ぶ」。同種移行は間取りが同じなので変換屋は呼ばず、運送業者だけで済む——これが結論の表の中身です。
3. DMSの背骨は「先に塊 → 差分で追いつき → 切替」
DMSが「止めずに運べる」のはなぜか。ここが移行分野共通の背骨で、掴めると丸暗記が要らなくなります。DMSの動きは3拍子です。
- ① Full Load（一括ロード）：まず現行DBの中身をまるごとコピー（＝先に大きな塊を運ぶ）。
- ② CDC（Change Data Capture＝継続レプリケーション）：一括コピー中や後に元DBで発生した変更を拾って反映し続ける（＝差分で追いつく）。
- ③ カットオーバー：差分が追いついたところで接続先を切り替える（＝最小停止で引っ越し完了）。
この「先に塊 → 差分で追いつき → 切替」は、サーバー移行のMGNも、データ移送のSnow＋DataSyncもまったく同じ形です。DMSの「継続レプリケーション」はその差分パートの正体。移行サービスは別々の暗記対象ではなく、同じ発想の別実装だと分かると一気に軽くなります。実際に運ぶのはDMSが立てるレプリケーションインスタンス（＝運搬トラック）で、SCTは移行前にアセスメントレポートで「自動変換できない箇所・手直しの工数」を先に見せてくれます。
4. ここからが本題：「意味は分かるのに公式用語が出てこない」問題
ここまでで、DMS／SCTのやってることは説明できます。私も概念は早い段階で自分の言葉にできていました。「DBを動かしながら運ぶやつ」「違うDBに乗せ換えるための道具」——意味は掴めている。問題はその先でした。
設問や口頭で問われると、homogeneous / heterogeneous、継続レプリケーションといった公式ラベルが出てこない。「同じDBのやつ…えっと、なんだっけ」で止まる。SAPは選択肢が公式用語で並ぶので、意味を掴んでいても用語で選べなければ得点にならない。これは移行に限らず、私が学習を通してずっと再発していた弱点でした（前回のSnow／DataSync編でも、この「用語が口から出ない」癖を自分の課題として書いています）。
5. 突破法：絵で概念 → ラベルを後乗せ → 語源で固定する
やめたのは「用語カードを丸暗記する」やり方です。代わりに、順番を固定しました。この手順にしてから、はじめて公式用語が定着し始めました。
- ① まず絵で概念を掴む：引っ越し業者／間取り変換屋、で役割を先に腹落ちさせる。用語はまだ出さない。
- ② 概念が固まってから公式ラベルを「後乗せ」する：掴んだ役割に、あとから homogeneous（同種）／heterogeneous（異種）という名札を貼る。
- ③ 語源で固定する：homo＝同じ・hetero＝異なる。生物で習った「ホモ接合・ヘテロ接合」と同じ接頭辞だと接続すると、綴りごと一発で定着した。同様に「差分で追いつき続ける動き」に継続レプリケーションという公式名を後から接続。
この「概念が先、公式ラベルは後、最後に語源で錨を打つ」順番が効きました。丸暗記だと意味と切り離された記号なので抜けますが、掴んだ概念に語源という取っ手を付けると引き出せる。用語が出ないのは記憶力の問題ではなく、貼り付ける順番の問題だった——これが私の最大の収穫です。
6. 私がつまずいたポイント（実体験）
ここまで整理して書いていますが、移行は私の最弱分野で、DMSとSCTでも同じ壁に何度もぶつかりました。つまずきの正体は知識の量ではなく、2つの癖だったと気づけたのが転機です。
- 「同種か異種か」の判別が咄嗟に出ない：SCTが要るケースと要らないケースを、要件を見た瞬間に選べませんでした。「引っ越し先の間取りが違うか（＝DBの種類が違うか）」の一点に還元してから、迷いが消えました。
- 意味は掴めるのに公式用語が口から出ない：差分で追いつく動きは説明できるのに、名前が「定期的に更新して…」で止まり、継続レプリケーションという公式名が出てこない。homogeneous／heterogeneous も同じでした。これは前述（4〜5章）のとおり、絵で概念を掴んでから語源で貼り直す順にして、ようやく口から出るようになりました。
まとめ
DB移行の道具選びは「同種か異種か」の1点——同種はDMS単独、異種はSCT＋DMS。DMSは「先に塊→差分（継続レプリケーション）で追いつき→切替」の背骨で、止めずに運ぶ。そして、意味は分かるのに公式用語が出てこないなら、絵で概念→ラベルを後乗せ→語源で固定の順に変えてみてください。用語が出ないのは記憶力ではなく順番の問題です。
このDMS／SCTの整理は、私がオンプレ環境の出身からクラウド（AWS）インフラエンジニアへ転職し、いまAWS SAP合格を目指して続けている学習記録の一部です。「AWSの用語や移行に苦労している」という方は、そもそも私がどうやってオンプレからクラウドの世界へ移ってきたのか——転職のリアルも参考になるかもしれません。