24/7 AI エージェント運用で SaaS スタートアップが踏むべき 5 つの判断ルール — 執行境界・BAN リスク・OAuth guardrail・可逆性 diff・blanket 承認

単独創業の SaaS スタートアップが AI エージェントを 24/7 で回そうとする時、3 ヶ月で頓挫するか、代表 1 人分以上のレバレッジを取れるかは、初期に決めておく判断ルールで大きく分岐します。 頓挫の代表例は、代表が「一つひとつの実装 diff を個別承認する」運用に戻ってしまい深夜に起きて approve する暮らしになる、あるいは逆に blanket approve しすぎて BAN cascade や決済系事故を踏み抜く、の 2 パターンです。 Xiora では 2026-07-19 の 1 セッションで、Stripe MCP 再接続・Gourmie 3 tier product の実 write・brain runtime handler の追加・Vercel deploy・6 SEO 記事の PR / merge flow を 1 日で消化しましたが、その中で言語化された 5 つの判断ルールを、実運用の落とし穴とセットで共有します。

ルール 1: 執行境界を先に 3 分類で定義する

AI エージェントに何をさせるかを議論する時、「執行」と「非執行」を単純な二分法で切ると、「PR draft 作成は執行か？」「commit だけは非執行か？」で毎回止まります。 実運用では 3 分類に分けておくと判断が速いです: (a) 実 write = 実際に生産環境の state を変える操作 (例: git commit + push、DB への insert、決済 API 経由の write、外部 SaaS へ publish)、(b) communication = draft / preview 生成にとどまり生産環境に到達しない (例: PR body draft、レビュー comment draft、メール draft の Gmail Drafts 保存)、(c) read-only = 状態を一切変えない (例: git log 読み取り、API の GET、file の read)。 (c) は default 全自動、(b) は draft は自動生成・送信可否は代表判断、(a) は憲法 5 条 (5 種の hard gate: billing / delete / permission / contract / kyc) に該当するもののみ代表承認、それ以外は blanket approval の scope 内で自動、という運用に統一できます。 Xiora HP の SEO 記事 PR / merge flow でも、代理人が draft 作成 + commit + push + gh pr create まで実行し、代表が GitHub 上の merge click だけを担う分業になっており、5 記事分の PR を 1 日で消化できています。

ルール 2: BAN リスク資産を tiered 管理する

24/7 エージェント運用で見落としがちなのが「一つの Google アカウントが停止した時にどこまでの資産が同時に失われるか」の見積もりです。 個人 Gmail 1 つに事業の credential を全部通していると、AdSense 違反 1 回で決済・広告・分析・メール・DNS・Cloud すべてが同時に凍結する、いわゆる cascade BAN が起こり得ます (参考: Google Terms of Service、Anthropic Usage Policies)。 対策は、アカウントを 3 tier に分けて、エージェントに触らせる範囲を明示的に指定することです: (a) 業務用サブアカウント (例: 事業運営専用の Gmail で、Stripe / GCP / GA4 / Vercel など高リスク SaaS を紐付ける) は「BAN されても事業の別 tier に影響しない sandbox 資産」として代理人が API 経由で自由に write、(b) 会社 main アカウント (info 系や公開 outreach 用) は代理人が read + draft、送信は代表 or 明示的な blanket approval 内で、(c) 代表本人アカウント は default 使用禁止で、緊急時のみ代表本人が使う、という table を代理人と共有しておきます。 Xiora の Stripe 決済も、Xiora ブランド用の新規 Stripe account を業務用サブアカウント側で開設し、代表本人アカウントには送金導線を通さない構造にしています。 tier table を明示化しておくと、代理人の judgement 時間が明確に短縮されます。

ルール 3: OAuth guardrail の 60 秒 runbook を標準化する

MCP や API 経由でエージェントが外部 SaaS を叩く時、認証切れやトークン期限で処理が止まるのはよくあります。 ここで guardrail (許可判定ロジック) が「未認証だから触るな」と block した場合、エージェント側は「動かないから止まる」ではなく「動かないから代表に 60 秒依頼して回す」の型に落とすのが要点です。 具体的には、(1) block を受けたら stop condition と reason を state DB に記録、(2) 代表への通知メッセージに「revoke → 新 OAuth → account 選択」の 3 step + 想定所要 60 秒 の runbook を同梱、(3) 代表が実施したら override 済 memory を書いて処理再開、という 3 step です。 Xiora の Stripe MCP 再接続でも、Xiora org 配下に account が 2 つある状態 (kigen 系と Xiora メイン系) で「どの account に接続するか」を明示的に指定できず一度 block、代表が Web UI で account 選択して再接続した後、代理人側は再度 mcp__plugin_stripe_stripe__get_stripe_account_info を叩いて疎通確認、という形で 60 秒経路が回りました (参考: Stripe API Keys documentation、Model Context Protocol spec)。 「block → runbook 提示 → 手動 60 秒 → 再開」の型を先に決めておくと、深夜の approve 待ちが消えます。

