ClearJanitor — アプリケーション検証¶
商業用清掃ロボット管理
概要¶
ClearJanitor はスケジュール駆動型のマルチテナントアプリケーションで、商業用清掃ロボットフリートを管理します。WES と比較して、より単純な実行コントラクトを使用しますが、複雑な組織関係を導入します——リース会社、コントラクター、エンドユーザーが異なるアクセスレベルで同じロボットと対話する場合があります。
ClearJanitor は、WES の複雑な倉庫オペレーションをサポートする同じアーキテクチャを通じて、プラットフォームが定期スケジュール、マルチテナント所有権階層、およびよりシンプルなエッジコントラクトを処理できることを検証します。Syrius Robotics が構築したファーストパーティアプリケーションとして、ClearJanitor はサードパーティ開発者が利用できる同じ API を使用します——特権アクセスはありません。
所有権と運用の分離¶
ClearJanitor は2つのビジネスモデルをサポートしています:
Model A: Leasing Company → Contractor → End User
(ClearJanitor user = Contractor who operates the robots)
Model B: End User buys/rents directly
(ClearJanitor user = End User)
ClearJanitor は所有権に関わらず、ロボットを運用する事業者にサービスを提供します。リース会社はすべてのコントラクターにわたるアセット利用状況への読み取り専用の可視性を持つ場合がありますが、日々の運用を制御しません。
この所有権チェーンはプラットフォームのアイデンティティインフラに直接対応します:
役割 |
プラットフォームサービス |
アクセス |
|---|---|---|
リース会社 |
Org Service(管理アカウント) |
コントラクター全体への読み取り専用の可視性 |
コントラクター |
Org Service(メンバーアカウント) |
割り当てられたロボットの完全な運用制御 |
エンドユーザー |
DotID(認証済みユーザー) |
モデルAまたはBに依存 |
クロスアカウント可視性 |
リース会社はコントラクター全体のアセットを確認できます |
利用するプラットフォームサービス¶
サービス |
プレーン |
用途 |
|---|---|---|
データ |
清掃ロボットの登録、リース状況の追跡、アラートおよび OTA ステータスの監視 |
|
データ |
清掃カバレッジヒートマップ、バッテリー分析、ロボットステータスダッシュボード |
|
データ |
ポリシー駆動のマップおよびファームウェア配信(清掃フリート向け) |
|
アイデンティティ |
オペレーターの認証、請負業者とエンドユーザーのロールの区別 |
|
アイデンティティ |
リース会社 → 請負業者 → エンドユーザーの階層をモデル化 |
|
アイデンティティ |
リース会社が複数の請負業者にわたる読み取り専用の可視性を取得 |
|
空間 |
建物のフロアプラン、ゾーン定義 |
|
空間 |
カバレッジクエリ——「今日清掃されていないフロアはどこか?」 |
|
インテリジェンス |
清掃ルートとシーケンスの生成 |
|
インテリジェンス |
定期清掃ジョブ——毎夜、毎週、条件付きトリガー |
|
インテリジェンス |
清掃中のロボット監視、スタック/エラー状態の処理 |
|
ガバナンス |
バッテリー閾値、時間帯制限、ゾーンルール |
|
ガバナンス |
オペレーターが会話形式で清掃ポリシーを定義 |
使用するプレーン¶
プレーン |
ClearJanitor での利用方法 |
|---|---|
デバイス登録(DeviceAdmin)、カバレッジダッシュボード(ThingIO)、マップ/ファームウェア配信(OTAForge) |
|
リース会社、コントラクター、エンドユーザー全体にわたるマルチテナントアクセス制御 |
|
建物のフロアプラン、カバレッジ追跡、ゾーンベースのクエリ |
|
ルートプランニング → 定期スケジューリング → 実行モニタリング |
|
オペレーター定義の清掃ルール、時間制限、バッテリーポリシー |
|
Marketplace に公開され、インストール時に清掃ドメインポリシースキーマを登録します |
検証シナリオ¶
1. Multi-Tenant Org Hierarchy¶
あるリース会社が5つのコントラクターに展開された200台の清掃ロボットを所有しています:
LeaseCo (management account)
├── CleanPro Inc. (member account) — 60 robots
├── SparkleTeam (member account) — 45 robots
├── NightShift Cleaning (member account) — 35 robots
├── FreshFloors (member account) — 30 robots
└── BrightSpace (member account) — 30 robots
LeaseCo は IAM Identity Center を通じて、すべてのコントラクターにわたるアセット利用率、バッテリー状態、リース状況を確認できます
各コントラクターは自分のロボットを独立して管理します
コントラクターはお互いのデータを確認できません
この検証内容:
Org Service の3階層構造(管理アカウント → メンバーアカウント → リソース)は現実世界のアセット所有権チェーンをモデル化します
IAM Identity Center は運用制御を付与することなくクロスアカウントの可視性を提供します
プラットフォームのマルチテナンシーは複雑なB2B関係に対して十分な粒度を持っています
2. Recurring Schedule-Driven Scheduling¶
ClearJanitor は一回限りのオーダー駆動型割り当てではなく、定期スケジュールを使用します:
スケジュールタイプ |
例 |
頻度 |
|---|---|---|
毎夜 |
営業時間後に全フロアを清掃 |
毎日、午後10時 |
毎週 |
トイレの徹底清掃 |
毎週日曜日、午前2時 |
条件付き |
通行量が閾値を下回ったときにロビーを清掃 |
イベント駆動 |
この検証内容:
Scheduler の定期/cronスタイルモードは予測可能な繰り返しワークロードを処理します
WES の一回限りの割り当てを処理する同じ Scheduler が ClearJanitor の定期ジョブも処理します
条件付きスケジューリング(将来の機能)は有効なユースケースです
3. Simple Single-Path Execution Contracts¶
ClearJanitor のコントラクトは WES のマルチステップピッキングよりもシンプルです:
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
この検証内容:
Execution Contract モデルはグレースフルにスケールダウンします——同じパターンがシンプルな単一パスルートと複雑なマルチステップ倉庫オペレーションの両方で機能します
コントラクトペイロードの複雑さはアプリケーションが定義するものであり、プラットフォームが強制するものではありません
4. Edge-Cloud Reconciliation (Lower Complexity)¶
清掃ロボットがビルの地下でルートの途中で接続を失います:
予測状態: 床の70%を清掃済み(ルートの進捗と経過時間に基づく)
実際の状態: 100%清掃済み(ロボットが予測より速く移動した)
再接続時:状態が更新され、再プランニング不要、次のジョブをより早く開始できる可能性があります。
この検証内容:
Edge-Cloud Reconciliation は異なる複雑度レベルで機能します——ClearJanitor の整合はよりシンプル(単一パスルート)ですが、WES と同じステートマシンを使用します
正の乖離(予測より良好)はグレースフルに処理されます
5. Conversational Policy Creation (Cleaning Domain)¶
ビルのオペレーターが AI Policy Agent に伝えます:
「平日の午前8時から午後7時の間は清掃禁止、廊下よりもトイレを常に優先すること」
エージェントは ClearJanitor のドメインポリシースキーマを使用して cleaning-robot、time-window、zone-priority を理解し、正式なポリシーを作成します。
この検証内容:
同じ AI Policy Agent が清掃(ClearJanitor)と倉庫(WES)のドメインで機能します——ドメインポリシースキーマによって真にドメイン非依存になります
異なるドメインは異なる語彙を持ちますが、同じポリシーメカニズムを使用します
明らかになったアーキテクチャの洞察¶
洞察 |
プラットフォーム設計への影響 |
|---|---|
マルチテナント組織階層(資産所有者 ≠ オペレーター) |
Org Service は、デバイスを運用するアカウントと所有するアカウントが異なる所有権チェーンをサポートする必要があります |
定期/cronスタイルのスケジューリングが必要 |
Scheduler は一回限り(WES)と定期(ClearJanitor)の両方のスケジューリングモードをサポートする必要があります |
よりシンプルなエッジコントラクト、同じモデル |
Execution Contract パターンは、シンプルなユースケースに対してオーバーヘッドなしにグレースフルにスケールダウンする必要があります |
制御なしのクロスアカウント可視性 |
IAM Identity Center は、デバイスを運用しないアセットオーナーのための読み取り専用のクロスアカウントアクセスをサポートする必要があります |
同じ実行コントラクト・モデル、異なるペイロードの複雑度 |
プラットフォームがコントラクト構造を定義し、アプリケーションがペイロードの複雑さを定義します |