Wantedly の AIエージェントと Human-in-the-Loop の設計判断

2026年5月28日の「第7回 AWS ジャパン 生成 AI Frontier Meetup」で登壇した資料です。

Transcript

1. © 2026 Wantedly, Inc. Wantedly の AIエージェントと Human-in-the-Loop の設計判断 第7回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ May.28 2026 - Sora Ichigo (ウォンテッドリー株式会社 )
2. © 2026 Wantedly, Inc. 所属 ウォンテッドリー株式会社 Visit AI Squad リーダー 略歴 2023年4月にウォンテッドリー新卒入社。 複数のチームで基盤・プロダクト開発を経験したのち 2026年4月より Visit AI Squad のリーダー。 自己紹介 Sora Ichigo 2
3. © 2026 Wantedly, Inc. ウォンテッドリーは、⾃律‧共感‧挑戦のある適材適所を、 ⼀時的でも、局所的でもなく、構造的に⽣み出し続けることによって、 あらゆる⼈がシゴトに没頭し成果を上げ、その結果成⻑を実感できるような 「はたらくすべての⼈のインフラ」を構築していきます。 究極の適材適所により シゴトでココロオドル ひとをふやす ミッション 3
4. © 2026 Wantedly, Inc. 究極の適材適所により、 シゴトでココロオドルひとを ふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを 2012年から創出。 はたらくすべての⼈が共感を通じて「であい」「つながり」「つな がりを深める」ためのビジネスSNS「Wantedly」を提供していま す。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合える ような世界を実現するために、国境を超えて「はたらくすべての⼈ のインフラ」を創っていきます。 / / 提供サービス
5. Wantedly Visit iOS, Android and Web 気軽に会社訪問 ミッションや価値観への共感でマッチング • 給与や福利厚生などの条件ではなく、想いがあれば会社の規 模にとらわれない まず「話を聞きに行く」という新しい体験 • 個人と企業がフラットな目線で出会えることで、より魅力的な場 所を見つけることが可能に
6. © 2026 Wantedly, Inc. Visit Tribe Engagement Tribe Ground Tribe Growth Squad Growth Squad Feature Squad Growth Squad Growth Squad Infra Squad AI Ops Squad Chapter Frontend Chapter Backend Chapter Mobile Chapter Infrastructure Chapter Data Chapter PdM Chapter Engineering Manager (CTO / VPoE) Hire Tribe 開発組織の全体像 Visit AI Squad の 立ち位置
7. © 2026 Wantedly, Inc. ユーザー向け 運⽤ Wantedly の AI プロダクトの全体像 7 キャリアAI エージェント プロフィール 自動生成 企業向け ソーシングAI エージェント 募集の AI 特徴 コンテンツ モデレーション 求職者向け‧企業向け‧運⽤向けの3つの軸で展開
8. © 2026 Wantedly, Inc. AI プロダクトの技術選定 ▎Amazon Bedrock とは AWS（Amazon Web Services）が提供する⽣成AIアプリケーションを構築‧運⽤するための フルマネージド型プラットフォーム https://aws.amazon.com/jp/bedrock/ ▎採⽤理由 • 既存 AWS インフラとの整合性 ◦ ウォンテッドリーでは K8s クラスタが EKS で稼働 • セキュリティ（VPC内完結‧監査性） • 価格‧コスト最適化 • モデルカタログの充実 Amazon Bedrock 経由で LLM モデル / 埋め込みモデルを利⽤
9. © 2026 Wantedly, Inc. Apps #Components < 10 admin Web Platform iOS Platform admin Android Platform Infrastructure : Wantedly Design System [Language] TypeScript, Swift, Kotlin [Foundation] Next.js, Kotlin Multiplatform System API GraphQL The System #Components < 100 System Cluster Gateway Online Communication • Protocol Buffers Over gRPC • Protocol Buffers over Cloud Pub/Sub Online Communication (Batch) • Argo Workflow Infrastructure : Kubernetes [Language] Ruby, Go, Python [Datastore] Postgres, Redis, Elasticsearch [Machine Learning] scikit, LightGBM [Observability] Istio, Datadog Data Data Warehouse Infrastructure : クラウド DWH [Language] SQL [BI tool] クラウドBIツール [Data Collector] fluentd [Data Transformer] dbt アーキテクチャと主要技術
10. © 2026 Wantedly, Inc. マイクロサービス構成に組み込む⼯夫 ① 非同期化でユーザ操作 のブロッキングを防ぐ ③ LLM Observability 計装や Region フォールバック実装を集約 ② 各 AI 機能に 関心のあるマイクロサービスが Bedrock を直接呼び出す Web / App GraphQL Gateway バックエンド マイクロサービス Amazon Bedrock 専用ライブラリ
11. © 2026 Wantedly, Inc. AI エージェントを実⽤化する時に考えるべきことは多い • Agent vs Workflow • Human-in-the-Loop (HITL) の設計 • 評価インフラ • LLM Observability • モデル選定とコスト • プロンプト設計 • ガードレール • セキュリティ‧プライバシー要件 • 透明性 LLM の性質による課題 • ⻑時間ジョブの中断‧再開のサポート • ユーザーの操作をブロッキングしない ⼯夫 ◦ Polling vs SSE vs Streaming • レートリミットの存在 • 複雑化するのジョブ同⼠の依存解決 LLM の性質によらない課題
12. © 2026 Wantedly, Inc. 今⽇の話 • Agent vs Workflow • Human-in-the-Loop (HITL) の設計 • 評価インフラ • LLM Observability • モデル選定とコスト • プロンプト設計 • ガードレール • セキュリティ‧プライバシー要件 • 透明性 LLM の性質による課題 • ⻑時間ジョブの中断‧再開のサポート • ユーザーの操作をブロッキングしない ⼯夫 ◦ Polling vs SSE vs Streaming • レートリミットの存在 • 複雑化するのジョブ同⼠の依存解決 LLM の性質によらない課題 今回は Human-in-the-Loop の設計にフォーカス
13. © 2026 Wantedly, Inc. Human-in-the-Loop (以降、HITL) とは何か ▎定義 AI の出⼒‧⾏動に対して、⼈間が介⼊できるポイントを持つこと ▎⽬的 信頼性 / 安全性 / 軌道修正 / ユーザー納得感 ▎スペクトラム 「⼊れるか / ⼊れないか」ではなく「いつ‧どの粒度で介⼊させるか」 完全自律 完全手動
14. © 2026 Wantedly, Inc. HITL の種類 パターンごとに使い分けが必要 パターン 説明 Wantedly の事例 承認ゲート AI のアクション前に人間が承認 ソーシングAIエージェント （プラン承認） 対話形式 AI と人間がマルチターンで合意形成 キャリア AIエージェント （対話型） モニタリング & Override AI が自走、人間は監視と必要時介入 募集の AI 特徴 （自動生成、非公開導線） よく登場するパターン
15. © 2026 Wantedly, Inc. 事例. キャリアAIエージェント / ソーシングAIエージェント ユーザー向け 企業向け
16. © 2026 Wantedly, Inc. 事例. 募集の AI 特徴 募集編集フローで確認・非 公開可能に
17. © 2026 Wantedly, Inc. • LLM の性質上、⽣成された⽂章に違和感が出る可能性はゼロではない • ユーザーの⼼理「気に⼊らない部分だけピンポイントで直したい」 • ⼀⾒すると、筋の通った要望に⾒えるが... 事例3「募集の AI 特徴」で実際にあった設計議論 社内ユーザー要望「個別の AI 特徴を編集‧削除したい」
18. © 2026 Wantedly, Inc. しかし、個別の編集‧削除を許すとどうなるか ミクロな介⼊が常態化すると、⼈間がボトルネックになる 1. AI特徴の確認‧編集が常態化 2. ⼈のレビューが増⼤ 3. 再⽣成の判断が曖昧で迷いが発⽣ AIが動くたびに 人間の確認・判断が 必要になる 判断基準が不正確で、品質やスピードに影響
19. © 2026 Wantedly, Inc. あえて「個別の編集‧削除なし」を採⽤ 採⽤理由： • 個別の編集‧削除を許すと、AI ⾃⾛の前提（=⾃動再⽣成‧常時稼働）が成⽴しなくなる • 事前テストではリスクもニーズも読みきれず、⾮公開設定で最⼩限から出すと判断した 公開設定は全体に対して適用 募集編集ごとに自動で再生成
20. © 2026 Wantedly, Inc. もう⼀つ考えられるアプローチ ▎概要 • ⾒せたくない AI 特徴を削除すると 同時に AI への追加学習データとして回す ▎Wantedly が採⽤しなかった理由 • 「⾮公開設定」を⽤意しておくことで必要最低限の品質リスクはクリアした上で、指標‧ 体験が悪化したら段階的に設計を拡張していくデータドリブンな意思決定をした • 実際にリリース後の⾮公開率のモニタリングでは、ほとんどの企業が AI 特徴を⾮公開せず にそのまま使っていた 個別アイテムごとに「誤り訂正」のメニューを置く UX
21. © 2026 Wantedly, Inc. まとめ ▎HITL は⼈間の介⼊ポイントを「いつ‧どの粒度で持たせるか」 を意識して設計する • 募集の AI 特徴の事例のように、あえて「どう介⼊させないか」まで考えることで LLM のス ケール性を守る必要がある ▎AI 機能ならではの事前予測の難しさがある • 例えば、⽣成コンテンツの品質をリリース前予測には限界がある • 時には、⽣成コンテンツの品質リスクに対して過剰に備えすぎず、あえて拡張余地を残し てリリース後にモニタリングするアプローチも有効 • 想定より品質リスクが顕在化していないこともあり得る