テスト自動化のMagicPod、CEOが生成AIを使ったノーコードの自動テスト機能を解説

連載 :

2025年11月7日(金)

テスト自動化のMagicPodのCEOにインタビューを実施し、生成AIを使ったノーコードの自動テスト機能について解説してもらった。

テスト自動化ソリューションを開発提供するベンチャー株式会社MagicPodのCEO伊藤望氏にインタビューを行った。伊藤氏は新機能として生成AIを使ったノーコードのテスト生成機能を解説し、その背景などについての質問に答えた。伊藤氏へのインタビューは2023年以来、2回目だ。2023年のインタビューについては以下のリンクを参照されたい。

●2023年に実施したインタビュー：テスト自動化のMagicPodのCEO伊藤氏にインタビュー。テスト自動化の未来を語る

今回は新しい機能を紹介してくれるということで楽しみにしてきました。生成AIを使っているということですが、どんな機能ですか？

伊藤：これは生成AIを使って、テストコードを書けない人でもテストが作れるという機能です。Autopilotという名前でプレスリリースもしています。これまでもGUIを使ってテストを作ることはできましたが、新たに自然言語を使って指示することで実行したいテストを作ることができるようになりました。これでプログラミングができない人でも、ノーコードでテストを作って実行することができます。

MagicPod、CEOの伊藤望氏

この機能は生成AIを使っているということですが、バックエンドで使っているツールは何ですか？

伊藤：GoogleのGeminiを使っています。この機能はクラウドベースなので、ユーザーがこの機能を使うと一旦MagicPod側でリクエストを受けてそれを我々が契約している有償のGeminiのサービスに流すというやり方で実装しています。現時点では、MagicPodのユーザーはこの機能自体を無償で使えるようになっていますが、リクエストが増えるとこちらの負担も増えてしまうので、これをどうやってMagicPodのユーザーに負担してもらうかをこれから考えていきたいと思います。

生成AIにおいてはハルシネーションが常に問題になりますが、この機能については特に問題ないのですか？

伊藤：今のところ、大きな問題にはなっていないですね。アーリーアダプターとして10社程度のユーザーに使ってもらっていますが、良い反応が多いと思います。ただ問題とまでは言えないんですが、テストの中にちゃんとコメントを書いてくれる場合とそうじゃない場合があるほか、テストを作って実行までしてくれる場合と作っただけで終わる場合があって、明示的に「テストを作って実行して」と指示しないと実行しないこともあるというのは確認しています。

「テストを作成して」という指示だと作成しただけで終わるということですね。

伊藤：そうです。でも実行してくれる場合もあるので、そこは生成AIのその時の結果に依存するということですね。でも実行することはMagicPodのUIでボタンを押すだけなので、実情としては問題はありません。逆にUIの中に要素が多かったり、画面のスクロールをかなり下までしないとボタンが出てこないような場合は人間がテストを作ると要素を見落としたりするんですけど、AutopilotはAIなのでそこは絶対に見落とさないという良さもありますね。あとはどんなプロンプトを入れて生成されたのかを記録として残して欲しいというのは言われます。つまりこういう指示を入れるとこうなるというのを残して欲しい、それがあれば次にプロンプトを入れる時の参考になるみたいな話です。MagicPodはすべての履歴をコメントとして保存しているので、そこにプロンプトを保存するように変えれば実現可能だと思います。

Autopilotのデモをする伊藤氏

Claudeとかだとコード生成についてはほとんどハルシネーションは起こらないということも聞いてはいるんで、試してみたい気もするんですが、Geminiに比べるとコストが数倍になってしまうので、今のままユーザーに無償で提供するというわけにはいかないと思います。なのでそれを使う場合はユーザーにある程度負担して貰うという仕組みを入れないといけないかなと。

その場合も何でも選べるという状態は良くないと思うので、MagicPodとして「このモデルではこういう特性があります、高価だけど性能が良いとか安価だけど間違いも起こります」といったような指針は必要かなと。テストの要約を作るという機能については、あまり高価で高性能なモデルを使わなくてもいいんじゃないかという感じに使い分けをしていきたいと思います。

