こんにちは、TECH Street編集部です！
この記事では、2026年5月14日（木）に開催した「AI機能実装知見／プロダクト開発エンジニア勉強会」の登壇者の発表内容の紹介と、イベント中に回答しきれなかったQ&Aを記載しています。
登壇者はこちらの方々！
宇賀神拓也
パーソルキャリア株式会社
データ・AIソリューション本部
リードエンジニア
2023年にパーソルキャリアに入社。前職ではAIベンチャーで自社サービスの開発に従事。現在はバックエンド開発を担当。
LLMを「主役」にしないための3つの原則〜求人票自動生成システムの本番開発を通じて学んだこと〜
Q&Aコーナー
（Q）LLMや生成AIは、そもそもサービス提供のための「手段」であって「目的」ではないため、「主役にしない」という原則には非常に共感します。
宇賀神：おっしゃる通りです。まさにその通りであると考えています。
（Q）最近は子育てに関する質問を生成AIに聞くケースもあるようですが、宇賀神さんはプライベートでも活用されていますか？
宇賀神：私自身も日常生活や子育ての中で日常的に生成AIを非常に活用しています。提示される回答に対して納得させられることも多く、実際にアドバイスを参考にして実践しています。
（Q）求人サイト（各社サービス）がMCP（Model Context Protocol）を外部に公開しない大きな理由は何なのでしょうか？
宇賀神：私は求人サイト自体の直接的な運営担当ではないため、組織としての公式な回答はできかねるのですが、個人としての見解でお答えいたします。やはり一番の要因としては、セキュリティ面におけるリスクやガバナンスの担保を慎重に考えているからではないかと推測しています。
（Q）求人サイトでのAI活用により、導入前後で具体的に結果（パーソルキャリア側、利用企業側、転職希望者側）はどのように変わりましたか？
宇賀神：2026年3月にリリースしてからまだ2ヶ月（2026年5月時点）ということもあり、現時点では利用企業様や転職希望者側の定量的な変化までは確認できていません。しかし、弊社（社内業務）側の具体的な変化としては、顧客から求人票の作成依頼を受けてから既存の求人票管理システムに登録を完了するまでのリードタイムが、約0.5日（半日程度）短縮されました。まだメンバーがシステムに慣れていない部分もあるため、今後は習熟度を上げることで、さらなるスピード向上を図れると考えています。
（Q）将来的には、この求人票自動生成機能を（社内だけでなく）顧客である企業側が直接操作して利用できるようにする構想はありますか？
宇賀神：現在は社内向けのシステムとして提供しているため企業様が直接操作することはできませんが、今後の構想（ロードマップ）としては検討されていました。
（Q）LLMは「失敗する前提での設計が必要」という点に納得しました。最近はモデルのアップデートにより精度が向上していますが、それによってシステム側で想定する「失敗の度合い（設計基準）」は変わってきていますか？
宇賀神：本システムにおける「失敗」の基本的な定義は、APIを呼び出した際にHTTPステータスが200以外（エラー）で返却されること、および不適切な回答が出力されることです。
確かに最近のモデルはAPIとしての安定性が非常に高く、ハルシネーションや不適切な出力もほぼ見られなくなっているため、リトライ処理の必要性自体は以前より低くなっている印象はあります。しかし、実際の運用ログを細かく確認すると、タイムアウトや軽微なエラーなどでシステム的なリトライが必要となる場面は依然としてゼロではないため、引き続き失敗を前提とした堅牢な設計は不可欠であると考えています。
（Q）LLMのモデル（GPTなど）を選定する際、どのような基準で判断されていますか？また、HR（人材）システムならではの特有の判断指標などはありますでしょうか？
宇賀神：モデル選定に関しては、弊社としてもまだ様々な検証を行っている実験段階です。今回のシステム開発においては、導入直前にリリースされた最新モデル（GPT-4系など）の性能をタイムリーに評価し、エリア（対象機能）ごとに適したものを採用したという側面が大きいです。
HRシステムならではの明確な選定・判断指標を定義していく必要性は強く認識していますが、現状はまだそこまで手が回っていないため、今後の重要な検討課題として捉えています。
（Q）AIプロダクトに関連するシステムのセキュリティ対策（ガードレールの設定やアーキテクチャなど）はどのように構築されましたか？
宇賀神：入力および出力のセキュリティ担保としては、利用しているクラウドプラットフォーム（Azure等）が提供する標準的な「コンテンツフィルタリング機能」を採用し、不適切な表現やデータのフィルタリングを行っています。
アーキテクチャの面では、完全にクローズドかつプライベートなネットワーク環境内にシステムを構築し、外部と隔離された安全な空間でデータをやり取りする設計にしています。社内システムということもあり、ネットワークの閉域化を徹底することでセキュリティを担保しています。
（Q）品質担保において、何をもって「良い出力」と定義しましたか？また、網羅性や禁止表現率といった自動評価指標などは運用されていますか？
宇賀神：品質担保の自動評価指標に関しては、今回の初期開発フェーズでは十分な仕組みを構築できていないのが実情です。現状の評価運用の仕組みとしては、弊社に既存で存在する「求人票の審査部門」の審査ルールに準拠しているかどうかを基準にしています。AIが生成したプロンプトベースの出力結果が、最終的な社内チェック（バリデーション）を通過して既存システムへ連携できるか否かで品質を担保している状態です。現時点では数値化した自動評価ロジックまでは実装できていないため、今後の優先的な改善点として認識しています。
（Q）今回のシステムでは、どの部分にRAG（検索拡張生成）を適用するのが効果的でしたか？
宇賀神：検討段階ではRAGの導入も考慮しましたが、扱うマスターデータの規模がRAGを組むほど大きくはなかったため、最終的には一般的なRAGの仕組みは採用しませんでした。代替として、特定のコード値（職種・業種）へ変換・マッピングする処理の部分に限定し、自前で実装した軽量なベクトル類似度検索のロジックを適用しています。その他のテキスト生成に関しては、基本的にプロンプトによる指示制御のみで対応しています。
（Q）本番環境における、LLM生成処理の「成功」と「失敗」の具体的な比率はどのくらいでしょうか？
宇賀神：具体的な数値は手元にありませんが、体感値としては約99%が正常に成功しています。過去に一時的にエラーが発生した事例としては、社内でユーザー（リクルーティングアドバイザー）向けのシステム利用研修を一斉に実施した際、同一タイミングで大量の同時アクセスと同時生成リクエストが集中したことで負荷がかかったケースが挙げられますが、通常の業務利用においては極めて安定して稼働しています。
（Q）今後、転職サイトや人材系サービスがAIによってどのように変化していくか、個人としての考察を教えてください。
宇賀神：あくまで個人の見解ですが、転職希望者の中には「自身のスキルや経験のアピール」「自己表現」を文章化することが苦手な方も多くいらっしゃいます。そうした方々がAIのサポートを受けることで、本当に伝えたい強みやキャリアの魅力を、より分かりやすく言語化して企業に届けられるようになるのではないかと思います。転職希望者の可能性を広げる手段として、今後さらに転職サイトでのAI活用がポジティブに進んでいくことを期待しています。
（Q）外部環境の技術トレンドの移り変わりが早いため、場合によっては「またゼロから開発し直した方が早いのではないか」というレベルに直面することもあるかと思います。そのあたりの割り切りや捉え方はいかがでしょうか？
宇賀神：まさにその通りだと強く同意します。開発している最中にも新しい技術やプロトコルが次々と登場するため、ゼロから作り直したいというエンジニアとしての想いは常に浮かんで連動してきます。
一方で、社内事情としてゼロから新規にシステムを立ち上げるとなると、各種申請や手続きなどのプロセスで時間を要し、開発がスタックしてしまうという組織的な課題もあります。こうした技術トレンドの進化スピードと、組織的な意思決定・開発プロセスのバランスをどう最適化していくかは、今後の大きな挑戦です。
（Q）ビジネス側のKPIとして、どのような数値を改善することを目標に開発されましたか？また、実際の改善度合いについても教えてください。
宇賀神：私は開発側の担当であるため、ビジネス側の詳細な資料を一部把握している範囲での回答となりますが、メインのKPIは「顧客から依頼を受けてから求人票がデリバリーされるまでのリードタイムの短縮」に置かれていました。まだ本番稼働から1ヶ月程度しか経過しておらず、業務の特性上、正確な効果測定の手法自体を確立させる難しさも浮き彫りになってきているため数値の算出根拠は引き続き議論が必要ですが、現時点では「約0.5日（半日）のリードタイム短縮」という成果が出ていると聞いています。
（Q）LLMや生成AIの機能を実装・制御するにあたり、何か特定のフレームワークは使用されましたか？
宇賀神：今回の開発では、ほぼ使用していません。AzureやOpenAIが公式に提供しているSDK（標準ライブラリ）のみで実装しています。設計初期にはLangChain等の導入も検討しましたが、今回のシステムの要件やワークフローの複雑さを精査した結果、標準ライブラリだけで十分にコントロール可能でシンプルな構成を維持できると判断し、採用を見送りました。
（Q）AI（LLM）によって自動生成された求人票の最終的な「審査・チェック」は、現時点では人が行っているのでしょうか？
宇賀神：現状の業務運用としては、最終審査はまだ「人（社内の審査部門）」が目視で行っています。ただし、完全に目視に頼るのではなく、現在は「人が行う審査業務を強力に支援・アシストする自動チェックの仕組み」を裏側で開発している最中です。これについても近い将来にまた具体的な知見として皆様に発表できればと考えています。
（Q）今回のプロジェクト開発における体制（AI担当、業務担当、既存システム担当の役割分担など）を教えてください。
宇賀神：開発のコアメンバーとしては7〜8名程度で推進しました。具体的な役割内訳としては、プロジェクトマネージャー（PM）が1名、バックエンド開発が私を含めて2名、フロントエンド開発が1名、インフラ構築（AWS/Azure）が1名です。ここに、AIのプロンプト改善や出力性能の測定・評価を専門に担当する「AI担当メンバー」が1名加わっています。さらに、複雑な既存システム側の仕様変更や連携仕様を調整・担保してくれる「既存求人システム側の担当エンジニア」が1名という体制で、密に役割を分担しながら開発を行いました。
（Q）利用率が上がらなかった時期、開発側と現場側で、どのように改善を行いましたか？
宇賀神：システムが完成した後の利用促進に関しては、開発側で直接コントロールできるアプローチが限られていたため、業務・企画側のチームが主体となって精力的に動いていただきました。具体的には、対象となるリクルーティングアドバイザー向けの丁寧なシステム研修会を繰り返し開催したり、活用を促すリマインドメールをこまめに配信したりするなどの泥臭いコミュニケーションを行っていただきました。
また興味深い傾向として、社内で「この自動生成システムを使うと業務が本当に楽になる」というポジティブな口コミが現場のユーザー間で広がっていったことで、ある時期を境に利用率が右肩上がりに伸びていきました。特に、既存の求人票を流用するのではなく「新規でイチから求人票を作成する業務」が多いチームからは、非常に高い評価を得ることができました。
（Q）LLMモデル選定の観点を知りたいです。「この観点だけは持っておくと良い」というアドバイスがあれば教えてください。
宇賀神：モデル選定に関しては、私自身も正解を模索している最中であり、ぜひ皆様からも知見を伺いたい部分です。一般的な開発目線でのアドバイスとしては、やはり「扱えるコンテキストウィンドウの長さ（トークン上限）」、トークンあたりの「コスト効率」、そして実際に開発者が手動でプロンプトを投げてテストしてみた際の手応え（応答の柔軟性やニュアンスの再現度）といった基本的な要素を、国内外のLLM比較ベンチマークサイト等の客観的なデータと照らし合わせながら、バランス良く評価していくことが重要であると考えています。
（Q）最新技術（MCPやAIエージェントなど）を取り入れることの重要性について、どのように考えていますか？
宇賀神：技術要件として最新トレンドを追うことは刺激的ですが、「新しい技術を取り入れること自体が目的」になってしまうのは避けるべきだと考えており、個人的にはアーキテクチャ設計において比較的保守的なスタンスをとっています。今回の求人システム開発においても、既存システム側の制約やビジネスルールが非常に複雑であったため、新しさにこだわるよりも「いかに堅牢に結合できるか」を重視しました。
ただし、多システム間のデータ連携という課題に対しては、MCP（Model Context Protocol）のようなオープンな共通規格を適用できれば設計がスマートになる可能性もあるため、「システムが抱える既存の課題を綺麗に解決できる手段」として合致するのであれば、最新技術も積極的に評価し、取り入れていくべきだと考えています。
（Q）本番リリース前の品質・性能テストは、どのようなことを実施されましたか？LangSmithなどで重視した評価指標などがあれば教えてください。
宇賀神：今回の開発では、LangSmithなどの高度な外部のLLM専用評価・運用プラットフォームの導入までは至りませんでした。リリース前のテスト手法としては、業務（運用）側のチームと密に連携し、実際の業務で発生しうる求人パターンの「テストシナリオ（データパターン）」を事前に網羅的に作成しました。
そして、プロンプトやロジックの修正を行うたびに、そのテストパターンをひたすら一括で回す「回帰テスト（リグレッションテスト）」を実行し、出力の品質や生成されるテキストの傾向に予期せぬ劣化や変化が起きていないかを機械的に担保する手法をとりました。
本番稼働後に十分な性能が出ないリスクも考慮しつつ、実務に耐えうる最低限のラインをテストパターンで証明しながらリリースへと踏み切ったのが実態であり、評価検証の仕組み化については今後のアップデートにおける改善の余地を多く残しています。
（Q）求人票の項目を一度に生成せず、段階的に分割して生成しているとのことでしたが、なぜ分割が必要だったのでしょうか？その分割単位の決め方も教えてください。
宇賀神：求人票に必要なすべての項目（要件、給与、勤務時間、福利厚生など）を一括のプロンプトでLLMに生成させようとすると、出力の精度が著しく低下したり、指示の文脈が長くなることで「文章の中央付近にある重要な指定をLLMが読み飛ばして忘れてしまう」という問題が発生したため、分割が必須となりました。
分割の単位については、人間の業務知識に基づき「意味のあるまとまり」で大きく6つに分類しています。例えば「給与・年収に関する項目」「勤務時間・休日に関する項目」「勤務地に関する項目」といった単位でざっくりと切り分け、それらをシステム側でステップバイステップのパイプラインとして段階的に実行・生成していく設計にしています。
（Q）社内でLLMを活用した様々な業務改革のテーマ（候補）が検討されたかと思いますが、なぜ今回の「求人票の自動作成」が開発テーマとして選ばれたのでしょうか？選定の観点が知りたいです。
宇賀神：私が選んだわけではないので正確なところは分かりませんが、私自身のこれまでの経験を踏まえると、「生成されたアウトプットのデリバリー先（明確な出口となる業務・システム）が確実に存在していたこと」が選定の決定打だったと考えています。
過去のプロジェクトでは、PoCの検証結果として「良いものができた」と評価されても、それを流し込む先の既存業務フローや受け皿となるシステムが社内で明確になっていなかったために、リリースを見送ってステイ（クローズ）となってしまった苦い経験があります。その点、今回の「求人票の作成および管理システムへの登録」という業務は、パーソルキャリアの人材紹介事業において「100%確実に毎日発生する基幹業務」であったため、投資対効果や出口の明確さという観点から最優先テーマとして選ばれたのだと認識しています。
（Q）今回のプロジェクトの全体の開発期間はどのくらいでしたか？
宇賀神：要件定義や設計を開始した2025年11月頃から、本番リリースを迎えた2026年3月までの、約5ヶ月間です。
（Q）今回の開発において、ソースコードの実装自体もAIベースで行われましたか？その場合のフローや注意点があれば教えてください。
宇賀神：はい、今回のシステム開発では、フロントエンドからバックエンドのロジック構築に至るまで、ほぼすべてのソースコード実装においてAIコーディング支援を活用しました。
AIベースでのコーディングを経験して感じた注意点としては、やはりテストです。「圧倒的なスピードでコードを生成してくれる反面、間違えるときは構造的なバグを含めて非常に大きく間違える」という特性はどうしてもあり、AIが書いたコードの正当性を担保し、エラーを早期に検知するための「ユニットテスト（自動テスト）」による厳密なフォローフローループが極めて重要になります。AIコーディングにおける最適な開発フローやテストの網羅性については、私自身も現在手探りで勉強している最中ですので、ぜひ皆様からも知見を共有していただければ幸いです。
（Q）最後にまとめとして、パーソルキャリアにおけるAI活用の展望は？
宇賀神：パーソルキャリアとしては、中期経営計画などでも対外的に示している通り、全社を挙げて生成AI・LLMテクノロジーのビジネス活用を非常に強力に推進していく方針を掲げています。社内の業務効率化はもちろん、今後はよりコアなプロダクトやサービスへのAI実装を加速させていきます。AIを活用した大規模なプロダクト開発や、最前線でのアーキテクチャ設計・価値検証に興味があるエンジニアの方がいらっしゃいましたら、カジュアル面談等も随時実施しておりますので、ぜひお気軽にお話を聞きに来ていただけますと幸いです。
