はじめに

こんにちは、DevKumaです。
前回の記事では、Apexの基礎知識や開発者コンソールでの「Hello, World!」までを一緒に行いました。

Trailheadやご自身のDeveloper Editionで学習を進め、簡単なApexトリガやApexクラスが書けるようになってくると、次にぶつかる大きな壁がこれです。

「あれ、このApexコード、どうやって本番環境（Production）に移すの...？」

開発者コンソールで「Save」を押せば、Sandboxではすぐに動きました。でも、本番環境で同じように開発者コンソールを開いてコピペ...なんてことは、絶対にやってはいけません（というか、本番環境ではできないよう制限されています）。

本番環境を安全に保つため、Salesforceには厳格な「リリース」の仕組みが用意されています。今回は、その中でも最も基本的で、追加ツール不要な標準機能「変更セット（Change Set）」を使ったApexのリリース手順を整理します。

1. リリース前に絶対確認！Apex特有の「75%ルール」

手順に入る前に、Apexを本番環境にリリースするための絶対の掟を確認しておきましょう。前回学んだApexコードを書いただけでは、実は本番には持っていけないのです。

【Apexリリースの鉄則】
本番組織にリリースするためには、組織全体のApexコードの75%以上が、単体テスト（テストコード）によってカバーされていなければならない。

Sandboxではテストコードがなくても保存・実行ができましたが、本番適用時には必須となります。つまり、リリースしたいApexクラスだけでなく、それが正しく動くことを保証する「テストクラス」も一緒にリリースする必要があるということです。（テストクラスの書き方は、また別の機会に！）

準備物リスト
- リリースしたいApexクラス（またはトリガ）本体
- それに対応するテストクラス（@isTestがついているもの）

2. 今回使う「変更セット」とは？

「変更セット（Change Set）」は、Sandboxで作った機能（Apex、カスタム項目、フローなど）を、別の環境（本番など）に安全に送るためのSalesforce標準機能です。

よく「引っ越しのダンボール」に例えて理解しています。

Sandbox（旧居）で、送りたいApexなどをダンボール（変更セット）に詰める。
トラックに乗せてアップロード（送信）する。
本番環境（新居）に届いたダンボールを受け取り、中身を検証して、棚に並べる（リリース）。

イメージはこんな感じです。大切なのは「自分で明示的にダンボールに入れないと、勝手には送られない」という点です。

3. 実践！リリース手順ステップバイステップ

では、実際の流れを見ていきましょう。行ったり来たりするので、今どちらの環境を操作しているかに注意してください。

Step 0: 【本番側】環境をつなぐ（初回のみ）

「Sandboxから変更セットを送ったのに、本番に届かない！」私が最初にハマった罠です。実は、本番環境側で「このSandboxからの荷物は受け取っていいよ」という許可設定が必要です。私は最初これを知らず、Sandbox側の変更セットの画面でアップロードすると、組織管理者に問い合わせしてくださいとのエラーが発生し、解決策を探っていました。

本番環境にログインします。
[設定] > [リリース設定] を開きます。
接続したいSandboxの横にある「編集」をクリックします。
「着信変更セットを許可」にチェックを入れて保存します。

Step 1: 【Sandbox側】送信変更セットの作成

ここからSandboxでの作業です。

Sandboxにログインします。
[設定] > [送信変更セット] を開きます。
「新規」をクリックします。
名前を付けます。
- 一回アップロードすると修正できないため、私は YYYYMMDD_機能名_v1 のように、日付とバージョンを入れて管理します。（例：20251107_取引先トリガ実装_v1）

Step 2: 【Sandbox側】コンポーネント（中身）の追加

ここが最重要工程です。ダンボールに詰める作業ですね。

「変更セットコンポーネント」セクションにある「追加」ボタンをクリックします。
コンポーネントの種類を選択して、作成したApexを追加します。
- クラスの場合：種類「Apex クラス」を選択
- トリガの場合：種類「Apex トリガ」を選択
(重要) 対応する「テストクラス」も忘れずに追加してください！

🔍 ワンポイント：依存関係を確認
「連動関係を参照/追加」ボタンを押すと、「このApexクラス、中でこの新しいカスタム項目を使ってるみたいだけど、一緒に送らなくて平気？」とSalesforceが教えてくれます。入れ忘れ防止に役立ちます。

Step 3: 【Sandbox側】本番組織へのアップロード

ダンボール詰めが終わったら、発送します。

変更セットの詳細画面で「アップロード」ボタンをクリックします。
送信先に「本番組織（Production）」を選択して「アップロード」します。

これでSandbox側の作業は完了です！トラックが出発しました。

Step 4: 【本番側】受信変更セットの確認

ここからは本番環境での作業です。緊張しますね...！

本番環境にログインします。
[設定] > [受信変更セット] を開きます。
先ほどアップロードした変更セットが届いているはずです。（届くまで数分かかることもあります。焦らず待ちましょう ☕）
変更セット名をクリックして開きます。

Step 5: 【本番側】「検証 (Validate)」をする〜転ばぬ先の杖〜

ここが最大のポイントです。詳細画面には「リリース」ボタンがありますが、いきなり押してはいけません（自戒を込めて）。

まずはその隣にある検証ボタンを押しましょう。

検証とは？
- 「もし今リリースボタンを押したら、成功するかどうか？」をシミュレーションしてくれる機能です。
- 実際にApexは本番に反映されず、テスト実行してくれます。

Apexが含まれている場合、検証時にテストが実行されます。しばらく待って、ステータスが成功になれば、リリースしても安全だという証明です！

Step 6: 【本番側】いざ、リリース (Deploy)！

検証が成功したら、いよいよ本番反映です。

検証済みの変更セットに対し「リリース」ボタンをクリックします。
再度、リリース状況の画面で進捗を見守ります。

ステータスが緑色の「成功」になれば、無事あなたのApexコードが本番環境で動き始めます！

4. よくあるエラーと対処法

Apexリリースで初心者が（私も）よくぶつかる壁です。

エラー：「コードカバー率が75%未満です」
- 原因：テストクラスを入れ忘れているか、テストコードの品質（網羅率）が足りていません。
- 対策：Sandboxに戻って、テストクラスが変更セットに入っているか確認しましょう。
エラー：「コンポーネント xxx が見つかりません」
- 原因：Apexコード内で使っている新しい「カスタム項目」や「カスタムオブジェクト」を、変更セットに入れ忘れています。
- 対策：Sandboxに戻って、送信変更セットに足りないコンポーネントを追加し、再度アップロードします。（※一度アップロードした変更セットは修正できないので、クローンして作り直すのが早いです）

5. おわりに

せっかく書いたApexコードも、本番で動かなければ意味がありません。最初はリリース作業に緊張すると思いますが、Salesforceには検証という素晴らしいリハーサル機能があります。

「まず検証、成功したらリリース」

この癖をつけて、安全なApexリリースを目指しましょう！以上devKumaでした。