AIでユーザを怒らせないために

プロダクトヒストリーカンファレンス2025 の登壇資料です
https://lp-prohis.youtrust.jp/

LAPRASにおけるLLMプロダクトの品質周りについての取り組みについてお話させていただきました。

Transcript

1. @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典 AIでユーザを怒らせないために
2. LAPRAS株式会社 CTO 興梠 敬典(コウロキ タカノリ) @rocky_manobi https://lapras.com/public/rocky_manobi
3. @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典 AIでユーザを怒らせないために
4. そもそも「怒らせる」という言葉自体に どこか揶揄するようなニュアンスが含まれている このタイトル自体に怒らせる要素が詰まっている ですよね
5. 今日のお話 AI(主にLLM)の出力を利用した真面目な機能を提供するにあたっての、 品質についての考え方や品質担保のためのプラクティスについて共有します。 直近でリリースした機能を題材にしながら、 おもちゃや賑やかし機能のような受け取られ方を避け、 届けたい価値を安定してユーザに届けるための、 プロセス的な工夫、設計的な工夫についてお話ができればと思います。 - LLMがあってもアノテーション、データ収集は未だ重要 - 開発段階から品質検証のしくみを作っておきたい理由と方法 - 複数の判定機を組み合わせることでロバスト性を担保 - プロンプトと同等、またはそれ以上にLLMに入力するコンテキストが重要 <例>
6. @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典 AIでユーザをガッカリさせないために 怒らせないために これでいかせてください LLMアプリケーションの品質向上のための設計とプロセスの工夫
7. 題材となるサービス 背 景
8. https://lapras.com
11. 題材となる機能 背 景
12. 自社のサービスで自分をこんなふうに表現するのあh抵抗ありますが CTOなのだからこうあってくれよ、という圧力として受け取ることにしております
15. 本編
16. 何も考えずに作ると...? 職務経歴書 情報 プロンプト LLM レポート LLMのおかげで学習データ集めなくてもできるぜ！！ 的な
17. 何も考えずに作ると... こうなりますよね (なりました@プロトタイピング時点) ただの要約？？ 書いたことがそのまま 載っているだけやん 納得感がない 😇 良いことばっかり 盛りすぎ スコアとの関連性は？ そもそも気づかない 言うことが 毎回バラバラ おもちゃ？ 一般論ばかり
18. どれくらい頑張る必要があるのか
19. 責任の大きさの話 - 機能の位置付け次第 今回の市場価値スコアのコメント機能のリリースは、これまでリリースした LLM を利用したアプリケーションと比較しても、 一番不安が大きいです。ユーザーの書いた Qiita 記事をレビューするのと、ユーザーの市場価値スコア、もとい、Career ページに 入力されている情報 ー つまりキャリアについてアドバイスするのとでは、 プレッシャーの度合いが全然違います。 開発者コメント キャリアや転職関係のサービスを運営しているLAPRASにとって、 「ユーザのキャリアや転職市場での立ち位置についてコメントする」 というのはとてもシリアスな領域 転職市場についての有識者であり、ユーザの理解者でもあるという立ち位置から 自信や気付きなど、価値をえることのできる総評を出力する必要がある ⇒ 責任は”大”
20. • インタラクティブな会話による LLM の利用 ◦ ChatGPT, Cursor, Claude Code などなど ◦ ユーザーが会話を通して理想の出力を得ようとする → 得られた出力を採用するか否かはユーザーの自己責任 • 一方通行の指示による LLM の利用 ◦ LAPRASの「記事 AI レビュー」「キャリア市場価値コメント」などはこちら ◦ 人による判断の介入ができない → AIの出力の責任が100%サービス提供側に ※こういった LLM アプリケーションを分類するときに、「Agent か否かではなく、どれくらい Agentic か (エージェントっぽいか) で判断すべき」、つまりグラデーションで判断す べき、という考え方がありますが、その両極端に位置するアプリケーションの両方を扱っている自分たちとしては、これらを区別したいため、このような呼び分けをしています。 —------- 厳密にはこのような二元論ではなくこの間のいずれかに位置します----------- 責任の所在の話 - LLMの利用方法による
21. この反対の例として MCPを例に出します
22. 求人の検索 職務経歴の更新
23. LAPRAS LAPRAS MCP 職務経歴なおして！ こういう求人さがして は い よ
24. めちゃめちゃ意識の低いキャリア相談を考えてみる (殴られそう ) 基本は働きたくなくて、 そんなにチャレンジもしたくないし ハードワークもしたくないんだよね。 それなりに規模あって安定したところで 余暇の時間はギターを弾いたりして過ごしたいんだけど、 それを踏まえて良い求人ある？ AI台頭で吹き飛ばないくらいの規模がいいなぁ
25. ※AIの見解です
26. ※AIの見解です
27. 公式としてこの体験はとても提供しづらい ぶっちゃけレベルの温度感でのキャリア相談体験を提供する ... 敷居を下げるという意味で「あり」とも思いつつですが ...
28. 検索条件生成 解釈 見解付与 LAPRAS 意識の低い要件 意識の低い人に 刺さる表現 LAPRAS MCP 普通の検索条件 普通の求人情報 (表現における)責任の壁 真面目に利用する ユーザもいる
32. 公式としてこの体験もとても提供しづらい
33. 検索条件生成 解釈 見解付与 LAPRAS スパルタに やってくれ スパルタ コメント LAPRAS MCP 普通の検索条件 普通の求人情報 (表現における)責任の壁
34. MCPの特徴の一つ ※「使ったらデータが全部消えた」のような動作的な部分の担保は別の話 サービスの出力結果のうち、 “表現”についての責任をユーザに預けることができる 体験をユーザにカスタマイズしてもらえる 責任の所在という要素は AI x プロダクト の提供形態を考える際の一つの要素になりそうです
35. もどります！
37. 品質の担保 プロセス的な工夫
38. ◦ 品質の言語化 ▪ 「良い」の定義を具体的に定める ◦ 検証基盤の構築 ▪ 評価セットの作成: • 品質を測るための基準データを用意する ▪ Assertionの実装: • (特に)「当たり前品質」は自動チェックされるようにする ▪ ツールによる検証負荷軽減 • promptfoo等のツールを持ちいて 定量的・客観的に評価しやすくする 品質の担保 - プロセス的な工夫 3.0 = LLM時代でも本質は変わらない この2つからはじめます
39. 品質の言語化 満たすべき／満たしたい「品質」を言語化できないということは... → 自分たちの実現したい機能の品質保証を LLM に「お任せ」している状態 → LLM の出力を制御できていないことと同義 このコードおかしくない？ AIがやったところなので 特にLLMでユーザ向けの文章を出力する際は • LLMの作文を受けてユーザーにどう行動してほしいか • どういう気持ちになってほしいか • どう心が動いてほしいか これらを考慮してなるべく明瞭な指示を心掛けます
40. 品質の言語化 満たすべき／満たしたい「品質」を言語化できないということは... → 自分たちの実現したい機能の品質保証を LLM に「お任せ」している状態 → LLM の出力を制御できていないことと同義 このコードおかしくない？ AIがやったところなので 特にLLMでユーザ向けの文章を出力する際は • LLMの作文を受けてユーザーにどう行動してほしいか • どういう気持ちになってほしいか • どう心が動いてほしいか これらを考慮してなるべく明瞭な指示を心掛けます
41. 品質の言語化 現在のLAPRASではシンプルに 狩野モデル に則って、 当たり前品質、一元的品質、魅力的品質を言語化しています 出典：及川 卓也「ソフトウェア開発は『狩野モデル』で「品質の本質」を見直せ」日経 BOOKプラス、2024年9月19日、https://bookplus.nikkei.com/atcl/column/090100409/090100004/ （最終閲覧日： 2025年9月17日）より、各種資料を基に作成 先々こちらもやっていくべきではあります
42. プロジェクト初期の 議事録からの抜粋です 󰢛
43. - 特に人の感じ方に関わる機能 ユーザインタビュー等を通じて体験を向上させていきたい - ただでさえLLMの出力は確率的なものである上に、 頻繁にアップデートしながら構築していく必要がある - 運用段階でももちろん重要に - 将来的にモデルが利用できなくなることもある 検証基盤の構築 最初に 評価の仕組みを作り、 これをベースに改善のサイクルをなるべく高速に回していく LLM登場以前から変わらないベストプラクティスと考えています CI/CDの整備と同様 → 理想の出力、過去の出力について比較・検証が可能な状態をつくっておく
44. 評価セット 出力を評価するためのデータとして インプットと期待するアウトプットのデータセットを収集します。 「10例でも良いので、まずはここからはじめよう」 という考え方があります。 実感としても同意するところが大きいと感じています。 入力に対しての理想の出力を定義できる何よりの方法だと考えています。 ラベリング・アノテーションはいまでも必要 <例> - プロジェクト経験の文章 vs 抽出されるべき保有スキル - レポートのコメント vs ハイライトしたい部分 - 職務経歴書(PDFなど) vs 正しい抽出結果 ※評価指標は正解率だったり、ROUGE-Lだったり、課題に応じて選択します スキル 300+ 種類 27,000件くらい
45. アサーション : 当たり前品質の担保 ◦ 主に当たり前品質については、 アサーションを実装して自動でエラーを検知できるようにしつつ、 本番実行時にもエラーとして落とすようにしています ▪ 主にPydantic の validation の仕組みを利用しています ◦ 一元的品質以上については、それに違反したからと言って本番でエラー にしたくないため、ユニットテスト的なスクリプトを用意します
46. ツールによる検証負荷軽減 • オープンソースの LLM のテストツール • 複数のプロンプト x 複数のモデル x 複数のアサーションによるテスト結果を、 CLIやブラウザで一覧で確認することができる https://www.promptfoo.dev/ モデルやプロンプトごとの出力を記録しつつ、 いい感じに比較できるUIも提供してくれるテストランナー的なもの 一元的品質以上の内容は、定性的な評価がどうしても必要になるため、 ツールを利用して負荷軽減を計っています
48. 「プロンプトのこの指示をちょっと変えた場合に、 各モデルの出力がどう変化するのか見てみたい...」 のような期待に応えてくれます
49. promptfoo の良いところ 情報を外部に送信せずに使える 👍 - オープンソースであり、実行はローカルなので セルフホスティングが可能 - 個人情報だけでなくツールの利用状況等含めて完全プライベートにした い場合は PROMPTFOO_DISABLE_TELEMETRY オプションなども 設定しておくとさらに安心
50. 検証基盤の構築 - LLM 世代においても、機械学習モデルを自分たちで構築していたころと、 やっていることはあまり変わらない - モデルの学習や学習セットを用意する必要はなくなったが 「メトリクス、評価指標、評価セット、評価の仕組みを用意して、改善のサイクルを回す」こと は依然として必須 - モデルの学習がプロンプトの改善に置き換わっただけ LLM登場以前から変わらないベストプラクティス(再) まず 評価の仕組みを作り、 これをベースに改善のサイクルをなるべく高速に回していく
51. 品質の担保 設計的な工夫
52. 基本的にはこうなります 書いたことがそのまま 載っているだけ。 ただの要約？？ 納得感がない 😇 良いことばっかり 盛りすぎ スコアとの関連性は？ そもそも気づかない 言うことが 毎回バラバラ おもちゃ？ 一般論ばかり
53. 何も考えずに作る...ではなく 職務経歴書 情報 プロンプト LLM レポート
54. 職務経歴 市場価値スコア (市場での立ち位置 ) キャリア市場価値レポートの仕組み 詳細スコア (強みの方向性 ) 推定保有スキル 今後やりたいこと 以下(+α) 全てをコンテキストとして入力しています
55. キャリア市場価値レポートの仕組み : 市場価値スコアの算出 LAPRASの求人 LAPRASの求人からスキル要件を収集 様々な職種から300+種類
56. キャリア市場価値レポートの仕組み : 市場価値スコアの算出 LAPRASの求人 職務経歴情報 各スキル要件にマッチするかをAIが判定 （実際は0/1ではなくマッチ率で判定）
57. キャリア市場価値レポートの仕組み : 市場価値スコアの算出 LAPRASの求人 職務経歴情報 全体スコア 詳細スコア 企業からの 注目度
58. LAPRASの求人 職務経歴情報 全体スコア 詳細スコア 企業からの 注目度 • 弱い分類器 x 多数 → 大数の法則で精度・ロバスト性を実現 • 求人で需要があるスキル要件で判定 → 実際の市場価値を反映した評価 • LAPRASユーザーの中での相対評価 → 転職市場の中での相対的な立ち位置の判定 キャリア市場価値レポートの仕組み : 市場価値スコアの算出
59. 職務経歴 市場価値スコア (市場での立ち位置 ) キャリア市場価値レポートの仕組み 詳細スコア (強みの方向性 ) 推定保有スキル 今後やりたいこと 以下(+α) 全てをコンテキストとして入力しています
60. 職務経歴 市場価値スコアスコア (市場での立ち位置 ) キャリア市場価値レポートの仕組み 詳細スコア (強みの方向性 ) 推定保有スキル 今後やりたいこと 以下(+α) 全てをコンテキストとして入力しています プロンプトの工夫でこれを実現することはとても難しい (不可能に近い ) → プロンプトよりもコンテキスト情報で出力の性能が決まる 個人の職務経歴情報に加えて、 求人や市場の情報をインプットとすることによって 「要約しただけ」「適当に当たり障りのないことを言っている」 などの感触をぬぐい、転職市場の有識者としてのコメントが可能に
61. その他「言うことがコロコロ変わらないようにする」ための工夫として 職務経歴に変更があった場合は 変更箇所のみのスキル判定を再実行できるように、 スキル判定の結果をデータソースと一緒に保存する などの工夫もしています 1行変えたらスコアが二倍に!!?にならないように
63. まとめ
64. • 品質の言語化の重要性 ◦ 出力結果を論理的に担保しづらいからこそ 事前に品質を言語化することが重要 • プロトタイプ&フィードバックプロセスの重要性 ◦ LLMで簡単にプロトタイプが作れるからこそ、 早期に検証基盤を作り、素早くたくさん試すことが重要 ◦ 評価セットは現在も変わらず必要(頑張る) • 適切なコンテキストの重要性 ◦ プロンプトよりもコンテキスト情報で出力の性能が決まる (プロンプトも大事です) まとめ(もとい学び)
65. @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典 AIでユーザをガッカリさせないために 怒らせないために これでいかせてください LLMアプリケーションの品質向上のための設計とプロセスの工夫