初めての有料顧客の前にAI構築SaaSを監査すべきこと
著者はAIでSaaSを構築した経験から、AI生成コードが規模化する際に機械的な拒否表面が欠如していることを指摘。最初の有料顧客を受け入れる前に、境界認可、データベース層の多層防御、AI呼び出しの評価（単体テストではなく）、テナントごとのコスト帰属、プロンプトインジェクションの爆発半径、APIキーセキュリティ、可観測性の7項目を監査することを提案。行動的なリマインダーよりも構造的な防御が効果的であると論じる。
この記事は警告的な逸話から始まる：AIで構築されたMVPが本番環境に出荷され、2週間も経たないうちに、ある顧客が別の顧客のデータを読めてしまった。モデルが14個のハンドラのうち1つでテナント分離チェックを忘れたためだ。コードは同一に見え、テストは合格したが、コードベース内の何も機械的にそのバグを拒否しなかった。これが核心問題を浮き彫りにする：AI生成コードには「拒否表面」—コード自体が無効な入力や状態を機械的に拒否する境界—が欠けている。
著者はCursorとClaude Codeを使って9ヶ月間でマルチテナントSaaSのAllsetを単独で構築した経験から、最初の有料顧客を受け入れる前に監査すべき7つの領域を提案する：
- ハンドラ内部ではなく境界での認可：各ハンドラ内の実行時チェック（モデルが忘れる可能性がある）に頼るのではなく、認可を型にする。例えば、
TenantAccess値はデータベースルックアップを行う境界関数からのみ構築できる。これをスキップするハンドラはコンパイルできない。AllsetはSpiceDBを使ってこれを強制している。
- データベース層での多層防御：型付き境界があっても、第二の鍵が必要。PostgreSQLの行レベルセキュリティやDynamoDBのIAM条件のようなデータベースレベルの強制を使用する。アプリケーションは接続境界でテナントIDのセッション変数を設定し、データベースは独立して不一致の行を拒否する。AllsetはすべてのテナントスコープテーブルでAurora PostgresのRLSを使用している。
- AI呼び出しには単体テストではなく評価（evals）：単体テストは確率的なAI出力には不適切。代わりに、入力とスコアリング関数のペアからなるデータセットをCIで実行する評価を使用する。20個の評価から始め、ユーザーがモデルの誤りを報告するたびに1つ追加する。このインフラは真の信頼を提供する。スナップショット固定はモデル更新のたびに壊れる。
- すべてのモデル呼び出しにおけるテナント単位のコスト帰属：すべてのモデル呼び出しにtenant_id、model、purposeのタグを付ける。シンプルなダッシュボードでテナントごとの日次コストがわかる。これは初日に5分で追加できるが、後から追加するには1週間かかる。これがなければ、インテリジェントな価格設定や暴走ループの検出は不可能。
- プロンプトインジェクションの爆発半径：注入を完全に防ごうとするのではなく（不可能）、エージェントのツールを現在のテナントコンテキストにスコープする。例えば、
db_queryツールはテナントスコープの認証情報を使用すべき。テナント境界を越えるツールは、シングルテナントエージェントコンテキストから構造的に呼び出せないようにする。
- APIキーセキュリティ：長期キーではなく、一時的でスコープが限定されたキーを使用する。これにより、キー漏洩時の被害を制限できる。
- 可観測性：メトリクス、ログ、トレースを実装し、特にセキュリティとコストの異常に焦点を当てる。これにより、問題を迅速に検出し対応できる。
著者は、これらの構造的防御は「CLAUDE.mdにテナントアクセス検証を追加」のような行動的リマインダーよりもはるかに効果的だと強調する。コード自体が機械的に誤った振る舞いを拒否しなければならない。最初からこの拒否表面を構築することは、本番信頼性を目指すAI構築SaaSにとって極めて重要である。