platform-custom-object-generate

このスキルを使用するタイミング

次の場合にこのスキルを使用してください。

• 新しいカスタムオブジェクトを作成する
• カスタムオブジェクトのメタデータ XML を生成する
• オブジェクトの共有設定とセキュリティ設定を行う
• オブジェクトの機能と能力を設定する
• カスタムオブジェクトに関連するデプロイエラーをトラブルシューティングする
• 既存のオブジェクトのフィールドまたは入力規則を追加、更新、削除する — いずれの場合もオブジェクトの <description> が古くなる可能性があるため、更新する必要があります（提案して確認を得てください）。入力規則の変更にもフィールドの変更と同様に適用されます。セクション 3.B を参照してください。

このスキルで扱う範囲を超える、Metadata API のタイプ、フィールド、列挙値に関する正式な情報については、platform-metadata-api-context-get スキルを使用してください。

仕様

1. 概要と目的

このドキュメントでは、カスタムオブジェクトのメタデータ XML（.object-meta.xml ファイル）を生成する際の必須制約を定義します。Metadata API のデプロイエラーを防ぐため、XML を出力する前にエージェントはこれらの制約を確認する必要があります。

ファイル拡張子： .object-meta.xml

説明の最新性 — フィールドと入力規則の両方を含む、すべてのオブジェクト変更に適用されます： オブジェクトのフィールドまたは入力規則を追加、更新、削除するたびに、<description> が古くなっている可能性があります。作業を終える前に、セクション 3.B に従って説明を更新してください（提案し、ユーザーの確認を得て、記述します）。入力規則の変更はフィールドの変更とまったく同じように扱われます。説明の整合性を取るまでは、変更は完了していません。入力規則の編集や削除では忘れやすいため、注意してください。

---

2. 構文上の必須事項（ティア 1）

XML 本文を正常にデプロイするには、次の制約を満たす必要があります。

注： API 名（fullName）はタグではなく、ファイル名です（例：Vehicle__c.object-meta.xml）。

必須要素

要素	要件	注記
<label>	必須	UI に表示する単数形の名前
<pluralLabel>	必須	UI に表示する複数形の名前
<sharingModel>	必須	以下の共有モデルのルールを参照
<deploymentStatus>	必須	常に Deployed に設定
<nameField>	必須	主レコード識別子（<label> と <type> が必要）
<visibility>	必須	常に Public に設定

共有モデルのルール

デフォルト： <sharingModel> を ReadWrite に設定します。

例外： このオブジェクトに主従関係項目が含まれる場合、<sharingModel> は必ず ControlledByParent にします。

判断ロジック：

• オブジェクトに主従関係項目がない場合 → ReadWrite を使用
• オブジェクトに主従関係項目がある場合 → ControlledByParent を使用
• 既存の子オブジェクトに主従関係項目を追加する場合 → 既存オブジェクトの <sharingModel> も ControlledByParent に更新する必要があります

誤り — 次のエラーが発生します：Cannot set sharingModel to ReadWrite on a CustomObject with a MasterDetail relationship field

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
  <label>Order Line Item</label>
  <pluralLabel>Order Line Items</pluralLabel>
  <sharingModel>ReadWrite</sharingModel>  
  <deploymentStatus>Deployed</deploymentStatus>
</CustomObject>

正しい例：

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
  <label>Order Line Item</label>
  <pluralLabel>Order Line Items</pluralLabel>
  <sharingModel>ControlledByParent</sharingModel>  
  <deploymentStatus>Deployed</deploymentStatus>
</CustomObject>

---

3. スマートデフォルトと判断ロジック（ティア 2）

オブジェクトの想定用途に基づいて、有効にする機能をエージェントが選択する必要があります。

A. 名前項目の選択

タイプ	使用する場面	追加要件
Text	人が名前を付けるエンティティ（プロジェクト、場所、チーム）のデフォルト	なし
AutoNumber	トランザクション、ログ、ID に使用（請求書、リクエスト、チケット）	<displayFormat>（例：INV-{0000}）と <startingNumber>1</startingNumber> を含める必要があります

テキスト名前項目の例：

<nameField>
  <label>Project Name</label>
  <type>Text</type>
</nameField>

自動採番名前項目の例：

<nameField>
  <label>Invoice Number</label>
  <type>AutoNumber</type>
  <displayFormat>INV-{0000}</displayFormat>
  <startingNumber>1</startingNumber>
</nameField>

B. オブジェクトの説明（充実化）

<description>：必須 — すべてのカスタムオブジェクトに設定する必要があります。人が書いたドキュメントのような文章にしてください。汎用的なテンプレート（「追跡および管理に使用するオブジェクト...」）や、メタデータの羅列（「Project_Name__c を含む8つのフィールド...」）にしてはいけません。

