platform-data-and-tooling-api-context-get

Salesforce Data + Tooling API スキル

このスキルでは、2 つのランタイム API サーフェスにまたがる 2130 個の標準 Salesforce オブジェクトについて、フィールドレベルのリファレンスを提供します。対象は、SOQL でクエリを実行し、DML で変更する標準 sObject の Enterprise/Data API と、ApexClass、ApexCodeCoverage、TraceFlag、EntityDefinition などの開発者向け／メタデータに関連するレコードを扱う Tooling API です。

SOQL／SOSL の作成、DML の構築、またはランタイムでのレコードの読み取りを行う前に、信頼できるフィールド名、型、プロパティを確認するために使用してください。これにより、クエリや書き込みで INVALID_FIELD／「No such column」エラーが発生するのを防げます。

標準オブジェクトのみが対象です。 これらのアセットには、標準 sObject と Tooling レコードが含まれます。カスタム __c オブジェクトや、標準 オブジェクト上のカスタム __c フィールドは、このコーパスには 含まれていません。静的なドキュメントページとしては存在しません。 これらについては、代わりにライブ組織を記述してください（sf sobject describe --sobject <Name>）。

概要

各オブジェクトは JSON ファイルとして記載されており、以下が含まれます。

• フィールド定義：名前、型、プロパティ（Createable、Filterable、Groupable、Nillable、Sortable、Updateable）
• Enterprise sObject のリレーションシップメタデータ（リレーションシップ名、参照先オブジェクト、リレーションシップの種類）
• Tooling レコードでサポートされる SOAP 呼び出しおよび REST HTTP メソッド
• WSDL スキーマのセグメント
• 使用上の注意と関連オブジェクト（Enterprise sObject）

このスキルはランタイムデータ用であり、デプロイ用ではありません。 *-meta.xml ソースファイル（CustomObject、Flow、Profile など）を作成する場合は、 Metadata API スキル（platform-metadata-api-context-get）を使用してください。この 2 つは相互に補完するものであり、代替ではありません。

このスキルの使い方

重要：フィールド存在確認ゲート（回答する前に実行してください）

「フィールド X は存在しますか？」「X はフィルター可能／ソート可能／グループ化可能ですか？」「X の API 名／型は何ですか？」といったフィールドに関する質問には、記憶や学習データに基づいて絶対に回答しないでください。 これには Id、Name、CreatedDate、LastModifiedDate、OwnerId、IsDeleted などの明白なシステムフィールドも含まれます。必ず最初に検索を実行してください。 これらのフィールドについて学習済みであっても、このスキルが存在するのは、フィールドのプロパティ（Filter／Sort／Group）や、どのカタログに記載されているかについての記憶が信頼できないからです。確信があっても、検証したことにはなりません。

両方のカタログを一度に確認する単一のアトミックなコマンドを実行してください（フィールドは fields にある場合、field_reference にある場合、どちらにもない場合があります。以下の二重カタログに関する注意を参照してください）。

jq '{fields: .fields["<FieldName>"], field_reference: .field_reference["<FieldName>"]}' assets/enterprise_api/<Object>.json
# e.g. checking CreatedDate on Account:
jq '{fields: .fields["CreatedDate"], field_reference: .field_reference["CreatedDate"]}' assets/enterprise_api/Account.json

結果の解釈：fields で見つかった場合は、機能に関する回答にその properties を使用してください。field_reference でのみ見つかった場合は、そのフィールドは存在しますが、このカタログにはプロパティフラグがないため、Filter／Sort／Group を判断できません。両方で null の場合は、このコーパスには含まれていません（実際のライブ組織やカスタムフィールドには存在する可能性があります。その場合は組織を記述してください）。

必須の検証ゲート。 フィールドに関する事実を述べる前に、メタデータスキルのステータス行のように、ユーザーへの返信に次の行を一字一句そのまま最初に出力する必要があります。

field_lookup: object=<Object> field=<FieldName> checked_fields=<yes|no> checked_field_reference=<yes|no> result=<in_fields|in_field_reference|not_found>

