# 割当は権限ではない ### 非同期・多主体協調のための権利分離という見方 - languages: [EN](./RIGHTOS_RIGHTFLOW_ESSAY.md) · JA（本ファイル） · [zh-CN](./RIGHTOS_RIGHTFLOW_ESSAY.zh-CN.md) · [zh-TW](./RIGHTOS_RIGHTFLOW_ESSAY.zh-TW.md) - date: 2026-07-14 - updated: 2026-07-17（読者向け概略・キャッチを追加。厳密性は維持） - 短い資料: [概念ガイド](./RIGHTOS_RIGHTFLOW_CONCEPT_GUIDE.md) · [判断ガイド](./RIGHTOS_RIGHTFLOW_DECISION_GUIDE.md) · [Architectural Scope](./RIGHTOS_RIGHTFLOW_ARCHITECTURAL_SCOPE.md) - Web: https://rightos.i-s3.com/guides/RIGHTOS_RIGHTFLOW_ESSAY.ja.md - 体験: [Facility Handoff Lab](https://rightos.i-s3.com/software/rightflow/lab) · [RightFlow](https://rightos.i-s3.com/software/rightflow) --- ## 30秒でつかむ（厳密なキャッチ） > **「担当になった」≠「入ってよい」。** > Physical AI が増える現場で先に効くのは、脳ではなく**境界**。 | 層 | 問い | 置かないもの | | --- | --- | --- | | **RightOS** | してよいか（MAY） | — | | **RightFlow** | 次は誰か／何か（NEXT） | 金銭・配車・権利の再定義 | | **実行系** | どう動くか（HOW） | （航行・制御・急停はここ） | - **局所優先:** 高頻度の進捗や制御の内部は各実行系に残し、共有するのは提案・割当・端末状態など協調事実だけ。 - **Physical AI との関係:** 本稿の対象は Physical AI そのものではない。それが多数並ぶ環境で重要になる、許可と次の一手の分離である。 - **ライブで見る:** [Facility Handoff Lab](https://rightos.i-s3.com/software/rightflow/lab)（遅延→封鎖で停止→権利修復→完遂） --- ## 要旨 人・機械・ソフトウェアのあいだで仕事を動かす多くの系は、ふたつの問いを一つの記録へ押し込む。あるアクターが行為してよいか、そして次に何をするべきか、である。政策・ワークフロー・実行を一つの組織が握るなら、この圧縮は便利だ。所有者が分かれ、スタックが分かれ、許可の失効時刻がタスクの寿命と揃わない瞬間から、圧縮はもろくなる。 本稿は **RightOS** と **RightFlow** が用いる作業上の切り分けを展開する。RightOS は「何をしてよいか」（権利・ポリシー・証明）に答える。RightFlow は「次に何が起きるべきか」（タスク・順序・割当・再割当・交換・依存・実行向け状態）に答える。実行系は「どう実行するか」に答える。表題の命題——**割当は権限ではない**——は安定条件である。仕事の引き継ぎを協調しても、黙って許可を作ってはならない。 認可エンジン、ワークフロー、マルチロボット割当、エージェント間メッセージング——周辺の要素はいずれも長い系譜を持つ。本稿は各要素そのものの新規性を主張しない。主張するのは、権利権威と協調状態を分離可能な層に置き、負の適用域を明示しておくことが、非同期かつ権威横断の協調にとって有用であり、層の混同が危険な設計の反復源だということである。 --- ## 1. ワークフローに見える問題 薬局システム、二つのロボット運用会社、入退管理、AI スケジューラ、人の監督が、同じ搬送に触れる施設を想像してほしい。各自が自分のソフトウェアを持つ。各自が「自分が認可してよいこと」を別に持つ。遅れが出る。誰か——あるいはモデル——が、A が始めた仕事を B に継がせる案を出す。 同時に三つの問いが来る。 1. B はその場所・時刻で作業してよいか。 2. 未完の仕事を B に再割当すべきか。依存はどうなるか。 3. B は実際にどう航行し、掴み、止まるのか。 一つのフリートが三者を専有するなら、一つの製品の内側で答えられる。所有者が共有されないなら、問いまるごと融合した瞬間、なじみ深い失敗が出る。最適化器が書いた割当が許可に見える。緊急停止が通常の cancel 扱いになる。失効した権利の下に「割当済み」タスクが残る。権威同士の不一致が成功として丸められる。 建築上の手は述べると単純で、守り続けるのは難しい。**許可**と**協調**を寿命の違う別オブジェクトとして扱い、**実行**はトルクと遅延と局所危険を感じる系に残す。 --- ## 2. 三つの問い、三つの時計 | 層 | 問い | 典型的な寿命 | 典型的な所有者 | | --- | --- | --- | --- | | 権利（RightOS） | 何をしてよいか | ポリシー窓・失効・譲渡・期限 | 施設、臨床、管理者 | | 協調（RightFlow） | 次に何が起きるべきか | タスク視野・提案の受理／拒否 | 計画系、監督、対等エージェント | | 実行 | どう実行するか | 制御ループ、秒以下 | ベンダー制御、ロボット、局所アプリ | 時計は重要だ。タスクが開いたまま権利が切れうる。権利が残ったままタスクだけが渡りうる。提案が終わる前に安全割込みが来る。`割当済み＋許可` を一つのフラグに閉じ込めれば、物理が起きるまでズレは見えない。 RightOS と RightFlow は、そのズレを隠さず名付ける試みである。 --- ## 3. 「割当は権限ではない」が禁じること 日常語では、仕事を「割当」れば誰かに「権限を与えた」ように聞こえる。その含意こそ、このアーキテクチャが拒むものである。 ここでの境界契約では次のとおりである。 - 協調提案の受理は**協調状態**を更新する。権利を発行しない。 - 最適化スコアの高さは認可ではない。 - 能力ラベル（できること）は、権利（いま許されていること）と同じではない。 - ポリシーが求めれば、提案を数分前に受理していても、実行直前に権利を再確認する。 これは文書作法ではない。協調 API が意味してよい範囲の制約である。受理が許可を含意すれば、あらゆる計画器が偶発的権威になり、侵害された計画器は偶発的な権限昇格装置になる。 --- ## 4. 層を分けたまま話せる語彙 議論に足りる語彙は小さい。製品名は意図的に英語のまま残す。残りは共有用語に従う。 **アクター。** 能力を持ちタスクを引き受けうる参加者——人、AI、ロボット、車両、施設サブシステム、組織エンドポイント。製造元やランタイムの共有は必須ではない。 **能力（Capability）。** 「軽い荷物を運べる」といった適格性。能力は権利ではない。権利を失っても能力記述が消える必要はなく、能力を得ても権利は生まれない。 **権利（Right）。** 「してよい」ことの機械表現可能な認可。有効・失効・譲渡・証明を伴う。RightOS では、不要な本人情報を集めずに提示できる Right Token として現れることが多い。 **タスク。** 起きるべき作業単位。一回の要求より長く生き、依存を持ち、能力と権利参照を要求しうる。 **提案（Proposal）。** 割当・再割当・交換の、未コミットな案。受理と拒否は協調の遷移であって、権利発行ではない。 この語彙があれば、「B は能力を持ち受理済み提案もあるが有効な権利がない」は整合した状態であり、存在論の誤りではない。融合型設計は、その状態を嘘なしに表しにくい。 --- ## 5. 先行文献の隣人——隣人が代替にならない理由 周辺が空いているなどと偽ってはいけない。認可には XACML、OAuth/OIDC、関係ベース認可、能力トークン、利用制御研究がある。協調と割当には BPMN や耐久ワークフロー、Linda 系、オークション型マルチロボット割当、Open-RMF 系の施設ロボティクス、エージェント間タスク規約がある。ツール接続（MCP など）は対等対話の横に並ぶ。 その地図を俯瞰すると、型が繰り返す。強い**認可**製品は、主体中立の再割当プロトコルを第一級の主題にしないことが多い。強い**協調**製品は、実行直前に再確認すべき機械検証可能な権利を別権威として扱わないことが多い。垂直統合のフリート／FMS は割当と交通と制御を束ね——一つのベンダー境界では有効でも、独立権威の横断には弱い。 ゆえに建築上の興味は「タスクを発明した」でも「ポリシーエンジンを発明した」でもなく、**権利分離型の協調**にある。MAY 層と NEXT 層を潰さない。金銭と物理制御を協調コアに載せない。配車語彙を許可の別名にしない。 権利検証だけが要る読者は RightOS で足りる。単一所有のワークフローだけなら、単純な統合設計のままがよいことが多い。両方を組む設計に家賃が発生するのは、権威の独立が現実であるときである。 --- ## 6. 正の適用域と負の適用域 有用なアーキテクチャには、行ってはならない場所がある。 **正の適用域。** 独立したアクターと権威のあいだの非同期協調。タスクが一コールより長く生き、許可が仕事存続中に変わり、第三者の最適化器が認可を持たずに提案し、実行スタックは外に残る。 **負の適用域。** 秒以下の安全と連続制御。デバイス局所の排他。許可・ワークフロー・実行をすでに一つの正当な所有者が持つ場合。市場・入札・精算を協調の本性とする設計。権利証明であるかのごとく振る舞う配車・運賃決定。 負の適用域は広告の但し書きではない。理論の一部である。e-stop が要るなら、豊かな提案オブジェクトではなく実行側コントローラが要る。競売清算が要るなら、権利を見失った協調の比喩的「bid」ではなく市場系が要る。一つの SaaS が世界を握っているなら、分離は装飾になりうる。 --- ## 7. 融合の失敗様式 層が融けるとき、よく四つの失敗が出る。 1. **許可ロンダリング。** 割当記録がのちに「許可済み」として読まれる。誰が何を授けたのか監査できない。 2. **最適化主権。** 計画品質が権威の代用品になる。もう決まった、という理由で失効経路が飛ばされる。 3. **安全の待ち行列化。** 緊急行動が通常の提案合意を待つ。 4. **沈黙した衝突。** 権威が食い違うのに、強い側の好みで成功を返す。部分失敗が見えない。 権利分離型協調は衝突を消さない。衝突を表現可能にする。未確定、拒否された提案、生きたタスクの下の失効権利。可視性は設計目標であり、丁寧さのオプションではない。 --- ## 8. エージェント、ツール、対話 いまのエージェント構成は、ツール呼び出しと対等対話を分けがちである。その分離自体は健全でも、**共有タスク状態**と**独立に失効しうる権利**がどこに住むかは未解決のまま残る。 実用的な組み合わせは次のとおりである。 - ツール規約で RightOS / RightFlow API を呼ぶ。 - エージェント間メッセージで交渉と説明を行う。 - 権利確認は権利レイヤに置く。 - 受理済み割当は協調レイヤに置く。 - モータ・航行・局所割込みは実行系に置く。 これらを一つの「中央エージェント」へ畳み込めば、親しみやすい看板の下で単一権威の錯覚が戻る。本アーキテクチャはこの点でわざと地味である。地味さは、特権行為が会話に便乗しないために要る。 --- ## 9. ホスト実装とその限界 RightOS と RightFlow はホスト API とパッケージとしても存在する。ホスト v0.1 は組織ごとの一つの API キーを用いる。組織横断の権威連携はその実装ではまだない。短いガイドの概念例は設計パターンの図示であり、顧客導入の全数ではない。 限界を論ずるのは、建築とプロダクトを混同してはならないからである。移動するのは区別（MAY / NEXT / HOW、割当≠権限）である。誰がどの権威をホストし、どう連合証明するかは後続の契約であって、協調レイヤが割当の意味を水増しして発明するものではない。 --- ## 10. 短い資料との読み分け | 欲しい深さ | 読むもの | | --- | --- | | 1分の方位 | [概念ガイド](./RIGHTOS_RIGHTFLOW_CONCEPT_GUIDE.md) または概念ページ | | 使うべきか | [判断ガイド](./RIGHTOS_RIGHTFLOW_DECISION_GUIDE.md) | | 規範的境界と未完 | [Architectural Scope](./RIGHTOS_RIGHTFLOW_ARCHITECTURAL_SCOPE.md) | | 共有用語 | [用語集](./RIGHTOS_RIGHTFLOW_TERMINOLOGY.md) | | 論証と動機 | 本稿 | --- ## 11. 結び 独立アクターのあいだの仕事は増え続ける。建物の中のベンダーが増え、人の隣にソフトウェアエージェントが増え、タスクボードと無関係に切れる権利が増える。便利な記録を許可の代わりにする誘惑は消えない。 **割当は権限ではない**は、便利さが認可ではないという注意書きである。RightOS と RightFlow は、その注意書きを建築の内側に留める一つの規律あるやり方である。問いを分け、時計を名指しし、負の適用域を公開し、実行の仕方は実行できる系に委ねる。 --- ### サイト上の続き - 概念（Web）: https://rightos.i-s3.com/software/rightos/docs/concept - RightFlow: https://rightos.i-s3.com/software/rightflow - RightFlow OpenAPI: https://rightos.i-s3.com/rightflow-openapi.json - RightOS OpenAPI: https://rightos.i-s3.com/openapi.json