Salesforce認定 MuleSoft Integration 基礎 の過去問対策 無料模擬試験です。実際の試験問題ではなく、公式試験ガイド（日本語版）のセクション別出題比率にそのまま準拠して書き起こしたオリジナル問題を、本番と同じ 40問収録しました。全問に解説が付いています。この記事は最後まで無料で読めます。
Salesforce資格の試験対策には、知識を読むだけでなく、問題を解き、間違えた理由を全問解説で確認する勉強法をおすすめします。解いて採点すれば、いまの自分がどのくらいの位置にいるか、どの分野を落としているかが数字で分かります。
Salesforce認定資格 過去問 模擬問 研究所（note.com/sfcertlab）
受験予定の資格が違う方は、こちらから探せます。当研究所では他のSalesforce認定資格の模擬問題集も公開しています。
この無料模試を試験対策に活かす勉強法
公式受験ガイド（日本語版）に記載されている条件に合わせています。
- 問題数：40問（本番は多肢選択方式の 40 問）
- 制限時間：70分（本番と同じ）
- 合格ライン：70%＝28問正解（本番の合格点と同じです）
この無料模試の先に、全500問版があります。
まずは本記事で現在地を確認してください。試験対策の演習量を先に確保したい方は、同じ密度の全問解説が付いた全500問・全問解説付き問題集へ進めます。
※本記事の40問は、全500問版にも含まれています。
先に40問を解き切ってください。 解答と解説はこの記事の後半にまとめてあります。1問ごとに答えを見てしまうと、本番と同じ条件で現在地を測れません。紙かメモアプリに「問1 A」のように書き出しながら進めるのがおすすめです。
問題編（全40問）
1. インテグレーションプロジェクトの役割、責任、およびライフサイクルを特定する
問1. ［難易度：シナリオ応用］
Cloud Kicks社は、営業、受注、配送の各システムを連携する企画を開始した。各部門から要望は出ているが、何を改善し、どの結果をもって成功とするかは合意されていない。プロジェクト立ち上げ時に最初に行うべきことはどれか。
A. 候補となる全コネクタをAnypoint Studioへ追加し、接続テストを始める。
B. 本番用のMuleアプリケーションを先にデプロイし、利用量を測定する。
C. 各システムのデータを一括移行し、移行件数を成果として採用する。
D. ビジネスニーズ、意図する価値、測定可能な成果を関係者と定義する。
問2. ［難易度：基礎］
インテグレーション構想について投資判断を求める前に、ビジネスケースへ含める内容として最も適切なものはどれか。
A. 期待便益を示さず、採用するコネクタの詳細設定と運用費だけを投資判断資料にする
B. 期待便益と主要前提を示さず、全実装タスクの担当者と日単位の作業予定だけを提示する
C. 解決する業務課題、期待便益、概算コスト、および主要な前提条件
D. 投資判断の前提を示さず、API仕様の全項目と各エラー応答の完成版だけを提示する
問3. ［難易度：シナリオ応用］
Ursa Major Solar社の統合プロジェクトで、追加の接続先が要求された。対応すると作業範囲が広がり、納期延長または費用増加が見込まれる。プロジェクトマネージャーが取るべき対応はどれか。
A. 範囲、スケジュール、コストへの影響を示し、関係者と優先順位や計画を調整する。
B. 納期を守るため、追加作業を計画に記録せず開発者へ割り当てる。
C. 予算を変えずに全機能を追加し、テスト工程だけを削除する。
D. 技術チームだけで追加要求を承認し、スポンサーには完了後に報告する。
問4. ［難易度：基礎］
利害と影響力が異なるステークホルダーへ、同じ頻度・同じ粒度で情報を送った結果、意思決定者の確認が遅れている。改善策として最も適切なものはどれか。
A. 利害や影響力を区別せず、全員への連絡を同じ月次報告書だけに限定して情報量を均一にする
B. 影響力は評価せず、技術チームだけを主要ステークホルダーとして高頻度の報告対象にする
C. 関心度だけで関係者を並べ、要望の多い順に同じ情報粒度で承認依頼を送る
D. 影響力と関心度を踏まえて関与方法、情報粒度、連絡頻度を調整する
問5. ［難易度：基礎］
外部APIの提供時期やネットワーク開通が統合計画の前提になっている。プロジェクト期間中のリスクと依存関係の扱いとして適切なものはどれか。
A. 開始時に一度だけ確認し、その後は変更されない前提で記録を閉じる。
B. 発生してから担当者を探し、事前の所有者や対応策は決めない。
C. 所有者と対応策を記録し、進行中も定期的に見直して更新する。
D. すべて開発者個人の課題として扱い、ステークホルダーに共有しない。
問6. ［難易度：基礎］
Cloud Kicks社のビジネスプロセスアーキテクトは、アジャイル手法に従い、チームがプロジェクトを予定どおり完了できるようにする責務を持つ。計画が遅れたとき、この役割が取るべき対応はどれか。
A. 個々のMuleフローを自ら書き直し、開発者の実装責務も引き受ける
B. 本番アラートを調整し、遅延を運用上の問題としてだけ扱う
C. アジャイルな計画と進捗をチームで見直し、完了予定への影響を調整する
D. APIのクライアントアプリケーション契約を一括して承認する
問7. ［難易度：シナリオ応用］
統合計画では、SAP、Salesforce、関係データベースの接続方式、データ所有、可用性、セキュリティ境界を整理し、各システムを公開するAPIの技術設計を決める必要がある。主に責任を持つ役割はどれか。
A. ビジネス利用者として画面操作手順だけを決めるシチズンインテグレーター。
B. 既存システムと技術制約を把握して接続構造を設計するITシステムアーキテクト。
C. プロジェクトの議事録と会議日程だけを管理するプロジェクトコーディネーター。
D. モバイル画面の色と配置だけを決めるユーザーエクスペリエンスデザイナー。
2. 重要なインテグレーションの概念と用語を認識して解釈する
問8. ［難易度：基礎］
MuleSoftにおける「アプリケーションネットワーク」の説明として最も適切なものはどれか。
A. 再利用可能なAPIによって接続されたアプリケーション、データ、デバイスのネットワークである。
B. 一つのデータベーススキーマをすべての業務システムへ強制する構成である。
C. 本番環境のMuleアプリケーションだけを一覧表示する監視画面である。
D. 一回限りのポイントツーポイント接続を変更せず保存した集合である。
問9. ［難易度：基礎］
API主導の接続の説明として正しいものはどれか。
A. 目的を定めた再利用可能なAPIでアプリケーション、データ、デバイスを体系的に接続する。
B. 利用先ごとに専用コードを書き、既存の接続は再利用しない。
C. すべてのシステムに同じ製品と同じデータベースを導入する。
D. APIを使わず、画面操作とファイル添付だけで業務を連携する。
問10. ［難易度：シナリオ応用］
Ursa Major Solar社では、モバイルアプリが在庫、価格、配送の各システムへ専用コードで直接接続している。配送システムのインターフェース変更だけでモバイルアプリの修正も必要になった。この構成を表す用語はどれか。
A. 各接続を再利用可能なAPI階層へ分離したアプリケーションネットワークである。
B. 送信者と受信者をキューで分離した非同期メッセージングである。
C. 複数の購読者がトピックから通知を受けるパブリッシュ・サブスクライブである。
D. 利用先と各システムを個別に結ぶポイントツーポイントインテグレーションである。
問11. ［難易度：シナリオ応用］
Universal Containers社の販売アプリケーションは、ERP固有のテーブル名と認証方法をコード内に直接持っている。ERP更新のたびに販売アプリケーションも修正されるため、結合度を下げたい。最も適した改善はどれか。
A. ERPのテーブル名を販売画面にも表示し、依存関係を利用者へ公開する。
B. 安定したAPI契約でERP接続を包み、利用側から実装詳細を隠す。
C. 販売アプリケーションへERPの管理者資格情報を追加して直接接続を増やす。
D. 両システムのリリース日を同日に固定し、直接参照のコードは維持する。
問12. ［難易度：難問］
AW Computing社では、旧ERPと新ERPが半年間併存し、移行済み顧客だけ新ERPへ格納される。上位の注文プロセスAPI契約を変えず、認証方式と項目差も隠したい。システムAPI層の設計として最も適切なものはどれか。
A. 旧ERP用と新ERP用の契約を上位へ並べ、注文プロセスAPIが顧客の移行状態を判定して選択する
B. 新ERPの項目を標準契約へ即時採用し、未移行顧客の応答だけ旧項目を追加して二形式を返す
C. 安定した顧客契約を持つシステムAPIが移行状態で接続先を選び、旧新モデルを正規化する
D. エクスペリエンスAPIがチャネル別にERP認証と移行判定を実装する
問13. ［難易度：シナリオ応用］
Ursa Major Solar社は、Salesforceの顧客情報、ERPの請求情報、倉庫の出荷情報を組み合わせて「注文履行状況」という共通業務機能を提供する。チャネル固有の画面整形は別のAPIが担う。注文履行状況を実装する層はどれか。
A. 各基幹システムへの接続だけを抽象化するシステムAPI層。
B. 複数システムを編成して業務処理を表すプロセスAPI層。
C. モバイル画面に合わせて項目を整形するエクスペリエンスAPI層。
D. 実行ログを一元保存して可視化する監視ダッシュボード層。
問14. ［難易度：基礎］
API主導の接続で、同じ業務機能をWebサイトとモバイルアプリから利用する。各チャネルが必要とする項目や表示粒度は異なる。チャネルごとのデータ形式を提供するAPI層はどれか。
A. 記録システムへの接続を隠蔽するシステムAPI層。
B. 利用体験に合わせて応答を整えるエクスペリエンスAPI層。
C. 複数システムの業務ロジックを編成するプロセスAPI層。
D. 実行環境のCPUとメモリを収集するランタイム監視層。
問15. ［難易度：基礎］
アプリケーションプログラミングインターフェース（API）の説明として最も適切なものはどれか。
A. 利用者が基盤システムの内部コードを直接変更するための管理画面である。
B. 機能やデータの利用方法を定め、実装詳細を隠すインターフェースである。
C. 複数サーバーのCPUとメモリだけを可視化する監視レポートである。
D. データベースの物理テーブルを全利用者へそのまま公開する仕組みである。
3. 一般的なインテグレーションの問題、ユースケース、およびテクニカルソリューションを認識する
問16. ［難易度：シナリオ応用］
Northern Trail Outfitters社では、店舗、EC、サービス部門がそれぞれ別のシステムに顧客情報を保持し、同じ情報へ個別のカスタム接続を作っている。データサイロを解消し、今後のチャネルでも再利用しやすくする方針はどれか。
A. 各チャネルから全データベースへ直接接続するコードを追加する。
B. 毎月、各システムの画面をPDF化して共有フォルダーへ保存するうえ、画像差分の承認を部門ごとに管理する。
C. 一つのチャネル専用テーブルへ全データを複製して所有させる。
D. 基幹データを再利用可能なAPIで公開し、段階化したAPIから利用する。
問17. ［難易度：シナリオ応用］
AW Computing社では、新しいSaaSを導入するたびに既存の各システムとの個別接続を追加している。接続数と変更影響が急増しているため、今後の拡張で複雑性を抑えたい。採用すべき方針はどれか。
A. システム、プロセス、エクスペリエンスのAPI階層で接続を整理し再利用する。
B. 各SaaSの画面操作を別々の手順書に記録し、連携は手作業に戻す。
C. すべてのSaaSへ相互の管理者権限を与え、直接テーブルを参照させるうえ、接続先追加のたびに権限表を個別更新する。
D. 既存のポイントツーポイント接続を複製し、名称だけ変更して追加する。
問18. ［難易度：難問］
Universal Containers社には、販売、請求、配送の組み合わせごとに作られた個別接続が多数ある。請求システムを変更すると複数の接続を修正する必要があり、同じ変換ロジックも重複している。技術的負債を段階的に減らす施策はどれか。
A. 既存接続を変更せず、新規案件でも同じコードをコピーして使う。
B. 基幹接続と業務処理を再利用可能なAPIとして分離し、利用先から共有する。
C. すべての接続を単一の巨大なMuleフローへ結合し、境界をなくすうえ、変更時は全機能を同時に再デプロイする。
D. 各利用先に請求システムのテーブル定義を配布して直接参照させる。
問19. ［難易度：基礎］
営業、EC、サポートの各システムに分散する顧客情報を、担当者が一貫した顧客像として利用できるようにする方法はどれか。
A. 各システムの顧客画面を毎週画像として保存し、目視で比較するうえ、担当者が更新日時を目視で照合する。
B. 部門ごとに新しい顧客IDを追加し、他部門には共有しない。
C. 各システム間の接続を利用者ごとに個別作成し、再利用を避ける。
D. APIで各データ源を接続し、顧客データを統合するプロセスを設ける。
問20. ［難易度：基礎］
Salesforceで受注した注文をERPへ渡し、ERP側の処理結果をSalesforceへ反映する基本的な連携方法はどれか。
A. Salesforce用とERP用のコネクタやAPIを用いて注文データを連携する。
B. 両システムの利用者が同じ画面を見て手作業で二重入力する。
C. 注文内容を画像として出力し、ERPのデータベースに添付する。
D. ERPの内部テーブル構造をSalesforce画面の項目名に直接埋め込むうえ、ERP変更時はSalesforce側の全画面を改修する。
問21. ［難易度：シナリオ応用］
Northern Trail Outfitters社では、営業担当はCRMの商談履歴を、サービス担当は別システムの問い合わせ履歴を見ている。双方が顧客との過去のやり取りを一貫して確認できるようにする方法はどれか。
A. 各部門の履歴を独立したままにし、必要なときだけ口頭で確認する。
B. 両システムの履歴をAPIで取得し、顧客単位に統合して提供する。
C. 問い合わせ履歴を毎月削除し、CRMの商談だけを顧客履歴とする。
D. サービス担当へCRMの管理者権限を付け、別システムは参照しない。
問22. ［難易度：基礎］
業務担当者がSalesforceの商談成立を契機にSlackへ通知し、関連するGoogleスプレッドシートへ行を追加したい。コードを記述せず構成する製品はどれか。
A. MuleSoft Composerを日次スケジュールで起動し、成立済み商談をまとめて処理する。
B. MuleSoft Composerで商談成立をトリガーにするが、Slack通知だけを構成する。
C. MuleSoft Composerでトリガーと二つの後続操作を構成する。
D. Anypoint StudioでSalesforce、Slack、Google Sheetsの各コネクタを使うMuleアプリケーションを開発する。
4. インテグレーション開発での一般的な技術的複雑さとパターンを説明する
問23. ［難易度：難問］
Ursa Major Solar社は、取引先がSFTPへ500MBのCSVを書き終える前にMuleが読み始める事象を防ぎたい。SFTP Connectorの直接的な設定はどれか。
A. WatermarkをCREATED_TIMESTAMPにし、作成直後のファイルだけを優先する。
B. MatcherでCSV拡張子と最終更新時刻を判定し、単一時点のサイズだけを読取り開始条件にする。
C. Lockを有効にし、取引先側の書込み完了時刻は判定しない。
D. Time Between Size Checkを設定し、二回のサイズが同じ場合に読み取る。
問24. ［難易度：シナリオ応用］
Universal Containers社は二つのアプリケーションが同じ顧客データベースを直接読み書きするShared DatabaseパターンをMuleで実装する。このパターンに対応する実装手段はどれか。
A. HTTP Connectorで各アプリケーションの画面を相互に呼び出す。
B. Database Connectorで共通データベースへアクセスする。
C. File Connectorで顧客表を一行ずつ別ファイルへ変換する。
D. JMS Connectorでデータベース接続設定をトピックとして配信する。
問25. ［難易度：シナリオ応用］
Cloud Kicks社の送料計算RPCは平均200ミリ秒だが、依存先停止時に注文スレッドが長時間滞留する。呼び出し側で最初に定めるべきものはどれか。
A. 業務上の待機上限に合うタイムアウトと、失敗時の明示的な処理方針。
B. Response Timeoutを依存先の最大バッチ時間に合わせ、画面の待機要件は別途扱う。
C. Connection Idle Timeoutを200ミリ秒にし、応答待ち時間は既定値のままにする。
D. 送料計算を一方向Publishへ変更し、同じ画面要求で結果を受け取る。
問26. ［難易度：シナリオ応用］
Ursa Major Solar社では、受注システムが注文確定を通知した後、倉庫システムが一時停止していても注文を失わず、復旧後に自分の処理速度で受け取りたい。送信側は倉庫処理の完了を待つ必要がない。最も適したスタイルはどれか。
A. 両システムが同じ画面セッションを共有する同期呼び出しを使う。
B. キューを介する非同期メッセージングで送信側と受信側を分離する。
C. 毎回、倉庫データベースの内部テーブルを受注側から直接更新する。
D. 注文ごとにAPI応答が返るまで受注画面をロックして待機する。
問27. ［難易度：シナリオ応用］
Webアプリケーションが価格照会メッセージを送り、対応する価格が返るまで待ってから利用者へ結果を表示する。要求と応答を正しく関連付ける必要がある。このメッセージ交換パターンはどれか。
A. 複数購読者へ同じイベントを配るパブリッシュ・サブスクライブである。
B. 受信確認も処理結果も待たない一方向の送信である。
C. データをファイルへ蓄積し、別の日にまとめて取り込む方式である。
D. 要求を送信し、対応する返信を待つ要求応答パターンである。
問28. ［難易度：基礎］
送信側がメッセージを渡した後、処理結果の返信を待たずに次の処理へ進む交換パターンはどれか。
A. 一方向のファイアアンドフォゲットパターンを使用する。
B. 要求応答パターンで返信が届くまで実行を停止する。
C. 共有データベースで同じトランザクションを長時間保持する。
D. Scatter-Gatherですべての並列ルートの結果を集約する。
問29. ［難易度：基礎］
一つの注文確定イベントを、在庫、配送、分析の各システムが互いを知らずに受け取れるようにしたい。適切なメッセージ交換パターンはどれか。
A. 送信者が一つの受信者を指定するポイントツーポイントキューを使う。
B. 全システムが同じデータベース行を継続的にロックして読む。
C. トピックへパブリッシュし、関心のある複数システムが購読する。
D. 送信者が各受信者の処理完了を順番に待つ要求応答を使う。
5. システムインテグレーションのための Anypoint Platform のコンポーネントと利点について説明する
問30. ［難易度：難問］
Universal Containers社は、API仕様の設計からMuleアプリケーションの実装、デプロイ後の監視までを別々の製品群で管理しており、成果物の引き継ぎに時間がかかっている。再利用可能な資産も組織内で見つけにくい。Anypoint Platformを採用する価値を最も包括的に表す説明はどれか。
A. Anypoint Studioだけで仕様の公開と本番監視まで完結させる。
B. Anypoint Exchangeを実行基盤として使い、すべてのフローを処理する。
C. 設計、構築、リリース、運用を一つの基盤上の連携したツールで扱う。
D. Anypoint Runtime ManagerだけでAPI仕様を設計し、実装も生成する。
問31. ［難易度：シナリオ応用］
Northern Trail Outfitters社では、開発者が実装を始める前に、注文APIのリソース、メソッド、データ型を定義し、関係者がモック応答で仕様を確認できるようにしたい。利用すべきAnypoint Platformの機能はどれか。
A. Anypoint Design CenterのAPI DesignerでAPI仕様を作成する。
B. Anypoint Runtime Managerでワーカーの稼働状況を監視する。
C. Anypoint Exchangeから完成済みアプリケーションだけを実行する。
D. Anypoint Monitoringで受信要求からRAML仕様を自動生成する。
問32. ［難易度：難問］
AW Computing社は、実装チームとモバイルチームが並行作業できるよう、顧客APIのリソース、HTTPメソッド、要求と応答、再利用するデータ型を先に契約として定義したい。この作業に直接使うツールはどれか。
A. Anypoint Runtime Managerでアプリケーションのデプロイ設定を作成する。
B. API DesignerでRAMLまたはOpenAPI仕様を編集する。
C. Anypoint Monitoringで本番トラフィックから要求例を収集する。
D. VM Connectorで仕様ファイルを非同期キューへ送信する。
問33. ［難易度：基礎］
開発者がビジュアルキャンバスとXML編集を使ってMuleフローを組み立て、ローカルランタイムで実行してテストしたい。使用する開発環境はどれか。
A. Anypoint Exchangeで公開資産のカタログだけを管理する。
B. Anypoint Runtime Managerで本番アプリケーションだけを監視する。
C. Anypoint StudioでMuleアプリケーションを設計してテストする。
D. API Managerで実装済みAPIへポリシーだけを適用する。
問34. ［難易度：基礎］
Mule Runtime Engineの主な役割を表す説明はどれか。
A. API仕様の文章だけを保存し、実装を一切実行しない。
B. Muleイベントをフローの構成に従って各コンポーネントで処理する。
C. 組織内の再利用可能な資産だけを検索可能なカタログにする。
D. プロジェクトのスコープ、予算、日程だけを追跡して承認する。
問35. ［難易度：基礎］
Muleフローにおけるイベントソースとイベントプロセッサーの関係を正しく説明しているものはどれか。
A. プロセッサーがフローを開始し、イベントソースは最後にログだけを保存する。
B. イベントソースが実行を開始し、後続プロセッサーがMuleイベントを順に処理する。
C. イベントソースはAPI仕様を編集し、プロセッサーは仕様をExchangeへ公開する。
D. 両者はAnypoint Runtime Managerの利用者ロールを表し、フロー要素ではない。
問36. ［難易度：シナリオ応用］
AW Computing社の開発者は、HTTP要求を受けたフローで本文とヘッダーを処理しながら、後続処理用の追跡値も保持したい。MuleイベントとMuleメッセージの関係を正しく表すものはどれか。
A. MuleメッセージがMuleイベント全体を包み、変数はメッセージ属性にしか置けない。
B. MuleイベントはMuleメッセージと変数を含み、メッセージはペイロードと属性を持つ。
C. MuleイベントはAPI仕様ファイルだけを含み、実行データはRuntime Managerに置かれる。
D. Muleメッセージはペイロードだけを持ち、HTTPヘッダーは常に破棄される。
6. API インテグレーションのための Anypoint Platform のコンポーネントと利点について説明する
問37. ［難易度：基礎］
API Designerで作成できるAPI仕様の組み合わせとして正しいものはどれか。
A. WSDLだけを作成でき、REST APIの仕様は編集できない。
B. Javaクラスだけを作成でき、API契約は別製品で管理する。
C. RAMLまたはOpenAPI仕様を作成し、仕様を設計できる。
D. デプロイ済みMuleアプリケーションのログだけを仕様として保存する。
問38. ［難易度：基礎］
複数のRAML API仕様で同じデータ型やセキュリティスキーマを再利用するために作成するものはどれか。
A. RAML APIフラグメントを作成し、仕様から参照できる資産として共有する。
B. 各APIの実行ログをコピーし、データ型の代わりに仕様へ貼り付ける。
C. Muleイベントの変数へ仕様を保存し、実行が終わるまでだけ保持する。
D. Runtime ManagerのアラートをAPI仕様のセキュリティ定義として使う。
問39. ［難易度：シナリオ応用］
Ursa Major Solar社は、設備予約APIの仕様を作成したが、実装はまだ始まっていない。モバイルチームは、定義済みの要求とサンプル応答を使って画面開発を先行し、業務担当者もインターフェースを早期確認したい。使用すべき機能はどれか。
A. Runtime Managerで空のMuleアプリケーションを本番へデプロイする。
B. Anypoint Monitoringで存在しないAPIのログ検索を開始する。
C. モッキングサービスで仕様に基づくAPIコールをシミュレーションする。
D. API Managerで実装のないエンドポイントへポリシーだけ適用する。
問40. ［難易度：シナリオ応用］
設計チームがDesign Centerで完成させたAPI仕様を、組織内の開発者が検索し、ドキュメントとバージョンを確認して実装に利用できる状態にしたい。次に行うべき操作はどれか。
A. 仕様をRuntime Managerへサーバーとして登録する。
B. 仕様をAnypoint Monitoringのログ索引へ追加する。
C. 仕様からMUnitの実行結果だけを生成して共有する。
D. APIアセットとしてAnypoint Exchangeへパブリッシュする。
解答一覧
ここから答え合わせです。まだ解き終えていない方は戻ってください。
問1 D / 問2 C / 問3 A / 問4 D / 問5 C / 問6 C / 問7 B / 問8 A / 問9 A / 問10 D
問11 B / 問12 C / 問13 B / 問14 B / 問15 B / 問16 D / 問17 A / 問18 B / 問19 D / 問20 A
問21 B / 問22 C / 問23 D / 問24 B / 問25 A / 問26 B / 問27 D / 問28 A / 問29 C / 問30 C
問31 A / 問32 B / 問33 C / 問34 B / 問35 B / 問36 B / 問37 C / 問38 A / 問39 C / 問40 D
採点と判定
結果はいかがでしたか。正解数から、いまの状況を把握しましょう。
28問以上（70%以上）
合格ラインに乗っています。ただし本番は初見の問題ばかりですし、この模試より緊張もするはずです。ここからはシナリオ問題と難問層をどれだけ潰せるかが差になります。
22〜27問
あと一歩です。取りこぼしている分野がはっきりしているはずなので、次の「セクション別の正答率シート」で弱点を特定してください。この層は演習量を積めば最も伸びます。シナリオ問題で時間を使いすぎていないかも振り返ってみてください。
21問以下
基礎領域に抜けがあります。いま受験しても厳しい結果になる可能性が高いので、分野ごとに演習量を積むことを先にしてください。
どの結果でも共通して言えること
当研究所が実際に受験してきた範囲では、シナリオ形式の問題が多く出ます。状況設定を読み解いたうえで最適な設定を選ばせてくるので、用語を覚えているだけでは手が止まりますし、思っている以上に頭と時間を使います。ここに慣れているかどうかが、同じ知識量でも結果を分けます。
本記事では40問中17問（42%）をシナリオ形式にしました。形式ごとの内訳は公式試験ガイドに公表されていないため、これは当研究所の判断による配分です。実際に受験してきた経験から、これくらいは身構えて臨んだほうがよいと考えています。
解き直すときは正解を確かめるだけでなく、問題文のどこを手がかりに絞り込んだのかを言葉にしてみてください。それが本番で効きます。
セクション別の正答率シート
問番号はセクション順に並んでいます。分野ごとに正解数を数えると、どこを重点的にやり直すべきかが分かります。
- インテグレーションプロジェクトの役割、責任、およびライフサイクルを特定する：問1〜問7（7問） 正解した数 ＿＿ / 7
- 重要なインテグレーションの概念と用語を認識して解釈する：問8〜問15（8問） 正解した数 ＿＿ / 8
- 一般的なインテグレーションの問題、ユースケース、およびテクニカルソリューションを認識する：問16〜問22（7問） 正解した数 ＿＿ / 7
- インテグレーション開発での一般的な技術的複雑さとパターンを説明する：問23〜問29（7問） 正解した数 ＿＿ / 7
- システムインテグレーションのための Anypoint Platform のコンポーネントと利点について説明する：問30〜問36（7問） 正解した数 ＿＿ / 7
- API インテグレーションのための Anypoint Platform のコンポーネントと利点について説明する：問37〜問40（4問） 正解した数 ＿＿ / 4
落とした分野をどう埋めるか
セクション別の正答率が出たら、次にやることは決まっています。落とした分野の演習量を積むことです。
まずはこのあとの全問解説で、40問ぶんの取りこぼしを潰してください。そのうえで演習量が足りないと感じたら、同じ密度の解説が付いた全500問の問題集があります。本記事の40問もこの中に含まれています。
全問解説（全40問）
正解の理由だけでなく、誤りの選択肢がなぜ誤りなのかまで書いています。間違えた問題はもちろん、迷って正解した問題も読んでおくと取りこぼしが減ります。
1. インテグレーションプロジェクトの役割、責任、およびライフサイクルを特定する
問1. 正解：D
Dが正しく、開始時には技術手段より先にビジネスニーズ、提供する価値、測定方法を明確にして関係者の判断基準をそろえる。Aは実装手段の検証であり、目的が未確定の段階では選定根拠がない。Bは計画と受け入れ条件を飛ばして本番運用へ進むため不適切である。Cの一括移行は一つの実施案にすぎず、期待成果そのものを定義する作業の代わりにはならない。
問2. 正解：C
Cが正しい。ビジネスケースは、解決する業務課題、期待便益、概算コスト、主要な前提条件を示して投資判断の材料にする。Aは期待便益を欠いており、コネクタの詳細設定と運用費だけでは投資に見合うかを判断できない。Bの日単位の作業予定は承認後の実行計画であり、投資の可否を決める材料ではない。DのAPI仕様の完成版も設計段階の成果物で、承認後に具体化すればよい。
問3. 正解：A
Aが適切で、範囲、スケジュール、コストは相互に影響するため、変更の影響を可視化し、スポンサーや主要ステークホルダーと優先順位と計画を合意する必要がある。Bは未管理のスコープクリープを生む。Cは品質リスクを高め、制約間の調整にもなっていない。Dはビジネス上の判断権を持つ関係者を除外し、承認と期待値の管理というプロジェクトマネージャーの責務を果たさない。
問4. 正解：D
Dが正しい。影響力と関心度を見て関与方法、情報粒度、連絡頻度を変えると、意思決定者が判断に必要な情報を必要な形で受け取れる。Aは全員を月次報告書だけに統一するため、承認を急ぐ相手への情報がかえって遅くなる。Bは技術チームだけを高頻度の報告対象にしており、承認権限を持つ側が抜け落ちる。Cは関心度しか見ていないので、要望は多いが影響力の小さい相手に粒度を合わせてしまう。
問5. 正解：C
Cが適切で、技術的・運用上のリスクや外部依存関係は、所有者、影響、対応策を記録し、プロジェクトの進行に合わせて継続的に見直す。Aは状況変化を検出できない。Bは問題が顕在化してから対応を始める受動的な方法で、納期影響を抑えにくい。Dは意思決定に必要な情報を隠し、スポンサーや関係者が代替案、受容、軽減策を選ぶ機会を失わせる。
問6. 正解：C
Cが正しい。ビジネスプロセスアーキテクトは、アジャイルな計画と進捗をチームで見直し、完了予定への影響を調整する立場にある。AはMuleフローの実装であり、開発者の作業を肩代わりしても計画の遅れは解消しない。Bは本番アラートの調整で、まだ本番前の計画遅延を運用上の問題へすり替えている。DのAPI契約の一括承認はAPIオーナーの権限であり、進捗の調整とは別の判断である。
問7. 正解：B
Bが適切で、ITシステムアーキテクトは既存の主要システム、データベース、接続方式、非機能要件を理解し、システムAPIなど技術的な境界を設計する。Aのシチズンインテグレーターは承認されたコネクタを使う簡易連携には関われるが、全社システム構造の所有者ではない。Cは調整支援に限定され、技術判断を担わない。Dは利用体験の設計役で、SAPやデータベースの可用性と接続境界を決定しない。
2. 重要なインテグレーションの概念と用語を認識して解釈する
問8. 正解：A
Aが公式の説明に合う。アプリケーションネットワークは、API主導の接続の原則に従う再利用可能なAPIによって、アプリケーション、データ、デバイスがつながるネットワークである。Bは共通スキーマの強制であり、APIによる疎結合を示さない。Cは運用画面の説明に限定され、ネットワークという概念全体ではない。Dは再利用と体系化を欠くポイントツーポイント接続の集合で、対比される従来方式である。
問9. 正解：A
Aが公式の定義に合う。API主導の接続は、再利用可能で目的を持つAPIを通じてアプリケーション、データ、デバイスを体系的につなぐ方法である。Bは接続のたびに専用実装を増やすポイントツーポイント型で、再利用性がない。Cは全システムを同一製品へ統一する方法ではなく、既存の異種システムをつなぐ考え方を誤解している。DはAPIによる明確な契約、見つけやすさ、再利用という利点を利用していない。
問10. 正解：D
Dが該当する。利用先が各バックエンドへ専用接続を持つポイントツーポイント方式では、接続先の変更が利用側コードへ直接波及し、接続数と保守負担が増える。AならシステムAPIがバックエンド変更を隔離するため、提示された症状と逆である。Bのキューによる非同期分離は説明されていない。Cも一対多のイベント配信を示す構成であり、モバイルアプリから三システムへの直接呼び出しを表さない。
問11. 正解：B
Bが適切で、システムAPIなどの安定した契約でERP固有の接続詳細を抽象化すれば、販売アプリケーションは内部テーブルや認証変更から隔離され、疎結合になる。Aは内部詳細への依存をさらに広げる。Cは直接接続と過剰な権限を増やし、結合度と安全上の問題を悪化させる。Dは変更日を合わせるだけで依存関係を除去せず、どちらかの変更がもう一方の修正を要求する密結合の状態を残す。
問12. 正解：C
Cが正しい。システムAPIが移行状態に応じて旧新ERPを選び、認証方式と項目差を正規化すれば、上位の注文プロセスAPIの契約を変えずに済む。Aは旧新二つの契約を上位へ並べ、プロセスAPIに移行状態の判定まで負わせるため、併存期間の終了時に上位も改修が要る。Bは応答が二形式になり、利用側が顧客ごとに項目を出し分ける必要が生じる。Dはチャネルごとに認証と移行判定を実装するので、同じ処理がチャネルの数だけ重複する。
問13. 正解：B
Bが適切。プロセスAPIは複数のシステムAPIを組み合わせ、注文履行のような再利用可能な業務プロセスを表す。Aは記録システムごとのデータや機能を抽象化する層。Cは特定チャネルの利用形態に合わせる層である。Dは運用可視化であり、API主導の3層における業務オーケストレーションではない。
問14. 正解：B
Bが適切。エクスペリエンスAPIはWeb、モバイルなど特定のコンシューマーやチャネルに合わせてデータを提示する。Aはバックエンドへのアクセスを抽象化する層。Cは複数のシステムAPIを組み合わせて業務処理を構成する層。Dは運用監視の機能であり、API主導の3層におけるチャネル適応ではない。
問15. 正解：B
Bが適切。APIはデータや機能への予測可能な利用方法を提供し、提供側の内部実装を抽象化する。Aは利用者が提供側コードを変更する仕組みではない。Cは監視ツールの説明に限られる。Dは物理構造を直接さらすため抽象化と反対であり、契約を通じて安全に機能を利用させるAPIの説明ではない。
3. 一般的なインテグレーションの問題、ユースケース、およびテクニカルソリューションを認識する
問16. 正解：D
Dが適切で、システムAPIによりデータソースへの接続を抽象化し、プロセスAPIやエクスペリエンスAPIから再利用すれば、サイロと接続の増殖を抑えられる。Aはポイントツーポイント接続を増やし、変更時の影響範囲を広げる。BのPDF共有は業務データを処理可能な形で統合しない。Cは別のサイロを作るだけで、チャネル追加時の再利用性やデータ所有の整理を改善しない。
問17. 正解：A
Aが最も適切で、API主導の接続では接続機能をシステム、プロセス、エクスペリエンスの各APIに分け、既存資産を再利用して接続の増殖を抑える。Bは自動化とデータの一貫性を失う。Cは製品間の強い依存と過剰な権限を生み、保守性と安全性を悪化させる。Dは従来の個別接続を増やすため、システム追加のたびに変更対象が増えるという問題をそのまま拡大する。
問18. 正解：B
Bが適切で、接続詳細をシステムAPIに隔離し、共通業務処理をプロセスAPIとして再利用すれば、請求システム変更の影響と重複実装を限定できる。Aはコピーされたコードをさらに増やし、負債を蓄積する。Cは責務を一つに集めるため、変更とテストの影響範囲を拡大する。Dは利用先を内部スキーマへ直接結合し、バックエンド変更から保護するというAPIの利点を失う。
問19. 正解：D
Dが適切で、各システムの顧客データをAPI経由で取得し、プロセス層で統合すれば、利用者へ一貫した顧客情報を提供できる。Aの画像は検索や自動処理ができず、更新にも追随しにくい。Bは識別子をさらに分断し、顧客の照合を難しくする。Cは利用者数に応じて接続が増えるうえ、共通ロジックを再利用できないため、サイロと保守負担を悪化させる。
問20. 正解：A
Aが適切で、Salesforce ConnectorやERP向けコネクタ、各システムのAPIを用いることで、接続と認証の詳細を抽象化しながら注文を交換できる。Bの二重入力は遅延と入力誤りを生み、自動連携にならない。Cの画像は注文項目を構造化データとして処理できない。DはSalesforce側をERPの内部スキーマへ密結合し、ERP変更時に画面や連携ロジックへ広い修正を要求する。
問21. 正解：B
Bが適切で、CRMとサービスシステムをそれぞれAPIで公開し、共通の顧客識別に基づいてプロセス層で履歴を統合すれば、各部門へ一貫した顧客像を提供できる。Aはサイロを残し、情報の遅延と漏れを解消しない。Cは有用なサービス履歴を失い、統合とはいえない。Dは過剰権限を与える一方、別システムにある問い合わせ記録を取り込まないため要件を満たさない。
問22. 正解：C
Cが正しい。Composerなら商談成立をトリガーにし、Slack通知とGoogle Sheetsへの行追加を一つのフローでローコード構成できる。Aは即時性を満たさず、Bは一方の後続処理が欠ける。Dでも実装できるが、業務担当者がコードを記述せず構成するという条件に合わない。
4. インテグレーション開発での一般的な技術的複雑さとパターンを説明する
問23. 正解：D
DはSFTP Connectorが二回のサイズ確認を行い、値が同じなら読み取り準備完了と判断する設定である。Aは新規性、Bは名前、Cはアクセス時のロックであり、書込み中かを二回のサイズで判定しない。
問24. 正解：B
Bが公式のEIP対応表にあるShared Databaseパターンの実装手段である。AはRPC、CはFile Transfer、DはMessagingの手段であり、共通データベースへの直接アクセスではない。
問25. 正解：A
同期RPCは呼び出し先の遅延と可用性が呼び出し側へ波及する。Aはその境界を制御する。Bは資源枯渇、Cは契約不能、Dは業務誤りを生む。
問26. 正解：B
Bが適切で、メッセージキューは送信側と受信側の稼働タイミングを分離し、受信側が処理可能になった時点でメッセージを消費できる。Aの画面セッション共有は可用性の結合を強める。Cの内部テーブル直接更新は受信システムのデータモデルに依存し、変更影響が大きい。Dの同期要求応答は倉庫停止中に受注画面まで待たせるため、送信側が完了を待たないという条件を満たさない。
問27. 正解：D
Dが正しく、要求応答では呼び出し側が要求を送り、その要求に対応する返信を受け取ってから後続処理を進める。Aのパブリッシュ・サブスクライブは複数の関心先への通知に向き、単一要求への返信を前提としない。Bの一方向送信は処理結果を待たないので画面表示に必要な価格を得られない。Cのファイル一括連携は即時性がなく、個々の要求と応答の相関を扱うこの場面に合わない。
問28. 正解：A
Aが正しい。一方向またはファイアアンドフォゲットでは、メッセージ送信後に処理結果を待たず、送信側は自分の実行を継続する。Bは返信を待つため反対の交換パターンである。Cはデータ共有方式とトランザクション管理の話で、送信後の応答有無を表す交換パターンではない。DのScatter-Gatherは複数ルートを並列実行して結果を集約するため、結果を待たない一方向送信とは動作が異なる。
問29. 正解：C
Cが適切で、パブリッシュ・サブスクライブでは送信者がトピックへイベントを公開し、複数の購読者がそれぞれ受信できる。送信者と受信者は直接互いを知る必要がない。Aのポイントツーポイントキューでは一つのメッセージを通常一つの受信者が消費する。Bはデータベース競合と密結合を生み、イベント配信を表さない。Dは受信者ごとの同期応答を要求し、独立した複数購読者への通知に適さない。
5. システムインテグレーションのための Anypoint Platform のコンポーネントと利点について説明する
問30. 正解：C
Cが適切で、Anypoint Platformはアプリケーションネットワークを設計、構築、リリース、運用するためのツール群を提供する。AのAnypoint Studioは主にMuleアプリケーションの開発環境で、資産公開や本番運用の全機能を単独では担わない。BのAnypoint Exchangeは再利用資産のカタログであり実行基盤ではない。DのAnypoint Runtime Managerはデプロイ後の管理を担い、API仕様の設計ツールではない。
問31. 正解：A
Aが適切で、Anypoint Design Centerに含まれるAPI DesignerはRAMLやOpenAPI仕様を設計でき、モッキングサービスで実装前の確認も行える。BのAnypoint Runtime Managerは実行中アプリケーションの管理領域で、仕様作成には用いない。CのAnypoint Exchangeは資産の共有と再利用を担うが、要件に合わせた仕様設計そのものではない。DのAnypoint Monitoringは運用監視用で、要求から仕様を生成する機能ではない。
問32. 正解：B
Bが正解で、API DesignerはRAMLまたはOpenAPI仕様を作成し、リソース、メソッド、パラメーター、データ型などを実装前に定義できる。AのAnypoint Runtime Managerはデプロイと運用管理のための機能で、API契約の編集場所ではない。CのAnypoint Monitoringは稼働後の観測に用いるため、設計先行の要件に合わない。DのVM ConnectorはMuleフロー間のメッセージ連携に使うもので、API仕様を設計しない。
問33. 正解：C
Cが正しい。Anypoint StudioはMuleアプリケーションを設計、実行、テストするEclipseベースの統合開発環境で、ビジュアルキャンバスと設定XMLの両方を扱える。AのAnypoint Exchangeは資産の検索、共有、再利用を担い、フローのローカル実行環境ではない。BのAnypoint Runtime Managerはデプロイ後の管理が中心である。DのAPI ManagerはAPIインスタンスの管理とポリシー適用に使い、Muleアプリケーション開発の代替にはならない。
問34. 正解：B
Bが正しい。Mule Runtime Engineは、イベントソースが生成したMuleイベントをフローへ渡し、設定された順序でイベントプロセッサーに処理させる実行基盤である。AはAPI仕様管理の説明で、ランタイムの実行責務と反する。CはAnypoint Exchangeのカタログ機能に近く、イベント処理ではない。Dはプロジェクト管理の責務であり、Muleアプリケーションの実行を担う製品コンポーネントの説明ではない。
問35. 正解：B
Bが正しい。HTTP ListenerやSchedulerなどのイベントソースがMuleイベントを生成してフローを開始し、後続のコンポーネントやコネクタ操作がイベントプロセッサーとして処理を進める。Aは開始と処理の役割を逆にしている。CはAPI設計と資産公開の工程をフロー実行要素に置き換えており誤りである。DはどちらもMuleアプリケーションを構成する概念であり、利用者権限の名称ではない。
問36. 正解：B
Bが正しい。MuleイベントはMuleメッセージと変数で構成され、Muleメッセージには本文に相当するペイロードと、HTTPヘッダーなどのメタデータを表す属性が含まれる。Aは包含関係を逆にし、変数の位置も誤っている。Cは設計資産と実行時イベントを混同している。Dは属性の存在を否定しており、HTTP Listenerが要求本文をペイロード、その他のHTTP情報を属性へ設定する動作と矛盾する。
6. API インテグレーションのための Anypoint Platform のコンポーネントと利点について説明する
問37. 正解：C
Cが正しい。API DesignerのWeb UIではRAMLとOpenAPI仕様を設計でき、リソースやメソッドなどを契約として記述できる。AはREST API仕様を扱えないとしている点が誤りである。BのJavaクラス生成はAPI Designerの中心機能ではなく、実装と契約を混同している。Dの実行ログは運用時の記録であり、利用者と実装者が合意するAPI仕様の代わりにはならない。
問38. 正解：A
Aが正しい。API DesignerではRAML APIフラグメントを作成でき、データ型やセキュリティスキーマなどをExchangeで共有して複数仕様から再利用できる。Bの実行ログはAPI契約を構成する型定義ではない。CのMuleイベント変数は個々の実行中に使うデータで、設計資産の共有場所にならない。DのRuntime Managerアラートは運用上の通知であり、要求や応答に適用するセキュリティスキーマを定義しない。
問39. 正解：C
Cが適切。モッキングサービスはAPI仕様の例と定義に基づく要求・応答をシミュレーションでき、実装前の並行開発とレビューを可能にする。Aは動作する実装を提供せず本番配備も不要。Bは実行データがないため検証にならない。Dは実トラフィックの管理機能で、サンプル応答を生成する設計時機能ではない。
問40. 正解：D
Dが適切。Design Centerで作成したAPI仕様はExchangeへパブリッシュすることで、発見、文書化、バージョン管理、再利用の対象になる。Aは実装済みアプリケーションの配備・管理先であり仕様カタログではない。Bは運用テレメトリを扱う。Cはテスト結果にすぎず、API契約そのものを共有できない。
この先の演習量を確保するために
ここまでの40問と同じ密度の解説が、全500問すべてに付いた問題集を販売しています。本記事の40問も、この500問の中に含まれています（残りの460問は本記事には入っていません）。
免責事項
- 非公式のオリジナル教材です：本記事の模擬問題・解説はすべて当研究所が独自に作成したものであり、実際の試験問題の複製・転載・流用ではありません。Salesforce, Inc.が提供・監修・承認したものではなく、同社と提携・協賛等の関係もありません。Salesforce、Trailhead等の名称・ロゴはSalesforce, Inc.の商標または登録商標です。
- 公式情報との相違の可能性：実際の試験の出題内容・出題形式・出題比率・難易度・合格ライン・受験料等は、Salesforce社の判断により予告なく変更されることがあります。当研究所は適宜、内容の点検を行っていますが、本記事が常に最新の公式試験ガイドと完全に一致することを保証するものではありません。受験前に必ず公式試験ガイド（Trailhead／Salesforce公式サイト）で最新情報をご確認ください。
- 対応バージョンについて：本記事の問題は作成時点の公式情報を参照しており、公式試験ガイド（日本語版）に明記された対応バージョンと差異がある場合があります。
- 合格・成果の保証はありません：本記事は学習の補助を目的としたものであり、内容を利用したことによる資格試験の合格・特定のスコア取得その他の成果を保証するものではありません。
- 正確性についての留意：内容の正確性については作成時点および見直し時点で可能な限りの確認を行っていますが、誤字脱字・解説内容の誤り等が皆無であることを保証するものではありません。お気づきの点はコメント欄にてお知らせください。確認のうえ無料で修正します。
- 損害についての免責：本記事の内容を利用したことにより生じたいかなる損害（学習時間の損失、受験結果に関するものを含みますがこれに限りません）についても、当研究所は責任を負いかねます。あらかじめご了承のうえご利用ください。
- 著作権・利用範囲：本記事の全文の著作権は当研究所に帰属します。読者ご本人が学習目的でご利用いただく範囲を超えて、内容の複製・転載・再配布・第三者への共有・譲渡・転売等を行うことは禁止します。