---
generated_at: 2026-03-01 20:45:00
metrics:
  claims_total: 46
  claims_with_evidence: 43
  claims_without_evidence: 3
confidence_derived: 0.93
---

# 根拠レポート：plugin-sentry.csv

## 本レポートについて

### 目的
本レポートは、生成された単体テストケース一覧の信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.93**
  - 根拠あり：43 / 46、根拠なし：3
- 優先レビュー（高）
  1. **C-37**：AdminErrorBoundaryのエラーキャプチャ動作（Sentry内部実装依存）
  2. **C-38**：childrenがnullの場合の挙動（Reactの一般的挙動に依存）
  3. **C-23**：X-Forwarded-Forヘッダーの取得（ランタイム環境依存）

## 2) 参照した情報（Evidence一覧）
> ここに「実在するもの」だけ列挙。抽出フェーズで付けたIDをそのまま出す。

- E-01: `packages/plugin-sentry/src/index.ts` - sentryPlugin関数の実装（L1-93）
- E-02: `packages/plugin-sentry/src/types.ts` - PluginOptions、SentryInstance型定義（L1-47）
- E-03: `packages/plugin-sentry/src/providers/AdminErrorBoundary.tsx` - ErrorBoundaryコンポーネント（L1-13）
- E-04: `packages/plugin-sentry/src/exports/client.ts` - クライアントエクスポート（L1-2）
- E-05: `packages/plugin-sentry/src/plugin.spec.ts` - 既存の単体テスト（L1-123）
- E-06: `packages/plugin-sentry/package.json` - パッケージ依存関係

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | プラグインが有効時にConfig拡張されること | E-01 (L29-92), E-05 (L18-23) | ○ |
| C-02 | enabledがデフォルトでtrueになること | E-01 (L32), E-05 (L25-30) | ○ |
| C-03 | AdminErrorBoundaryがprovidersに追加されること | E-01 (L43-50) | ○ |
| C-04 | 既存のprovidersが保持されること | E-01 (L47) | ○ |
| C-05 | 既存のafterErrorフックが保持されること | E-01 (L53-54) | ○ |
| C-06 | 既存のadmin設定が保持されること | E-01 (L42-51) | ○ |
| C-07 | enabledがfalseの場合プラグインが実行されないこと | E-01 (L34-36), E-05 (L39-44) | ○ |
| C-08 | Sentryが提供されない場合プラグインが実行されないこと | E-01 (L34-36), E-05 (L32-37) | ○ |
| C-09 | Sentryがundefinedの場合プラグインが実行されないこと | E-01 (L34) | ○ |
| C-10 | 空のオプションオブジェクトの場合プラグインが実行されないこと | E-01 (L34) | ○ |
| C-11 | 500エラーでSentry.captureExceptionが呼ばれること | E-01 (L57), E-05 (L46-106) | ○ |
| C-12 | statusが未定義の場合500として扱われること | E-01 (L56) | ○ |
| C-13 | 501エラーでキャプチャされること | E-01 (L57) | ○ |
| C-14 | 503エラーでキャプチャされること | E-01 (L57) | ○ |
| C-15 | captureErrorsに含まれる400エラーがキャプチャされること | E-01 (L57) | ○ |
| C-16 | captureErrorsに含まれる403エラーがキャプチャされること | E-01 (L57) | ○ |
| C-17 | captureErrorsに含まれない400系エラーはキャプチャされないこと | E-01 (L57) | ○ |
| C-18 | 404エラーがデフォルトでキャプチャされないこと | E-01 (L38, L57) | ○ |
| C-19 | ステータス499でキャプチャされないこと | E-01 (L57) | ○ |
| C-20 | ステータス500でキャプチャされること | E-01 (L57) | ○ |
| C-21 | コンテキストにcollection.slugが含まれること | E-01 (L59-61), E-05 (L79-84) | ○ |
| C-22 | ユーザー情報がコンテキストに含まれること | E-01 (L62-70) | ○ |
| C-23 | X-Forwarded-ForがIPアドレスとして設定されること | E-01 (L67) | △ |
| C-24 | ユーザーがない場合userコンテキストが含まれないこと | E-01 (L62) | ○ |
| C-25 | X-Forwarded-Forヘッダーがない場合ip_addressがundefinedになること | E-01 (L67) | ○ |
| C-26 | collectionがundefinedの場合errorCollectionSlugがundefinedになること | E-01 (L60) | ○ |
| C-27 | カスタムcontext関数が呼ばれること | E-01 (L73-78), E-05 (L52-58) | ○ |
| C-28 | カスタムcontext関数にdefaultContextが渡されること | E-01 (L74-77) | ○ |
| C-29 | カスタムcontext関数にreq, error, collectionが渡されること | E-01 (L75-76) | ○ |
| C-30 | 非同期のカスタムcontext関数がサポートされること | E-01 (L74), E-02 (L31) | ○ |
| C-31 | debugがtrueの場合ログが出力されること | E-01 (L82-86) | ○ |
| C-32 | ログメッセージにexceptionIDとエラーメッセージが含まれること | E-01 (L83-85) | ○ |
| C-33 | debugがfalseの場合ログが出力されないこと | E-01 (L38, L82) | ○ |
| C-34 | captureExceptionの戻り値（eventID）が取得できること | E-01 (L80) | ○ |
| C-35 | childrenが正しくレンダリングされること | E-03 (L10-12) | ○ |
| C-36 | SentryのErrorBoundaryがラップされること | E-03 (L5, L11) | ○ |
| C-37 | 子コンポーネントでエラーが発生した場合ErrorBoundaryがキャッチすること | E-03 (L11) | △ |
| C-38 | childrenがnullの場合もエラーにならないこと | E-03 | △ |
| C-39 | enabledプロパティがオプショナルであること | E-02 (L17) | ○ |
| C-40 | optionsプロパティがオプショナルであること | E-02 (L21) | ○ |
| C-41 | options.captureErrorsがnumber[]型であること | E-02 (L27) | ○ |
| C-42 | options.contextが同期関数として機能すること | E-02 (L31) | ○ |
| C-43 | options.contextが非同期関数として機能すること | E-02 (L31) | ○ |
| C-44 | options.debugがオプショナルでbooleanであること | E-02 (L36) | ○ |
| C-45 | captureExceptionメソッドが必須であること | E-02 (L5) | ○ |
| C-46 | AdminErrorBoundaryがエクスポートされること | E-04 (L1) | ○ |

