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

489 Views

September 19, 25

スライド概要

PRODUCT HISTORY CONFERENCE 2025 での登壇資料です
2025.09.18

profile-image

LAPRAS株式会社でSWEをしています

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

AIでユーザを怒らせないために @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典

2.

LAPRAS株式会社 CTO 興梠 敬典(コウロキ タカノリ) @rocky_manobi https://lapras.com/public/rocky_manobi

3.

AIでユーザを怒らせないために @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典

4.

このタイトル自体に怒らせる要素が詰まっている そもそも「怒らせる」という言葉自体に どこか揶揄するようなニュアンスが含まれている ですよね

5.

今日のお話 AI(主にLLM)の出力を利用した真面目な機能を提供するにあたっての、 品質についての考え方や品質担保のためのプラクティスについて共有します。 直近でリリースした機能を題材にしながら、 おもちゃや賑やかし機能のような受け取られ方を避け、 届けたい価値を安定してユーザに届けるための、 プロセス的な工夫、設計的な工夫についてお話ができればと思います。 <例> - LLMがあってもアノテーション、データ収集は未だ重要 開発段階から品質検証のしくみを作っておきたい理由と方法 複数の判定機を組み合わせることでロバスト性を担保 プロンプトと同等、またはそれ以上にLLMに入力するコンテキストが重要

6.

これでいかせてください 怒らせないために AIでユーザをガッカリさせないために LLMアプリケーションの品質向上のための設計とプロセスの工夫 @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典

7.

景 背 題材となるサービス

8.

https://lapras.com

11.

景 背 題材となる機能

12.

自社のサービスで自分をこんなふうに表現するのあh抵抗ありますが CTOなのだからこうあってくれよ、という圧力として受け取ることにしております

15.

本編

16.

何も考えずに作ると...? 職務経歴書 情報 LLM プロンプト LLMのおかげで学習データ集めなくてもできるぜ!! 的な レポート

17.

何も考えずに作ると... こうなりますよね (なりました@プロトタイピング時点) ただの要約?? 書いたことがそのまま 載っているだけやん 良いことばっかり 盛りすぎ 一般論ばかり そもそも気づかない スコアとの関連性は? 言うことが 毎回バラバラ 納得感がない 😇 おもちゃ?

18.

どれくらい頑張る必要があるのか

19.

責任の大きさの話 - 機能の位置付け次第 キャリアや転職関係のサービスを運営しているLAPRASにとって、 「ユーザのキャリアや転職市場での立ち位置についてコメントする」 というのはとてもシリアスな領域 転職市場についての有識者であり、ユーザの理解者でもあるという立ち位置から 自信や気付きなど、価値をえることのできる総評を出力する必要がある ⇒ 責任は”大” 開発者コメント 今回の市場価値スコアのコメント機能のリリースは、これまでリリースした LLM を利用したアプリケーションと比較しても、 一番不安が大きいです。ユーザーの書いた Qiita 記事をレビューするのと、ユーザーの市場価値スコア、もとい、Career ページに 入力されている情報 ー つまりキャリアについてアドバイスするのとでは、 プレッシャーの度合いが全然違います。

20.

責任の所在の話 - LLMの利用方法による ● インタラクティブな会話による LLM の利用 ○ ChatGPT, Cursor, Claude Code などなど ○ ユーザーが会話を通して理想の出力を得ようとする → 得られた出力を採用するか否かはユーザーの自己責任 —------- 厳密にはこのような二元論ではなくこの間のいずれかに位置します----------- ● 一方通行の指示による LLM の利用 ○ LAPRASの「記事 AI レビュー」「キャリア市場価値コメント」などはこちら ○ 人による判断の介入ができない → AIの出力の責任が100%サービス提供側に ※こういった LLM アプリケーションを分類するときに、「Agent か否かではなく、どれくらい Agentic か (エージェントっぽいか) で判断すべき」、つまりグラデーションで判断す べき、という考え方がありますが、その両極端に位置するアプリケーションの両方を扱っている自分たちとしては、これらを区別したいため、このような呼び分けをしています。

21.

この反対の例として MCPを例に出します

22.

求人の検索 職務経歴の更新

23.

こういう求人さがして は い よ 職務経歴なおして! LAPRAS MCP LAPRAS

24.

めちゃめちゃ意識の低いキャリア相談を考えてみる 基本は働きたくなくて、 そんなにチャレンジもしたくないし ハードワークもしたくないんだよね。 それなりに規模あって安定したところで 余暇の時間はギターを弾いたりして過ごしたいんだけど、 それを踏まえて良い求人ある? AI台頭で吹き飛ばないくらいの規模がいいなぁ (殴られそう )

25.

※AIの見解です

26.

※AIの見解です

27.

ぶっちゃけレベルの温度感でのキャリア相談体験を提供する... 敷居を下げるという意味で「あり」とも思いつつですが... 公式としてこの体験はとても提供しづらい

28.

真面目に利用する ユーザもいる (表現における)責任の壁 意識の低い要件 検索条件生成 普通の検索条件 LAPRAS MCP 意識の低い人に 刺さる表現 解釈 見解付与 普通の求人情報 LAPRAS

32.

