--- name: research-agentic description: エージェンティックリサーチとAIナレッジベース管理。固定的な手順ではなく、臨機応変に深掘り・横展開しながら徹底調査を行う。包括的な調査、ファクトチェック、深い探究に使用。また、AI（Teddy）が参照するナレッジデータ（lib/knowledge/）の正確性検証、更新、新規追加にも使用。番組情報、放送回データ、タレント情報の管理に特化。 --- # エージェンティックリサーチとAIナレッジベース管理 ## 核心理念 調査は**探索**である。地図を作りながら歩くようなもの。 ``` 質問 → 収集 → 理解 → 「もっと知りたい」 → 深掘り/横展開 ↑ ↓ └──────── 新しい問いが生まれる ←─────┘ ``` ### 基本姿勢 - **好奇心主導**: 「面白そう」「気になる」は立派な調査動機 - **柔軟な軌道修正**: 予定を変更しても良い、より重要なものが見つかればそちらへ - **質 > 量**: 表面的な情報の羅列より、いくつかのことを深く理解する - **不確実性を受け入れる**: わからないことはわからないと正直に言う - **自分の理解を疑う**: 「本当にこれで合ってるか？」を常に自問 - **データは嘘をつく**: 特に時系列データ、リストデータは**必ず検証が必要** --- ## 🚨 重要: データ品質管理（教訓から学んだこと） ### データ作成時の鉄則 **データは検証してからコミットする** ``` ❌ 作成 → コミット → 検証 → 修正（これでは遅い） ✅ 作成 → サンプル検証 → 問題発見 → 修正 → コミット ``` ### 信頼性の低いデータパターン（要注意） | パターン | 危険度 | 対応 | |---------|-------|------| | **時系列データ（放送回、イベント等）** | 🔴 高 | 公式サイトで必ず検証 | | **ゲスト/出演者リスト** | 🔴 高 | 複数ソースで確認 | | **日付+曜日の組み合わせ** | 🟡 中 | カレンダーで検証 | | **数値データ（視聴率、売上など）** | 🟡 中 | 公式発表を確認 | | **主観的評価（人気ランキング等）** | 🟢 低 | 出典を明示 | ### 検証必須チェックリスト データを作成・更新する前に必ず確認： - [ ] **Primary Source（一次情報源）**は確認したか？ - テレビ番組→公式サイト、放送局サイト - 技術情報→公式ドキュメント - 人物情報→本人SNS、所属事務所 - [ ] **複数の情報源**でクロスチェックしたか？（最低2つ） - [ ] **日付と曜日**が一致するか？ - [ ] **存在しない組み合わせ**（放送局×曜日など）がないか？ - [ ] **サンプル検証**（全体の10-20%）を実施したか？ ### 検証結果の記録 検証を実施したら、必ず以下を記録： ```markdown ## 検証記録 - **検証日**: YYYY-MM-DD - **検証対象**: [ファイル名/データ名] - **検証方法**: [使用したツール/サイト] - **検証結果**: ✅ 正確 / ⚠️ 一部誤り / ❌ 重大な誤り - **修正内容**: [修正した項目] - **未検証項目**: [検証できなかった項目] ``` --- ## 調査の始め方 ### まず最初に 1. **ユーザーの質問を自分の言葉で言い換える** - 何が知りたいのか、本当の意図は何か - どの程度の深さ・広さが必要か推測 2. **前提条件と既存データの確認** - ユーザーが提供する「正しい情報」と「既存データ」の関係を明確にする - **差分リストを作成**（追加・削除・修正を明示） - **必ず確認**: 削除が「過去の実績」なのか「誤記載」なのか意図を確認 - **修正範囲を宣言してから作業開始**（予期せぬ副作用を防ぐ） 3. **最初の検索を実行** - 広く浅くでOK - 全体像をつかむ 4. **「これは何についての話か」を把握** - キーワード、主要な関係者、文脈 - 自分の無知を特定する ### 調査対象のタイプ（参考） 対象に応じて自然に異なる観点が浮かぶはず： | タイプ | 自然に気になること | |--------|------------------| | **人物** | 経歴、転機、周囲との関係、評価の多様性 | | **組織** | 歴史、事業、人、競合、評判、変化 | | **技術** | 仕組み、用途、限界、競合、将来性 | | **出来事** | 経緯、背景、影響、当事者の違う見方 | | **作品** | 制作背景、評価、影響、文脈 | | **テレビ番組** | 放送局、時間、MC、放送回、ゲスト | --- ## データの信頼性と整合性の確認 ### 既存データと新情報の比較 調査・修正作業で必ず確認すること： | 確認項目 | 確認方法 | 判断が必要な場合 | |---------|---------|---------------| | **情報の正確性** | 複数の信頼できる情報源で検証 | 矛盾があればユーザーに確認 | | **誤記載 vs 過去実績** | コンテキストから判断 | 削除時は必ず意図を確認 | | **完全性** | リスト同士を比較して差分を特定 | 不足・過剰があればリストアップ | ### 削除時の判断基準 削除が必要なデータに対して： ``` □ これは過去に存在したが現在は終了したものか？ → 「過去の実績」として適切に記録を残す □ これはそもそも関係のない誤記載か？ → 完全に削除（履歴にも残さない） □ 判断がつかない → ユーザーに確認してから処理 ``` **重要**: 「削除」と「過去実績としての記録」は別物。判断に迷ったら必ずユーザーに確認すること。 --- ## AIナレッジベース管理 ### いつ使用するか **Teddy（AI）が参照するナレッジデータの管理:** - 「`lib/knowledge/` の番組情報を更新して」 - 「放送回データを追加して」 - 「タレント情報が正しいか検証して」 - **「新しい番組の情報をリサーチして」** ← 重要 **データ品質管理:** - 「このデータは正しいかファクトチェックして」 - 「改編期の番組変更を反映して」 - 「古い放送回データを整理して」 - **「検証記録を残して」** ← 重要 ### AIナレッジ管理フロー ``` ┌─────────────────────────────────────────────────────────────┐ │ 1. AIナレッジ収集 │ │ - lib/knowledge/programs.ts（番組基本情報） │ │ - lib/knowledge/programs-detailed-data.ts（放送回） │ │ - lib/knowledge/talents.ts（タレント情報） │ │ - その他のナレッジデータファイル │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 2. 検証ポイント抽出 │ │ - 放送局・曜日・時間（番組基本情報） │ │ - 日付と曜日の整合性（放送回データ） │ │ - タイトル・ゲストの正確性 │ │ - 番組状態（放送中/終了/休止） │ │ - **時系列データの整合性** ← 特に重要 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 3. 外部情報での検証 │ │ - **放送局公式サイト**（一次情報源） │ │ - **番組公式サイト・SNS**（最新情報） │ │ - **番組表サイト**（Gガイド等） │ │ - Wikipedia（補助的確認のみ） │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 4. 差分検出と優先度付け │ │ - 🔴 重大（放送局誤り、時間誤り）→ 即時対応 │ │ - 🟡 中程度（タイトル誤り、ゲスト誤り）→ 計画的対応 │ │ - 🟢 軽微（表記ゆれ、説明文改善）→ 次回更新時 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 5. ナレッジ更新と検証記録 │ │ - 該当ファイルの更新 │ │ - 関連ファイルの整合性確認 │ │ - **検証記録を docs/lessons/ に保存** │ │ - 更新履歴の記録 │ └─────────────────────────────────────────────────────────────┘ ``` ### 収集対象（AIナレッジ） | カテゴリ | 収集対象ファイル | 検証すべき内容 | |---------|----------------|---------------| | **番組基本情報** | `lib/knowledge/programs.ts` | 放送局、曜日・時間、MC | | **放送回データ** | `lib/knowledge/programs-detailed-data.ts` | 日付、タイトル、ゲスト | | **追加放送回** | `lib/knowledge/programs-detailed-data-2.ts` | 日付、タイトル、ゲスト | | **タレント情報** | `lib/knowledge/talents.ts` | 所属、出演番組、SNS | | **検証記録** | `docs/verification/*.md` | 過去の検証結果 | | **学びの記録** | `docs/lessons/YYYY-MM-DD-*.md` | 教訓、改善点 | ### このプロジェクト特有の検証文化 **UPエージェント（AI Hub）** では、以下の検証文化が確立されている： ``` □ lib/knowledge/（AIナレッジベース） → programs.ts: 番組基本情報 → programs-detailed-data.ts: 放送回データ → talents.ts: タレント情報 □ docs/verification/ → CHECKLIST.md: 検証用チェックリスト → episode-data-verification-report.md: 検証結果報告書 □ docs/lessons/ → YYYY-MM-DD-[タイトル].md: 検証記録・学びの蓄積 → 例: 2026-02-27-programs-data-verification.md □ 定期検証スケジュール → 毎週: 先週の放送回データ追加・検証 → 四半期ごと: 全番組基本情報の確認 → 改編期（4月・10月）: 放送時間変更・新番組対応 ``` **検証記録の必須要素**: - 検証日・検証者 - 検証対象（ファイルパス） - 検証方法（使用した情報源：公式サイト等） - 結果（✅正確/❌誤り/⚠️一部誤り） - 修正内容 - 教訓・改善点 --- ## 深掘りの判断 ### 「ここをもっと調べるべき」信号 - 矛盾している情報がある - 直感が「おかしい」と感じる - 根本的な「なぜ」がわからない - 専門用語が出てきた - 影響が大きそうな要素 - ユーザーが特に関心を持ちそうなポイント - **既存データと新情報に差分がある** - **日付と曜日が一致しない** - **存在しない組み合わせがある**（放送局×曜日など） ### 「ここはスキップできる」信号 - すでに複数の信頼できる情報源で確認できた - 本質的でない細部（電話番号など） - 調査目標から外れている - 同じような情報の繰り返し --- ## 情報源の扱い ### 信頼度の直感（参考） | 高い | 公式発表、一次資料、査読付き論文、確立した報道機関 | | 中程度 | 専門メディア、専門家の分析、業界出版物 | | 注意が必要 | 要約サイト、SNS、匿名情報、古い情報 | ### 検証の直感 - **「本当？」と思ったら**: 別の情報源で確認 - **「確かな情報源は？」**: 公式サイト、プレスリリース、専門家の発言を探す - **「この人は何者？」**: 発信者の背景を調べる - **「いつの話？」**: 日付を確認、最新か、文脈に合うか ### 矛盾を見つけたら 1. 両方を記録 2. どちらが信頼できそうか判断（情報源、日付、文脈） 3. 判断できなければ「情報源によって異なる」と記載 4. 必要ならユーザーに確認 --- ## 思考のフレームワーク（使い方を強制しない） 必要に応じて使える思考ツール： ### 5W1H + So What - Who, What, When, Where, Why, How, そして「だから何か」 ### 因果関係の追究 - 「なぜそうなったか」を何度も問う - 「そうだからこうなった」の証拠はあるか ### 文脈の把握 - 歴史的文脈：当時の状況は？ - 制度的文脈：どんなルールの中で？ - 専門的文脈：業界の常識は？ ### 反証の探索 - 「もしかして逆のことも言える？」 - 批判的な意見はないか - 自分の仮説を否定する証拠を探す --- ## 出力のあり方 ### 基本 - 自分が理解したことを、他人に説明する形で書く - 情報源は可能な限り明示（「〜によると」） - 不確実なことは「〜と報じられている」「〜の可能性がある」と書く - **検証できなかったことは「未確認」と明記** ← 重要 ### 構成（参考例、これに従う必要はない） ``` ## 概要 [全体を2-3文で要約] ## 主要な発見 [重要だと思ったことを整理して記述] - 事実と出典 - 疑問や矛盾（あれば） - 未確認事項（あれば） ## 補足・深掘り [気になったことをさらに調べた結果] ## わからないこと/次に調べるとしたら [残った疑問や、さらに深掘りできそうな方向] ## 検証記録（データ作成時） - **検証日**: YYYY-MM-DD - **検証方法**: [使用したサイト/ツール] - **検証結果**: [サンプル数/正確/誤り] ``` ### 内部ナレッジ監査レポートの構成 ``` ## 監査概要 [監査対象、範囲、期間を要約] ## 検証した内部ナレッジ [チェックしたドキュメント・設定の一覧] ## 発見した差分 | 重要度 | 項目 | 内部記載 | 外部最新情報 | 対応提案 | |-------|------|---------|-------------|---------| | 🔴 高 | XXX | v1.0 | v2.0 (破壊的変更あり) | 即時更新 | | 🟡 中 | YYY | 推奨A | 推奨Bに変更 | 計画的対応 | | 🟢 低 | ZZZ | 文言X | より正確な文言Y | 余裕あり | | 🔴 高 | 放送回データ | 誤り多数 | 公式サイトと一致せず | 全件見直し | ## 詳細な検証結果 [各項目の深掘り調査結果] ## 推奨アクション - 即時対応が必要な項目 - 計画的対応すべき項目 - 参考情報として記録すべき項目 ``` --- ## 調査を終える判断 ### 終了のタイミング - 「もう新しい情報が出てこない」感覚 - ユーザーの質問に十分答えられそう - 時間的制約 - 10回以上検索しても進展がない ### 終了前に自問 - 「本当にこれで理解できたか？」 - 「矛盾や不明点を無視していないか？」 - **「データは検証したか？」** ← 追加 - **「検証記録は残したか？」** ← 追加 - 「自分の推測と確定事実を区別しているか？」 --- ## 実例（参考） ### 例：TV番組放送回データの検証・修正 ``` ユーザー: "TV番組の放送回データを追加しました" 思考プロセス： 1. データを受け取る → 13番組×5回分=65件の放送回データ 2. 信頼性の判断 → 「時系列データ」は危険度が高い → サンプル検証を実施すべき 3. サンプル検証（xAI API + Web検索） → 5番組を検証 → 放送局誤り、タイトル誤り、存在しない放送回を発見 4. 残りも検証 → さらに8番組を検証 → 同様の誤りパターンを確認 5. レポート作成 → 検証結果を詳細に記録 → 修正優先度を分類 → 教訓を記録 6. 対応提案 → データの一時無効化 → 公式サイトからの再収集 → データ品質管理プロセスの確立 ``` ### 例：曜日と日付の整合性チェック ``` 状況: 番組表データに「3月15日（火）20:00〜」と記載 思考プロセス： 1. 直感的に違和感 → 「3月15日って火曜日だったかな？」 2. カレンダーで検証 → 2024年3月15日は実際は「金曜日」 → 「火曜日」は誤り！ 3. 正しい情報の特定 → 公式サイトを確認 → 正しくは「3月15日（金）」 → または「3月12日（火）」の誤りか？ 4. 修正実行 → 曜日を「金」に修正 → 変更履歴に「曜日誤りを修正」と記録 教訓: 日付+曜日の組み合わせは必ずカレンダーで検証する ``` ### 例：データの修正・更新（リストの入れ替え） ``` ユーザー: "正しいリストはA,B,Cです。現在のデータに誤りがあるので修正してください" 思考プロセス： 1. 差分を特定 現在のデータ: A, B, X, Y 正しいリスト: A, B, C → X, Yを削除、Cを追加 2. 削除するデータの性質を確認 → X, Yは過去に存在したが終了したものか？ → それともそもそも関係ない誤記載か？ 3. ユーザーに意図を確認（重要） "X, Yは過去の実績として残しますか？それとも完全に削除しますか？" → ユーザー: "誤記載なので完全に削除" 4. 修正を実行 → X, Yを完全に削除（過去実績としても残さない） → Cを追加 → 更新履歴に「誤記載を削除」と明記 → 検証記録を残す ``` ### 例：内部ナレッジ監査 ``` ユーザー: "ドキュメントが最新か確認して" 思考プロセス： 1. 内部ナレッジ収集 → docs/ 以下の Markdown を走査 → package.json の依存関係を確認 → .claude/skills/ のスキルドキュメントを確認 2. 検証ポイント抽出 → Node.js v18.17.0 と記載（2024年1月時点） → React v18.2.0 と記載 → 「Next.js App Router は実験的機能」と記載 3. 外部情報で検証 → Node.js LTS: v20.x が推奨（2024年10月時点） → React: v19.0 がリリース済み → Next.js App Router: v14 で安定版に 4. 差分検出 → Node.js: 2 メジャーバージョン古い（重大） → React: 1 メジャーバージョン古い（中程度） → App Router: 文書が古い（軽微） 5. レポート作成 → 重要度別に差分をリストアップ → 各項目の影響範囲を分析 → 更新優先度を提案 ``` ### 例：緊急対応 - 誤りデータの無効化ワークフロー ``` 状況: 放送回データ65件を検証したところ、大部分に誤りが発見された 緊急対応フロー： 1. **即座のリスク評価**（5分以内） → 誤情報がAIに提供されているか？→ Yes → ユーザーに影響を与える可能性？→ Yes → 緊急度：🔴 即時対応が必要 2. **データの無効化**（10分以内） → 該当データを空配列に置き換え → 理由をコメントで記録 // 実装例： // recentEpisodes: 誤りが見つかったため一時的に無効化（2026-02-27） recentEpisodes: [], 3. **バックアップ作成** → 元データは .bak として保持 → または Git で履歴を管理（コミット前なら問題なし） 4. **検証レポート作成**（30分以内） → docs/verification/ に保存 → 誤りの詳細、影響範囲、修正方針を記録 5. **ユーザー報告**（即時） → 発見した誤りの概要 → 既に無効化したことを報告 → 再収集・再検証の方針を提示 6. **正確なデータ収集体制構築**（同日中） → 公式サイトからの収集テンプレート作成 → 検証チェックリスト作成 → データ品質管理ガイド作成 7. **再収集と再検証**（翌日以降） → 公式サイトから正確なデータを収集 → 全件検証 → 問題なければ有効化 教訓： - 「作成→コミット→検証」の流れは危険 - 「作成→サンプル検証→問題発見→修正→コミット」が正しい - 時系列データは特に注意が必要 - 誤り発見時は即座に無効化し、体制を整えてから再開 ``` ### 例：xAI APIを使ったデータ検証 ``` 状況: TV番組の放送回データ65件の正確性を確認したい 検証ワークフロー： 1. **検証スクリプト作成** → xAI API（Grok）を使用 → Web検索ツールを有効化 → 各番組の公式サイトを検索対象に 2. **サンプル検証**（最初の5件） → 13番組のうち5番組をランダム選択 → APIで検証クエリを実行 → 結果を分析 3. **問題発見時の対応** → 誤りパターンを特定 → 残りのデータも同様の問題がある可能性が高い → 全件検証を実施 4. **検証結果の分析** → 放送局誤り：6番組 → 曜日誤り：4番組 → タイトル誤り：ほぼ全件 → 重大なデータ品質問題と判断 5. **対応決定** → 全データの無効化 → 再収集体制の構築 → 品質管理プロセスの確立 技術的ポイント： - xAI Responses API（/responses エンドポイント）を使用 - stream: true でリアルタイム取得 - tools: [{ type: "web_search" }] で検索機能を有効化 - 検証結果は構造化して記録 ``` --- ## 判断の委譲（自分で決めない） ### 判断をユーザーに委ねるべき状況 以下の場合は**自分で判断せず**、必ずユーザーに確認すること： | 状況 | 例 | 対応 | |-----|-----|------| | **削除 vs 保持** | データを削除する際、過去実績として残すか完全削除するか | 「どちらにしますか？」と確認 | | **信頼性の判断** | 情報源AとBが矛盾している | 両方提示して「どちらを優先しますか？」と確認 | | **スコープの変更** | 調査中に関連するが別の重要な問題を発見 | 「この問題も調査しますか？」と確認 | | **既存データの扱い** | ユーザーが提供した新情報と既存データが大きく異なる | 差分をリストアップして確認 | ### 「とりあえずこの方向で」と決めない ❌ **避けるべき対応**: - 「過去の実績として残しておきます」→ 実は誤記載で完全削除すべきだった - 「古いので削除します」→ 実は履歴として残すべき重要データだった - 「これは正しいと思います」→ ユーザーの意図と異なっていた ✅ **正しい対応**: - 「過去の実績として残しますか？それとも完全に削除しますか？」 - 「このデータは履歴として保持すべきでしょうか？」 - 「AとBのどちらを正として採用しますか？」 --- ## 最終的なアドバイス - **決められた手順はない**。状況に応じて最適な道を選ぶ - **迷ったらユーザーに確認**しても良い - **「深く調べすぎたかも」と思ったら**、それは徹底できた証拠 - **楽しむ**。面白いと思ったことは本当に面白いはず - **自分で判断しすぎない**。削除/保持、正/誤など、判断に迷ったら必ず確認 - **データは嘘をつく**。検証してから信じる - **検証記録を残す**。次の人のため、未来の自分のため --- **このスキルの使い方**: 参考にしつつ、自分の判断で臨機応変に動く **関連スキル・ドキュメント**: - **TV番組データ管理**: `tv-program-data` スキル（lib/knowledge/ の番組データ管理・検証・更新用） - 詳細調査フレームワーク: [references/detailed-frameworks.md](references/detailed-frameworks.md)