Etsy 向けギフト支援ツール、プロトタイプから本番環境へ

Etsy が LangChain で実現した「ギフト支援エージェント」の本番導入と、非構造化データへの挑戦

Etsy は、数百万人の出品者が手作りのユニークなアイテムを販売する二面型マーケットプレイスです。しかし、在庫に固定された属性スキーマが存在せず、専門知識や視覚情報が不可欠な「非構造化データ」の検索は長年の課題でした。この課題に対し、エンジニアリングチームは LangChain ベースのエージェントを導入し、6 週間で本番環境へのリリースを成し遂げました。

本記事では、Etsy のエンジニアがどのようにして複雑なギフト検索を実現し、LLM の不確実性を制御しながら信頼性の高いシステムを構築したのか、そのアーキテクチャと評価プロセスを解説します。

非構造化データへの対応：LangChain と ReAct アージェントの採用

Etsy の商品データは、時として雑多でノイズの多い記述や、画像に依存する情報が散在しています。また、ギフト選びという行為自体が「誰に贈るか」は分かっても「何を贈ればよいか」が不明確な曖昧なプロセスです。

こうした課題に対し、Etsy は単なる検索エンジンではなく、ユーザーと対話しながら推薦リストを洗練させるエージェントの導入を決断しました。選定された基盤技術は、業界標準である LangChain です。

「エージェント分野で最高かつ最先端のツールであり、ネイティブな観測性と評価機能も提供します」

具体的には、抽象化と制御のバランスが取れた LangChain v1 のReAct アージェントを採用しました。このアーキテクチャでは、モデルがリクエストを受け取ると、まずどのツールを呼び出すかを判断し、その結果に基づいて推論を行います。そして「さらに検索を続けるか」「推薦リストを返すか」を選択するループを回します。

このエージェントの核心となるカスタマイズポイントは以下の 2 点です。

1. ミドルウェアによる制御: モデルの挙動を監視・補正する層
2. 独自ツールの設計: 検索、リスト表示、記憶機能を提供するツール群

受取人の長期記憶には PostgreSQL のキーバリューストアを使用し、モデルが動的に指示を読み込んで適切なツールを使用できるようにスキルを設定しました。これにより、ユーザーはエージェントとペアとなり、協力的かつ反復的に最適なギフトを見つけ出す体験が可能になりました。

信頼性と速度のエンジニアリング：無限ループ防止とストリーミングの実装

本番環境への移行において最大の障壁となったのは、LLM の信頼性と速度です。Etsy は以下の具体的な対策を講じました。

ミドルウェアによる「スピン」とハルシネーションの制御

モデルが同じツールを繰り返し呼び出す現象（スピン）や、存在しないリスト ID を返すハルシネーションは致命的な問題となります。これらに対し、Etsy は独自のミドルウェアで介入を行いました。

• 5 回連続呼び出し: システムプロンプトに追加し、「発見内容を要約する」か「ユーザーに入力を求める」よう指示します。
• 10 回連続呼び出し: エラーを発生させ、ユーザーに再試行を促します。

また、リスト ID のハルシネーション対策として、ツール実行後に得られた ID を台帳（観測済み ID）と比較し、ミドルウェアが可能な限り最善の方法で ID を修正する仕組みを実装しました。これにより、不確実なモデル出力を堅牢に制御しています。

メモリ管理の可視化とデバッグ

モデルが誤って「T シャツのサイズ」を「興味分野」フィールドに保存するなど、メモリを破損する事例も発生しました。これを解決するため、Etsy はターミナル UI エージェントデバッガを開発しました。

このツールにより、エージェントの状態を可視化し、グラフ内のノードでブレークポイントを設定してスタックを確認できます。Python のネイティブデバッガーとも統合されており、7〜8 種類の課題を迅速に特定・解決することができました。

既存インフラを活用した高速ストリーミング

理想的には LangGraph から直接クライアントへ結果をストリームしたいところですが、Etsy は新しい Kubernetes クラスターへの依存やセキュリティリスクを避けました。代わりに、長年使われている既存の Web インフラ（Apache）を活用するソケット転送パターンを採用しました。

1. PHP と Apache ワーカーが認証を行う。
2. ファイル記述子を常駐デーモンにハンドオフし、Apache ワーカーを解放する。
3. 常駐デーモンが更新イベントをクライアントへストリームする。

この工夫により、既存の Web インフラを破壊することなく、エージェントによる高速ストリーミングを実現しました。

LLM 判定器の整合性と評価：LangSmith と CLI ツールによる自動化

本番リリースに向けて最も時間を割いたのが評価プロセスです。Etsy は「結果に至る軌跡」と「最終成果物」の両面から評価を行いました。

非決定論的テストと LLM ジャッジの課題

エージェントの軌跡については、Pass-K テスト（非決定論的なテストを K 回実行し、パス率が閾値を超えることを保証）を採用しました。一方、最終成果物の評価にはLLM ジャッジ（AI が AI を判定する仕組み）が必要でしたが、データセット生成やレビューヤーの整合性確保など多くの課題がありました。

「多様なデータセットをどう生成するか？ レビューヤーをどう整合させ、較正して出品物を一貫した方法でラベル付けさせるか？」

Etsy Agents CLI と LangSmith の連携

これらの課題に対し、Etsy はLangSmith APIを活用した独自ツール「Etsy Agents CLI」を開発しました。この CLI を用いて以下のワークフローを自動化・標準化しています。

1. データセット生成: 多ユーザーシミュレーションを実行し、バッチ処理で大量のテストデータを生成します。
2. レビューヤーのキャリブレーション: コヘンのカッパ係数などの統計指標を用いて、偶然による整合性を除外し、レビューア間の合意率を管理しました。
3. LLM ジャッジの最適化: 業界ベストプラクティス（訓練/検証/テストの 20/40/40 分割）に基づき、JEPA などの手法で LLM のエラーを振り返りながらプロンプトを調整します。

このプロセスにより、精度と再現率を統計的に管理し、LLM ジャッジの整合性を高めました。最終的には、ホールドアウトセットや本番環境の例に対して実行し、自信を持ってリリース判断を下しています。

まとめ：6 週間の短縮とエンタープライズ AI のベストプラクティス

Etsy は、シニアエンジニア 3 名とデザイナー 1 名の小規模チームで、LangChain と LangSmith を活用してわずか6 週間で本番環境へのベータ版リリースを達成しました。

この事例が示すのは、複雑な非構造化データを扱う AI エージェントであっても、ミドルウェアによる制御や既存インフラの流用、そして標準化された評価ワークフローによって、大規模サイトでも安全かつ高速に導入できるという事実です。LLM の不確実性を「制御」し、「評価」を自動化するこのアプローチは、エンタープライズレベルの AI 開発における新たなベストプラクティスとして注目されるでしょう。