食べログにおけるDevinブラウザテストの実現に向けた取り組み – Tabelog Tech Blog

この記事は 食べログアドベントカレンダー2025 の7日目の記事です🎅🎄

はじめに

※本記事は合作記事となっており、記事全般とDevin環境構築の課題1・3を@massaaaaanが、課題2を@weakbosonが執筆しています。

こんにちは、食べログ 国内メディア開発部の@massaaaaanです。

食べログでは、開発効率向上を目指して完全自律型AIエージェントのDevinを導入しています。

Devinは、コードの実装からテストまでを自動で行うAIエージェントです。独自のVM環境（Devin’s Machine）を持ち、ブラウザテストを実施できます。これにより、実装からブラウザテストまでを完全自動化し、画面確認の手間を削減してテスト工数を大幅に削減できます。

しかし、食べログのシステムは20年の歴史を持つ大規模システムです。長年の開発で培われた複雑な構成や大容量データがあり、Devinを導入したもののブラウザテストが動作しませんでした。そのため、Devinの利用時に以下の課題に悩まされていました。

• エンジニアがDevinの実装した機能をブラウザで確認すると、初歩的なエラーが発生して正常に動作せず、それをエンジニアが修正する作業に手間がかかる
• 最終的なブラウザテストは人間が手動で行う必要があったため、Devinで実装が早くなってもブラウザテストの工数がボトルネックになっていた
• 仮にブラウザが動く状態になっても、Devin’s Machine上にはテスト用データが存在しないため、十分なブラウザテストができない

これらの課題を解決しなければ、Devinの真の価値を発揮できません。そこで、私たちはDevinを最大限活用するための環境整備に取り組みました。

本記事では、食べログでDevinによるブラウザテストを実現するために取り組んだ3つの課題と、それぞれの解決策を詳しく紹介します。

Devin環境構築で直面した3つの課題と解決策

食べログの現在の開発環境は以下のような構成になっています。

この環境をDevinで活用するために解決が必要だった主要な課題は以下の3つです（図の赤塗り箇所）

1. HTTPS環境の構築：食べログの開発環境と同等のWebサーバー構成が必要
2. 大容量データの制約：開発の共有データが大きすぎてDevin’s Machineで扱えない
3. 外部サービス接続制約：社内外のAPIに依存しておりDevin’s Machineからアクセスができない

それぞれの課題について、詳しく見ていきましょう。

課題1：HTTPS環境の構築

食べログの開発環境構成とDevinでの課題

食べログの開発環境では、HAProxyとNginxを組み合わせた構成を採用しています。

当初はHAProxyやNginxを使わず、Rails serverのみでブラウザテストを行うことを検討しましたが、以下の理由でRails serverだけでは動作しませんでした。

• Nginxが必要：一部のルーティング処理がNginxで定義されており、これがないと適切な画面遷移ができない
• HTTPS必須：開発環境でもHTTPSでないとアクセスできない制約がある

そのため、Devin’s Machineでも同等の構成が必要でした。Nginxはルーティング処理のためそのまま利用することとし、リバースプロキシについてはSSL終端が目的なのでHAProxy以外の方法も含めて解決策を検討しました。

解決策の検討

この課題に対して、以下2つの選択肢が候補に挙がりました。

どちらの案も要件を満たすことができますが、検討の結果Caddyをリバースプロキシとして活用する方式を採用しました。

Caddyを選択した理由：

• 自動HTTPS機能: 証明書の生成・管理を完全自動化（HAProxyでは手動管理が必要）
• シンプルな設定: リバースプロキシ設定が直感的で、複雑な設定を学習する必要がない
• 新技術へのチャレンジ: これまで食べログで導入したことのない技術の導入にチャレンジする機会でもあった

採用した構成：

• Nginx: 従来の開発環境と同様にWebサーバーとして利用（設定変更なし）
• Caddy: HAProxyの代替として、SSL終端とリバースプロキシ機能のみを担当

Caddyは本来Webサーバーですが、今回はリバースプロキシ機能のみを使用しました。
この構成により、Nginxが担当していたルーティング処理はそのまま維持しながら、SSL終端部分のみをCaddyで代替することで、開発環境と同等の動作を実現できました。

