Perko | 主な実績

運用上の課題

独立した地域事業者では、顧客体験、注文、人員、在庫、日々の管理が別々のツールに分かれがちです。この分断により、業務の引き継ぎや検証が難しくなります。

KuanはPerkoを、顧客向けマーケットプレイス、店舗体験、スタッフ業務、オーナー管理、本番インフラを一つの記録でつなぐマルチテナント運営システムとして構築しました。

パイロットの根拠: 2026年9月10日のリリース判定記録は、Solid Coffeeで受け入れられた一つのスタッフ業務フローを保持しています。全モジュールの本番稼働を意味しません。
過去のDB基準値: 2026年9月1日の展開記録には7テナント、15拠点、818件の注文レコードが保存されています。稼働顧客数、営業拠点数、有料需要の証明ではありません。
範囲: 終日運用の継続、決済代行、税務用レシート処理、独立した顧客需要は、この事例では立証していません。ゲスト注文はリポジトリに実装されていますが保留中です。

アプリケーション: ReactとTypeScriptによるレスポンシブWeb・PWA画面、iOSとAndroid向けのCapacitorシェル。
APIとデータ: Fastify APIとPostgreSQL 17。追記型のイベントと台帳で運用履歴を保持。
アーキテクチャ: 自社管理のモジュラーモノリス。テナント、ID、認可、監査、モジュールの共通カーネルが、顧客、スタッフ、オーナー、運営者向けチャネルを支えます。
本番ランタイム: Caddy配下のDocker Compose。Web、API、PostgreSQLを分離し、暗号化バックアップ、復元確認、単一APIライターを運用。

事業者ごとにフォークせず、一つのプラットフォームを構成する: 一つのリリースとスキーマで複数テナント・拠点を運用します。モジュール、業種別ブループリント、国別パックで構成を変え、顧客別コードベースを増やしません。
業務上の正をサーバーに置く: 注文、在庫、資金、人員、権限はPostgreSQLが管理します。クライアント状態や外部プロバイダーは投影またはアダプターであり、正規記録を暗黙に置き換えません。
履歴を上書きせず、由来を残す: 重要な変更にはテナント、拠点、実行者、端末、時刻、冪等性、再試行系譜を保持します。訂正は保護された履歴を編集せず、補償事実として追記します。
ID、所属、財務責任を分離する: 認証ID、顧客メンバーシップ、スタッフ割当は別の概念です。注文と特典債務は発生元の事業者・拠点を保持し、ネットワーク全体で混在させません。
運用上の正が不明な場合は閉じて失敗させる: モジュール利用は、権利、稼働設定、準備状態、ロールアウト、権限を個別に検証します。未対応のオフライン決済や未解決の財務・同期状態は、可視化したまま処理を止めます。