こんにちは！ LIFULLのマーケット横断部署でエンジニアリングマネジャーをしている吉永です。
本日は、エンジニアもサービス改善の施策を提案しやすくするために、生成AIへ調査手順や参照する情報、出力形式をまとめた、再利用可能な指示書を作った取り組みについて紹介します。
※本記事では、この指示書を「施策提案スキル」と呼びます。
生成AIを活用してチームの企画力を広げたい方や、AIに施策案を出してもらっても一般論にとどまりがちだと感じている方の参考になれば幸いです。
取り組みを始めた背景
実際にチームへ展開すると、2つのケースで結果に違いが出ました。一つは、私が生成AIに現状分析から施策案の作成までを任せたケースです。もう一つは、長くサービス開発に携わってきたエンジニアが自分のアイデアを生成AIで補強したケースです。
この経験から、生成AIに施策を考えてもらう際に、プロンプトやデータ分析と同じくらい大切だと感じたものがあります。それが、人が持っているドメイン知識です。
※ここでいうドメイン知識とは、サービスの仕様やユーザー理解、過去施策の経緯など、担当業務を通じて蓄積される知識や経験のことです。
私たちのチームでは、サービス改善を企画するメンバーがSEOやCRO（Conversion Rate Optimization、コンバージョン率最適化）など、複数領域の施策を並行して担当していました。
継続的に改善を進める一方で、施策の選択肢を出し続けることには難しさがあります。特に当時は、チーム目標と現状のギャップを埋めるプランを早急に立て、実行へ移す必要がありました。
そこで考えたのが、エンジニアも施策提案に参加しやすい環境を作ることです。
エンジニアは、日々の開発を通じてサービスの仕様、データ構造、技術的な制約、ユーザー体験上の違和感に触れています。ただし、気付きを企画として説明するには、現状の数値、期待効果、過去施策との差分、A/Bテストの設計などをそろえる必要があります。アイデアはあっても、提案書へ落とし込むまでのハードルが高い状態でした。
このハードルを生成AIで下げられないかと考え、過去の不動産情報を提供するアーカイブサイトの課題抽出から改善提案までを支援するスキルを作成しました。
スキルを作成した後は、企画担当者のタスクが多く、施策を十分に検討する時間を確保しにくい一方で、チーム目標とのギャップを埋める必要があるという現状をエンジニアへ共有しました。そのうえで、「こんなスキルを作ってみたので、試しに使ってみませんか。みんなで施策案を出してみましょう」と声をかけました。
完成した仕組みを渡すだけではなく、なぜ今エンジニアからも施策案を出したいのかを伝えたことで、チームの課題を自分ごととしてとらえてもらえたと思います。
施策提案スキルで実現したこと
初版のスキルでは、生成AIに「施策を考えて」と依頼するだけではなく、施策提案に必要な調査と整理を一定の手順で進められるようにしました。
当初扱っていたのは、主に次の情報です。
- 行動データから、ページ閲覧や導線の利用状況を確認する
- ソースコードを読み、現在の仕様や実現可能性を確認する
- 課題、仮説、対象ユーザー、期待効果、リスクを整理する
- A/Bテストの指標と判断基準を含む、施策仕様書のたたき台を作る
初版で特に意識したのは、推測と事実を混ぜないことです。仮説を立てたらデータで確認し、確認できないものは仮説として残すようにしました。また、施策の魅力だけではなく、対象となるユーザーの規模、実装コスト、既存機能への影響まで整理するようにしていました。
これにより、エンジニアは自分の気付きやアイデアを入力し、企画担当者が優先度や実施可否を検討できる内容まで具体化しやすくなりました。
一方、実際に使ってみると、過去の類似施策や足元のチーム目標とのつながりまで十分に確認できないケースがありました。この点は、後述する施策案の比較を通じて見えてきた課題です。
そこで現在のスキルには、次の観点を追加しています。
- 関連する過去施策とA/Bテスト結果を確認し、同じ失敗を繰り返さない
- 足元のチーム目標や中間指標と、施策が動かす指標のつながりを確認する
- 「なぜ行うか」「何を変えるか」「誰に届けるか」を整理し、提案の優先理由を明確にする
スキルも一度作って終わりではなく、実際の提案結果から得た学びを取り込みながら更新しています。
2つの使い方と、その結果
スキルを使って、私とチームのエンジニアがそれぞれ施策案を作りました。興味深かったのは、同じスキルを使っていても、生成AIへの入り口が異なっていたことです。
| 私のアプローチ | チームのエンジニアのアプローチ | |
|---|---|---|
| 出発点 | まず行動データを分析する | 日々感じていた改善アイデアを入力する |
| 生成AIの役割 | 数値から課題を抽出し、施策案を広く作る | アイデアの確からしさをデータや過去事例で検証する |
| 人が主に提供したもの | 分析対象と目標 | 仮説、ユーザー理解、実装経験、過去施策の記憶 |
| 結果 | 複数の案を作ったが、実施候補には選ばれなかった | 2件が実施候補に選ばれ、いずれもA/Bテストでエンジニアが提案したBパターンが既存パターンを上回り、採用された |
私のアプローチ: データから課題と施策を探す
私は、行動分析ツールのデータから現状を把握し、課題を抽出したうえで改善案を作るところまで生成AIに依頼しました。
生成AIは、複数のデータや実装を横断し、短時間で施策候補を並べることには向いていました。施策ごとの期待効果や実装コストも整理できたため、検討材料を増やすという点では役立ちました。
一方で、作成した案は実施には至りませんでした。
実施に至らなかったのは、案そのものが成立していなかったためではありません。中には、過去に類似施策を実施し、A/Bテストで新しいパターンが既存パターンを下回っていた案もありました。また、足元で改善したい指標へ直接つながらず、優先度が下がった案もありました。
データから一見妥当に見える改善余地を見つけるだけでは、今その施策を選ぶ理由として十分ではありません。過去の失敗を踏まえて再挑戦するなら何を変えるのか、現在の目標に対してどの指標を動かすのかまでつながって、初めて実行候補になります。初版のスキルには、その判断に必要な文脈を確認する仕組みが不足していました。この経験が、過去施策の結果と足元の目標指標を確認する現在の形へ更新するきっかけになりました。
チームのエンジニアのアプローチ: アイデアの確からしさをAIで補強する
今回施策を提案したのは、長年アーカイブサイトのフロントエンド開発に携わっているチームメンバーです。
開発を通じて、過去にどのような施策を実施し、何がうまくいかなかったかを知っています。さらに、普段の開発やサービス利用の中で感じていた改善アイデアも持っていました。
今回は、そうした経験から生まれたアイデアを生成AIに入力し、関連する行動データや過去施策を調べてもらうことで、仮説の確からしさを補強しました。つまり、AIにゼロから施策を発明してもらうのではなく、自分の中にある仮説を検証し、企画として説明できる形へ整えるために使ったのです。
その中から2件が実施候補に選ばれました。どちらのA/Bテストでも、エンジニア提案のBパターンが既存パターンを上回り、採用されました。エンジニアのアイデアが提案で終わらず、検証と本実装まで進んだことは大きな成果でした。
結果の違いから見えたドメイン知識の価値
この結果だけで、データ起点のアプローチが悪く、アイデア起点のアプローチが常に正しいとは言えません。試した施策の性質や優先順位も異なるため、単純な比較はできないと思います。
それでも、今回の経験から強く感じたのは、生成AIは入力された情報を増幅する存在だということです。
チームのエンジニアが入力したのは、施策のアイデアだけではありません。その背景には、長年の開発で蓄積した次のような情報がありました。
- ユーザーが画面上で迷いやすい箇所
- 過去に試した施策と、その成否だけでは表せない学び
- データやコードがその形になっている理由
- 実装コストや既存機能への影響に関する感覚
- 日々の開発で感じていた、小さな違和感や改善の余地
これらは、データベースやドキュメントを検索するだけでは、すべてを取得できるとは限りません。人の中にある経験知と、生成AIが集められるデータや実装情報が組み合わさったことで、提案の説得力が増したのだと思います。
生成AIによって、調査や資料化のコストは大きく下げられます。一方で、調べる対象や深掘りする違和感を選び、結果を業務の文脈で解釈するには、引き続きドメイン知識が必要です。
生成AIの急速な高度化に伴い、人間の業務を支援・代替する場面も増えています。私自身、これから人の役割はどう変わっていくのだろうと考えていました。
しかし、今回の2施策では、エンジニア提案のBパターンが既存パターンを上回りました。その結果を見て、ドメイン知識を持つ人の役割はまだまだ大きいと感じました。AIが十分なデータへアクセスできても、最初に渡す問いや仮説の質、その結果を業務の文脈で解釈する力によって、得られる成果は変わります。
人間にしか担えない領域はまだあります。生成AIが発達しても、担当するサービスや業務への理解を深める重要性は変わらないと思います。むしろ、生成AIが知識やアイデアを増幅できるようになったことで、入力となるドメイン知識の価値がさらに高まるのではないかと感じています。
次に取り組みたいこと
今回のスキルには、行動データ、ソースコード、計測仕様、過去の施策資料など、すでに言語化されている情報を参照できるようにしました。
次の課題は、人だけが持っている情報を、生成AIが利用しやすい形に整えることです。
たとえば、次のような情報を継続的に残せると、施策提案の質をさらに高められると考えています。
- 施策を実施した事実だけでなく、当時の仮説と判断理由
- A/Bテストで勝った理由、負けた理由についての振り返り
- 見送った案と、見送った時点の制約
- 開発や問い合わせ対応で感じたユーザー体験上の違和感
- サービス固有の用語、データの定義、実装上の制約
ただし、すべてを無制限にAIへ渡せばよいわけではありません。情報の公開範囲、個人情報や機密情報の取り扱い、古くなった知識の更新方法、AIが参照した根拠を追える状態も合わせて設計する必要があります。
最終的には、職種に関係なく、誰でも気軽に質の高い施策提案ができる状態を目指しています。人のアイデアと経験を起点に、生成AIが調査、検証、具体化を支援する。その積み重ねによって、企画担当者の負荷を分散するだけでなく、チーム全体でサービスを良くする文化につなげていきたいと思います。
最後に
今回の取り組みを通じて、生成AIが得意なことと、人が持つ知識の価値をあらためて考えることができました。
生成AIに施策案を作ってもらう際は、いきなり「改善案を出して」と依頼するのではなく、まずチームが持っている仮説や過去の経験を入力できないか考えてみると、結果が変わるかもしれません。
チームで生成AIを使った施策提案に取り組む方の参考になれば幸いです。最後まで読んでいただきありがとうございました！
最後に、LIFULLではともに挑戦していける仲間を募集しています。ご興味をお持ちいただけましたら、ぜひ以下のページもご覧ください。
