社内自作アプリ基盤: IAP 入口 + ゲートプロキシ認可 + テナント別 DB

どんなときに使う？

• 生成 AI で作った社内ツールを、GitHub なしのメンバーにも URL で配りたい
• アプリコードの認証実装を信じられない（実装ミス＝穴になる）
• 常時起動の固定費を避けたい（scale-to-zero）

やり方（設計パターン）

1. 入口を 1 箇所に強制
   Cloud Run 等の前に Identity-Aware Proxy（や同等の IdP 連携プロキシ）を置き、Workspace（など）ログインなしではアプリ画面に到達できないようにする。各アプリにログイン実装を任せない。
2. 認可はアプリの外
   利用者アプリの前に基盤側ゲートプロキシを置き、公開範囲（オーナー／グループ／全社）は設定値で渡す。プロキシを迂回してアプリを直接叩けないネットワーク／IAM にする。
3. データはアプリごとに分離
   アプリ専用 DB（例: Firestore プロジェクト／DB）を割り当て、SDK 経由以外の書き込み経路を持たせない。接続先を選ぶ引数自体を SDK から消し、IAM で「自分の DB 以外は触れない」を保証する。
4. コスト
   min-instances=0 など scale-to-zero と、従量課金ストアを組み合わせ、使われないアプリの固定費を殺す。
5. ガバナンス
   管理者ダッシュボードで一覧・削除・公開範囲変更。デプロイ権限はグループ所属で絞る。

利用者の導線は「Claude Code スキルがデプロイ API を呼ぶ」など、CLI／GitHub を必須にしない形が現実的。

注意点

• 事例は Google Cloud（Cloud Run / Firestore / IAP）だが、パターン自体は他クラウドでも移植可能
• プロキシとアプリのネットワーク分離を崩すと「認可を外に寄せた」意味が消える
• scale-to-zero はコールドスタートとトレードオフ

出典

• @yuki82511988 · 2026-07-16
• 解説記事: zenn.dev