product-analysis

製品分析

Claude Code エージェントチームとCodex CLIを組み合わせ、モデルをまたいだテスト時計算スケーリングを行う、複数経路による並列製品分析です。

基本原則：同じ分析タスクに対し、複数の AI の視点から検討し、深く統合します。

仕組み

/product-analysis full
         │
         ├─ Step 0: Auto-detect available tools (codex? competitors?)
         │
    ┌────┼──────────────┐
    │    │              │
 Claude Code         Codex CLI (auto-detected)
 Task Agents         (background Bash)
 (Explore ×3-5)      (×2-3 parallel)
    │                   │
    └────────┬──────────┘
             │
      Synthesis (main context)
             │
      Structured Report

ステップ 0：利用可能なツールを自動検出する

エージェントを起動する前に、利用可能なツールを検出します。

# Check if Codex CLI is installed
which codex 2>/dev/null && codex --version

判定ロジック：

• codex が見つかった場合：ユーザーに「Codex CLI を検出しました（バージョン X）。より幅広い視点を得るため、モデルをまたいだ分析を実行します。」と伝えます。
• codex が見つからない場合：ユーザーに何も尋ねず、Claude Code エージェントのみで処理を続行します。ユーザーにインストールを促してはいけません。

エージェントのプロンプトを調整するため、プロジェクトの種類も検出します。

# Detect project type
ls package.json 2>/dev/null    # Node.js/React
ls pyproject.toml 2>/dev/null  # Python
ls Cargo.toml 2>/dev/null      # Rust
ls go.mod 2>/dev/null          # Go

スコープモード

$ARGUMENTS を解析して、分析のスコープを決定します。

スコープ	対象範囲	通常のエージェント数
full	UX + API + アーキテクチャ + ドキュメント（デフォルト）	Claude 5 件 + Codex（利用可能な場合）
ux	フロントエンドのナビゲーション、情報密度、ユーザージャーニー、空の状態、オンボーディング	Claude 3 件 + Codex（利用可能な場合）
api	バックエンド API の網羅性、エンドポイントの健全性、エラー処理、一貫性	Claude 2 件 + Codex（利用可能な場合）
arch	モジュール構成、依存関係グラフ、コードの重複、関心の分離	Claude 2 件 + Codex（利用可能な場合）
compare X Y	自己監査 + 競合ベンチマーク（/competitors-analysis を呼び出します）	Claude 3 件 + competitors-analysis

フェーズ 1：並行調査

Task ツールを使用して、すべての調査エージェントを同時に起動します（バックグラウンドモード）。

Claude Code エージェント（常に実行）

各観点について、subagent_type: Explore および run_in_background: true を指定して Task エージェントを起動します。

エージェント A — フロントエンドのナビゲーションと情報密度

Explore the frontend navigation structure and entry points:
1. App.tsx: How many top-level components are mounted simultaneously?
2. Left sidebar: How many buttons/entries? What does each link to?
3. Right sidebar: How many tabs? How many sections per tab?
4. Floating panels: How many drawers/modals? Which overlap in functionality?
5. Count total first-screen interactive elements for a new user.
6. Identify duplicate entry points (same feature accessible from 2+ places).
Give specific file paths, line numbers, and element counts.

エージェント B — ユーザージャーニーと空の状態

Explore the new user experience:
1. Empty state page: What does a user with no sessions see? Count clickable elements.
2. Onboarding flow: How many steps? What information is presented?
3. Prompt input area: How many buttons/controls surround the input box? Which are high-frequency vs low-frequency?
4. Mobile adaptation: How many nav items? How does it differ from desktop?
5. Estimate: Can a new user complete their first conversation in 3 minutes?
Give specific file paths, line numbers, and UX assessment.

エージェント C — バックエンド API と健全性

Explore the backend API surface:
1. List ALL API endpoints (method + path + purpose).
2. Trace frontend, CLI, integration and documented external/API consumers. Mark unused only with consumer and lifecycle evidence; otherwise report coverage unknown.
3. Check error handling consistency (do all endpoints return structured errors?).
4. Check authentication/authorization patterns (which endpoints require auth?).
5. Identify any endpoints that duplicate functionality.
Give specific file paths and line numbers.

エージェント D — アーキテクチャとモジュール構成（full／arch スコープのみ）

Explore the module structure and dependencies:
1. Map the module dependency graph (which modules import which).
2. Identify circular dependencies or tight coupling.
3. Find code duplication across modules (same pattern in 3+ places).
4. Check separation of concerns (does each module have a single responsibility?).
5. Identify dead code or unused exports.
Give specific file paths and line numbers.

エージェント E — ドキュメントと設定の一貫性（full スコープのみ）

