No.# この問題は、メタデータ API（Metadata API）を「直接」呼び出す（プログラムを書いて API を叩く）ケースと、既存のツール（Ant や CLI）を介して利用するケースの違いを問うています。
正解：C, D
解説
メタデータ API は、Salesforce のカスタマイズ（メタデータ）を .zip ファイル形式で取得（retrieve()）したり、配置（deploy()）したりするための API です。
C. サンドボックスでの開発と Ant 移行ツールの利用
* 理由: Ant 移行ツール（Force.com Migration Tool） は、内部的に Java を使用してメタデータ API の retrieve() と deploy() を「直接」呼び出すスクリプトを実行するツールです。ファイルベースで環境間の移行を自動化するための代表的なユースケースです。
D. メタデータ API を使用した本番組織へのデプロイ
* 理由: 開発とテストが完了した後、アプリケーションを他の組織（本番など）へ移動させる際、手動ではなくプログラムやツールを用いてメタデータ API を呼び出し、一括デプロイを行うのは標準的なシナリオです。
他の選択肢が不適切な理由
* A. AppExchange 経由での配布:
AppExchange で配布されるアプリケーションは、通常「パッケージ（管理パッケージ）」として公開されます。この場合、開発者は API を直接叩くのではなく、Salesforce の UI または CLI を通じて「パッケージバージョン」を作成し、インストール用リンク（04t）を発行して配布します。
* B. Salesforce CLI (SFDX) の利用:
Salesforce CLI を使用する場合、開発者は背後で何が起きているかを意識せず、sf project deploy start といった抽象化されたコマンドを打ちます。この問題の意図である「直接 retrieve/deploy メソッドを呼び出すコードを記述する」という低レイヤーな操作の文脈とは異なります（CLI 自体は API を叩いていますが、開発者はコードを書きません）。
アーキテクトの視点：API vs ツール
現代のデプロイ戦略において、開発者が API の deploy() メソッドを直接叩くコードをゼロから書くことは稀です。
* Ant 移行ツール (C): 古くからあるファイルベースのデプロイで、Jenkins 等の CI ツールと組み合わせて使われます。
* Salesforce CLI (B): スクラッチ組織やパッケージ開発モデルで使用される現代の標準です。
* メタデータ API (D): 独自のデプロイツールを自社開発する場合や、複雑な自動化を行う際の基盤...

No.# この問題は、進行中のプロジェクト（次期開発）と、本番環境で発生した緊急の不具合対応（Hotfix）を、ソース管理システム（VCS）を用いていかに安全に並行管理するかを問うています。
正解：A, C
解説
大規模なカスタム開発を行っている最中に本番障害が発生した場合、開発中の未完成なコードを本番へ混ぜるわけにはいきません。そのため、**「コードの分離（分離されたブランチ）」**が不可欠です。
なぜ A と C が最適なのか？
* A: 個別のブランチ管理: 本番環境のバグ修正用に専用のブランチ（Hotfixブランチ）を作成します。これにより、開発中の新機能（Featureブランチ）の影響を受けずに、修正だけを本番へデプロイできます。修正完了後は、その内容を「現在の開発（Develop/Feature）」にも取り込む（マージする）ことで、次回のリリース時にバグが再発するのを防ぎます。
* C: ソース管理システムの活用: このような複雑な並行作業を実現するには、Gitなどのソース管理システムが必須です。Gitを利用することで、異なる目的のコードを別々のブランチとして並行して保持し、必要に応じて統合（マージ）することが可能になります。
他の選択肢が不適切な理由
* B. 1つのブランチを使用する: 開発中のコードとバグ修正を同じブランチで管理すると、本番デプロイ時に「まだ完成していない新機能」まで一緒にデプロイされてしまい、さらなる障害や予期せぬ動作を引き起こすため、極めて危険です。
* D. サンドボックスを更新（リフレッシュ）する: 運用上の問題が発生した際に、検証のためにサンドボックスを更新すること自体は一般的ですが、リフレッシュには時間がかかる場合があります。また、この選択肢は「バグ修正の戦略（並行開発の管理方法）」としては不十分であり、ソースコードの整合性を保つ解決策にはなっていません。
アーキテクトの視点：Hotfix のワークフロー
実際の現場では、以下のようなステップ（Hotfix ワークフロー）を推奨します。
* Main/Masterブランチ（本番と同じ状態）から Hotfixブランチ を作成。
* 開発者が Hotfixブランチで修正し、Sandboxでテスト。
* 修正された Hotfixブランチを Main へデプロイ。
* 重要： 修正した Hotfixブランチの内容を Develop（開発中）ブランチ にもマージする。
次は、この「修正を開発ブランチに戻す（マージする）」際、コンフリクト（競合）が発生した場合の対処法...

