シンクロ・フード エンジニアブログ

飲食店ドットコムを運営する、株式会社シンクロ・フードの技術ブログです

数週間かかっていた gem バージョンアップの手動テストを Claude Code で自動化した話

はじめに

こんにちは。第一開発G アプリケーション基盤チームの寸田です。

アプリケーション基盤チームは複数のサービスにまたがる部分の開発を担っており、その中で私は主に Ruby / Rails のバージョンアップを担当しています。

シンクロ・フードでは全社的に業務における AI 活用を進めており、開発部でも今年から全エンジニアに Claude Code を配布しています。ただ「配って終わり」ではなく、活用ノウハウの共有や、日々の開発業務の中で AI でできそうなことは AI に任せるといった取り組みを継続して行っています。

その結果、Claude Code によって開発速度は上がった一方で、レビューやテストにかける時間が新たなボトルネックになるという変化が見えてきました。本記事では、こうした AI 活用の取り組みの一例として、特に負荷の大きかった gem バージョンアップの手動テスト を自動化した事例を紹介します。

開発フローを AI 前提で見直す

Claude Code の配布後、私たちはコードを書く工程だけでなく、レビュー・テスト・調査といった周辺工程も AI に任せられないかを順に検討してきました。その中でも費用対効果が大きいと判断したのが、長年エンジニアの手を取られてきた「手動テスト」の領域です。なかでも代表的なのが、gem バージョンアップに伴うテストでした。

なぜ gem バージョンアップのテストが辛いのか

弊社では主に Ruby / Rails を使ってサービス開発をしています。Ruby / Rails はバージョンの更新頻度が高く、それに追従するためには依存している多数の gem も合わせてバージョンを上げていく必要があります。

gem のバージョンアップは、RSpec による自動テストが通るだけでは「問題ない」と言い切れないケースがあります。代表例は次のとおりです。

  • 外部システムに依存する処理 … テストではモック・スタブしている部分が、本番の外部サービスとの組み合わせで初めて壊れることがある
  • 本番環境固有の挙動 … 本番特有の設定・データ・インフラ構成でしか再現しない問題があり、テスト環境では気づけない
  • JavaScript が絡む処理 … ブラウザ上での実際の動作は、リクエストスペックなどサーバーサイドのテストだけでは検証しづらい

例: CarrierWave のバージョンアップ

具体例として、ファイルアップロードに使っている CarrierWave gem のバージョンアップが挙げられます。

CarrierWave gem は、

  • Amazon S3 へのファイルアップロード
  • 画像の場合はリサイズ処理

などを担っています。つまり 外部システム（Amazon S3）に依存 しており、アップロードやリサイズが実際の環境で正しく動くかは、自動テストだけでは担保しづらく、結局は人手による動作確認に頼ることになります。

また、弊社特有の課題として、影響範囲が複数のサービスにまたがりやすい、という点もあります。弊社では共通機能を Rails エンジンとして社内 gem に切り出し、それを複数のアプリケーションから利用しています。そのため、ある gem のバージョンアップによる影響が複数のサービスに及びやすく、それぞれを担当するサービスチームをまたいでしまうことも珍しくありません。影響箇所をひとつひとつ手動でテストしていく必要があり、各サービスチームにテストを依頼してから完了するまでに数週間かかる こともあります。これが gem バージョンアップの最大の辛みでした。

手動テストの自動化

そこで、この手動テストを AI（Claude Code）で自動化することにしました。手動テストの実行基盤としては Playwright を採用し、Playwright のテストを Claude Code に書かせることにしました。バージョンアップする gem の利用箇所をソースコードから洗い出し、その箇所を確認する Playwright のテストを生成してもらう、という流れです。

ただ、単純に「ソースコードをもとにテストを書いて」と指示しただけでは、意味のないテストが生成されてしまうことが多くありました。たとえば、画面を開くだけで肝心の処理を通っていなかったり、確認したい機能とは関係のない操作をテストにしてしまったりして、「一見テストはあるが、肝心の箇所をまったく検証できていない」という状態になりがちだったのです。

そこで重要になるのが、テスト対象のコードがちゃんとテストされているかを AI 自身に確認させることです。具体的には、テスト実行時のカバレッジを計測し、テスト対象の箇所がカバーされているかを判断させています。なお、カバレッジの計測には coverband gem を利用しています。

まとめると、以下のような手順でテストを追加しています。

  1. テスト対象（バージョンアップする gem の利用箇所）をソースコードから洗い出す
  2. テスト対象の Playwright のテストをコードから生成し、実行する
  3. カバレッジの計測結果を見て、ちゃんとテストでカバーされているかを確認する
  4. カバーされていない箇所のテストを修正する

どうしてもソースコードだけではテストを生成できない場合があるため、ステップ3〜4（カバレッジの確認と不足箇所の修正）は最大 3 回まで繰り返すようにしています。

スキルとして組み立てる

この一連の流れは、Claude Code のスキルとして実装しています。スキルは以下の3つから構成されています。

  • 手動テスト一覧を作るスキル … ソースコードを調査し、確認すべき項目をテンプレート形式で洗い出す
  • 1つの対象の Playwright のテストを生成するスキル … 指定された箇所をカバーするテストを生成し、実行 → カバレッジ検証 → 不足なら修正、というループを回す
  • オーケストレーターとなるスキル … 上記2つを束ね、対象をグループに分けて、テスト生成スキルを 複数エージェントで並列に 走らせる

処理の流れをフローチャートで示すと以下のようになります。

処理の流れのフローチャート

結果と課題

実際に CarrierWave gem のバージョンアップで試したところ、これまで手動でテストしていた多くの利用箇所を、自動化したテストでカバーできることが確認できました。一方で、現時点では AI が機能への到達方法を検出できず、カバーしきれないことがあります。この場合はソースコード以外のコンテキストを渡す必要があるようですが、こうした改善は今後の課題となります。

おわりに

今回は開発部における AI 活用の一例を紹介させていただきました。弊社ではこの他にも AI による生産性向上に取り組んでいます。 今回の記事が、AIでの開発生産性向上に取り組んでいる方々の参考になれば幸いです。