新たな課題：ブラウザでの証明書警告

Caddyの導入により環境構築は簡単になりましたが、新たな課題が発生しました。

Caddyが自動発行する証明書は、Caddy独自の認証局（CA）で署名されます。そのため、ブラウザからアクセスすると「この接続ではプライバシーが保護されません」という警告が表示されるようになりました。

この警告は手動であれば「詳細設定」から「安全でないサイトに進む」を選択することで回避できますが、Devinが自動でブラウザテストを実行する際に毎回警告を許可する必要があります。

解決策：証明書の自動インポートとスナップショット保存

この問題を解決するため、Ansibleによる証明書管理の自動化と、Devin’s Machineのスナップショット機能を組み合わせた仕組みを構築しました。

解決の流れ：

1. 証明書のシークレット登録
   Caddyが生成したルート証明書をDevinのシークレット機能を使って安全に保存

2. Ansibleによる証明書配布
   シークレットとして登録された証明書をAnsibleのPlaybookでDevin’s Machineに自動配布

3. ブラウザへの証明書インポート
   Devinのブラウザを操作し、配布された証明書を信頼済み証明書として登録

4. スナップショット保存
   証明書が正しく設定された状態でDevin’s Machineのスナップショットを作成・保存

本対応により、次回以降のDevin起動時には証明書が信頼された状態で自動的に復元され、ブラウザ警告なしでテストを実行できるようになりました。

Ansibleを使わずに手作業で行うことも可能ですが、今後Devin以外のAIサービスが登場した場合でも同じPlaybookを使って同様の環境を簡単に構築できると考え、再利用可能な仕組みを構築することを意識しました。

課題2：大容量データの制約

食べログの開発データとDevin’s Machineの容量問題

食べログの開発環境では、共有MySQLデータベースに100GB以上の開発用データが格納されています。これを活用することでリアルな環境でのテストが可能になりますが、Devin’s Machineで利用するには以下の課題がありました。

• ディスク容量の制約：Devin’s Machineのディスク空き容量は約100GBで、100GB超のデータベースを配置できない
• 起動時間の問題：仮に容量を削減したとしても、セッションごとに大容量データをインポートするとDevin起動までのリードタイムが長くなる
• データ転送の課題：Devin’s Machineに大容量データをインポートする適切な手段がない

このままではDevin環境で実用的なデータを使ったテストができない状況でした。

解決策の検討と選択

この課題に対して、以下の2つの手法を検討しました。

検討の結果、外部データベースへの接続方式を採用しました。この方式であれば、既存の開発データをそのまま活用でき、すぐに実用開始できるためです。

採用した方針：Cloud SQLへのオフロード

具体的には、GCPのCloud SQLにデータベースをオフロードする方式を実装しました。

運用方法

• 毎日深夜に開発環境からダンプしてCloud SQLにインポート
• 当日の変更は翌日まで反映されないが、通常は小規模な変更であり他のエンジニアの変更で動作しなくなることは稀なので問題にならない

この仕組みにより、Devin’s Machineのディスク容量を気にすることなく、実際の開発データを使ったブラウザテストが可能になりました。

工夫した点： 運用コストとパフォーマンスの最適化

外部データベース接続方式にはいくつかのデメリットがありますが、以下の工夫で対応しました。

マネージドサービスの活用

• Cloud SQLを利用することで、バックアップやメンテナンスを自動化
• プロダクション環境では問題となる強制メンテナンスも、開発環境では影響が少ない

コスト最適化

• オンプレ開発環境は物理的に複数インスタンスあるが、1インスタンス複数スキーマ構成で費用を抑制
• プロダクションの再現性は若干下がるが、Devinでは高度なデータベーストランザクションのテストを行わないため許容範囲

通信オーバーヘッドの最小化

• DevinはAWS us-west-2 リージョン（Portland, Oregon）にあると推定されたので、地理的に近い GCP us-west1 を選択（※）
• 食べログトップページ表示時のDBアクセス時間がオンプレ開発環境の4倍程度に収まった
• 参考：asia-northeast1 に配置した場合は32倍になった

※ 公開IPアドレス帯から推定。一部Azureのアドレス帯もあるが、諸々の情報から例外と判断。 Common Issues – Devin Docs#IP Whitelisting