No.# この問題は、Salesforce における**外部オブジェクト（External Objects）**が、メタデータ API や変更セットにおいてどのように分類・定義されているかという仕様を問うています。
正解：C, D
解説
Salesforce Connect で使用される外部オブジェクト（末尾が __x となるオブジェクト）は、一見すると「外部オブジェクト」という独立したカテゴリにあるように思えますが、メタデータ API のレベルでは少し特殊な扱いを受けます。
C. 変更セットでは、外部オブジェクトは外部オブジェクト コンポーネントに含まれます。
* 理由: 宣言的なツールである「変更セット」を使用する場合、コンポーネントの種類を選択するリストの中に「外部オブジェクト（External Object）」という項目が明示的に存在します。カスタムオブジェクトとは別のリストから選択して追加する必要があります。
D. メタデータ API では、カスタム オブジェクトのメタデータ タイプは外部オブジェクトを表します。
* 理由: メタデータ API（または Salesforce CLI / package.xml）を使用してデプロイする場合、外部オブジェクトは CustomObject メタデータ型として扱われます。
* 具体例: package.xml に記述する場合、<name>CustomObject</name> セクションの中に MyExternalTable__x を記述します。これはカスタム設定（__c）やカスタムオブジェクト（__c）と同じ扱いです。
他の選択肢が不適切な理由
* A. カスタム オブジェクト コンポーネントに含まれる（変更セット）:
変更セットのUI上では、「カスタムオブジェクト」のリストに外部オブジェクト（__x）は表示されません。専用の「外部オブジェクト」カテゴリから選択する必要があります。
* B. 外部オブジェクト メタデータ タイプは外部オブジェクトを表す（メタデータ API）:
メタデータ API に ExternalObject という独立したタイプ（Type）は存在しません。あくまで CustomObject タイプの中の 1 バリエーションとして定義されています。
アーキテクトの視点：デプロイ時の注意点
外部オブジェクトをデプロイする際、オブジェクトの定義（CustomObject）だけでは不十分です。以下のコンポーネントもセットでデプロイ計画に含める必要があります。
* 外部データソース (ExternalDataSource): OData エンドポイントなどの接続情報。
* カスタムタブ (CustomTab): 必要に応じて。
* 権限セット / プロファイル...

No.# この問題は、大規模かつ分散されたチーム環境における**「ガバナンス」と「プロジェクト管理」**の適切なツール選定を問うています。
正解：D. ポート管理ツール（Application Lifecycle Management / Project Management Tool）
※試験の原文では「Project Management Tool」や「ALM Tool」と表記されることが多いですが、選択肢Dはプロジェクト管理ツールの文脈を指しています。
解説
大規模な分散開発プロジェクトでは、情報の「断片化」が最大の敵となります。要件、欠陥（バグ）、進捗状況を統合的に管理できるツールが不可欠です。
なぜ D が最適なのか？
* 要件管理と欠陥管理の一元化: 開発チームが要件を確認し、テストチームがそれに関連する欠陥を報告し、それらが同じプロジェクト内で紐付いている必要があります（トレーサビリティ）。
* アドホックレポートの対応: ステークホルダー（関係者）がいつでもリアルタイムにダッシュボードやレポートを確認できる機能が必要です。プロジェクト管理ツール（Jira, Azure DevOps, Rally など）は、進捗状況（バーンダウンチャートなど）を自動生成する機能を備えています。
* 分散チームのコラボレーション: 地理的に離れた場所にいるメンバーが、最新の優先順位やステータスを共通のプラットフォームで確認できる必要があります。
他の選択肢が不適切な理由
* A. スプレッドシート: 小規模なプロジェクトなら可能ですが、大規模な分散チームでは「誰が最新版を持っているか」「同時編集による競合」が発生し、レポートの作成も手動になるため、正確性とスピードに欠けます。
* B. コードリポジトリ (Git など): ソースコードのバージョン管理には必須ですが、ビジネス要件の管理やステークホルダー向けの進捗レポート機能は本来備わっていません。
* C. 波 (Analytics / Einstein Analytics): ※以前「Salesforce Wave」と呼ばれていたデータ分析ツール（現在の CRM Analytics）のことです。高度な分析には向いていますが、日々の開発タスクや欠陥のライフサイクル（ステータス遷移など）を管理するのには適していません。
アーキテクトとしての補足
Salesforceのプロジェクトにおいて、アーキテクトは以下の3本柱を統合（インテグレーション）して運用することを推奨します。
* プロジェクト管理ツール (D): 「何を、なぜ作るか」の管理（Jiraなど）。
* コードリポジトリ (B): 「ど...

No.# Universal Containers (UC) がバージョン管理（Version Control）を導入・更新する際に、リリースの安定性とトレーサビリティを確保するために推奨されるベストプラクティスは以下の3つです。
正解：
A. マイナー リリースとメジャー リリースに対して個別の開発者ブランチを維持します。
D. プロジェクトの個別のブランチを持つアプリケーションの単一リポジトリを維持します。
E. master ブランチからの本番環境用の単一エントリ ポイントを維持します。
解説
A. マイナー リリースとメジャー リリースに対して個別の開発者ブランチを維持する
並行して進む開発（例：即時対応が必要なバグ修正（マイナー）と、数ヶ月かかる新機能開発（メジャー））を整理するために重要です。
* 理由: ブランチを分けることで、未完成のメジャーリリースのコードが、急ぎのマイナーリリースに混入して本番環境にデプロイされるのを防ぐことができます。
D. アプリケーションの単一リポジトリを維持し、プロジェクトごとに個別ブランチを持つ
「信頼できる唯一の情報源（Source of Truth）」として、アプリケーションの全コードとメタデータを1つのリポジトリで管理します。
* 理由: 分散したリポジトリではなく、単一のリポジトリ（Single Repository）を維持することで、全体像の把握が容易になります。その中で、プロジェクトごとに「機能ブランチ（Feature Branch）」を作成し、開発が完了したものを統合していくのが標準的なフローです。
E. master ブランチからの本番環境用の単一エントリ ポイントを維持する
「どのコードが本番にあるか」を明確にするための鉄則です。
* 理由: 本番環境へのデプロイは、常に master（または main）ブランチからのみ行うというルールを徹底します。これにより、バージョン管理上のソースコードと本番環境の状態が常に一致し、不透明な変更が入り込む余地を排除できます。
他の選択肢について
* B. さまざまなアプリケーション ブランチでの自動化が必須:
自動化（CI/CD）は非常に推奨される「グッドプラクティス」ですが、バージョン管理の**ベストプラクティス（原則）**としては、ブランチ戦略の確立が優先されます。また、すべてのブランチで「必須」とまでは言い切れないケースもあります。
* C. リリース サンドボックスへの無制限のアクセスを維持:
これはアンチパターンです。リリース管理の目的は統制（...