Copilotの本家であるGitHubに「ソフトウェア開発はグループワークなんだからもっとグループワークを支援する機能はないのか？」という質問をしたんですが、大した回答は貰えませんでした。Autopilotにはそういう発想はあるんですか？

伊藤：今のところはそういう発想はないですね。ただフィードバックとしてあったのは、テストの粒度を揃えたいというリクエストですね。これはグループの中でテストを分担してやる時にチームとして揃えたい、例えば今回のプロジェクトはこういう命名規則でやりたいといったようなことを統一したいというリクエストですね。Claudeとかだと共通して指示したい内容をルールファイル（claude.md）で定義できるので、そういうグループとしての決まりを生成AIに与えることが可能になると思います。

プログラマーからすると、テストを作るというのは面倒な作業です。そこで大規模な開発だと専任のテスターみたいな人がいて、そういう人の仕事をMagicPodはテスト自動化という発想で助けていると思っています。コードは書けないけどテストを作ってQAするという仕事をさらに速く正確にすることで、グループワークを支援している、と言えるかもしれませんね。あとコードも毎回ゼロから作るわけではなく、既存のコードに機能追加したり、直したりするわけですよね。そうすると前のバージョンで作ったテストはそのままだと失敗するわけです。でもコードの修正に合わせてテストを再度生成することができますので、単純なんだけど面倒な作業を減らすことができるようになります。

もうひとつ言えば、グループとして誰がどんなテストをやったのか？という統計情報は監査の目的で必要だと言われてはいるのでその部分、つまりテストの実行を統計的に見るという機能は今後やっていきたいなと考えています。

テストというのはそのソフトウェアが期待通り動いているのか？を確認する作業ですけど、これは見方を変えたら、非機能要件でもある処理速度を測ることにも使えますか？

伊藤：それはありますね。あるお客さんが、リリースしたスマホのアプリが正常に動いているかを確認するという目的でテストを実行しているというのは聞いたことがあります。

つまりリリースしたアプリケーションの機能を確認するんじゃなくて、正常に想定した速度で動いているかを判定するということですか？

伊藤：そうです。実際にはシステムのオブザーバビリティのツールを使えばどこで何が遅くなっているか？というのは確認できると思いますけど、何よりもユーザーと同じ視点で「何かが遅くなっている！」ということを一番先に知るためには実際に使ってみる、テストしてみることが簡単ですから。

質問に答える伊藤氏

そういう意味だとこれまでApplication Performance Monitoring（APM）でアプリの速度を測ったりサーバーの性能監視をしたりするよりも手軽にユーザーと同じ視点で異変を感じることができて、その後に原因を調査するみたいなやり方ですね。それだとMagicPodはテストの実行回数では課金してないのでコストをかけずに監視ができるということになりますね。クラウドベースのオブザーバビリティベンダーの監視コストがクラウドネイティブなシステムにおいては大きな負担になっているという実態から考えるとラジカルな発想で良いかもしれませんね。

伊藤：あとプログラマーもそうだしテストを作る人もそうだと思うんですけど、ツールはハックする余白があるほうが好きという人が多いと思うので、「このテストはいつどのモデルで生成されたのか？」を残しておくと「次は別のモデル、プロンプトで作らせてみよう」という工夫ができると思うんですよね。なのでユーザーが工夫する余白を残すような機能追加をしていきたいと思います。

この次に伊藤さんがやりたいことは何ですか？

伊藤：これまでいろいろと話してきましたけど、テストの自動修復機能を生成AIでやることが次の目玉の機能になると思います。これってアプリケーションが修正されて前のテストをそのまま実行するとUIが変わったような時には当然ですが、失敗するんですよ。そうすると次の朝に出社してテストを直して再実行みたいなことになって時間が無駄になるんですね。そうではなくてテストが失敗したらその原因を探ってテストがちゃんと実行されて成功するように修復するという機能になります。ノーコードでテストを書くというのはテストを書かない人にとって入口を拡げる意味では良いんですけど、ある程度テストに慣れてくるとこの自動修復という機能が業務そのものに大きなインパクトを与えることになるんじゃないかと想定しています。