この最適化により、実用的なパフォーマンスを維持しながら、運用コストも抑えた外部データベース接続を実現できました。

課題3：外部サービス接続の制約

外部APIにアクセスできずブラウザテストが実行不可

食べログは多数のシステムが連携しており、社内の他システムや外部サービスとも密接に連携しています。

しかし、Devin環境は社内ネットワークの外部に存在するため、以下の制約がありました。

• 接続制限：社内の他のAPIや外部サービスAPIにアクセスできず、システムエラーが頻発
• セキュリティリスク：仮にこれらのAPIへの接続を許可したとしても、セキュリティの観点から適切ではない
• テスト実行の阻害：API呼び出しでエラーが発生すると、その後の画面表示やユーザー操作のテストが継続できない

これらのAPIが動作しない状態ではページの読み込み時点でエラーが発生し、ブラウザテストがほとんど実行できない状況でした。そのため、これらのAPIを代替する必要がありました。

解決策の検討と選択

この課題に対して、以下の4つの解決策を検討しました。

今回の最優先目標は「ブラウザテストが動く状態を実現すること」であったため、検討の結果Caddyのリバースプロキシ機能拡張を採用しました。

Caddyを選択した理由：

• 迅速な実装：レスポンス内容は空でも良いので、固定レスポンスを返すだけの簡単な設定で済む
• 既存技術の最大活用：既にHTTPS環境構築で導入済みのため、追加の学習コストが不要
• 影響範囲の限定：既存システムへの変更が不要で、リスクを最小限に抑制
• 運用負荷の軽減：新しいサーバーやツールの管理が不要

具体的な実装

Caddyの設定で、Devin’s Machineからアクセスできない外部APIのドメインに対して、あらかじめ用意した固定のJSONレスポンスを返すように設定しました。これにより、実際のAPI接続なしでも、システムが期待する形式のレスポンスを受け取ることができ、その後の処理を正常に継続できるようになりました。

まとめ

本記事では、食べログでDevinを活用した自動ブラウザテストを実現するために取り組んだ3つの課題と解決策をご紹介しました。

取り組んだ課題と解決策：

1. HTTPS環境の構築 → Caddyによるシンプルなリバースプロキシ構成
2. 大容量データの制約 → Cloud SQLにオフロードして解決
3. 外部サービス接続制約 → Caddyを活用したAPI応答のモック

これらの解決策を導入後のDevin’s Machineのシステム構成は以下図の通りです。

20年の歴史を持つ食べログのシステムを外部環境で動作させるのは想像以上に困難でしたが、それぞれの課題に対して解決策を見つけ、Devinでブラウザテストを実現できる環境を整備できました。

本取り組みにより主要な技術課題は解消しました。まだシステムごとに細かい修正が必要な部分は残っていますが、ブラウザテストが動作するようになったシステムでは以下の効果を得ることができました。

• エラー修正作業の軽減：Devinが実装したコードで発生する簡単なエラーであれば、Devin自身で修正可能になり、手動での修正作業が軽減
• 実用的なデータでの動作確認：開発環境と同等のデータを使用することで、データ不足で画面が開けない問題やデータの不整合がなく、安定したブラウザでの動作確認が可能
• 軽微な修正作業の効率化：文言変更等の軽微な修正であれば、Devinで実装→ブラウザアクセス→スクリーンショット取得→確認という一連の作業が完結し、手動での画面確認作業が不要

今後の展望

本取り組みを通じてブラウザテストするための基盤が整いました。私たちはDevinの環境整備をさらに完成させて、以下のことを実現したいと考えています。

• 全システムでのブラウザテスト対応：現在は一部システムに限られているブラウザテストを、食べログの全システムで実行可能にする
• より高度なテストシナリオの自動化：単純な画面確認だけでなく、複雑なユーザー操作フローの自動テストを実現

AIエージェントを活用した開発効率化は今後ますます重要になると考えております。この取り組みが他の開発チームの参考になれば幸いです。

明日は @itaya の『タスク分割と進捗管理：なぜ「ほぼ終わり」が続くのか？』です。お楽しみに!

---

食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。