はじめに
今回は、自分に最も関係ありそうな"product-management"を動かしてみる。 ちなみに、2026/3/30時点では次の11種類がある。
リポジトリはここ。 https://github.com/anthropics/knowledge-work-plugins
| Plugin | How it helps | Connectors |
|---|---|---|
| productivity | Manage tasks, calendars, daily workflows, and personal context so you spend less time repeating yourself. | Slack, Notion, Asana, Linear, Jira, Monday, ClickUp, Microsoft 365 |
| sales | Research prospects, prep for calls, review your pipeline, draft outreach, and build competitive battlecards. | Slack, HubSpot, Close, Clay, ZoomInfo, Notion, Jira, Fireflies, Microsoft 365 |
| customer-support | Triage tickets, draft responses, package escalations, research customer context, and turn resolved issues into knowledge base articles. | Slack, Intercom, HubSpot, Guru, Jira, Notion, Microsoft 365 |
| product-management | Write specs, plan roadmaps, synthesize user research, keep stakeholders updated, and track the competitive landscape. | Slack, Linear, Asana, Monday, ClickUp, Jira, Notion, Figma, Amplitude, Pendo, Intercom, Fireflies |
| marketing | Draft content, plan campaigns, enforce brand voice, brief on competitors, and report on performance across channels. | Slack, Canva, Figma, HubSpot, Amplitude, Notion, Ahrefs, SimilarWeb, Klaviyo |
| legal | Review contracts, triage NDAs, navigate compliance, assess risk, prep for meetings, and draft templated responses. | Slack, Box, Egnyte, Jira, Microsoft 365 |
| finance | Prep journal entries, reconcile accounts, generate financial statements, analyze variances, manage close, and support audits. | Snowflake, Databricks, BigQuery, Slack, Microsoft 365 |
| data | Query, visualize, and interpret datasets — write SQL, run statistical analysis, build dashboards, and validate your work before sharing. | Snowflake, Databricks, BigQuery, Definite, Hex, Amplitude, Jira |
| enterprise-search | Find anything across email, chat, docs, and wikis — one query across all your company's tools. | Slack, Notion, Guru, Jira, Asana, Microsoft 365 |
| bio-research | Connect to preclinical research tools and databases (literature search, genomics analysis, target prioritization) to accelerate early-stage life sciences R&D. | PubMed, BioRender, bioRxiv, ClinicalTrials.gov, ChEMBL, Synapse, Wiley, Owkin, Open Targets, Benchling |
| cowork-plugin-management | Create new plugins or customize existing ones for your organization's specific tools and workflows. | — |
まずは使ってみる
何ができるかも分からない！ ということでスラッシュコマンドから、実行してみる。
/product-management:feature-spec
ふむ、PRDの作成・整理ができるのね。 だったらちょうど検索機能が欲しいからこんな感じで依頼してみる。
ものの数分でPRDを作成してくる。 何も設定していないプレーンな状態でも、最もらしい言葉を並べてくれる。
ただ、成功指標のあたりは「どうなの？」って感じる部分も多いから、 「どういう切り口で、どういうデータを扱うか」を考えるのが、人間とAIエージェントとの棲み分けになっていくんだろうか。
以下、記念品として生成物を置いておく。
PRD：記事キーワード検索機能
バージョン： 1.0 作成日： 2026-03-30 ステータス： ドラフト
1. 問題定義
ブログ・コンテンツサイトのユーザーは、読みたい記事を探す際に全記事を一覧からスクロールして探すか、カテゴリページを巡回するしかない。記事数が増えるにつれて目的の記事にたどり着くまでに時間がかかり、離脱率の増加とユーザー満足度の低下を招いている。
誰が・どのくらい影響を受けているか
一般消費者ユーザー全員が対象であり、特にサイトを訪問した際に特定のテーマや情報を探している目的志向型ユーザー（全訪問者の推定40〜60%）が強く影響を受けている。
解決しないことのコスト
- 直帰率の上昇（目当ての記事が見つからず離脱）
- PV数・滞在時間の機会損失
- 競合サイトへの流出（検索機能を持つ競合への乗り換え）
2. ゴール
| # | ゴール | 種別 | 計測方法 |
|---|---|---|---|
| G1 | 検索機能の利用率：サイト訪問者の30%以上が検索を使う（リリース後30日以内） | ユーザーゴール | アクセス解析（検索バー操作数 ÷ 総セッション数） |
| G2 | 検索からの記事閲覧完了率50%以上 | ユーザーゴール | 検索結果クリック→記事読了のコンバージョン率 |
| G3 | 平均「目的記事到達時間」を現在比30%短縮 | ユーザーゴール | セッション開始→記事ページ滞在30秒以上までの平均時間 |
| G4 | 直帰率を現在比10%改善 | ビジネスゴール | Google Analytics 直帰率 |
| G5 | 検索ゼロヒット率を15%以下に抑える | ビジネスゴール | 検索クエリの結果0件の割合 |
3. 非ゴール（スコープ外）
| 項目 | 理由 |
|---|---|
| オートサジェスト／インクリメンタルサーチ | v1はMVPに集中し、レスポンス複雑性を避ける。v2以降で対応 |
| パーソナライズ検索（閲覧履歴に基づくランキング） | ユーザーデータ基盤が未整備のため、別途インフラ整備が必要 |
| 高度な検索演算子（AND / OR / NOT、フレーズ検索） | 一般ユーザーには過剰機能であり、UIの複雑化を招く |
| 外部サイト・SNSを含むクロスサービス検索 | スコープと権限管理が大幅に複雑化する |
| 音声検索 | ユーザーニーズの優先度が低く、別ステップで検討 |
4. ユーザーストーリー
優先度：高（P0）
-
一般ユーザーとして、サイト内のどのページからでもキーワードを入力できる検索バーにアクセスしたい。そうすることで、わざわざトップページに戻らなくても目的の記事を即座に探し始めることができる。
-
一般ユーザーとして、キーワードを入力してEnterキーを押すと（またはボタンをクリックすると）、関連する記事の一覧が表示されてほしい。そうすることで、自分の興味に合った記事を素早く一覧から選んで読めるようになる。
-
一般ユーザーとして、検索結果に記事タイトル・サムネイル・公開日・概要（冒頭の抜粋）が表示されてほしい。そうすることで、クリック前に記事が自分の求めている内容かどうか判断できる。
優先度：中（P1）
-
一般ユーザーとして、検索結果が0件のとき、「見つかりませんでした」というメッセージと代わりのアクション（例：おすすめ記事、カテゴリ一覧）を表示してほしい。そうすることで、行き止まりにならず次のアクションをとれる。
-
一般ユーザーとして、検索結果の各記事に検索キーワードがハイライト表示されてほしい。そうすることで、なぜその記事が表示されたのかが一目でわかる。
-
サイト管理者として、どのキーワードが最も検索されているか確認できる管理画面のログが欲しい。そうすることで、ユーザーニーズを把握して記事の企画に活かせる。
優先度：低（P2）
- 一般ユーザーとして、検索結果をカテゴリや日付でフィルタリングしたい。（スコープ外：v2以降で対応）
5. 要件
P0：必須要件（これがないとリリース不可）
| ID | 要件 | 受け入れ条件 |
|---|---|---|
| R01 | 全ページのヘッダーに検索バーを設置する | - サイト内全ページのヘッダーに検索入力フィールドが表示される - PCとモバイル両方に対応している |
| R02 | キーワード入力→検索実行→結果表示 | - Enterキー押下またはアイコンクリックで検索が実行される - 結果ページへの遷移は1秒以内（通常の回線速度） |
| R03 | 検索対象フィールド：記事タイトル・本文・タグ | - タイトルまたは本文にキーワードを含む記事が検索結果に表示される - 部分一致に対応している（例：「プログラム」で「プログラミング」がヒット） |
| R04 | 検索結果の表示項目 | - タイトル、サムネイル画像、公開日、本文冒頭の抜粋（100〜150字）が表示される - 各結果は記事詳細へのリンクになっている |
| R05 | 検索結果のソート：関連度順（デフォルト） | - デフォルトはキーワードの一致度が高い順に表示される |
| R06 | 空白・空文字での検索の制御 | - 空白のみ・空文字で検索した場合は実行されない、またはエラーメッセージを表示する |
| R07 | 検索結果0件時のハンドリング | - 「"○○"に一致する記事は見つかりませんでした」というメッセージを表示する - 代替として人気記事またはカテゴリ一覧へのリンクを表示する |
P1：強く推奨される要件
| ID | 要件 | 受け入れ条件 |
|---|---|---|
| R08 | キーワードハイライト表示 | 検索結果の抜粋文内に、入力キーワードが太字またはマーカーで強調される |
| R09 | ページネーション（1ページあたり10〜20件） | 検索結果が多い場合、次のページに移動できるUIが表示される |
| R10 | 検索クエリのログ保存 | 検索された全キーワードと実行日時・結果件数を管理用DBに記録する |
P2：将来対応
- フィルタリング機能（カテゴリ・日付）
- 検索サジェスト
- パーソナライズランキング
6. 成功指標
リリース後1週間（ローンチ確認指標）
| 指標 | 目標値 | 計測ツール |
|---|---|---|
| 検索バーのクリック数 | 1日あたり100クリック以上 | Google Analytics / ヒートマップ |
| 検索実行完了率 | 検索バー入力者の80%以上が実行まで完了 | イベントトラッキング |
| エラー発生率 | 0.1%以下 | サーバーエラーログ |
リリース後30日（主要成果指標）
| 指標 | 目標値（成功） | 目標値（ストレッチ） |
|---|---|---|
| 検索機能の利用率 | 訪問者の30% | 訪問者の45% |
| 検索→記事閲覧完了率 | 50% | 65% |
| 直帰率改善 | 現状比 -10% | 現状比 -20% |
| ゼロヒット率 | 15%以下 | 10%以下 |
7. 未解決事項
| # | 質問 | 担当 | ブロッキング？ |
|---|---|---|---|
| Q1 | 検索エンジンは自前実装（DBの LIKE 検索）か外部サービス（Algolia、ElasticsearchなD）を使うか？ | エンジニアリング | YES（着手前に決定必要） |
| Q2 | モバイルでの検索バーUIはヘッダーに常時表示か、アイコンクリックで展開するか？ | デザイン | YES（設計前に決定必要） |
| Q3 | 検索ログに個人情報（IPアドレス等）を含める場合、プライバシーポリシーの更新が必要か？ | 法務・コンプライアンス | NO（リリース前に確認） |
| Q4 | 記事本文の全文インデックスをどの頻度で更新するか（リアルタイム or 定期バッチ）？ | エンジニアリング | NO（技術詳細設計フェーズで決定） |
| Q5 | 検索結果のランキングロジックのベースは何か（更新日 / PV数 / キーワード出現頻度）？ | プロダクト + エンジニアリング | NO（v1はシンプルな一致度で可） |
8. タイムライン考慮事項
| フェーズ | 内容 | 想定期間 |
|---|---|---|
| 設計・要件確定 | Q1・Q2の未解決事項を決定、UIワイヤーフレーム作成 | 1週間 |
| 開発（バックエンド） | 検索APIの実装、インデックス構築 | 2週間 |
| 開発（フロントエンド） | 検索バーUI、結果ページUI実装 | 1週間 |
| QA・テスト | 動作確認、エッジケーステスト（空白・特殊文字・大量件数） | 1週間 |
| リリース・モニタリング | 段階的リリース、指標の監視 | 1週間 |
| 合計（目安） | 約6週間 |
このPRDはv1 MVPのスコープを対象としています。フィルタリング・パーソナライズ機能等はv2以降の別スペックとして管理してください。