# Research To Slides

> 論文・GitHub リポジトリ・外部情報を調査し、プレゼンテーション用の構造化リサーチノートを生成する。 GitHub MCP tools（search_repositories, search_code, get_file_contents, search_issues, search_pull_requests, list_commits）でリポジトリ・コード・Issue を調査し、 web_search / web_fetch で論文・外部情報を収集する。 Use when 「調べて」「リサーチして」「論文を整理して」「リポジトリを調査して」「技術比較して」 「Related Workを整理して」「最新の実装を確認して」「Issueを調べて」。

- Skill: `nahisaho/research-to-slides` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nahisaho/research-to-slides`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nahisaho/research-to-slides/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: nahisaho (https://skillmd.com/u/nahisaho)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nahisaho/research-to-slides

---


# Research-to-Slides — Phase 0: リサーチ→スライド素材

## 概要

プレゼンテーション作成の前段階として、テーマに関連する論文・リポジトリ・技術情報を
体系的に調査し、構造化されたリサーチノート（`research-notes.md`）を生成する。

AI for Science / 政策提言 / 技術戦略のプレゼンテーションに必要なエビデンスを、
信頼性の高いソースから収集・整理する。

## 対象ツール

| ツール | 用途 | 優先度 |
|--------|------|--------|
| `search_repositories` | テーマ関連リポジトリの発見 | 高 |
| `search_code` | 具体的なコードパターン・実装例の検索 | 中 |
| `get_file_contents` | README, docs, 設定ファイルの取得 | 高 |
| `search_issues` | 議論・課題の調査 | 中 |
| `search_pull_requests` | 変更履歴・機能追加の把握 | 中 |
| `list_commits` | 開発活動の時系列把握 | 低 |
| `web_search` | 論文・外部技術情報の検索 | 高 |
| `web_fetch` | Web ページの詳細取得 | 中 |

## 実行手順

### Step 1: テーマ分析

1. ユーザーの入力からキーワードを抽出する
2. 検索クエリを 3〜5 パターン生成する（英語・日本語の両方）
3. 調査スコープを定義する（技術領域、時間範囲、対象組織）

### Step 2: GitHub リポジトリ調査

1. `search_repositories` でテーマ関連リポジトリを検索（Stars 順）
2. 上位 5〜10 リポジトリの `get_file_contents` で README を取得
3. `search_code` で主要な実装パターンを特定
4. `search_issues` / `search_pull_requests` で最新の議論・変更を把握
5. `list_commits` で開発活動のトレンドを確認

### Step 3: 論文・外部情報収集

1. `web_search` で学術論文・技術ブログ・公式ドキュメントを検索
2. `web_fetch` で重要ページの詳細を取得
3. プレプリント（arXiv 等）と査読済み論文を区別して記録
4. 政策文書（MEXT, NIST 等）がある場合は優先的に収集

### Step 4: 構造化・分析

1. 収集データを出力テンプレートに整理
2. 技術比較表を作成（強み・弱み・適用領域）
3. インサイト（「だから何か」）を導出
4. 全情報に出典 URL を付与

## 出力テンプレート: `research-notes.md`

```markdown
# リサーチノート: {topic}

## エグゼクティブサマリー
{3行でまとめ — 何が分かったか、何が重要か、次のアクション}

## 主要リポジトリ
| リポジトリ | Stars | 説明 | URL |
|-----------|-------|------|-----|
| {owner/repo} | {N} | {1行説明} | {URL} |

## 技術比較
| 技術 | 強み | 弱み | 適用領域 |
|------|------|------|---------|
| {tech} | {strengths} | {weaknesses} | {domains} |

## 論文・文献
| タイトル | 著者 | 年 | 要点 | URL |
|---------|------|-----|------|-----|
| {title} | {authors} | {year} | {key finding} | {URL} |

## コードパターン
{実装例とその説明 — コードブロック付き}

## 最新動向（Issue/PR）
| リポジトリ | タイプ | タイトル | 状態 | URL |
|-----------|--------|---------|------|-----|
| {repo} | Issue/PR | {title} | Open/Closed | {URL} |

## インサイト
{「だから何か」の考察 — プレゼンテーションへの示唆}

