なぜAIは企画書を書けないのか？ CursorをPdMの相棒にするために
はじめに
こんにちは！
株式会社ココナラのマーケットプレイス開発部 Web開発グループ バックエンド開発チーム所属のさいぴーです。
こちらは株式会社ココナラ Advent Calendar 2025 6日目の記事です。
ココナラでは現在、プロダクト開発のスピードを上げるため「AX推進（AIトランスフォーメーション推進）」に取り組んでいます。その一環として、私はPdM向けのAI活用環境を整備するプロジェクトを担当しています。
本記事では、「AIに事業ドメインを教える」というアプローチで、PdMの相棒となるAI環境を作った話を紹介します。
この記事を読むと：
- AIに「何を」教えればいいのか（3層のドメインコンテキスト）がわかる
- 企画向けのAI環境をどう設計するかのヒントが得られる
- 実際の活用事例から、効果のイメージが掴める
エンジニアの視点から、試行錯誤の過程で見えてきたことをお伝えします。
🤔 AIに企画書、書いてもらえましたか？
突然ですが、AIに企画書を書いてもらった時に、こんな経験をしたことはありますか？
- 「新機能の企画を考えて」→ 返ってくるのは汎用的なアイデアばかり
- 「GMVを上げる施策を考えて」→ 自社の事業構造を知らないから的外れ
- 「この機能の仕様を調べて」→ 社内用語が通じなくてうまく探せない
- 「競合と比較して強み・弱みを整理して」→ 表面的な情報しか出てこない
なぜか？AIは「事業ドメイン」を知らないからです。
🚀 開発が速くなったから、企画も速くしたい
開発側のAI活用は進んでいる
エンジニアのAI活用はここ1〜2年で大きく進みました。ココナラでも使うツールがGitHub CopilotからCursorへと変わり、開発スタイルが大きく変化しています（関連記事：いかにしてココナラはCursor Businessを導入したのか?、フルスタックエンジニア見習いがCursorを使い倒してみた！）。
AIを効果的に使うためのツールやノウハウが充実し、社内でも利活用のルールが整ってきたこともあり、開発速度は上がってきています。この技術ブログでも、開発におけるAI活用の記事がこれからどんどん上がっていくことでしょう。
施策全体で見ると、企画がボトルネックに
ただ、施策全体のリードタイムを考えると、開発フェーズは全体の一部に過ぎません。開発以外にも目を向けることにしました。
開発フェーズが速くなっても、企画フェーズに時間がかかっていたら、全体のスピードは上がりません。AX推進全体で「リードタイム40%削減」を目標に掲げていますが、開発だけでは達成が難しい。そこで、企画フェーズにもAI活用を広げることにしました。
PdMもAIを使ってはいたけれど
もちろん、PdMもGeminiやChatGPTは使っていました。ただ、「この機能のアイデアを出して」「この文章を校正して」といった単発の質問が中心で、既存プロダクトの機能や仕様をAIに与えきれていないことが課題でした。
プロジェクトの文脈を理解した上で、企画の壁打ち相手になってもらう、そういう使い方には至っていませんでした。
じゃあ、企画向けにAIを整備しよう
エンジニアとして「一緒に取り組めば、もっといい状態にできるのでは？」と思ったのがきっかけで始まったのが、社内で「coconala-aipm」と呼んでいるプロジェクトです。Cursorを使って、AIに企画業務の文脈やココナラというプロダクト、目指しているKPIや現在の数字などを理解させ、PdMの相棒として機能させる、そんな環境の構築に取り組んでいます。
💡 企画に必要なのは「事業ドメイン」
開発と企画では、必要なコンテキストが違う
ここで気づいたのは、開発向けのAI活用と企画向けのAI活用では、必要なコンテキストがまったく違うということです。
| 対象 | 必要なコンテキスト | 特徴 |
|---|---|---|
| 開発側 | コードベース、API仕様、テストコード | コードを読めばAIが理解できる |
| 企画側 | 事業構造、KPI、ドメイン用語、業務フロー | コードには書かれていない |
開発向けのAIツールが優秀なのは、コードという「形式化された情報」があるからです。AIはコードを読めば、そのプロジェクトの文脈をかなり理解できます。
一方、企画に必要な情報（「ココナラの事業構造」「GMVの分解」「サービス固有の用語」など）は、コードには書かれていません。PdMの頭の中や、散在するドキュメント、あるいはヘルプページの中にあります。
新人PdMのオンボーディングと同じ発想
これって、新人PdMのオンボーディングと似ているんですよね。新人が入ってきたら、何を教えますか？
- 用語集を渡す（「トークルーム」「正式な納品」って何？）
- KPIの構造を教える（GMVはどう分解される？）
- 業務の進め方を伝える（企画承認までに何を準備する？）
AIにも同じことをすればいい。企画向けのコンテキストを整理してAIに教えることにしたのです。
🛠️ 3層のドメインコンテキスト整備
では、具体的に何を整理したのか。まずは「PdMの企画業務フローにおいて、理解しておくべき事項は何か？」をヒアリングで把握することから始めました。すると、最低限必要なコンテキストは以下の3つだとわかりました。
① 業務フロー：いつまでに、どのようなフォーマットで成果物を作るのか？
② KPIツリー：その成果物を作るために、どんなKPI構造を知り、数字をどう取得するか？
③ ユビキタス言語：プロダクトの企画を練るために、どんな用語を共通理解にしておく必要があるか？
この3層をRulesやドキュメントとして整備することで、AIがこれらの知識を前提に企画を支援してくれるようになりました。
📋 層1：業務フロー
まず「どんな成果物が必要か」から考えた
最初に整理したのは、PdMの企画業務フローです。
ココナラでは企画の承認を得るレビューの場があり、「仕様書」と「Figma」をもとに参加者と認識を揃えます。仕様書は概要と詳細の2段階に分けて、手戻りを防いでいます。
| フェーズ | 成果物 | 内容 |
|---|---|---|
| 概要（Overview） | 企画概要書 | 課題、目的、影響するKPI、概算インパクト |
| 詳細（Detail） | 詳細仕様書 | 詳細仕様、画面フロー、エッジケース |
一方で、概要段階でも「影響するKPI」や「概算インパクト」を盛り込みます。これには、プロダクトへの理解と、データを扱うスキルの両方が求められます。
この構造をAIに教えておくことで、「企画を作りたい」と言えば「まず概要から整理しましょう」と正しいステップを踏んでくれるようになります。
PdMの企画業務には「型」がある
PdMの仕事は多岐にわたりますが、実はそれぞれに「型」があります。
- 企画立案: 背景整理 → KPI特定 → 施策検討 → PRD作成
- データ分析: どのデータソースを見るべきか → クエリ実行 → 分析
- 既存機能調査: ヘルプ記事で概要把握 → コードベースで詳細確認
これらの型をAIに教えておくと、「この作業を手伝って」と言ったときに、適切な手順で進めてくれます。
📊 層2：KPIツリー
企画にはKPI構造の理解が必須
業務フローを整理したことで、次の課題が見えてきました。企画概要書には「影響するKPI」と「概算インパクト」を盛り込みます。でも、AIに「GMVを上げたい」と言っても、GMVがどのように算出されるのか、AIにはわからないのです。これはAIの限界ではなく、私たちが事業のKPI構造を教えていないからです。
KPI構造をツリー形式で整理
そこで、KPI構造をツリー形式で整理しました。
トップKPI
├── 構成要素A
│ ├── 指標A-1
│ └── 指標A-2
├── 構成要素B
│ └── ...
└── 構成要素C
たとえば「指標A-1を上げたい」と言えば、それがトップKPIにどう影響するかを理解した上で施策を考えてくれます。
PdMからのフィードバック：ダウンサイドの考慮
最初のバージョンを作ったあと、PdMに使用感を聞きました。すると「新規プロジェクトならアップサイドを重点的に考えていいけど、既存機能の改修ではダウンサイドの影響も考える必要があるよね」というヒントをもらいました。
なるほど。そこで、KPI構造を教える際に「施策のダウンサイド（悪影響）も考慮すること」というルールを追加しました。すると「この施策はKPI Aを上げますが、KPI Bを下げる可能性があります」といった指摘が出てくるようになったんです。このように、実際に使ってみた声をルールにどんどん反映していきました。
📖 層3：ユビキタス言語辞書
「トークルーム」って何？という問題
ここまで整理して、最後に残ったのが用語の問題です。ココナラには独自の用語が多くあります。「トークルーム」「正式な納品」「おひねり」「見積もり相談」...。各チーム間で認識を揃え、プロダクトを正しく理解するためにも、用語を共通化しておくことが大事です。AIはなおさら理解できません。「トークルームを改善したい」と言っても、それが何を指すのか伝わらないのです。
10ドメイン × 220用語を整理
そこで作ったのが「ユビキタス言語辞書」です。DDDでおなじみの概念ですが、ここでは社内用語集として整理しました。
まずAIにヘルプページやフロントエンドの実装を読ませながら用語を収集させました。そこに説明文や英単語との照合、DBテーブル名や関連概念のリストなどを付与していき、最終的に10ドメイン × 220用語の辞書になりました。
- 取引ドメイン: トークルーム、正式な納品、おひねり など
- 決済ドメイン: ココナラコイン、売上金、振込申請 など
- サービス出品ドメイン: サービス、PRO認定、ランク など
- ...他7ドメイン
各用語には、こんな情報を付与しています。
正式な納品
├─ 定義: 出品者が成果物を納品し、購入者が承諾する行為
├─ ユーザー向け表現: 正式な納品
├─ システム内表現: deliver
└─ 関連テーブル: orders, order_messages
ポイントは「システム内表現」と「関連テーブル」も入れていること。これがあると、AIがコードベースやデータベースを調べるときに、正しい場所を探せるようになります。「正式な納品」という用語から orders テーブルに辿り着けるのは、地味ですが強力です。
🔌 データソース連携
3層のコンテキストを整備したら、次はデータソースとの連携です。今回は以下のデータソースと連携しました。
| データソース | 格納している情報 |
|---|---|
| BigQuery | KPIの実績値、ユーザー行動データ、取引データ |
| Notion | 既存の機能仕様書、PRD、議事録 |
| Googleスプレッドシート | WBS、企画シート、進捗管理表 |
| Slack | 過去の議論、決定事項、関連スレッド |
BigQuery連携
企画立案時に「影響するKPI」を書くには、現在の数値や推移を把握する必要があります。BIツールも使っていましたが、複数の分析軸からデータを扱うときには自分でSQLを書く必要がありました。そこで、Cursorから直接BigQueryにアクセスできるようにしました。
「先月のGMVの推移を見せて」と言えば、AIがSQLを生成してデータを取得してくれます。一番の貢献は、複雑なクエリを書けない人でもデータにアクセスできるようになったこと。SQLを書く技術的なハードルがなくなり、「知りたいこと」を自然言語で伝えるだけでデータが手に入るようになりました。
その他の情報源との連携
Notion、Googleスプレッドシート、SlackもAIからアクセスできるように設定しています。
当初はMCP（Model Context Protocol）ですべて連携しようとしましたが、コンテキスト消費が大きく、会話の途中で限界に達することがありました。結局、一部はシェルスクリプトに置き換えて軽量化しています。技術的な詳細については、また別の記事で紹介します。
🔧 構築と実践
精度向上のコツ
ユビキタス言語辞書にテーブル情報を付与したことで、AIの精度がぐっと上がりました。
用語の定義だけでは、データがどこにあるかわかりません。逆に、テーブル定義だけでは、それが何を意味するかわかりません。この2つを紐づけることで、AIは「ユーザーが話す言葉」から「データの在り処」まで辿れるようになります。
「正式な納品の件数を知りたい」
↓ ユビキタス言語辞書で変換
「正式な納品 = deliver、関連テーブルは orders」
↓ スキーマ定義を参照
「orders.delivered_at が NULL でないレコードをカウント」
↓ SQL生成・実行
テーブル定義が書かれたスキーマリポジトリも、AIがアクセスできる場所に置いています。ドメイン知識 × テーブル定義の組み合わせがあってはじめて、PdMの言葉でデータにアクセスできる環境が整いました。
現場に広げていく
小さなタスクから検証開始
まずは小さなタスクから試しました。プロジェクトにならない小さなタスクでも、既存機能の仕様を確認する場面は多くあります。「この機能、今どういう仕様だっけ？」という質問に対して、AIがヘルプ記事とコードベースを横断的に調査してくれます。
ユビキタス言語辞書があるおかげで、「トークルーム」という言葉から talkrooms テーブルに辿り着き、関連するビジネスロジックまで把握できるようになりました。以前は調査に30分〜1時間かかることもありましたが、一次回答であれば数分でAIが回答してくれるという状態を作れました。
ハンズオン会の開催
次にPdM向けのハンズオン会を開催しました。各自が抱えている企画テーマを持ち寄り、AIと一緒に課題整理や仮説立案を行いました。「企画概要を整理するのに有用そう」「考慮の抜け漏れが減りそう」といった声がある一方、「すでにある機能も提案してくる」「SQLの精度をもっと高めたい」といった改善点も見つかりました。
想定外の活用も生まれた
BigQuery連携は「企画書を作るため」に構築しましたが、実際にはマーケ、PdM、デザイナーがサービス内のデータ分析にも活用するようになりました。ある日、デザイナーから「サービス名の平均文字数と分散を知りたい」という質問が来ました。デザイン上、改行を考慮すべきか判断するためだそうです。AIに聞いてみると、数秒でデータが返ってきました。平均25文字、標準偏差は22文字。PdM向けに作った基盤が、デザイナーの意思決定も支援している。基盤を整えておくと、当初想定していなかった使い方が自然と生まれてきます。
最初から完璧を目指したわけではありません。使いながらフィードバックをもらい、少しずつ拡充してきました。この「まず動くものを作って、改善していく」アプローチが功を奏しました。
まとめ
企画側も開発同様にAIを活用すれば、プロダクト開発全体のスピードを一段上げられます。ただし、企画向けのAI活用には、開発とは異なるコンテキストが必要でした。コードではなく、事業ドメイン（業務フロー、KPI構造、ユビキタス言語）をAIに教えること。事業ドメインを知ったAIは、企画の壁打ち相手として効力を発揮し、事業に沿った企画が出力されるようになりました。
これから取り組む方へ
同じような取り組みを検討されている方に向けて、ポイントをまとめます。
- 上流から設計する：いきなり用語集を作るのではなく、「どんな成果物が必要か」から逆算する
- 開発向けと企画向けでコンテキストを分ける：コードベースとは別に、事業ドメインの情報を整備する
- データソースと繋ぐ：実際の数字を見ながら企画できる環境を作る
- 小さく始めて育てる：最初から完璧を目指さず、使いながら拡充していく
取り組みを始めて数ヶ月ですが、企画業務の質とスピードは上がってきています。AIをPdMの「相棒」にするというコンセプトは、少しずつ形になってきました。エンジニアとして、開発だけでなく企画も含めて全体を速くしたい、その思いで始めたプロジェクトです。今後も改善を重ねながら、プロダクト開発全体のスピードアップに貢献していきます。
最後に
明日はNoriaki Utsunomiya（nu2）さんによる「AI時代こそソフトウェアエンジニアは英語を学ぶべき2つの理由」です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion