はてなブックマーク

ウォンテッドリーでバックエンドエンジニアをしている冨永(@kou_tominaga)です。2025年11月に AI エージェントモード機能をリリースしましたが、リリース後の利用データを分析する中で、LLMが意図しない条件を一定割合で生成されていることが分かりました。本記事では、この問題をどのように発見し、どのように改善し、どのような成果につながったのかを紹介します。 目次AIエージェントモード機能とは 背景 分析のアプローチ 結果 まとめ AIエージェントモード機能とはAIエージェントモード機能とは2025年11月25日にリリースした機能で、AIが採用担当者に代わってスカウト送信対象の候補者を自動で探索するものです。採用担当者が採用要件を入力するだけで、AI がソーシング計画を生成し、候補者を自動リスト化する体験を提供します。 この機能により、これまで採用担当が時間をかけて行っていた「採用

こんにちは。ウォンテッドリーでデータサイエンティストをしている角川(@nogawanogawa)です。 この記事では、Two-Towerモデルについて技術検証した話についてご紹介したいと思います。 目次Two-Towerモデル 協調フィルタリングとコールドスタート問題 Two-Towerモデルによるコンテンツ特徴量の活用 準備 疑似データセット作成 行列分解によるベースライン 実装 特徴量とモデル定義 対称学習 実験 nDCGでの評価 コールドスタートユーザーに関する評価 まとめ Two-Towerモデル協調フィルタリングとコールドスタート問題推薦の一般的なアルゴリズムには協調フィルタリングが挙げられます。これは既知の(ユーザー, アイテム)のペアの評価値をもとに未知の(ユーザー, アイテム) のペアに関する評価値を予測し、その予測値をもとに推薦をするアルゴリズムです。また、協調フィルタリ

はじめにこんにちは。ウォンテッドリーのバックエンドエンジニアの西野です。本記事では、開発チームの課題であったコードレビューの遅延を解消するために実施した取り組みを紹介します。 10月初旬、チームのバックエンドエンジニア間で「コードレビュー完了までの待ち時間が長い」ことが問題になりました。レビュー依頼から完了（Approve）までに1日以上かかるケースが多く、時には次の作業に着手できずにスケジュールが遅れることもありました。この状況を改善するために、私たちはレビュープロセスの見直しに着手しました。 なぜコードレビュー完了までに時間がかかるのかバックエンドメンバー間で議論した結果、レビューが滞る根本的な原因は「プルリクエストの内容理解にかかる負荷が高く、それがレビュー着手への心理的ハードルにもなっていること」にあると判明しました。具体的には以下の2点が主要な要因です。 ①依頼されたレビューのコ

BigQueryのSQLについて、ドキュメントを読んだり実験したりしながら挙動を解き明かしていこうと思います。第5回はNULLについて紹介します。ここまでで扱わなかったその他の型についても触れます。 今回扱う型NULLBOOLEANGEOGRAPHYNULL値NULL値はSQLではおなじみの値です。BigQueryでは、全ての型に出現の余地があります。 NULLの保存テーブルではNULLの保存に制約があります。 カラム型が ARRAY の場合は、 REPEATED モードとして扱われるため、 NULL は空配列と同一視されます。それ以外の場合は、カラムは OPTIONAL モードか REQUIRED モードを選ぶことができます。 REQUIRED の場合は NULL の保存が禁止されます。NULLの操作NULLに期待される意味は、それが使われる文脈によってまちまちです。 データが存在しない

こんにちは。ウォンテッドリーでデータサイエンティストをしている林 (@python_walker)です。 この記事では、AI エージェント Devin の機能である Playbooks を活用し、データサイエンティストチームが管理するマイクロサービスで使用している Python バージョンの更新作業を効率化し、作業コストの削減を実現した取り組みについて紹介します。 目次チームの抱えていた課題 これまでの Python アップデートの手順 Devin Playbooks を利用した効率化 Playbooks とは何か なぜ Playbooks を選んだか Playbooks の活用法 結果 解決した課題 まだ残っている課題 まとめ チームの抱えていた課題ウォンテッドリーでは、会社訪問アプリ Wantedly をはじめ、さまざまなプロダクトを開発・運用しています。その中には機械学習を活用したサ

