Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LLMを利用した開発、はじめの一歩!

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

 LLMを利用した開発、はじめの一歩!

本資料は、LLM(大規模言語モデル)を使った開発をこれから始める人向けに、基本的な考え方をできる限りわかりやすくまとめたものです。dodaダイレクトの事例を通して、LLMが得意なこと・苦手なことや、従来の開発との違いを紹介しています。特に、「AIを使うこと」自体を目的にせず、ユーザーが安心して使える体験や、運用・リスクを考えながら進めることの大切さを解説しています。

プロダクトマネージャー勉強会~各社の取り組みや課題から学ぶ会~
イベントページはこちら

パーソルキャリア採用サイト
techtekt(テックテクト)
パーソルキャリアのエンジニアブログです。“みんなの「はたらく」をテックでつくる”をコンセプトに、技術、組織、学びなど、さまざまな情報を発信しています。
NUTION(ニューション)
パーソルキャリアのデザイン組織「NUTION」のブランドサイトです。「デザインの力で、はたらくを変え、社会を変えていく。」をステートメントとし、デザインの価値を広める活動をしています。
TECH Street
パーソルキャリアが主催する各社の現場で活躍しているITエンジニアやテクノロジー人材から、ITテクノロジーに関するさまざまなテーマの事例や知見が学べる勉強会コミュニティです。

More Decks by PERSOL CAREER Dev | techtekt

Other Decks in Technology

