Timee Product Team Blog
https://tech.timee.co.jp/
タイミー開発者ブログ
フィード

Devinはソフトウェアファクトリーのフレームワークになった
140
Timee Product Team Blog
こんにちは、タイミーで開発生産性改善チームのマネージャーをしている新谷です。 みなさん Devin を使っていますか?タイミーでは日々 Devin が仕事をしてくれています。 Devinは単にタスクを依頼するツールにとどまらず、ソフトウェアファクトリーのフレームワークになりました。最近の進化が著しいので紹介させてください。本当にすごい。 ソフトウェアファクトリーとは LayerX CTOの松本さんが、Xの投稿で次のように述べていました。ソフトウェア開発は、人間がCoding Agentをどう使うかを考える段階を過ぎた。これからは開発プロセスそのものを、ループが閉じたプロダクトとして作る段階で、…
3日前

Kaigi on Rails 2026に協賛・参加しました
Timee Product Team Blog
こんにちは!このたびタイミーは、2026年10月16日(金)・17日(土)にベルサール渋谷ガーデンで開催されたKaigi on Rails 2026に、Rubyスポンサーとして協賛し、ブースを出展いたしました。 kaigionrails.org 素敵な場をつくってくださった運営のみなさま、セッションやLTを聴いてくださったみなさま、そしてブースにお越しいただいたみなさま、ありがとうございました!また、420名以上の方がタイミーのブースに立ち寄ってくださいました。 タイミーのエンジニアはKaigiPassという制度を利用して参加しました。この記事では、ブース企画・スポンサーLT・ブースでいただい…
3日前

運用しながら改善する LLM-as-a-Judge の構築
94
Timee Product Team Blog
はじめに こんにちは、株式会社タイミーでプロダクトAIエンジニアとして働いている貝出です。直近は、LLMを利用した求人審査AIの開発や性能改善を行っています。 LLMを使った機能を開発していると、LLMの生成文を実際にユーザーに見せるケースがあります。そのときには「生成文に問題がないか」を評価する必要があります。解決策の一つとして、生成文をLLMに評価させる “LLM-as-a-Judge” があります。 ただし、LLM-as-a-Judgeを導入するには、そのLLM-as-a-Judge自体が意図通りに評価できているかを事前に確かめる必要があります(以下、この評価をメタ評価と呼びます)。メタ…
7日前

全社の SAST をどう選んだか — Amazon Inspector と CodeQL を同じコードで比べた
Timee Product Team Blog
ℹ️ この記事について この記事に出てくるコードとスクリーンショットは、すべて 検知の挙動を確かめるために用意した検証用のサンプルです。 実際のサービスのコードではありません。 ツールが反応するかを見るために意図的に脆弱に書いているので、 そのまま流用しないでください。 はじめに こんにちは、タイミーのプラットフォームエンジニアリング1グループに所属している久慈です。 この記事では、全社のソースコード向け SAST(静的アプリケーションセキュリティテスト)の選定で、Amazon Inspector Code Security と GitHub Advanced Security(以下 GHAS…
8日前

LLM Content Moderationを支える評価・改善ループの実践
Timee Product Team Blog
こんにちは。タイミーでAI・データサイエンス部に所属している栁です。 タイミーでは、募集内容やレビューなどの投稿コンテンツを審査するContent Moderationの仕組みにLLMを導入しています。この領域で品質を継続的に高めるには、プロンプトやモデルの改善だけでなく、評価データ、本番ログ、そして審査に関するドメイン知識を接続する仕組みが欠かせません。 本記事では、その評価・改善ループと、ドメインエキスパートの専門知識をループに組み込むプロセスの設計について、取り組みを紹介します。 Content Moderationの二つの課題:誤判定を減らし、正解を定義する Content Moder…
20日前

Navier–Stokes解決のエージェント群と自動研究論文9本から考える、推薦システム自動改善の設計
Timee Product Team Blog
はじめに こんにちは、株式会社タイミーでデータサイエンティストをしている藤井です。 普段は推薦エンジンの改善を担当しています。 最近は推薦エンジンそのものの改善に加えて、LLM を使って推薦エンジンの改善サイクル(仮説→実験→評価)をいかに速く回すかにも取り組んでいます。 5か月前の前回記事では、Claude の Skill を使って半自動で推薦システムを改善する取り組みを紹介しました。 現在はそこから一歩進んで、推薦エンジンの自動改善の運用を開始しており、以下のような構成をとっています。 エージェントは Claude Agent SDK で実装しています。 図1. 推薦エンジン自動改善システ…
20日前

名古屋 Ruby 会議05 に登壇しました
Timee Product Team Blog
こんにちは。株式会社タイミーのバックエンドエンジニアの神山(@dak2)です。 2026/9/19 に名古屋の大須演芸場で開催された名古屋 Ruby 会議05 に登壇してきました。 タイミーでは、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、そちらを活用して現地でカンファレンスに参加してきました。 今回は『特殊変数大全』というテーマで登壇しました。印象に残ったセッションや、当日の様子を紹介します。 Road to 名古屋 Ruby 会議05 会場の大須演芸場は、大須観音や大須商店街のある賑やかな大須界隈に位置する、1965年開館の寄席です。…
1ヶ月前

VPC Flow Logs で「6379 番ポートに外部 IP が…」と一瞬ひやっとした話
Timee Product Team Blog
はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 VPC Flow Logs に、VPC 内のサーバーがインターネット上の IP の 6379 番ポートと通信している行が記録されているのを見つけました。6379 は Redis のポートなので、字面だけ読むと「インターネット側に Redis がいて、そこに繋ぎに行っているのか?」と読めてしまいます。 この記事では、このログをパケットのヘッダーとしてどう読むか、そしてそこから立てた仮説を Flow Logs だけでどう裏付けたかを書いていきます。 きっかけ VPC Flow Logs を…
1ヶ月前

Renovate 設定の改善
Timee Product Team Blog
こんにちは。タイミーのデータエンジニアリング部DSグループでMLOpsを担当しているYukitomoです。 前回の記事では、Python + uvのモノレポ環境において、Renovateを用いて依存関係更新のプルリクエストを制御するための基本設計を紹介しました。 その後、実際に運用してみると、Renovateの管理対象はPythonの依存パッケージだけでは収まりませんでした。devcontainer.jsonやCloud Runのマニフェストなどへ対象を広げるにつれて設定が複雑になり、Mend.io経由で動かして結果を待つだけでは、意図通りに動かない設定の原因を追いにくくなりました。 そこで今…
1ヶ月前

DroidKaigi 2026参加レポート:ポスターセッションと参加後の振り返り
Timee Product Team Blog
タイミーでAndroidアプリの開発をしている、みかみとmurataです。 2026年9月1日から3日に開催されたDroidKaigi 2026に、タイミーでAndroidアプリを開発するメンバーで参加しました。Event Day(9月1日)ではポスターセッションでタイミーのAndroid開発について発表し、Conference Day(9月2日、3日)ではセッションを聞きました。 この記事では、ポスターで発表した内容と、参加後にSlackや社内勉強会で話したことを紹介します。 ポスターセッションに参加しました DroidKaigi 2026では、Event Dayの新しい企画としてポスターセ…
1ヶ月前

EXPLAIN で詰まったときの三つ目の手札、Optimizer Trace の話
Timee Product Team Blog
はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 MySQL が遅いとき、まず EXPLAIN で計画を見る。見積もりが怪しければ EXPLAIN ANALYZE で実測と突き合わせる。たいていのケースはこの二つで十分で、実際自分もそれで困ったことはほとんどありませんでした。 ところが先日、この二つをいくら眺めても答えが出ない場面に当たりました。最後に頼ったのが Optimizer Trace でした。普段のチューニングではまず使わないので、すっかり引き出しの奥にしまっていた手札です。そこに至るまでの経緯も含めて書いておきます。 まず…
2ヶ月前

Go Conference 2026に出展しました
Timee Product Team Blog
こんにちは!このたびタイミーは、9/11(金)開催のGo Conference 2026 にGoルドスポンサーとして協賛し、ブースを出展いたしました。 gocon.jp 素敵な場をつくってくださった運営のみなさま、そしてブースにお越しいただいたみなさま、ありがとうございました! Closingでの発表によると、参加者は会場とオンライン合わせて700人を超えたそうです。その内、300人以上の方がタイミーのブースに立ち寄ってくださいました。 この記事では、タイミーのブース企画と、ブースでいただいた質問をご紹介します。執筆者はこちらの4名です。 Engineering Manager: 新谷(@eu…
2ヶ月前

Product Engineering Conference 2026 参加レポート
Timee Product Team Blog
はじめに タイミーでは、世界中で開催される技術系カンファレンスの参加を支援する「Kaigi Pass」という制度があります。今回は、2026年9月5日(土)に中野セントラルパークカンファレンスにて行われた、Product Engineering Conference 2026に5名が現地参加してきました。 本レポートでは、参加したエンジニアが注目したセッションごとに、参加者自身の視点で学びや気づきをまとめました。読者の皆様にとって、今後の学びの参考になれば幸いです。 営業・CSを「開発の当事者」にする — 少人数チームで複数プロダクトを動かすDev<>Ops連携の方法 speakerdeck.…
2ヶ月前

そのプロダクト、自分で売れるか? ~商談同行で育つ、営業とのコミュニケーションパス~
Timee Product Team Blog
こんにちは。タイミーでプロダクトエンジニアをしている津守です。 普段は、エンジニアとして機能の開発をメインの仕事としていますが、最近は営業チームの商談に同行する機会が増えてきました。そこで突きつけられたのが、タイトルの問いです。 自分が作った機能を、自分で売れるか。 機能は作れる。仕様も説明できる。でも、顧客を前にして「これはあなたの課題をこう解決します」と語り、納得してもらえるか。やってみると想像以上に難しく、同時に開発者として得るものが大きい体験でした。 この記事では、商談同行を重ねる中で見えてきたことと、そこから営業メンバーとの間に育っていったコミュニケーションパスについてまとめます。9…
2ヶ月前

前例なし・高認知負荷の顧客企業データ統合を、主担当領域の異なるメンバーとAIと共に完走するための設計と実践
Timee Product Team Blog
こんにちは、タイミーでバックエンドエンジニアをしている志賀(@akitoshiga)です。 先日、複数の顧客企業にまたがる、複雑なデータ統合プロジェクトに取り組みました。 このプロジェクトには、次のような難しさがありました。 要件が曖昧で、影響範囲も見えづらい 統合パターンごとに状況や制約が異なり、考慮すべき条件が多い 関係者が多く、合意形成に時間がかかりやすい 事業上、変更しづらい期限がある 当時の体制では、バックエンド領域を主担当として動けるメンバーが限られていた このまま進めるだけでは、期限内の完了が難しい状況でした。 結論から言うと、次の3つを実践することで、期限内に完了できました。 …
2ヶ月前

iOSDC Japan 2026に協賛いたします
Timee Product Team Blog
iOSDC Japan 2026 にシルバースポンサーとして協賛します こんにちは!DevEnable室のshihorinです。 このたびタイミーは、iOSDC Japan 2026 にシルバースポンサーとして協賛いたします。 開催に向けて準備を進めてくださっている運営のみなさま、ありがとうございます! iOSDC Japan は、iOS関連技術をコアテーマにした技術者のためのカンファレンスです。 詳細は公式サイトをご覧ください。 開催日程:2026年9月11日(金)〜9月13日(日) 会場:有明セントラルタワーホール&カンファレンス/オンライン iosdc.jp 「iOSDCチャレンジ」に参…
2ヶ月前

Auroraバックアップを「取れているはず」で終わらせない監視の仕組み
Timee Product Team Blog
こんにちは。タイミーでプラットフォームエンジニアをしている菅原です。普段はAWSを中心に、インフラの設計と運用に取り組んでいます。 今回は、ランサムウェア対策として構築したバックアップと、そのバックアップが正しく機能していることを継続的に監視する仕組みを紹介します。 ランサムウェア攻撃は、データを暗号化したり盗んだりするだけでは終わりません。復旧そのものを妨害するために、既存のバックアップまで削除や改ざんの対象にするケースが増えています。この脅威に備え、私たちはAmazon Auroraクラスタのバックアップを、クロスアカウントの論理エアギャップVault(Logically Air-Gapp…
3ヶ月前

「はたらく」の体験に向き合う。タイミーに入社して感じていること
Timee Product Team Blog
はじめに 2026年7月にタイミーへ入社した細野です。現在はバックエンドエンジニアとして、ワーカーさんと事業者様双方の体験をより良くするためのプロダクト開発に携わっています。 この記事では、私がタイミーに興味を持った背景と、入社後に感じていることを書きます。タイミーに少しでも興味を持っている方にとって、入社後のイメージを持つ材料になれば嬉しいです。 簡単な自己紹介 私はもともと、紳士服販売からキャリアをスタートしました。その後、プログラミング講師を経て、2021年からエンジニアとして働いています。 エンジニアとしては、スタートアップや事業会社でフロントエンドからインフラまで、幅広く開発に携わっ…
3ヶ月前

テストが増えすぎてもう限界だったので、PRで全テストを回すのをやめた話
Timee Product Team Blog
はじめに こんにちは、タイミーのプラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 この記事では、スキマバイトサービス「タイミー」のバックエンド(Rails API)に Datadog Test Impact Analysis(TIA) を導入し、PRごとのCIフィードバックを大幅に高速化した取り組みについて紹介します。 なお、バックエンドはRailsアプリケーションなので、テストフレームワークは RSpec を前提として話を進めます。 サービスが成長してプロダクトの機能が増えてくると、テストも当然増えていきますよね。開発者が増えればPRの数も増え、CIの待…
3ヶ月前

Self-hosted Runner 基盤の o11y 向上 - Grafana・Prometheus・Loki・Alloy の導入時に直面した問題とその解決策 -
Timee Product Team Blog
1. はじめに こんにちは。プラットフォームエンジニアリングチームに所属する小泉(@naotoko_)です。 本記事は、同チームの徳富(@yannKazu1)が執筆した「消えるランナーの観測基盤をどう選んだか — Datadog・マネージド・OSS を料金体系で比べて Loki + Prometheus に決めた話」の本番環境への導入編です。EKS Auto Mode でホストしている Self-hosted Runner の監視基盤に Grafana・Prometheus・Loki・Alloy を導入した際にハマったポイントと解決策を、各コンポーネントごとにお伝えします。 Grafana・P…
4ヶ月前

Datadogでも長期ログ保存はできる ─ Flex Logs導入でエンジニアのログ調査工数を削減しようとしている話
Timee Product Team Blog
はじめに 株式会社タイミーのプラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 突然ですが、皆さんの組織では「3ヶ月前のログを見たいんですが……」という依頼が来たとき、どう対応していますか? タイミーではDatadogをログ基盤として利用しています。Datadogは日常的なログ検索やアラート、ダッシュボードなどに使える非常に強力なツールです。一方で、ログの保存にはそれなりのコストがかかります。そのため弊社でも、コストとのバランスを考えてログの種類ごとに14日〜長くても45日程度の保持期間を設定していました。 普段の運用ではこれで十分です。ただ問題となるのは、…
4ヶ月前

消えるランナーの観測基盤をどう選んだか — Datadog・マネージド・OSS を料金体系で比べて Loki + Prometheus に決めた話
Timee Product Team Blog
はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 GitHub Actions のセルフホストランナーを運用していると、「あのジョブのログ、後から見たいんだけど……」という場面、けっこうありますよね。普段は気にしないんですが、いざ調査となると地味に困る。しかもランナーは ephemeral(ジョブが終わると Pod が即削除される)なので、見たい頃にはログが残っていない、という状態でした。 今回は、この「消えるランナー」のログとメトリクスを観測できるようにした話です。ただ、構築手順そのものよりも、 「Datadog・マネージド・OSS…
4ヶ月前

日中でも安心して ALTER TABLE を流したい ─ Datadog + Devin によるロングトランザクション削減
Timee Product Team Blog
こんにちは、タイミーでバックエンドエンジニアをしている 福井 (bary822) です。 タイミーのバックエンドは巨大な Rails のモノリスアプリケーションです。以前から「アクセスが集中する特定のテーブル(以下、人気テーブル)への DB マイグレーションが日中に通らない」という問題を抱えており、看過できないレベルになってきたため、本格的に対処に乗り出しました。 この記事では、原因となっていたロングトランザクションに対し、Datadog と Devin を組み合わせた自動修正フローで対処した話と、その設計の裏側を紹介します。 DBマイグレーション失敗のメカニズム 日常的に発生していたのは、人…
4ヶ月前

Aurora MySQL の GTID モード有効化と Datastream の安全な切り替え
Timee Product Team Blog
はじめに こんにちは。タイミーで Platform Engineer をしている小河原(@kgwryk28)です。 現在、タイミーのシステムで利用しているメインのデータベース(Aurora MySQL)のバージョンアップを進めています。前回の記事では、アップグレードに伴う SQL の互換性や性能の検証について共有しました。 この記事では、そのアップグレードと並行して取り組んでいる Aurora MySQL の GTID モード有効化 を行うにあたって直面した課題と、それぞれをどう解決したかを紹介します。 GTID やレプリケーションに詳しくない方にも読んでいただけるよう、必要な前提はその都度補…
4ヶ月前

成長サービスのDB負荷に向き合う、Platform Team と Stream-aligned Teamで取り組む性能改善
Timee Product Team Blog
はじめに こんにちは! タイミーでPlatform Engineerをしている @MoneyForest です。 自分が所属しているチームでは、週一で「観測会」を実施しています。 サービスの負荷状況が分かるダッシュボードを確認したところ、ある時期から Aurora MySQL の Reader CPU 使用率が大きく上昇していることに気づきました。 原因になりそうな処理は見えてきましたが、関連する機能はすでに利用されていたため、単純にリバートできる状況ではありませんでした。そのため、インスタンスを追加して一時的にしのぎつつ、根本的な改善を進める必要がありました。 この記事では Reader C…
4ヶ月前

インスタンスサイズを「上げた」のに、Auroraのコストが「下がった」話
Timee Product Team Blog
はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 「インスタンスサイズを上げたらコストが下がりました」と言うと、だいたい「?」という顔をされます。スペック上げたらお金かかるに決まってるだろ、と。自分もそう思っていたので気持ちはわかります。 この記事では、Amazon Aurora のReaderインスタンスを db.r7g.8xlarge から db.r7g.12xlarge にスケールアップした結果、I/Oコストが大幅に減り、トータルのAuroraコストがむしろ下がった話を書きます。バッファプールの仕組みと、判断の経緯もあわせて紹介…
5ヶ月前

データベースのバージョンアップの不安を解消。Insight SQL Testingを活用した検証手順
Timee Product Team Blog
はじめに こんにちは、初めまして。今年3月に入社し、タイミーで Platform Engineer をしている小河原(@kgwryk28)です。 現在、タイミーのシステムで利用しているメインのデータベース(Aurora MySQL)のバージョンアップにおける検証を進めています。 データベースのアップグレードで気になるのは、「今まで動いていたSQLが新バージョンでもそのまま動くのか」「アップグレードによって遅くなるクエリはないのか」という点です。 アップグレード後に互換性の問題や性能劣化が本番で発覚すると、影響は計り知れません。そのため、バージョンアップ範囲内の各バージョンの変更内容(chang…
5ヶ月前

Datadog DASH 2026に参加してきました!
Timee Product Team Blog
はじめに こんにちは! タイミーでPlatform Engineerをしている @MoneyForest です。 2026年6月9日〜10日にニューヨークで開催された Datadog の年次カンファレンス DASH 2026 に参加してきました。弊社からは、MLOpsエンジニアの斎藤が「How Timee Delivers Day 1 Production Ready LLM Features」というタイトルで登壇していました。 本記事では、Keynote の全体像、タイミーの登壇セッション、そして Fireside Chat から得たメッセージについてお届けします。 DASH 2026 の全…
5ヶ月前

【GitHub Actions】明日からマネできる CI 高速化テクニック 3 選
Timee Product Team Blog
はじめに こんにちは、タイミーでエンジニアをしている徳富(@yannKazu1)です。 タイミーではメインサービスのバックエンドを Rails で開発しています(Go を採用しているプロダクトもありますが、本記事では Rails を前提とします)。 突然ですが、皆さんのチームでは CI の待ち時間、気になっていませんか? 「Push した、コーヒー淹れた、戻ってきた、まだ回ってる……」みたいな経験は、開発者なら一度はあるのではないでしょうか。 本記事では、そんな状況を改善するために GitHub Actions 上のテスト実行パイプラインで取り組んだ 3 つの高速化テク を紹介します。どれも「…
5ヶ月前

Docker Hardened Images から学ぶ、ビルド定義の抽象度
Timee Product Team Blog
こんにちは、株式会社タイミーでMLOpsエンジニアをしているKYです。普段はMLプラットフォームの構築・運用を担当しています。 実務の中でコンテナイメージのサプライチェーンセキュリティ強化を進めており、その一環として Docker 社が提供する「Docker Hardened Images(DHI)」の実装を辿る機会がありました。 その際、実際の定義ファイルを見て、少し驚きました。コンテナのビルド定義といえば「Dockerfile」が当たり前だと思っていたのですが、DHI の定義はなんと YAML で書かれていたのです。 「なぜ Dockerfile ではないのか?」と定義の読み方を追いかけて…
6ヶ月前