BigQueryのSQLについて、ドキュメントを読んだり実験したりしながら挙動を解き明かしていこうと思います。第4回はARRAYとSTRUCTについて紹介します。 今回扱う型ARRAYSTRUCTARRAY型ARRAY型は決まった要素型をもつ可変長の配列です。たとえば ARRAY<INT64> は整数の配列を意味します。 これだけで済むなら話は簡単なのですが、ARRAY型の意味論を考えるにあたっては以下の制約が重要になります。 ARRAYのネストARRAYとNULLの関係ARRAYのネストARRAYをARRAYの要素型にすることはできません。したがって、 ARRAY<ARRAY<INT64>> は無効です。 ただし、間にSTRUCTを挟んで ARRAY<STRUCT<ARRAY<INT64>>> とすることはできるため、表現力の観点からはARRAYのネストは可能ともみなせます。 ARRAY

こんにちは、ウォンテッドリーでソフトウェアエンジニアをしている市古（@sora_ichigo_x）です。現在は Visit Sourcing Agent Squad でスカウトの新機能「AIエージェントモード」の開発を担当しています。 目次はじめに 何を、なぜ作るのか どうやって AI に候補者リストを作成させるか AI が候補者リストを作成する際の問題点 ヒューマン・イン・ザ・ループ（Human-in-the-Loop, HITL） ソーシング計画をどう作るか さいごに はじめに「AIエージェントモード」は 2025年11月にリリースされたスカウトの新機能で、候補者探しの一部を AI で自動化することができます。 AIが候補者リストを作成提案する「AIエージェントモード」提供開始 | Wantedly, Inc. この度、ビジネスSNS「Wantedly」において、企業が採用活動を行う際

ウォンテッドリーの Infra Squad に所属している巨畠です。 ある日、社内のURLロギングサービスのDBでレイテンシが急増する事象に遭遇しました。 レイテンシの悪化と聞くと（アプリケーション開発の場合は特に）「重いクエリがあるのかな？」「インデックスが効いていない？」と実装を疑ってしまいますが、今回の問題はそこではありませんでした。 この記事では、どうやって問題となっている状況を理解したのか、そしてなぜ「ハードウェア（インフラ設定）で解決する」判断をしたのかについて共有したいと思います。アプリケーション開発者の方々に向けて、課題の理解・解決のための「インフラ視点」を提供できれば幸いです。 目次link-tracker とは メール配信時に発生したレイテンシ増大 原因の深堀り：レイテンシのパターン レイテンシ増大の真因：Burst Balance の枯渇 Burst Balance

こんにちは。ウォンテッドリーでデータサイエンティストをしている角川(@nogawanogawa)です。 この記事では、自然文で書かれたデータに対してローカルLLMを用いてテキストデータのラベリングを行う事例についてご紹介したいと思います。 目次テキストのラベリング LLMを用いたテキスト分類 LLMを使うメリット ローカルLLMを使うメリット vLLMを用いた推論高速化 Structured Outputを用いたラベル構造の整理 実験 モデル・データセット ローカルLLMを使用してStructured Outputを利用する場合 vLLMを使用してStructured Outputを利用する場合 出力と実行速度 まとめ テキストのラベリング我々の身の回りには数多くのテキストデータで溢れていますが、自然文で書かれたデータは必ずしも扱いやすくはありません。実際、われわれは文章を読む際に無意識の

こんにちは！ ウォンテッドリーでインフラエンジニアをしている加藤 健 (@kkato25)です。 2025年11月21日に開催されたPostgreSQL Conference Japan 2025に参加してきました。昨年も同じカンファレンスに参加してブログにまとめているので、よければそちらもあわせてご覧ください。 PostgreSQL Conference Japan 2024 参加・登壇してみて | Wantedly Engineer Blog こんにちは！ウォンテッドリーでインフラエンジニアをしている加藤です。この記事は Wantedly Advent Calendar 2024 の10日目の記事です。昨日は佐藤祐亮さんの「バックエン... https://www.wantedly.com/companies/wantedly/post_articles/941389 昨年は講演と当日

インフラチームの笠井（@takayukikasai）です。 ウォンテッドリーでは複数の Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL を運用しています。使用していた PostgreSQL のバージョンが EOL を迎えるためアップグレード作業が必要になりました。これまでは深夜にメンテナンスウィンドウを設けてアップグレードしていましたがダウンタイムのタイミングも読みづらく準備工数も大きいという課題がありました。今回 AWS の Blue/Green Deployment 機能を使ってアップグレードを実施したところタイミングをコントロールしやすくダウンタイムも短縮できています。本記事では事前調査から検証、本番実施まで一連の作業で得られた知見を紹介します。 目次背景・課題 なぜ Blue/Green Deployment を採用したのか

