実行コントラクト・パターン¶

背景¶

エッジデバイス（AMR、清掃ロボット、PDA）は、ネットワーク接続が断続的な環境で動作します。デバイスがタスクの実行を開始すると、プラットフォームは持続的な接続を前提とすることができません。これにより根本的な課題が生じます：クラウドとエッジ間のリンクがいつでも切断される可能性がある中で、プラットフォームはどのように作業を割り当て、進捗を把握し、障害から回復するのか？

タスク指示をデバイスのファームウェアに直接ハードコードするのは硬直的すぎます。ライブ接続でコマンドを送信するだけでは脆弱すぎます。プラットフォームは、オフライン実行のために十分に自己完結している が、デバイスに到達できない場合の クラウド側の推論のために十分に構造化された モデルを必要とします。

パターン¶

コントラクトの内容¶

プラットフォームがデバイスにタスクを割り当てる際、実行コントラクト をプッシュします。コントラクトは以下を含む自己完結型のパッケージです：

コンポーネント	説明
タスク定義	デバイスが達成すべきこと（ピック、移動、清掃など）
スコープ付きアクション	デバイスが実行を許可されているアクションのセット
必要なデータ	空間データ（Equator からのマップ抜粋）、ゾーン境界、ランドマーク
制約	バッテリー閾値、時間ウィンドウ、ゾーン制限
障害ポリシー	コントラクトを完了できない場合の対処方法

コントラクトがプッシュされた時点で接続が確認されます — プラットフォームはデバイスがそれを受信したことを把握します。

3つのデバイス状態¶

コントラクトがプッシュされると、デバイスは Execution Manager によって管理されるステートマシンに入ります：

    ┌────────────┐
    │    Live     │ ◄── Connected, real-time telemetry
    └─────┬──────┘
          │ connection lost
          ▼
    ┌────────────┐
    │ Projected  │ ◄── Offline, platform estimates based on contract
    └─────┬──────┘
          │ device reconnects
          ▼
    ┌────────────┐
    │ Reconciled │ ◄── Actual state corrects projection
    └─────┬──────┘
          │ divergence? → replan
          ▼
    ┌────────────┐
    │    Live     │
    └────────────┘

状態	意味	プラットフォームの挙動
ライブ	接続済み、リアルタイムテレメトリ	プラットフォームが実際の状態を直接把握
予測	オフライン、テレメトリなし	プラットフォームがコントラクトのスコープに基づいて推定
照合済み	デバイスが再接続し、実際の状態を報告	実際の状態が予測を修正し、必要に応じて再計画をトリガー

二層計画モデル¶

実行コントラクトは計画を2つの本質的に異なる層に分離します：

層	場所	スコープ	特性
Platform Planner	クラウド	グローバル、マルチリソース	戦略的 — 「どのリソースがどのタスクを担当するか」
エッジ・プランナー	デバイス	シングルエージェント、ローカル	戦術的、リアクティブ — 「前方に障害物、経路変更」

これらのプランナーは異なる問題を解決し、ロジックを共有しません。Platform Planner はフリート全体のリソース割り当てについて推論します。エッジ・プランナーは、コントラクトの範囲内でリアルタイムの障害物回避、ローカル経路調整、および即時センサー応答を処理します。

部分的な接続状態での再計画¶

一部のデバイスが接続を失い、他のデバイスが接続を維持している場合：

接続済みデバイス — 自由に再計画し、必要に応じてタスクを再割り当て
オフラインデバイス — コントラクトのタスクを予測状態として保持し、再割り当てしない
再接続時 — 実際の状態と予測を照合し、乖離が検出された場合はグローバル再計画をトリガー

これにより、プラットフォームが作業を二重に割り当てること（オフラインデバイスのタスクを別のデバイスに渡し、元のデバイスが再接続したときに両方が実行しようとする事態）を防ぎます。

コントラクト失敗時のリカバリ¶

障害回復はポリシー駆動であり、ハードコードされていません：

Execution Manager がコントラクトの失敗を検出
適用可能な回復戦略について Policy Service に問い合わせ
ポリシーの応答に基づいてリカバリを実行：

戦略	挙動
再試行	失敗したアクションを再試行
再割り当て	最も近くにある利用可能なデバイスにタスクを割り当て
エスカレーション	手動介入のためオペレーターに通知
保留	実行を一時停止し、条件が変わるのを待つ
中止	タスクを完全にキャンセル

アプリケーションは、開発者プリセットまたはオペレーターが作成したポリシー（AI Policy Agent 経由）を通じて障害回復ポリシーを定義します。

結果¶

メリット¶

オフライン耐性 — デバイスは持続的な接続なしにタスクを完了できる
二重割り当てなし — 予測状態により、オフラインデバイスがまだ実行中の作業の再割り当てを防止
コンポーザブルな障害処理 — 回復戦略はコードではなくポリシーで定義され、アプリケーション、アカウント、デバイスタイプごとにカスタマイズ可能
クリーンな分離 — クラウド側の戦略的計画とエッジ側の戦術的実行がコントラクト境界内で独立して動作

トレードオフ¶

古くなった予測 — デバイスがオフラインである時間が長いほど、予測状態の精度が低下します。プラットフォームは不確実性を受け入れなければなりません
コントラクトの粒度 — コントラクトはオフライン実行のために十分に自己完結していなければならず、空間データ、制約、およびポリシーを動的にクエリするのではなく、プッシュ時に含める必要があります
照合コスト — 多数のデバイスが同時に再接続すると、照合と再計画のバーストが計算コスト的に高くなる可能性があります

例¶

WES — 複雑なマルチステップ・コントラクト¶

倉庫オーダーが複数の意思決定ポイントを持つコントラクトをトリガーします：

Contract: Pick Order #4521
├── Step 1: Navigate to Rack B-12 (map excerpt included)
├── Step 2: Pick item SKU-7890 from shelf 3
├── Step 3: Navigate to Packing Station 2
├── Step 4: Place item on conveyor
├── Failure policy: Retry once, then reassign to nearest AMR
└── Constraints: Battery > 20%, complete within 15 min

AMR がステップ2の後に接続を失った場合、プラットフォームは過去の移動時間に基づいてパッキングステーション2に到着すると予測します。再接続すると、実際の位置が予測と照合されます。

ClearJanitor — シンプルな単一経路コントラクト¶

スケジュールされた清掃ジョブは、よりシンプルなコントラクトを生成します：

Contract: Clean Floor 3, Zone A
├── Route: [waypoint sequence from Marie]
├── Coverage target: 95%
├── Failure policy: Hold and notify operator
└── Constraints: Battery > 15%, complete before 6 AM

コントラクトモデルは同一ですが、ペイロードの複雑さは異なります。清掃ロボットは自律的にルートを実行します。スタックした場合、障害ポリシーは自動的な再割り当てではなくオペレーターへの通知をトリガーします。