こんにちは！アンドパッドのデータ部で機械学習エンジニアを担当している谷澤です！最近は機械学習パイプラインの開発やプロダクトへの機械学習導入の概念実証（PoC）に携わっています。今回は2023年のユーキャン新語・流行語トップテンにもなった生成AIに関するアンドパッドの取り組みについてお届けしたいと思います。

なお、本プロジェクトで開発した機能はまだ世の中に出ていないため、公開しても差し支えない内容のみの記載となることをご了承ください。

アンドパッドは生成AIに取り組んでいます

CEO稲田のSlackチャンネルでの一コマ

2023年の1Qに起きた出来事を紹介します。CEOの稲田がSlackで生成AIのプロダクト応用ケースを募集し、多くの人がアイディアを出しわいわい議論していました。このやりとりの後、あるプロダクトを対象とした生成AI活用プロジェクトが実際に立ち上がりました。今回はそのプロジェクトについてのお話となります。

立ち上がった生成AI活用プロジェクト

どんなタスクに取り組んだか

ある業務について入力されたテキスト情報をChatGPTを使って要約する機能を開発しました。

要約には一定水準の「専門用語への理解」「網羅性」「正確性」が求められ、現状の業務では現場のリーダーが毎日このタスクを担当しています。大きな課題として「①要約の質が担当者に依存してしまう」「②要約の入力に時間がかかる」という2事項が挙げられていました。そこで、生成AIに要約作成を支援してもらうことで「①要約の質が一定になる」「②入力が不要になる」という仮説を立て、仮説が成り立つかを検証するために、生成AIを使ったテキスト要約タスクに取り組むことにしました。

どんな人が参加したか

プロダクトマネージャーを意思決定者とし、プロダクトに関する知見を提供するプロダクトチーム、業務に関する知見を提供する業界経験者チーム、生成AIに関する知見を提供する機械学習チームの3種類のチームでプロジェクト体制が組まれました。私は右下の機械学習チームとして参加し、プロダクトマネージャーの意思決定をサポートするために様々な検証を行いました。

どんな進め方をしたか

2023年7月にプロジェクトがスタートしました。期間内に仕様策定、データ準備、開発、社内評価、顧客評価といった工程を実施しました。これまで経験してきた機械学習プロジェクトとは異なり、AIモデル部分の開発にほぼ工数がかからずデータ準備と評価に多くの時間が必要だった事が印象に残っています。

スケジュールのイメージ

どんな結果が得られたか

ある程度の質の要約は作成出来たものの、現場の方が満足する質には到達できませんでした。具体的には、今回のタスクに求められている「専門用語への理解」「網羅性」「正確性」の水準をアンドパッドが今所持しているデータだけでは満たすことができませんでした。今回の取り組みは一旦推進をストップし、検証を進める中で新たに需要が見えてきた別のタスクにアプローチする方針となりました。残念な結果となりましたが、プロジェクトの進め方に関する知見や技術系の知見が得られており、今後の生成AIの活用に向けて資産を残せたプロジェクトだったのではないかと考えています。

なお、これらの成果は機械学習チーム単体では到底実現できなかったものです。この場をお借りしてプロジェクトにご協力いただいた方に深く感謝申し上げます。

プロジェクト推進時のポイント

ここからはプロジェクトの進め方を振り返った際に、ここは良かった、ここはもっと改善できたと感じた事項についてお伝えします。

1. 生成AIを用いるべきタスクかを見極めてからスタートする

生成AIは「ハルシネーション」や「同じ入力をしても出力が都度変わる」などの特徴を持っており、この特徴が解きたいタスクで許容されるかが重要なポイントになります。例えば、100%の精度が求められるタスクには生成AIを用いないほうが良いでしょう。

今回取り組んだタスクは、「多様な視点からの意見が求められる」「正解が1つではない」「AIの出力結果に人間のチェックを入れることができる」という性質があり、生成AIがフィットしていると判断されプロジェクトがスタートしました。

余談ですが、アンドパッドにはAI検討会というAI機能のアイディアについて議論する会議が存在しており、タスクの性質の見極めもこの会議の中で行われています。本プロジェクトもAI検討会から発生しました。有望だと判断されたタスクのみプロジェクト化される仕組みになっており、プロジェクトが途中で頓挫するケースを減らすことができる有益な取り組みだと個人的に感じています。

2. プロジェクトの遅延を防ぐために開発スコープを絞る

今回のタスクは入出力がテキストであり、様々な情報を自由度高く記述することが可能でした。また、有識者チームの方から打ち合わせ中に業務知見に基づく意見を貰うことが可能でした。上記のことから、入力フォーマットや入力する業務情報（いわゆるプロンプトエンジニアリング）について改善アイディアが出続け、検証項目が増加しスケジュールが遅延するリスクが予見されました。

上記リスクへの対策として、開発サイクルを細かく切り、サイクル内の開発スコープを絞る方針を採用しました。例えば、最初のサイクルでは入力フォーマットのみ変更、次のサイクルでは入力する内容のみ変更といったイメージです。

その結果、ミーティング中の議論の発散や検証項目の増大を抑えることができ、当初のスケジュールどおりに検証を終えることが出来ました。

3. 現実に即した評価を行うために業務知見がある人をプロジェクトに巻き込む

今回のタスクの出力結果はある業務で使われることを想定しており、AIモデルの出力の良し悪しの見極めには該当業務に関する知見が必要でした。

幸いアンドパッドには業界経験者が多く、前職で該当業務を担当したことのある方複数名に有識者チームとしてプロジェクトに参加いただくことが出来ました。

その結果、現実に近い形で出力の良し悪しを判断することが出来ました。

余談として、試験的に機械学習チームのメンバーが良し悪しの見極めに挑戦してみたこともあったのですが、有識者の方の判断とはかなり異なるボロボロの結果となりました😅この経験から、業務知見がある方をプロジェクトに巻き込むことの重要性を改めて認識しました。

4. 評価に必要な工数、アサイン可能な工数を正確に把握した上で評価フェーズのスケジュールを立てる

今回のプロジェクトでは評価フェーズで有識者にAIの出力した要約の良し悪しを判断してもらいました。当初はタスクの難易度を把握しきれておらず、要約された結果の文字数や自身が作業した結果を元に1件の評価を1分でこなせると考え、実際に必要な時間よりも過小な時間見積もりでスケジュールを立ててしまいました。（有識者の方からは、要約に重要な情報が全て含まれているかが重要であり、網羅性のチェックに最低でも数分はかかるとのフィードバックを頂きました。）また、有識者の方は他の業務も担当しており、本プロジェクトに費やせる時間は限られていました。

その結果、当初想定していた評価期間では作業が終わらず、評価スコープを削ることになりました。

次回以降は、数件の評価作業を事前に実施してもらい必要な時間を正確に把握した上で、現実的なスケジュールを組むように心がけたいと思います。