---
title: "SitecoreAIビルド構成"
slug: "the-sitecoreai-build-configuration"
abstract: "SitecoreAIビルド設定ファイルの参考文献"
---
# SitecoreAIビルド構成

環境の[SitecoreAI](https://doc.sitecore.com/sai/en/users/sitecoreai/sitecoreai.html)ビルド構成はxmcloud.build.jsonファイル内で定義されています。このファイルには、ホスト編集、ビルドターゲット、その環境のXMインスタンスに展開するシリアライゼーションモジュールなどの設定が含まれています。

> !ヒント[PLAYを参照できます!](https://github.com/Sitecore/Sitecore.Demo.XmCloud.PlaySummit) [xmcloud.build.jsonファイルの](https://github.com/Sitecore/Sitecore.Demo.XmCloud.PlaySummit/blob/main/xmcloud.build.json)動作例はSummitプロジェクトリポジトリにあります。

> !注**XM Cloudは現在SitecoreAIです**。エンジニアリング資産が更新されている間、一部のコード例、画像、UIラベルはXM Cloudを使用している場合があります。

ビルド構成オブジェクトの構造は以下の通りです:

{
 "deployItems": {
 "modules": 
 },
 "buildTargets": ,
 "renderingHosts": {
 "<key>": <value>
 },
 "transforms": ,
 "postActions": {
 "actions": {
 "<key>": <value>
 }
 },
 "authoringPath": <value>
}

以下の表はビルド構成オブジェクトのプロパティを示しています:

名称

概要

deployItems

どのシリアライゼーションアイテムモジュールを展開するかを定義できます。これは sitecore.json ファイルで定義されたシリアライズ構成に似ています。ローカルで働く際に配置するものを制限するのに便利です。  
  
ここで定義されたすべてのモジュールは、Items as Resources(IAR)ファイルに変換されます。役割はサポートしていません。ロールをデプロイする必要がある場合は、 [SCSモジュールのデプロイメントアクション](https://doc.sitecore.com/sai/ja/developers/sitecoreai/deploying-sitecoreai/the-sitecoreai-build-configuration.html#post-deployment-actions)を使ってください。  
  
例えば:  
  
"deployItems": {  
  "modules":  
     "Foundation.\*",  
     "Feature.\*",  
     "Project.\*"  
       
}  
  
**重要**  
ビルド設定にdeployItemsを含めない場合、sitecore.jsonファイルのmodulesプロパティのすべてのメンバーはIARファイルに変換されます。  
  
IARファイルを直接削除・改変することはできません。既存の項目を上書きする必要がある場合は、次の展開の一環として行う必要があります。

buildTargets

どのプロジェクトやソリューションを作るかを定義できます。  
  
例えば:  
  
"buildTargets":  
    "./src/CM/Platform.csproj",  
   "./src/CM/Root.sln"  
,  
  
この構成は msbuild コマンドへの引数の渡し方に影響を与えます:  
msbuild .\\src\\platform\\Platform.csproj /p:Configuration=$env:BUILD\_CONFIGURATION /m /p:DeployOnBuild=true /p:PublishProfile=Local

renderingHosts

レンダリングホストの位置や、それらがマッピングするサイトの位置を設定できます。キーとバリューのペアで構成されており、キーは *一意なサイト名*で、その値は [サイトに関する情報](https://doc.sitecore.com/sai/ja/developers/sitecoreai/deploying-sitecoreai/the-sitecoreai-build-configuration.html#configuration-options-for-rendering-hosts)を含んでいます。

transforms

XDTパスをターゲットパスにマッピングするアイテムの配列です。  
  
XDT変換を処理する場所へのワイルドカード付きで完全適格パスを指定することができます。

postActions

[展開プロセスの展開段階後に実行される操作。](https://doc.sitecore.com/sai/ja/developers/sitecoreai/deploying-sitecoreai/the-sitecoreai-build-configuration.html#xdt-transformations)

authoringPath

オーサリング環境コードの相対的なパスを指定できます。これにより、編集ホストとオーサリング環境コードが同じリポジトリを共有している場合、オーサリング環境コードの変更が自動的に編集ホストの再デプロイを引き起こしたり、その逆を誘発したりしません。デフォルト値は ./authoringです。  
  
**注記**  
[このプロパティは、オーサリング環境と編集ホストを別々にデプロイできるベータ機能で作成された環境にのみ影響します。](https://developers.sitecore.com/changelog/sitecoreai/03032025/improvements-to-project-creation-and-management%2c-including-separate-repositories-for-each-authoring-environment-and-editing-host)

## ホストレンダリングの設定オプション

ビルド設定ファイルでレンダリングホストを定義できます。各定義は *、サイト名をサイト* に関する情報にマッピングします。

例えば:

"renderingHosts": {
 "xmcloudpreview": {
 "path": "./src/rendering",
 "nodeVersion": "16.3.19",
 "packageManager": "npm",
 "jssDeploymentSecret": "super-secret-value",
 "enabled": true,
 "type": "sxa",
 "buildCommand": "build",
 "runCommand": "next:start"
 }
 }

> !注編集ホストのビルドプロセスとランタイムは制限された環境で動作します。読み取り、追加、編集、削除などのファイル操作は指定された作業ディレクトリ内で行う必要があります。

以下の表は、サイト情報の設定に使用するプロパティを説明します。

名称

種類

概要

path

string

xmcloud.build.jsonファイルからアプリのソースコードへの相対的な経路です。通常はルートフォルダからの相対パスです。  
  
**XM Cloudは現在SitecoreAIとなっています**  
一部のコード例、画像、UIラベルは、エンジニアリング資産の更新中もXM Cloudを使用している場合があります。

nodeVersion

string

ホストレンダリング用の特定のNode.jsバージョン。  
  
ホストやスターターが使用するNode.jsのメジャーバージョンとContent SDKが使用するバージョンは一致しなければなりません。

packageManager

string

アプリケーション構築に使うパッケージマネージャーを定義します。  
  
可能な値: npm、 pnpm。デフォルト値は npmです。  
  
プロパティがなければデフォルトが適用されます。

jssDeploymentSecret

string

32文字以上のランダム生成文字列。デプロイシークレットは、アプリケーションがSitecoreインスタンスにアイテムをデプロイすることを許可する共有シークレットです。scjssconfig.jsonファイルにdeploySecretの値を入力します。

enabled

boolean

サイトを有効にする。  
  
デフォルト: false。

type

string

レンダリングホストの種類。  
  
許容値: "jss" または "sxa"。  
  
デフォルト: "jss"  
  
**注記**  
SXAサイトは [SXAテンプレート](https://doc.sitecore.com/xp/en/developers/sxa/104/sitecore-experience-accelerator/create-a-headless-site-collection-and-site.html) から作成され、アイテムベースの構成が使われます。JSSサイトは [JSSテンプレート](https://doc.sitecore.com/sai/en/developers/jss/217/jss-sai/the-jss-app-initializer.html) から作成され、ファイルベースの構成を使用します。

buildCommand

string

package.jsonファイルからコマンドをビルドして実行します。  
  
デフォルト: "build"

runCommand

string

package.jsonファイルからコマンドを実行して実行してください。  
  
デフォルト: "next:start"

> !重要startCommandは非推奨され無視されています。代わりにbuildCommandとrunCommandを使いましょう。

## カスタム編集ホスト

[編集ホストは](https://doc.sitecore.com/sai/ja/developers/sitecoreai/environment-editing-hosts-and-rendering-hosts/the-different-types-of-editing-hosts-in-sitecoreai.html)、Page BuilderやDesign StudioなどのエディターでWYSIWYG編集を可能にします。カスタム編集ホストは、xmcloud.build.jsonファイルのrenderingHostsエントリに対応します。

> !警告カスタム編集ホストを追加する際に「デフォルト」という名前は使わないでください。「Default」は予約された編集ホスト名であり、カスタム編集ホストには使用できません。この名前でカスタム編集ホストを設定しようとすると、誤ったサイト解像度や予期しない挙動を引き起こす可能性があります。

## XDT変換

XDT変換をサポートするには、フォルダまたはXDTのソースファイルおよび設定宛先ファイルへの完全限定パスを指定する必要があります。

変換は完全に構築された解で起こります。

パスは構築されたコードのウェブルートに対して相対的でなければなりません。例えば、XDTのソースファイルがsrc/platform/xdtsフォルダにあると仮定すると、変換パスを次のように設定できます:

"transforms": 
 {
 "xdtPath": "/xdts/<some-transforms>/",
 "targetPath": "/<somewhere>/"
 },
 {
 "xdtPath": "/xdts/<trasforms-at-the-root>/",
 "targetPath": "/"
 },
 {
 "xdtPath": "/xdts/web.config.xdt",
 "targetPath": "/web.config"
 }
 

> !注各変換のxdtPathプロパティの価値は、プロジェクトファイルの整理方法によって異なります。この例では、プロジェクトがSitecoreが提供する基礎テンプレートに基づいており、変換が /src/platform/xdts/ フォルダにあると仮定します。XDTファイルの定義方法については、[web.config](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/transform-webconfig?view=aspnetcore-6.0)変換のドキュメントを参照してください。

## 展開後の行動

デプロイメントプロセスのデプロイメントの*後に*実行される「*ポストアクション*」と呼ばれる様々な操作を設定できます。

ビルド構成には、要件に合わせてカスタマイズできるデフォルトのアクションが含まれています。これらはpostActionsオブジェクトのactionsプロパティを用いて定義され、以下が含まれます:

-   CMウォームアップ。
-   SCSモジュールの展開。
-   スキーマ集団。
-   インデックス変更。
-   出版。

> !注ポストアクションは設定ファイルに表示される順に順に実行されます。したがって、投稿アクションを設定する際は、アクションの順序を変更しないことを強くお勧めします。
> 
> 以下の例で示された順序により、SCSモジュールを展開した場合、それらは公開されます。そして、インデックスは再インデックスする前に入力されていること。

投稿アクション構成は以下の構成です:

"postActions": {
 "actions":{
 "warmUpCm": {
 "urls": 
 },
 "scsModules": {
 "modules": 
 },
 "populateSchema": {
 "indexNames": 
 },
 "reindex": {
 "indexNames": 
 },
 "publish": {
 "path": "",
 "languages": ,
 "itemIds": ,
 "targets": ,
 "republish": true,
 "publishSubItems": true
 }
 }
}

### CMウォームアップアクション

warmUpCmアクションのurlsプロパティで相対的なURLの配列を定義することで、さまざまな[SitecoreAI](https://doc.sitecore.com/sai/en/users/sitecoreai/sitecoreai.html)ページをウォームアップできます。

例えば:

"warmUpCm": {
 "urls": 
 "/sitecore/shell",
 "/sitecore/shell/Applications/Content%20Editor.aspx?sc\_bw=1",
 "/sitecore/client/Applications/Launchpad",
 "/sitecore/client/Applications/ControlPanel.aspx?sc\_bw=1"
 
}

### SCSモジュール展開アクション

> !注Sitecoreコンテンツシリアライズの詳細については、「 [Sitecoreコンテンツシリアライズの設定](https://developers.sitecore.com/learn/accelerate/xm-cloud/pre-development/sprint-zero/setup-content-serialization)」をご覧ください。

scsModulesアクションを使ってSitecore Content Serialization(SCS)モジュールをSitecoreインスタンスにデプロイできます。

scsModulesアクションの構造は以下の通りです。

"scsModules": {
 "modules": "Module1","Module2"
}

### スキーマ集団の行動

管理されるスキーマ集団を特定のインデックスに制限するには、populateSchemaアクションのindexNamesプロパティでインデックス名のリストを定義できます。

空配列は利用可能なすべてのインデックスの母集団となります。

例えば:

"populateSchema": {
 "indexNames": 
}

### リインデックス作業

reindexアクションのindexNamesプロパティでインデックス名のリストを定義することで、特定のインデックスにリインデックスを制限できます。

空の配列は利用可能なすべてのインデックスの再インデックス化につながります。

例えば:

"reindex": {
 "indexNames": 
}

### 出版の行動

publishアクションを使って公開操作を設定できます。

publishアクションの構造は以下の通りです。

"publish": {
 "path": "",
 "languages": ,
 "itemIds": ,
 "targets": "",
 "republish": true,
 "publishSubItems": true
}

publishアクションを使ってアイテムを公開する際、パブリッシュアクション内のpublishSubItemsプロパティを定義することで、そのサブアイテムの公開を制御できます。このプロパティが含まれていない場合、サブアイテムはデフォルトで公開されます。

許可される値は以下の通りです:

-   true - サブアイテムが公開されます。
-   false - サブアイテムは公開されません。

以下の例では、*/sitecore/content/Home*のサブアイテムは公開されていません:

"publish": {
 "path": "/sitecore/content/Home",
 "languages": ,
 "itemIds": ,
 "targets": ,
 "republish": true,
 "publishSubItems": false
}

### アクション後のタイムアウトを変更してください

各ポストアクションのデフォルトのタイムアウトは30分です。場合によっては、リインデックスすべきアイテムが多数ある場合など、デフォルトのタイムアウトを上書きする必要があるかもしれません。

デフォルトのタイムアウトは、Post Actions構造でtaskTimeOutプロパティを定義することで変更できます。

以下の例では、アクション後のタイムアウトが45分に変更されます:

"postActions": {
 "actions":{
 ...
 },
 "taskTimeOut": "00:45:00"
}