こんにちは！エンジニアの岩間です。
Salesforce × AWS Partner CRM Connector の連載、第3回です。前回はセットアップ手順とハマりどころを紹介しました。
| 回 | テーマ |
|---|---|
| 第1回 | 導入編 — なぜ AWS Partner CRM Connector を入れたのか |
| 第2回 | セットアップ編 — Guided Setup と指定ログイン情報のハマりどころ |
| 第3回（本記事） | フィールド設計編 — フィールド追加から日本語化・仕様突き合わせまで |
| 第4回 | ハマりどころ編 — パッケージのバグから仕様の罠まで |
| 第5回 | 運用編 — 同期機能の使い分けと提出フロー |
| 第6回 | Backfill / Refresh 編 — 受信エラーとの戦い |
今回は、Field Mapping の仕組みと、標準 Opportunity へのフィールド追加、フィールドの分類設計について書いていきます。
目次
Field Mapping の仕組み
AWS Partner CRM Connector は、Salesforce と AWS Partner Central の間でどのフィールド同士を対応させるかを「Field Mapping」というカスタムオブジェクト（awsapn__Field_Mapping__c）で管理しています。
1件のマッピングレコードはこんな構成です。
| フィールド | 説明 | 例 |
|---|---|---|
| Source Object | Salesforce 側のオブジェクト | Opportunity |
| Salesforce API Field Name | Salesforce 側のフィールド API 名 | ACE_Country__c |
| Target API Field Name | AWS Partner Central API 側のフィールド名 | country |
| Enable Updates From APN | AWS 側からの更新を許可するか | true / false |
さらに、ピックリスト型のフィールドには「Field Mapping Detail」（awsapn__Field_Mapping_Detail__c）という子オブジェクトで、値の対応関係を1件ずつ定義します。たとえば country フィールドなら、Salesforce 側の「日本」と AWS 側の「Japan」を紐づけるレコードが存在します。今回の環境では、この Detail レコードが全体で819件ありました。
このマッピングの仕組みを理解しておくと、フィールドが同期されない原因やピックリスト値の送信エラーの原因を特定しやすくなります。
今回の環境で使用した Field Mapping と Field Mapping Detail の全量データは Gist に公開しています。
https://gist.github.com/iwamarisa/12bc552bd299031bef4d6c93d5d75e14
標準 Opportunity へのフィールド追加
第1回で書いた通り、AWS Partner CRM Connector のカスタムオブジェクト（awsapn__ACE_Opportunity__c）ではなく、標準の Opportunity オブジェクトで運用する方針にしました。
ただ、標準 Opportunity を ACE のオポチュニティ連携に使うには、必要なフィールドを自分で追加する必要があります。AWS Partner CRM Connector をインストールしただけでは、標準 Opportunity にはフィールドが生えてきません。カスタムオブジェクトのフィールドを参考に、手動で合計88件のカスタムフィールドを追加しました。内訳は商談（Opportunity）に86件、取引先（Account）に1件、取引先責任者（Contact）に1件です。
88件のフィールドを Salesforce の GUI で1つずつ作成していくのは現実的ではありません。ここで活躍したのが Salesforce CLI と Claude Code です。
やったことはシンプルで、まず SF CLI でカスタムオブジェクトのメタデータを取得します。
|
1 2 |
$ sf project retrieve start --target-org geekfeed \ --metadata CustomObject:awsapn__ACE_Opportunity__c |
これでカスタムオブジェクトのフィールド定義が .field-meta.xml ファイルとして手に入ります。あとは Claude Code に「フィールド名のプレフィックスを awsapn__ から ACE_ に変更して、Opportunity 用のディレクトリにコピーして」と指示すれば、必要なフィールド定義が一括で生成されます。
フィールド API 名の40文字制限に引っかかるものがあったり（ACE_Opportunity_Engagement_Invitation_ARN__c → ACE_Opp_Engagement_Inv_ARN__c に短縮）、数式フィールド内の参照先も awsapn__ → ACE_ に書き換える必要があったりと、細かい調整はありましたが、Claude Code がまとめて対応してくれました。
最後に SF CLI でデプロイします。
|
1 2 |
$ sf project deploy start --target-org geekfeed \ --source-dir force-app/main/default/objects/Opportunity/fields |
GUI でポチポチやっていたら半日はかかりそうな作業が、このやり方なら数十分で終わります。
コラム: ACE Opportunity の「old」フィールドに注意
ここで1つ落とし穴がありました。ACE Opportunity のカスタムオブジェクトには、同じ意味のフィールドが old 版と new 版の2つ存在するものがあります。
たとえば awsapn__Campaign_Name__c（old）と awsapn__Campaign_name_new__c（new）のように、API のバージョンアップに伴って新しいフィールドが追加され、旧フィールドがラベルに「Old」と付けられて残っている状態です。
今回のフィールドコピー作業では、Claude Code に「ACE Opportunity のフィールドをコピーして」と指示した際、old 版のフィールドを参照元にしてしまいました。私自身もレビューで見落としていたため、後から気づいて new 版に差し替える手戻りが発生しています。old 版のフィールドはピックリスト値が古いままなので、new 版を参照元にしていれば、後述するレガシーピックリスト値の追加作業（partnerPrimaryNeedFromAws の9件など）が不要だった可能性があります。
Claude Code に指示を出すときは、対象フィールドの選定基準まで明確に伝えること、そしてその出力結果を自分でもしっかり確認することが大事だと実感しました。
フィールドの分類設計 — 編集可 / 参照のみ / 非表示
カスタムフィールドを追加するとなると、全部をそのままページレイアウトに並べるわけにはいきません。ユーザーが編集してはいけないフィールドを触ってしまうと、AWS への送信時にエラーになります。
そこで、フィールドを用途に応じて3つに分類しました。
| 区分 | 説明 |
|---|---|
| 編集可 | パートナーが入力・編集するフィールド。AWS への送信データの元になる |
| 参照のみ | AWS 側が管理するフィールド。担当者情報やステータスなど、パートナーが編集しても意味がない |
| 非表示 | パッケージ内部のフラグや数式フィールド。レイアウトに出す必要がない |
参照のみフィールドの扱い
参照のみにしたいフィールドは、AWS 担当者情報（営業担当者名やメールアドレスなど11件）、AWS 側が管理するステージやステータス情報（8件）、メタデータ（作成日・更新日など4件）です。ページレイアウトで「参照のみ」に設定しておけば、ユーザーが誤って編集することを防げます。
ACE ステージと社内ステージを分けた理由
設計判断として大きかったのが、ACE 用のステージ（ACE_Stage__c）と社内管理用のステージ（StageName）を別フィールドにしたことです。
ACE のステージは Prospect、Qualified、Technical Validation といった AWS の商談管理フローに合わせた値です。一方で、社内の商談管理では独自のフェーズ定義で管理したいケースがあります。両者を同じフィールドにしてしまうと、AWS からの Refresh で社内ステージが上書きされてしまいます。フィールドが増えるデメリットはありますが、運用の安全性を取りました。
フィールドの日本語化
AWS Partner CRM Connector のカスタムオブジェクトに含まれるフィールドは、ラベルも説明もピックリスト値もすべて英語です。社内の営業担当者が使うことを考えると、日本語化は必須でした。
日本語化の対象は4項目です。
| 項目 | XML タグ | 例 |
|---|---|---|
| フィールドラベル | |
Status → ステータス |
| 説明 | |
The status of… → ステータスを… |
| ヘルプテキスト | |
Select the… → 現在の… |
| ピックリスト値のラベル | |
Draft → 下書き |
Salesforce CLI でカスタムオブジェクトのメタデータを取得すると、フィールドごとに .field-meta.xml というファイルが生成されます。この XML を編集して日本語に書き換え、標準 Opportunity 用にフィールド名のプレフィックスを awsapn__ から ACE_ に変更してデプロイしました。
地味にハマったのが国名のピックリストです。ACE_Country__c フィールドには250以上の国名が含まれていて、Great Britain と United Kingdom の両方を「イギリス」に翻訳してしまい、ラベル重複のデプロイエラーが出ました。Great Britain は「グレートブリテン」に修正しています。
V14.3 仕様との突き合わせ
AWS Partner CRM Connector のフィールドマッピングには、AWS Partner Central API の仕様に準拠したバージョンがあります。今回は V14.3 の仕様書と現行のマッピングを突き合わせました。仕様書は GitHub で公開されています。
- フィールド定義（CSV）: https://github.com/aws-samples/partner-crm-integration-samples/blob/main/opportunity-samples/Opportunity-Fields.csv
- V14.3 差分（Excel）: https://github.com/aws-samples/partner-crm-integration-samples/blob/main/opportunity-samples/Opportunity-FieldsAndStandardValues-DiffWithPrevVersion-V14.3.xlsx
100件のマッピングを1件ずつ照合した結果、以下のような差分が見つかりました。
| 種別 | 件数 | 対応 |
|---|---|---|
| V14.3 で非推奨（Deprecated）になったフィールド | 11件 | レイアウトから非表示へ移動 |
| マッピングにあるが V14.3 にないフィールド | 4件 | パッケージ内部で使用されているものは残す |
以下、それぞれの差分の詳細です。
V14.3 で非推奨になったフィールド（11件）
| JSON 名 | SF フィールド |
|---|---|
awsFieldEngagement |
ACE_AWS_Field_Engagement__c |
contractVehicle |
ACE_Contract_Vehicle__c |
isThisAPublicReference |
ACE_Is_This_A_Public_Reference__c |
isThisForMarketplace |
ACE_Is_This_For_Marketplace__c |
isNetNewBusinessForCompany |
ACE_Is_Net_New_Business_For_Company__c |
leadSource |
ACE_Lead_Source__c |
publicReferenceTitle |
ACE_Public_Reference_Title__c |
publicReferenceUrl |
ACE_Public_Reference_Url__c |
rfxSolicitationNumber |
ACE_RFX_Solicitation_Number__c |
subUseCase |
ACE_Sub_Use_Case__c |
partnerPrimaryNeedFromAwsOther |
ACE_Partner_Primary_Need_From_AWS_Other__c |
これらは ACE Opportunity のカスタムオブジェクトにはフィールドが存在しますが、V14.3 では非推奨です。レイアウトから非表示にしましたが、マッピング自体は残しています。
マッピングにあるが V14.3 にないフィールド（4件）
| JSON 名 | SF フィールド | 理由 |
|---|---|---|
involvementType |
ACE_Involvement_Type__c |
V14.3 に未記載だが提出時に必須 |
visibility |
ACE_Visibility__c |
同上 |
hasUpdatesForAws |
ACE_Has_Updates_for_AWS__c |
パッケージ内部フラグ |
syncWithAws |
ACE_Sync_with_AWS__c |
パッケージ内部フラグ |
involvementType と visibility は V14.3 の仕様書には載っていませんが、実際の提出時に必須です。削除すると送信できなくなるので注意してください。パッケージ内部フラグ2件はそのまま残しています。
この突き合わせ作業は Claude Code にやってもらいました。V14.3 の仕様書をダウンロードして現行マッピングと diff を取る、という作業が数分で終わったのはかなり助かりました。
ピックリスト値マッピングの設定
フィールドの日本語化とは別に、Field Mapping Detail のピックリスト値マッピングも設定が必要です。
AWS Partner CRM Connector は Salesforce 側の値と AWS 側の値を Field Mapping Detail で紐づけるので、日本語のピックリスト値を使う場合はこの紐づけを全件設定する必要があります。今回の環境では819件の Detail レコードがありました。
819件を手で登録するのは現実的ではないので、Claude Code に sf data create recordコマンドを1件ずつ生成・実行させました。
おわりに
今回は、Field Mapping の仕組み、フィールド追加と日本語化、分類設計、V14.3 仕様との突き合わせ、ピックリスト値マッピングについて書きました。一番時間がかかったのは V14.3 仕様書との突き合わせで見つかった差分への対応で、ここは仕様を理解しながら1件ずつ判断していく必要がありました。
次回はハマりどころ編として、em dash とハイフンの文字コード不一致やビジネスバリデーションエラーなど、実際に踏んだ地雷の数々を紹介します。
岩間（@iwn_gnbr）でした。
- Salesforce × AWS Partner Central を AWS Partner CRM Connector でつないでオポチュニティ登録を自動化した話【フィールド設計編】 - 2026-03-20
- Salesforce × AWS Partner Central を AWS Partner CRM Connector でつないでオポチュニティ登録を自動化した話【セットアップ編】 - 2026-03-20
- Salesforce × AWS Partner Central を AWS Partner CRM Connector でつないでオポチュニティ登録を自動化した話【導入編】 - 2026-03-20
- Amazon Connect の MESSAGE_STREAMING でAmazon Lex ボット統合のタイムアウト問題が解決した話 - 2026-01-27
- Amazon Kendra Salesforce Connector V2でハマったポイント - 2025-12-23
【採用情報】一緒に働く仲間を募集しています
