Dev Container Feature で実現する ML 開発環境のガードレール
こんにちは、株式会社タイミーで MLOps エンジニアをしている KY です。普段は ML プラットフォームの構築・運用を担当しています。 私たちのチームでは、機械学習エンジニアやデータサイエンティストが開発に集中できるよう、VS Code のリモート開発（Remote SSH および Dev Container）を活用した開発環境を提供しています。本記事では、その中でも 共通 Dev Container Feature によるガードレール にフォーカスし、各チームが自分たちで開発環境を立ち上げられることを前提にしながら、セキュア・バイ・デフォルトをどう実現しているかをご紹介します。 なぜ Dev Container Feature にガードレールを寄せるのか この記事を書こうと思ったきっかけは、もともと機械学習エンジニアやデータサイエンティスト向けだった開発環境を、データアナリストをはじめとする別職種のメンバーにも広げ始めたことでした。ユーザー層が広がるにつれ、「どこまでを各自の設定に任せ、どこからを仕組みで縛るか」をあらためて考え直す必要が出てきた、というのが出発点です。あわせて、組織として求められるセキュリティレベルも年々高まってきています。 ML プラットフォーム特有の事情として、ユーザーの専門領域が幅広い、という点があります。機械学習エンジニアやデータサイエンティストはモデリングやデータ分析を主戦場としており、依存パッケージの脆弱性管理やコンテナの権限設計といった領域は、本来の業務の中心ではないことが多いです。だからこそ、これらをユーザー個々の習熟度に委ねるのではなく、プラットフォーム側で初期値を配る方針を取りました。各チームがセルフサービスで開発環境を立ち上げられ、特別な設定をしなくても初期状態でセキュリティのベースラインが担保される状態を目指しています。推奨パスに乗るだけで安全に進められる、いわゆる「ゴールデンパス」の発想であり、セキュア・バイ・デフォルトを仕組みで成立させるアプローチです。 この方針を devcontainer.json レベルで素直に表現できる仕組みが Dev Container Feature でした。Feature を1行足すだけで宣言的にガードレールが適用されるため、「各チームが自律的に環境を立ち上げつつ、危険な操作だけは仕組みで塞ぐ」という設計とよく噛み合っています。 共通 Dev Container Feature によるガードレール 私たちの開発環境では、共通化した Dev Container Feature（以下、共通 Feature）を配っています。まず、ベースイメージと Feature の役割は明確に分けています。Docker Hardened Images（以下、DHI）をベースにした開発用イメージでは、各種開発ツール（Python / uv / gcloud / Claude Code など）をインストールしておきます。共通 Feature では、それらツールの設定ファイル配置とガードレール適用のみを担います。 この前提のもと、各チームの devcontainer.json は以下のようにシンプルで、ベースイメージを指定し、共通 Feature を追加するだけで、後述するガードレールがまとめて適用されます。 { "image": "asia-northeast1-docker.pkg.dev/<PROJECT>/<CUSTOM_DHI_PATH>:<TAG>", "features": { "asia-northeast1-docker.pkg.dev/<PROJECT>/<CUSTOM_FEATURE_PATH>:<TAG>": {} } } こうしてレイヤーを分けておくと、ツールの入れ物とポリシーの適用が混ざらずに整理されるため、よりセキュアに締めやすいという体感があります。たとえばポリシー側だけを Renovate で継続的に更新していけるので、イメージの差し替えと独立してセキュリティ設定の追従・レビューを回せます。なお、ベースイメージ側で押さえるべきリスク（OS パッケージの脆弱性など）と、Feature 側で押さえるべきリスク（ツールの権限・設定）をどう切り分けるかといった論点もあります。ただし本記事のスコープ外のため、詳細は割愛します。 この Feature がプロビジョニング時に各種設定ファイルを配置し、ガードレールを自動で効かせます。実際には複数のツール設定を同じ方式で配布していますが、本記事では代表例として AI エージェントの制御を取り上げます。 Claude Code などの AI エージェントの制御 昨今、Claude Code のような AI コーディングエージェントが普及していますが、無制限の権限を与えると破壊的変更や意図しないデータ送信のリスクがあります。共通 Feature は /etc/claude-code/managed-settings.json を自動生成し、システムレベルで制御を行います。 { "strictKnownMarketplaces": [ { "source": "github", "repo": "<ORGANIZATION>/<REPOSITORY>" } ], "allowedMcpServers": [ { "name": "<APPROVED_MCP_NAME>", "command": "..." } ], "permissions": { "deny": [ "Bash(sudo:*)", "Bash(gcloud:*)", "Read(~/.config/**)" ] } } ※ 実際の設定から一部を抜粋しています。 プラグインマーケットプレイスと MCP サーバーは、社内で承認されたもののみに制限しています（ホワイトリスト形式）。また、sudo や gcloud などの権限昇格・クラウド操作、~/.config/ 配下の機密情報へのアクセスといった危険な操作は、Deny リストでブロックしています。ユーザー側の settings.json では上書きできない managed settings として配置しているため、「うっかり緩めてしまう」ことを構造的に防げます。 Feature に寄せることの嬉しさ これらを共通 Feature として提供していることで、以下のようなメリットが得られています。 各チームの devcontainer.json は Feature を1行足すだけでよく、セキュリティ設定の知識なしにベースラインを満たせる。 Feature のバージョンを上げるだけで、全社的にガードレールを一括更新できる（Renovate で自動 PR される）。 設定の出所が Feature に集約されているため、監査やレビューの対象が明確になる。 実際に運用してみると、Renovate の PR を1本マージするだけで全チームの Claude Code 設定が同時に更新されるのは、想像していた以上に運用が軽くなったと感じています。 補足：周辺で効かせている多層防御 共通 Feature だけで全てを押さえようとせず、周辺の仕組みと組み合わせて多層防御を成立させています。ベースイメージには DHI を採用してコンテナ起動時点でのベースラインを引き上げ、ホストとなる Remote SSH 用 VM 側にも同等のポリシーを展開し、依存関係は Dependabot / Renovate で継続的に追従させる、という具合です。 おわりに 今回は、MLOps チームが 共通 Dev Container Feature を使って、ML 開発環境のガードレールをどのように設計・運用しているかをご紹介しました。 振り返ってみると、ツールは DHI イメージ、設定は共通 Feature、更新は Renovate と責務を分けておくと、それぞれに対するレビューや更新のサイクルを独立して回しやすいのが大きな利点でした。ガードレール自体を作ることよりも、ガードレールを錆びさせない構造に落とすことが、各チームの自律性を損なわずにベースラインを引き上げていくうえでの要だったように思います。 参考文献 Claude Code - System settings: /etc/claude-code/managed-settings.json に関する公式ドキュメント Dev Containers - Features: Dev Container Feature の仕様 こうした「セキュア・バイ・デフォルトな ML 開発環境」を、より多くのチームと一緒に磨き込んでいきたいと考えています。 We're Hiring! タイミーでは、ML プラットフォームの構築・運用やセキュアな開発環境の整備に一緒に取り組んでいただけるエンジニアを募集しています！ 少しでも興味を持っていただけましたら、ぜひ以下のリンクから詳細をご覧ください。 MLOpsエンジニア シニアMLOpsエンジニア 募集ポジション一覧
- Docker
- セキュリティ
- 生成AI
- MLOps
小規模→大規模の分析組織へ。タイミーに入社して半年で感じたこと
1. 自己紹介・経歴 はじめまして、データアナリストのrizumuです。2025年にタイミーに入社しました。 前職ではファッション系のCtoCマーケットプレイスを運営する会社で約4年間データアナリストとして働いていました。UIの分析やクーポン施策の効果検証、顧客セグメントの分析などを担当していました。 2. なぜタイミーを選んだか 転職活動で最も重視したのは、アナリストが多い環境で働きたいという点でした。 前職のチームでは、少人数ならではのスピード感や、幅広い領域を任せてもらえる環境に感謝していました。一方で、「この分析アプローチで良いのか」「他のアナリストはどう考えるのか」と壁打ちをしたい場面では、相談できる相手が限られるもどかしさもありました。分析は一人で完結させようと思えばできてしまう仕事ですが、だからこそ他のアナリストの視点に触れる機会が、自分の成長には欠かせないと感じていました。 一方タイミーは、データを事業の意思決定に活かすことに組織として積極的に投資している姿勢が、選考を通じて伝わってきました。この人数の差は単なる規模の話ではなく、分析の型や議論の文化に触れられる機会が増えることを意味します。ここでならさらにアナリストとしてのスキルを伸ばせると感じたので、タイミーに転職することにしました。 3. 入社して驚いたこと 1つのプロジェクトに複数のアナリストが関わる体制 まず驚いたのは、プロジェクトの体制です。タイミーでは1つのプロジェクトに必ずリードメンバーが一人いて、その上で領域ごとに担当が分かれる形で複数のデータアナリストが関わります。 前職では、基本的に1プロジェクトにつきアナリストは一人、という体制でした。同じチームにアナリストはいても、プロジェクトの深い文脈を理解しているのは担当者だけ。他のメンバーに相談したい場面でも、まずは理解の前提をそろえるために背景共有から始める必要がある場面がありました。 結果として、一人で抱え込んで意思決定する場面が多かったように思います。 タイミーでは、同じプロジェクトに対して最初から共通理解を持った仲間が複数いる。だから「この切り口でいいのか」「この数字の解釈、どう思う？」といった相談を、前提の説明なしにその場で進められます。共通理解を持った相談相手がいる状態は、分析の進めやすさを変えてくれました。 リードメンバーへの相談ハードルの低さ もうひとつ驚いたのが、リードメンバーへの相談のしやすさです。ここでのリードとは、直接の上司ではなく、プロジェクトの中でリードの立ち位置を担うアナリストを指します。Slackで気軽に聞けるのはもちろん、リモート中心の環境なので、「今すぐちょっと相談したい」と思えばGoogle Meetで時間をもらうこともできます。立ち上がり期には、その点に助けられました。 ダッシュボードに求められるクオリティの高さ 想像以上だったのが、ダッシュボードに求められる見やすさ・使いやすさの水準です。データアナリストだけでなく営業など異なる職種の方も使うため、数字が正しいだけでは足りず、誰が見ても意図が伝わり、迷わず使えることが要件になります。ダッシュボード単体で完結する品質が必要、という感覚は業務に入って分かった部分でした。 これらを通して感じるのは、アナリストが多い環境の価値が、日々の相談しやすさやアウトプット基準の高さという形で具体的に現れている、ということです。 4. 半年やってみて、これから 具体的な業務エピソードでいうと、あるプロジェクトで担当したダッシュボード構築の案件が思い浮かびます。ステークホルダーが使い道の想いは持っているものの、ダッシュボードとして何を見るべきかの要件は固まっていない状態からのスタートでした。まず叩き台を作り、リードのデータアナリストからフィードバックをもらいながら要件を詰めていき、最終的には当初の目的に沿った形に仕上がったと評価をいただけました。 このプロジェクトに限らず、目的を起点に形を組み立てていく仕事を経験する中で、半年で一番変わったと感じるのは、以前より目的を強く意識するようになったことです。事業部の業務を十分に理解できていない状態から関わることが多く、目的を掴めていないとアウトプットはすぐにブレてしまう。解像度高く目的を持ち続けることの優先度が、自分の中で上がりました。加えて、自分一人では思いつかない分析の切り口や議論の進め方に日々触れられるのは、データアナリストが多い組織ならではだと実感しています。 今後チャレンジしていきたいのは、AI活用の幅を広げることです。SQL生成などは日常的に使っていますが、最近特に手応えがあるのはダッシュボードのモック作成です。自作のClaudeスキルを使うことでイメージに近いモックが最初から出てきます。一方で実装工程はまだ手作業が中心なので、ここをもっと簡単に進められる仕組みを作っていけたらと感じています。 AI活用の面白さは、個人の業務が速くなるだけにとどまりません。データアナリストが多い組織とAIへの意識の高さが重なると、一人のスキルや得意領域を他のメンバーも扱えるように広げていけます。自分が扱えるスキルやチャレンジできる領域も自然と広がっていく、この循環こそ、この半年で感じているタイミーで働くことの面白さだと思っています。 もし、かつての自分と同じように小規模なデータアナリスト組織で働いていて、次のステージを考えている方や、AIを活用しながらデータアナリストとしての幅を広げていきたいと考えている方がいれば、この記事が何かのきっかけになれば嬉しいです。 We're Hiring! タイミーでは、ともに働くメンバーを募集しています！ データアナリストのポジションも募集中です。カジュアル面談も行っていますので、少しでも興味がありましたら、お気軽にご連絡ください。 https://product-recruit.timee.co.jp/
- データ分析
- Claude
- 生成AI
RevenueCat App Growth Annual Tokyo 2026 で聞いたアプリ成長の話
株式会社タイミーでモバイルエンジニア (Android / iOS) をしている、みかみです。介護領域のグロース施策を中心に、AB テストや分析、マーケティングとの連携などにも取り組んでいます。 2026年4月16日に開催された RevenueCat App Growth Annual Tokyo 2026 (以下 RAGA) に参加してきました。 アプリ成長、サブスクリプション、AI をテーマにしたセッションの中から、個人的に印象に残った話をいくつか紹介します。 RAGA について RAGA (RevenueCat App Growth Annual) は、RevenueCat が主催する「モバイルアプリ成長」をテーマにしたグローバルカンファレンスです。RevenueCat は、モバイルアプリのサブスク収益化プラットフォームを提供している会社です。 カンファレンスでは「AI・サブスクリプション・アプリ成長」をテーマに、プロダクト戦略やユーザー獲得、マネタイゼーション設計といったトピックが扱われていました。登壇者は Notion、ElevenLabs、Speak、YAMAP、SmartNews、Mirrativ、NOT A HOTEL といった国内外のアプリ企業の実践者で、経営層・CPO・CTO クラスが多かったのが特徴的でした。加えて RevenueCat Co-founder / CTO による基調講演もありました。 参加した目的 RAGA に参加したのは、アプリグロースに取り組む他社の現場の話を直接聞ける機会だったからです。日々の業務では、アプリの機能開発だけでなく、AB テスト・分析・マーケ連携にも取り組んでいます。エンジニアリングの先にあるグロース領域への関心も、最近広がってきていました。RAGA で扱われるトピックは、まさに自分の関心と重なる内容でした。 もうひとつ、AI に聞けばなんでも答えてくれる時代だからこそ、現場で一次情報に触れる機会を大事にしたいという考えもありました。後からまとめ記事や録画で追える情報も多いですが、一日を通して様々な実践者の話を続けて聞ける経験は、その場に行かないと得られないと思ったからです。 印象に残ったセッション RAGA は2トラック構成で、世界でアプリを成長させたリーダーが集う「Global Track」と、日本市場の実践者や世界進出を目指す起業家が登壇する「Japan Track」がありました。自分が参加した中で特に印象に残ったセッションを紹介します。 1. 原点回帰：iモードから現代のアプリ経済へ RevenueCat 共同創業者兼 CTO の Miguel Carranza さんによる基調講演では、日本のモバイル市場の歴史を起点に、現代のアプリ経済が直面する変化が語られました。基調講演の内容や RAGA Tokyo 全体の様子は ProductZine の詳細レポート に詳しいので、ここでは個人的に印象に残った点を中心に紹介します。 冒頭で印象的だったのは、現代のアプリ経済で当たり前になっている概念の多くが日本発だった、という視点です。1999 年の i-mode、絵文字、LINE など、日本のモバイル文化が今のアプリ経済につながっているという話から始まりました。 同時に、日本市場の大きさも具体的な数字で示されました。 日本は世界 3 位のアプリ市場 ユーザー一人あたりの年間支出は $166 2027 年にはスマホユーザーが人口の 94% に達する見込み 一方で、印象に残ったのは「市場が大きい」という話だけではありません。AI によってアプリを作るハードルが下がった結果、過去 4 年間で アプリの供給は7 倍に増え、市場には明確な分断が起きているそうです。上位 25% のアプリは収益を 80% 以上伸ばす一方で、下位 25% は 33% 減少しているという話もありました。 この話を聞いて、アプリ市場は「作れば伸びる」市場ではなくなってきているのだと感じました。AI によって作る力が広がるほど、作れること自体の価値は相対的に下がり、継続して使われる体験をどれだけ設計できるかがより重要になっていくのだと思います。 最後に取り上げられていた 「AI パラドックス」 も、その流れとつながる話でした。AI を組み込んだアプリは初期コンバージョンが強い一方で、解約が約 30% 早く、継続率に課題を抱えるケースが多いそうです。AI の新しさで一度使ってもらうことはできても、継続的な価値に落とし込めなければ LTV にはつながらない、という指摘として受け取りました。 アプリ市場というと、これまで漠然と「大きそうだな」くらいに捉えていましたが、今回の話を聞いて、規模の大きさ以上に競争の中身が変わってきていることを実感しました。ペイウォール設計やトライアル期間、継続率改善といった細部への投資が差を生むという話は、日々のグロース施策を考えるうえでもかなり示唆的でした。 2. 広告視点で考えるサブスクハックネタお披露目会 Repro の中野竜太郎さんと Alethne の坂本翔也さんが、Adjust の高橋将平さんのモデレートで議論したパネルディスカッションです。広告運用・計測・クリエイティブ最適化など、アプリ成長を広告の視点から見つめてきた登壇者ならではの、現場感の強い話が詰まったセッションでした。 冒頭で出てきたフレーズが強烈です。 "CPI (Cost per install) だけ見る投資はナンセンス。" "エンゲージメントの時代じゃない、アクティベーションの時代だ。" 登壇者たちが共通して強調していたのは、広告で獲得したユーザーの8割は Day 0 で離脱するという前提です。離脱を防ぐ鍵になるのが 「アハ体験」、つまりユーザーがアプリの価値を実感する瞬間の設計です。リワードで引っ張ってくるのではなく、自社サービスのコア体験そのものをゲーム化していくのが大事だ、という主張でした。 もう一つ参考になったのが「マジックナンバー」と最適化トリガーの設計の話です。トライアル開始を成果イベントにするのは弱く、「7日間トライアルで辞める気のユーザーは2時間で消える」というデータがあるそうです。そこで、「2時間以上滞在したユーザー」や「特定アクションを N 回実行したユーザー」をマジックナンバーに設定したほうが、広告の最適化トリガーとしても成果が出やすいとのことでした。 AB テストや分析に取り組んでいる身として、「何をイベントとして計測するか」の解像度を一段上げるヒントになる話でした。単に画面遷移を計測するのではなく、ユーザーがそのアプリの価値を実感したシグナルとしてイベントを設計する、という視点が新鮮でした。 3. 激動の時代、日本発メガベンチャーはどのように世界で勝ちに行くのか SmartNews のホン・ランドンさんと Mirrativ の赤川隼一さんによるパネルディスカッションです。コミスマの坂本達夫さんがモデレーターを務めたこの回が、自分にとっては強く印象に残ったセッションでした。プロダクト・グロース・経営の観点から、AI の進化と激化するグローバル市場にどう立ち向かうかが議論されました。 特に印象に残ったのが、グローバル展開の戦略の話です。展開する国の数によって取るべき戦略は変わるそうです。1 カ国に絞るなら徹底した現地化が有効、多国展開なら同一プロダクトを広げて手応えのある市場に集中投資する、という対比でした。いずれにせよ、個別市場の局所最適ではなく、会社全体の収益最大化を基準に手段を選ぶべきだ、という話が腑に落ちました。 セッションの締めくくり、ランドンさんからの「AI 時代に変わるもの・変わらないものは？」という問いに対する赤川さんの答えが、一日で最も刺さった言葉でした。 "変わるもの = ほぼ全部。アンラーニングとスピードが勝負。変わらないもの = 現地現物。" 「優秀な PM は必ず現地でユーザーが迷う姿を観察する」という話でした。AI で機能開発のスピードが上がる時代だからこそ、ただ機能開発を進めるだけではなく、問いを立てる力や、現場やユーザーに直接聞きにいくことの重要性は、むしろ増しているように感じます。 おわりに 参加してみて改めて感じたのは、AI 時代だからといって仕事が華やかになっているわけではない、ということでした。 各セッションで語られていたのは、AI を使いこなす派手な事例というよりも、その手前にある地道な計測や粘り強い観察、ユーザーの一次の声を拾い続ける姿勢だったと感じます。今回語られていた事例のどれもが、こうした地道さの積み重ねの上にあるということを、当たり前のようでいて改めて強く感じました。 AI でプロダクトの作り方は変わっていきますが、アプリを成長させるために向き合う対象は変わらず、むしろ AI が広がるほど、ユーザーをどれだけ深く読めるかがアプリの差として出やすくなっていくのかもしれない、と感じた一日でした。 カンファレンス後のアフターパーティーも独特でした。ライブや DJ セットを交えた構成で、日中のセッション合間にもスタンダップコメディが入るなど、国内の他のカンファレンスと比べても振り切り方が際立っていて、一日を通して印象的でした。
- 生成AI
- グロースハック
- モバイルアプリ
- UI/UX
RubyKaigi 2026は、SREにとっても"行く価値"のあるカンファレンスだった
こんにちは、タイミーでSRE業務を担当している徳富(@yannKazu1)です。 先日、函館で開催されたRubyKaigi 2026に参加してきました。Ruby本体やパーサ、GC、JITといった「言語の中身」を深掘りするカンファレンスなので、普段アプリケーションコードよりインフラ寄りの仕事をしている自分が行って楽しめるのか、という気持ちも少しありました。ですが、結果としてとても楽しめたので、感想を書いておきます。 SREが行っても普通に楽しめた 普段の仕事はRailsアプリケーションを安定して動かしたり、スケールさせたり、観測したりすることが中心です。Ruby本体にコミットするわけでも、パーサを書くわけでもないので、専門外の話も多いだろうと思っていました。 実際、聞いていて全部の細部までは追えないセッションもありました。それでも、 普段ブラックボックスとして扱っているGCやランタイムの中身が、作っている人の口から語られる 他社のRails運用をやっている人たちと直接話せる このあたりだけでも参加する価値を感じました。 Day 1のブースが意外と良かった 参加されたことがある方ならわかると思いますが、Day 2以降はブース巡りが意外と慌ただしくなります。スタンプラリーで人が流れたり、セッションの合間で時間が限られていたり。 その点、Day 1はスタンプラリーがまだ始まっていないので、ブースが比較的空いていてゆっくり話せる時間帯でした。立ち寄っても順番待ちがほとんどなく、エンジニアの方とじっくり話せます。 RubyKaigiにはほぼ例外なくRailsを本番運用している会社さんがスポンサーとして出展しているので、SREとしては「他社さんのアーキテクチャや困りごとを直接聞ける場」として、これがかなり面白かったです。 Railsで完結する vs クラウドネイティブに振り切る 複数の会社さんと話して興味深かったのが、「Railsの中で完結させるか、AWSのマネージドサービスに切り出すか」の判断基準が会社によって全然違うことです。 Railsはよくできていて、ActiveJob + Sidekiq、ActiveStorage、ActionCableなどを組み合わせれば、大抵のユースケースはRailsの世界の中で完結します。わざわざクラウドネイティブなマネージドサービスに切り出さなくても、運用負荷を抑えながら回せるケースは多い。 一方で、「ジョブの遅延が事業KPIに直結するので、マネージドサービスに切り出して水平スケールを確実にしている」と話す会社さんもあれば、逆に「今のスタックで十分捌けているし、Rubyエンジニアが運用できる構成に揃えたほうが組織的に強い」と話す会社さんもありました。 技術選定の基準として挙がっていたのは、ざっくりこんな観点です。 スパイク耐性が事業上クリティカルかどうか 運用するチームのスキルセットと採用市場 コールドスタートを許容できるワークロードか RubyKaigiは登壇者も来場者もアプリケーションエンジニアが中心です。そのため、「Sidekiqのままいくか、それとも切り出すか」といったテーマひとつとっても、「アプリケーション側からどう見えているか、何が嬉しいかつらいか」という視点で語られていたのが印象的でした。 普段、SRE系のイベントで「インフラ側の都合」としてこの手の話を聞くことが多い私にとっては、この視点の対比が非常に新鮮に感じられました。 「正解は一つじゃない」と頭ではわかっていても、SRE目線とアプリ目線では同じ意思決定でも見えている景色が違います。両方の視点を持っておくことが大事だなと、改めて感じました。 AI活用の温度感 もう一つ、多くのブースでも話題になったのがAI活用です。プロダクトへの組み込み、社内開発フローへの導入、営業・カスタマーサポートへの活用と、レイヤーごとに状況が違っていて面白かったです。 特に印象に残ったのが、SmartBankさんのブースで展示されていた「スマートバンクで働くAI Agentたち」のポスターでした。アプリユーザー向けの「ワンバンフレンズ」(家計を読み解いて気づきを届けるAIアシスタント)、社内メンバー向けの「Ask! ワンバン」(自然言語で社内データを検索・分析する分析AI)、そして開発者向けの「Guardie」(エラーや異常を検知してログ・コード・変更履歴を横断して原因特定を支援する番犬AI)という三本立てで、ユーザー向け / 社内向け / 開発者向けの3レイヤーに対してそれぞれAIエージェントを配置しているのがすごく整理されていて印象的でした。 特にGuardieはSRE視点でめちゃくちゃ刺さりました。「2時間覚悟していた調査が10分で終わった」という社内の声が紹介されていて、これは障害対応におけるMTTR(平均復旧時間)を本質的に短縮しに行っている事例だなと。エラー検知 → ログ・コード・変更履歴を横断した原因特定までをAIに任せる、というのはこれから我々も作っていこうと思っていた仕組みが普通に動いていて、刺激を受けました。 ブース担当の方とは「どこまでをAIに任せて、どこから人間がやるべきか」「誤検知や暴走への安全装置をどう設計しているか」みたいな話までできて、こういう一次情報が聞けるのもRubyKaigiならではでした。 気になった話は、その後のアフターパーティでさらに深掘りできました。資料には載らない現場のリアルな知見が交換される場として、ブース + アフターパーティの組み合わせは、セッションと同じくらい価値があったと感じます。 参加したセッションを日ごとに振り返る ここからは、自分が参加して特に印象に残ったセッションを日ごとに紹介していきます。 Day 1: Exploring RuboCop with MCP (Koichi ITO さん) 1日目に聴いたのが、RuboCopコアチーム・MCP Ruby SDKチームメンバーのKoichi ITOさんによる、RuboCopとMCP(Model Context Protocol)を組み合わせる試みについてのセッションです。 これまでRuboCopは「人間」または「他のプログラム（CIなど）」をきっかけに実行されてきました。そこにAI時代になって、AIエージェントという新しい実行のきっかけが登場した、というのが導入の話です。生成AIとリンター/フォーマッターをどう組み合わせるか、Rubyで実装されたMCPサーバーをエージェントの隣で走らせるとどうなるか、という内容でした。 技術的には、 MCP SDKの構造(サーバーとクライアントそれぞれのSDKがあること) トランスポート層としてstdioとStreamable HTTPの2種類があり、用途で使い分けること HTTPトランスポートではセッション管理が肝になり、Pumaのようなスレッドモデル + シングルプロセス構成だと素直に動くが、複数プロセス・複数ホストに横断するとセッションの保持が難しくなること ただしStateless Mode(stateless: true)を使えば、Pumaの複数ワーカーやUnicornのような複数プロセス構成にも対応できること。ただしこれはリクエストごとに新しいtransportインスタンスが生成されるためMCP-Session-Idを共有できないという制約とのトレードオフであり、「セッション保持を諦める代わりに複数ワーカー/プロセスでもスケールできる」という割り切り あたりが特に勉強になりました。特にセッション管理の話は、MCPサーバーをWebアプリケーションとして本番に乗せようとすると、ロードバランサーやスケールアウトとの兼ね合いが出てくるという点で実践的でした。ステートフル/ステートレスをどう使い分けるかは、これから考えないといけないテーマになりそうです。 セッションの締めくくりで「LLMの確率的な性質を決定的なツールに組み込むことで、これまでの決定的なツールとは違う未来が描ける」という話があって、そこも印象的でした。MCPのサンプリング(サーバーがクライアント経由でLLM補完を要求する仕組み)や、Elicitation(実行中にユーザーへ追加情報を問い合わせる仕組み)といった機能は、ツールの形そのものを変えそうな予感があります。 スライド: https://speakerdeck.com/koic/exploring-rubocop-with-mcp Day 2: Chasing Real-Time Observability for CRuby (Shintaro Otsuka さん) 2日目で一番テンションが上がったのがこのセッション。CRubyの実行状態をリアルタイムに3D可視化するというツール「rrtrace」の話でした。 普通のプロファイラはサンプリングベースで、後から集計して結果を見る形が多いですが、このツールは「いまこの瞬間にCRubyの中で何が起きているか」を、複数スレッドのスタック状態として3次元空間にレンダリングしながら見せる、というアプローチです。デモを見せてもらった時、IRBに入力するたびにスタックが積み上がっていく様子がリアルタイムで見えて、純粋に「すごいものを見ている」という感覚になりました。 技術的なポイントとしては、 計測側のC拡張は軽量に保つ設計で、イベントの収集と転送に特化している イベントはTracePoint API(CALL / RETURN / INTERNAL_GC_ENTER / INTERNAL_GC_EXIT)や内部のスレッドイベント(INTERNAL_THREAD_EVENT、こちらはWindowsでは利用不可)から収集し、timestamp(60bit) + event type(4bit) + method id/thread id(64bit)の合計16バイトの構造体に統一 C拡張(計測側)とビジュアライザプロセスの間はOS管理の共有メモリ上のリングバッファで受け渡し ビジュアライザ側はCRubyのコアを使っていない別プロセスなので、可視化処理が重くてもCRubyの実行を直接ブロックしない スタックシミュレーションが重いため、Parallel Scanアルゴリズムで並列化している という設計でした。ただし、スライドのベンチマーク結果を見ると、rrtrace有効時は関数呼び出しスループットがplain CRubyの17%程度(73,417,127 → 12,760,131 calls/s、約5.9倍遅くなる)、Railsサーバーのrpsもplain CRubyの55%程度(203.19 → 110.84 rps)になるとのことで、計測のオーバーヘッド自体は「小さくない(not small)」とスライドでも明記されていました。TracePointフックのコストが支配的で、ここは今後の課題とのことです。 それでも、「重い処理を別プロセスに全部寄せる」というアーキテクチャの考え方は面白かったです。計測側はできるだけ軽く保って、分析・可視化は別のリソースでやる。この割り切りが設計をシンプルにしていて、きれいだなと思いました。 「現代のマシンは10コア以上あるのが普通で、CRubyが1コアで動くなら残りのコアを観測やビジュアライズに自由に使える」という、リソースの捉え方の話も新鮮でした。GVLがある世界での観測ツールの設計思想として、納得感が強かったです。 スライド: https://speakerdeck.com/whitegreen/chasing-real-time-observability-for-cruby Day 3: The Less-Told Story of Socket Timeouts (Misaki Shioi さん) 3日目に聴いたのがこれ。ソケットライブラリのタイムアウトの歴史と内部実装を、Issue/Commitを参照しながらRuby 4.0までの流れに沿って解説していくセッションでした。タイトルからして気になっていたけど、期待以上の内容でした。 Socket.tcp / TCPSocket.new には、 resolv_timeout (名前解決のタイムアウト) connect_timeout (接続のタイムアウト) そしてRuby 4.0で追加された open_timeout (全体のタイムアウト) の3種類があります。「この3つがなぜ必要で、どういう順番で導入され、どんな歴史的な紆余曲折があったのか」を、Issue/Commitを参照しながら丁寧に追っていく構成でした。 特に印象的だったのが、 まず Socket.tcp に connect_timeout が導入され、続いて Addrinfo.getaddrinfo への timeout および Socket.tcp への resolv_timeout が追加されたこと resolv_timeout と connect_timeout を両方指定しても、全体のタイムアウト時間は制御できない(複数アドレスに対して逐次接続を試行するため、合計時間が想定より長くなりうる) これらの問題を解決するために、Ruby 4.0で全体時間を管理する open_timeout が追加された という話の流れです。普段、HTTPクライアントのopen_timeout/read_timeout/write_timeoutを「だいたいこのくらい」で設定しがちですが、その下のレイヤーでは名前解決と接続が並行で走っていて、タイムアウトの組み合わせによっては想定と全然違う挙動になるということを、改めて意識させられました。 また、歴史的な経緯として特に面白かったのが、名前解決の中断可能化(interruptible)をめぐる話です。 getaddrinfo(3) はブロッキング呼び出しで、Ctrl+C でも中断できないという問題が長年ありました。これを解決するアプローチとして、まず2020年1月に「Addrinfo.getaddrinfo が timeout をサポートする」提案が行われ、そのパッチで Addrinfo.getaddrinfo に timeout、Socket.tcp に resolv_timeout が追加されると同時に、内部的に「GNU拡張のgetaddrinfo_a(3)が利用可能ならそれを使う」実装が入りました(getaddrinfo_a(3)はワーカースレッドで非同期に名前解決を行う仕組み)。その後2020年8月には「Make Socket.getaddrinfo interruptible」がマージされ、Socket.getaddrinfo の内部もこの getaddrinfo_a(3) を使うように利用範囲が拡張、さらに2020年9月には TCPSocket.new にも resolv_timeout / connect_timeout が追加され、名前解決を中断可能にする方向で進められました。 ところがその後、Rails ActiveJobの統合テストが失敗するようになったという報告が入り、調査の結果、fork後の子プロセスでgetaddrinfo_a(3)を呼び出すとハングすることが判明します。getaddrinfo_a(3)は内部で再利用可能なワーカースレッドを保持しているのですが、forkでコピーされる子プロセスにはワーカースレッドが存在しないにもかかわらず内部状態は「ワーカースレッドが待機中」のままになっており、これによってデッドロックが発生する、という仕組みでした。 2ヶ月以上の調査と回避策の検討を経て、最終的にはgetaddrinfo_a(3)の導入自体が撤回され、関連変更もrevertされました。その代わり、後に別アプローチとして「名前解決ごとに専用のpthreadを立ててgetaddrinfo(3)を実行する」方式(mameさん提案、ruby/ruby#8695)が採用され、こちらはrsock_getaddrinfo内に実装されることで、内部的にrsock_getaddrinfoを呼んでいるAddrinfo.getaddrinfoやSocket.getaddrinfoを含む幅広いメソッドで名前解決のブロッキング問題が解消された、という流れです。 外部API連携で「タイムアウトを設定したはずなのにハングする」「connect_timeoutを短くしたのに、複数アドレスがあるホストで合計時間が想定の何倍もかかる」みたいな経験がある人は少なくないと思いますが、まさにあれの背景にある話でした。タイムアウト設計の見直しや、Ruby 4.0以降はopen_timeoutを積極的に使っていくこと、テストでタイムアウト周りの挙動を確認しておくことなど、すぐに持ち帰れる学びがいくつもありました。 スライド: https://speakerdeck.com/coe401_/the-less-told-story-of-socket-timeouts リモートワーク時代の副次効果 もう一つ書いておきたいのが社内メンバーとの関係性の話です。 弊社エンジニアはリモートワーク中心で、普段の業務だと開発チームの全員と毎日話すわけではありません。SlackやZoomでは話すけれど、雑談ベースで「最近どう?」みたいな会話になりにくい人もいます。 それが、RubyKaigiで3日間一緒に過ごすと一気に距離が縮まります。一緒にセッションを聞いて、休憩中に「今のどう思った?」と話して、夜は飲みに行って、移動中に雑談する。この3日間の密度は、リモートでの数ヶ月分のコ
- Ruby
- Rails
- SRE
- 観測
- 生成AI
rubydex MCPでClaude Codeのトークン消費は減るのか？タイミーモノリスRailsで検証した
こんにちは、タイミーのバックエンド/Webフロント基盤チーム マネージャーの新谷（@euglena1215）です。 先日開催された RubyKaigi 2026 に参加してきました。その中で特に気になったのが、Shopify の Alexandre Terrasa さんによる「Blazing-fast Code Indexing for Smarter Ruby Tools」という発表です。 この発表では rubydex という Rust 製の Ruby Code Indexer が紹介されていました。RubyLSP や Tapioca に統合することで最大10倍の高速化と2倍のメモリ削減を実現したという内容でした。また、Ruby ツールのための統一的なコードインデックス基盤としてのビジョンも示されていました。Shopify の Ruby DX チームが9名関わっているということで、Shopify への rubydex への本気度が伺えます。 発表の中では、Experimental ながら MCP サーバー（rubydex-mcp）も提供されていることが紹介されていました。Claude Code などの AI アシスタントからセマンティックにコードベースを検索できるようになっています。 AI Coding Agent にコードベースを調査させると、Grep → Read → また Grep…というループが延々と続き、トークンがみるみる消費されていきます。rubydex-mcp を使えば、クラス定義やリファレンス、継承ツリーといった構造的な情報を、1回の MCP ツール呼び出しで取得できます。そのため、このループを大幅に削減できそうです。 実際にどの程度効果があるのか、タイミーのバックエンドリポジトリで定量的に検証してみました。 rubydex とは rubydex は Shopify が開発した Ruby Code Indexer です。 github.com Rust 製の Indexer がコードベースを解析し、MCP（Model Context Protocol）サーバーとして以下のツールを提供します。 ツール 機能 search_declarations 名前によるファジー検索（クラス、モジュール、メソッド、定数） get_declaration 完全修飾名による定義情報の取得（ドキュメント、祖先チェーン、メンバー） find_constant_references 定数の参照箇所をコードベース全体から検索 get_descendants クラス/モジュールの継承ツリーを取得 get_file_declarations ファイル内の構造一覧 codebase_stats コードベース全体の統計情報 通常、AI Coding Agent がコードベースを調査する際は grep や find でファイルを探し、Read で中身を読み、また grep で次のファイルを探し…というループを繰り返します。rubydex を使うと、このループの多くが1回の MCP ツール呼び出しで完結できる可能性があります。 検証方法 概要 claude -p（Claude Code の非インタラクティブモード）を使い、rubydex あり/なし の2条件で同じプロンプトを実行し、トークン消費量と回答品質を比較しました。 検証環境 ツール：Claude Code CLI (claude -p) モデル：claude-sonnet-4-6 rubydex_mcp バージョン：0.1.0 対象リポジトリ：タイミーのバックエンド（モジュラーモノリス、70パッケージ） 条件の制御 外部要因を排除するため、以下の共通オプションを使用しました。 claude -p "<prompt>" \\ --output-format json \\ # トークン使用量を含む JSON 出力 --model sonnet \\ # モデル固定 --bare \\ # hooks, CLAUDE.md 等を無効化 --strict-mcp-config \\ # .mcp.json を無視し引数の MCP 設定のみ使用 --mcp-config <config> \\ # 条件別の MCP 設定 --tools "Read,Bash,Edit" \\ --no-session-persistence --bare で CLAUDE.md の自動読み込み等の副作用を排除し、--strict-mcp-config により MCP サーバーの有効/無効を制御しています。これにより、2条件間の差は rubydex の有無のみになります。 プロンプト rubydex のツール群が効果を発揮しそうな質問を5種類用意しました。 ID プロンプト class_hierarchy XXXモデルのクラス継承チェーンと、includeしているモジュールの一覧を教えてください。それぞれのモジュールがどのファイルで定義されているかも含めてください。 find_references YYYモデルがコードベース全体でどこから参照されているか調査してください。参照元をコントローラ、モデル、サービス等のカテゴリ別に分類して一覧にしてください。 descendants ApplicationRecordを継承しているクラスの一覧を取得し、packs/ディレクトリ配下のパッケージごとに何個のモデルが存在するか集計してください。上位10パッケージを表示してください。 method_investigation XXXモデルに定義されているpublicインスタンスメソッドのうち、名前に'status'を含むものをすべてリストアップしてください。各メソッドの定義場所（ファイルパスと行番号）と、そのメソッドが何をしているかの簡単な説明を付けてください。 codebase_overview このRailsプロジェクトのpacks/ディレクトリ配下のパッケージ構成を調査してください。各パッケージに含まれるモデル数、主要なクラス名を一覧にし、パッケージ間の依存関係で特に密結合なものがあれば指摘してください。 各条件 × 各プロンプトで5回ずつ、合計50回実行しました。LLM の出力は非決定的なので、複数回実行して平均を取ることでばらつきの影響を軽減しています。 結果 トークン消費量 プロンプト rubydex なし（平均トークン） rubydex あり（平均トークン） 変化率 class_hierarchy 144,076 85,958 -40.3% codebase_overview 1,187,722 664,761 -44.0% descendants 46,501 165,795 +256.5% find_references 770,404 332,369 -56.9% method_investigation 986,840 636,411 -35.5% 5つ中4つのプロンプトで 35〜57% のトークン削減 を達成しました 🎉 コスト・速度 プロンプト コスト変化 実行時間変化 ターン数変化 class_hierarchy -16.7% -48.6% -35.4% codebase_overview -34.3% -19.6% -13.7% descendants +294.6% +261.0% +62.7% find_references -33.5% -19.0% -11.9% method_investigation -30.7% -50.1% -38.1% ターン数（エージェントのツール呼び出し回数）の削減がトークン削減の主因です。rubydex のセマンティック検索が Grep → Read の繰り返しを置き換えることで、エージェントループが短縮されています。 回答品質（LLM-as-a-Judge） トークンが減っても回答品質が下がっては意味がありません。別の Claude セッションを立ち上げ両条件の回答を渡し、正確性・網羅性・有用性の3観点で5点満点のスコアリングを行いました。 プロンプト rubydex なし（平均） rubydex あり（平均） 差分 class_hierarchy 4.33 4.00 -0.33 codebase_overview 4.33 4.00 -0.33 descendants 3.00 4.67 +1.67 find_references 4.00 4.00 0.00 method_investigation 3.33 4.33 +1.00 平均 3.80 4.20 +0.40 回答品質はむしろ改善しています 👏 Judge のコメントから見えた傾向を簡単にまとめます。 rubydex ありで改善した点（正確性） rubydex なしの場合、grep の結果をもとに関連しそうなクラスやメソッドを補足情報として列挙する傾向があった。目視では誤情報は確認できなかったが、裏取りが不十分な状態で情報を出しているため信頼性の判断がしにくい（method_investigation など） rubydex ありではインデックスに基づいた情報を返すため、出力の根拠が明確になっている rubydex なしが勝った点（網羅性・有用性） grep ベースの調査は探索範囲が広いため、rubydex が返さないカテゴリ（Policy、Mailer 等）の参照元も拾えていた（find_references） rubydex なしの回答はファイルのフルパスや構造図を含むなど、開発者がすぐに使える形に整理されている傾向があった（class_hierarchy, codebase_overview） 総じて、rubydex ありは正確性で優位、rubydex なしは網羅性で優位という傾向が見られました。また、いくつかのプロンプトの回答を目視でも確認しましたが、rubydex ありで明らかにおかしな内容を回答しているケースは見られませんでした。 descendants が悪化したケース 唯一、descendants プロンプトではトークンが +256.5% と大幅に悪化しました。 このプロンプトは「ApplicationRecord の子孫クラスをパッケージ別に集計する」という内容です。rubydex の get_descendants ツールは全子孫を忠実に返します。（我々の環境では346クラス）一方、rubydex なしの場合は grep -r "< ApplicationRecord" のような検索で主要なものだけを拾うため、結果的にトークンが少なく済んでいました。 つまり、大量の結果を返すような網羅的な検索では、rubydex がかえってトークンを増やすケースがあります。ただし、品質面では rubydex ありの方が +1.67pt と最も大きく改善しており、正確性とのトレードオフと言えます。 まとめ 5つ中4つのプロンプトで 35〜57% のトークン削減 と 17〜34% のコスト削減 を達成しつつ、回答品質は LLM-as-a-Judge の評価で同等以上（5点満点で 3.80 → 4.20）でした。特に「クラスの参照元を探す」「メソッドの定義場所を調べる」といった構造的な検索タスクで効果が顕著です。 一方、全件取得のような網羅的検索ではトークンが増えるケースもあり、万能ではありません。rubydex が提供するツールの特性を理解した上で導入すると、より効果的に活用できそうです。 また、現状 rubydex-mcp を利用するには Rust ツールチェーン（cargo）が必要で、ソースからのビルドが求められます。開発環境の依存が増えることになるため、チーム全員が使える形に整備するかどうかはもう少し見極めたいところです。とはいえ、トークン35〜57%削減という効果は十分に大きく、rubydex-mcp への期待はとても高まる結果となりました。 検証の制約 今回の検証にはいくつかの制約があります。結果を解釈する際の参考にしてください。 --bare モードでの検証: CLAUDE.md 等が無効化されているため、通常利用時とはベースのトークン消費量が異なります キャッシュの影響: 実行順序や間隔によってキャッシュヒット率が変わるため、コスト比較は参考値です 回答品質の評価: LLM-as-a-Judge による自動評価のみで、正解データとの突合は行っていません プロンプトの偏り: rubydex が得意そうなタスクを選んでいるため、実際の利用での改善幅はこれより小さくなる可能性があります
- Ruby
- Claude Code
- MCP
- 生成AI
Claude Code Skillを使ったベクトルベース推薦の半自動改善
はじめに こんにちは、株式会社タイミーでデータサイエンティストをしている藤井です。 普段は推薦システムの改善を担当しています。 早速ですが、皆さんは推薦モデルの改善実験を月に何本回せていますか？ 仮説を立てて、実装し、実験し、結果を整理し、次を考える。 1サイクル回すだけでも、相応の負荷がかかります。片手間でサイクル数を増やすのは簡単ではありません。 しかし、もし「仮説を立てる」から「結果を整理する」までを AI が担えるとしたら？ 実際に AI の案から改善が生まれています。しかも、人間が担うのは方針の選択、コードレビュー、実験の実行に絞れています。 では、実際にどれだけ回せて、どれだけ当たるのか？ 人間が思いつかない切り口は出てくるのか？ 私たちはそれを確かめるために、Claude Code の Skill 機能を使った半自動の実験プロセスを組み、実際に回してみましたので、紹介したいと思います。 先に結論 AI が出した改善案は 13件で、そのうち実験まで進めたのは 8件でした。 改善が確認できたのは 3件、横ばいが 2件、下落が 3件です。 打率だけを見ると突出して高いわけではありません。 ただ、人間が手を動かしたのは方針の選択、コードレビューと実験の実行だけで、それ以外は AI が担っています。通常業務と並行しながら、このサイクル数を回せたこと自体が、この取り組みのいちばんの成果でした。 モデル改善は 1回ごとの改善幅だけでなく、試行回数を増やせるかどうかが効いてくる領域です。 片手間で回せる仕組みがあれば、改善の累積速度が変わります。 解決したかった課題 AI に推薦モデルの改善案を聞くだけなら、チャットでもできます。 しかし、それを継続的な実験プロセスとして回そうとすると、運用上のボトルネックがいくつか出てきます。 長期記憶がない セッションが切れるたびに AI は過去の実験を忘れます。 同じ失敗を繰り返すリスクがあるだけでなく、過去の失敗を踏まえて次の方向を絞る、改善が出た方向を深掘りするといった、蓄積を活かした提案ができません。 コンテキストの無駄遣い 毎回生のログや大量のファイルを読ませると、トークンを消費するだけで、期待したほど精度も上がりません。 必要な情報を構造化して渡す仕組みがないと、コストだけが膨らみます。 これらを解決するために、Claude Code の Skill 機能を使って半自動の実験プロセスを組みました。 Skill と記憶の設計 このプロセスには 2種類の記憶があります。 knowledge（長期記憶） 過去の実験記録を構造化した Markdown ファイルとして蓄積するフォルダです。 各 Skill はここを読み、過去の試行を把握した状態から動きます。 実験結果はサマリとして圧縮されて書き戻されるので、サイクルを重ねてもトークン消費が膨らみにくい設計です。 scratch（作業記憶） サイクル途中の方針メモや実装の下書きなど、一時的な情報を置く場所です。 長期記憶に残すほどではないが、セッション内では参照したい情報がここに入ります。 また、AI のコンテキストウィンドウが圧縮された場合でも、ファイルとして残っていれば再読み込みで復元できるため、意図しないコンテキスト消失への備えにもなっています。 Skill Skill 自体には、参照すべきファイルパスやテーブル定義、コーディングルールに加えて、実験コストの前提、安全性チェックの観点、実装原則、過去実験との重複を避けるための自問自答リストなどを埋め込んでいます。 これにより、毎回ゼロから指示しなくても、各フェーズで必要な文脈と制約が揃った状態で AI が動けます。 また、長期記憶と作業記憶はリポジトリ上に存在するため、Cursor など別の AI ツールからも同じ情報を参照でき、Claude Code の提案を独立に検証することも可能です。 半自動実験プロセスの仕組み このプロセスは、上記の Skill と記憶の仕組みを使って構築しています。 1サイクルの流れ AI がテーブル定義やコーディングルールを確認する AI が過去の実験記録を読み、現状を把握する AI が次に試す改善案を複数提案する 人間が方針を選ぶ AI が実装する AI が変更の安全性を確認する AI が実施予定の内容を記録する 人間が実験を実行する AI が結果を記録に反映する 人間が手を動かすのは、方針の選択、コードレビュー、実験の実行だけです。 定義の確認、過去実験の整理、提案、実装、安全性チェック、記録は主に AI が担います。 実験結果 個別の実験内容の詳細は割愛し、ここでは改善幅の傾向のみを共有します。 13件の提案のうち、実験に進めなかった 5件を除いた 8件の結果です。 実験 主要な機械学習指標の改善幅（複数指標の範囲） A +2〜+7% B +0.5〜+3% C +1〜+3% D ±2%以内 E ±2%以内 F -3〜-7% G -3〜-6% H -35〜-20% 学び 以下はあくまで運用を通じた感想であり、厳密に検証された結論ではありません。 提案の方向性 変更が小さくなりがちな傾向がある。 AI に自走させると、実験結果の正確性を担保しやすい方向、つまり対照実験がしやすい最小限の変更に寄りやすい傾向がありました。 指示を入れると質が変わる。 「小さい改善ではなく構造ごと変える改善を考えてほしい」と明示的に伝えたところ、論文の知識を参照した鋭い提案が複数出てきました。AI の提案の質は、渡す制約や方向付けに強く依存します。 既存手法の非自明な応用が出てくる。 たとえば、DIN（Deep Interest Network）の target-aware attention を two-tower モデルに持ち込む提案がありました。two-tower では推論時に候補アイテムが不明なためそのまま適用できませんが、AI は「学習時だけ正例を attention query として使い、推論時はフォールバックする」という変形を考えました。この切り口自体、推薦チーム内では出ていなかったもので私たちには非自明でした。当然、学習と推論の不一致（train-serve skew）がリスクになりますが、提案自体にそのリスクと失敗した場合に何がわかるかが含まれていました。成功の保証はなく、失敗する可能性は高そうですが、失敗しても学びが得られる実験設計になっています。また、仮にこの方式がそのまま機能しなくても、事前学習フェーズでのみ target-aware に学習させるといった派生が考えられ、アイデアの種として意味のある提案でした。 壁打ち相手としては十分実用的だった。 厳密な比較をしたわけではありませんが、少なくとも今回の運用では、AI が出す提案は人間の壁打ち相手として十分実用的だと感じました。場面によっては、自分たちだけではすぐに出なかった切り口が出てくることもありました。 蓄積と学習 最も鋭い提案は最後に出てきた。 偶然の可能性はありますが、サイクルを重ねて過去実験の蓄積が増えたタイミングで、最も構造的な提案が出ています。蓄積が提案の質に寄与している可能性は否定できません。 過去の失敗を踏まえた推論が出てくる。 AI が提案を出す際に、「過去にこの実験は失敗したので、こういう可能性がある。だからこちらの方向を試してみましょう」といった推論のログを出してくることがよくありました。蓄積された記憶を参照しながら提案理由を組み立てている様子が見て取れます。 運用コスト 人間の作業時間の大半はバグ対応。 実験が問題なく動く回では、人間の仕事は方針を選び、コードをレビューし、実験を実行することに絞られます。一方でバグが出ると調査・修正・再実行に手を取られ、体感で人間の作業時間の 8〜9割はバグ起因でした。逆にいえば、バグが出た回を無理に立て直さず次の実験に進めば、手数自体はさらに増やせる可能性があります。実装にバグが出た実験案も、提案自体は knowledge に記録しておけば、AI のコーディング能力が向上した時点で低コストに再挑戦できます。 現時点でまだ分かっていないこと サンプルサイズが不足している。 この半自動改善プロセスを運用し始めたのは最近であり、実験数は 8 件です。ここから得られた傾向が一般化できるかは、まだわかりません。 長期記憶の効果は未検証。 長期記憶なしのフローと比較した実験は行っていません。蓄積が提案の質に寄与している可能性は示唆されますが、長期記憶が本当に効いているのか、それとも同じ品質の提案が記憶なしでも出るのかは、現時点では検証できていません。 まとめ このプロセスの価値は、AI が良い改善案を出すことそのものではなく、試行の回転数を上げられることにあります。 13件の提案から 8件を実験し、3件の改善を得る。個々の実験の改善幅は小さくても、改善を積み重ねれば累積的な効果は大きくなります。 つまり、モデル改善は打率ではなく打席数が効いてくる可能性が高い。この取り組みの価値は、試行錯誤を片手間でも継続して回せるようになる点にあります。 長期記憶の効果や AI の提案精度については、まだ言い切れることは多くありません。 ただ、少なくとも「AI に改善案を出させて回す」というサイクル自体は、実用的に機能しています。今後はサンプルを増やしながら、このプロセス自体の改善も続けていきます。 こうした推薦改善の試行錯誤や、評価・運用の仕組みづくりに興味がある方は、ぜひ以下もご覧ください。 We’re hiring! 現在、タイミーではデータサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ データ | 採用情報 |株式会社タイミー また、気軽な雰囲気でのカジュアル面談も随時行っておりますので、ぜひお気軽にエントリーしてください。↓ hrmos.co hrmos.co hrmos.co Reference Skillを作成するにあたっては、Y Combinator の Garry Tan さんによる gstack リポジトリ（MITライセンス）を大いに参考にしました。 GitHub - garrytan/gstack: Use Garry Tan's exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA · GitHub なお、本記事を書いている途中に、AI に継続的に作業させる方向の動きがいくつか出ていました。今回の取り組みと直接の関係はありませんが、同じ方向性の事例としてメモ的に置いておきます。 Automated Alignment Researchers: Using large language models to scale scalable oversight（Anthropic, 2026/04/14）― 9 体の Claude Opus 4.6 を自律的なアライメント研究者として走らせた実験。複数 AI に役割分担させて探索を回す、という方向の一例。 Introducing routines in Claude Code（Anthropic, 2026/04/14）― Claude Code にスケジュール実行や webhook トリガーで動かせる routines が追加。今回は Skill で手動起動していますが、こうした仕組みに載せれば定期的な提案・記録反映まで自動化できそうです。
- 生成AI
- 推薦システム
- MLOps
「理解してから作る」から「作りながら理解する」へ ― 入社3ヶ月、AIが変えた学習の順序
はじめに こんにちは。タイミー プロダクトエンジニアの津守です。今年1月にタイミーに入社し、気づけば早3ヶ月が経ちました。 この記事では、入社して数ヶ月働いて感じた「AIツールがオンボーディングプロセスをどう変えたか」という体験をまとめます。技術的な深掘りというより、新しい環境に飛び込んだエンジニアの個人的な気づきとして読んでもらえると嬉しいです。 従来のオンボーディングプロセスのイメージ 新しい会社に入ったとき、多くのエンジニアは最初の数週間を ドキュメントを読む。コードベースを読む。アーキテクチャを把握する。チームの開発スタイルを理解する。そして、ある程度理解できたと感じてから、ようやく手を動かし始める。 というような順序で過ごしてきたと思います。 言ってみれば「インプット先行」の学習スタイルです。この期間は"情報を受け取る期間"と暗黙的に認識されていることが多く、アウトプットは後回しになりがちでした。チームへの貢献よりも、まず「追いつくこと」が優先されるイメージです。 AI活用によって感じた変化 入社して最も強く感じたのは、この「順序」が変わったということです。 AIツールを使うことで、コードベースへの理解が浅い段階でも、まず動くものを作ることが現実的になりました。実際Cursor や Claude Code を主体に実装を進めると、知識のギャップをAIがある程度埋めてくれます。おかげで、入社初期からチームメンバーやステークホルダーのレビューやフィードバックを素早く受け取ることができました。 実際、チームメンバーやステークホルダーからのフィードバックやレビューには、基礎的な知識だけでなく、「タイミーではこうやってる」といった暗黙のコンテキストが含まれており、ドキュメントから得られる知識に加えて、より多くの背景情報を得られる場面があります。 開発アプローチとして広く受け入れられているアジャイルでは、「いかに早くステークホルダーがレビューできる状態を作るか」が重要な論点のひとつです。これは、個人が環境に適応するうえでも重要な要件だと思います。完璧な理解を待ってから動くのではなく、まず動くものを見せてフィードバックをもらう。そのサイクルを素早く回すことが、結果的に最も効率的な学習を生み出し、属する組織で求められる行動を起こせるようになるために重要と考えています。 適切に学習サイクルが回るための条件 ただ、このアウトプット先行の学習サイクルが機能するには、2つの環境が整っている必要があると感じました。どちらもAIツールの登場で新たに生まれた課題ではなく、組織の開発体験として元々重要だったものですが、AIツールの発達によってその重要性はさらに増しています。 1. AIが適切なアウトプットを出せる環境 AIが出すアウトプットの質は与えるコンテキストに大きく左右されます。学習サイクルの中でフィードバックを通じて暗黙のコンテキストを受け取れるとはいえ、そもそも明示的に言語化されているほうが望ましく、AIのアウトプットの精度も上がります。 実際、タイミーではバックエンド開発Handbookを通じて、開発プロセスを明示的に言語化する動きがあります。設計・実装・運用にまたがるガイドラインが体系的にまとめられており、さらにそれがAIエージェントのスキルとして提供されています（詳しくは新谷さんの記事「バックエンド開発Handbookを届けるために ― AI時代の知の高速道路を敷く」をご覧ください）。 Handbookが生まれた背景のひとつには、メンバーの増加やAIツールの進化により、バックエンド以外のエンジニアが越境してコードを書く機会が増えたという事情があります。ただ実際に使ってみて感じたのは、暗黙知をまだ何も持っていない入社直後のメンバーにこそ、そのインパクトが大きいということです。「そもそも何を知らないかもわからない」状態でも、AIがHandbookに沿ったアウトプットを出してくれることは、単なる品質担保以上の意味を持ちます。 自分がHandbookを意識していなくても、AIがガイドラインに沿った設計や実装を提案してくれる——「気づいたらタイミー流の書き方になっていた」という感覚は、入社して間もない時期にとても心強いものでした。 2. フィードバックをもらえる環境・体制 もうひとつの前提条件は、フィードバックの環境です。どんなに早くアウトプットを出しても、適切なフィードバックが返ってこなければ学習サイクルは止まります。 この3ヶ月間は、チームメンバーやステークホルダーから丁寧なフィードバックをもらえる環境にあり、そのおかげで学習が加速しました。特に、PRベースのコードレビューは厳密に行われており、そこでの指摘やディスカッションがとても多くの学びになりました。 ただ、3ヶ月を通じて感じたのは、現状ではフィードバックの質が運用や状況によってばらつきが出やすい状態にあるということです。体制として担保されているというよりは、チームメンバーの意識や余裕に左右される面があり、持続的に機能させるには仕組みとしての設計が必要だと感じています。 もうひとつ、AIがアウトプットを加速させることで生まれるトレードオフも見えてきました。学ぶ側が早く動けるようになった分、レビューする側が見るべきPRの量も増えます。学習サイクルが速くなった恩恵が、レビュワーの負荷という形で偏在してしまうわけです。 また、PRベースのレビューは厳密に行われている一方で、暗黙知やコンテキストを深く共有したうえでのフィードバックを、どう生み出すかという問いも残ります。これらに対してモブプログラミングやペアプログラミングのような形式は有効な解のひとつだと思っていて、後からまとめてレビューするコストを分散させながら、よりリッチなフィードバックを生みやすい構造だと感じています。 持続的に相互フィードバックが行われる開発体制をどう設計するか——これはまだ答えの出ていない問いですが、AIが学習サイクルを高速化させるほど、フィードバックを循環させる体制の重要性は増していくと感じています。 おわりに 3ヶ月を振り返ると、AIは入社直後の学習の「量」を変えたのではなく、「順序」を変えた、というのが一番しっくりくる表現です。 以前なら「理解してから作る」だったものが、「作りながら理解する」に変わりました。この変化は、入社直後という時期をより能動的に過ごす後押しをしてくれると感じています。 ただし、そのサイクルを本当に機能させるには、AIが適切なアウトプットを出せる環境と、フィードバックを届ける体制という、人間側の設計が不可欠だと感じました。Handbookをはじめとした環境を整えてくれたチームには、改めて感謝しています。 同じように新しい環境に飛び込んでいる方や、新しいメンバーを迎える立場の方に、少しでも参考になれば嬉しいです。
- 生成AI
- オンボーディング
- 開発プロセス
DAのABテスト業務をAIで加速する ── 実験設計レビューの自動化
はじめに こんにちは。タイミーのデータアナリティクス部でデータアナリストをしているishidaです。普段は、タイミーのプロダクトに関する分析業務に従事しています。 タイミーのデータアナリスト（DA）チームでは、プロダクト施策の効果検証としてABテストを頻繁に実施しています。ABテストの業務は、大きく「実験設計」「クエリ作成」「可視化・レポート」の3工程に分かれますが、これらすべてをDAが担当しています。 施策の数が増えるにつれ、ABテストの “回転数” がボトルネックになりつつありました。そこで私たちは Claude / Cursor を活用し、まず実験設計のレビューを自動化する取り組みを始めました。 本記事では、その仕組みと設計思想をご紹介します。 なお、タイミーにおけるABテストは「① 実験設計 → ② クエリ作成 → ③ 可視化・レポート」の3ステップで進みます。本記事で扱うのは、①の実験設計レビューの自動化です。 1. 実験設計レビューの自動化 課題：レビューの属人化 ABテストの実験設計にはいくつかの重要なチェックポイントがあります。 チェックポイント 確認内容 SUTVA TG/CG間でリソースの奪い合いが起きないか Unit Alignment ランダマイズ単位とメトリクス集計単位は一致しているか SRM サンプル比率のミスマッチを検知できる設計か Novelty/Primacy 経時的変化を考慮した期間設定か Multiple Testing 多重比較の問題を制御できているか Guardrail 副作用を監視するガードレール指標は定義されているか これらのレビューは経験や前提知識によって見落としが生じやすく、属人化しがちでした。 解決策：AIによるチェックリストレビュー 私たちは、実験設計チェックリストを Claude / Cursor のコンテキストに含め、実験設計ドキュメントを入力するとチェックポイントごとにレビューが返るようにしました。 具体的には、以下の2種類のファイルをプロジェクトのルールとして設定し、AIに読み込ませています。 実験設計ドキュメントのテンプレート: テスト概要・テスト設計・評価指標などの項目が定義されたMarkdown チェックポイント定義: 6つの観点それぞれについて「判定の観点」「よくある違反例」「対応方針」を構造化したドキュメント AIレビューの出力イメージ ## CP1: SUTVA ⚠️ リスクあり -TG/CG間でリソースの奪い合いが発生する可能性があります -推奨: クラスタ単位でのランダマイズを検討してください ## CP2: Unit Alignment ✅ 問題なし -ランダマイズ単位と集計単位が一致しています ## CP3: SRM ✅ 設計済み -Debugging Metric として介入の影響を受けない指標を設定 -カイ二乗検定を実験開始時に実行する設計 ... ポイント：AIレビューは「最低限の品質保証」として位置づける 重要なのは、AIレビューを 人間のレビューの代替 としてではなく、最低限実行されるべきレビュー として位置づけていることです。 AIレビュー = チェックリストの網羅的な確認（漏れ防止） 人間レビュー = ビジネスコンテキストを踏まえた判断（例：この施策ならSUTVA違反は許容範囲か） これにより、レビュー依頼を受けたDAは「AIが見つけた問題点」を起点に議論できます。 学び AIレビューは「ゲートキーパー」ではなく「下書き」 AIレビューの結果を鵜呑みにせず、「少なくともこのレベルのレビューは済んでいる」という 品質の下限保証 として使っています。最終判断は必ず人間が行います。 この位置づけにしたことで、「AIに任せて大丈夫か」という心理的なハードルも下がります。 We’re Hiring! 私たちは、ともに働くメンバーを募集しています！！ データアナリストの募集ページはこちら カジュアル面談も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。
- 生成AI
- データ分析
- ABテスト
NLP2026現地参加レポート : LLM評価・品質保証の実践知
はじめに こんにちは、株式会社タイミーでプロダクトAIエンジニアとして働いている貝出です。直近は、タイミーの求人内容などのコンテンツモデレーションにLLMを利用した、システム開発や性能改善を行っています。 2026年3月9日（月）〜3月13日（金）に開催された「言語処理学会第32回年次大会（NLP2026）」に、今年は初めて現地参加しました。大会2日目は記録的な大雪に見舞われ、会場にたどり着くだけでひと苦労でしたが、それでも現地ならではの熱気は格別で、ポスター発表や他社エンジニアとの立ち話など、オンラインでは得られない学びが随所にありました。 NLP2026では多くの発表がありましたが、本記事ではLLMの評価・品質保証・安全性に関する発表に絞って紹介します。単に発表内容を紹介するだけでなく、実際のプロダクト開発や評価データ設計にどう接続できるかという観点で読み解きます。研究と実務をつなぐ視点として、評価設計やベンチマーク整備のヒントになれば幸いです。 大会2日目の大雪 言語処理学会年次大会について 会場内看板 anlp.jp 言語処理学会年次大会は言語処理学会が主催する学術会議であり、国内における言語処理の研究成果発表の場として最大規模のイベントです。 今年で第32回を迎え、発表件数は797件、最終日までの参加者数は2,316人と過去最大を記録しました。年々規模が拡大しており、NLP分野への関心の高さが伺えます。LLMの登場により一時は「研究することがなくなるのでは？」という懸念もあり、2023年には「ChatGPTで自然言語処理は終わるのか」というテーマでパネルディスカッションが行われたこともありました。しかしその懸念に反して、近年は「安全にLLMをどう使うか」「LLMの挙動をどう解釈するか」といった観点の研究が増えてきており、まだまだ研究題材は尽きない印象です。 なお、発表論文は言語処理学会のWebページで公開されているため、当日参加できなかった方でも閲覧可能です。 私自身も今回、社会人大学院での研究内容をもとにポスター発表を行いました。多くの方と議論でき、大変刺激になりました。合計90分間、ポスターの前で参加者に説明したり質問に答えたりと、途中で酸欠になりそうなほど白熱したセッションでしたが、ありがたいことにスポンサー賞としてレトリバ賞をいただくことができ、とても良い思い出になりました。 興味深かった発表 普段の業務では、「LLMを活用してビジネス課題をいかに解決するか」という問いと同時に、「LLMの出力をどう評価するか」「そのための評価データをどう設計するか」といった問題にも日々向き合っています。今回は、こうしたLLMの評価・品質保証・安全性というテーマを軸に、特に業務課題と関連の深かった4件の発表を取り上げます。 チュートリアル３：信頼できるAIへのソフトウェア工学からのアプローチ：「品質」技術の動向と課題 発表内容 本チュートリアルでは、ソフトウェア工学の観点から「信頼できるAI」の品質保証技術について解説されました。 まず、品質は「複数の特性から構成され、様々なニーズや要求を満たすこと」と定義されると説明されていました。また、品質には、対象システム自体に対して測るもの（例: レイテンシなど）と、実際にシステムを利用する段階で計測可能なもの（例: 顧客満足度など）の2種類が存在するとのことでしたした。そのうえで、価値やリスクはシステム全体で評価されるべきであり、AI部品ごとに適切に評価することの重要性が強調されていました。 AIの品質保証に関するガイドラインとしては、AIQMやQA4AIなどが紹介されました。これらのガイドラインでは、「AIパフォーマンス」「リスク回避性」「公平性」といった機械学習に特有の品質や、それを評価するための「被覆性（事例パターンが網羅的に含まれているか）」や「均一性（実際の母集団の分布に近いか）」などのデータセットにおける品質の重要性も整理されていました。 一方で、LLMの普及に伴い、入出力が非定型になってタスクの境界が曖昧になっています。また、正解が一意に決めづらくなったことで、評価・改善の難易度と工数が増大しているという現場課題も指摘されていました。LLMの手軽さからシステム開発自体は進めやすくなった反面、活動の重心は「開発」から「評価・改善」へと移行しています。しかし、「開発」と違って「評価・改善」では、工数換算をする意識が低くなりがちです。そのため、評価・改善の継続的サイクルを定着させることが困難だという課題が挙げられていました。 また、モデル評価の文脈としてソフトウェア工学における「自動テスト生成」の手法が紹介されました。代表的なものの一つが、テスト生成を最適化問題に帰着させてメタヒューリスティックに解く Search-Based Testing（探索的テスト） です。たとえば自動運転の分野では、この手法を用いることで事故が起きやすい弱点領域を探索したり、モデルの性能限界の境界を可視化したりすることが可能になっています。 最後に、言語モデルが今後ロボットや自動運転など物理世界にも応用されていく中で、よりリスクベースの評価が必要になるという展望が示されました。 感想 「開発」から「評価・改善」にエンジニアの工数の主なタスクが移り変わっているというところも、たしかになと思わずうなずいてしまいました。今後は「モデル開発」よりも、どう評価するか、どうデータセットを作るのかにML/AIエンジニアの重心が移るのかもしれません。 また、Search-Based Testingは初めて聞いたのですが、LLM審査のコンテキストに当てはめると、微妙な偽陽性・偽陰性を生む「境界線にある言い回し」を自動探索し、モデルやプロンプトの弱点を事前に洗い出す、といった使い方ができそうだと感じました。 [B2-1] chakoshi Fine: 多層防御に基づくLLM向けガードレールの設計と実装および評価 発表内容 本研究は、生成AIの安全な業務利用のためのガードレール構築に関するものです。前年のNLP2025で発表された chakoshi の発展系にあたります。 chakoshi では単一モデルに複数の役割を担わせていたため、あるリスクの検知精度を伸ばそうとすると別の精度が低下しやすいという構造的な制約が課題でした。本研究ではこの課題に対し、リスクごとに特化した5つの独立した防御機構を段階的かつ選択的に適用する多層アーキテクチャ chakoshi Fine を提案しています。複数のコンポーネントに分割したパイプライン構造にすることで、単一モデルでの全体最適化を避け、各ポリシーが専門性を高めつつ相互に弱点を補完する設計になっています。この結果、既存の商用ガードレールサービスと比較して高い検知精度を達成していました。 さらに、擬似業務タスクを通じて実際の業務を想定した有用性評価も行われています。ガードレール導入の有無が人間のタスク正答率や平均所要時間に統計的な差を与えなかったという結果が示されており、過剰検知によるユーザー体験の悪化や業務効率の低下を防ぎつつ、パスワード漏洩のような不正な入出力に対しては、98%の確率で遮断できていました。 感想 ガードレールを利用する際は、どうしても使用感が気になります。本研究が、検知精度だけでなく処理速度や「ユーザー体験を損なわないか」という点まで踏み込んで評価してくれているのは、実務側としてありがたいです。また、4B程度の軽量なLLMでもガードレールのスコープによっては、ある程度検知精度が担保できるという点も個人的には発見でした。 [Q4-3] LegalRikai: Open Benchmark - 法務ドメインの日本語ベンチマーク 発表内容 本研究は、実際の法務業務のワークフローを模した、法務ドメインにおける新たな日本語ベンチマーク LegalRikai を提案しています。 このデータセットは、弁護士の監修のもとで人手による精緻なアノテーションが行われており、高コストではあるものの高品質な内容となっています。法令改正の要約や指示に基づく契約書編集など、実際の法務業務を模した4つの複雑なタスクから構成されており、法務文書特有の長文インプットに対して構造化された出力を求める設計になっています。 評価においては、単一の指標ではなく、指示の遵守度・契約書全体の構造の一貫性・不要な変更の有無など、実務に即した複数の観点から評価する尺度が採用されています。正解データの作成から評価に至るまで専門家が深く関与しているため、データ数は各タスク25件と少数ながら厳選された内容です。さらに、評価者間の一致度（Cohen の κ スコア）を計測することで、アノテーションの妥当性やガイドラインの信頼性を担保しており、LLMの法務実務における実力を正確に測るための堅牢な基盤を提供しています。データセットは公開されており、論文内のリンクから参照可能です。 感想 「専門ドメインのベンチマークをどう設計するか」という観点で非常に参考になる研究でした。特に、評価観点を実務の複数軸に分解している設計や、少数でも質を担保するためにアノテーターの一致度を計測している点は、評価データを整備する際にも応用できそうです。「データ数は少なくても、専門家による厳密な設計で品質を担保する」というアプローチは、社内の評価データ構築においても積極的に取り入れたい考え方です。 [B8-13] 医療系対話AIにおける評価基準の策定と自動評価手法の比較検証 発表内容 本研究は、日本の医療事情に即した独自の評価データセットを構築し、医療系対話AIにおける「LLM-as-a-Judge」を用いた3つの自動評価手法を比較検証したものです。具体的には以下の3手法が比較されました。 総合評点方式：詳細なガイドラインに基づき1〜10点でスコア化 総合評点方式（簡易版）：評価の観点のみを提示 項目別評価方式（チェックリスト形式）：具体的な評価項目に対してTrue/False判定を行い加重スコア化 実験の結果、モデル間の全体的な性能差を識別する能力においては、意外にも詳細な指示を与えない「総合評点方式（簡易版）」が最も優れていることが分かりました。一方で、個別の会話に対する評価の「一貫性」や、医学的に危険な回答を確実に除外するといった「説明可能性・安全性」の観点では、「項目別評価方式」が最も優れていることが示されています。目的（モデル全体の性能比較か、個別回答の厳密な品質保証か）に応じて適切な評価アプローチを使い分ける重要性が裏付けられた研究です。 感想 「簡易版のほうがモデル間の性能差を検出しやすい」という結果は、直感に反していて面白かったです。評価指標によっては、どの形式の評価にするかを実施前に比較しておくといいのかもしれません。 「項目別評価のルーブリック設計には専門家のコストがかかる」という点は、スポンサーブースで他社のエンジニアと話していたときにも、全く同じ悩みとして挙がっていました。「評価の精度を上げたいが、設計コストをどこまでかけられるか」というトレードオフは、ドメインを問わず共通の課題なのだと改めて実感しました。スモールスタートする場合は「まず簡易版で全体傾向を把握し、問題が疑われる領域だけ項目別で深掘りする」という使い分けが現実的かもしれません。 おわりに 今回取り上げた4つの発表は、主に評価、評価データ、そして安全性に関するものでした。LLMの能力が飛躍的に向上した今、「人間の期待通りに生成できているのか」「安全にLLMを利用できているのか」という問いへの関心はますます高まっており、研究も着実に進んでいる印象です。 NLP2026では今回紹介しきれなかった魅力的な研究も数多くあり、この領域の裾野の広がりを実感しました。タイミーを安心・安全なプラットフォームとして維持するためのLLM活用について、多くの示唆を持ち帰ることができた大会でした。 We’re hiring! 現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ product-recruit.timee.co.jp また、気軽な雰囲気でのカジュアル面談も随時行っておりますので、ぜひお気軽にエントリーしてください。↓ hrmos.co hrmos.co hrmos.co
- 生成AI
- LLM
- 機械学習
- 品質保証
3日間のUnicorn Gymが1ヶ月で組織を変えた —— データで見るAI-DLC導入の波及効果
こんにちは。タイミーでPlatform Engineeringグループのマネージャーを務める橋本（@kaz-under-the-bridge）です。 2026年1月26日〜28日の3日間、AWS様と共同で AI-DLC Unicorn Gym（以下UG）を開催しました。私はタイミー側のカウンターパートとして、企画・準備から当日の運営、振り返りまでを担当しました。 AI-DLC（AI-Driven Development Life Cycle）は、要件定義からリリースまでの開発プロセス全体にAIを深く組み込むことで、従来のアジャイル開発を大幅に加速するアプローチです。Unicorn Gymは、AI-DLCを実際のプロダクト開発テーマで短期集中的に実践できる体験的な取り組みです。AWS様の支援のもと、国内でも多くの企業が参加・開催しています。 タイミーでは11チーム・約69名が参加し、各チームが実際にプロダクション搭載予定の機能をテーマにAI-DLCを実践しました。当日の実施内容、各チームの成果、参加者の声についてはAWS様の執筆レポートに詳しく書かれていますので、ぜひそちらもご覧ください。 株式会社タイミー様の AI-DLC Unicorn Gym 開催レポート: 全社横断で挑む開発生産性の変革 本記事では、UG当日の内容ではなく 「UGの後、組織に何が起きたのか」 を、実施から約1ヶ月時点のデータを交えてレポートします。 個の生産性改善から、組織のムーブメントへ UG以前、タイミーにおけるAIツールの活用はエンジニアが個人個人で使いこなす 「個の生産性改善」 が主たるものでした。各自がCopilotやCursor、Claude Codeなどを独自に活用し、それぞれのやり方で生産性を高めていました。 それがUGを経て、チーム・組織単位でCoding Agentを使いこなす方向に大きくシフトしたと見ています。以下、データでその変化を追っていきます。 Claude Code利用者数の変化 タイミーのプロダクト開発組織では、以下のCoding Agentを利用しており、申請制で自由に使えるようにしています。 利用しているCodingAgent 私は上記ツール群の管理者でもあります。UG後に最初に気づいた変化は Claude Codeの利用申請が明らかに増えた ことでした。 CCシート数推移 UG前は週1〜2名ペースだったシート追加が、UG後は 週8名と約5倍に加速 しています。1ヶ月で85名から118名へ、1.4倍に拡大しました。 Skills/Plugin整備の加速 —— 組織的なAI活用への転換 利用者数の増加だけでなく、GitHubリポジトリ上のAI-DLC関連アクティビティ にも顕著な変化が見られました。 ここで言う「Skills」とは、Claude CodeのSkills機能を指します。指示・テンプレート・スクリプトをパッケージ化してリポジトリに配置すると、Claudeが会話内容に応じて自動で発見・ロードする仕組みです。たとえば「PRレビューの観点」や「テスト設計の手順」をSkillとして定義しておけば、チームの誰がClaude Codeを使っても同じ品質で作業できるようになります。 指標 UG前 UG後（1ヶ月時点） 変化 CLAUDE.md保有リポジトリ 3 37 +34 Skills保有リポジトリ 1 11 +10 Skills総数 3 78 +75 UG前、Skillsを持つリポジトリは たった1つで3 Skillsだけでした。それがUG後は 11リポジトリ・78 Skills に急拡大しています。 CLAUDE.md（Claude Codeのプロジェクト設定ファイル）を持つリポジトリも3から37へ。これは「AIにプロジェクトの文脈を伝える」取り組みが組織全体に広がりつつあると見ています。 つまり、個人がAIツールを使いこなすフェーズから、チームがSkillsを整備して組織的にAIを活用するフェーズ へ移行していると見ています。 エンジニア以外の職種への広がり この組織的なAI活用の進展を補強するデータとして、利用者の職種構成の変化 があります。 プロダクト組織の人数と照らし合わせると、エンジニアのClaude Code利用率はUG前の約70%からUG後 約89% へ上昇し、ほぼ全員が使っている状態になっています。一方、エンジニア以外の方の利用率はUG前の7%からUG後 約27% へ。まだ道半ばではありますが、エンジニア以外の方もClaude Codeを使い始める段階に来ていると言えます。 UG前後でのCC普及率比較 Skillsの整備によってチーム単位でのAI活用基盤が整ったことで、PdMやデザイナーにとってもCoding Agentが使える環境が生まれつつあると見ています。 何が変わったのか —— 代表的な変化のパターン Skillsの急増を支える具体的な動きを、いくつかのパターンに分類して紹介します。 既存リポジトリのAI-DLC駆動への変容 最も大きな変化を見せたのが、UG参加チームの既存プロダクトリポジトリです。UG前はCursorのコマンド設定がある程度だったリポジトリが、UG後には 23のSkillsと独自のAI-DLCフレームワーク を構築するまでに至りました。 コミットの中身を見ると、UG後は、Skillsの追加やAI-DLCフレームワークの構築、Inceptionの成果物（ユーザーストーリー、受け入れ基準、コンテキストマップ等）といった AI-DLCに関するコミットが大きな割合を占める ようになっています。これにより、個人がAIツールを使う段階から、チーム全体でAI-DLCのInception（要件定義）フェーズを実践し、プロダクト機能の設計にAIを組み込む段階へとシフトしたと見ています。 このチームの取り組みについては以下の記事もご覧ください。 失敗から学んだ仕様駆動開発――チームの暗黙知を形式知化した1ヶ月の実践と次の課題 ゼロからのAI-DLCワークスペース構築 UGをきっかけに、新たにリポジトリを立ち上げたチームも複数あります。UG初日に作成されたワークスペースの中には、backend・iOS・Androidなどのドメイン別Skills（7つ）や、inception・constructionといったAI-DLCのフェーズ別コマンド体系が整備され、今もSkillsやテンプレートの追加・改善を重ねているものもあります。 Knowledge-as-Code 特筆すべきは、ハンドブック（社内ナレッジ）をAI Skillsとしてコード化 する取り組みです。バックエンド開発のベストプラクティス、API設計指針、テスト設計、法的考慮事項の参照といった組織知を22のSkillsとして整備し、Claude Code Pluginとして提供しています。さらに、Cursor向けへの変換パイプラインも構築されており、複数のCodingAgentで活用できる仕組みになっています。 これは単なるツール活用を超えた、組織の暗黙知をAIが活用可能な形式知に変換する 取り組みと言えます。 こちらの取り組みについては以下の記事もご覧ください。 バックエンド開発Handbookを届けるために ― AI時代の知の高速道路を敷く Claude Skill を Cursor の Agent Skill として使えるようにした話 UG中の学びの即時適用 既にClaude Codeを活用していたチームの中には、UG 3日目（1/28）に新しいSkillsを追加 した事例もあります。agentsやcommandsで安定運用していた状態から、UGでSkillsという新しいレイヤーを学び、その場で自チームのリポジトリに適用しているケースもありました。 UG非参加チームへの波及 興味深いのは、UGに参加していないチームにもAI-DLCの動きが広がっている ことです。UG非参加のチームが8つのSkills（ワークフロー自動化特化）を持つリポジトリを立ち上げるなど、UG参加チームの取り組みが周囲に波及しています。 これらの変化をどう見るか 数字を俯瞰すると、UGを境に起きた変化の本質は 「個のAI活用」から「組織のAI-DLC実践」へのシフト だと考えています。 利用者の拡大: 週1.5名 → 週8名（5倍加速）、エンジニア以外の職種にも拡大 Skillsの整備: 1リポジトリ3 Skills → 11リポジトリ78 Skills（個人の効率化ではなく、チームの知識をAIに教える方向） チームを超えた波及: UG非参加チームにも動きが広がっている UGはあくまできっかけであり、3日間のイベントです。しかし、そのきっかけが 1ヶ月で組織全体の行動パターンを変えた ことは、データが示しているのではないかと思います。 おわりに 現時点では、ムーブメントはまだ初速の段階です。ただ、この動きは定着していくだろうと見ています。次にやるべきことは、AIを安全に使うためのセキュリティ面の整備と、より大きなうねりにしていくためのブロッカーを一つひとつ排除することだと考えています。 もちろん、本記事で取り上げたのはClaude Codeを中心とした変化に限っています。CursorやCopilotを活用して成果を出しているケースも多くあり、組織全体のAI活用はさらに広がりを見せています。 UG開催を検討されている方へ 最後に、主催者としてひとこと。UGの開催にあたって最初に立ちはだかる壁は、「参加者が乗り気になるかどうか」かもしれません。3日間という拘束時間の長さ、AI-DLCという新しい手法への不確実性——二の足を踏む気持ちは十分にわかります。 ただ、本記事でお伝えしたとおり、タイミーではUGの3日間をきっかけに1ヶ月で組織の行動パターンが変わりました。利用者の急増、Skillsの整備、エンジニア以外への波及。これらは3日間の投資に対して余りある効果だったと感じています。開催を迷っている方にとって、一つの事例として参考になれば幸いです。 最後まで読んでいただき、ありがとうございました。こうした取り組みに興味を持っていただけた方、一緒にチャレンジしてくれる方を募集しています！ タイミーの採用情報はこちら
- 生成AI
- 自動化
- 生産性
失敗から学んだ仕様駆動開発――チームの暗黙知を形式知化した1ヶ月の実践と次の課題
こんにちは！プロダクトエンジニアの@kazzhiraです。 私たちのチームでは、2025年の夏ごろから「AI活用による開発生産性の向上」に取り組んできました。しかし、当初の取り組みは抽象的なガードレールの提示や個々人の実践にとどまり、チームとして大きな成果には結びつきませんでした。 その後、SDD（仕様駆動開発）というアプローチに出会い、オープンソースの cc-sdd フレームワークをベースに試行錯誤を重ねてきました。 本記事では、AI開発標準の策定に失敗した経験から何を学び、どのように仕様駆動開発に辿り着いたのか、そして、実践を通じて得た成果と学びをご紹介します。 チームのAI導入でうまくいかなかった話 AI活用の個人最適化 当初、チームでは Cursor、Claude Code、Devin、GitHub Copilot、Gemini などの AI ツールを個々人の判断で利用できる状態でした。 しかし、AI活用の状況は個々人に閉じており、チームとしてのナレッジ共有や標準化は進んでいませんでした。 AI開発標準策定の失敗 そこで「AI開発標準」の策定を試みました。情報を収集したうえで、Planモードで実装計画を立て、途中でレビューを挟む開発スタイルを言語化しました。しかし、結果的にこの取り組みは失敗に終わりました。 資料の説明が抽象的で、チームが具体的に動きようがなかった 開発手法の共通項を抜き出しただけのガードレールに過ぎなかった 実際の開発プロセスに落とし込めず、絵に描いた餅になった 参考：当時の考えを振り返った記事 なぜSDDをやろうと思ったのか 理想の開発体験の議論 チームで理想の開発体験・開発生産性の課題を話し合った結果、以下の課題が明確になりました。 リファインメント（仕様を決める会議）で議論が発散して収束に時間がかかる AIは顧客課題、ユーザーストーリーを知らず、要件の精度が高くない AIの出力が微妙で、整理されたコンテキストが足りない SDDとの出会い これらの課題を解決する方法として、SDD（仕様駆動開発）に辿り着きました。 SDDの本質は、仕様書を「単なるドキュメント」ではなく、AI と人間の両方が参照する SSoT（Single Source of Truth）として機能させることです。 定性面 AIがユーザーストーリー、背景、受け入れ条件から精度の良い仕様書を生成する →「AIは顧客課題、ユーザーストーリーを知らず、要件の精度が高くない」の解決 構造化された要件定義書・設計書・開発ルールで一貫したコンテキストを提供する →「AIの出力が微妙で、整理されたコンテキストが足りない」の解決 定量面 価値提供速度の向上 これらの効果を期待し、投機的に取り組んでみることを決めました。 ちなみに、「リファインメントで議論が発散して収束に時間がかかる」は当時Notion AIでの解決も試しました。しかし本題から外れるため、本記事では割愛します。 SDDの実践と工夫 cc-sddフレームワークの採用 SDD を実践するにあたり、私たちはオープンソースの cc-sdd（Spec-Driven Development フレームワーク）を採用しました。 深い理由はなく、筆者が各所で目にして実験的に入れていた背景があります。 チーム固有の課題 cc-sdd の基本的なアプローチを導入した上で、私たちのチームは以下の課題に直面しました。 複数のリポジトリを AI が横断的に操作できない チーム固有のタスク分割・実行ルールがなく、AI の出力がチームの開発フローに合わない Rails 固有の設計パターンが AI に伝わらない プロダクトのドメイン知識が AI に渡っていない 私たち独自のソリューション これらの課題に対し、私たちは以下の解決策を構築しました。 1. マルチリポジトリ横断ワークスペース Cursorによる開発を前提に、code-workspaceを生成して複数リポジトリを統合的に扱う仕組みを実装しました。 【my-team.code-workspace】 { "folders": [ { "name": "my-team", "path": "." }, { "name": "backend", "path": "~/workspace/backend-repository" }, { "name": "frontend", "path": "~/workspace/frontend-repository" }, ... ] } これにより以下のメリットが得られました。 AI エージェント（Cursor / Claude Code 等）がリポジトリを横断して操作可能 仕様書リポジトリ（my-team）とコードベースを統合管理 私たちの最初の実装では、my-team・backend・frontendをセットで管理しました。 今はもう少し増えています。 2. タスク生成・実行ルールの整備 チーム固有のタスク生成・実行ルールを定義しました。 ルール種別 内容 タスク分割ポリシー "デプロイ可能な最小粒度" にタスク分割 Commit・Push・PRのルール 例示することで、意図した生成に誘導する。例えば "commitには変更理由とリファレンスを必ず含める"、"PRテンプレートに従う" など。 タスク実行順序の定義 Swaggerを定義してからfrontendとbackendの作業に移行する。 3. カスタムステアリングドキュメント Rails 固有の設計パターンやプロダクトのドメイン知識をステアリングドキュメントとして整備しました。 Controller Patterns（before_action の濫用禁止、個別でエラーハンドリング不要など） プロダクト固有の名称、用語、ユースケース リポジトリ構造のサマリ 採用している技術の詳細 例として「プロダクト固有の名称、用語、ユースケース」を定義した例を示します。 # Product Overview タイミーアプリのAPIサーバー、クライアント向けWebアプリケーションのAPIサーバー、 ワーカー向けモバイルアプリケーション、社内管理ツールを提供するプラットフォーム。 ## Core Capabilities 1. **ワーカー・クライアント管理**: ワーカーとクライアント企業のアカウント管理、認証、プロフィール管理 2. **求人・マッチング**: 求人作成、公開、ワーカーとのマッチング機能 3. **勤怠・給与管理**: 出勤管理、給与計算、支払い処理 4. **コミュニケーション**: チャット機能、レビュー・フィードバック機能 5. **管理機能**: 社内管理ツール、各種レポート・分析機能 ## Target Use Cases - **クライアント企業**: 求人作成・管理、ワーカー管理、勤怠確認、給与支払い - **ワーカー**: 求人検索・応募、勤怠管理、給与確認 - **社内管理者**: システム管理、データ分析、各種レポート生成 ## Value Proposition - ワーカーとクライアント企業を効率的にマッチングするプラットフォーム - 勤怠管理から給与計算まで一貫した業務フローを提供 4. カスタムコマンド cc-sddのコマンド体系以外で、チームで必要な成果物を保管するためのコマンドを用意しました。内容は長いため省略します。 QAチェックリストの自動生成「spec-qa-checklist」 Playwright MCPによるQA自動実行「playwright-mcp-qa」 最終的なファイルツリーを示します。 my-team/ ├── my-team.code-workspace # マルチリポジトリ統合ワークスペース定義（独自作成） ├── repos.yml # 対象リポジトリ一覧（独自作成） ├── repos.template.yml # ↑のテンプレート（独自作成） ├── docs/ # プロジェクト横断ドキュメント │ ├── scripts/ │ ├── setup.sh # 初期セットアップ（独自作成） │ ├── setup-workspace.sh # ワークスペース構成生成（独自作成） │ └── sync-*.sh # リポジトリ・設定の同期（独自作成） │ ├── .cursor/ │ └── commands/ # カスタムコマンド（独自作成） │ ├── spec-qa-checklist.md # QAチェックリスト生成 │ └── kiro/ # Kiro Spec-Driven コマンド群 │ └── .kiro/ ├── steering/ # アーキテクチャ制約 │ ├── product.md # プロダクト原則 │ ├── tech.md # 技術標準 │ └── structure.md # コード構造パターン ├── settings/ │ ├── rules/ # 設計・実行ルール（独自） │ │ ├── tasks-generation.md # タスク生成（プレフィクス規約・分割順序）（独自作成） │ │ └── task-execution-policy.md # 実行ポリシー（環境・Git・コミット規約）（独自作成） │ └── templates/ │ ├── specs/ # 仕様テンプレート │ └── steering/ # ステアリングテンプレート └── specs/{feature}/ # 機能単位で生成 ├── requirements.md # 要件 ├── design.md # 設計 ├── tasks.md # タスク └── e2e-qa-checklist.md # QA（独自作成） 評価 ポジティブな評価 cc-sddの短期間の導入で最も価値を感じたのは、実装速度の向上ではなく、開発プロセスの質の向上でした。 暗黙知の形式知化 — これまで個人の頭の中にあった仕様判断が、requirements / design / task の3つの成果物を通して言語化・共有された 手戻りの減少 — 仕様書によってコンテキストが整理されたことで、AIの出力品質が安定し、実装後の手戻りが体感として減った 合意形成の質の向上 — 仕様を厳格に言語化するプロセスが、チーム内の認識齟齬を早期に解消した モブワークとの親和性 — 構造化された仕様書が共通言語として機能し、スプリント初期の設計作業を効率的に進めることができた ネガティブな評価 一方で、チームで改善すべき課題も挙がっています。 モノにもよるが、仕様書を作る工程で同期的に1日〜1.5日の時間を使う 仕様書を精査する工程の疲労感 実装スピードとデプロイ頻度は、以前と同等か、微増している感覚 シンプルに練度不足 リファインメントが引き続きボトルネック。実装が効率化しても、要求の供給が追いつかなければ全体のスループットは上がらない 中間生成物のレビューがリファインメントに次ぐボトルネック。AIが高速に生成するアウトプットに対し、人間のレビューが追いつかない etc. データで見る事実：cc-sdd導入でデプロイ頻度は向上しなかった 前提として、開発者が3名のスクラムチームです。 【デプロイ頻度の移動平均推移】 デプロイ頻度の移動平均推移 開発生産性を測るFour Keysの1つの指標であるデプロイ頻度に着目しました。 cc-sdd導入前後でデプロイ頻度が向上していないことを観測 AIを本格導入してきた過去6ヶ月で見るとデプロイ頻度は増加傾向 先ほどのネガティブな評価の「実装スピードとデプロイ頻度は、以前と同等か、微増している感覚」とも一致しています。 ここで、他の視点も入れてみます。 【デプロイ頻度と変更リードタイムの移動平均推移】 デプロイ頻度と変更リードタイムの移動平均推移 【平均レビュープルリク数とレビューからアプルーブまでの平均時間の移動平均推移】 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/timee_dev/20260219/20260219151206.png" width="1200" height="427" loading="lazy" title="" class="hatena-fot
- 生成AI
- プロダクト開発
- スクラム