2025年5月13日から5月14日にかけてサンフランシスコで開催されたAIエージェント開発のテックイベント「LangChain Interrupt」。Day 2ではLinkedInのDavid Tag氏が登壇し、「From Pilot to Platform: Agents at Scale with LangGraph」と題して、LinkedInにおけるエージェント開発とLangGraphを用いたスケーリング戦略について語りました。特にJavaスタックからエージェント開発のためにPythonスタックへ移行する話は必見です。
2つの「スケール」への挑戦
David Tag氏は講演の冒頭で、エンジニアやプロダクトビルダーが考えるべき「スケール」には2つの側面があると述べました。
- パフォーマンスのスケール: サービスやアプリが大量データを効率的に処理し、高性能化すること。これは多くのエンジニアが馴染み深い概念です。
- 組織的導入のスケール: 組織内でエージェントの利用をいかに広げ、誰もが革新的なアイデアを生み出せるようにするか。こちらはより繊細な側面です。
LinkedInでは、この両方のスケールに取り組んでいると強調しました。
LinkedIn Hiring Assistant: 初のプロダクションエージェント
講演ではまず、LinkedIn初のプロダクションエージェントである「LinkedIn Hiring Assistant」が紹介されました。これは、リクルーターの採用プロセスにおける様々な業務を自動化し、候補者とのより本質的なコミュニケーションに時間を割けるように設計されたエージェントです。
Tag氏はデモ動画を交えながら、Hiring Assistantの動作をステップごとに解説しました。
- 求人内容の入力: リクルーターが募集職種（例：経験豊富なグロースマーケター）や関連ドキュメントを入力します。
- 資格要件の自動生成: エージェントが入力情報とドキュメントを基に、適切な資格要件を自動生成します。
- バックグラウンド処理の通知: エージェントは処理中であることをユーザーに伝え、完了後に通知することを約束します。
- 候補者レビューの通知: 処理が完了すると、レビュー可能な候補者がリストアップされたことを通知します。
- 候補者リストの表示: 通知をクリックすると、エージェントがソースした候補者リストが表示され、詳細を確認できます。
Tag氏は、このエージェントがバックグラウンドで自律的に動作し、ユーザーに結果を返すという点で、イベントで度々言及された「アンビエントエージェント (ambient agent)」のパターンに沿ったものであると説明しました。
アーキテクチャの概要：スーパーバイザーと「スキル」
Hiring Assistantの内部アーキテクチャは、伝統的なスーパーバイザー型マルチエージェントアーキテクチャ (supervisor multi-agent architecture) を採用しています。スーパーバイザーエージェントが複数のサブエージェントを調整し、各サブエージェントはツールコーリング (tool calling) を介してLinkedInの既存サービスやシステムと連携します。
ここでTag氏は、単なるツールコーリングに留まらない「スキル (skills)」という概念を導入している点に触れ、後ほど詳しく説明するとしました。
Pythonへの標準化：GenAI時代の技術選択
LinkedInでは従来、アプリケーション開発の大部分にJavaが用いられていましたが、GenAIの登場を機に、ビジネスロジック、エンジニアリング、評価など、プロダクションアプリケーション構築に必要な全てにPythonを採用するという大胆な決断を下しました。
「2022年後半まで、Pythonは主に社内ツールやビッグデータ処理（PySparkなど）に使われていました。ビジネスロジックの大部分はJavaでした。GenAIの初期にはJavaを継続利用しましたが、すぐに限界が見えました。多くのチームがPythonでの実験を望んでいましたが、既存スタックの制約があったのです。」 (Up until, I would say late 2022 Python was really and I like to call it Python here Python, we use mostly just different internal tooling, different internal productivity tools, but also big data applications, your PySpark offline jobs. But really Java was used to build up fast overwhelming majority of our business logic and so come link, does it 2022 which was really LinkedIn, first foray into generative. AI, we saw that, hey, we're already using Java for non for non generative AI use cases. Let's just use Java for j also. ... What we saw was a lot of teams. They wanted to experiment with Python. They wanted to use Python for positive caring for the evaluations, but because of our stack, they were forced to build Java and use that to build their services.)
オープンソースコミュニティの急速な進化に追従するためには、Pythonへの移行が不可欠だったとTag氏は語ります。新しいモデル、ライブラリ、技術が次々と登場する中で、非Pythonスタックではイノベーションの速度が著しく低下するためです。そこでLinkedInは、Pythonを標準とし、チームが容易に本番環境対応のPythonサービスを構築できるフレームワークを開発・提供するに至りました。現在では20以上のチームがこのフレームワークを利用し、30以上のGenAI関連サービスが生まれているとのことです。
サービスフレームワーク：Python, gRPC, LangChain, LangGraph
LinkedInが構築したサービスフレームワークは、PythonとgRPCをベースとし、ビジネスロジックのモデル化にはLangChainとLangGraphを活用しています。gRPCを採用した理由としては、組み込みのストリーミングサポート、バイナリシリアライゼーションによるパフォーマンス向上、そして多くの言語を使用するLinkedInにとって重要なクロスランゲージサポートが挙げられました。
Tag氏は、このフレームワーク上で構築されたリアクティブエージェントのサンプルコードを示し、ツールコーリング、大規模言語モデル推論、会話メモリ、チェックポイントなどの標準ユーティリティが提供され、それら全てをLangChainとLangGraphが中心となって結びつけていることを強調しました。
「LangChainとLangGraphが私たちのGenAIアプリの中核を形成しています。」 (Lang chain and link graph to tie all this stuff together, and really LinkedIn and lingrap inform the core of our generbi apps.)
なぜLangChainとLangGraphを選んだのか？
数ある選択肢の中からLangChainとLangGraphを選んだ理由として、Tag氏は以下の2点を挙げました。
- 使いやすさ (Ease of Use): 非常に直感的で、Javaエンジニアでも容易に習得できたとのこと。LangGraphのコミュニティ実装や事前構築済みエージェントなどを活用することで、数週間かかっていたアプリ開発が数日で可能になり、大幅な時間短縮に繋がったと述べました。
- 優れたインターフェース (Sensible Interfaces): LangChainとLangGraphのインターフェース設計が優れており、社内のインフラストラクチャ（Azure OpenAIやオンプレミスモデルなど）を容易にモデル化できた点を評価しました。これにより、モデルプロバイダーの切り替えなどが数行のコード変更で済む柔軟性を実現しています。
エージェントプラットフォーム：大規模システムの課題と解決策
次にTag氏は、複数のエージェントが連携する大規模システムにおける課題と、その解決のためにLinkedInが構築した「エージェントプラットフォーム」について説明しました。エージェントシステム特有の課題として、以下の2点が挙げられました。
- 長時間処理: エージェントは処理に長時間を要する場合があり、非同期フローのモデル化が不可欠。
- 並列実行と依存関係: 複数のエージェントが並列実行される中で、エージェント間の出力依存関係を管理し、正しい順序で処理を実行する必要がある。
これらの課題に対し、LinkedInは以下のソリューションを開発しました。
1. メッセージングによる非同期フロー
エージェント間の非同期コミュニケーションは、メッセージングの問題として捉えられました。LinkedInが既に保有する堅牢なメッセージングサービスを拡張し、エージェント間のメッセージングやユーザー・エージェント間のメッセージングをサポート。失敗したメッセージの自動リトライ機能なども備えています。
2. エージェント専用メモリ
エージェントがタスクを実行するために必要な情報を保持・活用できるよう、専用のメモリシステムを構築。このメモリはスコープ化・階層化されており、ワーキングメモリ (working memory)、長期メモリ (long-term memory)、集合的メモリ (collective memory) から構成されます。これにより、インタラクションの状況や履歴に応じて適切なメモリが利用されます。
「スキル (Skills)」：ファンクションコーリングの進化形
エージェントが具体的なアクションを実行する仕組みとして、LinkedInは「スキル (Skills)」という概念を開発しました。これはファンクションコーリングに似ていますが、いくつかの重要な違いがあります。
- スコープの広さ: ローカル環境に限定されず、RPCコール、データベースクエリ、プロンプト、さらには他のエージェント自体もスキルとして扱えます。
- 非同期呼び出し: スキルを同期的にも非同期的に呼び出すことができ、これは長時間処理が伴うエージェントシステムにおいて極めて重要です。
「スキルは同期的にだけでなく、非同期的に呼び出すこともできます。これは私たちが話してきた様々なテーマを考えると、非同期性は絶対に不可欠です。」 (how specifically we let agents invoke skills synchronously but also asynchronously, which we consider the different themes that we talked about. The asynchronicity part is absolutely critical.)
さらに、これらのスキルは中央のスキルレジストリ (skill registry) に登録され、異なるチームやエージェント間で発見・再利用が可能です。これにより、組織全体でのエージェント開発の効率化と連携強化が図られています。Tag氏は、スーパーバイザーエージェントがソーシングエージェントに指示を出し、ソーシングエージェントがスキルレジストリを介して適切なスキルを発見・実行するというフロー例を示しました。
オブザーバビリティの重要性
最後にTag氏は、エージェント的な実行方法には特有のオブザーバビリティ (observability) ソリューションが必要であるとし、カスタムのオブザーバビリティ基盤を構築したことにも言及しました。
「観察できないものは修正できません。これを実際に行うには、堅牢な評価が必要です。」 (You can't fix what you can't observe. And really, to do this, you need robust evaluations, things that people have talked about already.)
まとめと教訓
David Tag氏は講演の最後に、LinkedInでのエージェント開発から得られた2つの重要な教訓を共有しました。
- 生産性への投資: この分野は急速に進化しているため、開発者が容易に構築・適応できるよう、標準化されたパターンを提供し、生産性を高めることが不可欠です。
- 本番ソフトウェアとしての考慮事項: エージェントシステムも本番ソフトウェアである以上、可用性、信頼性、そして特にオブザーバビリティと堅牢な評価が極めて重要です。
LinkedInの事例は、大規模組織においてAIエージェントをプロダクションレベルで開発・運用し、スケールさせていく上での具体的な課題と、LangChain/LangGraphを含む技術スタックをいかに戦略的に活用していくかという点で、多くの示唆を与えてくれるものでした。特に、Pythonへの大胆な移行、標準化されたフレームワークの提供、そして「スキル」という独自の概念によるエージェント連携の仕組みは、今後のエージェント開発における重要なヒントとなりそうです。
