クラウド
プロダクト運用に必要なクラウド・SaaS をカテゴリ別に整理した参考メモ。ハイパースケーラ（AWS / GCP / Azure）、PaaS / BaaS、監視、品質レビューまで。
クラウド・プロダクト運用
カテゴリ早見表
アプリを公開・運用すると、サーバー・DB・ログ・デプロイなど役割の違うサービスを組み合わせる必要がある。下表は役割ごとの代表例を並べた地図。Vercel のような単体 SaaS も AWS 上のマネージド DB も、同じ役割なら同じ行。
| カテゴリ | 役割 | 代表サービス | 詳細 |
|---|---|---|---|
| ハイパースケーラ | IaaS / 基盤クラウド・GPU・エンタープライズ統合 | AWS, GCP, Azure | § HS |
| PaaS / BaaS / FaaS | アプリ稼働・Auth・DB・エッジを一体提供 | Vercel, Cloudflare, Firebase, Supabase | § PaaS |
| データ・検索 | RDB・Vector・オブジェクトストレージ | Neon, pgvector, Pinecone | § データ |
| デリバリー | 構成管理・CI/CD・デプロイ自動化 | Terraform, GitHub Actions | § デリバリー |
| 監視・オブザーバビリティ | ログ・メトリクス・トレース・エラー集約 | Datadog, Sentry | § 監視 |
| 品質・レビュー | PR レビュー・静的解析・セキュリティスキャン | CodeRabbit, CodeQL | § 品質 |
選定の流れ: 制約（既存契約・SLA）→ カテゴリごとに候補 2 つまで → 開発スタック選定手順 で ADR / tech_decisions に残す。
ハイパースケーラ（AWS / GCP / Azure）
世界規模でシェアの大きいクラウド基盤は AWS・GCP・Azure の 3 社（通称 Big 3）。自社でサーバーを買う代わりに、ネット経由で借りる「基盤レイヤ」を提供する。
- 誰が — インフラ担当・バックエンド／ML エンジニア。スタートアップから大企業まで、本番アプリや AI 基盤をクラウドで動かすチーム。
- 目的 — 仮想サーバー（IaaS）・コンテナ・DB・GPU/TPU・ストレージを必要な分だけ借り、拡張・バックアップ・可用性をクラウド側に任せる。
- 使い方 — いずれか 1 社を選び、Terraform 等で環境をコード化して構築する。4 位以降は その他 HS。Vercel や Supabase のような PaaS / BaaS は別カテゴリ（アプリ公開まで一括で提供）。
Big 3 比較（2026年）
| 観点 | AWS | GCP | Azure |
|---|---|---|---|
| AI/ML 強み | SageMaker・広範な GPU 選択肢 | TPU 8t/8i・JAX/PyTorch 最適化 | Azure OpenAI・AI Foundry |
| LLM 推論 | Amazon Bedrock | Vertex AI | Azure OpenAI Service |
| サーバーレス | Lambda | Cloud Run / Functions | Azure Functions / Container Apps |
| 向く用途 | 汎用・大規模 ML | TPU 学習・Google 連携 | Microsoft 365 / Entra 連携 |
| クラウドネイティブ監視 | CloudWatch (+ Datadog 連携可) | Cloud Monitoring / Logging | Azure Monitor |
| AWS | GCP | Azure | |
|---|---|---|---|
| コスト最適化 | Reserved Instances・Spot Training（SageMaker） | Committed Use Discounts・Preemptible VMs | Reserved Capacity・Spot VMs |
| 最適化ツール | Compute Optimizer | Cloud Recommender | Azure Advisor・Cost Management |
| コンテナ基盤 | EKS / ECS / Fargate | GKE / Cloud Run | AKS / Container Apps |
AWS
ガイド
| ドキュメント | 内容 |
|---|---|
| Lambda API設計ガイド | 画面 API は Lambda で始め、重い処理は SQS + Worker へ。実行時間・ECS/Batch への逃がし方針 |
| 11章 リポジトリ構成 | S3/MinIO・CI/CD（OIDC）・Terraform/CDK 方針・RAG 導入の判断 |
主要サービス（本サイト内）
- SageMaker — ML 構築・学習・デプロイ
- Amazon Bedrock — 基盤モデルへの統一 API
- Lambda / ECS / RDS / SQS — 汎用アプリ基盤（詳細は 11章）
- CI/CD（AWS） — GitHub Actions + OIDC デプロイ
SageMaker
AWS が提供する 機械学習（ML）の構築・学習・デプロイをまとめて扱うマネージドサービス。
- 誰が — ML エンジニア、データサイエンティスト。自前 GPU サーバーを持たずにモデルを作りたいチーム。
- 目的 — ノートブックで実験 → 大量データで学習 → 推論 API として本番公開、まで AWS 上で一貫して行う。
- 使い方 — SageMaker Studio で開発し、学習ジョブを Spot Training（空き GPU を安く借りる）で回してコストを抑える。成果物はエンドポイントとして公開する。
Amazon Bedrock
複数社の 基盤モデル（LLM） に、AWS 上の同じ API 経由でアクセスするサービス。
- 誰が — アプリ開発者・AI 機能担当。自前 GPU を立てず ChatGPT 的な機能を組み込みたい人。
- 目的 — Claude・Titan・Llama・Mistral などを切り替えやすく使い、推論・RAG・エージェントを AWS 内で完結させる。
- 使い方 — Bedrock API をアプリから呼ぶ。Bedrock Agents で外部ツール（DB 検索・API 呼び出し）付きエージェントも構築できる。
Lambda / ECS / RDS / SQS（汎用）
本リポジトリで想定している 汎用 Web / API アプリ の AWS 構成パターン。
- 誰が — バックエンドエンジニア、インフラ担当。画面付きサービスを AWS で運用するチーム。
- 目的 — 役割ごとに適したマネージドサービスを組み合わせ、運用負荷を下げる。
- 使い方
- Lambda — 画面から呼ぶ API（短時間で終わる処理）
- S3 — 画像・PDF 等のファイル保存（ローカル開発は MinIO で代替）
- SQS — メール送信など時間のかかる処理を非同期化
- ECS — 常時起動が必要なワーカー（SQS からジョブを処理）
- RDS — ユーザー・注文などのリレーショナル DB
設計・CI/CD・認証情報の扱いは 11章 と Lambda API 設計ガイド が正式な手順。
GCP
Vertex AI
Google Cloud 上の AI / ML 統合プラットフォーム。モデル API・学習・検索を 1 か所で扱う。
- 誰が — GCP を使う ML エンジニア、AI 機能を組み込むアプリ開発者。Google 連携（Workspace 等）があるチーム。
- 目的 — Gemini・Claude（Anthropic 提携）・Llama などのモデルを API で使い、必要なら自前データで学習・RAG 用ベクトル検索まで GCP 内で完結させる。
- 使い方 — Vertex AI コンソールまたは API からモデルを呼ぶ。カスタム学習は Vertex AI Training、RAG 検索は Vertex AI Vector Search を使う。
AI Hypercomputer と TPU 8t / 8i
Google が提供する AI 専用チップ（TPU） と、それを使いやすくする統合ソフトウェアスタック。
- 誰が — 大規模モデルを学習・推論する ML エンジニア。GPU より TPU 最適化を活かしたいチーム。
- 目的 — 学習コストと推論レイテンシを下げ、JAX / PyTorch / vLLM など主要フレームワークで動かす。
- 使い方 — Google Cloud Next ’26（2026-04）で第 8 世代 TPU が発表。TPU 8t は大規模学習向け、TPU 8i は推論・エージェント向けの 2 系統。AI Hypercomputer は JAX・PyTorch・vLLM を含む統合スタック。Cloud 提供は 2026 後半〜（公式ロードマップ要確認）。
Cloud Run
コンテナ（Docker イメージ）を サーバーレス で動かす GCP のサービス。
- 誰が — バックエンドエンジニア。サーバー管理なしで API を公開したい人。
- 目的 — FastAPI 等の推論 API や Web バックエンドを、トラフィックに応じて自動スケールさせながらホスティングする。
- 使い方 — コンテナをビルドして Cloud Run にデプロイ。リクエストが来たときだけ課金。サーバーレス AI 推論 の代表例の一つ。
Azure
Azure OpenAI Service
Microsoft Azure 上で GPT 系モデル を企業向けに提供する API サービス。
- 誰が — Microsoft 365 / Entra ID（旧 Azure AD）を既に使っている企業の開発チーム。
- 目的 — 社内 SSO と統合し、契約・リージョン・コンテンツフィルタを企業ポリシーに合わせて GPT 機能を使う。
- 使い方 — Azure ポータルでリソースを作成し、Entra ID 認証付き API をアプリから呼ぶ。OpenAI 直契約ではなく Azure 経由の請求・監査が必要なときに選ぶ。
Azure AI Foundry
Azure 上の AI 開発・評価・デプロイ を 1 つのコンソールで行う統合プラットフォーム。
- 誰が — Azure 中心の ML / AI 担当、PoC から本番まで Azure で完結させたいチーム。
- 目的 — モデル比較・プロンプト調整・RAG（Azure AI Search 連携）・エージェント構築を GUI と API で進める。
- 使い方 — Foundry ポータルでプロジェクトを作成。Claude 等は Model Catalog 経由。Container Apps・Service Bus・Key Vault と組み合わせて本番構成を組む。
その他ハイパースケーラ（参考）
Big 3 以外で、特定地域・既存契約で採用されるクラウドプロバイダ。
- 誰が — Oracle / 中国本土 / レガシー IBM 環境など、Big 3 以外の契約が既にある企業。
- 目的 — 既存 DB・地域要件・コスト条件に合わせて AWS/GCP/Azure の代替を検討する。
- 使い方 — 本リポジトリの AWS 想定フローの代替候補として知っておく程度でよい。詳細は下表を参照。
| プロバイダ | 強み | AI / 開発メモ |
|---|---|---|
| Oracle Cloud（OCI） | Oracle DB 統合・コスト | OCI Generative AI・GPU クラスタ。既存 Oracle 顧客向け |
| Alibaba Cloud | アジア・中国リージョン | 通義（Qwen）・Model Studio。国内/越境要件で検討 |
| IBM Cloud | エンタープライズ・Red Hat OpenShift | watsonx AI。レガシー統合が主用途 |
| Tencent Cloud | 中国本土 | 混元モデル。中国向けサービスのみ |
PaaS / BaaS / FaaS
アプリを素早く公開・運用するレイヤ。AWS 等の上に載せることも、Vercel のように単体 SaaS で完結することもある。
- 誰が — フロント／フルスタック開発者。インフラを最小限にして MVP や Next.js アプリを早く出したい人。
- 目的 — ホスティング・Auth・DB・CDN をまとめて借り、デプロイとスケールをサービス側に任せる。
- 使い方 — 下表で 5 社を比較し、用途に合う 1 社を選ぶ（検証 2026-05-31）。
| 観点 | Vercel | Cloudflare | Supabase | Firebase | Neon |
|---|---|---|---|---|---|
| 分類 | フルスタック PaaS | エッジ / CDN + FaaS | BaaS（Postgres） | BaaS（NoSQL / GCP） | DBaaS（Postgres） |
| 強み | Next.js 一体・プレビュー URL | CDN 前段・低レイテンシ | Auth + SQL + pgvector 一体 | モバイル SDK・Realtime | ブランチング DB・スケールトゼロ |
| サーバーレス | Fluid Compute Functions | Workers | Edge Functions（Deno） | Cloud Functions | —（接続先 DB） |
| AI 連携 | AI SDK・AI Gateway | Workers AI・AI Gateway | pgvector・Edge API | Firebase AI / Vertex | pgvector（拡張） |
| 向く用途 | Next.js 新規 Web | BFF・グローバル API 前段 | Auth + Postgres MVP | モバイル・Realtime MVP | DB のみ（Auth 別） |
Vercel — フルスタック PaaS
Next.js ホスティングと Fluid Compute
Next.js アプリを デプロイ・プレビュー・本番運用 する PaaS。
- 誰が — Next.js / React 開発者。Git push で自動デプロイしたいチーム。
- 目的 — フロントと API（Server Actions / Route Handlers）を同一プラットフォームでホストし、PR ごとにプレビュー URL を発行する。
- 使い方 — GitHub 連携でデプロイ。Fluid Compute（Node.js 24 既定・300s タイムアウト）で API Routes / Server Actions を運用。ISR も最適化済み。開発スタック（Next.js） のホスティング先として記載。
Vercel AI SDK / AI Gateway
Next.js 等から AI 機能（チャット・エージェント） を実装するための SDK と API ゲートウェイ。
- 誰が — AI 機能付き Web アプリを Vercel 上で作る開発者。
- 目的 — ストリーミング UI・ツール呼び出し・エージェントを型安全に実装し、複数 LLM プロバイダを 1 つの API にまとめる。
- 使い方 — AI SDK で UI とサーバー処理を書く。Vercel AI Gateway 経由で OpenAI / Anthropic 等を切り替え。Postgres は Marketplace 連携（Neon 等）。ルール/プラン の AI SDK 参照と併用。
Cloudflare — エッジ / CDN
Workers と Workers AI
Cloudflare の エッジ（CDN 近傍）で動くサーバーレス 実行環境。
- 誰が — グローバル向け API や BFF を低レイテンシで配信したい開発者。
- 目的 — ユーザーに近い場所でリクエスト処理・LLM 推論を行い、応答速度を上げる。
- 使い方 — Workers に JavaScript/TypeScript をデプロイ。Workers AI で推論をエッジ実行。Cloudflare AI Gateway は LLM プロキシ（キャッシュ・レート制限・オブザーバビリティ）。Vercel AI Gateway とは別製品。R2・D1・KV と組み合わせた軽量スタックも可能。サーバーレス AI 推論 の代表例の一つ。
Supabase — BaaS（Postgres）
PostgreSQL を中心に、Auth・Storage・Realtime・Edge Functions を 一体提供 する BaaS。
- 誰が — フルスタック開発者。SQL + 認証 + ファイル保存を 1 サービスで揃えたい MVP チーム。
- 目的 — バックエンドを自前構築せず、Postgres ベースでアプリのデータ・ユーザー管理を早く始める。
- 使い方 — ダッシュボードで DB・Auth を設定し、クライアント SDK または Edge Functions からアクセス。RAG 小〜中規模は pgvector を利用。
| 機能 | 用途 | AI 開発での位置づけ |
|---|---|---|
| Auth | メール/OAuth 認証 | ユーザー単位 RAG・履歴の分離 |
| Postgres + pgvector | リレーショナル + ベクトル検索 | 小〜中規模 RAG（IVFFlat で〜100 万件目安） |
| Edge Functions | Deno サーバーレス | Webhook・軽量 API |
| Storage | オブジェクト | PDF 等の取り込み元 |
大規模ベクトル検索は Pinecone / Qdrant も検討。pgvector 選定基準は RAG・ベクトルDB。2026 年更新例: AI テーブルフィルター・Stripe 統合・public スキーマ非公開化。
Firebase — BaaS（Google / GCP）
Google が提供する モバイル・Web 向け BaaS。GCP プロジェクトに紐づく。
- 誰が — モバイルアプリ開発者、Realtime 同期が必要な MVP チーム。
- 目的 — Auth・NoSQL（Firestore）・Storage・Hosting・Cloud Functions を SDK 中心で素早く組み合わせる。
- 使い方 — Firebase コンソールでプロジェクト作成。Supabase（Postgres）と対になるNoSQL + クライアント SDK 中心の選択肢。Gemini 連携は Firebase AI Logic / Vertex AI 経由。
| 機能 | 用途 | Supabase との違い |
|---|---|---|
| Firebase Auth | メール/OAuth/匿名 | 同等。モバイル SDK が厚い |
| Firestore | ドキュメント DB・Realtime | Supabase は Postgres（SQL・JOIN） |
| Cloud Functions for Firebase | サーバーレス API | Supabase Edge Functions（Deno）に相当 |
| Firebase AI Logic / Vertex AI | Gemini 連携 | 2025〜 Vertex 統合。RAG は自前 or Vertex AI Search |
向く: モバイル MVP・リアルタイム同期・スキーマレス。向かない: 複雑な SQL・トランザクション・pgvector を Postgres で一体運用したい（→ Supabase / Neon）。
Neon — サーバーレス Postgres
ブランチング・スケールトゼロが特徴の マネージド PostgreSQL。
- 誰が — Auth / Storage は別サービスで持ち、DB だけ 借りたい開発者。Vercel + Next.js チーム。
- 目的 — PR ごとに DB ブランチを切り、使わないときは課金を抑える。pgvector で小〜中規模 RAG も可能。
- 使い方 — Vercel Marketplace 経由で Next.js プロジェクトと一体運用。Supabase と同等の DB 選択肢だが Auth / Storage は自前または他 SaaS で補う。
その他 PaaS / BaaS（参考）
PoC・個人開発・特定用途でよく名前が出るサービス。
- 誰が — Vercel / Supabase 以外を試したい開発者、Docker 1 本でデプロイしたい人。
- 目的 — 用途（Jamstack / コンテナ / MySQL / MongoDB 等）に合わせて代替 PaaS を選ぶ。
- 使い方 — 下表から候補を選び、各社ドキュメントを正式な手順として参照する。
| サービス | 分類 | 向く用途 |
|---|---|---|
| Netlify | フロント PaaS | 静的/Jamstack・Next.js（Vercel 代替） |
| Railway / Render / Fly.io | コンテナ PaaS | FastAPI・Go 等を手早く公開。Docker 1 本デプロイ |
| DigitalOcean App Platform | 汎用 PaaS | シンプルなフルスタック・料金予測しやすい |
| PlanetScale | サーバーレス MySQL | Neon の MySQL 版。Vitess ベース |
| MongoDB Atlas | マネージド MongoDB | ドキュメント DB・Atlas Vector Search（RAG） |
| Upstash | サーバーレス Redis / Kafka | Vercel 連携・レート制限・キュー |
| Databricks | データ + ML プラットフォーム | Spark・Mosaic AI。エンタープライズ分析/ML |
データ・検索基盤
RDB・Vector DB・オブジェクトストレージは、PaaS に含まれることもあるが、RAG 規模や JOIN 要件で独立して選ぶことが多い。
- 誰が — バックエンドエンジニア、RAG を組む AI 担当。
- 目的 — 構造化データ（ユーザー・注文）と非構造化検索（ベクトル）を、規模とクエリ要件に合わせて配置する。
- 使い方 — Postgres + pgvector か専用 Vector DB（Pinecone 等）かを分岐する。典型判断は下の Vector DB 表。
マネージド Vector DB
RAG（社内文書検索など）の 類似度検索基盤。
- 誰が — RAG / 検索機能を実装する開発者。
- 目的 — 埋め込みベクトルを保存し、ユーザーの質問に近い文書チャンクを高速に取り出す。
- 使い方 — 既存 Postgres に pgvector を載せるか、専用 SaaS に切り出すかを下表で判断。実装詳細は RAG・ベクトルDB。
| サービス | 分類 | 向く規模・用途 |
|---|---|---|
| pgvector（RDS / Supabase / Neon） | Postgres 拡張 | 〜100 万件・他テーブルと JOIN したい |
| Pinecone | 専用 Vector DB SaaS | 大規模・低レイテンシ・運用を委譲 |
| Qdrant Cloud | 専用 Vector DB SaaS | フィルタリング・ハイブリッド検索重視 |
| Vertex AI Vector Search | GCP マネージド | Vertex / GCP データと一体 |
| Azure AI Search | Azure マネージド | Azure AI Foundry RAG と一体 |
| MongoDB Atlas Vector Search | マネージド MongoDB | Firestore / Firebase 代替のベクトル検索 |
デリバリー（IaC・CI/CD）
インフラ定義とデプロイを コード化し、自動検証 するレイヤ。
- 誰が — インフラ担当、DevOps、全員が PR 経由でデプロイする開発チーム。
- 目的 — 手動クリック構築を避け、変更履歴・レビュー・ロールバック可能なパイプラインを維持する。
- 使い方 — Terraform / CDK でインフラを定義し、GitHub Actions でテスト → デプロイ。11章 が AWS 想定の正式な手順。
Infrastructure as Code（IaC）
サーバー・DB・ネットワーク等を コード（HCL / TypeScript 等）で宣言 し、再現可能に管理する手法。
- 誰が — インフラ担当、フルスタック開発者（CDK / Pulumi を使う場合）。
- 目的 — 環境差分（dev / stg / prod）をコードで揃え、手作業ミスを減らす。
- 使い方 — 11章 方針どおり Terraform / CDK でコード化。手動リソース作成は避ける。
| ツール | 特徴 | 向くチーム |
|---|---|---|
| Terraform | マルチクラウド・HCL・状態管理 | AWS + GCP 混在、モジュール資産化 |
| AWS CDK | TypeScript/Python で AWS リソース定義 | AWS 中心・型安全を重視 |
| Pulumi | 一般言語（TS/Python/Go）で IaC | アプリコードと同言語で infra を書きたい |
# Terraform で AWS + GCP を統一管理する例
terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
google = { source = "hashicorp/google", version = "~> 5.0" }
}
}
# AWS: SageMaker Endpoint
resource "aws_sagemaker_endpoint" "ml_inference" {
name = "prod-ml-endpoint"
endpoint_config_name = aws_sagemaker_endpoint_configuration.main.name
}
# GCP: Cloud Run for serverless inference
resource "google_cloud_run_service" "inference_api" {
name = "inference-api"
location = "us-central1"
template {
spec {
containers {
image = "gcr.io/${var.project_id}/inference:latest"
}
}
}
}CI/CD（GitHub Actions）
GitHub 上で テスト・ビルド・デプロイ を自動化する CI/CD サービス。
- 誰が — 全開発者。AI が生成した PR も含め、マージ前に自動検証したいチーム。
- 目的 — lint・型チェック・テスト・セキュリティスキャンを PR ごとに走らせ、壊れたコードのマージを防ぐ。
- 使い方 —
.github/workflows/に YAML を置く。AWS デプロイ手順は 11章 CI/CD、PR 前チェックは PR前チェック。
name: AI-generated PR Validation
on: pull_request
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Lint & Type Check
run: npm run lint && npm run typecheck
- name: Test
run: npm test -- --coverage
- name: Security Scan
uses: github/codeql-action/analyze@v3GitHub Copilot Coding Agent
GitHub Issue から AI が実装 PR を自動生成 するエージェント機能。
- 誰が — GitHub 中心の開発チーム。Issue 駆動で AI に実装を任せたい人。
- 目的 — 「Issue 記述 → AI 実装 → CI 検証 → 人間レビュー → マージ」の流れを維持する（旧 Copilot Workspace は 2025-05-30 終了）。
- 使い方 — Issue に
@copilotをメンション。生成 PR は GitHub Actions で lint / test を通してから人間がレビューする。
監視・オブザーバビリティ
本番運用で ログ・メトリクス・トレース・エラー を 1 系統に束ねるレイヤ。
- 誰が — SRE、バックエンド／フロント開発者、オンコール担当。
- 目的 — 障害の早期検知、原因特定（どのリクエストが遅い／落ちたか）を可能にする。
- 使い方 — OpenTelemetry（OTel）で計装し、Datadog 等 SaaS または CloudWatch 等クラウドネイティブに送る。開発スタック（観測レイヤ） と併用。
| サービス | 分類 | 強み | 向く用途 |
|---|---|---|---|
| Datadog | 統合オブザーバビリティ SaaS | APM・Logs・Metrics・RUM・Synthetics | マルチクラウド・既契約があるチーム |
| Sentry | エラー / パフォーマンス | FE/BE 例外・Release Health・Session Replay | フロント中心・エラー可視化を最優先 |
| CloudWatch / Azure Monitor / Cloud Monitoring | クラウドネイティブ | HS リソースと一体・追加契約不要 | 単一 HS・コスト最小 |
| Prometheus + Grafana | OSS スタック | カスタム・オンプレ混在 | K8s 自前運用・ベンダー非依存 |
| Vercel Analytics / Speed Insights | PaaS 付帯 | Web Vitals・デプロイ単位 | Vercel ホストのみで足りるとき |
典型構成: OTel SDK → Collector → Datadog（BE）+ Sentry（FE 例外）。trace_id をフロント/バック/API Gateway で貫通させる（選定 7 軸・運用・観測）。
Datadog
APM・ログ・メトリクス・インフラ監視を 統合 する SaaS。
- 誰が — SRE、バックエンド担当。マルチクラウドまたは Datadog 契約があるチーム。
- 目的 — アプリとインフラの状態を 1 ダッシュボードで見、アラート・SLO・オンコールまで一気通貫で運用する。
- 使い方 — OTel exporter または Datadog Agent で計装。AWS では CloudWatch と併用・代替のどちらもあり（11章 運用表）。LLM Observability も提供。
Sentry
フロント・バックエンドの 例外とパフォーマンス を集約するエラー監視 SaaS。
- 誰が — フロント中心の開発者。Next.js / React チーム。
- 目的 — ユーザー画面で起きた JS エラーや API 失敗を Release 単位で追い、デグレを早く見つける。
- 使い方 —
@sentry/nextjs等で SDK を組み込む。BE の構造化ログは CloudWatch / Datadog 側に残す分業も多い。
品質・レビュー・セキュリティ
CI/CD の 上流・下流 で品質を担保する SaaS。AI 生成コードが増えるほど有効。
- 誰が — 全開発者、レビュアー、セキュリティ担当。
- 目的 — 自動レビュー + 静的解析 + 人間レビューの 3 層で、マージ前の品質を上げる。
- 使い方 — GitHub Actions（CI）と組み合わせ、下表のツールを PR フローに載せる。
| サービス | 分類 | 役割 | 関連 |
|---|---|---|---|
| CodeRabbit | AI PR レビュー | PR 差分の自動コメント・サマリー | PR前チェック |
| Cursor Bugbot | AI PR レビュー（IDE 連携） | PR 上のバグ・セキュリティ指摘 | ルール/プラン |
| GitHub CodeQL | 静的セキュリティ解析 | PR / 定期スキャン（SAST） | CI workflow |
| GitHub Copilot Coding Agent | Issue → PR 自動化 | 実装 PR 生成 + CI 待ち | § Copilot Agent |
CodeRabbit
GitHub / GitLab の PR に AI レビューコメント を自動投稿する SaaS。
- 誰が — レビュー負荷が高い開発チーム。人間レビューの前処理として AI を使いたい人。
- 目的 — 差分サマリー・セキュリティ・テスト観点・スタイル指摘を PR 上に残し、人間が本質的な判断に集中する。
- 使い方 — リポに CodeRabbit を連携。Cursor Bugbot 等と併用も可。設定で「要約のみ」等ノイズを抑える。
推奨フロー: AI 実装 → CI green（lint / test / CodeQL）→ CodeRabbit / Bugbot → 人間レビュー → マージ（PR前チェック）。