必ず説明を充実させてください — オブジェクトの作成時だけでなく、フィールドまたは入力規則の追加、更新、削除など、オブジェクトに変更を加えるたびに再度行います（説明が古くならないようにするためです）。フィールドまたは入力規則の変更は、オブジェクトの説明を更新するまで「完了」ではありません。これは任意ではありません。説明を追加するかどうかを尋ねてはいけません。

変更のたびに確認してください。 フィールドまたは入力規則の変更ごとに、個別に提案して確認を求めます。以前の「現状を維持する」という回答は、その変更だけに適用されます。後の変更で提案を省略する許可にはなりません。以前の回答からユーザーの意向を推測してはいけません。新しい変更のたびに、改めて提案し、確認を求めてください。

説明を作成します（以下の手順を参照）。オブジェクトにすでに説明がある場合は、そこに含まれるビジネス上の背景（ドメイン、チーム、スキーマからは読み取れない意図）を維持し、新しいフィールドまたは入力規則を組み込むための重要な手がかりとして扱ってください。内容を破棄してはいけません。

次に、説明がすでに存在するかどうかに応じて対応します。

• 既存の説明がない（新規オブジェクト）： 上書きするものはないため、作成した説明をそのまま記述します。確認を求めてはいけません。

• 既存の説明がある（更新、削除、または再度の充実化）： 黙って上書きしてはいけません。ファイルからは、管理者が手書きしたものか、以前に生成されたものか判断できません。提案を提示して確認を求め、停止してユーザーの返信を待ちます。

  {Object} の説明案： <充実化した説明> 現在の説明：<既存の説明> この内容を使用しますか？（はい／現状を維持／編集）

  ユーザーが返信するまで、<description> を書き込んではいけません。 差分を提示しただけでは承認されていません。変更が明白または軽微に見える場合も同様です。その後、回答に応じて対応します。はい → 提案した文章を書き込む · 現状を維持 → 既存の説明を変更しない（適用されるのは今回の変更だけです。次回は改めて提案してください） · 編集 → ユーザーの文言を使用します。

必ず最後に、記入済みの <description> を用意してください。

説明の作成方法：

1. 説明内での表現方法に従って、各フィールドを分類します。
   • 制約付き（必須、一意、externalId、制限付き選択リスト）→ 必要な属性のみを括弧書きにします。例：VIN（必須、外部 ID）、Color（Red/Green のみ）
   • 動作を持つもの（数式、ロールアップ）→ 計算内容を説明します。例：「Age Years フィールドは車両の年齢を自動計算します」
   • リレーションシップ（主従関係、参照関係）→ 文脈に織り込みます。例：「Account の子オブジェクトとして」（「（Account への主従関係）」とは書かないでください）
   • 標準 → ラベルのみを記載します。
2. 以下の順序で、フィールドのAPI 名ではなくラベルを使って説明を作成します。

   目的 → 主要なフィールド → 計算フィールド → 入力規則（ビジネスルールとして）→ 「一般的な用途は{ユースケース}です。」

3. 記述前に文字数を確認し、調整します（必須）： 単語数を数え、約45語を目安に、最大50語に収めます。超える場合は、まず表現を簡潔にし、それでも超える場合は、優先順位に従って文全体を削除します（ユースケース → 入力規則 → 計算フィールドの順。1～2文目は削除しないでください）。再度数えます。50語以下になるまで記述してはいけません。

例（Car、46語）：

<description>The Car object tracks vehicle inventory and maintenance. It captures Year, VIN (required, external ID), Color (Red/Green only), and Location; the Age Years field auto-calculates vehicle age. VIN is required and Black cars cannot be sold. Commonly used for fleet management, inventory tracking, and service scheduling.</description>

→ ワークフロー全体と例については、references/description-enrichment.md を参照してください。

C. ジャンクションオブジェクトの命名

オブジェクトが2つの親オブジェクト間の多対多リンクである場合は、スキーマが直感的に理解できるよう、2つの親エンティティを組み合わせた名前を付けます。

例：

• Position_Candidate__c（Position と Candidate をリンク）
• Job_Application__c（Job と Application をリンク）

D. 機能の有効化（クリーンな XML）

「クリーンな XML」を維持するため、Salesforce プラットフォームのデフォルトである false から変更する場合にのみ、オプションのタグを含めてください。

シナリオ A：ユーザー向けオブジェクト（アプリ、トラッカー、ビジネスエンティティ）

• トリガー：オブジェクトがユーザーの直接操作を想定している
• アクション：<enableSearch>、<enableReports>、<enableActivities>、<enableHistory> を true に設定します

