LayerX バクラク事業部でプロダクトマネジメント組織を管掌している飯沼(numashi)です。この記事はLayerX AI Agentブログリレー44日目の記事です。
今回はテックブログに全然テックじゃない話を差し込んでみようと思います。ちょっとくらい閑話休題ということで、LayerXにおいてAI系の機能を連続的に生み出す仕組みづくりや考え方について書きます。
ちなみに、自分自身もプロダクトマネージャーがPRD（Product Requirement Documet、要は仕様書みたいなもの）を作る際の自動化ToolであったりSpec Driven Developmentに興味あったりと色々書きたいことはあったんですが、その辺はおいおい別のブログで書こうと思います。
バクラクはLLM系機能開発が(相対的に)遅かった
ブログをせっかく書くなら、まずは世の中にあんまり出回らない失敗談からいこうかなと思うのでいきなり失敗談から書きます。
LayerXには3つの事業部があり、私はバクラク事業という組織にいるのですが、ここは実はLLM系の機能開発が他の事業部、特にAi Workforce事業部に比べて遅かったです。
理由はいくつかありますが、大きく記載すると以下の2つです。
- 市場構造：
- プロダクト自体が複数個、すべてPMFしている関係で、マーケットからの機能開発ニーズが強い。ある意味、来ている要望を開発するだけで、使い心地にこだわっておけば基本的には事業数値が伸びる構造が強固に存在します。特に、バクラクがメインでプロダクトを作っているBtoBのバックオフィス領域は、競合他社が多く、弊社は最後発の部類に入るため、そもそも当たり前の機能が少ないという壁に当たっており、よりマーケットから要求される必須機能の割合が高いです。結果として、AIやLLM系の機能を開発しなくても良い力学が強く働いていました。
- 組織構造：
- 市場の構造に引っ張られる形で、AI系の機能を開発するにしたって、LLMを扱った機能である必要は必ずしもなく、機械学習の機能で事足りることが多かったです。これを繰り返しているうちに、エンジニアの力量とは無関係に、無意識的にLLM系の機能開発への投資が少なくなる構造にありました。
上記2つの理由から、プロダクトで開発するロードマップは、90%以上が競合に追いつくための機能開発を占めており、他の事業部と比較してAI エージェントへの開発等が遅いという実態がありました。
これは、顧客が要望しているものを叶えるという意味でいうと、非常に真摯な考え方とも取れるのですが、一方で将来の働き方を実現するリーディングカンパニーになる企業の姿勢としては満足のいくものではありませんでした。
AI エージェント機能を開発できる組織にするためにやったこと
AI エージェント系の機能を開発するためには、実態としてはいくつかのハードルを超える必要がありました。市場の要求、組織の構造、どれを取っても開発をしない意思決定に傾きやすい構造にあるからです。
やったこととしては以下の通りです。
- LLMを触った。全然わからなかったので、得体の知れなさを体感しにいきました。
- コード書いたことなかったけどとりあえずやった。私はソフトウェアエンジニアではないですが、ChatGPTとかClaudeを触るとかじゃなくて、フロントエンドもバックエンドもコードを書いてLLMを使った機能を自分で作ってみました。
- トップダウンのアプローチにより、ロードマップを半年間白紙にした
- LLM系の開発への投資は、既存の力学から抜け出せないと確信したためです。様々な職種、ステークホルダーのメンタルモデルが全くついてこれず、触ることによるアドバンテージを享受できる環境にするには、説明責任を果たすのではなくてトップダウンのアプローチが適切と判断しました
- ロードマップを白紙にすることで発生する「PoCを超えられずリソースだけが無駄になる」副作用を抑える構造を社内で作り、開発したら使われるための機構を作った
LLMを用いて機能開発をした
バクラク事業のプロダクトマネジメント組織は、その多くがソフトウェア出身者ではありません。私もそうで、機能開発に関しては素人です。
※直近ではエンジニア出身のプロダクトマネージャーを注力して採用しています、1年くらい前はエンジニア出身者があまり、というかほぼいませんでした。
このため、社内のエンジニアたちがLLMに対して興奮/騒いでいる理由も、本当の意味で理解できていませんでした。ということで、わかんないなら触ろうかなと思って機能を開発してました。
本当に素人のレベルなんですが、コードを触りながら自分が解像度の高い営業関連の社内プロダクトにおいて、以下のことを2ヶ月くらいで触れていきました。2025年のはじめくらいのことです。
- セマンティック検索ってなんだろ、よくわからない
- AI SDK使うとめっちゃ簡単に作れるんだなあ
- え？検索？奥深すぎでは？結局人類は検索の問題に当たるのでは？
- 広めに解かせようとすると全然だめで、どうやって適切に狭い範囲で回答を出させるかを考えながら実装しないといけないのか…
- なんとなく自作してみたら、エンジニアに「これRAGですね」って言われた。これがRAGっていうのか…
- 結局人間ぽい感じで営業をエンハンスさせるなら、小さい解を導き出すものをいくつも作って、それをルーティングする層を作って、大元の指示と周辺の業務知識をかけ合わせて動くものを作ればいいんじゃない？と思って相談したらエンジニアに「それエージェントですね」って言われた。これが巷で話題のAI エージェントか…。人間考えることは一緒だなあ
- 色々細切れにツール作ったりすると途中で止まったり、なんなら挙動の評価ってどうするんだろう、論点はつきないし、QAのあり方も変わる。
最終的人類には取扱が難しいなと思う側面と、人類を前に進めてくれる技術だな、という柔らかい理解をしました。
世の中のトップランナーたちが自分の100周先くらいを走り抜ける中、自分の理解をするために遅めの足取りでちゃんとLLMに触れたとき、受けた衝撃は今でも忘れられません。
ちなみに、最初の衝撃は圧倒的にネガティブな感情でした。
プロダクトの作り方も変わるし、こんなものを使ったら世の中の色々な人が感覚的にはついていけないだろう、バックオフィスの領域と相性悪すぎて機能として出せない着地になるに決まっている、という考えでした。
一方で、数カ月自分で触っていくうちに、様々なアップデート情報を目にするようになります。その速度たるや、すごいもので、速度以上にすごいのは自分がネガティブに思っていた部分を解消しようとする機能がたくさん出回りそうな雰囲気を感じたことです。
この状態を自分は過去目にしたことがありました。
15年ほど前のスマートフォンの登場です。あのとき、一部のiPhoneユーザーは熱狂していたが、多数派はガラケー推しでした。
私はというと、フリック入力の体験に慣れなさすぎて最初タイピング速度が1/10くらいになっていたのを覚えています。その後、色々なアプリケーションを入れられることでエコシステムも開かれ、個人でも法人でも色々なアプリがローンチされ、ユーザーも便利になるという好循環が回っていたことを思い出しました。
たぶん、LLMも今までの物差しで見るのは間違っていて、違うバリュープロポジションを持っている技術だな、と腹決めすることに。
一方で、それを理解してもらえるように振る舞うには時間がかかるとも感じており、強硬手段を取ることとしました。
トップダウンでロードマップを半年間白紙にした
LLMを用いた様々な開発は、自分のようにリソースを注ぐ意思決定をしないと解像度が上がりません、たぶん。
プロダクトロードマップを実現していきながら、それを実行するのはおそらくできなかったため、断腸の思いでプロダクトロードマップを半年間白紙にする意思決定にしました。
これが良い意思決定だったのか、悪い意思決定だったのかは数年後にならないとわかりませんが、今このAI エージェントブログが1ヶ月以上続いているのも、たぶん私の意思決定が2%くらい入っている気がします
開発組織の時間を、AI エージェントの機能開発に関する学習に使うこととする、という意思決定を下しました。
一方で、この意思決定の裏に、一時的に応えられなくなってしまった機能要望などもあるため、とても貴重な時間・猶予であることは組織として強く意識しなければなりませんでした。
AI エージェント系の機能開発をPoCにさせないために
ロードマップを白紙にする、という意思決定を行ったとともに、メッセージングを間違えると、「ただLLMに濃密に触れられる半年間」となりがちです。
触ってみると楽しいし、得体の知れないところも多いので探索的に色々と動くことは非常に重要ですが、一方で「結果が出ない」ということは避けなければなりません。
これが所謂PoCの壁です。
実際、Mckinseyが出したレポートでも、多くの産業においてAI エージェントの利用実態は本格利用に至っていないケースが大半になっています。それくらい、予測できない挙動をする可能性のあるAI エージェントの機能開発は難しさがあります。Human In The Loopをたくさん挟めばそれも抑制できますが、それは今までの開発とほぼ変わらない側面が強いですし、理想的な体験とは言い難いです。
引用元：Mckinsey report state of ai 2025
PoCの壁を超えるコツ2つ
そもそも、PoCが失敗する場合ってなんでしょうか？私は3つくらいの要素があると思っています。
| 失敗の種類 | 内容 | 例 |
|---|---|---|
| 1. ビジネス的な失敗 | ・想定した効果(コスト削減・業務効率化・収益向上)が確認できない, 顧客のニーズや行動が仮説とずれていた | ユーザーがPoCで提供した機能をほとんど使わない |
| 2. プロセス・設計上の失敗 | ・検証目的が曖昧で、成功基準(KPI)が決まっていなかった, ステークホルダー間の認識ずれ, 検証期間・データ・環境が不十分 | PoC終了後に「結局なにが分かったのか」明確でない |
| 3. 技術的な失敗 | ・想定していた精度・速度・スケーラビリティが出なかった, 既存システムとの連携が困難だった, セキュリティや運用要件を満たせなかった | AIモデルの精度が目標値に届かない、APIレスポンスが遅すぎる |
この3つとも、多くの観点を広義のプロダクトマネジメントによって解消または失敗の確率を下げることができると思っています。
このため、バクラク事業部ではPoCの壁を超えるためのコツを2つ組織的に用意しています。
- ローンチできた場合に、ニーズが証明されているであろう、「ユースケースカタログ」を作ってエンジニアに渡すこと
- エンジニアは実装の難易度（失敗時のユーザーのメンタルモデル含む）を元に作りやすい/展開しやすい機能から優先的に取り組んでもらうこと
それぞれ順々に記載します。
ユースケースカタログについて
これは主に、先程記載した①ビジネス的な失敗、②プロセス・設計上の失敗の2つをケアするものです。
ニーズがあるかどうか？はLLMから考えるのではなく、ユーザーニーズから「あったら最高なんだけどな」という機能リストをたくさん作ってしまえば、それで担保ができます。
一例でいうと、以下のような「xxxくん」みたいなユースケースリストを数十カタログ用意しておき、これのユーザーニーズやデータを把握しているPdMをby nameで記載しておくことで、開発に着手する際に想定しているユーザーニーズ、UX、プロセス上どんな機能だと成功になるか？を確認できるようにしています。
所謂、AI エージェントに特化したbacklogを作っているようなイメージです。
エンジニアが作るものを最終的に決められるようにする
残念ながら、自分でもLLMを触っていて思ったのは、やはりエンジニアリングは専門職であるということです。
色々なカタログは用意しても、最終的に作るものを決める・優先順位を決めるのはエンジニアに任せる方が、PoCにおける失敗の③技術的な失敗を防げると考えています。
AI エージェントユースケースカタログを作ったとしても、開発の優先順位は決めません。あくまで、ニーズが証明されているトピックのうち、開発しやすい/技術的な要件も突破しやすいトピックから着手してもらうことで、世の中にインパクトのある機能を、速く、複数個出せることに繋がると思っています。
AI系の機能こそ継続的にリリースできる流れが必要
AI エージェント系の開発は、継続的なデリバリーが大事だと思っていて、放置しておくとどんどんリリースに対するハードルが無意識的に上がり続けます。
精度は？挙動は？もしうまくいかなかった場合にどういう挙動になるか？etc.
当然、これを考えるのはとても大事です。必須と言ってもいいですし、こういう機構がないとユーザーへの便益が減ることになりかねないので大切な考え方です。
が、過度なサービス品質を追い求めてしまう悪い面もあると考えていて、エージェントがうまく動かなかった場合でも通常通り違和感なく業務が行えるもの/UXを想定しやすいトピックから開発し、リリースをすることによって最初から過度なサービス品質を追い求めることによってリリースを阻害してしまう組織文化にしないようにする、というのはとても大切な考え方だと思います。
まとめ
本記事では、AIエージェント機能を継続的に生み出すためのプロダクトマネジメントについて、バクラク事業部での実践例を紹介しました。
AI エージェント開発において直面する主な課題は、市場構造と組織構造の2つです。特に、LLM系機能の開発が遅れる理由として、PoCの壁を超えられないことが大きな要因となっています。
これらの課題に対し、バクラク事業部では以下のアプローチを実践しています：
- トップダウンでのロードマップ刷新：既存のロードマップを白紙にし、AIエージェント開発を最優先事項として位置づける
- ユースケースカタログの作成：ユーザーニーズが証明されている機能リストを事前に用意し、ビジネス的な失敗とプロセス上の失敗を防ぐ
- エンジニア主導の優先順位決定：技術的な実現可能性を考慮し、開発しやすいトピックから着手することで技術的な失敗を回避
- 継続的なデリバリー文化：過度なサービス品質を最初から追求せず、段階的にリリースすることでリリースのハードルを下げる
AI エージェント系の機能開発は、従来の開発とは異なる難しさがありますが、適切なプロダクトマネジメントの仕組みを整えることで、継続的に価値ある機能を世の中に届けることができると考えています。
Discussion