こんにちは、QA Squad の青柳です。 前回、「3ヶ月でチームは変わる。Wantedly QAが示した『小さく始めて、確実に機能させる』組織変革の具体例」という記事で、QA依頼ワークフローの導入や「QAご意見箱」の設置を通じた、業務効率化と「建設的なフィードバックを交わせる組織文化」の醸成に向けた取り組みをご紹介しました。 こうした初期の地盤固めを経て、QA Squad は次のステップを目指し、FY26のテーマとして「攻めの品質」を掲げています。本記事では、ウォンテッドリーのQAが目指す「攻めのQA」の具体的な定義と、それを実現するための戦略的なアプローチである「対話から始まる協働QA」のロードマップについて詳述します。 目次QAの役割再定義と「攻めの品質」の必要性 事業成長を支えるQAのミッション QA Squadがプロダクト開発で果たす戦略的役割 品質を育てる3つのプロセス 協働Q

BigQueryのSQLについて、ドキュメントを読んだり実験したりしながら挙動を解き明かしていこうと思います。第3回は日付・時刻型についてです。 今回扱う型TIMESTAMPDATETIMEDATETIMEINTERVALRANGETIMESTAMP型TIMESTAMP型は、地球上で共有される同時性における特定の瞬間をあらわします。ただし、計算の都合上うるう秒は除外されているため、UTCやTAIとの秒単位での対応関係は曖昧です。 TIMESTAMPが表現できる範囲は、遡及グレゴリオ暦の紀元後1年の頭 (ちょうどを含む) から10000年の頭 (ちょうどを含まない) までの9999年間です。閏日の扱いの差により、ユリウス暦基準では1年1月3日からしか扱えません。 TIMESTAMPの精度はマイクロ秒です。 うるう秒は除外されているため、TIMESTAMP型において1日は正確に86400秒です

こんにちは。ウォンテッドリーでフロントエンドチームのリーダーをしている原 剛士 (@chloe463) です。この記事では、私が個人で開発したダッシュボードの開発時に使えるライブラリ panelgrid を紹介します。いわゆる「ダッシュボード」と呼ばれるような画面にある、複数のパネルをドラッグ・アンド・ドロップで自由で配置したり、パネルサイズを変えられたりする機能を実現するためのライブラリです。 きっかけ私は現在 Wantedly Hire の開発チームのリーダーをしています。Wantedly Hire はいわゆる ATS （Application Tracking System/採用管理システム) と呼ばれるシステムで、採用活動のために使われるWebアプリケーションです。この Hire の大きな目玉機能がレポートビルダーです。レポートビルダーには大きく2つの機能があります。 A. 集計項

2025年11月1日でウォンテッドリーの一員になれて一年になりました。吉良吉影のように静かに暮らしてきたフロントエンドエンジニアの一年をふりかえってみようと思います。 （余談ですが、ウォンテッドリーの会議室はジョジョの奇妙な冒険のスタンド名になっています） GitHubでふりかえるGitHubでの活動を集計してみました。 commit数: 1245Merged PR: 311初コミット: 2024/11/07初本番リリース: 2024/11/11この結果を見ると、ウォンテッドリーでは積極的に本番リリースを行なっていることがわかると思います。Feature Flagをつけてのリリースもありますが、ちょっとした不具合であれば発覚から1~2時間でリリースまでしているケースも珍しくありません。 このような積極的なリリースサイクルは、積み上げられた堅牢なCIやInfraチームの活躍、そしてなにより「

こんにちは。ウォンテッドリーでバックエンドエンジニアをしている小室 (@nekorush14) です。5年ぶりに触れたRubyで詰まったところを改めて学び直した話をします。今回はHashのSymbolキーとStringキーの違いについてまとめます。 目次はじめに :example_keyと"example_key"の違い Symbolは常に一意の識別子 Stringは毎回生成されうるデータ なぜSymbolキーが使われるのか パフォーマンスの優位性 セマンティクス(意味論) 的な使い分け Railsで発生させたnilバグとその対処法 対処法 まとめ 参考文献 はじめにウォンテッドリーへ入社し、5年ぶりにRubyの世界に戻ってきましたが、Symbolの扱い方や正しい考え方を忘れていました。ソース上でHashを使う機会があり、その時点では「RubyだからHashからデータを抽出するためのキーは

