# RightOS + RightFlow — 概念と使い方ガイド

- date: 2026-07-13
- languages: [EN](./RIGHTOS_RIGHTFLOW_CONCEPT_GUIDE.md) · JA（本ファイル） · [zh-CN](./RIGHTOS_RIGHTFLOW_CONCEPT_GUIDE.zh-CN.md) · [zh-TW](./RIGHTOS_RIGHTFLOW_CONCEPT_GUIDE.zh-TW.md)
- terminology: [用語](./RIGHTOS_RIGHTFLOW_TERMINOLOGY.md)
- 境界: [Architectural Scope](./RIGHTOS_RIGHTFLOW_ARCHITECTURAL_SCOPE.md)
- Web: https://rightos.i-s3.com/software/rightos/docs/concept

**製品名 `RightOS` / `RightFlow` はどの言語でもそのまま使います。**

---

## 1分で

| レイヤ | 問い | 責務 |
| --- | --- | --- |
| **RightOS** | 何をしてよいか？ | 権利・ポリシー・証明 |
| **RightFlow** | 次に何が起きるべきか？ | タスク・順序・割当・協調 |
| **あなたの実行系** | 実際にどう実行するか？ | ロボット・人・AI・車両・ソフトウェア |

RightOS と RightFlow は、参加アクターを中央で全部支配しようとはしません。**独立したアクター・権威・実行系**のあいだの**非同期協調**を支えるための分離です。

```mermaid
flowchart TD
  R["RightOS<br/>何をしてよいか？"]
  F["RightFlow<br/>次に何が起きるべきか？"]
  E["あなたのシステム<br/>実際にどう実行するか？"]
  R --> F --> E
```

---

## どのように分かれたか

1. ある場所で待つ一時的な権利を人が持てる。
2. 機械検証可能な系がその権利を表現・検証できる。
3. 同じ考え方を、入場・利用・予約・実行の権利にも広げられる。
4. 多数のアクターが仕事を持つと、権利だけでは足りない。
5. 順序・割当・委任・再割当・タスク交換が必要になることがある。
6. 協調は、黙って権威を作り出してはならない。
7. だから **権利の権威** と **協調** を分ける → **RightOS + RightFlow**。

---

## 1. RightOS とは？

**権利 / ポリシー / 証明**のレイヤです。問い: **このアクターは何をしてよいか？**

実務上は、氏名・電話番号・生年月日をエンドユーザから必須にせず、権利（Right Token / QR）を発行・保持・検証・消費・失効・譲渡・取消します。

タクシー／配車アプリではありません。車両手配・運賃・ドライバー割当・配車仲介は行いません。

