nahisaho 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: テーマ分析
- ユーザーの入力からキーワードを抽出する
- 検索クエリを 3〜5 パターン生成する（英語・日本語の両方）
- 調査スコープを定義する（技術領域、時間範囲、対象組織）
Step 2: GitHub リポジトリ調査
search_repositoriesでテーマ関連リポジトリを検索（Stars 順）- 上位 5〜10 リポジトリの
get_file_contentsで README を取得 search_codeで主要な実装パターンを特定search_issues/search_pull_requestsで最新の議論・変更を把握list_commitsで開発活動のトレンドを確認
Step 3: 論文・外部情報収集
web_searchで学術論文・技術ブログ・公式ドキュメントを検索web_fetchで重要ページの詳細を取得- プレプリント（arXiv 等）と査読済み論文を区別して記録
- 政策文書（MEXT, NIST 等）がある場合は優先的に収集
Step 4: 構造化・分析
- 収集データを出力テンプレートに整理
- 技術比較表を作成（強み・弱み・適用領域）
- インサイト（「だから何か」）を導出
- 全情報に出典 URL を付与
出力テンプレート: research-notes.md
# リサーチノート: {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（検証ループ）
出力検証チェック
- 出典完全性: 全データ行に URL またはファイルパスが付与されているか
- 信頼性ラベル: 各文献に査読状態（査読済み / プレプリント / ブログ）が明示されているか
- 技術比較の公平性: 比較表が一方的でないか（各技術に強み・弱み両方あるか）
- 鮮度: 情報の取得日時と対象期間が明記されているか
- テンプレート準拠: 出力が上記テンプレートの全セクションを含むか
検証手順
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 だけでソートしない
禁止事項
- 出典なし情報の記載禁止 — URL のない情報を
research-notes.mdに含めない - 信頼性ラベル省略禁止 — 全文献に査読状態を明記する
- 単一言語検索禁止 — 英語・日本語の両方で検索する
- 過剰な API コール禁止 — 1 テーマあたり GitHub MCP 呼び出しは 15 回以下
- 著作権侵害禁止 — 論文の全文コピーや図の無断転載を行わない
- プライベートリポジトリ内容の記載禁止 — アクセスできても公開可否を確認する