---
generated_at: 2026-02-22 16:20:00
metrics:
  claims_total: 25
  claims_with_evidence: 24
  claims_without_evidence: 1
confidence_derived: 0.96
---

# 根拠レポート：23-code-to-docs.sh

## 本レポートについて

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

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

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

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

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

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.96**
  - 根拠あり：24 / 25、根拠なし：1
- 優先レビュー（高）
  1. **大規模プロジェクトの処理時間が数時間**：実行時間の推定値に根拠なし

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

- E-01: `.claude/code-to-docs.sh` - バッチスクリプト本体（1631行）
- E-02: `docs/code-to-docs/バッチ一覧/バッチ一覧.csv` - バッチ一覧定義
- E-03: `docs/code-to-docs/バッチ設計書/plan.md` - バッチ設計書生成プラン

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | スクリプトは20ステップの処理で構成される | E-01（ステップ1～20の`should_run_step`呼び出しが20個存在、ヘルプメッセージにも20ステップ記載） | ○ |
| C-02 | `set -e` で厳格なエラーハンドリングを行う | E-01（2行目 `set -e`） | ○ |
| C-03 | macOS環境で `caffeinate -dims` を使用してスリープを防止する | E-01（`exec caffeinate -dims "$0" "$@"`、`CAFFEINATED` 環境変数チェック） | ○ |
| C-04 | Node.js/Electron経由実行時のstdoutパイプ対策がある | E-01（`python3 -c "import fcntl,os; ..."`） | ○ |
| C-05 | MAX_RETRIESのデフォルト値は3である | E-01（`MAX_RETRIES=3`） | ○ |
| C-06 | RETRY_DELAYのデフォルト値は30秒で指数バックオフする | E-01（`RETRY_DELAY=30`、`delay=$((delay * 2))`） | ○ |
| C-07 | MAX_PARALLELのデフォルト値は10である | E-01（`MAX_PARALLEL=10`） | ○ |
| C-08 | `--from N`、`--only N`、`--no-confirm`等のオプションが存在する | E-01（`while [[ $# -gt 0 ]]; do case $1 in`、各オプションの処理） | ○ |
| C-09 | `--skip-optional` でセキュリティ診断・改善提案書・設計意図書をスキップできる | E-01（ステップ15、16、18で `SKIP_OPTIONAL` チェック） | ○ |
| C-10 | `--program-design` でプログラム設計書を生成できる | E-01（`PROGRAM_DESIGN=false`、ステップ5で `PROGRAM_DESIGN` チェック） | ○ |
| C-11 | `claude -p` コマンドでヘッドレスモードのエージェントを実行する | E-01（`run_agent` 関数内 `claude -p "$prompt" --allowedTools "Read,Write,Edit,Grep,Glob,Bash,Task"`） | ○ |
| C-12 | 許可されたツールはRead、Write、Edit、Grep、Glob、Bash、Taskの7種 | E-01（`--allowedTools "Read,Write,Edit,Grep,Glob,Bash,Task"`） | ○ |
| C-13 | ステップ3で5エージェント（画面・機能・バッチ・通知・帳票一覧）を並列実行する | E-01（`agents3=("code-to-docs-screen-list" "code-to-docs-function-list" "code-to-docs-batch-list" "code-to-docs-notification-list" "code-to-docs-report-list")`） | ○ |
| C-14 | ステップ6-7でrun_design_with_review関数を使用する | E-01（`run_design_with_review "screen" ...`、`run_design_with_review "function" ...`） | ○ |
| C-15 | ステップ8でAPI・バッチ・通知・帳票の4設計書を並列生成する | E-01（4つのバックグラウンドプロセス起動、`pids7` 配列） | ○ |
| C-16 | ステップ18で10エージェントの設計意図書を並列生成する | E-01（`agents17` 配列に10個のエージェント名が定義） | ○ |
| C-17 | 単体テストケースCSVの統合関数 `merge_unit_test_csvs` が存在する | E-01（`merge_unit_test_csvs()` 関数定義） | ○ |
| C-18 | レビュー結果は `.review/failed-items.json` に記録される | E-01（`failed_items_file="$REVIEW_DIR/failed-items.json"`） | ○ |
| C-19 | plan.mdのグループテーブルは `<!-- GROUPS_START -->` / `<!-- GROUPS_END -->` マーカーで囲まれる | E-01（`extract_groups_from_plan` 関数内のsedパターン）、E-03（実際のplan.mdファイル） | ○ |
| C-20 | Bash 3.2互換性のためcase文（`get_design_info`関数）を使用している | E-01（`get_design_info()` 関数のcase文実装、コメント「bash 3.2互換のcase文実装」） | ○ |
| C-21 | ステップ20で一時ファイル・レビューディレクトリ・plan.mdを削除する | E-01（ステップ20内の `rm -rf "$TMP_DIR"/*`、`rm -rf "$DOCS_DIR/.review"`、`find "$DOCS_DIR" -name "plan.md" ... xargs rm -f`） | ○ |
| C-22 | 経過時間はHH:MM:SS形式で表示される | E-01（`format_elapsed` 関数、`printf "%02d:%02d:%02d" $hours $minutes $seconds`） | ○ |
| C-23 | 色付きログ出力で情報・成功・警告・エラーを区別する | E-01（`RED`、`GREEN`、`YELLOW`、`BLUE` 等の色定義、`log_info`、`log_success`、`log_warn`、`log_error` 関数） | ○ |
| C-24 | `--review-fix TARGET` でレビュー＆欠落分再生成のみ実行できる | E-01（`REVIEW_FIX_TARGET` 変数、`run_review_fix` 関数、main関数内の条件分岐） | ○ |
| C-25 | 大規模プロジェクトでは処理に数時間かかる | **根拠なし** | △ |

## 4) 不足情報（Unknown / Missing）
- C-25: 実行時間の推定値はソースコードに明記されておらず、20ステップの逐次・並列処理とClaude API呼び出しの所要時間から推定した値である。実際の実行時間はプロジェクト規模、API応答時間、並列実行数に大きく依存する。
  - 候補：実際の実行ログから計測 / ベンチマーク実施 / 開発者へのヒアリング

## 5) リスクフラグ（レビュー観点）
- 0: 低リスク - スクリプトの全オプションとデフォルト値はソースコードから直接確認済み
- 0: 低リスク - 20ステップの処理内容はソースコードのステップ定義と一致
- 0: 低リスク - 並列実行制御（`run_workers_with_limit`）の動作はソースコードから確認済み
- 0: 低リスク - リトライ仕様（回数・遅延・指数バックオフ）はソースコードから確認済み
- 0: 低リスク - エラー処理（`set -e`、リトライ、警告継続）の動作はソースコードから確認済み
- 1: 中リスク - 処理時間の推定値は実測データなし

## 6) レビュアーチェックリスト（最小）
- [ ] 20ステップの処理内容がソースコードの実装と一致しているか
- [ ] コマンドラインオプション一覧が網羅されているか（13個のオプション）
- [ ] 並列実行の制御方式（MAX_PARALLEL、バックグラウンドプロセス管理）の記述が正確か
- [ ] リトライ仕様（MAX_RETRIES=3、指数バックオフ）の記述が正確か
- [ ] 出力ファイル一覧が実際のステップで生成されるディレクトリと一致しているか
- [ ] レビュー＆リトライ機構（run_design_with_review、retry_failed_items）の記述が正確か
- [ ] 処理時間の推定値が妥当か（実測データとの比較が望ましい）
