USE SAAS
API-first SaaS
作るべきでないものは、成熟したSaaSを使う。
予約、POS、決済、会計、ECの中核は、自作するほど安全とは限りません。重要なのは、SaaSを使うかどうかではなく、CLI/API/Export、権限、運用責任、会社に残す判断基準を先に切ることです。
USE SAAS
予約 / POS
既に実績のある予約、POS、店舗オペレーションの中核は、まず成熟ツールを検討します。
USE SAAS
決済 / 会計
支払い、請求、会計、税務は専門SaaSと専門家の責任範囲を尊重します。
USE SAAS
EC / 専門業務
EC、業界特化SaaS、法令や安全性が絡む領域は、自作より既存ツールが安全です。
CHECK FIRST
SaaS採用前に確認すること
CHECK FIRST
API
必要なデータと操作がAPIで扱えるか。
CHECK FIRST
Export
契約終了後もデータを取り出せるか。
CHECK FIRST
Permission
スタッフ、店長、オーナーの権限を分けられるか。
CHECK FIRST
CLI / Logs
GUI操作に閉じず、設定、ログ、更新手順をエージェントが追えるか。
REJECT
GUIしか触れないSaaSは、中核構造にしない。
REJECT
使ってよいSaaS
成熟していて、API、Export、監査ログ、権限、サポート境界が確認できるもの。専門領域の責任はそのSaaSに残します。
REJECT
主力から外すSaaS
管理画面のクリック手順でしか作れず、設定をGitやコードに残せず、エージェントが検証・再現できないもの。
BOUNDARY
SaaSで足りない時だけ、次のルートへ進む。
BOUNDARY
Agent-operable Tool
社内の判断基準、FAQ、教育、日報、例外対応など、SaaSに入らない会社の記憶を保守可能な社内ツールにします。
Agent-operableを見るBOUNDARY
Client-Owned Deployment
顧客向けUI、独自DB、複数拠点、権限、顧客所有環境への移管が必要な時だけCloudflareへ進みます。
Cloudflareを見るSTART
自作しない範囲を決めることも、診断の成果です。
作る前に、SaaSで十分な領域、APIでつなぐ領域、会社側に残す記憶を分けます。