Wantedly でプロダクトマネージャー（PdM）をしている吉野雄大です。

半年前、「生成AIを駆使して『戦略』を練り上げる、PdMプロセス」という記事を書きました。ChatGPT で壁打ちし、Perplexity でリサーチし、Cursor で構造化する、個人の思考を加速させるワークフローの紹介でした。

あれから半年、ワークフローはかなり変わりました。ツールが変わったというよりも、「AI を何のために使うか」の前提が変わった感覚です。今回はその変化について書きます。

前回からの課題感

前回のやり方で半年ほど運用していましたが、いくつか課題を感じていました。

① まず、ツールが分散していること。ChatGPT でアイディアの発散、Perplexity でリサーチ……と使い分けていて、最終的には Cursor にまとめを収束させていました。ただ、ツールをまたぐたびにコンテキストが途切れるので、同じ前提を何度も説明し直す手間がありました。

② 次に、知識が属人化すること。自分のローカルにメモやコンテキストが溜まっていくので、他のメンバーが同じ質問を AI にしても、自分と同じ品質の回答が返ってこない。結局「吉野のローカルにあるコンテキストを共有してもらう」か「直接聞く」しかない状態でした。

③ そして、コンテキストを共有しても判断基準や手順がブレること。同じ情報を渡しても、プロンプトの書き方次第で成果物の品質が変わります。「こういうとき、こういう観点でチェックする」という暗黙のルールが共有されていなかった。

どう変えたか（全体像）

• 課題①：ツール分散でコンテキストが途切れる
  Claude Code に統合。MCP・CLI で外部ツールを接続
  情報収集から執筆まで1セッションで完結するようになった
• 課題②：知識が属人化し、メンバーが同じ品質で使えない
  GitHub リポジトリでコンテキストをチーム共有
  誰が聞いても同じ前提で回答が返るようになった
• 課題③：共有しても、判断基準や手順がブレる
  rules / skills を整備してリポジトリに同梱
  誰が実行しても同じ品質の成果物が出るようになった

補足しておくと、ChatGPT でコンテキストなしに気軽にアイデア出しをしたり、Perplexity でリサーチしたりは使い分けて、引き続き利用をしています。全部を1つに寄せたわけではなく、「作業のメイン」が Claude Code に移った、という感覚です。

以下、それぞれ具体的に書きます。

① Claude Code + MCP でツールを統合

Claude Code で外部ツール接続をした

現在の作業環境は Claude Code に統一しています。

大きな変化は、MCP や CLI を通じて外部ツールに接続した点です。MCP（Model Context Protocol）とは「AI に外部サービスへのアクセス手段を与える規格」で、これに加えて GitHub コマンドや Google Workspace などの CLI も組み合わせて使っています。

実際にどう使っているかの例を挙げると

• 新しいプロジェクトを始めるとき、Slack の関連チャンネルから過去の議論や経緯を AI にまとめてもらう
• KPI の進捗をスプレッドシートから取得して、定例用のレポートを生成する
• 経営会議で決まった方針や、GitHub issueコメントを拾って企画書の前提に反映する

など。

コンテキストが途切れずに作業できるようになった

たとえば「先週の定例で決まった方針を踏まえて、KPIデータを分析し、次の施策の企画書を書く」という作業があります。以前なら Slack を開いて理解し、スプレッドシートを開き、Cursor に貼り付けて……と往復していたのですが、今は1つのセッションで完結します。

Claude が Slack の議論を読み、スプレッドシートから数値を取得し、過去の企画書のフォーマットに沿って書く。コンテキストが途切れないので、自分がやるのは方向性の判断と最終確認です。

②GitHub 管理でチームの知識基盤にした

個人ローカルから共有リポジトリへ

前回の記事では、すべてが自分のローカルマシンで完結していました。今はPdM専用の GitHub リポジトリでチームのドキュメントを管理しています。

pdm-chapter/
├── .claude/            # AI の設定（rules / skills）
├── 00_context/         # 参照知識（KPI定義・用語集・規約ガイド等）
├── 01_templates/       # 文書の雛形
├── 10_ServiceA/        # サービス A の実務
│   ├── 10_strategy/    # 中期戦略・ロードマップ・定例議事録
│   ├── 11_projects/    # プロジェクト単位の企画・設計
│   │   ├── プロジェクトX/
│   │   ├── プロジェクトY/
│   │   ├── ...
│   │   └── _archive/   # 完了したプロジェクト
│   └── 12_idea/        # プロジェクト化前のアイデア
├── 20_ServiceB/        # サービス B の実務
├── 80_chapter/         # 組織運営・活動
└── 90_personal/        # 個人メモ

フォルダは「知識」と「実務」を分けた

このリポジトリの設計で意識したのは「知識」と「実務」を分けることです。

• 知識（00_context/）:
  KPI の定義、ファネル構造、用語集、規約ガイドなど。変更頻度が低く、チーム全員が参照するもの
• 実務（10_ServiceA/等）:
  企画書、議事録、プロジェクト計画。日々更新され、担当者が書くもの

AI は渡されたコンテキストの中でしか正確な回答を返せません。たとえば「CVRを分析して」と頼んだとき、KPI の定義がコンテキストに入っていなければ、AI は一般的な定義で CVR の式を予測して答えてしまいます。定義を知識として置いておけば、誰がいつ聞いても同じ前提で回答が返ってきます。

逆に、実務ファイル（企画書や議事録）は頻繁に変わるし担当者ごとに書き方が違う。これを知識と同じ場所に混ぜると、AI が古い情報を参照してしまうリスクがあります。だから分けています。

③Rules / Skills で品質を標準化した

