※この記事は、2026年2月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
椙浦 弘之 (Hiroyuki Sugiura)
パーソルキャリア株式会社
クライアントプロダクト本部
Webディレクターとして、キャリアをスタート。Eコマース、SNS、メディアの新規開発や運用を経験。2024年よりパーソルキャリアにて「dodaダイレクト」のPdMグループのマネジャーを務める。
椙浦：本日は「LLMを利用した開発、はじめの一歩！」と題しまして、私たちのチームが初めてLLMを使って開発を行い、そこで学んだことを皆さんに共有できればと考えております。
パーソルキャリア株式会社は、人材紹介や求人メディアを展開する人材業界の企業です。サービスとしては「doda」ブランドで多くの展開をしており、中途採用だけでなく、新卒採用や採用支援、個人向けサービスなど、時代の変化とともに多様化する「はたらく」に対するニーズに合わせて拡大を続けています。
私は、2024年5月にパーソルキャリアに入社し、ダイレクトリクルーティングサービスである「dodaダイレクト」のプロダクトマネジメントを担当しております。2025年10月からはゼネラルマネジャーとして部署のマネジメントを行っています。
前提
本題に入る前に、言葉の定義を整理させてください。今日お話しするのは「LLM（大規模言語モデル）」を活用した開発についてです。それがどこに該当するのかご説明します。
AI（人工知能）という広い概念の中に「機械学習」があり、その中に「深層学習（ディープラーニング）」があります。今回扱うLLMは、この「深層学習」と「生成AI」の2つにまたがる領域だと考えています。大量のデータを学習して自律的に特徴を抽出する深層学習の仕組みと、既存のデータから新しい文書を作る生成AIの領域。これらを合わせたLLM、つまり「大量の言語データを学習し、それをもとに自然な文章を作るモデル」を使って取り組んだ内容をお話しします。
今日持ち帰ってもらいたいこと
本日皆さんにお伝えしたい結論は一つです。「LLM開発は従来開発の延長線上ではない」ということです。考え方ややり方を切り替えないと問題を招くことになります。
dodaダイレクトの理解とLLM化ポイント
まず、私が担当している「dodaダイレクト」について説明します。これは業界最大級のスカウト会員を活用したダイレクトリクルーティングサービスで、利用企業の担当者が自ら候補者を検索し、スカウトを送るという能動的な採用サービスです。
企業の利用フローは大きく4つのステップがあります。
- 求人票を作成する
- 求人票をもとに、データベースから転職希望者を検索する
- 良い候補者がいれば、その方に合った文面を作成してメールを送信する
- 応募があれば面接を実施する
先ほどの4つのステップを見てみると、2つ目の「求人票をもとにした検索」に非常に高いハードルがあることが分かりました。検索条件の設計が難しく、担当者間で質に差が出てしまい、それが効率低下の原因になっていたのです。
検索項目は、居住地、年収、勤務状況、スキル、資格など、最大で30項目に及びます。これらを一つずつ設定する必要があり、どの条件を入れるべきかの設計が非常に難しかったのです。
この問題に対し、私たちは「LLMで検索条件の初期案を生成し、条件のヒントを提供することで検索負荷を軽減する」という解決策をとりました。
求人票をアップロードすると、AIが検索条件を自動で作成し、「これで良いですか？」と提案してくれる。これまで30項目を一つずつ手動で設定していた負荷を軽減し、検索スキルの属人化を防ぐことを目的として開発しました。
具体的には、初期候補者検索の自動化と、複雑な検索条件の組み合わせをLLMで可能にしました。
LLM開発と従来の開発との違い
ここからは、この機能を具体化するにあたって、従来開発と何が違ったのかを工程ごとに解説します。
開発の流れ自体は、「課題定義」→「体験設計」→「リスク制御」→「PoC」→「実装・評価設計」という従来のステップと変わりません。しかし、各工程で発生する事象がLLM特有のものになります。
① 課題定義（Why）
まず課題定義の段階で直面したのが、「LLMを使うことが目的化してしまう」という問題です。
実を言うと、私自身が最初にチームに「LLMを使って何か開発しようよ」と話してしまいました。これが間違いの始まりでした。
今では反省していますが、重要なのは「LLMを使うこと」ではなく「解くべき課題」を明確にすることです。
- 人や業務が本当に困っていることは何かを言語化する
- その課題は今のルールや従来のアルゴリズムでは解けないのかを考える
- その上で、LLMに向いているのかを判断する
LLMには向き不向きがあります。特に、結果がブレてはいけない処理や、100%の正確性が必須となる場面ではLLMは向いていません。そうした特性を理解した上で、最初の課題定義の段階で「本当にLLMを用いるべきか」を判断することが重要です。
② 体験設計（What）
課題が定義できたら、次は「何を作るか」という体験設計のフェーズです。ここで陥りやすいのが、「LLMの回答が100%正解であり、ブレがない」という前提で体験を作ってしまうことです。
従来のシステム開発であれば、特定の入力に対して決まった出力が出るため、ブレを考慮する必要はほとんどありません。しかし、LLMを利用する場合、出力には必ず「揺らぎ」が生じます。同じプロンプトを入力しても、毎回同じ回答が返ってくるとは限らないのです。
私たちは、この「100%正解ではない」という前提に立ち、「多少ズレていてもユーザーがリカバリーできるUI」を提供することにしました。具体的には、「変更不可」と「変更可能」の2つのパターンでユーザー調査を行い、どちらの体験が良いかを確認しました。
- パターン1（即時実行型）: 求人票を読み込んだら、すぐに検索結果を表示する。
- パターン2（確認・修正型）: 求人票を読み込んだ後、一度「AIが生成した検索条件」をユーザーに提示し、確認や修正を経てから検索を実行する。
検証の結果、採用されたのは後者のパターン2でした。一見、ステップが少ないパターン1の方が効率的に思えますが、AIの回答に誤りがあった場合、一度前の画面に戻って読み込み直す必要があり、かえってストレスになることが分かりました。
「AIは間違えることもある」という前提で、ユーザーがその場でヒントを修正できるステップを挟む。このリカバリーのしやすさが、LLM開発における体験設計のポイントです。
③ リスク制御（How）
次に、リスクや制御の面です。ここで直面した問題は、プロンプト設計の属人化です。生成AIへの命令文（プロンプト）の書き方が人によって異なると、出力の質もバラバラになってしまいます。
これを防ぐために、私たちはプロンプト設計のマニュアルとガイドラインを作成しました。具体的には以下の2点です。
- ガイドライン: プロンプトを書く前や書き直す前に確認すべき共通のルールや判断軸を明文化したもの。
- チェックリスト: 作成したプロンプトが一定の品質を満たしているか、必要な要素が押さえられているかを確認できるもの。
これにより、チーム全体で一定レベル以上のプロンプトを安定して作成できる土台を整えました。
また、ハルシネーション（もっともらしい嘘）への対策も重要です。私たちは、どのような入力パターンを与えると嘘が混じりやすいかを事前に徹底して検証しました。特定の条件下で発生しやすい「嘘のパターン」を理解しておくことが、次のPoCや実装工程に良い影響を与えると学んだからです。
④ PoC（Validate）
続いてPoC（概念実証）の段階ですが、ここでも「LLM向けに考え方を変える」必要がありました。
通常、PoCといえば「技術的に実現可能か」を確認することが主眼となります。しかしLLMの場合、APIを叩けばすぐに動くため、「作れるかどうか」は一瞬で分かってしまいます。
LLM開発のPoCにおいて本質的に検証すべきなのは、「動くか」ではなく「出力を制御できるか」「安全か」「コストは見合うか」といった観点です。私たちは以下の4つの観点を事前に用意しました。
- 事故耐性・リスク制御: 不適切な出力やリスクを制御できているか。
- ユーザー体験の成立性: 先述のリカバリーも含め、体験として成立しているか。
- 運用成立性: 継続的に運用できる仕組みになっているか。
- 精度・品質: 期待するアウトプットが出ているか。
これらの軸がないと、人によって「これならOK」「これは危ない」という判断がブレてしまいます。事前に判断軸を明確に設定しておくことの重要性を強く実感しました。
⑤ 実装・評価設計（PRD）
最終段階である要求仕様書（PRD）の作成においても、これまでの学びを反映いたしました。
従来のPRDは「結果がブレないこと」を前提に書かれますが、LLMの仕様書では、あえて「許容範囲」や「NG条件」を明文化するという手法を取りました。
「100%この通りに出す」という指定ではなく、「この範囲内であれば許容する」「ただし、これは絶対にやってはいけない」という境界線を仕様として定義します。安全性、体験、運用、そして「出力の曖昧さをどう管理するか」という要素を仕様に盛り込むことで、共通認識を形成しました。
まとめ
今回の挑戦を通じて得た学びを改めてまとめます。
- 課題定義: LLMを使うこと自体を目的にせず、解くべき課題に本当にLLMが適しているかを判断する。
- 体験設計: LLMの「揺らぎ」を前提に、ユーザーが修正・リカバリーできるUIを提供する。
- リスク制御: プロンプト設計の共通土台を作り、ハルシネーションのパターンを事前に把握する。
- PoC: 「動くか」ではなく、リスク制御や運用成立性といった軸でテストを行う。
- PRD: 曖昧性や不確実性を管理するために、許容範囲やNG条件を明文化する。
LLM開発は、従来の開発の延長線上にはありません。今回お話ししたような「切り替え」を意識しないと、思わぬ問題を招くことになります。
パーソルキャリアのエンジニアリング組織における「技術」や「人」、「組織」については技術ブログ「techtekt（テックテクト）」の方でも発信しています。また、私たちの組織に興味をお持ちいただいた方は、採用サイトもあわせてご覧ください。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
ない業務を作るということ〜採用管理システムの提供機能拡大への挑戦〜
https://www.tech-street.jp/entry/2026/04/15/103155