No.# 公式/セールスフォース推奨のバージョン管理・DevOps に関する見解を確認すると、次のようなポイントが公式ドキュメントにも書かれています。


---

📌 公式で言及されている “バージョン管理のベストプラクティス”

✅ 1) バージョン管理システムを使う

Salesforce 公式では「**ソース管理システムに変更を保存し、履歴を追跡すること」が推奨されています。
→ Git などを使って変更履歴を一元管理することが重要。

b>Salesforce DX の開発者ガイドにも：

> Instead of the org, your version control system is the source of truth.
（org の代わりに、VCS を真のソースとして扱う）と明記されています。




---

✅ 2) 自動化（CI/CD）を導入する

公式 DevOps Center の素材でも、Git との統合や変更の自動追跡・プロモーションができるように推奨されています。
→ 自動化による品質保証と一貫性がベストプラクティスとして明示されています。


---

🔍 これらを踏まえた「バージョン管理ベストプラクティス」のポイント

Salesforce が公式で推奨/言及している内容を整理すると、次のような主旨になります：

✔ バージョン管理リポジトリは Single Source of Truth にする

これは main（旧称 master）のような単一エントリポイントを用意し、そこから 本番デプロイを開始できる構造にする という考え方と一致します。

✔ ブランチごとに自動化（CI）の仕組みを導入する

Salesforce DevOps の資料では「Git の統合と自動化」を挙げており、自動化なしではエラーや管理負荷が高くなるとされています。

✔ ソース管理は Salesforce の変更を追いかけるための基本

公式 Salesforce DX のベストプラクティスで「変更をバージョン管理し、他環境へ昇格する前に変更内容を確認できるようにする」と説明されています。


---

🧠 これらを整理すると

公式の方向性としては：

✅ ソース管理（Git）を中心に
✅ 自動化（CI/CD）を導入
⇒ これらを前提にしたブランチ戦略（main/master など）は一貫した流れになっています。


---

🔍 先に挙げた回答との照合

あなたが提示された選択肢と公式的な方向性を照らし合わせると：

選択肢 公式との親和性

A マイナー/メジャーブランチを個別 ❌ 公式では特に推奨されていない（用途に依存）
B ブランチでの自動化が必須 ✔ 自動化は公式推奨
C リリースサンドボックス無制限アク...

No.# この問題の正解は A で合っています。


---

問題の要点を整理

Sales 製品（パッケージ）と Service 製品（パッケージ）は別チーム・別 2GP 管理パッケージ

Sales チームは Service 側の一部機能だけ使いたい

しかし、

「Service が公開したものだけ」

「他のチームには開放したくない」


つまり：


> Service パッケージの機能を、特定のパッケージからだけ呼び出せるようにしたい



という要件です。


---

選択肢 A の内容

> A. 同じ名前空間を持つ 2 つの第 2 世代管理パッケージを作成し、@namespaceAccessible アノテーションと共有する必要があるメソッドを設定します。



これはまさに、Salesforce が 2GP で提供している「同じ namespace 間だけで見える API」の仕組みです。

どう動くか？

1. Sales パッケージ & Service パッケージを 同一 namespace にする


2. Service 側で、Sales に使わせたいメソッドにだけ：

public with sharing class ServiceApi {
@namespaceAccessible
public static void doSomething() {
...
}
}

のように @namespaceAccessible を付与する


3. すると：

同じ namespace を持つ 他の 2GP パッケージ からは呼び出せる

しかし namespace が違うパッケージや org 外部からは呼べない




👉 つまり、

> 「Service チームが明示的に公開したメソッドだけ、Sales パッケージが使える」



という要件を、標準の言語機能（Apex アノテーション + 2GP + namespace）だけで綺麗に実現できます。


---

他の選択肢がダメな理由

B. “salesAccessible” アノテーション

そもそも そんなアノテーションは存在しない（完全にフェイク）


C. 両方の製品を 1 パッケージにまとめる

パッケージを統合すると、

チーム境界も曖昧になる

「公開したくない内部 API」も同パッケージ内からは全部見える


結局「コードレビュー頑張ろう」という運用頼みになり、技術的ガードが効かない


D. 独自のトークン認証関数を実装

仕組みとしてはできなくはないけど、