## 4) 不足情報（Unknown / Missing）
- C-23: X-Forwarded-Forヘッダーの取得はランタイム環境に依存。Next.jsのリクエストオブジェクトの実装によって挙動が異なる可能性がある
  - 候補：Next.jsドキュメント / PayloadのRequest型定義 / 実環境でのテスト
- C-37: Sentry ErrorBoundaryの内部実装に依存するため、実際のエラーキャプチャ動作の確認が必要
  - 候補：@sentry/nextjsのドキュメント / 統合テスト
- C-38: Reactの一般的なchildren処理に依存、明示的なnull処理コードは存在しない
  - 候補：Reactドキュメント / 実機テスト

## 5) リスクフラグ（レビュー観点）
- 0: 低リスク - 型定義の確認テスト（C-39〜C-45）は静的解析で十分確認可能
- 1: 中リスク - afterErrorフックの各種条件分岐テスト（C-11〜C-34）はモック実装で検証可能だが、本番Sentryとの統合確認が推奨
- 2: 高リスク - AdminErrorBoundaryのエラーキャプチャ（C-37）はSentry依存のため、E2Eテストでの確認が必須

## 6) レビュアーチェックリスト（最小）
- [ ] 既存テスト（plugin.spec.ts）との重複・整合性を確認
- [ ] captureErrorsの境界値テスト（499, 500）が適切か確認
- [ ] AdminErrorBoundaryのReact固有挙動（childrenがnull/undefined時）の検証方針を決定
- [ ] カスタムcontext関数のエラー処理（例外スロー時）のテストケース追加要否を検討
- [ ] Sentry.captureExceptionの戻り値を活用するユースケースの有無を確認
