--description "..."
```
登録が完了すると、セッションの開始時に、そのアウトポストが Devin Cloud のマシンオプション (Ubuntu や Windows などと並ぶ) として表示されます。そのアウトポストを対象とするセッションは、ワーカーが引き取るまで、そのキューで待機します。
fleet API では、アウトポストは `outposts` リソースとして表され、アカウント単位でスコープされます (そのアカウント内のすべての組織で共有されます) 。詳しくは、
[outposts エンドポイント](/ja/cloud/outposts/reference#outposts)をご覧ください。
### 2. fleet API で待機中のセッションを監視する
オーケストレーターは、担当するアウトポストの待機中のセッションを一覧表示します:
```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending"
```
その後は、list の最後の cursor から再開しながら、Server-Sent Events (SSE) の監視を使って表示を最新の状態に保ちます:
```bash theme={null}
curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&cursor="
```
これは、Kubernetesで一般的な「list してから監視する」パターンです。レスポンスの cursor を使って list をページングし、その後、list の続きから監視を開始します。また、変更を取りこぼさずに再接続できるよう、各イベントの cursor を永続化します。配信は少なくとも 1 回行われるため、`metadata.session_id` で upsert し、重複を許容してください。クエリパラメータ、レスポンス形式、pagination の詳細な仕様については、[List queued sessions](/ja/cloud/outposts/reference#list-queued-sessions) と [Watch for changes](/ja/cloud/outposts/reference#watch-for-changes) を参照してください。
### 3. プロビジョニング前に引き取る
セッション用のマシンを起動する前に、ほかのワーカーに取得されないよう、アトミックに引き取ります。`acceptor_id` を渡します。これは、ワーカー自身が申告する識別情報です：
```bash theme={null}
curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"acceptor_id": "worker-1"}' \
"https://api.devin.ai/opbeta/outposts/devins/{session_id}/claim"
```
引き取りはアトミックです。別のワーカーが先にそのセッションを引き取っていた場合は、`409` が返されます。引き取ると、サーバーによって割り当てられた引き取り期限 (`status.claim_deadline`) までにワーカーの準備が整うことが保証されます。期限切れになった引き取りは自動的にキューへ戻ります。プロビジョニングに失敗した場合は、セッションがすぐにキューへ戻るように、[引き取りを解放](/ja/cloud/outposts/reference#release-a-claim)してください。
### 4. マシンを起動してワーカーを実行する
取得済みの各セッションについて、イメージを使って VM またはコンテナをプロビジョニングします。その中で、セッションのリポジトリがすでにチェックアウトされているディレクトリからワーカーを実行します：
```bash theme={null}
cd /path/to/repos
devin worker start --session= --outpost= --acceptor-id=
```
API で引き取る際に使用したものと同じ `--acceptor-id` を指定し、トークンは `--token` または `DEVIN_OUTPOSTS_TOKEN` で指定します ([フラグの完全な一覧](/ja/cloud/outposts/reference#devin-worker-start)を参照) 。ワーカーは Devin のクラウドに接続し、セッションを準備完了にして、ツール呼び出しの実行を開始します。
### 5. ワーカーが終了したらマシンを終了する
`devin worker start` が終了した時点で、セッションは終了しているか、一時停止されています。VM またはコンテナを終了してください。アウトポストが再開可能な場合は、終了前にマシンのスナップショットを作成しておくと、セッション再開時に復元できます。
オーケストレーターは、引き取ったセッションとその状態を追跡できます：
```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
"https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1"
```
各エントリの `status.session_status` には、`pending`、`running`、`suspended`、または `terminated` が示されます。
## 中央集約なしのスケジューリング
約16台を超えるコーディネーター (アウトポストを監視して引き取りを行うワーカーまたはオーケストレーター) を
運用する予定がある場合は、まずアカウント担当チームにご相談ください。大規模な
フリートでは引き取りの競合やキュー読み取りの負荷が増大するため、
それに対応できるようアウトポストが適切にプロビジョニングされていることを
事前に確認したいためです。
フリートの運用に中央スケジューラーは必要ありません。キュー API は、多数の独立したワーカーが互いに通信することなく、同じアウトポストを処理できるよう設計されています。
* **調整の仕組みは引き取りだけです。** 各ワーカーは独立してキューを監視し、保留中のセッションの引き取りを競って行います。引き取りはサーバー上で原子的な compare-and-swap として処理されるため、成功するワーカーは必ず1台だけです。失敗したワーカーはすべて `409` を受け取り、そのまま次の保留中セッションに進みます。引き取り競争に負けることは通常の動作であり、エラーではありません。
* **各ワーカーはそれぞれ固有の ID を持ちます。** `acceptor_id` によって、ワーカーの引き取り、更新、再起動後の復旧はそのワーカー自身にのみ紐づけられます。`devin worker start` はマシンごとにこれを自動生成して保存するため、フリート側で ID を設定する必要はありません。acceptor ID (またはコピーしたワーカーデータ directory) を複数のマシンで共有しないでください。衝突したワーカー同士で互いの引き取りを奪い合ってしまいます。
* **障害は自動的に復旧します。** ワーカーが引き取り後に停止した場合、その引き取りは引き取り期限に達すると失効し、セッションはキューに戻って別のワーカーが取得できるようになります。フリート全体でヘルス状態を追跡する必要はありません。
つまり、スケールアウトは、同じアウトポストを参照するワーカーをより多くのマシンで実行するだけです。N 台のマシンで N 個のセッションを同時に処理でき、それ以外は保留のまま待機します。
## カスタム オーケストレーターの構築
`devin worker start` で実行される処理はすべて fleet API から直接利用できるため、CLI を完全に置き換えられます。`devin-remote` バイナリを Devin の静的配布元から取得し、ドキュメントに記載された環境で自分で起動してください。詳しくは、リファレンスの [Remote binary distribution](/ja/cloud/outposts/reference#remote-binary-distribution) と [spawn contract](/ja/cloud/outposts/reference#spawn-contract) を参照してください。