選定パターン: ReAct

理由:

• 問い合わせ内容によって次のアクションが動的に変わる（配送遅延なのか、配送トラブルなのかで対応が異なる）
• 各ステップの結果を見て判断を変更する必要がある（在庫があれば代替品発送、なければ返金提案）
• 探索的な要素が強く、事前に全手順を確定できない

行動フロー:

Thought: 注文ORD-98765の状況を確認する必要がある
Action: search_orders(order_id="ORD-98765")
Observation: {status: "shipped", shipped_date: "2026-02-28"}

Thought: 発送済みだが届いていない。配送状況を追跡しよう
Action: track_shipment(order_id="ORD-98765")
Observation: {status: "配送トラブル", reason: "住所不明で持ち戻り"}

Thought: 配送トラブルだ。顧客は代替品を希望している。在庫を確認しよう
Action: check_inventory(product_id="PROD-001")
Observation: {available: true, stock: 15}

Thought: 在庫あり。代替品の発送を手配しよう
Action: create_replacement_order(original_order="ORD-98765")
Observation: {new_order_id: "ORD-99001", estimated_delivery: "2026-03-08"}

Thought: 代替品を手配できた。顧客に通知しよう
Action: send_notification(customer_id="...", message="...")
Observation: {sent: true}

Final Answer: 配送トラブル（住所不明で持ち戻り）が発生しておりました。
代替品（注文番号: ORD-99001）を手配しました。3月8日にお届け予定です。

エラーケース対処:

• 在庫切れ → 返金処理を提案し、process_refund ツールを使用
• 追跡番号不明 → 配送業者に直接問い合わせるよう案内
• 代替品発送失敗 → 手動対応にエスカレーション

選定パターン: Plan-and-Execute

理由:

• 処理手順が事前に明確に定義できる（データ取得→集計→比較→レポート）
• 複数のデータソースから順序立ててデータを収集する必要がある
• 一部のデータ取得は並列実行可能（効率化）
• 毎月同じフローを実行するため、計画をテンプレート化できる

計画（サブタスク分解）:

Plan:
  Phase 1: データ収集（並列実行可能）
    Step 1a: query_sales_db(period="2026-02")
    Step 1b: query_access_logs(period="2026-02")
    Step 1c: query_cs_tickets(period="2026-02")

  Phase 2: 比較データ収集（並列実行可能）
    Step 2a: query_sales_db(period="2026-01")  # 前月
    Step 2b: query_sales_db(period="2025-02")  # 前年同月

  Phase 3: KPI計算（Phase 1, 2完了後）
    Step 3a: calculate_kpi(data=phase1_results, type="current")
    Step 3b: calculate_kpi(data=phase2_results, type="comparison")

  Phase 4: レポート生成
    Step 4a: generate_chart_data(kpi_data=phase3_results)
    Step 4b: format_report(all_data=collected_results)

リプランニング方針:

• 売上DB接続エラー → 3回リトライ後、キャッシュされた前日のデータを使用
• アクセスログDB不可 → 売上データのみでレポートを生成し、アクセスログ部分は「データ取得不可」と表記
• KPI計算エラー → 該当KPIをスキップし、利用可能なデータのみでレポート生成

選定パターン: Reflection（Critic-Generator型）

理由:

• レビューの品質そのものが重要（不正確なレビューは開発者の信頼を失う）
• 初回レビューを自己評価し、誤検出（False Positive）を減らすことができる
• レビューコメントの表現も改善する必要がある（建設的なフィードバック）
• コード分析の結果を多角的に評価する必要がある

レビュープロセス:

Phase 1: データ収集
  → get_pr_diff → analyze_code → check_test_coverage

Phase 2: 初期レビュー生成（Generator）
  → 各観点でレビューコメントを生成
  → 重要度（Critical / Warning / Info）を付与

Phase 3: 自己評価（Critic）
  → 各コメントの妥当性を評価
  → 「このコメントは本当に正確か？」
  → 「開発者にとって建設的か？」
  → 「コンテキストを考慮しているか？」
  → 評価スコア: 85/100以上で投稿

Phase 4: 改善（必要な場合）
  → 誤検出の除去
  → コメント表現の改善
  → 優先度の再調整

Phase 5: 投稿
  → post_review_comment で各コメントを投稿

品質評価基準: