tech-selection-research

name	tech-selection-research
description	エンジニアの技術選定・比較調査を、要件の言語化から根拠ある推奨まで導くスキル。Claude Code 環境での利用を前提とし、各候補の調査をサブエージェント(candidate-researcher)に委譲して本線のコンテキストを汚さず進め、公式ドキュメント等の原文引用つき図解HTMLレポートにまとめる。生成後の「なぜ/もっと調べて」は該当候補の深掘りに、「修正したい」は report-revision に振り分ける。ライブラリ・フレームワーク・クラウドサービス・DB・認証方式・アーキテクチャパターンなどの選定に使う。「技術選定」「ライブラリ比較」「どれを採用すべき」「AとBどっちがいい」「〜の選び方」といった語が出たとき、また明示的に「比較して」と言われなくても複数の技術的選択肢から1つを選ぶ判断が絡む相談では必ずこのスキルを使うこと。

技術選定・比較調査(tech-selection-research)

技術選定は「情報を集める」作業ではなく「判断可能な形に情報を整理する」作業である。Claude Code での実行を前提とし、本線(オーケストレーター)は段取りと統合に徹し、重い調査はサブエージェントへ委譲して本線コンテキストを汚さない。

関連スキル/エージェント:

• 各候補の調査 → candidate-researcher サブエージェント({{HARNESS_DIR}}/agents/candidate-researcher.md)
• 裏取り → source-verification スキル(サブエージェント側で適用)
• 成果物のHTML化 → research-writeup の生成器(assets/render.py)
• 生成後の修正 → report-revision スキル

全体の流れ

1. 要件・制約の明確化(本線)
2. 候補の洗い出しと絞り込み(本線)
3. 評価軸の設定(本線)
4. 候補ごとに candidate-researcher へ委譲(並列可)
5. 返ってきたJSON断片を統合(本線)
6. トレードオフの整理(本線)
7. research-writeup で原文引用つき図解HTMLを生成(本線)
8. フォローアップ(深掘り / 修正)への対応(本線)

1. 要件・制約の明確化

何のための選定かを言語化する。要件が出ていなければ先に確認する:目的、制約(性能・スケール・予算・既存スタック・習熟度・運用・法規制)、must と want の区別、時間軸。要件が曖昧なまま候補調査に進まない。

2. 候補の洗い出しと絞り込み

must 条件で足切りし 2〜4 個に絞る。何を残し何を落としたかを記録する。

3. 評価軸の設定

既定軸を土台に案件へ合わせ、must 由来の軸に重み(◎/○/△)を付ける。既定軸:機能適合性 / 性能 / コスト(初期・運用) / 学習コスト・開発体験 / エコシステム / 保守性・将来性 / ライセンス / セキュリティ。

4. 候補ごとに委譲

候補ごとに candidate-researcher を Task で起動する。本線の全文脈は渡さない。 渡すのは:候補名 / 評価軸(重み) / must・want / JSON断片の出力パス。各サブエージェントは独立コンテキストで一次情報を原文引用しながら裏取りし、findings 用のJSON断片(主張+原文引用+バッジ+任意のscores)を書き出し、本線には要約だけを返す。独立候補は並列、相互依存があれば逐次。

5. JSON断片の統合

各サブエージェントが書いた断片を集約し、research-writeup の data.json を組み立てる:

• findings = 各候補の断片を連結
• comparison = 各断片の主要所見から要点表を作成(セルに inline 出典URL)
• positioning(任意)= scores がそろった2軸があれば設定 生の検索結果は本線に貼らない。詳細が要る候補は、その断片/HTMLを参照する。

6. トレードオフの整理

候補間の「何を取ると何を諦めるか」を言語化。must を落とす候補は理由を添えて除外。

7. HTMLレポート生成

data.json を作り、assets/render.py で生成する。原文引用(非日本語は日本語訳併記)は解説の直後にインライン表示され、末尾一括にはしない。事実と解釈は視覚分離。レーダーチャートは使わない。ファイルは調査ごとに新規作成。

8. フォローアップへの対応

生成後のレポートに対する依頼を次に振り分ける。

• 「なぜ」/「もっと調べて」/「裏付けは?」(深掘り): オーケストレーションのプロンプトと当該箇所を分析し、どの候補のどの論点かを特定して、その候補の candidate-researcher を深掘りモードで再委譲する。渡すのは対象論点のみ。返ってきた items を既存 findings にマージし、render.py で再生成する。複数箇所なら候補ごとに分けて委譲する。
• 「内容を修正したい」(修正): report-revision スキルに回す。文言・トーンなど軽い修正は report-copyeditor(安いモデル)、図解・レイアウト・構成など重い修正は report-reviser(高めのモデル)へ振り分けられる。事実の追加確認が要る修正は revision ではなく深掘りに戻す。

出力の原則

• 事実と解釈を分ける。 出典から得た事実(原文引用つき)と、こちらの推奨を区別する。
• 信頼性を最優先しつつ簡潔に。 主張は自分の言葉で短く、根拠は一次情報の原文+リンクで示す。引用は最小限。
• 不確実性を隠さない。 裏取りできていない点はバッジ(要確認/不明)で明示する。
• 要件に紐づけて推奨する。 断定できないときは条件付き推奨にし、分岐条件を示す。

コンテキスト隔離が効く理由

各サブエージェントは独立コンテキストを持ち、本線には要約とJSON断片だけを返す。調査の中間情報がサブエージェント側に閉じるため、複数候補を調べても・深掘りを重ねても本線は判断に必要な情報だけで保たれる。