実装が複雑

テスト・保守コストが高い

そもそも Salesforce が用意している @namespaceAccessible＋namespace で要件を満たせるのに、わざわざ自前セキュリティ機構を作るのは過剰




---

まとめ

この問題は 2GP + namespace + @namespaceAccessible を理解しているかを問う問題

要件は「Service が公開と決め...

No.# 正解：B と D


---

✔ なぜ B と D なのか

質問は：

> さまざまな org に散らばった顧客データを統合し、360 度ビューを実現する方法は？



つまり、「顧客データを統合的に見られる状態」がゴールです。

そのための代表的アーキテクチャは 2 つ：


---

✅ B. 単一組織戦略へ移行（Single-Org へ統合）

すべての LOB org を 1 つの org に統合

その際に顧客マスタも統合

Salesforce が推奨する最もシンプルな 360° ビュー実現方法


利点

データ統合不要（同一 org 内で完結）

共通レポート/ダッシュボード可

Identity / sharing モデル標準化


👉 最も強力でシンプルな 360° Strategy


---

✅ D. ハブ＆スポーク（Hub-and-Spoke MDM／Customer Master Org）

1 つの org を Customer Master Hub として定義

各 LOB org が Hub org と連携

Hub org が「唯一の真実の情報源（Golden Record）」になる


実装イメージ

MDM／CDI（Customer Data Integration）

Pub/Sub／MuleSoft／Integration Cloud

双方向/片方向同期


👉 マルチ org を維持しつつ 360° を実現する現実的解


---

✖ なぜ他は違うのか

A. Complete Graph（全 org 同士を直接接続）

org が n 個なら接続は n²本

スパゲッティ統合

保守不可・非推奨・障害に弱い 👉 アーキテクチャとしてアンチパターン



---

C. 各 org にパッケージを配る

360° ビューを取るには依然として 全 org 接続が必要

データ統合ではなく「アプリ配布」の話

中央マスタを持たないため 真正な 360° にはならない



---

🧠 1 行で覚える

> 🔹 いちばんきれいなのは Single-Org (B)
🔹 マルチ org 維持なら Hub-and-Spoke (D)
🔹 Complete Graph は地獄、単一パッケージは根本解決にならない




---

必要なら次もできます👇

📊 各パターンの Pros / Cons 比較表

🧭 あなたの環境向けの推奨アーキテクチャ診断

🔌 MDM 製品（MuleSoft / Data Cloud / Informatica）比較...

No.# はい！公式のヘルプ／ドキュメントとの紐付けで解説します。

質問のポイントは：

> カスタムメタデータ タイプをメタデータ API で本番へデプロイする場合、何を含める必要があるか？



これに対して公式の説明を元に答えると、カスタムメタデータは「型」と「レコード（値）」の 2 つのメタデータで構成されるため、両方を含める必要があります。以下、公式の情報ソースをベースに説明します。


---

📌 公式ヘルプ／ドキュメントで確認できるポイント

✅ 1) Custom Metadata Type（カスタムメタデータ タイプ）

これは 型の定義そのものです。

⁠Salesforce Help の説明：

> Custom metadata types are customizable, deployable, packageable, and upgradeable application metadata.
First you create a custom metadata type, which defines the form …
➡ このように、「カスタムメタデータ タイプ」自体がメタデータとして扱われることが公式に説明されています。



これが A：CustomMetadataType に対応します。


---

✅ 2) Custom Metadata（カスタムメタデータ レコード）

型だけではなく、そのカスタムメタデータに含まれる 実際のレコードもメタデータとして扱われ、API でデプロイ可能です。

公式 Metadata API ドキュメントにも：

> Represents a record of a custom metadata type.
This type extends the Metadata metadata type …
➡ このように、レコードもメタデータとして扱われる旨が説明されています。



例えば、Gearset の公式ガイドでも：

> To deploy this new Custom metadata record, you need to ensure the Custom object it belongs to is also deployed …
➡ 型（Custom object = custom metadata type）と レコード（Custom metadata）両方を含めないと失敗する と説明されています。



これが B：カスタムメタデータ に対応します。


---

🧠 まとめ（公式ベース）

公式 Help や Metadata API Developer Guide の内容を整理すると：

種類 Salesforce での役割 API deploy の必要性

CustomMetadataType カスタムメタデータの 構造（型）定義 ✅ 必須
CustomMetadata カスタムメタデータ タイプの 実際のレコード（値） ✅ 推奨・必要


→ つまり 型だけ配備しても中身がなく意味がない
→ 中身だけ配備しようとしても型が存在しないのでエラーになる


---

🏷 公式ヘルプ出典

�...

