I-S3 Software Division
RightOS + RightFlow — 概念と使い方
「担当になった」≠「入ってよい」。Physical AI が増える現場の境界レイヤを、1分で。
1分で
RightOS — 何をしてよいか？
RightFlow — 次に何が起きるべきか？
実行系 — 実際にどう実行するか？
RightOS と RightFlow は、参加アクターを中央で全部支配しません。独立したアクター・権威・実行系のあいだの非同期協調のための分離です。
- RightOS — 何をしてよいか？
- RightFlow — 次に何が起きるべきか？
- 実際にどう実行するか？
どのように分かれたか
- ある場所で待つ一時的な権利を人が持てる
- 機械検証可能な系がその権利を表現・検証できる
- 入場・利用・予約・実行の権利にも同じ考えを広げられる
- 多数のアクターが仕事を持つと、権利だけでは足りない
- 順序・割当・委任・再割当・交換が必要になることがある
- 協調は、黙って権威を作り出してはならない
- だから権利の権威と協調を分ける → RightOS + RightFlow
RightOS とは？
権利・ポリシー・証明のレイヤです。氏名や電話番号を必須にせず、権利（Right Token）を発行・検証・消費・失効・譲渡できます。
タクシー／配車アプリではありません。車両手配・運賃・ドライバー割当は行いません。
RightFlow とは？
協調レイヤです。タスク・能力・割当提案（割当／再割当／交換）・依存・実行状態を扱います。
マーケットプレイス、フリート管理、ロボット制御、決済ではありません。権利は書き換えません。
なぜ分けるのか？
許可と作業順序は別の時計で変わります。割当済みでも権利は失効しえます。最適化器は良い案を出せても権威は持てません。
独立アクターの問題
病院を想像してください。病院管理、薬局システム、ロボット運用会社A/B、AI協調、職員、建物入退。所有者もソフトも権威も共有しません。
RightOS は「してよいか」を表し検証します。RightFlow は「次に何が起きるべきか」を協調します。実際の実行は各実行系の責任です。
用語（簡潔）
アクター＝能力を持ちタスクを引き受けうる参加者（人・AI・ロボット・車両・ソフト・組織）。
能力＝できることのラベル（権利ではない）。権利＝「してよい」の認可。タスク＝起きるべき作業。提案＝未コミットの割当案。
権利が変わったら？
割当 ≠ 永続認可。ポリシーが求めるなら実行前に再確認します。緊急停止は通常の協調を待たず、事後に調和します。
外に残るもの
モータ制御、航行、衝突回避、緊急停止、ベンダー制御、臨床即時割込み、市場・入札、配車・運賃は実行系などの責務です。
いつ使う／使わない
RightOS のみ: 権利の発行・検証・証明が主で、多アクター割当が不要なとき。
両方: 独立アクターがタスクを協調し、権威は別管理のままにしたいとき。
どちらも不要: ロボットやAIやキューがあるから、という理由だけでは入れない。単一権威が許可＋ワークフロー＋実行を既に持つなら、単純な設計を選ぶ。
何が作れるか（例）
待合・受取（RightOS・対応パターン）。軽量物流の再割当（概念／対応）。マルチベンダーロボット、病院搬送、荷捌き場（概念例）。
EV充電の権利＋タスク再割当、AI委任、人/AI/ロボット、独立ソフトウェア同士。
上記は設計パターンの例です。顧客事例ではありません。
適用の見極め
“一つの権威を共有せずに協力しなければならない、独立アクターは誰か？”
- 独立アクターは誰か？
- 各許可は誰が握るか？
- タスク存続中に許可は変わりうるか？
- 別アクターがタスクを引き継げるか？
- 最適化器は権威なしで提案できる必要があるか？
- 実行は別システムか？
- タスクは1リクエストより長く生きるか？
- 複数組織か？
境界契約（平易）
- 割当 ≠ 永続認可
- 最適化 ≠ 権威
- 安全は通常協調を迂回してよい
- 権威の不一致は隠さない
次の一歩
判断の境界は Decision Guide と Architectural Scope に詳しく書いてあります。