Explore documentation and configuration:
1. Compare README claims vs actual implemented features.
2. Check config file consistency (base.yaml vs .env.example vs code defaults).
3. Find outdated documentation (references to removed features/files).
4. Check test coverage gaps (which modules have no tests?).
Give specific file paths and line numbers.

Codex CLI エージェント（自動検出）

ステップ 0 で Codex CLI が検出された場合は、バックグラウンドの Bash を介して Codex 分析を並行して起動します。

各 Codex の呼び出しには、異なるモデルの視点から、同じ観点別のプロンプトを渡します。

codex -m o4-mini \
  -c model_reasoning_effort="high" \
  --full-auto \
  "Analyze the frontend navigation structure of this project. Count all interactive elements visible to a new user on first screen. Identify duplicate entry points where the same feature is accessible from 2+ places. Give specific file paths and counts."

主要な観点ごとに 1 つずつ、Codex コマンドを 2～3 件並行して実行します（バックグラウンドの Bash）。

重要：Codex はプロジェクトの作業ディレクトリで実行され、ファイルシステム全体にアクセスできます。--full-auto フラグ（古いバージョンの場合は --dangerously-bypass-approvals-and-sandbox）を指定すると、自律的に実行できます。

フェーズ 2：競合ベンチマーク（compare スコープのみ）

スコープが compare の場合は、競合ごとに competitors-analysis スキルを呼び出します。

Use the Skill tool to invoke: /competitors-analysis {competitor-name} {competitor-url}

これは、以下を処理する直交的な competitors-analysis スキルに処理を委ねます。

• リポジトリのクローンと検証
• 根拠に基づくコード分析（ファイル名と行番号の引用）
• 競合プロファイルの生成

フェーズ 3：統合

すべてのエージェントの処理が完了したら、メインの会話コンテキストで調査結果を統合します。

相互検証

統合方法を使用して、エージェント間の調査結果を比較します。一致点と相違点はレビューの手がかりとして扱い、重要な主張は、元の情報源または該当する利用者について再現可能な観察結果と照合して検証します。確信度は、投票数やモデルの種類ではなく、測定の妥当性、スコープの網羅性、証拠の独立性に基づいて判断します。件数を合算する前に、スコープの違いを調整します。件数はタスクで摩擦が生じる可能性のある箇所を特定するために使い、ユーザビリティやビジネスへの影響を主張する前に、タスクへの影響を検証します。

定量化

エージェントのレポートから具体的な数値を抽出します。

指標	測定内容
最初の画面に表示されるインタラクティブ要素	新規ユーザーに表示されるボタン／リンク／入力欄の合計数
機能のエントリーポイントの重複	2 つ以上のエントリーポイントを持つ機能の数
API 利用者のカバレッジ	CLI／統合機能／外部クライアントを含む、利用者が確認されたルート、未使用が確認されたルート、不明なカバレッジ
最初の価値を得るまでのオンボーディング手順	起動から最初のアクションが正常に完了するまでの手順数
モジュール結合度スコア	循環依存または双方向依存の数

構造化された出力

階層化された最適化レポートを作成します。

## Product Analysis Report

### Executive Summary
[1-2 sentences: key finding]

### Quantified Findings
| Metric | Value | Assessment |
|--------|-------|------------|
| ... | ... | ... |

### P0: Critical (block launch)
[Issues that prevent basic usability]

### P1: High Priority (launch week)
[Issues that significantly degrade experience]

### P2: Medium Priority (next sprint)
[Issues worth addressing but not blocking]

### Cross-Model Insights
[Findings that only one model identified — worth investigating]

### Competitive Position (if compare scope)
[How we compare on key dimensions]

ワークフローのチェックリスト

• $ARGUMENTS を解析して対象範囲を確認する
• Codex CLI の利用可否を自動検出する（which codex）
• プロジェクトの種類を自動検出する（package.json／pyproject.toml など）
• Claude Code Explore エージェントを起動する（3～5 個を並列でバックグラウンド実行）
• 検出された場合、Codex CLI コマンドを起動する（2～3 個を並列でバックグラウンド実行）
• 対象範囲が compare の場合、/competitors-analysis を呼び出す
• すべてのエージェントの結果を収集する
• 調査結果を相互検証する
• 指標を定量化する
• P0／P1／P2 の優先度を付けた構造化レポートを作成する

参考資料

• references/analysis_dimensions.md — 監査対象の各側面の詳細な定義とプロンプト
• references/synthesis_methodology.md — 複数エージェントの調査結果の重み付けと統合方法
• references/codex_patterns.md — Codex CLI の呼び出しパターンとフラグのリファレンス