1. はじめに
こんにちは！今年もアドベントカレンダーの季節がやってきましたね。
私たちはdoda ダイレクトという、パーソルキャリアが提供するダイレクトリクルーティングサービスにてLLM開発を行っているチーム一同です。（記事は代表してデザイナーの近藤が取りまとめて作成しております。）
僕たちのチームは最近、LLMを活用して「検索条件の自動生成機能」をリリースしました。
プレスリリースも出しておりますので、内容はぜひそちらを参照ください。
初めてのLLM機能開発ということもあり、さまざまな点でつまずきが発生しました。
「企画・プロンプト」「法務 / セキュリティ」「デザイン」「実装・テスト」…
従来のWeb開発とは異なる「LLM特有の難しさ」に直面し、手探りながらに解決していきました。
この記事では、僕たちがリリースまでに各工程でどんな問題に直面し、どうやって解決していったのか？のあれこれ話をしていきたいと思います。
2. 企画 & プロンプト編
まずは、開発の肝となる企画とプロンプトエンジニアリング周りの歩みです。
悩み① [企画]：手段と目的のバランスが難しい
開発当初、「LLMを使うこと」自体が目的化してしまいそうになる瞬間がありました。
「まずはAIを使って…」というところに意識が向きがちで、ユーザーのペインに紐づく共通認識を持つことに苦労しました。
【僕らのチームでやったこと】
対応としては、PdMが一人で抱え込むのをやめて企画の最初期段階からPdM・エンジニア・デザイナーの3職種が集まって議論するスタイルに変更しました。
「技術的にこれは厳しそう」
「それなら、こういう体験に変えたほうが価値があるかも」
それぞれの視点で意見を出し合い、WSJF法などで重みづけを行い、「作れるもの」と「作るべきもの」のすり合わせを徹底的に行いました。
悩み② [プロンプト]：コントロールが難しく、過学習気味に
最初はChatGPTやGeminiを使う感覚で、一つのプロンプトに指示を詰め込んで検証を開始しました。
しかし、なぜか精度の低い・安定しない回答が返ってくることが多かったのです。
主な原因は、速度重視で軽量モデル（nanoやmini）を採用しているのに、ハイエンドなモデルに行わせるような処理をさせようとしていたために、キャパオーバーになっているということがわかってきました。
【僕らのチームでやったこと】
対応としては、「一つのプロンプトで全部やる」ことを諦めました。
処理を細かいステップに分割し、シンプルなプロンプトを複数組み合わせる構成に変更しました。
例えばの話ですが、求人原稿から卒業経過年数を推定してもらう時に
- 専門性の高い分野（医学/薬学）の場合、卒業年数を考慮すること
- それを踏まえて、職務内容から経験年数を推定して卒業経過年数を算出すること
みたいな2つの意識してほしいロジックをいっぺんにプロンプトに含むのではなく、Step1/Step2のような形でシステムに渡すようにしました。
これにより、軽量モデルでも十分な精度が出せるようになりました。
悩み③ [プロンプト]：評価のモノサシがない
プロンプトを調整しても、「この出力は本当に“良い”のか？」を判断する基準がなく、改善のサイクルが回りませんでした。評価結果の管理シートもバージョン管理が複雑化し、最新verが分かりにくい状態になりかけました。
【僕らのチームでやったこと】
チーム独自の「評価指標」を策定しました。
具体的には「網羅性・誤情報・正確性・一貫性」の4つの観点で評価軸と合格ライン（閾値）を設定。
さまざまなパターンの求人原稿を用意し、人間が作成した「正解の検索条件」とAIの回答がどれだけ一致するかを点数化しました。「OKライン」を言語化したことで、迷いが減り、プロンプト改善の方向性が定まりました。
一方で、プロンプトのバージョン管理は本施策での反省点であり、結局この施策の中でうまく解決することができませんでした…（力技で管理…）
次の機能開発からはGitでの管理を想定しており、そこで得た知見もまたtechtektなどを通して発信していければと思います。
悩み④ [プロンプト]：出力結果の一貫性が担保できない
プロンプトの改善は進んできたもののなかなか生成のブレに関してはそのままな状態が続いており、評価基準の「一貫性」の部分で、どうしても基準を満たす結果が得られていない時期がありました。
【僕らのチームでやったこと】
そこで、対応としては以下の部分の調整を行いました。
- パラメータ調整: TemperatureとTop-Pという値に着目し、プロンプト入力画面で設定可能な極小値に設定し、ランダム性を極限まで排除する方向で設定し直しました。
- 入力でのカバー: 一貫性が担保できない場合は、プロンプト自体の修正ではなく大元の情報についてのハンドリングを推進しました。
今回でいえばLLMで解釈しやすい求人原稿の形になれば精度は自ずと上がるので、カスタマーサクセスやセールスとの意思疎通をしっかりと行い、本番環境での精度が上がらない場合は求人原稿自体の修正を促すオペレーションを施策のリリースとともに行いました。
3. 法務 / セキュリティ編
LLM開発には、ハルシネーション（嘘）、情報漏洩、著作権侵害など、従来のリスクとは異なる懸念が上がってきます。そちらについても紹介していければと思います。
悩み①：相談の仕方がわからず、時間がかかる
法務・セキュリティ上の懸念事項の調整には時間を要することが多く、当初、開発チームとしてどう相談を進めるべきか迷いました。
しかし、リリース時期は期初に設定しており、完璧な仕様書を作ってから相談では間に合わないことは明確でした。
【僕らのチームでやったこと】
そこで、「申請して回答を待つ」という受け身の姿勢をやめ、「論点をこちらから提示して壁打ちする」能動的なスタイルでPdMが積極的な立ち回りを行いました。
「これって法務的に大丈夫ですか？」
と丸投げするのではなく、
「こういう企画で、想定されるリスクは○○と××です。それに対しては△△という対策を考えています。リリース時期を守るために、この方針で問題ないか見解をください！」
と、開発チーム側でリスクと対策案をセットにして相談を持ちかけました。
すると、担当者も回答しやすく関係性も築いていけるため、次の施策につながるような相談や回答を得られることが非常に多かったと思います。
結果、法務・セキュリティ部門とも「ワンチーム」のような協力関係を築くことができ、迅速な承認プロセスを実現できました。
4. デザイン編
デザインも複数の箇所で悩みました。
技術的制約に加え、時間/コストのレギュレーションもある中でどのようにユーザーへの体験価値をあげていくか？を悩みました。
悩み①：ターゲットと利用シーンの特定
「AI機能を誰が、どのタイミングで使うべきか？」「そもそも本当に使ってくれるのか？」
ここを明らかにできないと、絵に描いた餅になってしまいます。
【僕らのチームでやったこと】
そこで、ユーザー解像度を高めるために元々プロダクト全体で浸透しているユーザーセグメントに加え、「タイムラインでセグメントを考える」という方法を試してみました。
採用活動は1ヶ月単位でフェーズが変わります。
そのため、「どのフェーズにいるユーザーに、どうアプローチするか」を整理することで、機能を提供する最適な場所とタイミングが明確になりました。
悩み②：待ち時間（レイテンシー）の見せ方
AIの回答生成には数秒かかります。この間、ユーザーに「フリーズした？」という不安を与えない工夫が必要でした。
【僕らのチームでやったこと】
そこで行なった取り組みとしては以下の2点です。
- 競合リサーチ & ユーザーテスト:
他社事例を徹底調査し、ローディング表現や、イラストを複数検討しました。
社内にいるカスタマーサクセスの皆様にもご協力いただきロード体感時間を測るユーザーテストを行い、長いと感じるギリギリの時間と見せ方を考えました。 - ペアデザイン:
Figmaで完璧なモックを作る前に、デザイナーとフロントエンドエンジニアでかなり密な連携を取り、「話しながら作る、要件をブラッシュアップしていく」方法を取りました。それにより修正速度が速く、並行して出てくる急な仕様の変更にも耐えられる進め方となりました。
5. 実装・テスト編
いざエンジニアリング！そこでも要所要所で課題が発生しました…
悩み① [テスト]：応答が不確実で網羅試験ができない
「本物のモデルをつなぐと、毎回微妙に出力が違う……これじゃテストが通らない！」という状況に何度もなっておりました…
外部のテストツールの導入も検討しましたが制約が多く断念し、どうにか対策を講じる必要がありました。
【僕らのチームでやったこと】
そこで、私たちはPythonで「モックシステム」を自作することでテストでの網羅性を高めました。
「この入力が来たら、必ずこう返す」という固定レスポンスを返す仕組みを用意することで、LLMの気まぐれに左右されずにロジックの網羅試験を行えるようにし、テストの再現性を担保しました。
悩み② [運用]：コスト（従量課金）の心配
LLMは使った分だけお金がかかります。
「もし悪意ある攻撃で大量リクエストが来たら……？」
そういった意見がチームからも法務/セキュリティからも上がり、対策を講じる必要がありました。
【僕らのチームでやったこと】
そこでひとまずの対応として、「まずは守りを固めて、走りながら考える」作戦を取りました。
泥臭いですが、日々の利用状況を監視しつつ、あらかじめ設定したコストの閾値（しきい値）を超えたら自動で機能を停止するのような仕組みを運用しています。
これにより、安心してリリースを迎え現在でも安定稼働でリリースした機能が動いています。
6. リリースを迎えて
ここまで読んでいただき、ありがとうございます。
改めて振り返ると、技術的な挑戦と同じくらい、「どうやって進めるか」「どうやって協力するか」に悩み、向き合った5ヶ月でした。
PdM・エンジニア・デザイナーが自分の職種の殻に閉じこもらず全員が企画を考え、全員が品質に責任を持って「越境」し「自分ゴト化」を自然とできていた良いチームだったなぁ、と改めて思います。
リリース後には、カスタマーサクセス経由でお客様から喜びの声をいただくこともあり、今後のLLM施策検討にも大きくモチベーション向上につながっていると思います。
最後に
LLM開発にはまだ正解の地図がなく、荒野を行くようなものかもしれません。
でも、チームで独自のコンパス（評価軸やゴール）を作り全員で知恵を出し合えば、必ず道は拓けると信じています。
もし今LLM開発の進め方で悩んでいる方がいたら、僕たちの失敗や試行錯誤が少しでもヒントになれば嬉しいです。
近藤 鷹冶 Takaya Kondo
プロダクト&マーケティング事業本部 クライアントプロダクト本部 テクノロジー統括部 クライアントプロダクトデザイン部
2021年4月新卒入社。 大学時代では統計学/データサイエンスの分野を中心に学んでいたが、在学中にデザインとの出会いをきっかけにインハウスデザイナーを志す。入社後はdodaでデザイン業務に従事。2022年9月よりdodaダイレクトのデジタルプロダクトデザイナーとしてジョインし、現在はプロダクトの機能改善からからコミュニケーションデザインまで幅広く担当している。
