ナレッジソース削除のCloud Storage対応 PRD¶
ステータス：検討中（ドラフト）
このドキュメントは現在**レビュー・議論中**です。仕様が大きく変わる、または開発が見送られる可能性があります。
1. メタデータ¶
- 作成者:
- 作成日: 2026/04/03
2. 目的と背景 (Why)¶
- なぜこれを作るのか？: Cloud Armor でCloud StorageにバケットレベルのIPフィルタリングを設定した場合、バックエンドのCloud RunはIPが動的なためGCSへのアクセスがブロックされる。その結果、ナレッジソース削除時にFirestoreのドキュメントは削除されるが、GCS上のファイルが残り続けるデータ不整合が発生している。
- 目指すゴール: IPフィルタリングを維持しつつ、ナレッジソース削除時にGCSファイルも確実に削除されること。
3. ターゲットユーザー (Who)¶
- 誰のための機能か？: ナレッジソースの削除操作を行う管理者・編集者ロールのユーザー
4. ユーザーメリットと想定効果 (Value & ROI)¶
- ユーザーが得られる価値: 削除操作が完全に完結し、GCSに不要ファイルが蓄積されない
- 想定効果: ストレージコストの抑制、データ管理の整合性確保
5. 機能要件 (What)¶
選択肢の比較¶
| # | 案 | 概要 |
|---|---|---|
| A | フロントエンドからSigned URLでGCS削除（推奨） | バックエンドでFirestore削除後にSigned URLを返し、フロントエンドがGCSに直接DELETEリクエストを送る |
| B | Cloud RunをVPCに入れる（Direct VPC Egress） | Cloud RunにDirect VPC Egressを設定し、GCSのIPフィルタにそのVPCを許可として追加する |
| C | GCSのIPフィルタリングを外す | Cloud Armorによるバケットレベルのアクセス制限を撤廃する |
| D | Cloud RunをVPCに入れて静的IPを付与（Cloud NAT） | VPC + Cloud NATで固定IPを取得し、GCSのIPフィルタに追加する |
詳細比較¶
案A：フロントエンドからSigned URLでGCS削除（推奨）¶
メリット - IPフィルタリングを維持できる（Signed URLはブラウザIPで発行されるためフィルタをパスする） - アップロードと同じパターンで実装できるため、実装コストが低い - インフラ変更不要、追加コストなし
デメリット - フロント側のネットワーク断などでGCS削除が失敗した場合、GCSにファイルが残る（ただし現状のバックエンド実装でも同リスクがある） - フロントエンドがストレージ操作を担う責務が増える
実装概要
1. バックエンド deleteReference：Firestore削除 → BQレコード挿入 → Cloud Tasks作成 → GCS削除用Signed URL返却
2. フロントエンド：Signed URLでGCSに直接 DELETE リクエスト
案B：Cloud RunをVPCに入れる（Direct VPC Egress）¶
メリット - フロントエンドの変更不要 - バックエンドのコード変更不要 - 追加費用ほぼゼロ（VPC・サブネット作成は無料、同一リージョン間転送も無料） - 将来的に Cloud SQL・Memorystore など他サービスとのVPC接続にも流用できる - Cloud NATが不要（GCSはVPCソースとしてIPフィルタに登録できるため）
デメリット - Terraformとcloudbuild.ymlの両方に変更が必要 - コールドスタート時に接続確立で若干の遅延が発生する可能性がある（1分以内） - サブネットのIPアドレス数を最大インスタンス数に合わせて設計する必要がある
必要な作業
1. TerraformでVPC・サブネット作成（デフォルトVPCがあれば省略可）
2. TerraformでバケットのipフィルタリングにそのVPCを追加
3. cloudbuild.ymlに --network --subnet --vpc-egress オプションを追加してデプロイ
追加コスト - VPC・サブネット：無料 - Direct VPC Egress：無料（同一リージョン間転送のため） - Cloud NAT：不要
案C：GCSのIPフィルタリングを外す¶
メリット - 即時対応可能、実装コストゼロ
デメリット - セキュリティ要件を満たせなくなる - IPフィルタリングを導入した目的が失われる
案D：Cloud RunをVPCに入れて静的IPを付与（Cloud NAT）¶
メリット - バックエンドの責務が変わらず、フロントエンドの変更不要 - 固定IPでGCSのIPフィルタを管理できる
デメリット - Cloud NATの稼働コストが発生する（月数千円規模） - VPC・Cloud NATの構築・維持が必要でインフラ構成が複雑になる - Cloud Runのコールドスタートに影響が出る可能性がある - 案Bで同等の効果が追加コストなしで実現できるため優位性が低い
推奨案¶
案A（Signed URL方式） を推奨。アップロードで実績のあるパターンを踏襲でき、追加コストなしでIPフィルタリングを維持できる。
インフラ側で完結させたい場合は**案B（Direct VPC Egress）**が次点。追加費用ほぼゼロでコード変更不要。
6. 非機能要件・やらないこと¶
- Signed URLの有効期限: 15分（アップロードと統一）
- 今回のスコープ外: GCS削除失敗時の自動リトライ・クリーンアップバッチ（将来対応）