テクニック選択: ReAct

選択理由: 障害分析は「仮説を立てる（Thought）→ 情報を確認する（Action）→ 結果を観察する（Observation）」のサイクルが必要。ログ確認やメトリクス参照といった「行動」が必要なため、推論のみのCoTよりReActが適切。

あなたはNetShop社のSREエンジニアです。以下の障害の根本原因を分析してください。

利用可能なツール:
- check_logs(service, timerange): サービスのログを取得
- check_metrics(metric_name, timerange): メトリクスを取得
- check_deploy_history(timerange): デプロイ履歴を取得
- check_external_service(service_name): 外部サービスのステータス確認
- run_command(command): サーバー上でコマンドを実行

障害情報:
時刻: 2026-03-05 10:30
症状: 決済完了後の注文確認メールが届かない
影響範囲: 全ユーザー
関連メトリクス:
- メール送信キュー: 5,000件滞留（通常: 0-10件）
- SMTPサーバー接続: タイムアウトエラー 100%
- アプリケーションサーバーCPU: 45%（正常）
- メモリ使用率: 60%（正常）
- 直前のデプロイ: 10:15にメール送信テンプレート更新を実施
- SES送信クォータ: 50,000/日（残り48,000）

以下のフォーマットで分析してください:

Thought 1: [初期仮説]
Action 1: [確認する情報]
Observation 1: [確認結果]

（繰り返し）

Root Cause: [根本原因]
Impact: [影響範囲と深刻度]
Immediate Action: [即座に実行すべき対処]
Prevention: [再発防止策]
Timeline: [障害タイムライン]

ポイント:

• ツール定義が具体的で実行可能
• 出力フォーマットに根本原因だけでなく、対処と再発防止も含めている
• 10

テクニック選択: Tree of Thoughts（ToT）

選択理由: 技術選定は複数の候補を多角的に評価し、最適解を選ぶ「設計的な問題」。各候補をツリーの枝として展開し、段階的に評価・選別するToTが最適。

あなたはNetShop社のテックリードです。検索機能の技術選定をTree of Thoughts形式で分析してください。

背景:
- 現在: PostgreSQL LIKE検索（平均レスポンス3秒）
- 商品数: 100万件、月間検索クエリ: 500万回
- チーム: バックエンドエンジニア5名（Elasticsearch経験者1名）
- 予算: 月額50万円以内

Step 1: 各候補技術の特徴を整理してください。
候補: Elasticsearch / OpenSearch / Algolia / Meilisearch

各候補について:
- 概要（1-2行）
- 強み
- 弱み

Step 2: 以下の5軸で各候補を1-5点で定量評価してください。

| 評価軸 | 重み | Elasticsearch | OpenSearch | Algolia | Meilisearch |
|--------|------|--------------|------------|---------|-------------|
| パフォーマンス | 30% | | | | |
| コスト（月額） | 25% | | | | |
| 運用負荷 | 20% | | | | |
| 学習コスト | 15% | | | | |
| スケーラビリティ | 10% | | | | |

Step 3: 加重スコアを計算し、上位2候補を選出してください。

Step 4: 上位2候補について、NetShop社の具体的な状況を踏まえて最終判定してください。
以下の観点で深掘り分析:
- 既存チームのスキルセットとの親和性
- 移行コストと移行期間の見積もり
- 3年後の拡張性

最終出力:
{
  "recommendation": "推奨技術",
  "score": "加重スコア",
  "reason": "選定理由（3行以内）",
  "migration_plan": "移行の概要",
  "estimated_cost": "月額コスト",
  "risks": ["リスク1", "リスク2"],
  "next_steps": ["次のアクション1", "次のアクション2"]
}

ポイント:

• ToTの4ステップ（特徴整理→定量評価→上位選出→深掘り分析）で段階的に絞り込み
• 評価軸に重みを設定して定量的な比較を実現
• NetShop社固有の条件（チーム構成、予算）を反映

Step 1: 分析・評価メタプロンプト

あなたはプロンプトエンジニアリングの専門家です。
以下のチャットボット用プロンプトを10項目で分析してください。

対象プロンプト:
「あなたはNetShop社のサポートスタッフです。お客様の質問に丁寧に回答してください。」

分析項目（各1-5点で評価）:
1. 役割定義の具体性
2. 回答スタイルの指定
3. 回答長の制約
4. 禁止事項の定義
5. ハルシネーション防止策
6. エスカレーション基準
7. 対応範囲の明確さ
8. 出力形式の指定
9. コンテキスト活用の指示
10. 安全性ガード

出力形式:
| # | 項目 | 点数 | 問題点 | 改善提案 |
|---|------|------|--------|---------|

合計スコア: /50
改善優先度トップ3: [項目名]

Step 2: 改善版生成メタプロンプト

以下の分析結果に基づいて、改善版のシステムプロンプトを生成してください。

分析結果: [Step 1の出力を挿入]

改善版プロンプトの要件:
- 500文字以内
- 役割、制約、禁止事項、エスカレーション基準を明確に含める
- 在庫・価格の質問には「システムで確認します」と応答し、推測しないよう指示
- 回答は3文以内を基本とする
- エスカレーション基準（クレーム、返金要求、技術的問題）を定義

出力形式:
1. 改善版システムプロンプト
2. 改善前後の比較表
3. 各改善ポイントの根拠

Step 3: テストケース

テストケース1: 在庫確認（ハルシネーション防止の検証）
ユーザー入力: 「iPhone 15 Proの在庫はありますか？」
期待出力: 推測せず在庫システムの確認を案内する
NG出力: 「はい、在庫がございます」と推測で回答する

テストケース2: クレーム対応（エスカレーション基準の検証）
ユーザー入力: 「3回も不良品が届いた。もう二度と使わない。責任者と話したい。」
期待出力: 謝罪した上でオペレーターへエスカレーションする
NG出力: チャットボットだけで対応しようとする

テストケース3: 回答の簡潔さ（冗長性の検証）
ユーザー入力: 「返品の期限は？」
期待出力: 「商品到着後30日以内です。返品手続きはこちらから...」（3文以内）
NG出力: 返品ポリシーの全文を長文で回答する

ポイント:

• 分析→改善→検証の3ステップで体系的なアプローチ
• テストケースに「期待出力」と「NG出力」の両方を定義
• 具体的な課題（冗長性、ハルシネーション、エスカレーション漏れ）に対応