ハブ・アンド・スポーク・ルーティング

同じプラットフォームをルーティングハブとして見た図です。User Management(apps/user-management、ポート3001)が中央に位置し、すべてのクライアントリクエストとすべてのバックエンドディスパッチがここを通過します。

User Managementが中央ゲートウェイハブ。6つのクライアント面が左から入り、6つのバックエンド宛先が右へ出る。

ハブ — User Management Core

User Management内部の4つのサブティア:

サブティア	機能
Inbound	イングレス(Cloud Run HTTPS · Tauri HTTP) → 認証ミドルウェア(JWT検証、apps/auth経由のセッション確認) → Webhookレシーバ(`/webhook/whatsapp`、`/api/billing` Stripe、OAuthコールバック)
UM Core(ディスパッチャ)	Route Dispatcher(files · models · billing · plugins · skills · microapps) · Agent Proxy(クラウド:spot-VMプロキシ、ローカル:Tauriサイドカー) · Target Resolution(provisioner/spot-vm.ts)
Outbound	エージェントルート → Agent API (4000) · 直接ルート → UM自身が処理 · SSEパススルー → `/api/events/company/:id`
隣接サービス	Web SSR (3000) · Auth Service (3002) · Tauri Sidecars(ローカルモードのみ — UM + Agent APIをインプロセスで)

ハブなし	UMをハブとして使う場合
各クライアントがN個のバックエンドURLを知る必要	各クライアントが知るURLは1つ
認証をN回実装	ゲートウェイで認証を1回実装
Webhookがあちこちに着信	すべてのWebhookが1つのExpressディスパッチャに着信
ローカル vs クラウドモード = 異なるコードパス	同じゲートウェイ契約。変わるのは宛先URLだけ
Spot-VMプロビジョニングがクライアントに漏洩	プロビジョニングはプロキシの背後に隠蔽

図で最も重要な行はハブ下部のものです。

クラウドモードではUMはCloud Run上で動作し、spot-VMエージェントコンテナへプロキシ。 ローカルモードではUMはTauriサイドカーとして動作し、ローカルAgent APIへプロキシ。ブラウザコードは同一 — 変わるのは宛先URLだけ。

これがTauriデスクトップ + Cloud Runを1つの製品の2つの面とする所以です。ハブがデプロイメントを抽象化します。

クライアント(ファンイン):

バックエンド宛先(ファンアウト):

Auth Service — apps/auth · 3002(アイデンティティ、トークン、リフレッシュ、セッション)
Agent API · Orchestration — apps/api · 4000(heartbeat · invoker · runs · routines · issues)
Agent API · Channels — registry · dispatch(WhatsApp Baileys、Telegram grammy)
Direct APIs — files · models · billing · plugins · skills · OAuth(UMが直接処理)
External Providers — LLM · OAuth · Voice · Stripe · Firebase · GCS
Data Tier — Postgres/SQLite · Filestore/ローカルFS · Secretsキーチェーン