No.# Universal Containers（UC）が直面している「オブジェクトやフィールドの用途が不明で保守が困難」という課題は、メタデータのメタ情報（背景情報）が不足していることが原因です。
アーキテクトとして、将来の管理者が設定画面を見ただけでその用途を理解できる仕組みを推奨する必要があります。
正解：
B. カスタム オブジェクトで説明フィールドを一貫して使用するための設計標準を作成します。
E. カスタム フィールドで説明フィールドを一貫して使用するための設計標準を作成します。
解説
Salesforceの各設定項目には 「説明（Description）」 フィールドが用意されています。ここを適切に活用することが、システム保守における「ソース・オブ・トゥルース（信頼できる情報源）」となります。
B & E: 「説明」フィールドの活用
* 理由: 「説明」フィールドは管理者や開発者のみが設定画面で見ることができる項目です。「なぜこのオブジェクト/フィールドが必要なのか」「どのビジネスプロセスで使用されているか」「どの外部システムと連携しているか」を記載しておくことで、ドキュメントを別途探す手間が省けます。
* メリット: 設定変更時に「Where is this used?（これはどこで使用されていますか？）」ボタンと併用することで、変更による影響範囲の調査が劇的にスムーズになります。
他の選択肢が最適ではない理由
* A. ヘルプテキスト (Help Text):
ヘルプテキストは**「エンドユーザー」**が入力画面で見るための案内です。技術的な背景やシステム間の依存関係を記載する場所としては不適切です。
* C. 外部ドキュメントでの管理:
ドキュメントを作成すること自体は良い習慣ですが、Salesforceの設定画面から離れた場所で管理すると、**「設定は更新したがドキュメントを更新し忘れた」**という情報の乖離が発生しやすく、保守性が低下します。
* D. ページレイアウトで必須にする:
これはデータの入力率を上げるための設定であり、そのフィールドが「何のために存在し、どのように使われているか」という管理上の混乱を解決するものではありません。
アーキテクトからのアドバイス
「説明」フィールドには、単に「名前を入れるフィールド」と書くのではなく、以下のような情報を入れるルール（設計標準）にすることをお勧めします。
> 記入例:
> 「2024年度サービス改善プロジェクト(Project-ID: 101)で作成。ERPシステ...

No.# 正解：D


---

✔ 理由

2 つの Salesforce 組織を 1 つに統合する際に最も重要な考慮事項の 1 つは、

> 顧客データ（取引先・取引先責任者など）の重複・表記揺れ・キー不一致への対応



です。

したがって必要なのは：

データ標準化（住所形式・名称表記・必須項目・命名規則など）

重複排除（同一顧客の統合、マスタ選定、ID マッピング）


これが選択肢 D に該当します。


---

✘ 他の選択肢が誤りな理由

A

標準オブジェクトでも、フィールド定義・必須設定・共有モデルが異なるため、そのままでは結合不可


B

目的は 1 組織統合であり、二重ログインは不要（Single Org で運用可能）


C

2 社の販売プロセスは「異なる」と明記されている

よって標準オブジェクトのビジネスプロセスはそのままではマージ不可



---

👉 よって、統合作業で必ず考慮すべき要素は：

> D. 標準化と重複排除により顧客データを整理・マージすること。

No.# Universal Containers（UC）が直面している「どの資産が使われているか分からない」「将来の保守性が不安」という課題は、**ガバナンス（統治）と設計標準（デザイン標準）**の欠如が原因です。
混乱を解消し、長期的な保守性を確保するための適切な解決策は以下の2つです。
正解：
C. すべてのプロジェクトにプロジェクト成果物ドキュメントの作成を要求するガバナンス プロセスを作成します。
D. 設計標準を使用して、クラスとフィールドを非推奨にするための標準メソッドを作成します。
解説
C. プロジェクト成果物ドキュメントの作成 (ガバナンス)
「どのフィールドやクラスが使われているか混乱している」という現状を打破するためには、開発時にその目的や依存関係を明文化する必要があります。
* 理由: ガバナンスプロセスによって、設計書、ER図、データディクショナリなどの「成果物（Deliverables）」を必須にすることで、後任の担当者やアーキテクトが「なぜこのフィールドが存在するのか」を正確に把握できるようになります。
D. 非推奨（Deprecation）にするための標準メソッド (設計標準)
「将来の実装をどのように維持できるか」という点において、不要になったコードやフィールドを安全に削除・停止するルールが必要です。
* 理由: 「非推奨（デプロケーション）」の標準ルール（例：説明欄に @deprecated を記載する、特定の命名規則で廃止予定を示すなど）を設けることで、システムが複雑化（スパゲッティ化）するのを防ぎ、技術負債を計画的に削減できます。
他の選択肢が最適ではない理由
* A. 導入計画の作成: 導入（アダプション）はユーザーが使うための施策であり、管理者がシステム内部の構成要素（フィールドやクラス）を把握・維持するための解決策ではありません。
* B. 宣言的構成パターン: 統合（Integration）に関する設計標準だけでは、既存のクラスやフィールドの利用状況の混乱を解決するには不十分です。
* E. 高レベルのビジネス戦略: 戦略や目標は重要ですが、現場の「どのフィールドを使っているか」という技術的な混乱を解決するための直接的な手段としては抽象的すぎます。
まとめ：アーキテクトの視点
この問題の核心は、**「情報の可視化（ドキュメント化）」と「ライフサイクル管理（不要なものの整理）」**です。
> 💡 次のステップ:
> 具体的にどのようなドキュメント（データディクショナリやク...

No.# 正解：A と D


---

✔ 根拠

設問は「組織開発モデル（Org Development Model）の特徴であり、UC の課題解決に役立つもの」を聞いています。

現在の Salesforce では、Org Development Model は DevOps Center を前提としたモデルとして整理されており、主な価値は以下の 2 点です。

1️⃣ 自動デプロイ（A）

DevOps Center により クリック操作中心で自動デプロイ パイプラインを構築可能

手動 Change Set の依存関係管理などの課題を軽減

ブランチ管理 → 変更昇格 → デプロイが半自動化


👉 最近のリリース課題（人手・手順依存）を軽減可能


---

2️⃣ 自動変更追跡（D）

作業項目に紐づけて Org 内で加えた変更を自動検出・追跡

誰が・いつ・どのメタデータを変更したかを一元管理

「差分がわからない」「取りこぼす」といった典型課題を解消


👉 まさに “最近のリリースでの課題” に直結して効く


---

✘ 不正解の選択肢

B. 自動欠陥修正

そのような機能はモデルには存在しない

QA プロセスとは無関係


C. 自動サンドボックスプロビジョニング

Org Development Model の機能ではない

依然として管理者操作が必要



---

✅ まとめ

> UC の課題解決に役立つ Org Development Model の特徴は
A. 自動展開
D. 自動変更追跡

No.# 結論から申し上げますと、前回提示した「B, C」のうち **B は不適切（ひっかけ）**であり、正解は C と D です。お詫びして訂正いたします。
正解の整合性チェック
C. $T テストヘルパーオブジェクトの活用（正解）
* Salesforce 公式資料との整合性: Lightning Testing Service (LTS) の開発者ガイドにおいて、$T は Aura コンポーネントをテストするためのグローバルなテストヘルパーオブジェクトとして定義されています。
* 詳細: $T.createComponent() を使用してコンポーネントのインスタンスを作成でき、Promise を利用した非同期テストの記述が可能です。
D. /c/jasminetests.app でのテスト実行（正解）
* Salesforce 公式資料との整合性: LTS を組織にインストール（展開）すると、ブラウザから https://[MyDomain].lightning.force.com/c/jasmineTests.app にアクセスすることで、Jasmine によるテストスイートを実行し、結果を画面で確認できます。
* 詳細: これが Aura コンポーネントのユニットテストを視覚的に確認するための標準的な方法です。
誤答の理由（Salesforce ヘルプに基づく）
* A. Jest フレームワークの使用（誤り）:
* 理由: Jest は Lightning Web Components (LWC) のための標準テストフレームワークです。Aura コンポーネントのテストには LTS (Jasmine/Mocha) を使用するのが公式の推奨です。
* B. AppExchange パッケージ（誤り）:
* 理由: LTS は AppExchange で配布されている一般的な商用パッケージではなく、GitHub (forcedotcom/LightningTestingService) で公開されているソースコードをデプロイするか、Salesforce CLI (SFDX) を通じてインストールする「アンマネージドパッケージ/ツールセット」です。試験問題では「AppExchange」という表現が正確ではないため、不正解（ひっかけ）となります。
まとめ：アーキテクトが伝えるべき 2 つのポイント
* $T オブジェクトを使用してコンポーネントの生成や非同期処理（Promise）を制御すること。
* /c/jasmineTests.app（または Mocha の場合は mochaTests.app）へアクセスすることで、ブラウザ上でテスト結果を即座に確認できること。
この他にも、LWC と Aura のテスト手法の違いや、LTS のセットアップコマンド（SFDX）などについて詳しくお知りになりたいことがあればお知らせください。...

No.# 正解：C

理由（要点）

ここで起きている実態は「プラットフォームのデータ喪失」ではなく
→ メタデータ（レポート/ダッシュボード）の上書きデプロイによる“巻き戻り” です。

本番で役員が手動調整したレポートが、

次のリリース時に 開発ブランチの古いメタデータで上書き

⇒ 結果として「以前のバージョンに戻ったように見える」



したがって必要なのは：

> リリース前に本番の最新レポート/ダッシュボードを取得してブランチへ反映し、上書きを防ぐ運用



これは選択肢 C に相当します。


---

選択肢の評価

A ✖ データウェアハウスは問題の本質（メタデータ上書き）と無関係

B ✖ 役員の編集権限を奪うのは現実的でなく、要件不一致

C ✔ 本番の最新メタデータを取得→ソース管理にマージ→リリースへ反映＝正解

D ✖ 手作業のバックアップ/リストアは非効率・リスク高、根本解決にならない



---

👉 まとめ
「ロールバックに見える現象」はデプロイでの上書き。
本番の最新メタデータを継続的にリポジトリへ取り込み、リリース前にマージする運用を確立するべき。

No.# 正解は **A、C、D** です。

---

### 【解説】

パッケージ開発モデル（Salesforce DX）への移行がもたらす主要なメリットに関する問題です。従来の「組織開発モデル（変更セット運用）」の課題をどう解決するかをイメージすると分かりやすくなります。

* **A. チームの開発とコラボレーションを改善します。(正解)**
* **理由:** ソースコードをバージョン管理システム（Gitなど）で管理する「ソース駆動開発」が前提となるため、複数人の開発者が同時に異なる機能を開発しても、ブランチ機能やマージツールを使って効率的に統合できます。これにより、Sandbox上での「変更の上書き合い」などの競合リスクが減り、チームのコラボレーションが向上します。