両方の確認結果が yes の状態でこの行を正直に出力できない場合、検索を実行していません。そこで止めて jq コマンドを実行してください。実行していないのに「スキルのデータに基づいています」などの出典を捏造してはいけません。

このゲート行は、会話での回答のみを対象とする自己検証マーカーです。ユーザー向けに生成するファイル（.soql、.md、.json、クエリのコメントヘッダーなど）には書き込まないでください。納品物には、ユーザーが求めた回答／クエリだけを含め、field_lookup: 行は記載しないでください。

重要：セクションごとの読み込み

JSON ファイルは、必要な特定のセクションだけを必ず読み込んでください。ファイル全体を読み込まないでください。

assets/enterprise_api/*.json および assets/tooling_api/*.json ファイルでは、必要なセクションだけを抽出するため、必ず jq またはプログラムによる JSON 解析を使用してください。 これらのファイルを Read、cat、read_file で丸ごと読み込まないでください。冗長な wsdl_segment セクションと field_reference セクションが含まれており、Account などの大規模な sObject ではトークンの 60～80％が無駄になります。

各 JSON ファイルには複数のセクションが含まれています。ほとんどの用途で必要なのは 1～2 セクションだけです。

• クエリ／DML のフィールド一覧の場合：fields セクションだけを読み込みます
• リレーションシップのたどり方の場合：fields を読み込みます（relationship_name／refers_to 列はその中にあります）
• Tooling の呼び出しサポートの場合：supported_soap_calls／supported_rest_api_http_methods を読み込みます
• 「このユーザーはクエリできるか？」などの権限に関する質問の場合：special_access_rules を読み込みます（オブジェクトのアクセス制限が記載されている場合、両方のサーフェスにあります）
• クエリの上限／サポートされない句の場合（レコード上限、ORDER BY／queryMore()／OFFSET が使えない場合）：limitations を読み込みます。このセクションがあるのは、制限を課しているオブジェクトのみです
• デフォルトでは読み込み不要：wsdl_segment、ispersonaccount_fields

二重カタログのルール（必須 — ここを間違える人が多いため注意してください）：

1. フィールドは fields に含まれる場合、field_reference に含まれる場合、両方に含まれる場合、またはどちらにも含まれない場合があります。この 2 つは異なるカタログであり、片方がもう片方を包含する関係ではありません。
2. fields に見つからなくても、「そのフィールドは存在しない」という答えにはなりません。 何かを結論づける前に field_reference も確認してください。上記の jq コマンドで両方を一度に確認できます。
3. フィルタ／ソート／グループ化／作成／更新／Nillable のプロパティは、fields からのみ取得できます。field_reference にのみ見つかったフィールドには、ここで取得できる機能フラグがありません。その旨を伝え、推測しないでください。

2 つのカタログが異なる理由（参考 — 任意）

fields は Salesforce の SOAP「Fields」テーブル（クエリ／DML プロパティ： Create／Filter／Sort／Group／Update／Nillable）に由来します。field_reference は、 一部のオブジェクトで SOAP テーブルとは別に記載されている、UI 向けの別の「Field List」 テーブル（ラベル／長さ／精度／スケール）に由来し、fields にはまったく記載されない フィールドが多数含まれることもあります（例：ブール型フラグの一覧が非常に多いオブジェクトや、 SOAP テーブルから省かれている管理者向けのさまざまなフィールド）。全データを通じて、 field_reference にのみ存在するフィールドは数千件あり、fields にのみ存在するフィールドも 少数あります。これが、フィールドの存在を確認するには両方を調べる必要があり、機能に関する 質問には fields の情報だけで回答できる理由です。

どのフォルダーを使う？

• 標準 sObject のうち、実行時にクエリや変更を行うもの（Account、Contact、Opportunity、Lead、Case など）→ assets/enterprise_api/
• 開発者向け／診断用レコード（ApexClass、ApexCodeCoverageAggregate、TraceFlag、EntityDefinition、MetadataComponentDependency、SymbolTable）→ assets/tooling_api/
• カスタム __c オブジェクトおよびカスタム __c フィールド → これらのアセットにはありません。稼働中の組織を記述します：sf sobject describe --sobject <Name> --target-org <alias>。（標準 Account 上の Region__c のようなカスタムフィールドも、assets/enterprise_api/Account.json には含まれません。）

クエリの例（セクションごとに読み込む）

適切な例：

• 「assets/enterprise_api/Account.json から「fields」セクションだけを表示してください」
• 「Opportunity のフィルタ可能なフィールドは何ですか？」
• 「Contact のどのフィールドがリレーションシップで、何を参照していますか？」
• 「Tooling API で ApexClass がサポートする SOAP 呼び出しは何ですか？」
• 「フィールド X が fields にありません。存在しないと言う前に field_reference を確認してください」

避ける例：

• 「Account.json を読み込んでください」（巨大な wsdl_segment も読み込まれます。ファイル全体ではなく、fields と field_reference を個別に読み込んでください）

JSON ファイルの構造

Enterprise（データ）sObject は assets/enterprise_api/ に、Tooling レコードは assets/tooling_api/ にあります。どちらも共通の基本構造を持ち、いくつかのセクションは表面ごとに異なります。

{
  "sections": ["title", "description", "fields", "wsdl_segment", ...],
  "title": "Account | Enterprise API",
  "description": "Plain-text description of the object.",
  "fields_columns": ["type", "properties", "description", "relationship_name", "refers_to", "relationship_type"],
  "fields": {
    "fieldName": {
      "type": "string | reference | picklist | ...",
      "properties": "Create, Filter, Group, Nillable, Sort, Update",
      "description": "Field description",
      "relationship_name": "(reference fields only)",
      "refers_to": "(reference fields only) e.g. Account"
    }
  },
  "wsdl_segment": "<xsd:complexType>...</xsd:complexType>"
}

fields はフィールドの API 名をキーとする辞書（例：fields["AnnualRevenue"]）であり、リストではありません。.items()／.keys() を使って反復処理し、位置を指定してインデックス参照しないでください。

セクションの導出方法（セクション一覧を想定する前にお読みください）

各 JSON ファイルは、そのオブジェクトの Salesforce ドキュメントページに実際に記載されている ## 見出し から生成されます。JSON スキーマは、すべてのオブジェクトに同じように適用される固定の統一テンプレートではありません。このことから、次の 2 点がわかります。

1. fields を含め、すべてのオブジェクトに存在することが保証されたセクションはありません。 ファイル内にセクションが存在するのは、ソースのドキュメントページに対応する見出しがあった場合だけです。Tooling のドキュメントページにはフィールドテーブルがないもの（内容が少ないページやベータ版のページ）があり、その場合は fields が存在しないことがあります。また、SOAP ヘッダー形式のページの一部では、フィールドテーブルの見出しが複数形ではなく単数形の field になっています。セクションが存在すると想定する前に、必ずそのファイル自身の sections 配列（または "fields" in sections）を確認してください。1、2 個のオブジェクトを見ただけで、存在を決めつけてハードコードしないでください。
2. ページには共通セクション以外のセクションが追加されることがあります。 Salesforce のドキュメントでそのページに固有の追加 ## 見出しがある場合は、それぞれに対応するセクションが追加されます（例：項目から参照される入れ子の複合型。選択リストの値メタデータの説明やレコードタイプ情報のブロックなど）。これらは snake_case のキーに正規化され、独立したトップレベルのセクションとして格納されるか、見出しが通常のコンテンツセクションではなく独立したサブタイプとして認識される場合は、サブタイプ名をキーとする sub_types 辞書の下に格納されます。以下の「利用可能なセクション」の一覧は、共通または頻出のケースであり、網羅的な列挙ではありません。各オブジェクトの正式な一覧は、そのオブジェクト自身の sections 配列で確認してください。

利用可能なセクション（一般的なケース。網羅的ではありません。上記を参照）

• title、description、fields_columns：ほぼすべてのオブジェクトに存在します
• fields：大多数のオブジェクトに存在しますが、上記のポイント 1 を参照してください。存在を決めつけず、sections で確認してください
• Enterprise のみ：usage、associated_objects、ispersonaccount_fields、field_reference、field_reference_columns
• Tooling のみ：supported_soap_calls、supported_rest_api_http_methods
• special_access_rules：誰がそのオブジェクトをクエリ／アクセスできるか、および必要な権限やライセンスの条件（例：「Customer Portal ユーザーはこのオブジェクトにアクセスできない」、「Omnistudio ライセンスが必要」）。どちらの表面にも存在します。特定のユーザーがクエリを実行できると判断する前に確認してください。これは、フィールドのフラグからはわからないクエリ実行可否の情報です。
• limitations：オブジェクトに設定されたクエリの上限と、サポートされていない SOQL 句（例：MetadataComponentDependency：Tooling API 経由では最大 2000 件、Bulk API 2.0 経由では 100,000 件。ORDER BY、OFFSET、queryMore()、および *Name フィールドによるフィルターはサポートされません）。このセクションがあるオブジェクトに対してクエリを書く前に確認してください。こうした制約は fields のプロパティからは導き出せません。
• wsdl_segment：スキーマ定義（詳細なため、生の型が必要な場合を除き読み飛ばしてください）
• sub_types および上記にないその他の snake_case 名のセクション：オブジェクト固有の入れ子になったスキーマの説明。そのオブジェクトのドキュメントページに対応する見出しがある場合にのみ存在します。各オブジェクトの sections 配列を調べて確認してください fields_columns 配列は、各オブジェクトの fields エントリがどのカラムを持つかを示します。固定の形を想定せず、オブジェクトごとに確認してください。エンタープライズの sObject は通常 relationship_name、refers_to、relationship_type を追加します。Tooling のレコードは通常 type、properties、description のみを持ちますが、意味のある少数の Tooling オブジェクトは relationship_type も持つため、これをエンタープライズ専用として扱わないでください。relationship_type の値にはソースデータ内で綴りの異形もあります（例: "Lookup" と "Look up"）。厳密な文字列一致ではなく、緩やかに比較してください（例: .replace(" ", "").lower()）。

型文字列はオブジェクト間で大文字小文字が一貫していません。単一のケーシングを想定しないでください。 同じ概念が、ソースのドキュメントページによって複数の表記で現れます: string/String、boolean/Boolean、dateTime/DateTime/datetime。type の値は、ある 1 つのケーシングに対して == で比較するのではなく、大文字小文字を区別せずに比較してください（例: .lower()）。一般的な string | reference | picklist 型に加えて、実データには int、boolean、double、currency、date、dateTime、textarea、address、url、phone、email、time、anyType、base64 なども含まれます。型のリストは開かれたものとして扱ってください。

オブジェクトが構造化された type/properties を持っていても、フィールドがそれらを欠くことがあります。データが欠けていると結論づける前に、フォールバックとして description を確認してください。 各オブジェクトの JSON はそのオブジェクト自身のドキュメントページから生成されるため、フィールドの型/プロパティを別々のテーブルカラムではなく、1 つの説明段落内の散文（"Type: ... Properties: ... Description: ..."）として提示しているページでは、type/properties が空でその散文が description に押し込まれた fields エントリが生成されます。これはさまざまな理由で発生し（多くの標準オブジェクト、例えば history/share/feed-tracking のコンパニオンオブジェクトで再利用される汎用テンプレートページなど）、オブジェクトの 1 つのフィールドからすべてのフィールドまで影響し得ます。最悪の場合、fields_columns 自体が ["description"] しか示さないこともあります。type/properties が空であるか、fields_columns が不自然に少ない場合は、フィールド/オブジェクトに型情報がないと結論づける前に、description が "Type: " で始まっていないかを確認し、フォールバックとして解析してください。

Picklist の許可値は description の散文に現れることがあります。存在しないと想定する前に確認してください。 構造化された picklistValues リストを持つ fields エントリはありません。picklist の許可値が description に列挙されているかどうか（"Possible values are: ..." の後に値が続く形）は、ソースのドキュメントページがその特定のフィールドについてそれらを列挙しているかどうかに完全に依存します。列挙しているものもあれば、していないものも多くあります（例えば、別の値セットオブジェクトに支えられた組織設定可能な picklist は、通常、完全なリストではなく「such as New, Closed, or Escalated」のような例示のみを提示します）。存在する場合、その形式自体も一貫していません。あるときは空白/カンマ区切りのトークン、あるときは行ごとの Value—explanation の em ダッシュペアです。したがって、単一の信頼できる正規表現はありません。"Possible values are:" の後の部分文字列を抽出し、ケースバイケースで解析してください。また、すべての picklist がここで発見可能な値セットを持つと想定しないでください。 フィールドの description には、関係性（例：「これは従属選択リストです」「このフィールドは X を制御します」）への言及があっても、関係の相手側の名前や解決方法が記載されていない場合があります。その答えが、エンタープライズ sObject の fields セクションにあるとは限りません。 このデータセットの Tooling API 側には、Salesforce のフィールドメタデータオブジェクト（スキーマについて記述するスキーマ。例：フィールドごとの describe 形式の属性を公開するオブジェクト）が記載されています。これらのオブジェクトには、従属選択リストの制御フィールドの識別情報など、エンタープライズ sObject のドキュメントページに明示されていない構造化属性が含まれる場合があります。エンタープライズフィールドの説明が、解決方法のわからない関係性を示している場合、このスキルのどこにもデータが存在しないと結論付ける前に、Tooling 側のフィールドメタデータオブジェクトで答えが得られないか確認してください。

オブジェクトの JSON には、上記の一般的なリスト以外のセクションが含まれる場合があります。決められた一覧があると思い込まず、そのオブジェクト独自の sections 配列を確認してください。 元のドキュメントページにある追加の ## 見出しはそれぞれ、独立した snake_case 名のセクションになります（コンバーターが独立したネスト型として認識する場合は、sub_types エントリになります）。これらは、該当する見出しがドキュメントに含まれていた特定のオブジェクトにのみ現れます。無視すべき不要なデータではなく、オブジェクトごとのスキーマ記述ペイロードです。考えられる追加セクション名をすべて網羅した固定リストはありません。sections を使ってオブジェクトごとに確認してください。

すべてのオブジェクトとオブジェクトごとの追加セクションの一覧については、インデックステーブルを参照してください。約 125 KB あるため、ファイル全体を読むのではなく、個々の項目を調べるには grep -i "<ObjectName>" を実行してください。

詳細： 実際のクエリ／DML の例、関係のたどり方のパターン、およびセクションの用語集全体は、references/usage_guide.mdにあります。必要な場合のみ、Read ツールで読み込んでください。

ファイルの場所

オブジェクトの JSON ファイルは、API サーフェスごとに分かれています。

assets/
├── enterprise_api/      # standard sObjects (SOQL/DML)
│   ├── Account.json
│   ├── Contact.json
│   └── ...
└── tooling_api/         # developer / diagnostics records
    ├── ApexClass.json
    ├── TraceFlag.json
    └── ...

ファイルはスキルのルートからの相対パスで参照します。例：assets/enterprise_api/Account.json または assets/tooling_api/ApexClass.json。

動作する例

実行可能なセクション読み込みの例（各例では、フィールドの抽出、properties を使ったフィルター可能フィールドの検索、関係のたどり方、fields と field_reference の二重カタログ、および Tooling の supported_rest_api_http_methods の読み込みを紹介しています）：

• Python: examples/python_section_loading.py — セクションを抽出する json.load()
• JavaScript/Node.js: examples/javascript_section_loading.js — セクションを抽出する JSON.parse()
• Bash + jq: examples/bash_section_loading.sh — jq によるコマンドラインでの JSON 処理

使用方法と、property と SOQL／DML の機能の対応表については、examples/README.mdを参照してください。

クエリと DML の生成要件

これらのオブジェクトに対して SOQL／SOSL または DML を生成する場合は、ステートメントが実際に実行されるよう、以下のルールに従ってください。

項目が存在することとその API 名を確認する

1. まず項目を検索し（両方のカタログ、アトミックな jq）、 field_lookup: ゲート行を出力してください — 確実だと思っているシステム項目であっても同様です。 「このスキルの使い方」の冒頭にある項目存在ゲートを参照してください。項目の API 名は Salesforce では大文字と小文字が区別されませんが、実在する項目に解決される必要があります。カスタム項目は __c で終わります。カスタムリレーションは __r で辿ります。
2. 項目をでっち上げないでください。 推測した列は INVALID_FIELD: No such column 'X' on entity 'Y' を引き起こします。不明な場合は fields セクションを読み込み、確認してください。
3. 照合時に fields のキーの大文字と小文字を区別しないようにしないでください。 少なくとも 1 つのオブジェクト （LoginEventLog）には、同じ fields 辞書の中に UserName と Username が 別個の実在する項目として存在します — 小文字/大文字と小文字を区別しない検索では、これらが 黙って衝突してしまいます。指定されたとおり、正確なキーの大文字と小文字で照合してください。これらは 異なるデータを保持する可能性のある 2 つの異なる列 です — それらは 「プラットフォームが選んだ方に解決される」同じ項目では ありません。それぞれを正確な 大文字と小文字で選択し、フィルタリングしてください。それらを互換可能なものとして説明したり、クエリが 「曖昧に解決される」と言ったりしないでください。プラットフォームはそれらを別個の項目として扱います。

項目のプロパティを尊重する

各項目の properties 文字列は、それを使って何ができるかを制御します:

• Filter → WHERE 句で使用できます。Filter のない項目はフィルタリングできません。
• Sort → ORDER BY で使用できます。
• Group → GROUP BY で使用できます。
• Createable / Updateable → insert / update DML で設定できます。システム項目と 数式項目は読み取り専用です（Create/Update なし） — それらへの書き込みは失敗します。
• Nillable → null になる可能性があります。nillable でない項目は insert 時に必須です。

このスキルの properties 文字列には External ID フラグがありません — upsert には 組織で External ID としてマークされた項目が必要ですが、そのフラグはこのデータ ソースでは取得されません（Metadata API の describe 出力にのみ現れ、この スキルの基になっている HTML ドキュメントには含まれません）。項目の External ID フラグを検索または設定するには、 Metadata API スキル（platform-metadata-api-context-get）を使用し、 CustomField の externalId 属性を確認してください — このスキルの プロパティだけから upsert 項目を推測しないでください。

リレーション（エンタープライズ sObject）

reference 型の項目では、relationship_name 列が SOQL トラバーサル用の親 リレーションを示し、refers_to がターゲットオブジェクトを指定します:

-- OwnerId (reference, relationship_name = Owner, refers_to = User)
SELECT Id, Owner.Name FROM Account
-- Custom lookup Foo__c traverses as Foo__r
SELECT Id, Foo__r.Name FROM My_Object__c

Tooling API と Data API

Tooling レコード（assets/tooling_api/）は、通常の Data API ではなく、Tooling API エンドポイント（/services/data/vXX.0/tooling/query）を通じてクエリされます。各レコードが 何をサポートするかは supported_soap_calls / supported_rest_api_http_methods を確認してください。 多くの Tooling オブジェクトは読み取り専用です。

デプロイ用ではありません。 *-meta.xml ソース（CustomObject、 Flow、Profile など）を作成または編集するには、Metadata API スキルを使用してください — ここにあるオブジェクトは ランタイム/クエリ可能な表現であり、デプロイ可能なメタデータ形式ではありません。

重複および曖昧なオブジェクト名

Metadata API とここには、同じ名前のオブジェクトがいくつか存在します（ApexClass、ApexTrigger、 CustomField、CustomObject、EmailTemplate、Layout、Profile、PermissionSet、 RecordType、ValidationRule、Flow など）。ただし、意味は異なります。

• このスキル ＝ ランタイムでクエリ可能なレコードです。SELECT するフィールド、絞り込みに使うフィールド、および Data API または Tooling API を通じて（場合によっては）書き込むフィールドが該当します。
• Metadata API スキル ＝ 作成してデプロイする *-meta.xml のソース形式です。

次の手がかりを使って、どちらを指すか判断してください。

• 「query」、「SOQL」、「SOSL」、「DML」、「insert/update/upsert」、「what fields/columns」、 「filterable」、「record」、「runtime」、「REST/SOAP」→ このスキル。
• 「authoring」、「deploy」、「retrieve」、package.xml、force-app/、sfdx、 .meta.xml、「blueprint/template」→ Metadata API スキル。
• Tooling 固有：「Tooling API」、ApexCodeCoverage、EntityDefinition、 TraceFlag、SymbolTable、「code coverage」、「compile errors」、「debug log」→ このスキルの Tooling 部分（assets/tooling_api/）。

ほかの手がかりがなく、名前を直接指定して呼び出された場合は、ランタイムデータを指すものと解釈し、その前提を明示してください。

トラブルシューティング

ファイルが見つからない

• ファイル名はオブジェクトの API 名と一致する、大文字と小文字を区別する PascalCase 形式です （Account.json、ApexClass.json）。区切り文字はありません。
• 正しいフォルダーを確認してください。Enterprise sObject は assets/enterprise_api/、 Tooling レコードは assets/tooling_api/ にあります。名前が片方にしか存在しない場合や、 両方に異なるフィールドが存在する場合があります。
• 「見つからない」と判断する前に、コーパス内のすべてのオブジェクト名が一覧になったインデックス表を、約 125 KB のファイル全体を読むのではなく、対象を絞った grep で検索してください。 grep -i "<ObjectName>" references/data_and_tooling_index_table.md。大文字と小文字を区別せずに照合し、オブジェクトが存在しないと結論づける前に、表記の違い（空白、複数形、軽微なスペル違い）も考慮してください。全体像を把握する場合に限り、ファイル全体を読んでください。

INVALID_FIELD / 列が見つからない

• そのフィールドがオブジェクトに存在しないか、誤った API 名を使用しています。fields セクションを読み込み、正確な名前を確認してください（カスタムフィールド名の末尾は __c です）。
• フィールドが存在していても、必要なプロパティがない場合があります。Filter ではないフィールドでの絞り込み、Sort ではないフィールドでの並べ替え、読み取り専用フィールド（Create／Update なし）への書き込みは、いずれも失敗します。properties 文字列を確認してください。

リレーションクエリが失敗する

• 参照をたどるには、ID フィールドではなく relationship_name を使用してください。OwnerId.Name ではなく Owner.Name を指定します。カスタムルックアップでは __r を使ってたどります。
• refers_to を確認してください。多相フィールド（例：WhoId、WhatId）は複数のオブジェクトを参照するため、TYPEOF または適切なリレーションシップが必要です。

Tooling クエリが何も返さない／エラーになる

• Tooling オブジェクトは、標準の Data API ではなく Tooling API のエンドポイント （/tooling/query）に対してクエリする必要があります。supported_rest_api_http_methods／supported_soap_calls で確認してください。

フィールドが fields にはなく、wsdl_segment にある

• 複雑なネスト型では、そのサブフィールドが wsdl_segment にあります。セグメント全体を読み込むのではなく、該当する complexType だけを取得してください。 jq -r '.wsdl_segment' file.json | grep -A 30 'complexType name="Foo"'。

一般的なオブジェクト

Enterprise／Data API（SOQL + DML）

• Account：個人アカウントを表します。顧客、競合他社、パートナーなど、ビジネスに関わる組織または個人を指します。
• Contact：連絡先を表します。アカウントに関連付けられた人物です。
• Opportunity：商談を表します。販売案件または進行中の取引です。
• Lead：見込み客またはリードを表します。
• Case：ケースを表します。顧客の問題または課題です。
• User：組織内のユーザーを表します。
• Task：電話やその他の ToDo 項目など、ビジネス活動を表します。
• Event：カレンダー上のイベントを表します。

ツール API（開発者レコード）

• ApexClass：Apex クラスの保存済みコピーを表します。
• ApexTrigger：Apex トリガーの保存済みコピーを表します。
• ApexCodeCoverageAggregate：Apex クラスまたはトリガーのコードカバレッジテスト結果の集計を表します。
• TraceFlag：指定したログレベルで Apex デバッグログを生成するトレースフラグを表します。
• EntityDefinition：標準オブジェクトとカスタムオブジェクトのメタデータに行ベースでアクセスできます。