ルール 4: 実 write は前後 diff evidence で回す (可逆性 pattern)

「作った」「消した」「書き換えた」系の実 write は、guardrail が過剰に block しても、逆に何も block しなくても、事故りやすい領域です。 対策は、operation の前後で状態量 (bodyLenBefore / bodyLenAfter、レコード count、特定 phrase の appear / disappear) を diff として取り、evidence として保存する運用に統一することです。 guardrail が「未 verified だから block」と反応した場合は、実施済 verify の evidence を提示して retry、逆に guardrail が block しない場合でも代表への post-execution report に diff サマリを載せてから submit する非対称ルールです。 Xiora の 2026-07-19 の Gourmie 3 tier products 作成 (Free / Pro / Enterprise) では、Stripe API の POST /v1/products + POST /v1/prices を実行する前に既存 products count = N を read、実行後に count = N+3 と 特定 metadata (tier=free|pro|enterprise) の appear を verify、という前後 diff で全 3 件を確認しています。 同 session の services/shared/billing-core-service/ (FastAPI, port 3025) の Stripe webhook receiver 実装でも、event_id ベースの冪等キーを DB に upsert する前後で「同一 event_id が既に存在するか」の appear / disappear diff を evidence として記録しています。 可逆な operation ほど「diff evidence 必須」を先に決めておくと、後追い修正の時間が減ります (参考: Stripe Webhooks best practices、Anthropic Usage Policies)。

ルール 5: per-write vs blanket approval を operation 単位で切り替える

エージェント運用の疲弊要因の 1 位は、代表が「1 実装ごと」「1 PR ごと」に approve/reject を求められることです。 対策は、operation を「実験研究名で全自動運用を default にするもの」と「代表の 1 メッセージで N 件を blanket approve するもの」に分け、per-write 確認を default で不要にすることです。 default policy は「稼ぎ直結の低リスク行動 (SEO 記事 draft、PR create、internal SaaS への実装 commit、内部 handler 追加、ローカル test 実行) は代理人判断で着手、外部送信と outgoing money と 5 種の hard gate (billing / delete / permission / contract / kyc) のみ代表 gate」に設定できます。 exception policy は「hard gate に触れる可能性のある draft のみ per-write 確認」の ホワイトリスト / ブラックリスト 分離です。 Xiora の brain runtime では、代表が「go」or「投稿 OK」の 1 語で複数実装分を blanket 承認する運用にしており、細かな per-write 確認は default で不要、という運用で N 件 × 数往復の approve 疲弊を回避しています。 「default = 自動」「exception = ホワイトリスト」の分離が、単独創業の稼働時間を守ります (参考: Anthropic Claude Agent SDK best practices)。

Xiora 2026-07-19 実運用 tech 事例: 5 ルールが同時に効いた 1 セッション

2026-07-19 の 1 セッションで、上記 5 ルールが同時に効いた実運用 tech 事例として、(a) Xiora HP に 6 本の SEO 記事を「執行境界 = 実 write (git commit + push + gh pr create)」で代理人が全 draft + PR 作成まで自動化し、代表は GitHub の merge click だけを担当、(b) Stripe MCP 再接続を「業務用サブアカウント側 = BAN cascade 影響外」で行い、guardrail block → 60 秒 OAuth runbook → 再開の型で処理、(c) Gourmie の 3 tier product を Stripe 新 org 側で API 経由 write し、前後 count diff で verify、(d) services/shared/billing-core-service/ (FastAPI, port 3025) の webhook receiver を Docker build 640MB で疎通確認、(e) brain runtime に新規 handler 3 種を追加し restart 経由で activate、(f) 45+ 件の実 command 実行を代表の「go」1 語で blanket 承認、という形が 1 セッションで消化されました。 これは代理人自律運用の憲法 5 条 ((a) profit-first / (b) legal / (c) reversibility / (d) transparency / (e) escalation only when needed) を、テキストとして守るのではなく operation ルールとして埋め込んでいる結果です。

お問い合わせ / 30 分無料相談

Xiora の AI エージェント 24/7 運用の tech 実装事例 (執行境界 3 分類・BAN リスク tier table・OAuth 60 秒 runbook・実 write 前後 diff pattern・blanket approval scope) を、貴社の SaaS 事業や社内 automation 要件に当てはめる形で 30 分お話しします。 単独創業 / 小規模チーム向けに設計された運用ルールなので、まずは今の approve 疲弊の棚卸しから使っていただけます。

---