メニュー
作成手順「research-synthesis」（self-evolving-agent から自動同期）: Procedure: research-synthesis
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
全 Claude セッションをスキャンし、ユーザーが何をしているかを分析して、 スキル・MCP プラグイン・エージェント・CLAUDE.md のどれに最適化すべきかを分類し、 具体的な改善提案（優先度・実装難易度・推奨アクション付き）を生成する。 Use when the user wants to analyze their Claude usage patterns, or when asked to "scrape sessions", "what do I do with Claude", or "what should be a skill vs agent vs claude.md".
PRをレビューしてインラインコメントをGitHubに投稿する。PR descriptionで意図を把握してからdiffをレビューし、What+Why+How形式・重大度ラベル付きのコメントをgh APIで各行に直接投稿する。「PRをレビューする」「コードレビューしたい」「このPRの品質を確認したい」時に使う。
Claude Code のトークン使用量・コストの確認と分析を行う。日次・月次レポートの表示から 高コスト要因・キャッシュ効率の分析、削減提案まで（表示だけの軽量モードあり）。 Use when you need to check today's or this month's token usage and cost, or to analyze Claude Code costs and get reduction suggestions. Triggers on: "今日のコスト", "今月のコスト", "トークン使用量", "ccusage", "コスト分析", "コスト削減".
/compact の前に、圧縮の要約から抜け落ちやすい「判断構造」と「セッション状態」を tmp/compact-state/latest.md に固定フォーマットで保存する。 Use when you are about to run /compact, when the user says "compact する前に", "compact-prep", "コンテキストを圧縮したい", or when context usage is high and compaction is imminent. Do NOT use for cross-session handover documents (use handover) — compact-prep is for surviving in-session compaction, not for ending a session.
現在のセッションの作業内容を次のセッションへ引き継ぐための引き継ぎドキュメントを生成する。 Use when the user asks to summarize the session for handover, says "引き継ぎ", "次のセッションに渡して", "context をまとめて", or when a session is ending and you think it would help to create a handover document for continuity. Also use when you are about to run out of context and want to preserve progress.
作成手順「1on1-prep」（self-evolving-agent から自動同期）: 1on1 準備手順（ EM 版）
| name | research-synthesis |
| description | 作成手順「research-synthesis」（self-evolving-agent から自動同期）: Procedure: research-synthesis |
用途: Andy が任意のリサーチ（競合分析・SNS 動向・ユーザー調査・技術トレンド）を実施し、
プロダクト意思決定に直結するアウトプットとして Notion/Slack に共有するとき。
workspace/research-YYYYMMDD-[テーマ略称].md または Notion の所定リサーチページに作成。
タイプが変わると適切なソース・統合軸・共有先が変わる。着手前に確定する。
| タイプ | 代表例 | 追加で必須になる要素 |
|---|---|---|
| 競合分析 | 競合アプリの新機能・価格変更・UI 刷新 | 📌/💭 の事実/推測区別、外部バリデーションとしての活用方針 |
| SNS 動向 | AppStore レビュー・Twitter/X トレンド・Reddit 反応 | 声の量と質の区別（ボリューム指標 vs 代表コメント抽出） |
| ユーザー調査統合 | インタビュー議事録・アンケート・UX テスト | データの代表性・バイアス注記 |
| 技術トレンド | Android/iOS SDK 変更・新ライブラリ・Google I/O 発表 | チームへの影響度評価（対応必須/オプション/観察継続） |
| クロス型 | 複数タイプの統合（競合 + SNS + アナリティクス等） | 各ソースの重み付けと統合軸の事前定義 |
テンプレート:
「[具体的な情報] を知りたい。なぜなら [期日・文脈] における [意思決定] に使うから。」
良い例:
悪い例（着手禁止）:
なぜ問いを先に定義するか: 問いなしで調査を始めると「情報は集まったが何を決めるか分からない」状態になる。後から問いを設定しようとすると、集めたデータに合わせて問いを作るバイアスが生じる。
タイプ別の優先ソース:
| タイプ | 一次ソース（📌 確認推奨） | 二次ソース（💭 参考） |
|---|---|---|
| 競合分析 | AppStore/Play Store リリースノート、公式ブログ・プレスリリース | SNS の反応、テック媒体の報道 |
| SNS 動向 | AppStore/Play Store レビュー（直近 30〜90 日）、Twitter/X キーワード検索 | Reddit r/[カテゴリ]、YouTube コメント |
| ユーザー調査統合 | インタビュー議事録、アンケート生データ、ヒートマップ | CS チームのユーザー声まとめ |
| 技術トレンド | 公式 Changelog（Android Developers・iOS Dev ブログ） | Qiita・Zenn・Medium・GitHub Stars 動向 |
「ソースを選んだ理由」を一行書く（後から再現できるように）:
今回のソース: AppStore レビュー（直近90日・評価3以下）+ Twitter/X「[アプリ名] 不満」
選定理由: リリース後ユーザーの生声を最短で集めるため。定性的な代表声を取る目的なので n < 50 でも可。
収集しながら以下の記法で記録する:
| マーク | 意味 | 使い方 |
|---|---|---|
| 📌 | 事実（一次情報で確認済み） | AppStore 記載・公式ブログ・生インタビュー発言 |
| 💭 | 推測（論理的に導いた解釈） | 必ず「〇〇から類推」と根拠を添える |
| ❓ | 要確認（一次情報未取得） | 共有前に確認が必要な項目。放置しない |
事実と推測が混在すると、PM・本部長が「これは確かな情報か？」と都度確認する往復コストが発生する。記法を統一することで「📌 は裏取り済み、💭 は解釈」が一目で分かり、意思決定の速度が上がる。
❌ やってはいけない（ソース別列挙）:
競合A: AI 予定提案を追加、無料枠を拡大
競合B: 法人向けプランを新設
AppStore レビュー: 「使いにくい」という声が多い
→「で、TimeTree は何をすべきか」の答えが出てこない。
✅ 正しい統合（テーマ別）:
テーマ①「AI 機能のコモディティ化」
- 📌 競合A・B が同四半期に AI 提案を追加 → 業界全体のトレンドになっている
- 💭 差別化ではなく「あって当然」の機能になる兆候（スマートスピーカー音声操作と同じ軌跡）
テーマ②「ユーザーの認知負荷への不満」
- 📌 AppStore レビュー 3 ヶ月分で「操作が複雑」が最頻出ワード（47/120 件）
- 💭 競合Aのシンプル UI への切り替えと時期が重なる → UI 競合が始まっている可能性
テーマの切り出し方（3 ステップ）:
各テーマについて以下の構造で書く:
## テーマ[n]：[タイトル]
### 観察（📌 事実）
[確認済みの事実を箇条書き]
### 解釈（💭 推測）
[なぜそれが起きているか・何を意味するか。「〇〇から類推」を必ず添える]
### EVD/TimeTree への影響
| 脅威/機会 | 内容 |
|---|---|
| 脅威 ⚠️ | [放置するとどうなるか] |
| 機会 ✨ | [活かせるとどうなるか] |
### アクション案
| 優先度 | アクション | 期待値・担当・期限 |
|---|---|---|
| ⭐⭐⭐ 高 | [具体的アクション] | [誰が / いつ / 何のために] |
「示唆なし → アクションなし」は禁止。テーマを立てる以上、必ず判断・行動への接続を書く。書けないテーマは「今回の問いに関係なかった」として削除し、別回に回す。
# [リサーチタイトル]
| 項目 | 値 |
|---|---|
| 作成日 | [今日の日付] |
| 作成者 | Andy（EM / Discovery チーム）|
| リサーチタイプ | [競合分析 / SNS 動向 / ユーザー調査統合 / 技術トレンド / クロス型] |
| リサーチ問い | [Step 1 で定義した 1 文] |
| 想定読者 | [チーム / PM（Oz・Meicy）/ 本部長 など] |
| ソース | [使ったソースと確認日] |
| ステータス | 共有可 / ❓ 要確認事項あり（下記リスト参照）|
---
> **着手前に埋める項目（❓ 要確認の場合）:**
> 1. `[❓ 項目: 確認先・確認方法]`
---
## 凡例
📌 = 一次情報確認済みの事実 ／ 💭 = 推測（根拠つき）／ ❓ = 要確認
---
## テーマ [n]：[タイトル]
（Step 5 のフォーマットで記述）
---
## 全体サマリー
| テーマ | 脅威 | 機会 | 最優先アクション |
|---|---|---|---|
| テーマ① | … | … | … |
### 直近の優先アクション（期限付き）
| 期限 | アクション | 対応テーマ |
|---|---|---|
| 🔴 [期日（曜日）] | … | テーマ① |
---
## 未解決の問い（次回リサーチのシード）
1. [今回答えられなかった問い]
2. [継続観察が必要な動き]
| アクション | タイミング | 方法 |
|---|---|---|
| Notion 転記 | 作成当日中 | Discovery チームのリサーチまとめページに追記 |
| チーム共有 | 当週のリファインメントまたは定例で口頭説明 | Slack に URL を貼り、1 行サマリーを添える |
| PM 共有 | 最優先アクションが PM 判断を要する場合は当日 Slack | 「示唆の結論 + アクション提案 + 要判断事項」の 3 点形式 |
| 継続観察 | 「継続追跡が必要」と判断した場合 | 担当者・確認頻度（週次/月次/四半期）を Notion に記録 |
| 次回シードへ | 未解決の問いを次のリサーチ問いの候補に | workspace/research-backlog.md または Notion にストック |
取り込み経緯: 2026-06-23 の auto-kaizen セッションで「research-synthesis が 10 ドメイン中で
唯一 Procedure ゼロ・Lesson ゼロかつ、競合分析以外のタイプ（SNS 動向・ユーザー調査・技術トレンド）
に対する品質担保がゼロ」と自己診断。Andy の優先事項 #4「プロダクト戦略の深化」に直結し、
週次リファインメントで毎回使う高頻度タスクとして選定。workspace/auto-kaizen.md に作成後
procedure として昇格。