npx claudepluginhub caphtech/claude-marketplace --plugin knowledge-pluginWant just this skill?
Then install: npx claudepluginhub u/[userId]/[slug]
一般・技術の両分野に対応した体系的情報収集スキル。調査設計→手法選定→実行→検証の4フェーズで進める。Use when: 調査・リサーチ・情報収集を依頼された時、バグ調査・API調査・市場調査・競合調査・文献調査・ファクトチェック等を行う時。
This skill uses the workspace's default tool permissions.
references/evaluation-guide.mdreferences/method-catalog.mdreferences/tech-research-methods.mdInfo Gathering(情報収集)
調査設計→手法選定→実行→検証の4フェーズで、一般調査と技術調査の両方を体系的に行う。
Phase 1: 調査設計
収集を始める前に「何を知りたいのか」を明確化する。
1.1 問いの定義
| 項目 | 内容 |
|---|---|
| 調査対象 | 何を調べるのか(テーマ・ライブラリ名・エラー等) |
| 目的 | なぜその情報が必要か・この調査で決めること |
| 既知情報 | 現在知っていること・手元の資料 |
| 対象者 | 誰にとっての情報か |
| スコープ | 地域・期間・バージョン・環境等の範囲 |
| 品質基準 | 必要な精度・エビデンス強度 |
1.2 分野判定
調査対象に応じて主な分野を判定する。手法選定の分岐に使う:
- 技術調査: バグ・エラー原因、API仕様、ライブラリ使い方、移行・アップグレード、ベストプラクティス、パフォーマンス検証
- 一般調査: 市場・競合、学術・文献、ジャーナリズム・ファクトチェック、問題解決、デジタル調査(OSINT等)
両方にまたがる場合は、それぞれの手法を組み合わせる。
1.3 調査目的の分類
目的によって適切な手法が変わる:
- 探索的: 何が問題か分からない → 広く浅く情報を集める
- 検証的: 仮説があり正しいか確認したい → 仮説に絞って検証する
- 実証的: 事実・データで裏付けたい → 定量データを収集する
Phase 2: 手法選定
技術調査の手法選定
| 調査目的 | 推奨手法(優先順) |
|---|---|
| API仕様・使い方 | 公式ドキュメント → ソースコード → Stack Overflow |
| バグ調査 | GitHub Issues → Stack Overflow → 再現実験 |
| 最新情報・変更点 | リリースノート → GitHub Releases → 公式ブログ |
| 移行・アップグレード | マイグレーションガイド → Breaking Changes一覧 → GitHub PRs |
| ベストプラクティス | 公式ガイド → コミュニティ事例 → ソースコード読解 |
| エラー原因 | エラーメッセージ検索 → GitHub Issues → 再現実験 |
複数手法を選ぶ場合は「一次情報を優先」「信頼性の高いものを先に」で順序付ける。 各手法の詳細な実行手順は tech-research-methods.md を参照。公式ドキュメント・GitHub・Stack Overflow・パッケージレジストリ・ソースコード読解・再現実験・AI活用・コミュニティ問い合わせの手順を記載。
一般調査の手法選定
| 調査目的 | 推奨手法(優先順) | カテゴリ |
|---|---|---|
| 先行研究の把握 | 文献調査 → 系統的レビュー → メタ分析 | 学術・研究 |
| 市場規模・動向 | デスクリサーチ → 市場調査 | ビジネス |
| 競合の戦略分析 | 競合調査 → デスクリサーチ | ビジネス |
| ユーザーニーズ | フィールドリサーチ → デザイン思考 | ビジネス / 問題解決 |
| 事実の真偽確認 | ファクトチェック → SIFT法 → CRAAP Test | ジャーナリズム / 情報評価 |
| 問題の全体像 | 5W1H → マインドマップ → MECE | 問題解決 / 整理統合 |
| 根本原因特定 | なぜなぜ分析 → ロジックツリー | 問題解決 |
| 仮説の設定と検証 | 仮説思考 → uncertainty-resolution | 問題解決 |
| 公開情報からの調査 | OSINT → Google高度検索 → Webアーカイブ | デジタル調査 |
| 収集情報の分類整理 | KJ法 → MECE → ロジックツリー | 整理・統合 |
| エビデンス強度判断 | エビデンスピラミッド → CRAAP Test | 情報評価 |
各手法の概要・使いどころ・手順は method-catalog.md を参照。7カテゴリ20手法の詳細を記載。
Phase 3: 実行
3.1 情報収集の実行
選定した手法に従って情報を収集する。収集中は以下の形式で記録を残す:
### [情報タイトル]
- **情報源**: [URL / 書籍名 / ファイルパス]
- **取得日**: [YYYY-MM-DD]
- **種別**: [一次情報 / 二次情報]
- **バージョン**: [該当する場合]
- **信頼度**: [高 / 中 / 低]
- **要約**: [3行以内]
- **根拠**: [一次情報/二次情報/実験結果 等]
3.2 信頼性評価
収集した情報の信頼性を評価する:
- CRAAP Test: Currency / Relevance / Authority / Accuracy / Purpose の5基準で体系的に評価
- SIFT法: Stop / Investigate / Find better coverage / Trace claims の4ステップで迅速評価
詳細な評価手順・チェックリスト・スコアリングシートは evaluation-guide.md を参照。CRAAP Test・SIFT法・バイアス排除手法・エビデンスピラミッド・情報源別信頼度目安表を記載。
3.3 技術調査での追加検証
技術調査ではドキュメントだけで確信が持てない場合、再現実験で検証する:
- 最小限の再現コードで問題を再現する
- 1つの仮説を1つの実験で検証する
- バージョン確認: 情報が対象バージョンに適合するか検証
- 矛盾の検出: 複数ソースで矛盾があれば実験で検証
3.4 評価の原則
- 一次情報を優先: 公式ドキュメント・ソースコード・政府統計 > ブログ・Q&Aサイト
- 鮮度を確認: 公開日・更新日・対象バージョンを必ず確認
- AI回答は出発点: ハルシネーションリスクあり。必ず一次情報で裏取りする
- バイアスに注意: 確証バイアス・選択バイアス・生存者バイアスを意識する
- 英語ソースを優先(技術調査): 日本語情報は翻訳・要約のズレが生じやすい
Phase 4: 統合と成果物
4.1 情報統合
| 状況 | 推奨手法 |
|---|---|
| 断片的な情報が大量 | KJ法(ボトムアップでグループ化) |
| 問題の構造を可視化 | ロジックツリー(MECE原則で分解) |
| 網羅性を担保 | MECE(漏れ・ダブりを排除) |
| 全体像と関連性把握 | マインドマップ(視覚的に俯瞰) |
4.2 成果物の整理
# 調査結果サマリ
## 調査概要
- **調査テーマ**: [テーマ]
- **調査日**: [日付]
- **調査目的**: [探索的 / 検証的 / 実証的]
- **使用手法**: [手法名リスト]
- **対象バージョン**: [該当する場合]
## 結論
[最も重要な発見を1〜3行で]
## 主要な発見
1. [発見1](信頼度: 高/中/低、根拠: [情報源])
2. [発見2]
3. [発見3]
## 未解決の問い
- [追加調査が必要な事項]
## 情報源一覧
| # | 情報源 | 種別 | 信頼度 | 取得日 |
|---|--------|------|--------|--------|
| 1 | [URL等] | 一次/二次 | 高/中/低 | YYYY-MM-DD |
## 推奨アクション
[調査結果に基づく次のステップ]
連携スキル
| スキル | 連携タイミング |
|---|---|
| uncertainty-resolution | 調査中に不確実性が出てきた時、台帳化して優先順位を付ける |
| dependency-observation | ライブラリ調査と合わせて依存関係を確認する時 |
Similar Skills
This skill should be used when the user asks about libraries, frameworks, API references, or needs code examples. Activates for setup questions, code generation involving libraries, or mentions of specific frameworks like React, Vue, Next.js, Prisma, Supabase, etc.