## 出典一覧
{全URL・パス — 番号付きリスト}
```

## Validation Loop（検証ループ）

### 出力検証チェック

1. **出典完全性**: 全データ行に URL またはファイルパスが付与されているか
2. **信頼性ラベル**: 各文献に査読状態（査読済み / プレプリント / ブログ）が明示されているか
3. **技術比較の公平性**: 比較表が一方的でないか（各技術に強み・弱み両方あるか）
4. **鮮度**: 情報の取得日時と対象期間が明記されているか
5. **テンプレート準拠**: 出力が上記テンプレートの全セクションを含むか

### 検証手順

```
1. research-notes.md の全行を走査
2. URL のない情報行を検出 → 出典追加 or 行削除
3. 信頼性ラベル未付与の文献を検出 → ラベル追加
4. 比較表の偏りチェック → バランス調整
5. 全チェック通過 → Phase 1（Presentation Architect）に引き渡し可能
```

### Failure Recovery（失敗時リカバリ）

| 失敗パターン | 原因 | リカバリ手順 |
|-------------|------|------------|
| GitHub MCP rate limit | 短時間に大量リクエスト | 検索を 3 回以下に分割し、結果を累積 |
| web_search で結果ゼロ | クエリが狭すぎる | キーワードを一般化して再検索 |
| get_file_contents 失敗 | リポジトリがプライベート or パス不正 | search_code でファイル存在確認後に再取得 |
| 論文の URL がリンク切れ | 移動 or 削除 | DOI / タイトルで web_search し代替 URL 取得 |
| 情報が古い（2年以上前） | 最新情報が見つからない | 「最新情報なし」と明記し、取得済み情報の日付を記載 |

## Quality Gates（品質ゲート）

- [ ] エグゼクティブサマリーが 3 行以内で要点を伝えている
- [ ] 主要リポジトリが 3 件以上リストされている
- [ ] 技術比較表に 2 技術以上が含まれている
- [ ] 論文・文献が 3 件以上リストされている
- [ ] 全データ行に出典 URL が付与されている
- [ ] プレプリントと査読済み論文が区別されている
- [ ] インサイトセクションに「プレゼンテーションへの示唆」が含まれている
- [ ] 出典一覧が番号付きリストで整理されている

## Gotchas（落とし穴）

### 1. GitHub MCP Rate Limits — 大量検索の分割実行

GitHub MCP ツールには暗黙の rate limit がある。`search_repositories` を連続 10 回以上
呼ぶとタイムアウトする。**検索は 1 回あたり 3 クエリ以下に分割**し、結果を累積すること。
特に `search_code` は結果数が多いため、`language:` や `path:` フィルタで絞ること。

### 2. 論文の信頼性検証 — プレプリントと査読済みの区別

arXiv プレプリントを「査読済み論文」として引用すると、MEXT / Microsoft HQ 向け資料で
信頼性が問われる。**全論文に信頼性ラベル**（査読済み / プレプリント / テクニカルレポート /
ブログ）を付与すること。政策提言資料では査読済み論文を優先的に引用する。

### 3. 出典なしデータの禁止 — 全情報に URL を付与

「〜と言われている」「一般的に〜」のような出典不明の記述は禁止。
全ての主張・データ・比較結果に、検証可能な URL またはファイルパスを付与すること。
出典が見つからない情報は `research-notes.md` に含めない。

### 4. 検索言語バイアス — 英語・日本語の両方で検索

英語のみで検索すると日本国内の重要リポジトリや文献を見逃す。
逆に日本語のみでは国際的な動向を把握できない。**必ず英語・日本語の両方**で
検索クエリを生成すること。

## Memory Persistence（記憶の永続化）

過去のリサーチで学んだパターン:

- **AI for Science 領域**: RIKEN, AIST, 理研 AIP のリポジトリは `search_repositories`
  より `web_search` の方が発見しやすい
- **Microsoft 関連技術**: `org:microsoft` フィルタで公式リポジトリに絞る
- **MEXT 政策文書**: `web_fetch` で mext.go.jp のページを取得する際、
  PDF リンクが多いため、HTML ページの要約に留める
- **Stars 数の罠**: Stars が少なくても公式リポジトリは重要。Stars だけでソートしない

## 禁止事項

1. **出典なし情報の記載禁止** — URL のない情報を `research-notes.md` に含めない
2. **信頼性ラベル省略禁止** — 全文献に査読状態を明記する
3. **単一言語検索禁止** — 英語・日本語の両方で検索する
4. **過剰な API コール禁止** — 1 テーマあたり GitHub MCP 呼び出しは 15 回以下
5. **著作権侵害禁止** — 論文の全文コピーや図の無断転載を行わない
6. **プライベートリポジトリ内容の記載禁止** — アクセスできても公開可否を確認する