シナリオ B：システム向けオブジェクト（中間オブジェクト、バックグラウンドログ）

• トリガー：オブジェクトが技術的な関連付けまたはバックグラウンドデータ用に存在する
• アクション：UI をすっきり保ち、XML を簡潔にするため、これらのタグを省略します

---

4. 重要な制約とよくある失敗

予約語

カスタムオブジェクトまたはカスタム項目の API 名に予約語を使用しないでください。

カテゴリ	予約語（API 名に使用しないでください）
SOQL/SQL	Select、From、Where、Limit、Order、Group
システム	User、External、View、Type
時間関連	Date、Number

リレーションの上限

1 つのオブジェクトに 2 つを超える主従関係を作成しないでください。3 つ目のリレーションが必要な場合は、参照関係を使用してください。

XML のルート要素

.object-meta.xml ファイルのルートに <fullName> タグを含めないでください。API 名はファイル名から導出されます。

誤り：

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
  <fullName>Vehicle__c</fullName>  
  <label>Vehicle</label>
</CustomObject>

正しい例：

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
  <label>Vehicle</label>
  
</CustomObject>

入力規則の命名規則

入力規則の名前には、カスタム項目とは異なる規則が適用されます。

規則：

• 英数字とアンダースコアのみを使用する必要があります
• 先頭は英字にする必要があります
• 末尾をアンダースコアにすることはできません
• アンダースコアを 2 つ連続させることはできません
• カスタム項目とは異なり、末尾を __c にしてはいけません

誤り：

<validationRules>
  <fullName>Require_Start_Date__c</fullName>  
  <active>true</active>
  <errorMessage>Start Date is required.</errorMessage>
  <formula>ISBLANK(Start_Date__c)</formula>
</validationRules>

エラー： The validation name can only contain alphanumeric characters, must begin with a letter, cannot end with an underscore...

正しい例：

<validationRules>
  <fullName>Require_Start_Date</fullName>  
  <active>true</active>
  <errorMessage>Start Date is required.</errorMessage>
  <formula>ISBLANK(Start_Date__c)</formula>
</validationRules>

命名パターンの参考：

メタデータ型	命名パターン	例
カスタム項目	__c で終わる	Start_Date__c
入力規則	接尾辞なし	Require_Start_Date
カスタムオブジェクト	__c で終わる	Vehicle__c

---

5. 検証チェックリスト

カスタムオブジェクトの XML を生成する前に、次の項目を確認してください。

構文チェック

• <label> と <pluralLabel> の両方が含まれていますか？
• <deploymentStatus> は Deployed に設定されていますか？
• <visibility> は Public に設定されていますか？
• <nameField> に <label> と <type> の両方が含まれていますか？
• <type> が AutoNumber の場合、<displayFormat> と <startingNumber> が含まれていますか？

共有モデルの確認（重要）

• このオブジェクトに主従関係項目はありますか？
  • はいの場合 → <sharingModel> は ControlledByParent にする必要があります
  • いいえの場合 → <sharingModel> は ReadWrite にする必要があります

制約の確認

• API 名に予約語が含まれていませんか？
• 主従関係は 2 つ以下ですか？
• XML のルートに <fullName> が含まれていませんか？

入力規則の確認（該当する場合）

• 入力規則名の末尾が __c になっていませんか？
• 入力規則名が英数字とアンダースコアのパターンに従っていますか？

説明の充実度に関する品質チェック

• 「The {Object} object...」で始まり、業務上の目的が記載されていますか（「Object used to track and manage...」ではありませんか）
• API 名ではなく項目のラベルを使用し、「Contains N fields including」のような羅列がありませんか
• 数式／集計項目は動作で説明し、入力規則は業務ルールとして示し、リレーションは文脈として説明していますか
• 一般的なユースケース（「Commonly used for...」）が含まれ、50 語未満ですか
• 現在の説明に含まれる業務上の背景を、提案する説明に組み込んでいますか（破棄していませんか）
• 既存の説明を変更・削除・再充実する場合、書き込み前に停止してユーザーの返信を待ちましたか（差分を表示しただけで承認とみなしていませんか）

アーキテクチャの確認

• <description> はありますか？（セクション B に従って内容を充実させ、記述する前にユーザーと確認します。）
• ユーザー向けの場合、<enableSearch> と <enableReports> は true に設定されていますか？
• ファイル名は想定される API 名と一致していますか？

---

参照ファイル一覧

ファイル	読むタイミング
references/description-enrichment.md	オブジェクトの <description> を作成または更新するとき（作成時、またはフィールド／ルールの変更時）。内容を充実させるための完全なワークフロー、フィールドの優先順位付けの段階、ジャンクション／子要素の扱い、エッジケース、その他の例が記載されています