Transcript

  1. © PERSOL CAREER CO., LTD. 2 会社概要 社 名 本

    社 創 業 資 本 金 事 業 内 容 従 業 員 数 パーソルキャリア株式会社 東京都港区 1989年6月 1,127百万円 人材紹介サービス、求人メディアの運営、転職・就職支援、 採用・経営支援、副業・兼業・フリーランス支援サービスの提供 7,048名 (有期社員含む グループ会社出向中の者は除く 2025年3月1日時点)
  2. © PERSOL CAREER CO., LTD. 5 椙浦 弘之 Hiroyuki Sugiura

    パーソルキャリア株式会社 プロダクトマネジメント統括部 PdM3部 ゼネラルマネジャー ベンチャー企業でWebディレクターとしてキャリアをスタート し、toC・toB向けのサービスにおいて、ディレクターやプロ ジェクトリーダー、プロジェクトマネージャーとして参画。 2024年5月にパーソルキャリアへ入社し、「dodaダイレクト」 のPdMグループのマネジャーを務める。2025年10月より PdM3部のゼネラルマネジャーに就任し、部署のマネジメント を担当。
  3. © PERSOL CAREER CO., LTD. 6 AIに関する前提と今日取り上げるLLMがどこに属するものか 前提 AI(人工知能) 機械学習(マシンラーニング)

    深層学習(ディープラーニング) 生成AI 知的作業を行うためのプログラムや技術 大量のデータを学習し、人間が調整しなが らルールの改善や分析・予測を行う 大量のデータを学習し、自律的に特徴を抽 出し、ルールの改善や分析・予測を行う 既存のデータから 新しい文章、画像、音楽、動画を作る →LLM(Large Language Model) 大量の言語データを学習し、それを基に自然な 文章を作る
  4. © PERSOL CAREER CO., LTD. 10 業界最大級のスカウト会員を活用した ダイレクト・リクルーティングサービス 01. dodaダイレクトの理解とLLM化ポイント

    ▼ダイレクトサービスの特徴 企業が直接候補者を検索し、スカウトを送る能 動的な採用サービスです。 人材紹介サービスや求人情報サービスと違い、 利用企業の積極的なアクションが必要です。 ▼企業のサービス利用フロー ①求人票を作成する ②求人票をもとに転職希望者を検索する ③転職希望者に合った文面を作成しメール送信 ④応募があれば面接を実施
  5. © PERSOL CAREER CO., LTD. 11 いざ利用し始めようとしたときのハードルの高さがある! 01. dodaダイレクトの理解とLLM化ポイント ▼候補者検索の課題

    検索条件の設計が難しく、担当者間で質に差が出ており、効率低下の原因となっている (居住地/年収/勤務状況/学歴/雇用形態/スキル/資格など、約30項目)
  6. © PERSOL CAREER CO., LTD. 13 具体的にどのような機能をLLM化したのか? 01. dodaダイレクトの理解とLLM化ポイント 検索時入力率が高い項目を、求

    人票からLLMにより自動で設定。 検索項目を理解・設定する初動 の負荷を軽減しました。 初期候補者検索の自動化 求人票の募集要項などから、必要な経験 年数(社会人年数)、通勤可能な居住エ リアなどをLLMが人間に代わって検索条 件を検討します。LLMが支援することで 検索力の属人化を防ぐことができます。 複雑な検索条件の組み合わせ
  7. © PERSOL CAREER CO., LTD. 15 開発フェーズの前までの流れ 02.LLM開発と従来の開発との違い ①課題定義(Why) &LLM適用可否判断

    (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate)
  8. © PERSOL CAREER CO., LTD. 16 02.LLM開発と従来の開発との違い これらは、各工程で発生するLLMならではの事象 これまでの開発にはなかったような悩みやポイントを認知していただくことで、 手戻りや考慮漏れを抑えるために、ここでご紹介します。

    ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate) 本当にLLMを用いる べきかの判断・検討 ができていない プロンプト 設計が属人 化しやすい ハルシネー ションの検 討不足 PoCをLLM向け に変えられてい ない PRDをLLM向け に変えられてい ない 「LLMを使うこと」 が目的化している LLMの回答が100%正 解で、ブレないことを 前提としたUXになっ ている
  9. © PERSOL CAREER CO., LTD. 17 02.LLM開発と従来の開発との違い 課題定義&LLM適用可否判断で発生するLLMならではの事象 対処法 向いている

    向いていない 非構造テキスト処理 厳密な計算 要約・生成 結果のブレない処理 曖昧さを含む判断 100%の正解性が必須 本当にLLMを用いるべきか?判断・検討が出来ていない 「LLMを使うこと」が目的化している LLMを適用すべきかを、特性を理解したうえで判断する LLMの得意・不得意から、LLMを用いるべきかを判断 LLM+ルールベース/従来型アルゴリズムを組み合わせるハイブリッドAIなど も検討する 「LLMを使うこと」ではなく「解くべき課題」を明確にする まず「人や業務が本当に困っていることは何か」を言語化する。そのうえで、その 課題はルールや従来アルゴリズムでは解けないか?LLMに向いているか?LLMを 使った場合のリスク・制約を許容できるかを検討する ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate)
  10. © PERSOL CAREER CO., LTD. 18 02.LLM開発と従来の開発との違い LLMの回答が100%正解、ブレない前提のUXになっている UX /

    体験設計で発生するLLMならではの事象 対処法 「多少ズレてもユーザーがリカバリできる」UIを提供する LLMを利用すると、出力には必ず揺らぎがあります。同じ回答が返っ てくるとは限らないですが、体験としては成立させる必要があります。 このため、私たちは出力情報をユーザーが修正できる体験設計にしま した。 (変更可否の2パターンをユーザー調査にかけたが、リカバリー可能 な体験が好まれる結果が出ました。※LLMの回答精度次第で変わる部 分なので、都度判断必要です) ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate)
  11. © PERSOL CAREER CO., LTD. 20 02.LLM開発と従来の開発との違い プロンプト設計が属人化しやすい これまでなかった工程が追加されます。 リスク制御(プロンプト設計)で発生するLLMならではの事象

    対処法 ハルシネーション対策の事前実施 LLMへの入力パターンを定義して、ハルシネーションが起こるパ ターンを事前にキャッチし、次工程(PoCや人間による体験テス ト)に影響あるようなハルシネーションがあれば対策を実施します。 パターン分類やモデル選定(精度 / コスト / レイテンシ)も組み合 わせて考慮しておくと、手戻りが減らせます。 ハルシネーションの検討不足 ハルシネーションとはもっともらしい嘘を、自然な文章で生成し てしまう現象です。LLMは事実を「検索」しているわけではなく、 「確率的にもっともらしい文」を生成しているだけです。 これが顕著な状態で次工程(PoCやヒトによる体験テスト)を実 施すると、思うような検証結果が得られない可能性があります。 プロンプト設計マニュアルを作成 誰もがプロンプトを作れるように土台を作りました。 私たちは以下のような2つの拠り所を設けました。 ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate) ①ガイドライン(原則) → プロンプトを書く前/書き直す前に読む → どう書くか・何を優先するかの判断軸 → Yes / No で品質を確認 ②チェックリスト(品質確認)
  12. © PERSOL CAREER CO., LTD. 21 02.LLM開発と従来の開発との違い PoCで発生するLLMならではの事象 対処法 LLMのPoCとして検証すべき観点を事前に用意

    PoCをLLM向けに変えられていない 通常のLLMを用いない開発では、PoCは主に技術的実現性 ・性能・既存システム連携の確認、つまり「実装できるか 」を確かめるもの 一方LLMは、APIを叩けば基本的にすぐ動き、デモも容易 に成功するため、LLM開発ではPoCの本質が変わる。 検証すべきは「動くか」ではなく「出力を制御できるか」 「不確実性を扱えるか」「安全に運用できるか」「コスト やリスクに耐えられるか」が重要。 つまりLLMのPoCとは、実装確認ではなく「制御と運用の 成立性」を検証するプロセスです。 ② ユーザー体験の成立性 判断に影響する出力の安全性を知る ・過信されなさすぎない設計 ・信頼されなさすぎない設計 ・誤りへの気付きやすさ ・修正/再生成のしやすさ ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate) ① 事故耐性・リスク制御(最重要) 壊れ方を知る ・ハルシネーション頻度の確認 ・禁止領域への逸脱チェック ・プロンプトインジェクション耐性確認 ・ワーストケース挙動の把握 ④ 精度・品質の評価 事故防止を最優先に評価する ・平均精度だけで判断しない ・主観評価を構造化して確認 ③ 運用成立性(現実に回るか) 続けられる運用かを知る ・コスト構造(トークン消費)の確認 ・業務フローへの組み込み確認 ・人間の確認フロー設計と検証 ・ログの取得と改善サイクルの可否 ・モデル変更に対する耐性確認
  13. © PERSOL CAREER CO., LTD. 22 02.LLM開発と従来の開発との違い PoCで発生するLLMならではの事象 対処法 PRDをLLM向けに変えられていない

    • 従来PRDは「結果がぶれない」ことを前提に記載 • LLMでは「制御できるか」「体験が安全か」「運 用可能か」が重要 • PRDには安全性・体験・運用・可変性の項目を追 加する必要がある 判断基準の明文化 LLM開発PRDでは、許容範囲やNG条件を明文化し、ユーザー体験の基準を共有します ①安全性要件 1.ハルシネーション許容範囲 2.禁止ワード・誤情報制御 3.ワーストケース想定 ③運用要件 1.トークンコスト・レイテンシ上限 2.モデル更新時の回帰テスト 3.人間確認フロー・改善ループ ②体験要件 1.過信防止(信頼されすぎない設計) 2.不安防止(信頼されなさすぎない設計) 3.誤りへの気付きやすさ ④出力可変性・曖昧性の管理 1.許容される出力バリエーション 2.自信度表示や出典表示 3.不確実性のUI表現 ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate) 要求仕様書に追加すべき特有要素
  14. © PERSOL CAREER CO., LTD. 24 03.まとめ 「LLMを使うこと」ではな く「解くべき課題」を明確 に

    LLMに向いているか?LLM を使った場合のリスク・制 約を許容できるかを検討す る 「多少ズレてもユーザーが リカバリできる」UIの提供 出力情報をユーザーが修正 できる体験設計にしました。 プロンプト設計マニュアル を作成 ・ガイドライン ・チェックリストの作成 判断基準の明文化 ①安全性要件 ②運用要件 ③体験要件 ④出力可変性・曖昧性の 管理 LLMのPoCとして検証すべ き観点を事前に用意 ① 事故耐性・リスク制御 ② ユーザー体験の成立性 ③ 運用成立性 ④ 精度・品質の評価 対処法 ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate) ハルシネーション対策の 事前実施 NGワード、差別・攻撃 表現検知などの対策 LLMを適用すべきかを特 性を理解したうえで判断 する LLMの得意・不得意から、 LLMを用いるべきかを判 断
  15. © PERSOL CAREER CO., LTD. 25 今日 持ち帰ってもらいたいこと LLM開発は、従来開発の延長線ではない。 考え方・やり方を切り替えないと、思わぬ問題を招く。

    03.まとめ ①課題定義(Why) &LLM適用可否判断 (Should) ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate)
  16. © PERSOL CAREER CO., LTD. 26 03.まとめ ①課題定義(Why) &LLM適用可否判断 (Should)

    ②UX / 体験設計 (What) ③リスク制御 (How) ④ PoC (Validate) ⑤ 実装・評価設計 ⑥ 運用・改善ループ (Operate) 「LLMを利用した開発、はじめの一歩」が 皆さんにとって良いものになりますように。