AIが「問題を解く」時代に、PdMが解くべき問いとは何か──LayerX・渡辺氏が示した、AIエージェント開発に求められる本質
こんにちは、株式会社ラクスでプロダクト部の部長をしている稲垣です。
この記事は、pmconfの動画や資料をもとに、学びのポイント・自分の環境との共通点や違い・どう活かせるかを自分なりに整理するシリーズの第三弾です。
はじめに
第三弾は、
「AIエージェント開発に求められるPdMの仕事を考える」
登壇者：
・渡辺 謙太さん （株式会社LayerX バクラク事業部 CEO室 プロダクトマネージャー）
発表タイトルを見た瞬間は「また“AI時代のPdM論”か」と思いました。この種のテーマはpmconf界隈でも増えていて、「AIでPdMの仕事が変わる」という主張自体は、もう珍しくありません。
でも実際に見始めると、すぐに印象が変わりました。この発表は「AIを使いましょう」という話ではなく、「AIエージェントを本番環境で動かすことで見えてきた、PdMとして本当に向き合うべき課題」を、かなり具体的な失敗例も交えながら語るものでした。抽象論ではなく、自分の手を動かしてきた人が語る言葉の重みがありました。
この発表の背景として語られていたのは、LLMの急速な進化によって、PdM自身の働き方も、プロダクトの競争優位のつくり方も大きく変わりつつあるという認識です。
一方で、AIやエージェントに関する情報は玉石混交で、「何をどう業務やプロダクトに落とし込めばいいかわからない」と迷っているPdMが多い、という現場感も共有されていました。発表の核は、次の3つです。
LLMの挙動を経験的に理解する
LLMの前に人を理解する
LLMに問題を解かせない
この3点は一見バラバラに見えますが、根底にある問いは同じです。
「PdMとして、AIエージェント開発に何を持ち込めるか」。
その答えを、発表者自身の実践から導き出したのがこのセッションでした。
「デモは動く。でも本番は違う」
──LLMを経験的に理解するとはどういうことか
従来のPdMは、「コードで何が難しく、何が簡単か」についての感覚を持っていました。たとえば、ループ処理が多いと重くなる、外部APIの呼び出しが増えると遅延が出る、DBのテーブル設計を変えると影響範囲が広い、といった技術的な難易度の肌感覚です。そうした感覚が、PdMのスコープ設計や仕様判断の裏側にあったはずです。でも、LLMが前提になると、この感覚がリセットされます。
LLMを使えば、デモはあっという間に作れます。カレンダー連携もメール処理も、数行のプロンプトで動き始める。デモ映えするから「いけそうだ」と思いやすい。これが罠です。
発表で取り上げられていた予定調整エージェントの例は、この難しさを鮮明に示していました。
「来週、Aさんと1時間調整して」という、一見シンプルな入力に見えるリクエスト。でもこれだけで、
来週とはいつを指すのか
Aさんが複数いたらどうするか
既存予定と競合したら優先度をどう判断するか
相手の空き時間の確認はどう行うか
確定前にユーザー確認を挟むのか
といった、入力の曖昧さや文脈依存によって、エージェントは簡単に破綻します。技術的な難易度は、コードの複雑さではなく、暗黙の前提の多さに移行した。これがLLM時代の開発の難しさの本質だと感じました。
ここで必要なのは、「このモデルは、自分たちが解きたい問題に対して、どの精度・レイテンシー・コストで成立するのか」を、自分の手で確かめ続けることです。一般的なベンチマークやリリースノートを読んで「このモデルは賢い」と判断するのではなく、具体的なユースケースで何が通用して、何が破綻するのかを、経験的に積み上げていく。
エンジニアなら、「これはLLMに任せるより正規表現で書いたほうが堅い」といった判断を肌感覚でできます。PdMにも、それに相当する経験値が必要になってきている。この感覚なしにAIエージェント開発のPdMは務まらない、というメッセージは、自分ごととして受け取りました。
また、ここはPdM自身のAI活用とも地続きだと思っています。要件整理、仮説出し、顧客ヒアリングの論点整理など、PdMの仕事にもAIを使える場面は増えています。だからこそ、AIを便利な道具として触るだけでなく、どの仕事は任せやすく、どの仕事はまだ人が責任を持つべきかを自分で見極める感覚が、プロダクト開発においても重要になっていくはずです。
最も刺さったのは「LLMの前に人を理解する」という視点
発表の中で最も印象に残ったのは、「LLMを理解する前に、まず人の仕事を理解する必要がある」という話です。
これは言葉にすると当たり前に聞こえますが、実践においては案外できていないことだと感じます。AIエージェントは、人がやっていた一連の作業を自律的に担える可能性を持ちます。だからこそ、開発する前に「人は実際にどうやってその仕事をしているのか」を徹底的に観察しなければならない。
でもここが、多くのAIエージェント開発プロジェクトで最初に省略されるステップでもあります。人の仕事は、表面的には単純に見えても、その裏に大量の暗黙知があります。
発表では「1on1のリスケ」を例に、その暗黙知が丁寧に分解されていました。
相手との関係性。上司か同僚かで連絡の仕方が変わる。
時間帯の好み。この人は朝早い打ち合わせを嫌がる。
会議室確保の必要性。リモートなら不要かもしれない。
他の予定との優先順位。この会議はずらせないから別の枠を探す。
通知すべきタイミング。変更を即連絡すべきか、翌日でよいか。
単純に見えるこの作業に、明示されていない判断基準が山ほど存在します。
LLMは「空気を読む」ように見えても、与えられていない文脈は読めません。
人間は暗黙のうちに持っているこれらの判断基準を、LLMには明示的なコンテキストとして渡す必要がある。そのコンテキストを設計できるのは、ユーザーの仕事を深く観察して暗黙知を言語化したPdMです。
この発想は、ラクスのプロダクト部で日頃から大切にしていることと重なります。
「顧客の要望をそのまま仕様に落とさない」
「一次情報に直接触れる」
「リリースして終わりにしない」
これらの背景にあるのは、顧客の暗黙知を解像度高く理解することの重要性です。AIエージェントの設計でも、ここは変わらない。むしろ、より重要になると感じます。
顧客業務の暗黙知を理解することは、単に要件定義の精度を上げるだけではありません。結果としてそれは、顧客にとって“安心して任せられる業務体験”をつくることにつながります。AIが自律的に動く場面が増えるほど、この安心感の設計は、機能そのものと同じくらい重要になるはずです。
暗黙知の言語化が設計の質を左右する。
これはソフトウェア開発全体に言えることですが、AIエージェントの文脈ではその影響がより直接的に、より速く表面化する。そこに、この視点の今日性があると思いました。
逆説的な知恵──「LLMに問題を解かせない」
もう一つ印象的だったのが、「LLMに問題を解かせない」という視点です。
逆説的に聞こえますが、これはAIエージェント開発の現場感が凝縮されている言葉だと感じました。
AIエージェントの話になると、すべてを自然言語で処理したくなります。「LLMが賢くなったのだから、全部任せればいい」という発想は、デモを何度か見ていると自然に湧いてきます。
でも、全部をLLMに任せるほど、不確実性と検証コストは跳ね上がります。
発表では、「外部参加者がいる予定を探す」というタスクを例に取っていました。これをLLMに「外部の人が参加している予定を探して」と自然言語で全部考えさせると、「外部参加者とは何か」「どこで判断するか」が曖昧になり、結果が安定しない。
一方で、「メールアドレスのドメインが社内ドメイン以外のものを含む予定を検索する」という条件をツール呼び出しで実装すれば、はるかに堅く動きます。つまり、決定的に解ける部分はコードやツール呼び出しに寄せ、LLMには「曖昧な入力の解釈」や「柔らかい判断」だけを担わせる。
この、システム全体の中での責務の切り分けが、AIエージェント開発における腕の見せ所だということです。
この発想の地味さが、逆に誠実だと感じました。
「AIネイティブな体験」を目指すことと、「LLMが苦手な部分をコードで補う」ことは矛盾しません。むしろ、この両立ができるかどうかがプロダクトとしての品質を分ける。AIを「魔法の箱」として扱うのではなく、システム全体の一部として適材適所に配置する。この冷静さがあるからこそ、AI機能がデモで終わらず、業務に耐える体験になるのだと思います。
3つの核心が指し示すもの
この発表の3つの核心──
LLMの挙動を経験的に理解する
LLMの前に人を理解する
LLMに問題を解かせない
──は、それぞれ独立した話ではなく、きれいにつながっています。
LLMの挙動を経験的に理解しないと、どこをLLMに任せて、どこをコードで補うかの判断ができない。人の仕事を深く理解しないと、どの暗黙知をコンテキストとして設計すべきかわからない。その両方があってはじめて、「LLMに問題を解かせない」という設計判断が正確にできる。
この3つは、AI時代のPdMに求められる能力の層として重なっているのだと気づきました。そして面白いのは、この3つがどれも「LLMに関する特殊なスキル」ではなく、「PdMとして本来求められてきたスキル」の延長にあることです。
技術的な難易度への感覚、ユーザー業務への深い理解、設計における責務の明確化。これらはAI以前からPdMの核心にあった仕事です。
AIエージェント時代は、それをLLMという新しい素材に対して発揮しなければならない時代になったのだと思います。
この発表を通して、「AIがPdMを不要にする」どころか、「AIはPdMに、より本質的であることを要求する」という感覚が強くなりました。
ラクスへの示唆
私がラクスのプロダクト部として持ち帰った問いは、次のものです。
私たちのPdMは、顧客業務の暗黙知をどこまで言語化できているか。
そして、それをAI設計のインプットとして活かす仕組みが、今のラクスにあるか。
ラクスでAI機能を考えるときに大切なのは、「AI機能をつくった」という事実そのものではなく、顧客業務の暗黙知に正しく向き合ったうえでAIを設計できているかという問いだと、あらためて感じました。
メンバーからは、「一次情報にもっと直接触れたい」「上流から入りたい」「リリース後の効果検証がしたい」という声が出ています。これはAI機能開発においても、そのまま重要です。
機能をつくる前に、顧客がどういう判断をしていて、どこに暗黙知が集中しているかを分解できているか。ここが整ってはじめて、AIは「速いだけ」ではなく、「正しい判断を支援する」ものになります。
ラクスのクラウドサービスは、業務の定型と例外が共存する現場を多く持っています。だからこそ、いきなり万能エージェントを目指すより、特定のジョブに絞った設計から入り、そこで得た判断ログをもとに暗黙知を構造化していくのが現実的だと思います。
たとえば、申請、承認、確認、差し戻しといった一連の流れの中で、「どこはLLMで解釈し、どこはワークフローで縛るか」を明確に切る。この設計を丁寧に積み上げることが、ラクスらしいAI機能の磨き方になるのではないでしょうか。
さらに言うと、ラクスがBtoBの基幹業務に近い領域で価値を出していくなら、「信頼の設計」も外せません。
AI時代は、生成できるものそれ自体はコモディティ化しやすい。だからこそ、顧客が安心して任せられること、挙動が説明できること、壊れたときに戻せることが価値になる。
AIエージェントは、便利である前に、任せても大丈夫でなければならない。
ラクスがこの領域で磨いていくべきなのは、派手な自律性そのものよりも、顧客の業務文脈を深く理解したうえでの、安心して使い続けられる自動化体験なのだと思います。
まとめ
AIエージェント時代に、PdMの仕事はなくなるのか。
この発表が示した答えは、「なくなるどころか、むしろ本質が問われる」でした。
LLMの挙動を経験的に理解する力
人の仕事の暗黙知を言語化する力
どこをAIに任せ、どこを構造化するかを判断する力
これらは、AIが強くなるほど、むしろ希少になるスキルです。AIが「問題を解く」時代に、PdMが解くべき問いは変わらない。
むしろ、より本質的になる。そんな感覚を言語化してくれた発表に、素直に感謝したいと思います。
記事を読んでラクスに興味を持ってくださった方は、以下もぜひご覧ください。
