この記事は、著者がメルカリの PM インターンとして構築した Agent Skills パッケージ mercari-pm-agent について説明している。このスキルは、課題の発見、データ収集、PRD の作成、UI モックアップという、プロダクトマネージャーがたどるワークフローを単一のセッション内で処理する。記事の焦点は、プロダクトとしての成果ではなく、そのスキルの設計と、その背後にある Model Context Protocol の接続である。
出発点となる課題は、アクセスではなく統合である。メルカリの PM は、中期戦略や KPI 目標を Notion で確認し、社内の要望やフィードバックを Slack で検索し、ユーザーの定量的な指標を Looker で確認し、現在のデザインを Figma で見て、それらすべてを PRD に統合する。記事の指摘は、各ツールにたどり着くこと自体は難しくないということである。無視できない時間がかかるのは、それらを行き来しながら、目の前の意思決定にとってどのデータが重要かを整理することである。PM の時間を代わりに何に使うべきかについての記事の見解は、集めた情報について深く考え、意思決定を行い、ステークホルダーと対話することである。著者がこのツールを作った動機として挙げるのは、情報収集にかかる時間を減らし、その分を思考と意思決定に振り向けることである。
最も他に応用しやすい主張は、PM の仕事についてではなく、プロンプトの構造についてのものである。当初すべてを 1 つの SKILL.md にまとめていた著者は、採点を通じて、ファイルが長いほど出力の精度が悪化することに気づき、それに応じて振る舞いの定義と参照データを分離した。記事はこれを、ソフトウェアエンジニアリングにおける関心の分離をプロンプト設計に適用したものとして提示しており、構造の変更だけでスコアが明確に向上したと報告している。
要点
- スキルは、エージェントの振る舞いの定義を保持する薄い
SKILL.mdと、PRD テンプレート、9 項目の PRD 品質チェックリスト、UI 仕様と Figma プロンプトのテンプレート、データ解釈ガイド、データソース一覧、出力チェックリストを保持するreferences/ディレクトリで構成されている。記述されている役割分担は、SKILL.mdには何をどの順序で行うかだけを置き、具体的なデータやテンプレートは必要なときに参照する、というものである。 - 著者は、長いファイルでの精度の問題を、長いコンテキストの中ほどにある関連情報にモデルが適切に注意を向けられなくなるという、しばしば「Lost in the Middle」と呼ばれる既知の現象と関連づけており、Anthropic のプロンプトエンジニアリングのガイダンスもプロンプトを簡潔に保つことを推奨していると指摘している。
SKILL.mdは英語で書かれている。著者が挙げる理由は、英語の指示のほうが Claude で高い精度が出やすいというものである。- 4 つの MCP サーバーが接続されており、そのうち 1 つは公式のもの、3 つは社内で構築されたものである。戦略ドキュメントと KPI ダッシュボードには Notion が提供する Notion MCP、社内フィードバックチャンネルの投稿にはカスタムの Slack MCP、CVR などの指標には社内の BigQuery・Looker 基盤である Socrates、デザインファイルのコンポーネント情報にはカスタムの Figma MCP を用いる。
- データ収集の際、これらの MCP ソースには並列に問い合わせが行われる。データソースの参照ファイルには、あるソースの応答を待たずに別のソースに問い合わせること、そしてソースが利用できない場合は黙ってスキップし、出力にその旨を記すことをエージェントに指示するルールが書かれている。記述されている効果は、逐次アクセスに比べて待ち時間が減ることと、一部の MCP が停止していても処理が止まらないフォールバック動作である。
- Slack MCP のセットアップには社内 VPN への接続とユーザートークンが必要で、著者はトークン文字列がチャット上に露出しないよう、それを環境変数として Claude Code の設定に渡している。Slack のユーザートークンは 7 日で失効するため、別途更新用のスクリプトが用意された。
- 評価基準は実装の前に定義された。理解の正確さ、仕様の具体性、実現可能性、UX の妥当性である。著者はこのアプローチをテスト駆動開発になぞらえ、Prompt TDD と呼んでいる。記述されている理由は、LLM ベースのエージェントでは、出力が動くかどうかよりも正しいかどうかを判断するほうが難しいため、先に評価軸を定義しておけば直感ではなく基準に基づいた改善サイクルを回せる、というものである。実際のウェブの改善テーマが評価データセットとして集められた。
- 記事は、業務ワークフローに LLM を組み込むうえで最も危険なリスクとして、もっともらしいハルシネーションを挙げている。モデルはデータが存在しないところでも妥当に見える数値を出力しうるため、それを信じた PM は PRD に作り話を書き込んでしまう。記事の立場は、これはモデルに嘘をつくなと指示するだけでは解決できず、データの欠落を認識したときにモデルがどう振る舞うべきかを制約として明示しなければならない、というものである。用いられたルールは、未確認のデータには「Not provided」または「To be validated」とラベルを付けること、そして数値や出典を決して捏造しないことである。
- また、エージェントは PM の確認なしに次のステップへ進むことを禁じられている。完了を推測することは許されず、PM からの明示的な確認があって初めて先に進める、という指示によるものである。著者が挙げる目的は、もっともらしい流れに沿ってエージェントが自動的に先へ進むのを許すのではなく、PM を意思決定の主導者として保つことである。
- 別の評価用スキルがエージェントにテストケースを送り、出力の品質についてのスコアを返す。このスコアをもとに反復したことが、ファイルを短くするという洞察を生み、ファイル分割の変更につながった。記事はこれを、スキルを使ってスキルを評価することだと説明している。
- 著者が結びで挙げる学びは次のとおりである。スキルの設計は振る舞いの仕様を書くことに近く、命令よりも制約のほうが重要であること。MCP 接続は並列性を前提に設計し、フォールバックと堅牢性をあわせて考慮すべきであること。コンテキストが長いほど精度が下がるため、関心の分離はプロンプト設計にも当てはまること。そして評価基準は実装の前に定義すべきであること。
文脈
この記事はチームの本番運用の実践ではなくインターンシップの立場から書かれており、記述されているツールは社内向けのものである。その根拠は著者自身の評価ハーネスであり、採点は同じ著者が書いたスキルによって、同じ著者が集めたデータセットに対して行われた。記事は評価そのものの数値を報告しておらず、ファイル分割による向上もスコアの明確な改善として記述されているだけで、定量化はされていない。
記事の主張は、区別しておくべき 2 種類に分かれる。メルカリにおける PM 向けツールに関する観察は、同社の技術スタックに固有のものである。一方、設計に関する主張、すなわち短い振る舞いの定義は 1 つの長いファイルよりも高いスコアを得ること、データが欠けているときの振る舞い方についての制約は捏造するなという指示が効かないところでも機能すること、そしてエージェントには自らの完了を推測させないようにすべきであること、は Claude Code Skills 上でエージェントを構築するうえでの一般的な教訓として述べられており、著者もそのようなものとして提示している。