Content

Content は Content Type（型）から作り出された実際のデータ 1 件です。アパレル系のショッピングモールを例にすると、Content Type「商品」が商品名・価格・詳細説明といった項目構成を定義し、「ステンレスタンブラー 500ml」1 件がその型に従う Content 1 件になります。

Content は 2 つの部分で構成されます。fields には各フィールドの実際の値が入り、sys には公開・バージョン・アーカイブといった状態が入ります。CMA において Content は Space の下位リソースであり、照会・削除のパスは /spaces/{spaceId}/contents を、作成・更新のパスは Content Type の下位である /spaces/{spaceId}/content-types/{contentTypeId}/contents を基準とします。管理操作は CMA で行い、公開されたスナップショットは CDA で配信されます。

リソース構造

以下は公開された Content「ステンレスタンブラー 500ml」の単一照会レスポンスです。sys（システムプロパティ）とともに fields（フィールド値）と metadata（タグなどの付加情報）を持ちます。

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 1,
      "at": "2026-06-18T09:51:44.128Z",
      "firstAt": "2026-06-18T09:51:44.128Z",
      "counter": 1,
      "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
    },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T09:51:14.597Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T09:51:44.128Z",
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "price": { "en-US": 18000 },
    "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

主なキー:

• sys.id: Content の一意な識別子です。単一照会・更新・削除・公開パスの {contentId} に入ります。
• sys.contentType: この Content が従う Content Type を指す Refer です。
• fields: 各フィールドの値です。キーはフィールドの apiName であり、値はロケールごとのマップです。以下の フィールドキーは apiName である で説明します。
• metadata.tags: この Content に付けた Tag の一覧です。各項目は Refer<Tag> の形であり、タグがない場合は空の配列 [] です。

フィールドキーは apiName である

fields オブジェクトのキーは各フィールドの apiName です。Content Type の内部 id やコンテンツスタジオに表示されるフィールド名（例: 商品名）ではありません。したがって Content を作成または読み取る際は、Content Type に定義された apiName をキーとして使う必要があります。

デモ用「商品」Content Type のフィールドとその apiName のマッピングは以下のとおりです。

各フィールドの値はロケールごとのマップです。値の形は localized によって異なります。

• localized: true のフィールドは { "<locale>": 値 } の形で複数のロケール値を持てます。例: "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }。
• localized: false のフィールド（非依存フィールド）は Space のデフォルト Locale キー 1 つにのみ値を入れます。他のロケールキーは入れられません。デモ用 Space のデフォルト Locale が en-US であるため、価格は "price": { "en-US": 18000 } のように en-US キー 1 つだけを持ちます。

デフォルト Locale が何か、required フィールドをどのロケールまで埋める必要があるか、値がない場合の fallback ルールは 多言語対応（概念） で扱います。

タイプ別の値の形

ロケールキーの中に入る値の形は、フィールドの type に従います。ほとんどのタイプはそのタイプの値をそのまま入れます（テキストタイプは文字列、Number・Long は数値、Boolean は true/false）。形がオブジェクトや配列であるため混同しやすいタイプは次のとおりです。

• Location: { "latitude": <数値>, "longitude": <数値> } オブジェクトです。latitude は -90 以上 90 以下、longitude は -180 以上 180 以下であり、両方のキーが必須です。定義されたキー以外は受け付けないため、lat・lng・lon のような省略キーを使うと拒否されます。
• Refer: 対象を指す Refer オブジェクトであり、id 文字列だけを入れるのではなく sys オブジェクトをそのまま入れます。別の Content を指す場合は targetType が Content、Media を指す場合は Media です。Refer の形自体は システムプロパティ (sys) の Refer の形 で定義します。
• Array: 要素タイプの値を収めた JSON 配列です。要素がテキストなら文字列の配列であり、要素が Refer（Content または Media）なら Refer オブジェクトの配列です。id 文字列の配列ではありません。

以下は fields の中に入る値の例です（Space のデフォルト Locale が en-US の場合）。

{
  "location": { "en-US": { "latitude": 37.5662, "longitude": 126.9910 } },
  "tags": { "en-US": ["新着", "限定版"] },
  "photo": { "en-US": { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } },
  "photos": { "en-US": [ { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } ] }
}

システムプロパティ (sys)

すべての Content は共通のシステムプロパティを sys オブジェクトに格納します。space、contentType、createdBy、updatedBy は Refer の形（{ "sys": { "id", "type": "Refer", "targetType" } }）で入ります。

status は次の 4 つのうちの 1 つです。

publish オブジェクトは公開状態を指すポインタです。公開中は次のキーをすべて持ちます。

公開を取り消すと publish から version・at・by が外れ、firstAt・counter だけが残ります。一度も公開したことがなければ publish は { "counter": 0 } です。

archive オブジェクトはアーカイブ中のみ存在します。アーカイブ中であれば version（アーカイブ時点の sys.version）・at（アーカイブ時刻）・by（アーカイブしたユーザー）を持ち、アーカイブ状態でなければ archive キー自体がありません。

以下の例の sys.version とすべての時刻値は実際の呼び出し時点の値であり、呼び出しごとに異なります。

公開とバージョン、同時実行

Content のライフサイクルは次のとおりです。

• 作成すると status は Draft です。Content は作成時に自動で公開されません。 この点が Content Type と異なります。Content Type は作成と同時に自動公開されますが、Content は別途の公開呼び出しがあって初めて配信経路に乗ります。
• 公開すると status が Published になります。
• 公開した後に更新すると status が Changed になります。未公開の変更分があるという意味です。
• 公開を取り消すと status が再び Draft になります。
• アーカイブするには 先に公開を取り消す必要があります。 公開状態の Content はそのままアーカイブできません。

sys.version は変更ごとに 1 ずつ増えます。

更新・部分更新・公開・公開取り消し・アーカイブ・アーカイブ解除のリクエストには、x-weegloo-version ヘッダーに現在の sys.version を載せる必要があります。この値が抜けたり現在のバージョンと食い違ったりすると、同時更新の競合とみなされてリクエストが拒否されます。作成と削除のリクエストにはこのヘッダーはありません。公開・公開取り消し・アーカイブ・アーカイブ解除のような状態遷移には別途のリクエストボディはありません。

API

以下のすべてのエンドポイントの基準 URL は https://cma.weegloo.com/v1 であり、Authorization ヘッダーに CMA を認証する Bearer トークンが必要です。更新・部分更新・公開・公開取り消し・アーカイブ・アーカイブ解除は、楽観的同時実行制御のために X-Weegloo-Version ヘッダー（現在のリソースの sys.version）も合わせて送る必要があります。

/contents リスト(GET /spaces/{spaceId}/contents)を fields.* でフィルターまたはソートするときは、sys.contentType.sys.id={contentTypeId} で Content Type も合わせて指定する必要があります。contentType={contentTypeId} の形では代用できません。/content-types/{contentTypeId}/contents は Content Type がパスに明示されているため、別途指定する必要はありません。

関連ドキュメント

• Content Type: この Content の型（フィールド定義・apiName）。
• CDA Content: 公開された Content を訪問者に配信（読み取り）。
• Tag: metadata.tags に付ける分類ラベル。
• 多言語対応（概念）: デフォルト Locale・必須入力・fallback。