---
generated_at: 2026-02-24 23:30:00
metrics:
  claims_total: 42
  claims_with_evidence: 40
  claims_without_evidence: 2
confidence_derived: 0.95
---

# 根拠レポート: コードリーディングガイドライン

## 本レポートについて

### 目的
本レポートは、生成された設計書・ドキュメントの信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

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

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

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

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

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）: **0.95**
  - 根拠あり: 40 / 42、根拠なし: 2
- 優先レビュー（高）
  1. **デバッグ手法の詳細**: 具体的なデバッグ設定方法の検証が必要
  2. **全モジュール数の正確性**: 「30以上」の正確なカウント要確認

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

- E-01: `package.json` - ルートパッケージ設定
- E-02: `_tsconfig.base.json` - TypeScript基本設定
- E-03: `CLAUDE.md` - 開発ガイドライン
- E-04: `packages/core/core-flows/src/promotion/steps/delete-promotions.ts` - ステップ定義例
- E-05: `packages/core/core-flows/src/promotion/workflows/delete-promotions.ts` - ワークフロー定義例
- E-06: `packages/core/core-flows/src/order/workflows/update-order.ts` - 注文更新ワークフロー
- E-07: `packages/medusa/src/api/admin/orders/route.ts` - 注文APIルート
- E-08: `packages/medusa/src/api/admin/orders/validators.ts` - バリデーター定義
- E-09: `packages/modules/api-key/src/services/api-key-module-service.ts` - サービス実装例
- E-10: `packages/modules/order/src/services/order-module-service.ts` - 注文サービス
- E-11: `packages/modules/product/src/models/product.ts` - プロダクトモデル
- E-12: `packages/modules/order/src/models/order.ts` - 注文モデル
- E-13: `packages/medusa/src/api/middlewares.ts` - ミドルウェア定義
- E-14: `packages/medusa/src/subscribers/payment-webhook.ts` - サブスクライバー例
- E-15: `packages/core/utils/src/modules-sdk/medusa-internal-service.ts` - 内部サービス基盤
- E-16: `packages/core/types/src/http/common/request.ts` - HTTP型定義
- E-17: `packages/` ディレクトリ構造 - モノレポ構成
- E-18: `packages/modules/` ディレクトリ - モジュール一覧
- E-19: `packages/modules/providers/` ディレクトリ - プロバイダー一覧
- E-20: `README.md` - プロジェクト概要

## 3) Claims と根拠の対応（レビューの主戦場）

| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | TypeScriptがES2021をターゲットとしている | E-02 | ○ |
| C-02 | Yarn 3.2.1をパッケージマネージャーとして使用 | E-01 | ○ |
| C-03 | MedusaServiceパターンでモジュールサービスを構築 | E-09, E-10 | ○ |
| C-04 | DMLを使用してエンティティを定義 | E-11, E-12 | ○ |
| C-05 | createStepでステップを定義 | E-04 | ○ |
| C-06 | createWorkflowでワークフローを定義 | E-05, E-06 | ○ |
| C-07 | StepResponseで結果と補償データを返却 | E-04 | ○ |
| C-08 | @InjectManager()デコレーターをパブリックメソッドに使用 | E-09 | ○ |
| C-09 | @InjectTransactionManager()をprotectedメソッドに使用 | E-09 | ○ |
| C-10 | @EmitEvents()でイベントを発行 | E-09 | ○ |
| C-11 | @MedusaContext()でコンテキストを注入 | E-09, E-10 | ○ |
| C-12 | APIルートはHTTPメソッド名でエクスポート | E-07 | ○ |
| C-13 | Zodを使用してバリデーションを実装 | E-08 | ○ |
| C-14 | モジュールはcontainer.resolveで解決 | E-04, E-14 | ○ |
| C-15 | ファイル命名はkebab-caseを使用 | E-04, E-07, E-09 | ○ |
| C-16 | インターフェースはIプレフィックスを使用 | E-04, E-10 | ○ |
| C-17 | protectedメソッドはアンダースコアサフィックスを使用 | E-09 | ○ |
| C-18 | MedusaErrorで統一されたエラーハンドリング | E-06, E-15 | ○ |
| C-19 | softDeleteで論理削除を実装 | E-04 | ○ |
| C-20 | useQueryGraphStepでデータ取得 | E-06 | ○ |
| C-21 | transformでデータ変換 | E-06 | ○ |
| C-22 | whenで条件分岐 | E-06 | ○ |
| C-23 | parallelizeで並列実行 | E-06 | ○ |
| C-24 | emitEventStepでイベント発行 | E-06 | ○ |
| C-25 | defineMiddlewaresでミドルウェアを定義 | E-13 | ○ |
| C-26 | SubscriberConfigでサブスクライバーを設定 | E-14 | ○ |
| C-27 | model.id()でプライマリキーを定義 | E-11, E-12 | ○ |
| C-28 | model.hasMany()で1対多リレーションを定義 | E-11, E-12 | ○ |
| C-29 | model.belongsTo()で多対1リレーションを定義 | E-11 | ○ |
| C-30 | model.manyToMany()で多対多リレーションを定義 | E-11 | ○ |
| C-31 | cascadesで削除時の連鎖動作を定義 | E-11, E-12 | ○ |
| C-32 | indexesでデータベースインデックスを定義 | E-11, E-12 | ○ |
| C-33 | AuthenticatedMedusaRequestで認証済みリクエストを型付け | E-07 | ○ |
| C-34 | MedusaResponseでレスポンスを型付け | E-07 | ○ |
| C-35 | req.filterableFieldsでフィルター条件を取得 | E-07 | ○ |
| C-36 | req.queryConfig.paginationでページネーション情報を取得 | E-07 | ○ |
| C-37 | WorkflowResponseでワークフロー結果を返却 | E-05, E-06 | ○ |
| C-38 | createHookでワークフローフックを作成 | E-05 | ○ |
| C-39 | 30以上のコマースモジュールが存在 | E-18 | △ |
| C-40 | 15以上のプロバイダー実装が存在 | E-19 | ○ |
| C-41 | モジュラーモノリスアーキテクチャを採用 | E-03, E-20 | ○ |
| C-42 | デバッグ時のWorkflowManagerデバッグモード | **根拠なし** | △ |

## 4) 不足情報（Unknown / Missing）
- **モジュール数の正確なカウント**: E-18ディレクトリ一覧から35モジュール程度を確認したが、「30以上」という表現は保守的な記述として適切かどうか要確認
  - 候補: モジュールディレクトリの完全なカウント / 公式ドキュメントの参照
- **WorkflowManagerのデバッグモード**: デバッグセクションで言及しているが、具体的な設定方法のソースコード根拠が不足
  - 候補: `packages/core/orchestration/` の調査 / 公式ドキュメント参照

## 5) リスクフラグ（レビュー観点）
- **0 (低リスク)**: 基本的なコード構造、命名規則、パターン説明は全てソースコードから直接引用
- **0 (低リスク)**: ディレクトリ構造は実際のファイルシステムを確認済み
- **1 (中リスク)**: デバッグ手法のセクションは一般的なアドバイスを含み、具体的な設定方法の検証が推奨される
- **0 (低リスク)**: コード例は全て実在するファイルから引用し、ファイルパスと行番号を明示

## 6) レビュアーチェックリスト（最小）
- [ ] コード例のファイルパスと行番号が現在のコードベースと一致するか確認
- [ ] デコレーターパターンの説明が実際の動作と整合するか確認
- [ ] ワークフロー/ステップパターンの説明が最新の実装と一致するか確認
- [ ] 「30以上のモジュール」の表現が正確か確認（実際にカウント）
- [ ] デバッグセクションの内容を開発チームがレビュー
- [ ] 用語集の定義が社内で統一されているか確認
