品質保証
本ドキュメントは、TASHIKAプラットフォームの品質保証に関する要件を定義します。
NOTE
IPA 6大項目に直接対応しない横断的な品質要件です。 パフォーマンス目標値は PE-001 を参照してください。
QA-001: パフォーマンス監視 (Performance Monitoring)
Performance Budget（性能予算）
| 指標 | 閾値 | 強制方法 |
|---|---|---|
| LCP | ≤ 1.5秒 | CI/CD パイプラインで自動計測。基準超過でマージをブロック |
| INP | ≤ 200ms | 同上 |
| CLS | ≤ 0.1 | 同上 |
| API P95 レスポンスタイム | → PE-001 各カテゴリ準拠 | APM アラート |
| バンドルサイズ（JS） | ≤ 300KB（gzip後、初期ロード分） | CI/CD で計測。増加時にレビュー必須 |
負荷テスト
| テスト種別 | 実施頻度 | 内容 |
|---|---|---|
| ベースライン負荷テスト | リリースごと | 通常時想定のRPSで全主要APIのレスポンスタイムを検証 |
| ピーク負荷テスト | 月次（12月〜1月は週次） | 1月ピーク想定（通常の10倍RPS）でシステム全体の耐性を検証 |
| スパイクテスト | 四半期ごと | 瞬間的な急増（通常の20倍）に対するオートスケーリングの動作を検証 |
| ソークテスト | 四半期ごと | 長時間（24時間+）の持続負荷でメモリリーク・コネクションプール枯渇を検出 |
QA-002: テスト戦略 (Testing Strategy)
カバレッジ目標
| テストレベル | カバレッジ目標 |
|---|---|
| ユニットテスト | Backend ≥ 90%, Frontend ≥ 80% |
| 統合テスト | 主要APIエンドポイント 100% |
| E2Eテスト | 主要ユーザーフロー 100% |
| アクセシビリティテスト | 全画面 |
QA-003: 可観測性 (Observability)
三本柱
| 柱 | 要件 |
|---|---|
| ログ（Logs） | 構造化ログによるイベント記録。全ログに TraceId, TenantId, UserId を付与 |
| メトリクス（Metrics） | CPU、メモリ、RPS、レスポンスタイム、キュー深度、エラー率の時系列記録 |
| トレース（Traces） | フロントエンド → API → DB クエリまでの一気通貫の分散トレーシング |
| フロントエンドエラー（Frontend Errors） | クライアントサイドの未捕捉例外・エラー境界での捕捉エラーの自動収集・集約 |
アラート体系
| 重要度 | 条件例 | 通知先 | 応答目標 |
|---|---|---|---|
| Sev1（緊急） | サービス全停止、データ不整合検出 | オンコール担当者への即時通知 | 15分以内に応答開始 |
| Sev2（重大） | API エラー率 > 5%、レスポンスタイム SLA 違反 | 運用チームへの即時通知 | 30分以内に応答開始 |
| Sev3（警告） | CPU > 80%持続、キュー滞留 > 100件 | 監視チャネルへの通知 | 次営業日対応 |
| Sev4（情報） | デプロイ完了、証明書期限30日前 | 情報チャネルへの通知 | 計画的に対応 |
障害分析
- 全リクエストに
TraceIdを付与し、障害発生時 5分以内 に根本原因（RCA）の特定に着手できる体制を構築 - ユーザーに表示されるエラー画面には
TraceIdを含め、サポート問い合わせ時の迅速な調査を可能にする
フロントエンドエラー追跡
クライアントサイドで発生するエラーを自動収集し、サーバーサイドの可観測性と統合する。
追跡対象:
| エラー種別 | 追跡方法 | 例 |
|---|---|---|
| 未捕捉例外 | window.onerror / unhandledrejection | TypeError、ReferenceError |
| Error Boundary 捕捉エラー | React Error Boundary の componentDidCatch | レンダリングエラー |
| API エラー | TanStack Query の onError コールバック | 4xx/5xx レスポンス |
| チャンク読み込みエラー | 動的 import() の reject | ChunkLoadError（デプロイ後の古いチャンク参照） |
メタデータ要件:
各エラーイベントには以下のメタデータを付与する:
traceId: バックエンドの分散トレースと紐付け可能な一意識別子userId/tenantId: ユーザー・テナントの特定（マイナンバー等の機密情報は含めない）portal: エラーが発生したポータル（employee/admin/agency/system）route: 発生画面のルートパスuserAgent: ブラウザ・OS 情報release: アプリケーションのリリースバージョン
QA-004: サプライチェーンセキュリティ (Supply Chain Security)
SBOM (Software Bill of Materials)
- ビルドごとにソフトウェア部品表（SPDX形式）を自動生成
- 既知の脆弱性（CVE）が含まれていないか自動スキャン
- Critical / High の CVE が検出された場合、マージをブロック
依存関係管理
| 対象 | ポリシー |
|---|---|
| サーバーサイド依存ライブラリ | 週次で脆弱性の自動スキャン。セキュリティアップデートは即日対応 |
| フロントエンド依存ライブラリ | 同上 |
| コンテナベースイメージ | ビルド時にスキャン。既知の脆弱性がある場合はビルド失敗 |
| ライセンス | コピーレフト（GPL等）のライブラリの混入を自動検出・ブロック |
QA-005: SLO / エラーバジェット (Service Level Objectives)
SLO 定義
| SLI (指標) | SLO (目標) | 計測期間 |
|---|---|---|
| 可用性（成功リクエスト率） | ≥ 99.9% | 30日ローリング |
| レイテンシ（API P95） | ≤ 各カテゴリ目標値 | 30日ローリング |
| エラー率（5xx） | ≤ 0.1% | 30日ローリング |
| 正確性（税計算一致率） | 100% | 年度単位 |
エラーバジェット運用
- 月間エラーバジェット = 100% − SLO（可用性の場合 0.1% = 約43分/月）
- エラーバジェット残量が 50%以下 になった場合: 新機能リリースを凍結し、信頼性改善に専念
- エラーバジェット残量が 0% になった場合: ポストモーテムを実施し、再発防止策を完了するまでリリース凍結
QA-006: コード品質ゲート (Code Quality Gates)
PRマージ条件（全て必須）
- [ ] 全テスト通過（ユニット + 統合 + E2E）
- [ ] カバレッジ閾値達成（Backend ≥ 90%, Frontend ≥ 80%）
- [ ] 静的解析 Quality Gate 通過（バグ0件、脆弱性0件、コードスメル上限以内）
- [ ] Linter/Formatter チェック通過
- [ ] 型チェック通過
- [ ] バンドルサイズ上限以内
- [ ] セキュリティスキャン通過
- [ ] レビュー1名以上承認