senior-backend

シニアバックエンドエンジニア

概要

API 設計、サービスアーキテクチャ、データ管理、運用の卓越性に重点を置き、堅牢でスケーラブルなバックエンドシステムを設計、実装します。このスキルでは、RESTful API と GraphQL API のパターン、メッセージ駆動型アーキテクチャ、キャッシュ戦略、レート制限、ヘルスチェック、OpenTelemetry による完全な可観測性を扱います。

開始時に伝えること：「バックエンドシステムの設計と実装にシニアバックエンドスキルを使用します。」

---

フェーズ 1：API 設計

目標： 実装コードを書く前にコントラクトを定義します。

アクション

1. リソースモデルと関係を定義する
2. エンドポイント構成（REST）またはスキーマ（GraphQL）を設計する
3. 認証と認可の戦略を確立する
4. レート制限とスロットリングのポリシーを定義する
5. API ドキュメント（OpenAPI／GraphQL スキーマ）を作成する

API スタイルの判断表

要素	REST	GraphQL	gRPC
データのニーズが異なる複数のコンシューマー	不向き	最適	不向き
シンプルな CRUD 操作	最適	過剰	過剰
リアルタイムのサブスクリプション	WebSocket の追加が必要	組み込み	組み込み（ストリーミング）
サービス間通信	良好	過剰	最適
パブリック API	最適	良好	不向き（ツール面）
帯域幅に制約のあるモバイル	過剰取得のリスク	最適	最適

停止 — フェーズ 2 に進む前に、以下を完了してください：

• リソースモデルが定義されている
• エンドポイント構成またはスキーマが文書化されている
• 認証戦略が選択されている
• API コントラクトをレビューできる状態になっている（OpenAPI／GraphQL スキーマ）

---

フェーズ 2：実装

目標： 関心事を明確に分離したサービスレイヤーを構築します。

アクション

1. 明確なレイヤー構成でプロジェクト構造を整える
2. データアクセスレイヤー（リポジトリー／DAO）を実装する
3. ビジネスロジックを含むサービスレイヤーを構築する
4. API コントローラー／リゾルバーを作成する
5. ミドルウェア（認証、ロギング、エラー処理、CORS）を追加する
6. キャッシュ戦略を実装する

RESTful URL 構成

GET    /api/v1/users              # List users (paginated)
GET    /api/v1/users/:id          # Get single user
POST   /api/v1/users              # Create user
PUT    /api/v1/users/:id          # Full update
PATCH  /api/v1/users/:id          # Partial update
DELETE /api/v1/users/:id          # Delete user
GET    /api/v1/users/:id/orders   # Nested resources
POST   /api/v1/users/:id/activate # State transitions

HTTP ステータスコードの判断表

コード	意味	使用する状況
200	OK	GET、PUT、PATCH の成功
201	作成済み	リソースを作成する POST の成功
204	コンテンツなし	DELETE の成功
400	不正なリクエスト	バリデーションエラー
401	未認証	認証情報がない、または無効
403	禁止	認証は有効だが、権限が不十分
404	見つかりません	リソースが存在しない
409	競合	重複または状態の競合
422	処理できないエンティティ	意味的に無効な入力
429	リクエストが多すぎます	レート制限超過
500	内部サーバーエラー	予期しないサーバー障害

レスポンス形式

// Success (single)
{ "data": { "id": "123", "name": "Alice" }, "meta": { "requestId": "req_abc123" } }

// Success (collection)
{ "data": [...], "meta": { "page": 1, "pageSize": 20, "totalCount": 150, "totalPages": 8 } }

// Error
{ "error": { "code": "VALIDATION_ERROR", "message": "Invalid input", "details": [...] } }

キャッシュ戦略の判断表

戦略	説明	使用例
キャッシュアサイド	アプリがキャッシュを確認し、なければ DB にフォールバックする	汎用
ライトスルー	キャッシュと DB に同時に書き込む	強い整合性
ライトビハインド	キャッシュに書き込み、非同期で DB に書き込む	高い書き込みスループット
リードスルー	キャッシュミス時にキャッシュが DB から読み込む	透過的なキャッシュ

停止 — フェーズ 3 に進む前に、以下を完了してください：

• プロジェクト構造がレイヤードアーキテクチャに従っている
• 入力バリデーションがエッジで行われている（Zod、Joi、class-validator）
• エラー処理が構造化されたエラーレスポンスを返す
• 無効化計画を含むキャッシュ戦略が実装されている

---

フェーズ 3：堅牢化

目標： 本番環境での運用に向けてサービスを準備します。

アクション

1. 包括的なエラー処理を追加する
2. ヘルスチェックとレディネスプローブを実装する
3. 可観測性（トレース、メトリクス、ログ）を設定する
4. 重要なパスの負荷テストを実施する
5. 運用シナリオに関するランブックを文書化する

ヘルスチェックエンドポイント

// GET /health — lightweight liveness check
{ "status": "healthy" }

// GET /health/ready — readiness with dependency checks
{
  "status": "healthy",
  "checks": {
    "database": { "status": "healthy", "latency": "5ms" },
    "redis": { "status": "healthy", "latency": "2ms" },
    "queue": { "status": "healthy", "latency": "8ms" }
  },
  "uptime": "72h15m",
  "version": "1.4.2"
}

可観測性：RED メソッドのメトリクス