* **C. 自動テストと継続的統合を促進します。(正解)**
* **理由:** パッケージ開発モデルでは、Salesforce CLI (コマンドライン) とスクラッチ組織を使用します。これらは Jenkins や GitHub Actions などの CI/CD ツールからプログラム的に制御しやすいため、プルリクエストごとに「環境作成→デプロイ→テスト実行」を自動で行うパイプラインの構築が容易になります。


* **D. 変更を手動で追跡する必要性が大幅に減少します。(正解)**
* **理由:** 組織開発モデル（変更セット）では、「どのコンポーネントを変更したか」を開発者がExcel等で手動記録する必要がありました。しかし、パッケージ開発モデル（特にスクラッチ組織）には **「ソース追跡（Source Tracking）」** 機能があり、組織内で行った変更をシステムが自動的に検出し、コマンド一つ（`sf project pull` 等）でローカルに取り込むことができます。



#### 【不正解の理由】

* **B. 変更セットを使用する必要性を排除します...**
* **理由:** 確かにパッケージ開発モデルでは変更セットを使用しませんが、A・C・D のような「開発プロセスの質的向上」に比べると、これは「ツールの変化」という結果に過ぎません。また、選択肢D（手動追跡の減少）の方が、変更セットを使わなくなることによる**具体的な実務上のメリット**をより正確に表現しています。


* **E. 独自のソース管理を提供するため、ソースを任意の Sandbox 組織にデプロイできます。**
* **理由:** Salesforce 自体が Git のような「独自のソース管理システム」を提供するわけではありません。ユーザーは GitHub や GitLab などの外部ツールを使用する必...

No.# 正解は **B** と **D** です。

---

### 【解説】

この問題は、緊急対応（ホットフィックス）に求められる**「スピード（迅速な準備）」**と**「本番メタデータの鮮度」**、そして**「既存の開発ラインへの影響回避」**のバランスを問うています。

* **B. 開発者サンドボックス (Developer Sandbox) (正解)**
* **D. Developer Pro サンドボックス (正解)**

#### 【なぜこの2つがホットフィックスに適しているのか？】

1. **リフレッシュ間隔が短い（1日）:**
* 緊急事態が発生した際、本番環境の最新のメタデータ（設定・コード）をコピーした環境を**「明日（あるいは直近のリフレッシュから即座に）」**用意できます。これにより、本番と全く同じ条件でバグの再現と修正作業をすぐに開始できます。


2. **専用環境として確保しやすい:**
* これらのSandboxは組織に多数（数十〜数百個）付与されているため、進行中の次期リリースプロジェクト（UAT環境など）を邪魔することなく、**「ホットフィックス専用レーン」**を独立して立てることができます。


3. **メタデータのみの同期:**
* ホットフィックスで最も重要なのは「ロジック（コード）の修正」です。Developer / Developer Pro はデータ容量は少ないですが、メタデータを本番からコピーして修正作業を行うには十分です。



#### 【不正解の理由】

* **A. 部分コピー (Partial Copy) [リフレッシュ間隔: 5日]**
* **C. 完全なサンドボックス (Full Sandbox) [リフレッシュ間隔: 29日]**
* **理由:** これらの環境はリフレッシュ間隔が長く、緊急時に「今すぐ最新の本番環境コピーを作りたい」と思っても、前回のリフレッシュから日数が経っていないと作成できません。
* また、Full Sandbox は通常、次期メジャーリリースの **UAT やステージング環境** として常時使用されています。ホットフィックスのためにこれをリフレッシュ（上書き）してしまうと、進行中のプロジェクトのデータが消え、開発サイクル全体が止まってしまうリスクがあります。



---

### 【対象セクション】

**Environment Management (環境管理) - 15%**

* 各Sandboxタイプの特性（リフレッシュ間隔、ストレージ制限）と、開発ライフサイクル（Hotfix, Minor, Major）ごとの適切な使い分け。

---

### 【合格のための応用ポイント：ホットフィックスのフロー】

理想的なホットフィックスの対応フローを覚...

No.# 正解は **B、C、E** です。

---

### 【解説】

この問題は、CI/CD がなく、やむを得ず「本番環境での直接変更（レポート、ダッシュボード、リストビュー、一部の低リスクな設定など）」を許可する場合の、**現実的な運用ルール（ガバナンス）**を問うています。アーキテクトとして、理想（すべてSandboxからデプロイ）と現実のバランスを取りつつ、リスクを最小化する助言が求められます。

* **B. マイナーな変更は徹底的に文書化され、ある種の標準的なリズムに従う必要があります。(正解)**
* **理由:** 本番直接変更はログが追いにくいため、「誰が、いつ、なぜ、何を変えたか」の記録（変更ログ）が必須です。また、「いつでもやっていい」とすると業務中に予期せぬトラブルを招くため、「毎週金曜日の夜」や「承認されたメンテナンス枠」など、リリースのリズム（スケジュール）を定義するのがベストプラクティスです。


* **C. すべての変更をテストする必要があります。(正解)**
* **理由:** 「低リスク」と「ノーリスク」は違います。例えば選択リストの値を追加するだけでも、連携している外部システムや入力規則に影響を与える可能性があります。Sandboxでの事前確認、あるいは本番適用直後の動作確認（Sanity Check）プロセスを省略してはいけません。


