Cursor × MagicPod MCPサーバーで、AIレビューの仕組みづくりに挑戦してみた話
株式会社Hacobu(以下、Hacobu)でQAエンジニアをやっています、かわせです。
MagicPod MCPサーバーの活用事例としてAIにテストケースをレビューさせる仕組みづくりをしたお話しを今回紹介できればと思います。
はじめに
MagicPodのようなノーコード自動テストツールは、運用が進むほどテストケースの均一化と質をどう担保するかという壁にぶつかります。この点については、導入時にガイドライン・命名規約などのルールを設け、それを運用することで回避できると考えていました。
テスト自動化のレールを敷く -MagicPod運用設計の舞台裏
しかしガイドラインや規約になじみのないテストケース実装者も多いため学習コストが想定以上にかかるのに加え、慣れるまではレビュー時の指摘が多く出てしまうことでレビューコストが増大する問題に直面していました。
このままではMagicPodを扱うメンバーが増えるたびに痛みが増していく未来が想像できました。こういった課題を感じていた中で、Cursor × MagicPod MCPサーバーを使って、AIによるテストケースレビューができないかと思い、仕組み化に取り組みました。
最初にやったこと(別記事)
今回の仕組みを始めるにあたって行った準備については、別記事にまとめています。
MagicPod MCPサーバーを試してみた
レビューの仕組みづくり
まず取り組んだのが、「各種規約をProject RulesとしてCursorに教えること」でした。
Project Rulesの作成
Cursorでは、プロジェクトという概念があり、そのプロジェクトごとにルールを設けることができます。例えば、日本語でやりとりがしたいよっといったルールや、MagicPodのAPI実行時の組織とプロジェクトを毎回指示しなければならないといったことを回避するために、あらかじめルールとして記憶させておくことができます。以下の例では、組織とプロジェクト、APIのレスポンスに含まれる日時項目のタイムゾーンを日本時間で読み取ってもらうようなルールを書いています。
プロンプト群の作成
次に実際にどのようなレビューをしてもらいたいか具体的なプロンプトを書き出していきます。AIレビューはこのプロンプト群がどれだけ精度よく作れるかが成功のカギだと思っています。とはいえ、最初はどうなるかわからないので、規約通りに実装されているか順序よくプロンプトを書いていきながら調整を繰り返しました。
- テストケースの命名規約に則っているかレビューしてください
- 変数の命名規約に則っているかレビューしてください
このような感じでプロンプトをまとめたファイルを作っていきます。このファイルについてはMarkDown(.md)形式のファイルとして、プロジェクト内の任意の場所に保存しておきました。
実行してみると
あらかじめ定義した規約に沿ってレビュータスクを実行してもらうようにプロンプトを組み、何度か微修正を加えながらレビューを実行してみた感じです。
(最初のプロンプトが/rev_t xx
になっているのは、レビュー実行の指示用のショートカットもルールとして登録しているためです)
最初にMagicPodのAPIを実行して必要な情報を取得してきています。
その後、Project Rulesに登録した規約に則ってレビュー結果を返してきています。日本語でやりとりしてほしいというルールも読み込めていますね。
このあたりで「レビューをAIが肩代わりしてくれる」感が出てきます。
調整の連続
「定義したルールに則って、レビューしてください」だけでは不十分で、チャットでやり取りを繰り返しながら少しずつ観点を加えていきました。特にAIにとってはプロンプトが曖昧で出力結果が不安定になることが多々あり、プロンプトの調整を繰り返し行う必要がありました。この繰り返し行った調整で得られた知見としては、以下の通りです。
- コーチングよりティーチングスキルが大切
- APIを扱う場合は、何が取得できるのか理解しておく必要がある
使ってみた所感
現在はまだチーム全体で本格運用している段階ではないですが、少なくともセルフレビューで使う用途としての質は担保できていると実感しています。
現時点の課題感
MagicPod APIレスポンスの仕様課題
レビューに使っているAPIレスポンスであるhuman_readable_steps
には以下の課題があります。
- ステップの行番号が返ってこない
- 無効化されたステップがわからない
一括実行の実行ログを取得するAPIであれば行番号も取得でき、実行されたステップになっているので上記は解決しますが、一括実行後にのみ取得できる情報なのでテストケースの実装段階では使いにくいかなと思ってます。
管理方法の課題
AIレビューは継続的な調整が必要なので、運用開始後の改善フローの準備が必要と考えています。そのため、Project Rulesやプロンプトのテンプレートをどこで・どうやって管理するか?という課題があります。この点についてはチーム運用開始までに明確にしていきたいと思っています。
まとめとこれから
- Project RulesとCursorのプロンプト整備で、AIレビューの仕組みはある程度形になった
- ルールやプロンプトの運用フローは今後の検討課題
最終的にはGitHub連携してソースコードとの整合性レビューも視野に改善していけるとより精緻なレビューになるのではないかと想像しています。
Discussion