メトリクス	説明	実装
レート	1 秒あたりのリクエスト数	リクエストごとにインクリメントするカウンター
エラー	1 秒あたりのエラー率	エラーごとにインクリメントするカウンター
期間	レイテンシーの分布	ヒストグラム（p50、p95、p99）

構造化ログの形式

{
  "timestamp": "2025-01-15T10:30:00.123Z",
  "level": "info",
  "message": "User created",
  "service": "user-service",
  "traceId": "abc123",
  "spanId": "def456",
  "userId": "usr_123",
  "duration": 45
}

レート制限アルゴリズムの選択表

アルゴリズム	長所	短所	最適な用途
固定ウィンドウ	シンプルで、メモリー消費が少ない	境界でバーストが発生する	内部 API
スライディングウィンドウ	分布が平滑化される	メモリー消費が多い	公開 API
トークンバケット	バーストを制御できる	やや複雑	業界標準
リーキーバケット	出力が一定	バーストを許可しない	厳格なレート制御

STOP — 以下が完了したらハードニング完了です：

• ヘルスチェックエンドポイントが正しく応答する
• 構造化ログが設定されている
• メトリクスがエクスポートされている（RED メソッド）
• 重要な経路で負荷テストが完了している
• エラー処理が適切なステータスコードを返す

---

イベント駆動アーキテクチャのパターン

メッセージキューパターンの選択表

パターン	ユースケース	例
パブリッシュ／サブスクライブ	複数のコンシューマーへのブロードキャスト	ユーザー登録 -> メール、分析、CRM
ワークキュー	ワーカー間でタスクを分配	画像処理、PDF 生成
リクエスト／リプライ	応答を伴う非同期リクエスト	価格計算サービス
デッドレター	失敗したメッセージの処理	再試行ポリシーの上限超過

イベントスキーマ

{
  "eventId": "evt_abc123",
  "eventType": "user.created",
  "timestamp": "2025-01-15T10:30:00Z",
  "version": "1.0",
  "source": "user-service",
  "data": { "userId": "usr_123", "email": "[email protected]" },
  "metadata": { "correlationId": "corr_xyz789", "causationId": "cmd_def456" }
}

---

GraphQL のアンチパターン

アンチパターン	問題	修正方法
N+1 クエリ	パフォーマンスの低下	DataLoader によるバッチ処理
無制限のクエリ	DoS の脆弱性	深さと複雑さの上限を設定する
リゾルバーでの過剰なデータ取得	無駄な DB クエリ	リクエストされたフィールドのみを選択する

---

アンチパターン／よくある間違い

アンチパターン	問題である理由	正しい方法
データベース ID をそのまま公開する	セキュリティリスク、DB への依存	UUID またはプレフィックス付き ID を使用する
リクエスト処理中の外部サービスへの同期呼び出し	単一障害点、レイテンシー	キューまたはサーキットブレーカーを使って非同期に処理する
N+1 クエリパターン	パフォーマンスが線形に低下する	Eager ローディングまたは DataLoader
エラーを捕捉して握りつぶす	失敗が見えず、デバッグが不可能になる	コンテキストを付けてログに記録し、伝播させる
ハンドラー間で変更可能な状態を共有する	競合状態、予測不能な動作	ステートレスなリクエスト処理
入力検証を省略する	インジェクション、データ破損	常にエッジで検証する
すべてのエラーに汎用の 500 を返す	開発者エクスペリエンスの低下	具体的なエラーコードとメッセージ
API バージョニングを行わない	破壊的変更がすべてのコンシューマーに影響する	初日からバージョンを付ける（/v1/）

---

ドキュメントの参照（Context7）

最新のドキュメントを取得するには、mcp__context7__resolve-library-id、次に mcp__context7__query-docs を使用してください。返されたドキュメントは、記憶された知識より優先されます。

• express — ミドルウェアのパターン、ルーティング、またはリクエスト／レスポンス API の場合
• fastify — プラグインシステム、フック、またはスキーマ検証の場合
• nestjs — デコレーター、モジュール、プロバイダー、またはガードの場合
• prisma — スキーマ構文、クライアント API、またはマイグレーションコマンドの場合

---

統合ポイント

スキル	関係
senior-architect	アーキテクチャ上の決定がバックエンドサービスの境界を導きます
security-review	バックエンドのセキュリティは OWASP と認証パターンに従います
performance-optimization	バックエンドのパフォーマンスはキャッシュとクエリのチューニングを活用します
testing-strategy	バックエンドのテスト戦略が統合テストのアプローチを定めます
code-review	レビューで API 設計とエラー処理を検証します
acceptance-testing	API の動作が受け入れ条件になります
senior-fullstack	バックエンドがフルスタックの tRPC レイヤーを提供します

---

主要な原則

• 初日から API をバージョン管理します（/v1/）。
• エッジで入力を検証します（Zod、Joi、class-validator）。
• GET 以外のエンドポイントには冪等性キーを使用します。
• グレースフルシャットダウンを実装します（接続をドレインし、処理中のリクエストを完了させます）。
• 外部サービスの呼び出しにはサーキットブレーカーを使用します。
• データベースのマイグレーションはバージョン管理し、元に戻せるようにします。
• シークレットは環境変数に格納し、コードには決して含めません。

---

スキルの種類

FLEXIBLE — API のスタイルとアーキテクチャは、プロジェクトの状況に合わせて調整します。3 段階のプロセス（設計、実装、堅牢化）を強く推奨します。本番サービスでは、ヘルスチェック、構造化ログ、エラーハンドリングは必須です。