ウォンテッドリーでバックエンドエンジニアをしている江草です。 今回は、私たちのプロダクトである Wantedly Hire の Rails アプリケーションにおいて、CI の実行を約2.5倍高速化しコストを大幅に削減した取り組みについてご紹介します。 抱えていた課題高速化に取り組む前、このリポジトリの CI には大きく2つの問題がありました。 1. CircleCI の料金が高額となっている対象のリポジトリでは CircleCI を利用していますが、十数年以上前から存在し、ウォンテッドリーにおいて最も巨大な Rails アプリケーションよりも CircleCI の利用クレジットが高額となっていました。Wantedly Hire がリリースから1年未満であることなどアプリケーションの規模を考えると、異常にコストが高い状態でした。 2. テストファイルの実行時間が異常に長い個々のテストファイル

Mobile Tech Leadの久保出です。 今回は、Jetpack Composeにおけるプラットフォームと独自のデザインシステムとのギャップを解決する話になります。 目次デザインシステムにおけるタイポグラフィの重要性 直面した課題 原因 解決策 まとめ デザインシステムにおけるタイポグラフィの重要性私たちのチームでは、プロダクト開発の品質と効率を向上させるために、内製のデザインシステムを構築・運用しています。このデザインシステムには、カラーパレットやコンポーネントの状態定義と並んで、タイポグラフィに関する厳密な定義が存在します。 タイポグラフィは、ユーザーが情報を正しく受け取るための基盤となる要素です。定義されたフォントやフォントサイズ、行の高さ（Line Height）、文字間隔などがUI全体で一貫して使われることで、プロダクトの世界観が統一され、ユーザーは直感的に情報を理解しやす

ウォンテッドリーでバックエンドエンジニアをしている冨永(@kou_tominaga)です。本記事では、「ジョブが途中で止まり、ログにも例外が残らない」問題を原因特定から対策比較、実装まで順に解説します。一見まれな事象に見えますが、実際にはミドルウェアの設定値、デプロイやスケールインのタイミングなど、特定の運用条件が重なると再現しやすい問題でした。本記事ではその仕組みを明らかにし、同様の問題を防ぐための知見をまとめています。 目次前提 背景・問題の発見 解決策の検討 実装の詳細 1.SIGTERM を検知できるようにする 2.自己再エンキューによる再実行 結果と効果 まとめ 前提ウォンテッドリーでは、任意のタイミングでデプロイを実行できる オンデマンドデプロイ を採用しています。アプリケーションは Kubernetes 上で稼働しており、本記事はその環境で発生したジョブ中断の事象について解説

こんにちは、ウォンテッドリーでバックエンドエンジニアをしている平岡です 。 サーバーを経由せずクライアントからS3へ直接ファイルをアップロードする技術は、より良いユーザ体験を作るための選択肢として昨今のWebアプリケーション開発では欠かせないものとなっています。 本記事では、それらを実現する技術として、AWS S3のPresigned URLとPOST Policyについて調べたことをまとめてみたいと思います。 目次Presigned URL POST Policy CORS制約（Cross-Origin Resource Sharing） まとめ Presigned URL Presigned URLは、S3オブジェクトに対する一時的なアクセス権限付きのURLを発行する仕組みです。 サーバー側の役割： AWS SDK（例：Pythonのboto3やNode.jsのAWS SDK）を使用し

アンドパッドに新たに Ruby コミッタの nagachika さんこと、 近永 智之 が入社しました ! 数年前の RubyWorld Conference の廊下で hsbt が声をかけたのが入社のきっかけだったということで、早速、 hsbt が福岡でインタビューしました !! 意外にも Ruby を使った開発ではなく、データ部へ配属になった背景も取材していますので、ぜひご覧ください ! インタビュアー：柴田（アンドパッド 開発本部 フェロー） 鳴海（アンドパッド 開発本部 製品（EE）エンジニア） インタビュイー：近永（アンドパッド 開発本部 データ部 エンジニア） Rubyコミッタとしての活動柴田: 今日はアンドパッドに入社した近永さんの入社インタビューです。このインタビューのために、福岡オフィスに初めて出社しました。また近永さん同様に福岡からリモートで働いている鳴海さんにも参加し