公式としてこの体験もとても提供しづらい

33.

(表現における)責任の壁 スパルタに やってくれ 検索条件生成 普通の検索条件 LAPRAS MCP スパルタ コメント 解釈 見解付与 普通の求人情報 LAPRAS

34.

MCPの特徴の一つ サービスの出力結果のうち、 “表現”についての責任をユーザに預けることができる 体験をユーザにカスタマイズしてもらえる 責任の所在という要素は AI x プロダクト の提供形態を考える際の一つの要素になりそうです ※「使ったらデータが全部消えた」のような動作的な部分の担保は別の話

35.

もどります!

37.

品質の担保 プロセス的な工夫

38.

品質の担保 - プロセス的な工夫 ○ 品質の言語化 ■ 「良い」の定義を具体的に定める この2つからはじめます ○ 検証基盤の構築 ■ 評価セットの作成: ● 品質を測るための基準データを用意する ■ Assertionの実装: ● (特に)「当たり前品質」は自動チェックされるようにする ■ ツールによる検証負荷軽減 ● promptfoo等のツールを持ちいて 定量的・客観的に評価しやすくする 3.0 = LLM時代でも本質は変わらない

39.

品質の言語化 満たすべき/満たしたい「品質」を言語化できないということは... → 自分たちの実現したい機能の品質保証を LLM に「お任せ」している状態 → LLM の出力を制御できていないことと同義 特にLLMでユーザ向けの文章を出力する際は ● ● ● LLMの作文を受けてユーザーにどう行動してほしいか どういう気持ちになってほしいか どう心が動いてほしいか これらを考慮してなるべく明瞭な指示を心掛けます AIがやったところなので い? かしくな ードお このコ

40.

品質の言語化 満たすべき/満たしたい「品質」を言語化できないということは... → 自分たちの実現したい機能の品質保証を LLM に「お任せ」している状態 → LLM の出力を制御できていないことと同義 特にLLMでユーザ向けの文章を出力する際は ● ● ● LLMの作文を受けてユーザーにどう行動してほしいか どういう気持ちになってほしいか どう心が動いてほしいか これらを考慮してなるべく明瞭な指示を心掛けます AIがやったところなので い? かしくな ードお このコ

41.

品質の言語化 現在のLAPRASではシンプルに 狩野モデル に則って、 当たり前品質、一元的品質、魅力的品質を言語化しています 先々こちらもやっていくべきではあります 出典:及川 卓也「ソフトウェア開発は『狩野モデル』で「品質の本質」を見直せ」日経 BOOKプラス、 2024年9月19日、https://bookplus.nikkei.com/atcl/column/090100409/090100004/ (最終閲覧日: 2025年9月17日)より、各種資料を基に作成

42.

プロジェクト初期の 議事録からの抜粋です 󰢛

43.

検証基盤の構築 最初に 評価の仕組みを作り、 これをベースに改善のサイクルをなるべく高速に回していく LLM登場以前から変わらないベストプラクティスと考えています - 特に人の感じ方に関わる機能 ユーザインタビュー等を通じて体験を向上させていきたい ただでさえLLMの出力は確率的なものである上に、 頻繁にアップデートしながら構築していく必要がある 運用段階でももちろん重要に - 将来的にモデルが利用できなくなることもある CI/CDの整備と同様 → 理想の出力、過去の出力について比較・検証が可能な状態をつくっておく

44.

評価セット 出力を評価するためのデータとして インプットと期待するアウトプットのデータセットを収集します。 <例> - プロジェクト経験の文章 vs 抽出されるべき保有スキル - レポートのコメント vs ハイライトしたい部分 スキル 300+ 種類 27,000件くらい - 職務経歴書(PDFなど) vs 正しい抽出結果 ※評価指標は正解率だったり、ROUGE-Lだったり、課題に応じて選択します ラベリング・アノテーションはいまでも必要 「10例でも良いので、まずはここからはじめよう」 という考え方があります。 実感としても同意するところが大きいと感じています。 入力に対しての理想の出力を定義できる何よりの方法だと考えています。

45.

アサーション : 当たり前品質の担保 ○ 主に当たり前品質については、 アサーションを実装して自動でエラーを検知できるようにしつつ、 本番実行時にもエラーとして落とすようにしています ■ 主にPydantic の validation の仕組みを利用しています ○ 一元的品質以上については、それに違反したからと言って本番でエラー にしたくないため、ユニットテスト的なスクリプトを用意します

46.

ツールによる検証負荷軽減 一元的品質以上の内容は、定性的な評価がどうしても必要になるため、 ツールを利用して負荷軽減を計っています https://www.promptfoo.dev/ ● オープンソースの LLM のテストツール ● 複数のプロンプト x 複数のモデル x 複数のアサーションによるテスト結果を、 CLIやブラウザで一覧で確認することができる モデルやプロンプトごとの出力を記録しつつ、 いい感じに比較できる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.

これでいかせてください 怒らせないために AIでユーザをガッカリさせないために LLMアプリケーションの品質向上のための設計とプロセスの工夫 @PRODUCT HISTORY CONFERENCE 2025 2025.09.18 LAPRAS株式会社CTO 興梠 敬典