Rules：判断基準を整備・強化した

コンテキストを共有しても、まだ課題が残りました。普段の仕事には「毎回必ず確認すべきこと」があります。たとえば新しい施策を企画するとき、利用規約やプライバシーポリシーの改修が必要かを確認する工程。大事だとわかっていても、毎回プロンプトに書くのは面倒だし、忙しいと忘れます。

Claude の rules という機能で、これを解決しています。マークダウンで判断基準を書いておくと、セッション開始時に自動で読み込まれ、該当する場面で Claude が自律的に従います。

実際に使っているルールはこんな感じです:

.claude/rules/
├── check-terms-policy.md    # 規約・ポリシー改修チェック
├── check-job-placement.md   # 法務リスクの該当性チェック
├── kpi-data-handling.md     # KPI データの取り扱いルール
├── suggest-research.md      # 企画検討時のリサーチ提案の型
└── google-docs.md           # Google Docs の読み取り手順
など

たとえば check-terms-policy.md の中身はこう書いています

# 規約・ポリシー・ヘルプページの改修チェック


チェックを実行するタイミング:
- 新しい企画・設計ファイルを初めて作成するとき
- 企画の方針・スコープが変わる変更を加えたとき
...

こう書いておくだけで、企画書を新規作成するたびに Claude が規約チェックを走らせてくれます。ルールはコードとして管理しているので、更新すればチーム全員の AI に即座に反映されます。

Skills：繰り返しの業務を再現可能にした

定例会の議事録作成、KPIレポートの生成、スケジュール確認——PdM には繰り返しの業務が多いです。これらを Skills として定義しています。

.claude/skills/
├── meeting-notes        # 議事録作成
├── visit-schedule       # スケジュール管理
├── visit-kpi-csv-sync   # KPI データ同期
├── analysis-report      # 分析レポート生成
└── blog-reviewer        # ブログレビュー
など​

スキルは「このタスクではこういう手順で、こういう判断基準で、こういうフォーマットで出力する」をまとめたものです。たとえば議事録スキルには「まず施策管理スケジュールを確認し現状を把握。その上で、音声書き起こしと Google Doc のメモを統合し、決定事項・理由・アクションアイテムを構造化して出力する」という手順が書かれています。Skill化により、誰が実行しても同じ品質の成果物が出るようになりました。

前回との比較

• メインの作業環境
  Cursor（他ツールからコピペで集約） → Claude Code（MCP/CLI で直接接続）
• コンテキスト
  ツール間で途切れる → 1セッション内で連続する
• 知識の管理
  ローカルに散在 → GitHub リポジトリで一元管理
• 再現性
  プロンプト次第でブレる → rules/skills で担保
• 受益者
  自分だけ → チーム全員
• AI の役割
  主に思考の壁打ち相手 → チームのオペレーティングシステム

実際に運用してみて

そもそもチーム基盤にすべきか、正直迷った

実はこの仕組みをチームに展開するかどうか、しばらく悩んでいました。

懸念は「skill が自動で処理してしまうと、個々人のスキルが育たないのでは」ということです。誰かが裏側で skill を設計・整備していて、他メンバーはそれを意識することなく、AIがいい感じに振る舞い、いい感じのレポートや議事録が出てくる。便利だけど、それって知的産業の工場員を作る結果になるのではないか、と。

間違いなく効率は上がったし、チーム内でも「この仕組みは助かる」という声は出ています。ただ、正直なところ私の中にまだ答えはありません。効率化と育成のバランスをどこに置くのか、引き続き考えながら運用しています。

情報の蓄積が、チームにも自分にも効いてきた

もう一つ実感している効果があります。戦略会議の内容もリポジトリに入っているので、チームメンバーがプロジェクトを立ち上げるとき、戦略的な背景を最初から理解した状態で始められます。逆方向もあって、チームのプロジェクト進捗が蓄積されるので、経営会議の資料を作るときに最新の状況をすぐ反映できる。上から下、下から上の情報伝達が、同じリポジトリを介して自然に回る感覚です。

私自身の業務でも変化がありました。以前は提案書のアウトプット自体はまとめていたのですが、オフラインの打ち合わせや Slack で生まれた文脈（なぜこの方向になったか、何を懸念して却下されたか）は管理していなかった。今は打ち合わせの内容もリポジトリに入れるようにしていて、調査データ・前回の提案・議論の経緯がすべて同じ場所にある状態で次の提案を書き直せます。

これは Claude Code の機能というより、「情報をどこに残すか」の習慣が変わった結果です。ツールを統合して置き場所が明確になったことで、以前は放置していた情報も自然に格納するようになりました。

AI 活用には段階がある

振り返ってみると、私の AI 活用は段階的に変わってきています。

1. 個人の加速: AI で自分の作業を速くする
2. 個人の構造化: ルールと手順を定義して、品質を安定させる
3. チームの標準化: 知識とルールを共有し、チーム全体の精度を上げる

世の中の「AI活用事例」は 1 の話が多い印象です。ただ、組織として価値が出始めるのは 3 に到達したときだと実感しています。

半年前は「AI を使うと自分が速くなる」という話を書きました。今は「AI を前提にチームの情報構造を設計すると、全員の判断精度が上がる」と感じています。

ツールは変わり続けます。Claude Code も MCP も半年後には別のものになっているかもしれません。ただ、「知識を構造化し、判断基準を明文化し、チームで共有する」というやり方自体は、ツールが変わっても使い続けられるはずです。

Wantedly では、Claude Code をはじめ様々な AI ツールを会社として導入しており、こうした環境で働くことに興味がある方はぜひお声がけください！PdM も募集しています！