ポリシーアーキテクチャパターン

背景

FlexGalaxy.AI プラットフォームは、異なる開発者が作成した複数のアプリケーションをホストしており、それぞれ固有のドメインロジック、制約、および運用上の優先事項を持っています。同時に、プラットフォームはいかなるアプリケーションもオーバーライドできない安全限界と物理的制約を強制する必要があります。

サービスへの動作のハードコードは硬直的すぎます——倉庫アプリケーションと清掃アプリケーションでは、障害回復のニーズ、スケジューリングの優先事項、および運用ルールが大きく異なります。しかし、アプリケーションに任意の動作を定義させることは危険すぎます——設定ミスのポリシーはロボットを安全でない方法で動作させる可能性があります。

プラットフォームには次の特性を持つポリシーモデルが必要です：

1. 階層的 — プラットフォームの安全ルールは常に優先されます

2. ドメイン対応 — アプリケーションは自分たちの語彙でポリシーを定義できます

3. オペレーターカスタマイズ可能 — エンドユーザーはコードを書かずに動作を調整できます

4. 検証済み — すべてのポリシーは有効化前に競合と安全違反についてチェックされます

パターン

ポリシー階層

ポリシーは厳格な優先順位を持つ3つの階層に整理されています：

Platform defaults (safety, physics, hard limits) — cannot be overridden
    ↓
App-defined policies (developer presets) — can be customized within bounds
    ↓
User-defined policies (via AI Policy Agent) — validated before activation

層	作成者	オーバーライドルール	例
プラットフォーム	FlexGalaxy.AI	下位階層のいずれによってもオーバーライドできません	バッテリー最低閾値、最高速度制限、物理的制約
アプリ定義	開発者	開発者が設定した範囲内でオペレーターがカスタマイズ可能	デフォルトの障害回復戦略、スケジューリング優先事項、優先度ルール
ユーザー定義	オペレーター（AI Policy Agent 経由）	有効化前にすべての上位階層に対して検証済み	カスタムの時間帯制限、ゾーンルール、デバイス固有のオーバーライド

ポリシー評価

Intelligence Plane のすべての意思決定サービスは、実行前に Policy Service に問い合わせます：

Service (e.g., Scheduler)              Policy Service
         │                                    │
         │  "Can Robot A run at 2 AM?"        │
         │───────────────────────────────────→│
         │                                    │ 1. Check platform policies
         │                                    │ 2. Check app-defined policies
         │                                    │ 3. Check user-defined policies
         │  "No — time-of-day restriction"    │
         │←───────────────────────────────────│

Policy Service はすべての適用可能なポリシーを階層順に評価し、決定を返します。サービスは独自のポリシーロジックを実装しません——問い合わせて従うだけです。

問い合わせサービス	質問	ポリシーの回答
Planner	「このオーダータイプに対してどのプランニング戦略を使うか？」	緊急オーダーには優先度優先を使用する
Scheduler	「ロボットAは午前2時に稼働できるか？」	不可 — 時間帯制限が適用中
Execution Manager	「コントラクトが失敗した、次はどうする？」	1回リトライし、その後最も近い利用可能なデバイスへ再割り当て
Planner	「ロボットのバッテリーが15%、続行するか？」	不可 — プラットフォームの安全限界は20%

ドメインポリシースキーマ

アプリケーションは ドメインポリシースキーマ を登録することで、プラットフォームにドメイン固有の語彙を教えます。これにより AI Policy Agent がドメイン非依存になります：

Platform provides:              App injects:
├─ Conversational engine        ├─ Domain ontology (entities, actions)
├─ Policy syntax understanding  ├─ Domain constraints
├─ Validation logic             ├─ Available strategies
└─ Common concepts              └─ Example policies / best practices
    (devices, zones, time)

スキーマの例（倉庫ドメイン）：

{
  "domain": "warehouse",
  "entities": ["order", "pick-task", "AMR", "rack", "zone"],
  "actions": ["pick", "place", "move", "charge", "wait"],
  "strategies": ["priority-first", "proximity-first", "load-balance"],
  "constraints": ["max-carry-weight", "zone-access-level"],
  "examples": [
    "Prioritize urgent orders over standard orders",
    "Never assign more than 3 tasks to a single AMR"
  ]
}

スキーマは Marketplace からアプリケーションがインストールされるときに登録されます。AI Policy Agent は、オペレーターがそのドメインのポリシー会話を開始するときにスキーマを読み込みます。

有効化前の検証

すべてのポリシーは Policy Validator を通過しなければ有効化されません：

チェック	説明	例
競合検出	2つのポリシーが同じ入力に対して矛盾した回答を返す	「夜間にゾーンAを許可」対「午後10時以降にゾーンAを拒否」
安全オーバーライド	ユーザー/アプリポリシーがプラットフォームの安全性を低下させようとする	バッテリー閾値がプラットフォームの最低値を下回って設定される
デッドロック検出	ポリシーが循環的なブロックを生成する	AはBの完了を必要とし、BはAの完了を必要とする
カバレッジギャップ	有効なシナリオをカバーするポリシーが存在しない	タイムアウトエラーに対する障害回復が定義されていない
階層違反	下位階層のポリシーが上位階層をオーバーライドする	ユーザーポリシーがアプリ定義のプリセットと矛盾する

