> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ランナーのデプロイと管理

> CKS クラスターにランナーをデプロイし、健全性の確認、設定の更新、削除を行います。

**マネージドランナー**は、CKS クラスター内でサンドボックスを実行する、CoreWeave が管理するコンポーネントです。このページでは、ランナーのデプロイ、健全性の確認、ニーズの変化に応じた設定の調整、不要になった場合の削除まで、ライフサイクル全体を説明します。サンドボックスのアーキテクチャにおけるランナーの位置付けと、ゲートウェイがランナーへのリクエストを仲介する仕組みについては、[サンドボックスのアーキテクチャ](/ja/products/sandboxes/architecture)を参照してください。

ランナーの有効化から最初のサンドボックスの実行までの手順ガイドについては、[独自のコンピュートを使用する](/ja/products/sandboxes/get-started-cks)を参照してください。

<h2 id="before-you-begin">
  事前準備
</h2>

このページの CLI と `curl` の例は、いずれも CoreWeave API アクセストークンで認証します。Cloud Console の [Tokens](https://console.coreweave.com/tokens) ページでトークンを生成し、**Token Secret** の値をコピーしてください。トークンの詳細については、[API アクセストークンの管理](/security/authn-authz/manage-api-access-tokens)を参照してください。

**CLI**: [CoreWeave Intelligent CLI](https://github.com/coreweave/cwic) (`cwic`) をインストールし、`cwic auth login` を実行して、プロンプトが表示されたらトークンを貼り付けます。トークンはローカルの `cwic` 設定に保存され、以降のコマンドでは自動的に読み込まれます。環境変数を設定する必要はありません。

```bash theme={"system"}
cwic auth login
```

**`curl`**: このページの例からトークンを参照できるよう、シェルでトークンをエクスポートします。`[API-ACCESS-TOKEN]` は、ご自身の CoreWeave API アクセストークンに置き換えてください。

```bash theme={"system"}
export TOKEN="[API-ACCESS-TOKEN]"
```

<h2 id="runner-commands">
  ランナーコマンド
</h2>

`cwic sandbox runner` グループはランナーを管理します。以下の表は、各ライフサイクルタスクとそれを実行するコマンドの対応を示しています。以降のセクションでは、これらのコマンドについてコンテキストに沿って順を追って説明します。

| 目的 | コマンド |
| - | - |
| ランナーをデプロイする (ウィザード) | `cwic sandbox runner create [RUNNER-ID]` |
| ファイルからランナーをデプロイする | `cwic sandbox runner create [RUNNER-ID] -f runner.yaml` |
| ランナーを一覧表示する | `cwic sandbox runner get` (エイリアス `ls`) |
| 1つのランナーを検査する | `cwic sandbox runner get [RUNNER-ID]` |
| 詳細ビュー | `cwic sandbox runner describe [RUNNER-ID]` |
| ランナーを編集する | `cwic sandbox runner edit [RUNNER-ID]` |
| 利用可能なアップデートを適用する | `cwic sandbox runner upgrade [RUNNER-ID]` |
| ランナーを削除する | `cwic sandbox runner delete [RUNNER-ID]` |
| ランナーのポリシーを読み取る | `cwic sandbox runner policy get [RUNNER-ID]` |
| ランナーのポリシーを編集する | `cwic sandbox runner policy edit [RUNNER-ID]` |

すべての入力は YAML または JSON を受け入れます。

<h2 id="deploy-a-runner">
  ランナーをデプロイする
</h2>

組織内の各 CKS クラスターでホストできるマネージドランナーは最大 1 つです。デプロイするには、以下を指定します。

* ランナー ID: クライアント側で割り当てる、人が読める形式の ID。組織内で一意である必要があります。
* ゾーン: クラスターが属する地理的ゾーン。
* クラスター ID (またはクラスター名): ランナーを実行する CKS クラスター。どちらも Cloud Console の [Clusters](https://console.coreweave.com/clusters) ページで確認できます。
* ポリシー: ランナーがそのクラスター上のサンドボックスに適用するルール。サンドボックスを実行するにはポリシーが必要です。省略した場合は、ランナーの接続時に CoreWeave がデフォルトのポリシーを適用します。ポリシーではサンドボックスのデフォルトのライフタイムを指定できます。ただし、上限である 30 日はプラットフォーム側で強制されます。[サンドボックスポリシーを設定する](/ja/products/sandboxes/profiles/configure) を参照してください。

<Tabs>
  <Tab title="CLI">
    ウィザードでは、クラスター、リリースチャンネル、メンテナンス期間をインタラクティブに入力します。その後、送信前に値が入力済みの spec がエディターで開きます。

    ```bash theme={"system"}
    cwic sandbox runner create prod-us-east-1
    ```

    ファイルモードは YAML または JSON を受け入れます。そのため、再現可能なセットアップにはこの方法が推奨されます。また、Claude Code や Codex など、ユーザーに代わってランナーの spec を生成するエージェントとの併用にも適しています。CLI は `-f -` を指定すると stdin からも読み込めます。`[CLUSTER-NAME]` は、ランナーをデプロイする CKS クラスターの名前に置き換えてください。

    ```yaml title="runner.yaml" theme={"system"}
    identity:
      zone: us-east-1
      cluster_name: [CLUSTER-NAME]
    spec:
      release_channel: RELEASE_CHANNEL_STABLE
      maintenance_policy:
        windows:
          - cron: "0 9 * * SAT"
            duration_seconds: 14400
    policy:
      display_name: default
      constraints:
        resources:
          default_cpu: "1"
          default_memory: "2Gi"
          max_cpu: "4"
          max_memory: "8Gi"
          require_limits: true
        lifecycle:
          default_lifetime_seconds: 3600
    ```

    spec を送信します。

    ```bash theme={"system"}
    cwic sandbox runner create prod-us-east-1 -f runner.yaml
    ```
  </Tab>

  <Tab title="curl">
    `[CLUSTER-ID]` は、ランナーをデプロイする CKS クラスターの ID に置き換えてください。

    ```bash title="マネージドランナーをデプロイする" theme={"system"}
    curl -X POST https://api.coreweave.com/v1/sandbox/managedRunners \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "displayName": "Production runner (US East)",
        "identity": {
          "runnerId": "prod-us-east-1",
          "zone": "us-east-1",
          "clusterId": "[CLUSTER-ID]"
        },
        "spec": {
          "releaseChannel": "RELEASE_CHANNEL_STABLE",
          "maintenancePolicy": {
            "windows": [
              { "cron": "0 9 * * SAT", "durationSeconds": 14400 }
            ]
          }
        },
        "policy": {
          "displayName": "default",
          "constraints": {
            "resources": {
              "defaultCpu": "1",
              "defaultMemory": "2Gi",
              "maxCpu": "4",
              "maxMemory": "8Gi",
              "requireLimits": true
            },
            "lifecycle": { "defaultLifetimeSeconds": 3600 }
          }
        }
      }'
    ```
  </Tab>
</Tabs>

以下の動作に注意してください。

* `maintenance_policy.windows` はオプションです。設定すると、自動更新は指定した cron ウィンドウの間にのみ適用されます。
* `runner_group_id` はオプションです。同じゾーンに複数のランナーがある場合、スケジューリングのアフィニティ指定に使用します。

<h3 id="common-validation-errors">
  よくある検証エラー
</h3>

| エラー | 対処 |
| - | - |
| `runner.identity.zone is required` | ゾーンを指定してください。CKS クラスターがある (つまりランナーのクォータがある) ゾーンは、Cloud Console の [Clusters](https://console.coreweave.com/clusters) ページ、または `cwic cluster get` の実行で確認できます。 |
| `runner.identity.cluster_id or cluster_name is required` | いずれかを指定してください。どちらも Cloud Console の [Clusters](https://console.coreweave.com/clusters) ページ、または `cwic cluster get` の実行で確認できます。 |
| `policy exceeds 256 KiB limit` | ポリシードキュメントを削減してください。エンコード後のドキュメントの上限は 256 KiB です。 |
| `a managed runner already exists for this cluster` | 1 つのクラスターでホストできるマネージドランナーは最大 1 つです。先に[既存のランナーを更新](#update-a-runner)するか、[削除](#delete-a-runner)してください。 |

<h2 id="check-runner-status">
  ランナーのステータスを確認する
</h2>

作成後、ランナーのステータスを確認して、正常にロールアウトされたかどうかを確認します。ロールアウトに失敗した場合は、ステータスをもとに問題を診断します。

<Tabs>
  <Tab title="CLI">
    ```bash theme={"system"}
    cwic sandbox runner describe prod-us-east-1
    ```

    表形式で概要をすばやく確認するには、エイリアス `get` を使用します。

    ```bash theme={"system"}
    cwic sandbox runner get prod-us-east-1
    ```

    どちらのコマンドでも、作成時に指定したランナー ID (`prod-us-east-1`) またはサーバーが割り当てた UUID を指定できます。
  </Tab>

  <Tab title="curl">
    ```bash title="ランナーを取得する" theme={"system"}
    curl -H "Authorization: Bearer $TOKEN" \
      https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1
    ```

    作成時に指定したランナー ID と、サーバーが割り当てた UUID のどちらでも渡すことができます。
  </Tab>
</Tabs>

応答には、トラッキングすべき 2 つのステータスフィールドが含まれます。

* **`installStatus`**: クラスターへのランナーのデプロイメントの進行状況 (`PENDING`、`PROVISIONING`、`READY`、または `FAILED`) 。
* **`connectionStatus`**: 現在の接続状態 (`CONNECTED` または `DISCONNECTED`) 。この値はランナーのハートビートによって更新されるため、最大 30 秒の遅延が生じることがあります。

`installStatus == FAILED` の場合、応答には構造化された `installError` が含まれます。

```json theme={"system"}
{
  "installError": {
    "reason": "...",
    "message": "...",
    "remediationHints": ["Add toleration for taint 'workload=gpu:NoSchedule'"],
    "occurredAt": "2026-04-24T12:03:11Z"
  }
}
```

`remediationHints` は、実行すべき action を示します。`diagnosticDetail` には、サポートチケットを作成する際に添付すると役立つ内部ログも含まれています。

<h2 id="update-a-runner">
  ランナーを更新する
</h2>

ランナーの編集コマンドは、対話型ウィザードとファイルによるパッチの両方をサポートします。内部的には、更新にフィールドマスクを使用し、変更したフィールドのみが適用されます。それ以外はすべて読み取り専用で、`installStatus`、`connectionStatus`、タイムスタンプ、解決済みのデプロイメント仕様も含まれます。

次のパスは変更可能です。

* `identity.zone`
* `identity.runner_group_id`
* `spec` (オブジェクト全体)
* `spec.release_channel`
* `spec.maintenance_policy`
* `spec.overrides`
* `spec.enforce_resource_limits`
* `policy` (ドキュメント全体)

REST API では、`PATCH` の本文はマネージドランナー自体であり、リクエストのラッパーはありません。フィールドマスクは `updateMask` クエリパラメーターとして渡されます。マスクが指定されていない場合、または `updateMask=*` の場合は、変更可能なリソース全体が置き換えられます。

次の 2 つのパスは、従来の `v1beta2` サーフェスでのみ受け付けられ、`v1` のマネージドランナーへの書き込みでは拒否されます。`profile_bindings` (代わりに `policy` を設定してください) と `spec.allow_privileged_profile_annotations` です。

<h3 id="common-runner-updates">
  ランナーの一般的な更新
</h3>

以下の例では、ランナーに対して最も頻繁に行われる編集を紹介します。リリースチャネルの切り替え、ランナーが保持するポリシーの置き換え、クラスター内でランナー Pod を配置する場所の調整、そしてレガシーのプロファイルテンプレートに特権構成を許可する方法です。

<h4 id="example-switch-release-channel">
  例: リリースチャンネルを切り替える
</h4>

<Tabs>
  <Tab title="CLI">
    stdin から 1 行のパッチを適用します:

    ```bash theme={"system"}
    echo 'spec: {release_channel: RELEASE_CHANNEL_RAPID}' \
      | cwic sandbox runner edit prod-us-east-1 -f -
    ```

    または、パッチをファイルに書き込んで送信します:

    ```yaml title="patch.yaml" theme={"system"}
    spec:
      release_channel: RELEASE_CHANNEL_RAPID
    ```

    ```bash theme={"system"}
    cwic sandbox runner edit prod-us-east-1 -f patch.yaml
    ```
  </Tab>

  <Tab title="curl">
    ```bash title="ランナーを RAPID チャンネルに移動する" theme={"system"}
    curl -X PATCH "https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=spec.releaseChannel" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "identity": { "runnerId": "prod-us-east-1" },
        "spec": { "releaseChannel": "RELEASE_CHANNEL_RAPID" }
      }'
    ```
  </Tab>
</Tabs>

<h4 id="example-replace-the-policy">
  例: ポリシーを置き換える
</h4>

ポリシーはドキュメント全体として置き換えられます。現在のポリシーを読み取り、必要な箇所を変更して送り返してください。`policy` 内にはフィールド単位のマスクがないため、本文の一部だけを送信すると、省略したグループは消去されます。

ポリシーの更新には `etag` も含めます。これは、ランナーを読み取るときに返される、不透明なリビジョントークンです。より新しい値ではなく、編集の基になった読み取りで取得した値を送信してください。古いトークンを使用すると `FAILED_PRECONDITION` で失敗し、何も変更されません。そのため、同時に行われた編集は知らないうちに上書きされることなく、エラーとして報告されます。

<Tabs>
  <Tab title="CLI">
    ```bash theme={"system"}
    cwic sandbox runner get prod-us-east-1 -o json > runner.json
    jq '.[0].policy' runner.json > policy.json
    ```

    `policy.json` を編集し、同じ読み取りで取得した `etag` に固定して送信します。

    ```bash theme={"system"}
    cwic sandbox runner policy edit prod-us-east-1 -f policy.json \
      --etag "$(jq -r '.[0].etag' runner.json)"
    ```

    `policy get` はポリシーを `etag` なしでエクスポートし、`--etag` を指定しない `policy edit -f` は送信時にランナーの現在のリビジョンを読み取ります。そのため、どちらもファイルの取得元のリビジョンには固定されません。エクスポート後に `policy describe` を使用するなどしてトークンを別途読み取る場合も、同じ問題が生じます。手元のドキュメントより新しいトークンはチェックを通過してしまい、その間に行われた変更を上書きします。`cwic sandbox runner edit` のテンプレートを使用すれば、この追加の手順は不要です。`--print-template` は変更可能な設定、ポリシー、およびその `etag` をまとめてエクスポートし、`-f` はファイル内の値を使用します。
  </Tab>

  <Tab title="curl">
    ランナーを読み取り、現在のポリシーと `etag` の両方を取得します。

    ```bash theme={"system"}
    curl -H "Authorization: Bearer $TOKEN" \
      https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1 \
      | jq '{policy, etag}' > policy-and-etag.json
    ```

    そのファイル内の `policy` オブジェクトを編集し、取得時の `etag` とともに送り返します。

    ```bash title="ランナーのポリシーを置き換える" theme={"system"}
    curl -X PATCH "https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=policy" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d @policy-and-etag.json
    ```
  </Tab>
</Tabs>

すべての制約グループと具体的な例については、[サンドボックスポリシーを設定する](/ja/products/sandboxes/profiles/configure)を参照してください。

<h4 id="example-pin-node-placement-through-deployment-overrides">
  例: デプロイメントのオーバーライドによるノード配置の固定
</h4>

`spec.overrides` フィールドは、サンドボックスの Pod ではなく、ランナー自体の Pod を調整します。ランナーの Pod を適切なノードに配置するために、特定のトレランス、ノードセレクター、またはランタイムクラスが必要な場合に使用します。

よくあるケースは、SUNK クラスター内で Slurm ジョブと並行して実行できるように、ランナーの Pod を SUNK Pod Scheduler 経由で配置することです。ランナーのオーバーライドにスケジューラー名と SUNK アノテーションを設定します。使用可能なアノテーションと必要な設定については、[SUNK Pod Scheduler インテグレーション](/ja/products/sandboxes/profiles/sunk-integration)を参照してください。

<Tabs>
  <Tab title="CLI">
    ```yaml title="overrides.yaml" theme={"system"}
    spec:
      overrides:
        node_selector:
          node-pool: system
        tolerations:
          - key: dedicated
            operator: Equal
            value: system
            effect: NoSchedule
    ```

    ```bash theme={"system"}
    cwic sandbox runner edit prod-us-east-1 -f overrides.yaml
    ```
  </Tab>

  <Tab title="curl">
    ```bash title="ランナーを特定の Node Pool に固定" theme={"system"}
    curl -X PATCH "https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=spec.overrides" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "identity": { "runnerId": "prod-us-east-1" },
        "spec": {
          "overrides": {
            "nodeSelector": { "node-pool": "system" },
            "tolerations":  [ { "key": "dedicated", "operator": "Equal", "value": "system", "effect": "NoSchedule" } ]
          }
        }
      }'
    ```
  </Tab>
</Tabs>

<h4 id="example-allow-a-privileged-profile-posture">
  例: 特権プロファイルの構成を許可する
</h4>

`allow_privileged_profile_annotations` は、ランナーにバインドされたレガシーのプロファイルテンプレートが特権的な構成を保持できるかどうかを制御します。ポリシーではなくプロファイルバインディングを引き続き使用しているランナーに適用されるため、リクエストは `v1beta2` サーフェスに送信されます。既定値は `false` で、このフラグが設定されていないランナーでは、特権的な構成を含むテンプレートは拒否されます。

名前から受ける印象とは異なり、このフラグは次の 2 種類の内容を制御します。

* 特権 Pod アノテーション、つまりランタイムおよびスケジューラのプレフィックス。
* `serviceAccountName`、ホスト名前空間、`hostPath` ボリューム、特権コンテナや権限昇格コンテナなど、特権的な構造化 Pod スペックフィールド。

ランナーが拒否したテンプレートは `permission_denied` を返し、問題となったフィールド名を示します。たとえば、`securityContext.appArmorProfile` と `securityContext.seccompProfile` を設定するテンプレートは、次のように失敗します。

```text title="Example output" theme={"system"}
Error: updating runner: permission_denied: profile_bindings[7]: template
"[TEMPLATE-ID]" contains privileged pod-spec fields
[securityContext.appArmorProfile securityContext.seccompProfile];
runner does not have allow_privileged_profile_annotations=true
```

テンプレートを拒否したランナーにフラグを設定します。このフラグは 1 つのランナーにのみ適用されるため、特権構成が必要なランナーごとにこの操作を繰り返してください。

<Tabs>
  <Tab title="CLI">
    ```bash theme={"system"}
    echo 'managed_spec: {allow_privileged_profile_annotations: true}' \
      | cwic sandbox runner edit prod-us-east-1 -f -
    ```
  </Tab>

  <Tab title="curl">
    ```bash title="1 つのランナーで特権プロファイル構成を許可する" theme={"system"}
    curl -X PATCH https://api.coreweave.com/v1beta2/sandbox/managed-runners/prod-us-east-1 \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "runner": {
          "id": "prod-us-east-1",
          "managedSpec": { "allowPrivilegedProfileAnnotations": true }
        },
        "updateMask": "managedSpec.allowPrivilegedProfileAnnotations"
      }'
    ```
  </Tab>
</Tabs>

更新が成功したら、拒否されたプロファイルテンプレートを再度適用します。

<Warning>
  このフラグを設定すると、ホストリソースへのアクセスを含め、ランナー上のサンドボックスが実行できる操作の範囲が広がります。特権構成が必要なランナーにのみ設定してください。
</Warning>

<h2 id="trigger-an-on-demand-runner-update">
  ランナーの更新をオンデマンドで実行する
</h2>

ランナーの `updateAvailable` が `true` の場合、次のメンテナンス期間を待たずに、すぐに更新を適用できます。

<Tabs>
  <Tab title="CLI">
    ```bash theme={"system"}
    cwic sandbox runner upgrade prod-us-east-1
    ```
  </Tab>

  <Tab title="curl">
    ```bash title="利用可能な更新をすぐに適用する" theme={"system"}
    curl -X POST https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1:applyAvailableUpdate \
      -H "Authorization: Bearer $TOKEN"
    ```
  </Tab>
</Tabs>

コントロールプレーンは、ランナーのリリースチャンネルで最新のバージョンを特定し、`target_revision` を更新します。クラスター内のコントローラーがその更新をロールアウトします。

<h2 id="list-runners">
  ランナーの一覧表示
</h2>

組織内のすべてのランナーを確認する場合や、特定のゾーン、クラスター、接続状態に絞り込んで表示する場合は、次の一覧コマンドを使用します。

<Tabs>
  <Tab title="CLI">
    ```bash theme={"system"}
    cwic sandbox runner get
    ```

    ゾーン、クラスター、接続状態でフィルタリングします。

    ```bash theme={"system"}
    cwic sandbox runner get --zone us-east-1
    cwic sandbox runner get --connection-status CONNECTED
    ```
  </Tab>

  <Tab title="curl">
    ```bash title="マネージドランナーの一覧表示" theme={"system"}
    curl -H "Authorization: Bearer $TOKEN" \
      'https://api.coreweave.com/v1/sandbox/managedRunners?pageSize=50&zone=us-east-1'
    ```

    サポートされているクエリパラメーターは、`zone`、`clusterId`、`connectionStatus`、`runnerId`、`managementMode`、`pageSize` (デフォルト 50、最大 100) 、`pageToken` です。ページネーションはカーソルベースです。
  </Tab>
</Tabs>

<h2 id="delete-a-runner">
  ランナーを削除する
</h2>

クラスター上のサンドボックスのキャパシティが不要になった場合、または同じクラスターに新しいランナーを再デプロイする前に、ランナーを削除します。

<Tabs>
  <Tab title="CLI">
    ```bash theme={"system"}
    cwic sandbox runner delete prod-us-east-1
    ```

    CLI で確認を求められます。スクリプトで使用する場合は、`--yes` を指定して確認を省略します。

    ```bash theme={"system"}
    cwic sandbox runner delete prod-us-east-1 --yes
    ```
  </Tab>

  <Tab title="curl">
    ```bash title="Decommission a runner" theme={"system"}
    curl -X DELETE https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1 \
      -H "Authorization: Bearer $TOKEN"
    ```
  </Tab>
</Tabs>

ランナーを削除すると、クラスター内のランナーのデプロイメントが撤去されます。そのランナーで実行中のサンドボックスはすべて停止します。ポリシーはランナーの一部なので、ランナーとともに削除されます。クラスターを再デプロイする予定がある場合は、ポリシードキュメントをバージョン管理下に保存してください。

<Warning>
  削除は元に戻せません。トラフィックを一時停止したいだけの場合は、このランナーを削除する前にサンドボックスを別のランナーに移動してください。
</Warning>

<h2 id="see-also">
  関連情報
</h2>

* [ノードの割り当て予算を設定する](/ja/products/sandboxes/operations/node-allocation-budgets): Node Pool またはノードのグループごとにサンドボックスの CPU とメモリのリクエストを制限します。
* [サンドボックスのアーキテクチャ](/ja/products/sandboxes/architecture): リソースモデル、コントロールプレーンとデータプレーンの比較、マルチクラスターのトポロジについて説明します。
* [ポリシーの概要](/ja/products/sandboxes/profiles/profiles): サンドボックスがポリシーに基づいてどのように決定されるかを説明します。
* [サンドボックスポリシーを設定する](/ja/products/sandboxes/profiles/configure): すべての制約グループを具体例とともに説明します。
* [コントロールプレーン API の概要](/ja/products/sandboxes/reference/control-plane-api): 認証、フィールドマスク、および各エンドポイントのリクエストと応答の構造について説明します。
* [ポリシーリファレンス](/ja/products/sandboxes/reference/profile): ポリシーで設定できるすべてのフィールドを説明します。