動画記事 · LangChain
採用プロセス60%短縮 AI エージェントで面接までの時間を劇的に変革
動画の文字起こしと公開情報をもとにAIで要約・構成しています。 正確な発言は元動画と時間位置で確認してください。
まず要点
LinkedIn は LangGraph を活用した AI エージェントで採用プロセスの面接までの時間を 60% 短縮し、動的な意思決定と堅牢なハルシーニング技術の実践例を公開。
採用プロセスを60%短縮!LinkedInがLangChainとLangGraphで実現した「自律型」エージェントの秘密
LinkedIn のエンジニアチームは、中小企業の採用における面接までの時間を平均で60%短縮することに成功しました。彼らの成し遂げたのは、単なるチャットボットの導入ではなく、LLM が意思決定を行う「計画・実行・再計画」のループを持つ動的なアーキテクチャの実装です。
本記事では、LinkedIn のエンジニアがLangChainとLangGraphをどのように活用して複雑な採用プロセスを自動化し、信頼性を確保したのか、その核心となる技術的アプローチと教訓を解説します。
採用は「反復するループ」であり、エージェント課題である
なぜ採用プロセスにAIエージェントが必要なのか。LinkedIn のエンジニアチームが中小企業の採用担当者から聞いた最大の課題は、「時間がかかる」ことです。平均して週9.5時間を候補者の選定や誰にアプローチするかという判断に費やしており、スタートアップのような小規模チームにとっては、面接が行われる前に数日分の業務時間が失われてしまいます。
さらに重要なのは、採用が一度きりのタスクではない点です。「求人票を投稿すれば完璧な候補者が現れる」という単純な話ではありません。応募状況を見ながら「必須条件は実はあればいい程度だった」「逆に別のスキルが必要だ」といった気づきが生まれ、求人内容の修正や再検索を繰り返す必要があります。
採用は計画し、行動し、観察し、適応するループそのものです。これがまさにエージェント課題の形です。
この反復的な調整プロセスこそが、LLM を活用した「計画・実行・適応」のサイクルに最適化されるべき課題であるとLinkedIn は定義しました。
静的なワークフローから、LLM が意思決定する動的モデルへ
初期段階では、システムは「もしこの条件なら、あの処理」という分岐(if-then)をハードコードした静的なワークフローでした。しかし、要件が複雑化し、柔軟性が求められるようになると、このアプローチでは限界に達しました。
そこで導入されたのがLangChainを用いたシーケンシャル実行ですが、これでもまだ動的な意思決定には欠けていました。最終的な突破口となったのはLangGraphの採用です。
LangGraph を用いることで、システムは中央集権型のプランナー(LLM)が主導する「計画・実行・再計画」のループを持つ真のアジェンティックな制御モデルへと進化しました。これにより、複雑で多段階の問題解決が可能になり、システム全体の堅牢性と適応性が劇的に向上しました。
設計の3つの柱
この動的モデルの実装には、以下の3つの重要な設計ポイントがあります。
- 単一のエージェントによる集中型推論
複数の分岐やチェーンに依存するのではなく、一つのLLMが「メインブレイン」としてすべての高レベルな意思決定を担当します。これにより、複雑なプロセス全体の一貫性が保たれ、多段階の問題解決が可能になります。
- 計画・実行・再計画のパターン
LangGraphのコアであるこのパターンにより、状況の変化に応じて柔軟に行動方針を修正できます。
- 継続的な改善と可視化
閉ループフィードバックと観測性(Observability)を確保し、システムを継続的に最適化します。
なぜLangGraphを選んだのか?エコシステムの力
LinkedIn は89ものエージェントフレームワークを調査・評価した結果、LangGraphを採用しました。その理由には、単なる機能面だけでなく、既存のインフラとの親和性が大きく影響しています。
LangChainのエージェントはすでに「ランナブル」「ツール」「コールバック」などの用語を共有しており、LangGraphはその上に構築されたものであり、ゼロから書き直す必要がありませんでした。
また、LangSmithによる深い統合も決め手となりました。トラブルシューティングやデバッグにおいて、LangSmithの追跡機能(Trace)を活用することで、Claude Codeとの連携などにより、実際の運用現場で即座に原因を特定し解決できる環境が整っています。これは単なるツールの選択ではなく、インフラ、メッセージングプラットフォーム、そして開発ツールを含むエコシステム全体が連携しているからこそ実現できた成果です。
確率性を制御する「ハルシーニング」技術の実践
生成AIモデルは本質的に確率的(ランダム性を持つ)ですが、実務で使われるエージェントには決定論的な安定性が求められます。LinkedIn はこれをハルシーニング(Harness Engineering)と呼ばれる手法で解決しました。
コンテキスト管理と出力形式の決定化
ハルシーニングでは、モデルの確率性を制御するために以下の工夫を行っています。
- コンテキストの厳格な管理: 会話全体を通じて共有するグローバルパラメータ(現在の意図、求人ID、候補者リストなど)と、ケースごとに有効になるローカルパラメータ(直近の学習結果など)を明確に分離し、LLM に渡す情報を最適化します。
- 出力形式の決定化: 前処理や後処理のフック(Pre-hooks/Post-format hooks)を活用し、モデルの出力が常に期待される形式になるよう強制しています。これにより、システム全体の予測可能性と安全性を担保しています。
メモリの活用:会話履歴と経験則
LinkedIn のエージェントプラットフォームでは、2種類のメモリ機構が活用されています。
- 会話メモリー: チャット履歴を保存し、メッセージングプラットフォームと深く連携します。
- 経験的メモリー(Experiential Memory): 状態のチェックポイントを保存し、これに基づいてエピソード記憶やセマンティック記憶などの高度な機能を実装しています。
評価と改善:人間による注釈から自動最適化へ
システムの信頼性を確保するためには、徹底的な評価が不可欠です。LinkedIn はLangSmithを活用して、ユーザーとのやり取りの全履歴(最終回答だけでなく、文脈の取得、ツールの呼び出し、意思決定のステップなど)を記録しています。
ただし、プライバシーポリシーの関係で生データをそのまま送信できないため、同様の仕組みを自社内で構築し、以下のプロセスで評価を行っています。
- データ収集: 全インタラクションのトレースを取得。
- 人間による注釈とLLM-as-judge: 人間の専門家とAIがそれぞれ評価を行い、モデルが見落としがちなニュアンスをキャッチします。
- 最適化: 注釈結果に基づき、プロンプトやモデルのパラメータを手動で調整・再チューニングします。
現在は人間主導の改善サイクルですが、将来的にはオンライン最適化技術を活用し、人間の介入を最小限にした継続的な学習ループを実現する計画です。
教訓:制約こそがアーキテクチャを決める
このプロジェクトを通じて得られた重要な教訓は、フレームワークの機能だけでなく、プロダクトの制約が実際のアーキテクチャを決定するという点です。
例えば、ユーザーが「教育要件を外してもよいか?」と提案された際、LangGraphの中断(Interrupt)機能を使って実行を一時停止し、Yes/Noを待つ設計も検討されました。しかし、ユーザーは提案を無視して話題を変えたり、会話自体を終了したりするケースが多く、このアプローチは不向きでした。
そこで採用したのが文脈駆動型の人間-in-the-loopです。
実行を中断するのではなく、グラフの最後で最小限の文脈(「教育要件を外す提案待ち」)を保存し、次のメッセージがその提案に関連するか、無視するか、別の話題に移るかをプランナーに判断させます。
このアプローチにより、ステートレスなスケーラビリティ、完全なリクエスト追跡、そして柔軟な会話が可能になりました。何より重要なのは、チェックポイントのサイズを最小限に抑え、システム全体を管理しやすくしている点です。
まとめ:信頼性の高いエージェントの実装には「ハルシーニング」が鍵
LinkedIn の事例は、生成AIを単なるチャットツールとして使うのではなく、複雑な業務プロセスを自律的に実行・調整する「エージェント」として実装するための具体的なアーキテクチャとベストプラクティスを示しています。特に、確率的なモデルの振る舞いを制御し、実務レベルでの信頼性と一貫性を確保するためのハルシーニング技術は、他業界における自動化プロジェクトにおいても重要な指針となるでしょう。
AIエージェントの実装において重要なのは、最先端のフレームワークを選ぶことだけでなく、自社の業務制約やユーザーの行動パターンに合わせて、柔軟かつ堅牢な制御層(ハルシーニング)を設計することなのです。
Original Source
元動画で発言を確認
プレイヤーは必要になるまで読み込みません。YouTubeのCookieと通信も再生を選ぶまで開始しません。
時間位置から根拠を確認
章や引用を選ぶと、元動画をその位置から再生します。