AI Policy Agent はオペレーターにポリシーを提案する前に検証を実行します。Policy Service は有効化前にもう一度検証を実行します。この二重検証により、エージェントがエラーを犯した場合でも、会話的に作成されたポリシーの安全性が確保されます。

会話型ポリシー作成

AI Policy Agent は2つのモードで動作します：

作成モード — オペレーターの意図を正式なポリシーに変換します：

Operator: "I want cleaning to stop during office hours on weekdays"
Agent:    "I understand. Let me create a policy:
           - Scope: All cleaning robots
           - Condition: Monday–Friday, 9 AM – 6 PM
           - Action: Suspend cleaning operations
           - Recovery: Resume at 6 PM, prioritize uncleaned areas

           I've validated this against your existing policies — no
           conflicts detected. Should I activate it?"
Operator: "Yes, but only for Floor 2"
Agent:    "Updated scope to Floor 2 only. Activating now."

監査モード — 既存のポリシーを説明し、シナリオをシミュレートします：

Operator: "What happens if a robot runs low on battery in Zone A?"
Agent:    "Based on your current policies:
           1. Platform safety: Robot must return to charging when battery
              drops below 20% (cannot be overridden)
           2. Your policy: Robots in Zone A should complete current task
              before returning to charge (applies above 20%)
           3. Result: Robot finishes the current pick, then navigates
              to the nearest charging station."

結果

メリット

• 安全保証 — アプリケーションやオペレーターが定義した内容に関わらず、プラットフォームポリシーを弱めることはできません

• ドメイン柔軟性 — 同じポリシーエンジンが、スキーマを通じて倉庫、清掃、物流、および将来のあらゆるドメインで機能します

• ノーコードカスタマイズ — オペレーターは設定ファイルやコードではなく、会話を通じて動作を調整します

• 監査可能 — すべてのポリシーはバージョン管理され、すべての決定はログに記録され、AIエージェントは任意のポリシーを平易な言葉で説明できます

• 競合防止 — 検証によりプロダクションに到達する前に問題を検出します

トレードオフ

• スキーマ設計の負荷 — アプリケーション開発者はドメインポリシースキーマを慎重に設計する必要があります。設計が不十分なスキーマは、オペレーターが表現できる内容を制限します

• 検証の遅延 — インタラクションが多い複雑なポリシーセットは検証に時間がかかります。ポリシー作成（低頻度）では許容されますが、評価パス（高頻度、決定ごと）は高速を維持する必要があります

• エージェントの精度 — AI Policy Agent は曖昧なオペレーターの意図を誤って解釈する可能性があります。二重検証（エージェント + Policy Service）によりリスクを軽減しますが、オペレーターは提案されたポリシーを引き続きレビューする必要があります

設計上の決定事項

• ポリシーはコードではなくデータ — ポリシーは実行可能なスクリプトではなく、構造化された定義として保存されます。これにより、検査・検証・説明が可能になります。

• サービスは問い合わせるのみ、決定しない — Intelligence Plane のサービスは独自のポリシーロジックを実装しません。すべての決定に対して Policy Service に問い合わせます。これによりポリシーの適用が一元化され、ドリフトを防止します。

• アプリスキーマはインストール時に注入される — スキーマは Marketplace からアプリケーションがインストールされるときに登録され、オペレーターがそのドメインのポリシー作成を試みる前にプラットフォームのポリシーインフラが準備完了していることを保証します。

例

WES — オーダー優先度ポリシー

倉庫オペレーターは緊急オーダーを優先させたいと考えています：

1. WES アプリケーションのドメインポリシースキーマは、order をエンティティとして定義し、priority を属性として、priority-first を戦略として定義します

2. オペレーターは AI Policy Agent に伝えます：「緊急オーダーは常に標準オーダーより先にピッキングされるべきだ」

3. エージェントはポリシーを作成します：IF order.priority = "urgent" THEN strategy = priority-first

4. Validator はチェックします：プラットフォームポリシーとの競合なし、既存のアプリ定義ポリシーとの競合なし

5. ポリシーが有効化されます

6. Planner が「このオーダーにどの戦略を使うか？」と問い合わせると、Policy Service は緊急オーダーに対して priority-first を返します

ClearJanitor — 時間帯制限

ビルのオペレーターは夜間のみ清掃を実施したいと考えています：

1. ClearJanitor スキーマは cleaning-robot をエンティティとして定義し、time-window を制約として定義します

2. オペレーターは言います：「平日の午前8時から午後7時の間は清掃禁止」

3. エージェントは時間条件を含むスコープ付きポリシーを作成します

4. Validator はチェックします：これは最低清掃頻度を要求するプラットフォーム安全ポリシーと競合しない（そのようなポリシーが存在する場合）

5. Scheduler が「このロボットは午後3時に2階を清掃できるか？」と問い合わせると、Policy Service は「不可 — 時間帯制限」を返します