- はじめに
- Cursorを要件定義に活用 ── 転職ドラフトの PdM 吉田さん
- Claude Codeを使った分析業務 ── アルバイト事業部 PdM 工藤さん
- 思考整理と検証に使う ── アルバイト事業部 デザイナー 大堀さん
- まとめ
はじめに
こんにちは。エンジニア採用広報チーム兼、社内勉強会 Livesense Engineering Talk（通称:LET）運営のオブザーバーもやっている岩田です。
先日、Claude Codeの活用事例を3事業部のエンジニアに語ってもらう勉強会を開催しました。
その回が好評だったこともあり、今度はエンジニア以外の職種 ── PdM・デザイナーにも声をかけて、続きを開催しました。 この記事は、2026年4月24日に開催したLET4月回「PdM・デザイナーの生成AI活用術」のレポートです。
お話してもらったのは3名。転職ドラフト事業部のPdMである吉田さん、アルバイト事業部のPdMである工藤さん、アルバイト事業部のデザイナーである大堀さんです。エンジニアが使うイメージの強いCursorやClaude Codeを、それぞれの職種でどう使っているか、興味がありました。
Cursorを要件定義に活用 ── 転職ドラフトの PdM 吉田さん
転職ドラフト事業部のPdMである吉田さんは、Cursorで要件定義の様々な部分を自動化しています。
ブレストから起票まで、地味に時間を食っていた
PdMの仕事は、アイデア出しをして、仕様を整理して、エンジニアに渡せる形にするまでが一仕事です。ブレストの議事録を整理して、コードの既存仕様を調べて、仕様書を書いて、Jiraに起票して……と、実装の前後に地味な作業が積み重なります。
「自分では限界があると感じていたところに、Cursorがやってきた」という出発点で、現在はブレストの整理から起票まで、幅広くCursorを活用しています。
やっていること
まずブレストの議事録をCursorに読み込ませます。MiroのキャプチャとGeminiで取った全体の議事録テキストを渡すと、マークダウン形式でまとめてくれます。「自分でメモを見て整理するよりも、正確にまとめてくれる」とのことでした。
次にCursorにGitHubリポジトリを設定することで、既存のコードから仕様を調査できるようになっています。「転職ドラフトにおいてこのカードという機能はどんな役割か」といった質問を投げると、コードを読んで説明してくれます。仕様を調べるために過去のConfluenceを掘り返す手間が省けます。
さらに、HTMLソースをチャットに貼り付けて希望するパーツのコードを生成させたり、FigmaのMCPを使ってデザインシステムを読み込ませたりすることで、デザイン適用前のUI改善モックを作成しました。 また、Atlassian MCPを使って、仕様書とJiraチケットを自動起票しています。チームで使っているConfluenceテンプレートとJiraテンプレートをCursorに読み込ませておき、SKILLも活用して「この変更内容でチケットを起票して」と指示するだけで作ってくれます。リリースノートも同様に文面の案を生成しているそうです。
印象に残った一言
「AIを使うことを目的にしない、ということはすごく意識しています。AIの機能を提供したいじゃなくて、AIを使って何を提供するか、ということをちゃんと意識してやっていきたい」
コスト管理についても話してくれました。Cursorは使った分だけコストがかかるため、チームで予算を決めて運用しています。「絶対使い切って見せます、と約束して予算をもらっています」という言葉に、導入時の泥臭さを感じました。
Claude Codeを使った分析業務 ── アルバイト事業部 PdM 工藤さん
アルバイト事業部のPdMである工藤さんは、Claude Codeを使って分析業務を変えた話をしてくれました。「この発表資料もClaude Code使って作成しました。」という前置きから始まりました。
SQLを書くには、テーブル定義を知らないといけない
PdMとして分析を依頼されることが多い工藤さんにとって、SQLを書くコストが一番の壁でした。SQLはクエリを書ければいいという話ではなく、データやテーブルの定義をちゃんと理解していないと正しいものが書けません。「定義の確認に一番時間がかかる」というのが正直なところだったそうです。
また、チームメンバーに仕様確認をお願いすることへの遠慮もありました。質問する側の言語化の手間、答える側の作業中断——どちらにとっても負担になっています。
なぜClaude Codeか
「データ定義のドキュメントを読んでくれる、最悪ソースコードを読んで定義を確認してSQLを書いてくれる」という点が、他のツール（社内ボット、Gemini）との違いです。
さらに「SQLを生成して、実行して、エラーが出たら自己修正して、完成まで持っていってくれる」という流れが、他のツールにはない強みです。Geminiなどに依頼すると、生成されたSQLをコピーして、実行して、エラーが出たらまた持っていって……というループが生じますが、Claude Codeは自己修正までしてくれるので完結します。
環境はWindows（WSL）で、psqlコマンドでRedshiftに接続してデータを取得、集計加工にはPythonのpandasを使っています。
精度を決めるのは、何を渡すか
発表の中で印象的だったのが、「何を渡すか」への意識でした。
Claude Codeはソースコードを読んでテーブル定義を把握できます。ただ、精度を上げるにはあらかじめ必要なメタデータを整理して渡すことが重要だという話でした。テーブルのカラム定義、過去の類似クエリ、対象データの概要——こういったコンテキストを最初に添付することで、生成されるクエリの質が変わってくるとのことでした。
特に効果的だったのが、過去に書いた類似クエリをコンテキストとして添付する方法です。「こういう形で書いてほしい」という暗黙の前提を共有することで、細かい説明を省けます。
「渡す情報の質が、アウトプットの質に直結する」という感覚は、他のAI活用と共通する話でもあります。コードやDB定義まで直接読めるClaude Codeは、渡せる情報の幅が広い分、その恩恵が出やすいツールなのかもしれません。
問いを立てるのは、人間の仕事
「要件がかっちり決まった集計・比較は得意。逆に、問いが曖昧な分析はまだ苦手です」という言葉が印象的でした。「X月X日にアプリのKPIが一気に跳ねたんですけどなんでですか」と聞いたら、「重大な発見があります」と言って頓珍漢な仮説を出してきた、という笑い話も添えられていました。
問いを立てるのは人間の仕事であり、そこをちゃんとしてからClaude Codeに渡すという分担が、今のところうまく機能しているそうです。
思考整理と検証に使う ── アルバイト事業部 デザイナー 大堀さん
アルバイト事業部のデザイナーである大堀さんは、最初にはっきり宣言しました。
「デザインの実制作にはClaude Codeは使っていません」
では何に使っているかというと、思考整理・実装検証・コミュニケーション、の3つです。
理由は明快です。「ちゃんと指示すれば作ってくれると思うんですが、指示を出すコストが高い。それなら自分で手を動かした方がデザインは早い」。指示内容によっては生成されたものの中に変なキャラクターが出てきたりするので、デザインは自分でやる、ということでした。
ケース1：散逸したリサーチをナレッジにする
チームメンバーがそれぞれ競合他社や他業種のサービスをリサーチしているのですが、「個人個人で知見は持っているけど、どこかにまとまっているわけではない」状態でした。アイデアの議論の根拠にしづらく、せっかくのリサーチが活かされない課題を感じていたそうです。
そこで、参考になりそうな事例の視覚的な情報をClaude Codeに読み込ませ、体験の文脈・信頼性・離脱ポイント・パーソナライズ度・サービスの強みといった軸で分析させ、UXボードとして可視化する取り組みを始めました。
「バラバラだったリサーチ結果を、ナレッジとして使える形に落とし込めた」という成果でした。
ケース2：プロトタイプで「動き」の合意を取る
UIデザインでは、静止画だけでは「動き」の共有が難しいという課題があります。ボタンを押したときのアニメーション、画面遷移後の挙動——これは各自の頭の中で補完するしかなく、リリース後に「イメージと違った」となることが心配でした。とはいえ、動くものを作るにはエンジニアへの依頼が必要で、検証コストが高いという悩みもありました。
そこでClaude Codeに登場してもらいます。特定のUIインタラクションを試作したいとき、SwiftでiOSアプリとして実装するよう依頼し、Xcodeを使って実機にインストールして確認しました。FigmaのMCPでデザインシステムも連携することで、デザインシステムに忠実な形で出力されました。
「エンジニアへの依頼ゼロで、デザイナー単独で実機検証まで完結できた」という体験は、検証スピードとチームの動き方に影響しそうです。
現状と今後
「個人的には思考整理と検証スピードが上がったと感じています。ただ、チーム内にはまだ浸透していない」と話してくれました。これからプロジェクトチームに使い方を広げていく段階だそうです。
まとめ
3名の発表を聞いて気づいたのは、使っているツールは同じでも、何に当てているかが職種ごとに全然違うということでした。
共通していたのは、「調査・整理・確認」という地味な作業をターゲットにしている点です。仕様の調査、テーブル定義の確認、リサーチの整理、仕様書の起票——これらはコードを書く前後に積み重なる、でも価値を生みにくい作業群です。それぞれが自分のボトルネックを見つけて、そこにAIを当てていました。
もう一つ印象的だったのが、「使わない領域を決めている」という姿勢です。吉田さんは機密情報を含むものは渡さないよう使い分けています。工藤さんは曖昧な問いは自分で立てると言っていました。大堀さんはデザインの実制作は自分でやると決めています。ツールを信頼しながらも、どこは自分でやるかをちゃんと持っていて、その線引きがうまく使いこなせている理由のように見えました。
エンジニアと同じツールを使いながら、こんなに違う使われ方をしているとは思っていませんでした。
今後もLETでは、社内での事例を共有する場を設けて、様々な「武器」を配っていければと考えています。