私は最近、社内で定期的な開発生産性アンケートをするようにしました (実際の作業は他の人に任せています)。本稿では、アンケートという古典的な手段に頼ることにした理由と、得られたものについてお伝えします。 なぜアンケートを取ることにしたのかアンケートにはいくつも落とし穴があります。その落とし穴を避けるため、私たちはしばしばアンケートに頼らない指標を探すことがあります。 開発生産性チームの課題ウォンテッドリーにはかつて DX (Developer Experience) チームという、開発生産性の向上を目的としたチームがありました。このチームが抱えていた課題は、その改善対象そのものにありました。つまり、「開発生産性」の可視化が困難だったのです。 Four Keys の問題私たちは DevOps のベストプラクティスに従い Four Keys と呼ばれる指標の可視化を試みたり、これに関係するケイパ

こんにちは、ウォンテッドリーでインフラエンジニアをしている田中です。 ウォンテッドリーは 2025年10月27日に開催された Observability Conference Tokyo 2025 にスポンサーとして協賛し、 Infra Squad のメンバー4名が現地でイベントに参加しました。この記事ではイベントレポートとして、現地の様子とスポンサーセッション発表の裏側、そして私たちが得た学びをご紹介します。 イベント直前にもストーリーを投稿しているので、こちらもぜひご覧ください。 ウォンテッドリーは Observability Conference Tokyo 2025 にスポンサーとして協賛し、スポンサーセッションにて田中が登壇致します | Wantedly Engineer Blog こんにちは、ウォンテッドリーのインフラチームの川井 (@fohte) です。ウォンテッドリーは O

ウォンテッドリーでデータサイエンティストをしています林 (@python_walker) です。先日チェコのプラハで開催された RecSys 2025 において、我々ウォンテッドリーと半熟仮想株式会社の齋藤優太 (@usait0)さんとの共同研究の成果が採択され、私の方から口頭発表をしてきました。 Off-Policy Evaluation and Learning for Matching Markets Matching users based on mutual preferences is a fundamental aspect of services driven by reciprocal recommendations, such as job search and dating applications. Although A/B tests remain the gol

こんにちは、ウォンテッドリーのインフラチームの川井 (@fohte) です。 ウォンテッドリーは Observability Conference Tokyo 2025 にスポンサーとして協賛します。 また、当日はスポンサーセッションにてインフラチームの田中 (@bgpat_) が登壇します。 現地にはインフラチームのメンバー (川井 (@fohte)、巨畠 (@donkomura_)、加藤 (@kkato25)) も参加します。参加される皆様との交流を楽しみにしております! Observability Conference Tokyo 2025 とはObservability Conference Tokyo 2025 は、オブザーバビリティに関心がある人が集まり、知見を共有しあうカンファレンスです。技術やツールの話はもちろん、現場の課題や工夫、組織・文化の壁をどう乗り越えるかといったリ

こんにちは、ウォンテッドリーでインフラエンジニアをしている @fohte です。 2025 年 10 月 16 日に開催された、Datadog Summit Tokyo 2025 に参加しました。本記事では本イベントの様子を紹介します! Datadog Summit Tokyo とは?Datadog 社が開催するカンファレンスで、Datadog の最新情報や企業の活用事例を知ることができるイベントです。 今回は赤坂インターシティコンファレンスの 2 フロアで開催され、メインセッション会場のほか、Japan Datadog User Group (JDDUG) ブース、Datadog のプロダクトデモコーナー、AWS GameDay が設けられ、多くの参加者で賑わっていました。 Japan Datadog User Group (JDDUG) ブース 今回の Datadog Summit T

はじめにこんにちは。ウォンテッドリーのデータサイエンティストの市村です。 2025年9月、推薦システム分野の国際会議である RecSys 2025 に併設される形で、Recommender Systems for Human Resources（RecSys in HR 2025）が開催されました。このワークショップは、採用・人材配置・学習支援といった人材（HR）領域における推薦技術の研究を専門的に扱うもので、今年で5回目の開催となります。 HR領域の推薦システムは、Wantedlyのように人と仕事の理想的なマッチングを目指すサービスにおいても中核的な技術領域であり、ワークショップで発表された研究の多くは、私たちが現場で抱える課題意識と強く関連しています。 本記事では、RecSys in HR 2025で発表された研究を取り上げ、その背景・手法・評価結果を整理します。社内での知見共有を目的