--- name: tech-researcher description: > 技術・ライブラリ・フレームワーク・ツールについて、Web検索ベースで包括的にリサーチし 構造化レポートを返すスキル。コードベースの存在は前提としない。 「Xってどんな技術？」「Xの最近の状況は？」「XとYどっちがいい？」 「Xを採用してる企業の事例を知りたい」「Xのエコシステムの成熟度は？」 といった技術調査全般に使う。 ユーザーが技術名を挙げて「調べて」「教えて」「比較して」と言ったらトリガーすべき。 具体的なコードベースへの導入判断は tech-fit-analyzer の領域だが、 技術そのものの理解・比較・動向把握はこのスキルの担当。 「最近話題のXって何？」のようなカジュアルな質問でも発動してよい。 argument-hint: "<技術名 [技術名2 ...]>" context: fork --- # Tech Researcher 技術・ライブラリ・フレームワーク・ツールについて、Web検索をベースに 包括的なリサーチを行い、構造化されたレポートとして返す。 コードベースの存在を前提としない。「この技術は何か？」「今どういう状況か？」 「他と比べてどうか？」という純粋な技術調査に特化している。 特定のコードベースへの導入判断が必要な場合は tech-fit-analyzer を使う。 このスキルはその前段階の「技術そのものを理解する」フェーズを担当する。 ## 実行モデル このスキルは `context: fork` で実行される。つまり、メインの会話とは独立した フォーク・コンテキスト上でスキル全体が走る。会話履歴は引き継がないため、 必要な情報（調査対象の技術名、動機、深さ）は `$ARGUMENTS` 経由で受け取る。 比較モードなど複数技術を並列に調べる場合は、このフォーク・コンテキストの中から さらに子サブエージェント（Agent ツール）を生成して並列リサーチを行う。 ``` フォーク・コンテキスト（このスキル） ├─ ステップ1: コンテキストの把握 ├─ ステップ2: 子サブエージェントによる並列リサーチ │ ├─ Agent（技術A のリサーチ） │ ├─ Agent（技術B のリサーチ） ← 比較モード時のみ │ └─ ... ├─ ステップ3: 統合・分析 └─ ステップ4: レポート出力 → メイン会話に返却 ``` --- ## ステップ1：コンテキストの把握 `$ARGUMENTS` から以下の情報を抽出する。 情報が不足している場合は、妥当なデフォルトを推測して進める （フォーク・コンテキストではユーザーに再質問できないため）。 ### 必須情報 - **調査対象**: 技術名（1つまたは複数） - **動機**: なぜ調べたいのか（純粋な興味？導入検討の事前調査？トレンド把握？） ### モードの判定 ユーザーの意図から、以下のどちらかを判定する： | モード | トリガー例 | 説明 | |--------|-----------|------| | **単体リサーチ** | 「Xについて調べて」「Xの最新状況は？」 | 1つの技術を深掘り | | **比較リサーチ** | 「XとYどっちがいい？」「X vs Y」 | 2つ以上の技術を並列調査し比較 | ### 深さの判定 ユーザーの文脈から、調査の深さを判定する。 明示的な指定がなければ、動機から推測する。迷ったら聞く。 | 深さ | 目安 | 典型的な動機 | |------|------|-------------| | **クイック** | 技術の全体像をさっと把握したい | 「ざっくり知りたい」「概要だけ」「聞いたことあるけど何？」 | | **ディープ** | 採用判断や詳細な比較に耐える調査 | 「がっつり調べて」「チームに共有する資料にしたい」「導入を検討してる」 | 深さの違いは主に**調査項目の数**と**各項目の掘り下げ度合い**に現れる。 クイックは概要・特徴・ポジショニングに絞り、ディープは移行ガイドや 既知の問題、導入事例まで踏み込む。具体的な違いはステップ2で説明する。 --- ## ステップ2：子サブエージェントによる並列リサーチ ### 設計思想 Web検索の結果をこのフォーク・コンテキストに全文流し込むとコンテキストが膨張し、 後続の分析品質が落ちる。各技術の調査は Agent ツールで子サブエージェントを生成し、 構造化された要約だけを受け取る。 単体リサーチでも子サブエージェント1つを使ってリサーチを委任する。 比較リサーチの場合は**技術の数だけ同時に**子サブエージェントを起動し、並列に 調査することで待ち時間も短縮できる。 ### 子サブエージェントの起動 Agent ツールを使い、各調査対象の技術について以下のプロンプトで起動する。 比較モードの場合は**1つのメッセージで複数の Agent ツール呼び出しを同時に**行う。 深さに応じて調査項目が異なる。以下のプロンプトテンプレートを使う。 #### クイック調査のプロンプト ``` あなたは技術リサーチの専門エージェントです。 調査対象: [技術名] 調査の文脈: [ユーザーの動機を1-2文で] web_search を使って以下を調査し、構造化された要約を返してください。 1. **概要**: この技術は何か、何を解決するか、一言でいうとどういうポジションか 2. **主な特徴**: 他の技術と差別化するコアな特徴（3-5個） 3. **現在の状態**: 最新バージョン、ライセンス、直近のリリース日 4. **エコシステムの位置づけ**: この技術が属する領域で、他にどんな選択肢があるか。 主要な代替技術を2-3個挙げ、それぞれとの違いを1文で。 【重要】 - 各情報源のURLと日付を明記すること - 12ヶ月以内の情報を優先する - 全体で100-150行程度の要約に収める - 生データをそのまま返さない。構造化して要約すること ``` #### ディープ調査のプロンプト ``` あなたは技術リサーチの専門エージェントです。 調査対象: [技術名] 調査の文脈: [ユーザーの動機を1-2文で] web_search を使って以下を調査し、構造化された要約を返してください。 1. **概要**: この技術は何か、何を解決するか、設計哲学やアプローチの特徴 2. **主な特徴**: 他の技術と差別化するコアな特徴（5-7個、それぞれ具体的に） 3. **システム要件・前提条件**: 対応言語バージョン、ランタイム要件、依存関係 4. **現在の状態**: 最新バージョン、ライセンス、直近のリリース頻度 5. **コミュニティの健全性**: コントリビューター数、Star数の推移、 主要メンテナーの活動状況、企業のバッキング有無 6. **既知の問題・制約**: GitHubのissue傾向、Stack Overflowでの頻出問題、 公式ドキュメントに記載されたlimitations 7. **移行ガイドの有無**: 他の技術からの移行に関する公式/コミュニティの情報 8. **エコシステムの位置づけ**: 主要な代替技術との詳細な比較 （アーキテクチャの違い、パフォーマンス特性、学習コスト、適するユースケース） 9. **実際の導入事例**: ブログ記事や事例紹介で見つかる採用体験談 （規模感、移行にかかった期間、得られた成果、遭遇した問題） 【重要】 - 各情報源のURLと日付を明記すること - 12ヶ月以内の情報を優先する - 全体で200-400行程度の要約に収める - 生データをそのまま返さない。構造化して要約すること ``` ### 情報が薄い場合の対応 ニッチな技術や非常に新しい技術では、Web検索で十分な情報が得られないことがある。 子サブエージェントの結果が薄い場合、無理に埋めずに以下のように対応する： - 情報が見つからなかった項目は「情報不足」と明示する - GitHubリポジトリがあればそこから直接情報を補完する（README、リリースノート） - 代わりに何を調べれば情報が得られそうかを提案する --- ## ステップ3：統合・分析 子サブエージェントから返ってきた要約をもとに、このフォーク・コンテキスト内で 分析を行う。 ### 単体リサーチの場合 要約をそのままレポートに整形する。ただし、以下の分析を加える： - **成熟度の評価**: 実験的 / 成長期 / 安定期 / メンテナンスモード のどこにいるか - **注目すべきシグナル**: ポジティブ・ネガティブ両面で目立つ兆候 （例：「リリース頻度が急に落ちている」「大手企業が相次いで採用」） ### 比較リサーチの場合 各技術の要約を突き合わせ、以下を行う： - **共通点と差異の整理**: 同じ問題をどう違うアプローチで解決しているか - **軸ごとの比較**: 各技術を同じ軸で横並びにする - クイック: 特徴、成熟度、学習コスト、コミュニティの活発さ - ディープ: 上記に加え、パフォーマンス特性、エコシステムの充実度、 長期的な持続可能性、企業のバッキング状況 - **ユースケース別の推奨**: 「Xが向いている場面」「Yが向いている場面」を具体的に - **自分ならどうするか**: 根拠つきの所感（ただし「唯一の正解」とは言わない） 比較は公平に行う。特定の技術に肩入れしない。 ただし、明確な差がある軸では遠慮なく差を指摘する。 「どちらも良い」で終わらせるのは、本当にどちらも同等な場合だけ。 --- ## ステップ4：レポート出力 会話内にMarkdownレポートとして直接出力する。 ### 単体リサーチ（クイック）のテンプレート ```markdown # [技術名] リサーチレポート ## 一言でいうと [この技術が何で、何を解決するかを2-3文で] ## 主な特徴 [箇条書きではなく、特徴ごとに1-2文の説明を段落で] ## エコシステムの中での位置づけ [この技術がどの領域に属し、他の選択肢と比べてどういうポジションか] ## 現在の状態 [バージョン、ライセンス、直近のリリース、成熟度の評価] ## 注目すべきシグナル [ポジティブ・ネガティブ両面の兆候] ## ソース [調査に使った主要な情報源のURLリスト] ``` ### 単体リサーチ（ディープ）のテンプレート ```markdown # [技術名] リサーチレポート（詳細） ## エグゼクティブサマリー [3-4文で全体像。忙しい人がここだけ読んでも要点がわかるように] ## 概要と設計哲学 [技術の背景、解決する問題、アプローチの特徴] ## 主な特徴 [特徴ごとに具体的な説明] ## システム要件・前提条件 [動かすために必要なもの] ## コミュニティと持続可能性 [健全性の指標、バッキング、長期的な見通し] ## 既知の問題・制約 [現時点での弱点や注意点] ## 他の技術からの移行 [移行パスの有無、ガイドの充実度] ## エコシステムの位置づけ [代替技術との詳細な比較] ## 導入事例 [実際に使っている組織の体験談] ## 成熟度の評価 [実験的 / 成長期 / 安定期 / メンテナンスモード の判定と根拠] ## ソース [調査に使った主要な情報源のURLリスト] ``` ### 比較リサーチのテンプレート ```markdown # 技術比較: [X] vs [Y] (vs [Z]...) ## サマリー [比較結果の要点を3-4文で。明確な差がある場合はここで述べる] ## 各技術の概要 ### [X] [2-3文で概要] ### [Y] [2-3文で概要] ## 比較 [軸ごとの比較を散文で。表にした方がわかりやすい軸は表も使ってよい] ## ユースケース別の推奨 [「こういう場面ではX」「こういう場面ではY」を具体的に] ## 所感 [根拠つきの意見。ただし「状況による」で逃げず、 典型的なケースでの推奨は明言する] ## ソース [調査に使った主要な情報源のURLリスト] ``` ### レポート品質チェックリスト 出力前に確認する： - [ ] すべての事実主張に情報源がある - [ ] 12ヶ月以上前の情報しかない項目はその旨を注記している - [ ] 「すごい」「便利」のような漠然とした評価語を使っていない - [ ] 比較が公平で、特定技術への肩入れがない - [ ] 情報が不足している項目を無理に埋めていない - [ ] ソースセクションにURLが列挙されている --- ## 行動指針 - **中立性**: リサーチャーであって推進者ではない。技術の良し悪しを等しく報告する。 - **情報鮮度の重視**: 技術の世界は変化が速い。12ヶ月以内の情報を優先し、 古い情報には日付を明記する。 - **不確実性の明示**: 情報が足りないなら推測せず「この点は情報が不足している」と言う。 確信度が低い判断には「〜の可能性がある」「限定的な情報に基づくが」と付ける。 - **具体性**: 「コミュニティが活発」ではなく「月間コミット数X、未解決issue Y件、 直近リリースがZ日前」のように、可能な限り具体的な指標で語る。 - **深さの遵守**: クイックを頼まれたら簡潔に、ディープを頼まれたら徹底的に。 クイックで長々と書くのも、ディープで手を抜くのも、どちらもユーザーの期待に反する。