Railsのテストを自動操縦：開発者が書かないコードを書くエージェントの構築

大規模な Rails モノリシックアプリケーションの多くにおいて、組織は新機能の実装を優先し、それに対するテスト作成には後回しにしがちです。時間が経つにつれて、テストされていないコードが徐々に増え、チームは痛みを伴うバグのデバッグにより多くの時間を費やすことになります。 私たちはそのギャップを埋める自律型エージェントを構築しました。このエージェントは Rails のソースファイルを読み込み、RSpec テストを生成または改善し、スタイルルールとカバレッジ目標に対して検証を行います。さらに、人間の介入なしで CI/CD パイプライン内で実行されます。このような大規模なコードベースを扱うために、並列処理で動作します：複数のインスタンスが異なるファイルを同時に処理します。 ## エージェントの視点から見た RSpec Ruby は動的型付け言語であり、コンパイルステップが存在しないため、エラーは実行時に表面化します。私たちのエージェントにとって、これはテスト構文を検証する唯一の方法が実際に実行することであることを意味します。**[RSpec](https://rspec.info/)** は標準的な Rails テストフレームワークですが、テストを表現豊かで読みやすくしますが、そのドメイン固有言語は誤りやすいものです。 エージェントが Ruby on Rails のコードベースを読み込む際、5 つの主要なファイルタイプ（モデル、シリアライザー、コントローラー、メールラー、ヘルパー）を読み込みます。それぞれ構造が異なり（したがってテスト方法も異なります）、エージェントは各タイプに対して固有の指示を必要とします。 一つの利点は、ソースファイルから spec ファイルへのマッピングがほぼ 1:1 であることです。一般的な規約は以下の通りです： ![image](https://cms.mistral.ai/assets/5825a803-d859-48f1-a3f8-ea095da3416a.png?width=1494&height=580) ただし、このルールにはいくつか例外があります。例えば、app/controllers/ディレクトリがspec/requests/にマッピングされる場合や、単一のソースファイルに対して複数の spec ファイルが存在する場合などです。その場合の慣習は以下の通りです。 ![image](https://cms.mistral.ai/assets/6ba9925a-0be9-410e-ba7f-e23d961531c2.png?width=1478&height=718) この単純なマッピングにより、任意のファイルに対応するテストを容易に見つけたり、全くテストが存在しないファイルを特定したりすることが可能になります。 しかし、当社のエージェントにとって難しくなるのは、コードの重複を防ぐために RSpec が共有コンテキスト（shared context）に大きく依存している点です。具体的にはファクトリ（factories）、フィクスチャ（fixtures）、データベーススキーマなどが該当します。 - ファクトリ：事前に定義された属性を持つテストオブジェクトを作成するための再利用可能なテンプレートであり、一貫性のあるテストデータの生成を容易にします。 - フィクスチャ：テストデータベースレコードをプリロードする静的データファイルであり、テストのための固定された基準値を提供します。 ファクトリファイルが存在しない場合はエージェントが作成し、存在する場合はそれを再利用します。ファクトリは spec ファイルとは異なり多くのテストで共有されるため、不用意な変更は他の場所のテストを簡単に壊す可能性があります。そのため、これらのファイルへの更新には注意が必要です。 ## Vibe を用いたエージェントの構築 当社は、Mistral のオープンソースコーディングアシスタントである **[Vibe](https://mistral.ai/products/vibe)** 上に本エージェントを構築しました。デフォルトのシステムプロンプトはこのプロジェクトで十分であったため、私たちは以下の3つのレバーに焦点を当てました：リポジトリレベルのコンテキスト、専門的なスキル、およびカスタムツールです。 ## コンテキストエンジニアリング コンテキストエンジニアリングは、私たちのアプローチの中核でした。Vibe はリポジトリレベルの AGENTS.md ファイルをサポートしており、このファイルがルートのリポジトリで実行される場合、その内容は自動的にシステムプロンプトに追加されます。 私たちが使用した AGENTS.md は、対象となるリポジトリに関する基本的な詳細を提供しましたが、主にエージェントに対して**段階的な実行計画**を提供するものでした: 各ステップには、何を行うべきか、そして成功の基準は何かという詳細が含まれていました。また、エージェントに方向性を示すことが重要だと感じた領域については、RSpec のベストプラクティスもいくつか記載しました。例を挙げると： 私たちは、エージェントが時折メソッドをスキップしたり、エッジケースのテストを怠ったりすることがあることに気づきました。つまり、完全に見えた仕様のコードを生成しながらも、ソースファイルから一部の公開メソッドを静かに無視してしまうのです。これに対処するため、AGENTS.md の最後には強制的な自己レビューを追加しました。エージェントは完了する前に、ソースファイルを再読し、「すべての公開メソッドをテストしたか？数を数えよ」と自らに明示的に問いかける必要があります。何か不足していれば、やり直します。 このように、厳格な計画に従うようエージェントを強制する汎用的な AGENTS.md ファイルを用いた結果、フレームワークレベルの指示を含む単一のマークダウンファイルだけで、品質スコアは**0.68 から 0.74 に向上**しました。 ## SKILLS ファイルの使用： AGENTS.md のステップ 4 を思い出してください： 4. ソースファイルの場所に基づき、正確に 1 つのスキルを選択して読む 単一の汎用的なスキルでは中途半端な結果しか得られません。モデルファイルをテストするための指示は、コントローラーファイルをテストするための指示とは異なるからです。 成功したのは、各カテゴリごとに別のスキルファイルを作成し、通常の Ruby ファイル用にも 1 つ用意したことです。 コントローラーのテスト用の基本的なスキルファイルの例を以下に示します： ## カスタムツールの追加 Vibe には、ファイルの読み書きや bash コマンドの実行、コード編集を行うための組み込みツールが備わっています。しかし、そのアクション空間を広げるためにカスタムツールや MCP（Model Context Protocol）にも対応しています。このプロジェクトでは、カスタムツールが鍵となりました。 いくつかの実験を経て、以下の構成を採用しました： - RuboCop リンティングツール：rubocop コマンドを実行してスタイル違反を検出し、エージェントがコードに戻って修正を行うようにします。 - SimpleCov ツール：RSpec と統合され、コードカバレッジとテストの正しさを同時にチェックします。これを最終ステップとして配置したことが重要でした。これにより、エージェントが作成するすべてのテストが実際に実行されることを保証できます。 以下は、RuboCop リンティングツールの実装を簡略化したバージョンです： SimpleCov ツールも同様のパターンに従いますが、より多くの機能を持っています。RSpec を使って spec ファイルを実行し、各テストのパス/フェイル結果を収集して、ソースファイルのカバレッジパーセンテージを報告します。エージェントは、どのテストが失敗したか（エラーメッセージ付き）と、ソースファイルのどの行が一度も実行されなかったかを取得できます。これにより、必要に応じて自己修正するための十分な情報を得ることができます。 このツールを最初に接続した際、生成されたテストのうち初回実行で成功したのは約 3 割だけでした。しかし、エージェントは数回の反復で全ての失敗を自己修正しました。このステップがなければ、一部のテストは実行されなかったでしょう。 ## テスト品質の測定 良いユニットテストは、[Arrange-Act-Assert](https://semaphore.io/blog/aaa-pattern-test-automation) パターンに従います：状態を設定し、1 つの動作を実行し、結果を検証します。正確なアサーションを使用し、ハッピーパスとエラーパスの両方をカバーし、何が壊れたかを明確に特定できる失敗を生成すべきです。 ![image](https://cms.mistral.ai/assets/32542f94-4778-4112-820f-203e96ef0735.png?width=2124&height=1144) ## ツールベースの指標 既存の Ruby on Rails のツールを使用すれば、いくつかの指標を容易に取得できます： - RSpec: Ruby 向けの最も人気のあるテストフレームワーク。読みやすく構造化されたテストを書くための表現力豊かな構文を提供します。 - RuboCop: スタイルガイドの遵守を支援しコードの一貫性を保つための、静的な Ruby コード解析器およびフォーマッターです。 - SimpleCov: テストスイートによって実行されるコードの量を測定する、Ruby 向けのコードカバレッジツールです。 これらのツールから、以下のいくつかの有用な定量的指標を抽出できます：テストのパス率、ファイルあたりの RuboCop ビオレーション数、ユニットテストスイートでカバーされているコードの割合、および実行速度です。これらの指標は、テストスイートの全体的なパフォーマンスを測定するための堅牢なベースラインを提供します。 しかし、これらの数字だけでは、テストファイルが実際に良いかどうかを判断することはできません。両方とも RuboCop ビオレーションがゼロで、カバレッジが 100%、かつすべてのテストにパスしている 2 つのファイルをどのように比較すべきでしょうか？定量的な指標は同じように見えるかもしれませんが、テスト品質における質的な違いが存在する可能性があります。 LLM-as-a-judge の背後にあるアイデアは、LLM に「すべてのエラー条件がテストされているか？」や「これは良いテストか？」と問いかけ、明確な基準に基づいて 0 から 1 のスコアを返させることです。 例となるプロンプト： ここでの「スコアリングルール」セクションは特に重要です。これにより、実行間でのスコアの整合性が保たれます。これがなければ、エージェントはスコアリングの厳格さや緩やかさをどのように定義すべきかという明確な基準を欠いてしまいます。 このようなスコアは、ツールの出力や徹底的な開発者によるレビューに比べると権威性は劣ります。しかし、リポジトリ内のすべてのファイルでスケールして実行される場合など、現在のバージョンのエージェントがどの程度機能しているかを示す良い指標となります。 ## LLM-as-a-judge 評価の限界： テキスト化できるものであれば何でも LLM-as-a-judge でスコアリング可能であるため、これは汎用性が高いと言えます。ただし、出力されるスコアは決定論的ではありません。*temperature=0* を設定していても、カーネル操作の順序によるばらつきが生じます。実際には、同じ評価に対する出力は常に近い値になりますが、この非決定性は特定のユースケースでは課題となり得ます。 私たちのユースケースでは、一度に単一のテストではなく通常数十から数百のテストをスコアリングするため、これは許容できる限界でした。集約されたスコアは一貫して保たれていました。 ## 欠落した括弧の問題 LLM-as-a-judge にはもう一つの核心的な問題がありました。テスト自体は高品質であっても実行されない場合や、背後にあるロジックが根本的に間違っている場合があります。 例： このテストは素晴らしいです。1 つの振る舞いを検証し、ドキュメントとして読める明確な記述を持ち、[Arrange-Act-Assert](https://semaphore.io/blog/aaa-pattern-test-automation) パターンに従っており、もし壊れた場合でも有用なメッセージで失敗します。 このテストを、以前に定義したスコアリングプロンプトを用いて複数のモデルで実行しました。得られた平均スコアは 0.75 です。サッと目を通す開発者なら、おそらく同意するでしょう。 しかし、このテストには 1 つの根本的な欠陥があります：**これは実行できません**。`User.new()` の閉じ括弧 `)` が抜けているためです。これはこのテストを明らかに不適切にする致命的な欠陥です。 この例は緩和しやすいですが、構文エラーを引き起こす可能性は他にもたくさんあります： - バージョンエラー：互換性のない Ruby や Rails のバージョンからメソッドや構文を使用している - 存在しないメソッド：一部のメソッドが削除された、名前が変更された、あるいは最初から存在しなかった - ファクトリ/フィクスチャエラー：欠落したファクトリの参照、誤った属性、または欠落した関連付けの参照 - 依存関係の欠如：テスト環境に含まれていない gem やモジュールの使用 ## 実験 エージェントが実際のコードベースに耐えられるかを確認するため、実験を行いました。対象のリポジトリには 275 のソースファイルが含まれていました。その半分はすでにテストカバレッジを持っており、残りの半分は何も持っていませんでした。 エージェントを、既にテストがあるかないかに関わらず、すべてのファイルに向けて実行しました。未カバーのファイルについては、ゼロから仕様に生成することに成功しました。すでにテストが存在するファイルについては、それらを再書き起こしして改善しました。 LLM-as-a-judge を用いて、各 spec ファイルをテスト前とテスト後に評価しました。その結果、テスト済みファイルの集計スコアは 0.49 から 0.74 に向上し、カバレッジは 100% に達しました。まだ改善の余地はありますが、このアプローチの有効性が実証されました。 MetricResult Files processed: 275 Tests passing: 100% Average line coverage (SimpleCov): 100% RuboCop violations after self-correction: 0 LLM-as-a-judge score: 0.74 ## By file type すべてのファイルタイプがテストしやすいわけではありませんでした。Models は最高スコアを獲得しました。そのビジネスロジックは完結しており、テストパターンも予測可能だからです。一方、Controllers は難易度が高く、HTTP リクエスト処理の追加によりエラーが発生する余地が大きくなりました。 File type | LLM-as-a-judge ---|--- Models | 0.81 Controllers | 0.67 Serializers | 0.80 ## Does it run? RSpec の実行最終ステップとして SimpleCov をバンドルし、エージェントが作成したすべてのテストを実行させるよう強制したことが、最も影響力のある決断でした。最初の試行で合格したのはテストのわずか 3 分の 1 に過ぎませんでした。しかし、エージェントは数回の反復内ですべての失敗を自己修正しました。 このステップがなければ、LLM-as-a-judge は実行されていないこれらのテストを高品質と評価していただろうという点です。これは、大規模化における「括弧の欠落」問題に他なりません。 **[Vibe is open source](https://github.com/mistralai/mistral-vibe)**: ここで説明したエージェント、ツール、スキルはすべて Vibe 上で動作します。ぜひお試しください。

Railsのテストを自動操縦：開発者が書かないコードを書くエージェントの構築

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

関連記事

ニュースの次に確認する

調べる

選ぶ

サイト