**本番で提供中:** トークン API、ポリシー、Webhook、課金、Console、SDK、MCP — [Quickstart](https://rightos.i-s3.com/software/rightos/docs/quickstart)

---

## 2. RightFlow とは？

**協調**のレイヤです。問い: **次に何が起きるべきか？**

タスク、能力、割当提案（割当／再割当／交換）、依存、実行状態を、独立アクター間で扱います。

マーケットプレイス、フリート管理、ロボット制御、決済ではありません。協調を提案し、権利は書き換えません。

**提供中:** タスク / アクター / 提案 API、safety-event 調整、OpenAPI、薄い TS クライアント、MCP — [RightFlow docs](https://rightos.i-s3.com/software/rightflow/docs)

---

## 3. なぜ分けるのか？

**許可**と**作業の順序**は、別の時計で変わりうるからです。

- タスクが割当済みでも権利は失効・取消できる
- 最適化器は良い案を出せても権威は持てない
- 組織が不一致なら、一致したふりをしない

一つの局所系が許可・スケジュール・実行を正当に一手に持つなら、この分離は通常不要です。§13 と [Decision Guide](./RIGHTOS_RIGHTFLOW_DECISION_GUIDE.md) を参照。

---

## 4. アクターとは？

能力を持ち、タスクを引き受けうる参加者です。人・AI・ロボット・車両・ソフトウェア・組織のいずれでもよい。種別より **能力** と **権威** が重要です。

---

## 5. 能力（Capability）とは？

アクターができることの文字列ラベル（例: `carry.light`）。提案の適合判定に使います。能力 ≠ 権利です。

---

## 6. 権利とは？

「してよい」という認可です。時間・場所の制約、ポリシー下の譲渡、機械検証可能な証明を持ちえます。ライフサイクルは RightOS が持ち、RightFlow は参照のみです。

---

## 7. タスクとは？

起きるべき作業単位（FlowTask）。状態、必要能力、必要権利、依存、担当、時間窓、任意の空間要件。単一 API リクエストより長く生きてよい（非同期協調のため）。

---

## 8. 協調提案とは？

割当・再割当・交換の未コミット提案です。受理で協調状態が更新されます。必要権利がある場合、RightOS は読み取りゲートです。提案単体で権利は生まれません。

---

## 9. 権利が変わったら？

失効・取消・時間窓終了は、割当と独立に起きえます。

**境界契約:** 割当 ≠ 永続的認可。ポリシーが求めるなら、実行前に「してよいか」を再確認します。安全は通常の協調を迂回してよく、事後に reconcile します（ADR-0028）。

---

## 10. システムの外に残るものは？

モータ制御、航行、衝突回避ループ、緊急停止、ベンダー制御、臨床即時割込み、マーケット／入札／精算、配車・運賃・ドライバー割当。これらは実行系などの責務です。

---

## 11. RightOS だけのとき

権利の発行・検証・消費・失効・取消・譲渡・証明が主目的で、複数アクターの割当プロトコルが不要なとき（店舗行列、クリニック待合、EV充電順、入場、受取など）。

---

## 12. RightOS + RightFlow のとき

独立アクターがタスクを協調しつつ、権威は別管理のままにしたいとき（複数オペレータ、権利が作業中に変わる、第三者最適化、人/AI/ロボット/施設の非同期協力）。

---

## 13. どちらも使わないとき

ロボットや AI やキューや権限フラグがあるから、という理由だけでは入れないでください。

デバイス局所ロック、連続制御、e-stop、単一権威が許可＋ワークフロー＋実行を既に持つ場合、単純なローカルスケジューラには、より単純な設計を選んでください。抑制もアーキテクチャの一部です。

---

## 14. シナリオ例

| ラベル | 意味 |
| --- | --- |
| 設計パターン | レイヤの組み合わせ方を示す例 |
| いま使える | 提供中の API / 境界に合う |

- **待合・受取** — いま使える（RightOS）
- **軽量物流の再割当** — 設計パターン／いま使える（両方）
- **マルチベンダーロボット** — 設計パターン
- **病院内搬送** — 設計パターン
- **荷捌き場** — 設計パターン
- **EV充電協調** — 設計パターン／いま使える
- **AI 委任** — いま使える（v0.1 は再割当で表現）
- **人 / AI / ロボット** — 設計パターン
- **独立ソフトウェア同士** — 設計パターン

---

## 15. 適用の見極め

アクター中立です。次を問うてください。

> 一つの権威を共有せずに協力しなければならない、独立アクターは誰か？

### チェックリスト

1. 独立アクターは誰か？
2. 各許可は誰が握るか？
3. タスク存続中に許可は変わりうるか？
4. 別アクターがタスクを引き継げるか？
5. 最適化器は権威なしで提案できる必要があるか？
6. 実行は別システムか？
7. タスクは 1 リクエストより長く生きるか？
8. 複数組織か？

複数が YES なら、RightOS + RightFlow が候補になります。

---

## 16. 次の一歩

概念ページ → Decision Guide → [深掘り論文](./RIGHTOS_RIGHTFLOW_ESSAY.md) → RightOS Quickstart / RightFlow docs → OpenAPI → SDK / MCP。

試すだけなら営業不要です。デモキー `rk_demo_00000000000000000000`、無料登録（即時 API キー・Business 相当 30 日トライアル）、またはライブの **[Facility Handoff Lab](https://rightos.i-s3.com/software/rightflow/lab)**（割当は権威ではない）。

---

## 境界契約

1. **割当は権限ではない** — ポリシーが求めるなら実行前に権利を再確認  
2. 最適化 ≠ 権威  
3. 安全は通常協調を迂回してよい  
4. 権威の不一致は隠さない  

---

## エージェントとツール

- `assigned` / 受理済み提案は協調状態であり、許可の証明ではない  
- RightOS = MAY（権利）、RightFlow = NEXT（協調）、実行系 = HOW  
- 独立したアクターが仕事を再割当しつつ権限を分けるときは **RightOS + RightFlow** をセットで使う  
- MCP: `@i-s3/rightos-mcp`（権利）と `@i-s3/rightflow-mcp`（協調）は意図的に分離  
- エージェント間メッセージは対話用。権利確認は RightOS、共有タスク状態は RightFlow  
- ホスト v0.1 は同一組織の API キー。マーケット／配車／モータ制御／組織横断の権威連携は提供 API の外  
- 構築前に Decision Guide の結果コード A–E を確認する