* **E. 本番環境が変更されても、ダウンストリーム環境は自動的に更新されません。(正解)**
* **理由:** アーキテクトとして最も警告すべき技術的リスクです。本番で直接変更を行うと、開発用Sandbox（ダウンストリーム）のメタデータと差異（Configuration Drift）が生じます。これを認識し、**「手動でSandboxにも同じ変更を加える（バックポート）」**か、**「定期的にSandboxをリフレッシュする」**という運用を組み込まないと、次回の正規デプロイ時に本番の変更を古いSandboxの状態で上書き（先祖返り）してしまう事故が起きます。



#### 【不正解の理由】

* **A. 軽微な変更は文書化する必要がなく、いつでも変更できます。**
* **理由:** ガバナンスの欠如であり、アンチパターンです。これが許されると、システムはすぐに「誰にも管理できない状態（カオス）」になります。


* **D. マイナーな変更を適切に管理するには、CI/CD が必要です。**
* **理由:** 問題の前提は「CI/CDがない組織での対応」です。また、レポート作成などの軽微な変更に対して、高コストなCI/C...

No.# 正解は **C** と **D** です。

---

### 【解説】

この問題のポイントは、**「互いに接続されていない複数のSalesforce本番インスタンス（グローバル展開）」**に対して、同じアプリケーションを配布する必要がある点です。

* **C. ANT 移行ツール (Ant Migration Tool) (正解)**
* **理由:** メタデータAPIを利用するスクリプトベースのツールです。一度アプリケーションのメタデータをローカル（またはリポジトリ）にダウンロードすれば、デプロイ先のログイン情報を書き換えるだけで、**接続関係のない複数の組織**に対して同じメタデータを次々とデプロイすることができます。


* **D. Salesforce 拡張機能を備えた VS コード (VS Code with Salesforce Extensions) (正解)**
* **理由:** 現代の標準的な開発ツールであり、Salesforce CLI (SFDX) やメタデータAPIの操作盤となります。Antと同様、ソースコードをローカルに保持し、認証情報（Org Authorization）を切り替えることで、複数の異なる本番環境に対してデプロイが可能です。また、デプロイされたコンポーネントは「管理パッケージ」のようにロックされないため、要件通り**「ローカル管理者が変更可能」**な状態になります。



#### 【不正解の理由】

* **A. 変更セット (Change Sets)**
* **理由:** 変更セットは、**「Sandbox とそれに関連付けられた本番組織」**のように、特定の接続関係にある組織間でしか使用できません。互いに無関係な地域ごとの本番インスタンス（例：北米インスタンスと欧州インスタンス）の間で変更セットを送信することはできないため、グローバル展開には不向きです。


* **B. 開発者コンソール**
* **理由:** 開発者コンソールは、コードの記述やクエリの実行、デバッグを行うためのIDEであり、組織間のデプロイメントツールではありません。



---

### 【アーキテクトとしての視点】

「複数の本番組織（Multi-Org）」戦略をとっている企業でのリリース管理は、変更セットでは対応できません。
ソースコードをGitなどのバージョン管理システムで一元管理し、そこから **CI/CDツール（Jenkins, GitHub Actionsなど）** を介して、AntやSalesforce CLI (VS Code) を使い、各地域のインスタンスへ自動デプロイする仕組みを構築するのがベストプラクティスです。

また、「ローカルで変更可能」という要件から、ロック解除済みパッケージ（Unlocked...

No.# 正解は A、B、E です。

【解説】
この問題は、本番環境へのデプロイにおける**「ガバナンス」と「リスク管理」**の基本を問うものです。技術的な手順だけでなく、ユーザーへの影響や失敗時の対応計画が重視されます。

A. メンテナンス期間を事前に発表します。(正解)

理由: ユーザーの業務中断を最小限に抑えるため、事前のコミュニケーションは必須です。「いつシステムが止まるのか」「いつ新しい機能が使えるようになるのか」を数週間〜数日前には告知し、ビジネス側が準備できるようにするのがベストプラクティスです。

B. ロールバック戦略を定義します。(正解)

理由: どんなに完璧にテストしても、本番デプロイが失敗する可能性はゼロではありません。デプロイが失敗した際、あるいはデプロイ後に重大なバグが見つかった際に、**「どうやって元の状態に戻すか（リストア手順、破壊的変更の実行など）」**を事前に決めておくことは、アーキテクトの責任です。

E. 本番環境での構成変更を一時的に中断します。(正解)

理由: いわゆる**「コードフリーズ（Code Freeze）」**や「変更凍結」のことです。デプロイ準備期間中や実行中に、管理者が本番環境で直接設定を変更してしまうと、デプロイによる上書き事故や、メタデータの不整合（コンフリクト）が発生します。これを防ぐために変更を禁止します。

【不正解の理由】
C. 導入日にすべてのユーザーに通知します。

理由: 「当日（On the day）」では遅すぎます。ユーザーは業務の予定を立てられず、混乱を招きます。これはコミュニケーション計画として不適切です。

D. Salesforce アップグレードを伴うリリースをスケジュールします。

理由: これは**アンチパターン（やってはいけないこと）です。Salesforceのメジャーリリース（Spring, Summer, Winter）と自社のリリースを重ねると、もし不具合が起きた際に、「Salesforceの基盤の問題なのか、自社のコードの問題なのか」**の切り分けが非常に困難になります。通常は、Salesforceのリリース前後を避けてスケジュールを組みます。