セミナー概要

AI​を活用し、ノーコードでWebサイト&モバイルアプリの自動テストを作成できるクラウドサービスMagicPodのZoomセミナーです。MagicPodメンバーが、サービス紹介とMagicPodに関する質問にお答えします。

以下のような方は、お気軽にご参加ください。

・自動テストツールやMagicPodの利用を検討している方
・MagicPodを使っているor使ってみたが、使い方・運用の仕方・欲しい機能の実装予定など、色々質問がある。

タイムスケジュール

※セミナー資料は、イベント終了後共有いたします。

Zoomセミナーについて

・Q&Aチャットを使って質問が可能です。質問内容と回答は参加者全員に共有されるので、個別に聞く必要がある内容はセミナー後にご連絡ください。

お申し込み

お申し込みは下のボタンからお願いします。

こんにちは。MagicPod カスタマーサクセスのHaradaです。

MagicPod Autopilot、皆さんはご活用されてるでしょうか？自然言語の指示だけでテストを自動生成できてとても便利ですよね。
一方で、「気づいたらAIクレジットをたくさん消費していた・・・」という経験をお持ちの方もいるのではないでしょうか？

この記事では、Autopilotのクレジット消費を抑えながら効率よくテストを作成するためのテクニックを5つ紹介します。すぐに実践できるものばかりなので、ぜひ取り入れてもらえると嬉しいです🌟

なお、Autopilotの基本的な使いこなし方についてはヘルプページでも解説しています。：Autopilotを使いこなす
本記事では特にクレジット効率化の観点から掘り下げています。

⚠️ 注意：
Autopilotは生成AIを活用した機能であるため、同じプロンプトを使用しても結果が毎回異なる場合があります。本記事でご紹介するテクニックはクレジット消費の削減に効果的ですが、その効果を完全に保証するものではありません。実際の消費量はアプリケーションの状態やプロンプトの内容によって変動します。

なお、本記事は2026年6月時点でのテクニックをまとめたものです。MagicPodではAutopilotをより快適にご利用いただけるよう継続的にアップデートを重ねており、今後さらに使いやすく・賢くなっていく予定です。アップデートにもぜひご期待ください！

クレジットを多く使うのはどんな時？

効率化のコツを理解するには、まずAutopilotがどのようにクレジットを消費するかを知っておくことが大切です。

Autopilotは指示を受けると、実際の画面を見て操作をしながらテストを作成していきます。その際の操作の試行回数が多いほどクレジットを消費します。つまり、Autopilotが仕様を探りながら実行したり、テスト実行に失敗して再試行したりするほど消費クレジットが大きくなります。

ということは、「Autopilotが迷わず・失敗せず動ける状況を作ること」がAIクレジットの効率的な使用につながります。

テクニック①：失敗が続いたらAutopilotを自動停止させる

上記のように失敗時の上限やその時の挙動をプロンプトに付け足すのが１つ目のテクニックです。
失敗を許容する回数に関してはご調整ください。

途中で失敗が連続して発生し、以下が出力されました。

同じ種類のエラーが続いています。wait_visible（ステップ33）で失敗しています。
これは formStep2 の要素が見つからない可能性があります。
現在の画面が何の状態にあるかを確認するため、画面キャプチャを確認します。

このステップは「カートに追加」からの流れを再度実行して実際の画面を確認するのが良いでしょう。
まず画面状態を見てみます。

同じステップで2回連続して失敗しました。
ご指示の通り、ここで実行を止めて状況を整理します。

---

現象と試行内容のまとめ

**発生している現象：**
お支払い方法選択画面（ステップ12「コンビニ払い選択 → 利用規約同意 → 注文確認ボタン」）で、
画面の要素が見つからないエラー（"Cannot find a UI element for this command"）が
2回連続で発生しています。

- 1回目：`wait_visible` なしで実行 → ステップ32で利用規約チェックボックス（id=termsCheck）が
見つからず失敗
- 2回目：「次へ（お支払い方法）」ボタンのクリック後に `wait_visible` でお支払いフォーム
（id=formStep2）の表示を待機するステップを追加 → ステップ33で wait_visible 自体が失敗

**考えられる原因：**
- 前回のテスト実行後に画面がお支払い画面まで進んだ状態のまま部分実行を開始したため、
「次へ」ボタンが押せず画面遷移が起きていない可能性があります
- 部分実行の開始ステップが「コンビニ払い選択」のコメントステップからになっているため、
それ以前の「次へ（お支払い方法）」ボタンの結果の状態に依存しており、
前の実行状態が違う場合に formStep2 が表示されていない可能性があります

**次のステップの提案：**
お届け先入力から購入完了まで通しで実行して確認するか、部分実行の開始位置を
お届け先情報入力（ステップ9）まで遡らせて、正しい画面遷移の流れの中で
実行し直すことをお勧めします。

どうしますか？

Autopilotはテストを作成する際に、部分実行をして作成したステップが成功することを確認しながら作業を進めます。部分実行が失敗するとエラーの内容を元に再度テスト対象を分析し、修正を試みます。
失敗時の挙動を予め指示しておくことで、Autopilotが同じ操作を繰り返し、気づかないうちにAIクレジットを大量消費してしまうことを防止できます。

停止後は、動作を確認して対象ステップを手動で追加してから、続きのステップをAutopilotに作成を依頼すると良いでしょう。
「少し様子を見よう」と放置するよりも、早めに止めて原因を特定するとクレジット使用の効率化につながります。

テクニック②：プロンプトのスコープを絞る

基本のプロンプト：
「ヘッドホンを購入するテストを作成して」
良いプロンプト：
「ヘッドホンを購入するテストを作成します。まずはヘッドホンをカートに入れるまでのステップを作成してください。」

セミナー概要

クラウド活用やアジャイル開発の普及に伴い、CI/CDやIaC、テスト自動化といったDevOpsの導入は広く進むようになりました。

一方で、実際の現場では、「どこで工数が膨らんでいるか見えない」「開発とインフラの連携が属人化している」「テストがボトルネックになりリリースが遅れる」といった理由から、DevOpsが形骸化しているケースが少なくありません。

本ウェビナーでは、DevOpsを真に機能させるための“最適解”を、3社の専門知見から徹底解説します。

DevOps全体の設計、プロジェクト原価やプロセスの「可視化」、そしてAIを活用した「テスト自動化の継続運用」まで、組織・プロセス・品質の3つの視点から、開発スピードと品質、収益性を両立する“止まらない開発基盤”の作り方をお届けします。

セミナーで得られること

・開発者を「迷わせない」ためのクラウド基盤設計とガードレール整備のポイント
・「継続可能なIT資産運用・可視化」の仕組み
・基盤設計と運用の分断を解消し、自社で優先して着手すべき運用の見直しポイント

こんな方におすすめです

・DevOpsを推進しているが、工数・進捗・原価のボトルネックが見えず、改善の優先順位が感覚的になっている方
・DevOpsが真の価値を発揮する組織体制や文化を知りたい方
・CI/CDを導入したものの、自動テストの作成・保守負荷が高く、結局テストがリリースの足枷になっている方

セミナー概要

「テスト自動化は進んでいるのに、リリースのたびにバタバタする」
そんな経験はありませんか？

テストを定期実行しているだけでは、コード変更のたびに品質を担保することはできません。本当の意味でソフトウェアの品質を高めるには、テスト自動化を開発フロー全体に組み込み、QAチームと開発チームが同じパイプライン上で動くことが重要です。

本ウェビナーでは、ノーコードでE2Eテストを自動化できる「MagicPod」と、柔軟なCI/CDパイプラインを構築できる「CircleCI」の連携方法を、ライブデモを交えてゼロからご説明します。「CI/CDって難しそう」「どこから手をつければいいかわからない」という方でも、2つのツールを組み合わせることで何が実現できるのか、具体的なイメージを持ってお帰りいただける内容です。

また、QAチームが管理したいテストはMagicPodで、開発チームがやりたい検証はCircleCIで、とそれぞれの役割に合った使い方の住み分けについても解説します。チーム間の連携をスムーズにしながら、品質を落とさずリリースできる開発体制を一緒に考えましょう。

タイムテーブル

こんな方におすすめです

・MagicPodを使っている／検討中で、CI/CDとの連携に踏み出せていない方
・QAチームと開発チームの連携をもっとスムーズにしたい方
・GitHub Actionsを使っているが、設定・運用の複雑さに課題を感じている方
・DevOpsやCI/CDに興味はあるが、何から始めればよいかわからない方

AIテスト自動化プラットフォームを提供する株式会社MagicPod（東京都中央区、代表取締役：伊藤 望）は、クラウドブラウザテストの実行エンジンとして、Microsoft が開発するオープンソースフレームワーク「Playwright」の正式サポートを開始しました。

AIテスト自動化プラットフォーム「MagicPod」について

「MagicPod」は、モバイルアプリテスト、ブラウザ(ウェブアプリ)テストの両方に対応したAIテスト自動化プラットフォームです。プログラミングなどの特別なスキルがなくても直感的に使うことのできるデザイン、クラウドでのサービス提供によるメンテナンス性の高さ、AI技術を活用した自動修正によるテストプログラム修正の手間削減などによりリリースサイクルの高速化を支援します。IT業界のリーディングカンパニーを中心にすでに500社以上の企業が導入しています。

PR TIMES

AIテスト自動化プラットフォームを提供する株式会社MagicPod（東京都中央区、代表取締役：伊藤 望）は、AIエージェントがWebサイトを自動巡回し、リンク切れ・誤字脱字・デザイン崩れ・アクセシビリティなどの品質問題を検出するWebサイト品質チェックツール「SiteRover（サイトローバー）」の提供を開始したことをお知らせします。

AIテスト自動化プラットフォーム「SiteRover」について

SiteRoverは、URLを入力するだけでAIエージェントがサイト内を自動巡回し、リンク切れ・誤字脱字・デザイン崩れ・アクセシビリティといった品質問題を自動的に検出。並列処理により、大規模サイトでも短時間で問題を把握でき、生成AIとルールベースを組み合わせることで高精度な問題検出と誤検知の低減を実現します。企業のサービスサイト、ECサイト、官公庁・自治体の情報サイトなど、幅広いサイトで利用が可能です。

PR TIMES

Enterprise Zine

こんにちは。MagicPodエバンジェリストのYoshiki Ito / 伊藤由貴です。

先日QA Success Panel #2 というオンラインイベントを開催しまして、多くの方にご視聴いただきました。

QA Success Panel 〜品質を上げるための「いつもどおり」を変える〜 - connpass

イベントレポート記事はこちらです。

QA Success Panel 〜品質を上げるための「いつもどおり」を変える〜

お昼休み1時間のイベントで、実際のディスカッションの時間は正味45分程度だったので、アンケートでも「もっと聞きたかった」という反応をたくさんいただきました。 実はパネリスト・モデレーター側も同じ気持ちでして、開催後に「もっと話そうぜ！」ということになり、先日3人でアフタートークを開催しました。

今回はそのアフタートークの際に話した内容を、いくつかのトピックに分けて共有します。当日「もっと聞きたかった！」と感じた方はもちろん、この記事をご覧になっているけれどもQA Success Panel #2 には参加していなかったという方はぜひ配信動画のほうも見ていただけると、より普段のQA業務に役立つヒントが得られるのではないかと思います。

We spoke with Hacobu Co., Ltd. about what led them to choose MagicPod and how they have been using it since implementation. The conversation was led by MagicPod CEO Nozomi Ito.

Hacobu Co., Ltd.

Hacobu offers the cloud logistics management solution "MOVO" series, logistics DX consulting under "Hacobu Strategy," and system integration and AI adoption support under "Hacobu Solution Studio."
Their lineup includes the truck appointment scheduling service "MOVO Berth," the fleet tracking service "MOVO Fleet," the dispatch order and management service "MOVO Vista," and the AI-powered ordering and transport optimization service "MOVO PSI" — all delivered as cloud services — as well as the smartphone app "MOVO Driver," designed to transform the working experience for truck drivers.
Hacobu supports the optimization of inter-company logistics as a logistics DX partner.

---

From left:
Tetsuya Kawase — Technology Division, Product Development Group, Vista Department
Nozomi Ito — MagicPod CEO

---

Kawase: I joined Hacobu in August 2023. I am responsible for QA on the dispatch order and management service "MOVO Vista." Hacobu does not have a centralized quality assurance department that spans the entire organization. Instead, we have built a "Product QA" structure in which a dedicated QA professional is embedded in each product team to develop and execute the optimal test strategy for that product.

With this structure, the consensus-building needed to launch new initiatives is handled entirely within the team, which means QA decisions directly shape the test strategy and quality improvement efforts for the whole team. I find it easier to move forward with genuine buy-in, and the agility it enables is a significant advantage. We have nine full-time QA engineers, each operating independently, and we hold a sharing session roughly every two weeks. We also have active informal groups — similar to guilds — where members with shared interests come together in small groups to work on things collaboratively.

I originally started my career as a software engineer, spending about 14 years at an SES company working on system development for other organizations. In the latter part of that period, I increasingly moved into roles overseeing entire teams and projects, and on smaller engagements I had more and more opportunities to handle scenario testing and integration tests.

After that, I joined another company in a business planning and SI vendor liaison role, and became involved in an app development initiative the company was running at the time. Through that experience, I discovered the interest of engaging not only with the builder's perspective of quality — "making sure the system works" — but also with quality from a user's point of view: "what does it take for customers to be genuinely satisfied?" That sparked my interest in the field, and after gaining experience at a third-party verification firm, I joined Hacobu.

---

Reasons and Background for Selecting MagicPod

Kawase: Product QA is one of Hacobu's strengths, but it also carries the risk of over-reliance on individual knowledge. When I joined, the company was in a phase that prioritized the speed of agile development, and regression testing had not been properly established — the prevailing understanding was that manual testing would cover what it could. The judgment of which tests to run depended on the discretion of each individual, and the situation was such that incidents like "there's a regression somewhere but we can't identify the cause" could easily arise.

Ito: Was it you who drove the adoption of automated testing and the selection of a specific tool?

Kawase: It had already been under consideration before I joined. It seemed to be a concern at the leadership level as well, and when MagicPod was introduced, our CEO responded positively. After I joined, the evaluation came down to a choice between a recording-type tool and MagicPod. In that process, we assessed MagicPod favorably for its straightforward creation flow and high maintainability. Personally, I also appreciated that Shared Steps were available.

Incidentally, I first came across MagicPod at my previous job at a third-party verification firm, when a client company was exploring automation of their regression testing. Another person was leading that effort so my involvement was limited to trying it out, but they ultimately adopted it there as well.

Ito: Many companies appreciate the ability to run tests without limits — was that not a significant factor for you?

Kawase: At the time, I don't think I had a concrete enough picture to fully appreciate it. That said, hearing you mention it now, being able to run tests every day without hesitation is genuinely a major benefit.

Ito: Thank you! Were overseas testing tools or Selenium also among the candidates?

Kawase: In the earlier rounds of evaluation, yes, those were on the list. However, recording-type tools — which are common among overseas products — tend to depend heavily on how each individual builds tests, making it difficult to maintain consistent quality. Coding-based tools, on the other hand, raised concerns about the onboarding learning curve, since programming experience varied across team members, and so they were ruled out. Ultimately, we selected MagicPod for its ability to support structured test creation and its high maintainability.

Ito: With product teams operating separately under a Product QA structure, I imagine it can be difficult to drive adoption across the organization. How did you approach that?

Kawase: Initially there was another person driving the effort alongside me, and that person first introduced MagicPod in the truck appointment scheduling service "MOVO Berth." Through that process, we established a full set of review mechanisms, review criteria, and test creation guidelines, and when rolling out to other products, we applied those frameworks while continuing to refine them.

I believe that in test automation, what matters more than the tool itself is designing the structure through which quality is assured. It is often misunderstood that "because it's no-code, no design is necessary" — but my view is that "no-code ≠ no design."

In practice, when teams jump straight into implementation without sufficiently thinking through the test structure, data handling, and rule design — the "architecture" of automation — changes become difficult to make later, and the result is often what I would call a hollowing-out of the automation: failed tests get left unresolved, and the whole effort falls into disuse.

At the same time, the mechanics of how to use the tool itself can be picked up along the way through hands-on practice. That is precisely why our team prioritized getting the hard-to-change, low-leverage-once-set elements — test structure, data design, and operational rules — sorted out before we began implementation.

---

Foundation Design in the Early Stages of MagicPod Implementation

Ito: What specifically did that preparation involve?

Kawase: In software development, coding standards and variable naming conventions are typically in place to ensure a baseline of quality. Drawing on my own background as an engineer, I applied a similar approach to test automation and organized the groundwork into four broad layers.

The first was structural design, with post-implementation maintainability and ease of implementation in mind. By clarifying which MagicPod features map to which traditional test structure concepts, the team was able to develop shared understanding and move forward with implementation on a common foundation.

---

Next, we established guidelines and naming conventions to enable safe Data Driven Testing. Naming rules are differentiated by variable type — for example, shared variables use uppercase snake_case, while variables within test cases use camelCase.

---

The third layer was operational design. Establishing structure, guidelines, and conventions alone is not enough to ensure they are actually followed, so we documented the implementation flow for test cases, the review flow, and the process from investigating a test failure through to resolution.

Finally, we prepared a "usage guide." In the early days after implementation, test case creation was a process of trial and error, so we set up a page to accumulate observations and anti-patterns from implementation, allowing the team to share good practices and patterns to avoid. Through this preparation, I believe we were able to build a foundation where operations would not become hollow over time and where adjustments would remain manageable.

Ito: That is impressive. It is rare for an organization to have this level of preparation in place before introducing a tool. I felt that the "no-code ≠ no design" philosophy is genuinely reflected in how you operate.

Kawase: Thank you. That said, maintaining this operational foundation over the long term also required keeping the team motivated in the early stages. What proved helpful there was MagicPod's analytics feature. In particular, we set stabilizing the "health score" — which measures the health of operations — in the 90s as our near-term goal. Because the evaluation criteria are broken down into incremental stages with the importance and priority of each item displayed, it was easy to set short-term milestones, and I felt that contributed to sustaining motivation.

---

How MagicPod Is Being Used

Kawase: Currently, we have automated testing for MOVO Berth, MOVO Vista, and a third — including a smartphone app — bringing the total to three products covered by MagicPod. Accounts have been issued to developers as well, bringing the total to around 50 users. Depending on the team, in the product I am involved in, MagicPod is used as part of the release approval process, and there are cases where developers independently run MagicPod outside the regular release schedule to make their own release judgments.

Scheduled Execution kicks off at 7:30 in the morning and completes in about 45 minutes, with results delivered to a dedicated Slack channel that only receives execution results. In general, when a Batch run test fails, QA investigates — but members who are engaged will proactively look into the error on their own. They first determine whether the issue is transient, and if it turns out to be a defect on the frontend or backend, a fix is applied and the release approval run is executed again.

There was actually a point in the past where production releases were going out before the daily test results had been reviewed, and we had a problem with testing and releases being disconnected. So we established a clear release standard: "all morning tests must have passed." For runs outside that window as well, we use a workflow automation tool — a Slack command triggers a Batch run automatically.

Ito: It sounds like your development engineers are also engaging with MagicPod. Have there been any positive responses since the rollout?

Kawase: We have received positive feedback about the fact that defects that previously slipped through testing are now being caught before release. There is a shared understanding across the entire team that proper verification happens before a release goes out, and I feel that the resulting sense of assurance is a visible effect. Beyond that, incorporating MagicPod into the release approval process has led to engineers proactively asking "Did you run MagicPod?" — and a culture has emerged where the team locks down release content by the day before to make it in time for the morning tests. That improvement in quality awareness across the whole organization has been one of the most significant outcomes.

Ito: It is wonderful to see such a healthy culture taking root across the development team. For that kind of stable daily operation to be sustainable, the maintainability of the test cases themselves also becomes important. Do you have any criteria for granularity when creating Shared Steps, or any tips for improving maintainability?

Kawase: As a baseline, we always implement API calls as Shared Steps — handling everything from the call itself through to result retrieval and return as a single unit. Beyond that, our policy is to actively consolidate anything that is used frequently or corresponds to shared UI components on the frontend.

Another practice we use to improve maintainability is an automated review system leveraging AI. Specifically, we integrate Cursor with MagicPod's MCP. We preload all of our coding rules and variable naming conventions into Cursor's configuration and created a custom command from there.

When you run this command and specify a test case number, the AI automatically performs a review against the conventions and feeds back the points that need to be corrected. In practice, each team member runs this automated review in their local environment, writes the output to Notion, and then uses that as the basis for requesting a final confirmation review from other team members. Once there are no issues, the test case moves into live operation.

Beyond reviews, we also run processing via Cursor through the MCP server to re-execute only the tests that failed in a Batch run, and to fetch data via the API and generate graphs showing trends in execution time. Aggregation and analysis tasks that would take more effort through the GUI can be executed simply by entering a natural language prompt, and I feel that has significantly expanded the freedom we have in managing test automation operations.

Ito: It sounds like quite a sophisticated setup — automated AI-powered reviews, aggregation via MCP, and more. Going forward, how are you thinking about rolling these practices out to other team members and teams within the company?

Kawase: Our organizational culture places a very strong emphasis on individual autonomy and team-level optimization. So rather than managing things top-down, the challenge going forward is how to expand these practices while leveraging the initiative of people on the ground. That said, one of Hacobu's strengths is a culture where proposing to try a new tool gets a "let's go for it" response from the company, and where lively discussion happens across team boundaries on Slack and elsewhere. I think the path forward is to leverage that environment to spread adoption organically.

---

Toward a QA Organization That Keeps Pace with the Speed of AI-Driven Development

Ito: What challenges are you hoping to address going forward with the help of AI?

Kawase: Proficiency with AI varies across teams and individuals. Some members struggle to effectively translate AI suggestions into test cases, while others find themselves in trial-and-error mode when unexpected side effects arise during fixes. There is also a significant challenge around not being fully aware in advance of which MagicPod test cases will be affected by a given change — even when those tests are part of the release approval criteria, the impact sometimes only becomes clear after the fact. That invisible blast radius is something I want AI to help us detect.

Ito: You mean identifying the scope of impact from a change. One approach that has emerged recently is to pass a GitHub pull request URL to an AI editor like Cursor via MagicPod MCP and instruct it to "list the tests that are likely to be affected by this change" — which allows for a reasonable degree of pre-run impact assessment without actually executing the tests.

Kawase: That sounds very useful — I'll look into it. Our development environment is quite complex, with dev and staging environments running alongside topic environments for each development unit. When resources allow, we can do comprehensive checks in the topic environment, but when things get busy, there are inevitably cases where verification ends up being limited to the dev environment.

Inheriting tests created by someone else is particularly challenging — it is not easy to read back the design thinking behind them. As a result, the tendency is to apply local fixes only to the step where an error occurred, without considering the overall structure, and that is one of our significant operational challenges.

Ito: I see — the more complex the environment, the more important it becomes to triage before running tests. Being able to reduce unnecessary executions through early detection is a meaningful benefit. And beyond just fixing the error location, supporting developers in making corrections that account for the broader context — in a way that is simpler and more accurate — seems like it will become increasingly important going forward.

Kawase: Exactly. On that point of "support for making the fix," I feel that MagicPod Autopilot would become even more powerful if it were extended to support Shared Steps. Even now, I have confirmed that when data patterns are in use, Autopilot appropriately retrieves the relevant variables — and that seems like something we can put to use. For things like calculation logic that I don't work with often, it feels easy to delegate the finer details to it.

Ito: We talked about Cursor and MCP for impact assessment earlier, but there is a step beyond that worth mentioning as well. Depending on how it fits your operational flow — are you currently using the approach of reviewing code in an AI editor and then applying those review results directly to test fixes via MCP?

Kawase: We are not doing that yet.

Ito: Actually, it has recently become possible to call Autopilot from MCP, so that by instructing the editor to "apply these review results to the tests as well," new test creation and modifications can be carried out automatically. At this point in the current specifications, changes are applied directly to the main branch rather than a test branch, so there is one extra step needed — checking the execution history to confirm everything looks correct.

Kawase: For newly created tests, having changes applied directly to the main branch is completely fine. That sounds very useful — I will definitely try it. Thank you.

Recently, AI-powered code generation and similar tools have dramatically accelerated the speed of feature development, and there is a shared sense of urgency within the company that if QA remains reliant on traditional manual testing, it will become a bottleneck for the entire release process.

Ito: How to keep QA pace with development speed as AI continues to accelerate it is a major theme for the industry as a whole. What will be needed going forward is not disposable tests written purely for speed, but tests that are resilient to change and built for stable long-term operation. MagicPod will keep evolving to support that.

---

Closing

Kawase: In our initial meetings after implementation, you shared common failure patterns and operational tips with us upfront — and that enabled us to design a structure with long-term operation in mind from the very beginning. Looking back on these past two years, I am genuinely grateful that we got that initial foundation right.

I think most engineers today understand the value of automating regression testing. But the true value, I would argue, lies in being able to achieve that "without depending on any one individual's technical ability — with consistent quality regardless of who touches it." My honest assessment is that adopting MagicPod was the right call — as a tool for embedding an automation culture across the organization and eliminating over-reliance on individuals.

Hacobu Co., Ltd.

• Corporate site: https://hacobu.jp/
• Careers: https://career.hacobu.jp/
• Tech blog: https://zenn.dev/p/hacobu
• Tech entrance book: https://hacobu.notion.site/entrance-book-engineers

株式会社Hacobu様に、MagicPod選定の決め手や導入時から現在までの活用状況について、MagicPod代表の伊藤がお話を伺いました。

株式会社Hacobu

クラウド物流管理ソリューション「MOVO（ムーボ）」シリーズと、物流DXコンサルティング「Hacobu Strategy（ハコブ・ストラテジー）」、システムインテグレーション・AI導入支援「Hacobu Solution Studio（ハコブ・ソリューションスタジオ）」を展開。トラック予約受付サービス「MOVO Berth」、動態管理サービス「MOVO Fleet」、配車受発注・管理サービス「MOVO Vista」、AI発注・輸送最適化サービス「MOVO PSI」などのクラウドサービス、ドライバーの働き方を変えるスマホアプリ「MOVO Driver」の提供に加え、物流DXパートナーとして企業間物流の最適化を支援しています。

---

---

左から
・川瀬 鉄矢さん　テクノロジー本部 プロダクト開発統括部 Vista部
・伊藤 望　MagicPod CEO

---

川瀬：Hacobuには2023年の8月に入社しました。私は配車受発注・管理サービス「MOVO Vista」のQAを担当しています。弊社には組織を横断する品質保証部門がなく、各プロダクトチームに専任のQAが入ってプロダクトごとに最適なテスト戦略を考えて進めていく“プロダクトQA”の体制を構築しています。

この体制ですと、新たな施策を始める際の合意形成がチームメンバー内で完結するため、QAの意思決定がそのままチーム全体のテスト戦略・品質向上に直結します。納得感を持って進めやすく、フットワークの軽さが大きなメリットだと感じています。QAエンジニアは正社員で9名いまして、個々に動いていますので2週間に1回ほど共有会を実施しています。また、興味関心の近いメンバーが少人数で集まって取り組む"ギルド"のような活動も活発です。

私はもともと開発エンジニアとしてキャリアをスタートし、SES企業で他社のシステム開発を14年ほど担当していました。その中で、キャリア後半にはチームやプロジェクト全体を見る立場になることが増え、小規模案件であればシナリオテストや結合テストを担当する機会が多くなっていきました。

その後、別の事業会社で事業企画やSIerとの折衝業務を担当することになり、当時その会社が進めていたアプリ開発の担当として参画しました。そこで「きちんと動くシステムを作る」という作り手側の品質だけでなく、「どうすればお客さまに満足してご利用いただけるか」というユーザー視点の品質に向き合う面白さを実感し、第三者検証会社で経験を積んだ後、Hacobuに入社しました。

---

MagicPod選定の理由・経緯

川瀬：プロダクトQAはHacobuの強みである一方、個人の感覚に依存してしまうという面もあります。私が入社した当時、アジャイル開発によるスピードを優先していたフェーズだったこともあり、リグレッションテストはマニュアルテストでカバーできる範囲で対応するという認識で整備されていませんでした。「どのテストを実施すべきか」の判断が実施者の裁量に依存しており、「どこに原因があるか分からないがデグレが起きている」という事象が発生しうる状況だったと言えます。

伊藤：自動テストの導入や、具体的なツールの選定は川瀬さんが推進されたのでしょうか？

川瀬：私が入社する前から検討されていました。経営層も含めて気にかけていたようで、MagicPod導入の際は弊社の代表も好意的な反応をしていました。私が入社した後は、レコーディングタイプのツールかMagicPodかという2択で検討を進めました。その中で、MagicPodは作成フローが容易であること、メンテナンス性も高いことを評価しました。個人的には共有ステップが用意されている点も良いと思いました。

ちなみにMagicPodは前職の第三者検証にいた頃、業務委託先の会社さんがリグレッションテストの自動化を検討されていた際に知りました。別の担当が進めていたので私は触る程度だったのですが、最終的にその会社さんでも導入されていました。

伊藤：無制限でテストが実行できる点を評価いただく会社さんも多いのですが、そこはそれほど重要なポイントではなかったですか？

川瀬：当時はそこまで具体的にイメージできていなかったかと思います。ただ、今おっしゃっていただいて毎日気兼ねなく実行できる状態は確かに大きなメリットだと感じました。

伊藤：ありがとうございます！海外製のテストツールやSeleniumなども候補でしたか？

川瀬：以前の検討ではそうしたツールも候補に入っていました。ただ、海外製ツールに多いレコーディングタイプは個人の作り方に依存しやすく、品質にばらつきが出やすい懸念がありました。また、コーディングベースのツールはメンバーによってプログラミング経験にばらつきがあり、立ち上がりの学習コストが懸念されたため候補から外しました。最終的に、構造的に作成できてメンテナンス性も高いMagicPodを選定しています。

伊藤：プロダクトQAでチームが分かれていると導入推進が難しいのではないかと思うのですが、どのように工夫されていますか？

川瀬：当初は推進するメンバーがもう一人いまして、その方が最初にトラック予約受付サービス「MOVO Berth」で導入しました。そこでレビューの仕組みやレビュー観点、テスト作成時の規約などをひと通り整備しまして、他プロダクトに展開する際はその仕組みを成長させながら適用していくというアプローチを取っています。

テスト自動化は、ツールの導入そのものよりも「どのような構造で品質を担保するか」を設計することが重要だと考えています。よく「ノーコードだから設計は不要」と誤解されがちですが、私は「ノーコード≠ノーデザイン」だと思っています。

実際に取り組む中で、テストの構造やデータの扱い、ルール設計といった“アーキテクチャ”を十分に考えずに実装から入ってしまうと、後から修正が難しくなり、結果として「失敗したテストが放置され、自動化が廃れてしまう」といった形骸化を招くケースが多いと感じています。

一方で、ツールの使い方自体は実際に触りながらでもキャッチアップ可能です。だからこそ、私たちのチームでは実装を始める前にテスト構造やデータ設計、運用ルールなど、後から変更しづらくレバレッジが効きにくい部分について初期段階で整備しました。

---

MagicPod導入初期の基盤設計

伊藤：具体的にどのような整備をされたのでしょうか？

川瀬：開発の現場ではプログラムのコーディングルールや変数規約があり、最低限の品質を担保する仕組みが導入されている場合がほとんどです。私自身がエンジニアとして開発経験を持っていたこともあり、それと同様のアプローチをテスト自動化にも適用しようと考え、大きく4つのレイヤーに分けて整備を進めました。

最初は運用後のメンテナンス性と実装のしやすさを考慮し、構成の設計に取り組みました。MagicPodの各機能が従来のどのテスト構成概念に当てはまるのか役割が明確になり、チーム内で共通認識を持って実装を進められるようになったと考えています。

---

次に安全なデータ駆動テストが実装できるようガイドラインと命名規約を整備しました。変数の種類ごとに命名規則を分けており、例えば共有変数は大文字のスネークケース、テストケース内変数はキャメルケースといった形で統一しています。

---

3つ目が運用設計です。構成やガイドライン・規約を整備しただけでは運用されない可能性があるため、テストケースの実装フローやレビューフロー、テスト失敗時の調査から修正に至るまでのフローを明文化しました。

そして最後が「活用の手引き」の準備です。導入直後は手探りでテストケースの実装を進めていたため、実装時の気付きやアンチパターンを蓄積するページを用意し、良いやり方や避けるべきパターンをチーム内で共有できるようにしました。こうした整備によって、運用が形骸化せず、修正もしやすい状態の土台を作ることができたと思っています。

伊藤：素晴らしいですね。ツール導入の前段階でここまでしっかり整備されているケースは珍しいと思います。「ノーコード≠ノーデザイン」という考えが運用にしっかりと反映されていると感じました。

川瀬：ありがとうございます。ただ、こうした運用基盤をしっかり継続していくうえで初期段階におけるチームのモチベーション維持も重要でした。そこで役立ったのがMagicPodのアナリティクス機能です。特に運用の健全性を測定してくれる「ヘルススコア」を90点台で安定させることを当面の目標に設定しました。評価項目が段階的に分かれており項目ごとの重要度や優先順位も表示されるため、ゴールを短いスパンで区切りやすく、モチベーションの維持につながったと感じています。

---

MagicPodの活用状況

川瀬：現在はMOVO BerthとMOVO Vistaに加え、スマホアプリも含めて3つをMagicPodで自動化しています。アカウントは開発者にも発行しているため、50人ほどになっています。チームによりますが私が参加しているプロダクトではリリース判定にも活用しており、定期リリース外のタイミングで開発者が独自にMagicPodを実行してリリース判定を行うこともあります。

スケジュール実行は朝の7時半から動かして45分ぐらいで終わり、実行結果だけを通知するSlackチャンネルに結果が届きます。基本的にはMagicPodの一括実行が失敗するとQAが調査に入りますが、関心を持っているメンバーは自発的にエラー原因の確認に動いてくれます。一時的な問題かどうかを切り分け、フロントエンド・バックエンド側の不具合であれば修正のうえ、再度リリース判定として実行しています。

実は以前、日次テストの結果を確認する前に本番リリースされてしまうことがあり、テストとリリースが結びついていないという課題がありました。そこで「朝のテストがすべて成功していること」を明確なリリース基準として設定しました。それ以外のタイミングでの実行に関しても自動ワークフローツールを利用していまして、Slackでコマンドを打つと勝手に一括実行が流れる仕組みになっています。

伊藤：開発エンジニアの方たちもMagicPodを見ていただいているようですが、導入してから良いフィードバックなどありましたか？

川瀬：テストで拾いきれなかった不具合がリリース前に検出できている点について評価してもらっているようです。リリース前にきちんと動作確認するという共通認識でチーム全体が動いているため、それが安心感につながっているのは目に見える効果として表れていると感じます。また、リリース判定に組み込んだことで開発エンジニアが「MagicPod実行した？」と気にかけてくれたり、朝のテストに間に合わせるために前日までにリリース内容を確定させる文化がチームに生まれたりと、組織全体の品質意識が高まったのも大きな収穫でした。

伊藤：開発チーム全体に良い文化が生まれているのは素晴らしいですね。そうした毎日の安定した運用を支えるうえで、テストケース自体の保守性も重要になってくるかと思います。共有ステップを作る際の粒度の基準や、保守性を高めるためのコツなどありますか？

川瀬：基本的にAPIの部分は必ず共有ステップとして、呼び出しから結果の取得、返却までを一連で実装する方針です。それ以外にも、頻繁に使用されるものやフロントエンド側の共通部品で使われているものについては、積極的に共通化する方針で進めています。

また、保守性を高めるもう一つの工夫としてAIを活用した自動レビューの仕組みがあります。具体的にはCursorとMagicPodのMCPを連携させています。Cursor側の設定にあらかじめ弊社のコーディングルールや変数の命名規約をすべて読み込ませておき、独自のカスタムコマンドを作成しました。

このコマンドを打ってテストケースの番号を指定すると、AIが規約を参照しながら自動でレビューし、修正すべきポイントをフィードバックしてくれます。実際の運用フローとしては、各メンバーが手元のローカル環境でこの自動レビューを実行し、出た結果をNotionに書き込みます。そして、その内容をもとに他メンバーへ最終確認のレビューを依頼し、問題がなければ本番の運用に乗せる、という流れになっています。

レビュー以外にもCursorからMCPサーバーを経由して、一括実行で失敗したテストだけを再実行する処理や、APIからデータを取得して実行時間の推移をグラフ化するといった検証も行っています。GUIでは少し手間がかかる集計や分析処理も自然言語のプロンプトを入力するだけで実行できるため、テスト自動化の運用の自由度が格段に上がったと感じています。

伊藤：AIを活用した自動レビューやMCPを通じた集計など、かなり高度な工夫をされている印象です。今後、そうした仕組みを社内の他のメンバーやチームへどのように展開させていこうとお考えですか？

川瀬：弊社の組織文化は個の自律やチーム最適を非常に重んじています。そのためトップダウンで管理するのではなく、どう現場の主体性を生かしながら広げていくかが今後の課題だと捉えています。ただ、弊社の良いところとして新しいツールを試したいと提案すれば会社として「やってみよう」と後押ししてくれ、チームの垣根を越えてSlackなどで活発に意見交換が行われる文化があります。そうした環境を生かしながら社内に浸透させていく必要があると考えています。

---

AI時代の開発スピードに伴走するQA組織へ

伊藤：今後AIを活用して解決していきたい課題はどのようなところでしょうか？

川瀬：AIに対する習熟度もチームや個人によって理解度の差が生じます。AIの提案をテストにうまく落とし込むのに苦労するメンバーや、修正時に予期せぬ影響範囲を発生させてしまい試行錯誤しているメンバーもいます。また、ある修正がMagicPodのどのテストケースに影響を及ぼすかを事前に把握しきれず、リリース判定に使っているにもかかわらず影響が後追いで判明してしまうのも大きな課題です。この見えない影響範囲の検知を、AIで防ぎたいと思っています。

伊藤：変更に対する影響範囲の特定ですね。最近ですと、MagicPod MCPを活用してCursorなどのAIエディタにGitHubのプルリクエストURLを渡し、「この修正に影響がありそうなテストをリストアップして」と指示することで、テストを実行せずともある程度の洗い出しが可能です。

川瀬：それは便利ですね、確認してみます。弊社の開発環境はdevやstgに加え、開発単位のtopic環境も並走しており非常に複雑です。リソースに余裕があればトピック環境で網羅的に確認できますが、忙しいとどうしてもdev環境での確認のみで済ませてしまうケースが出てきます。

特に他人が作成したテストを引き継ぐ場合、その背景にある設計思想まで読み取るのは容易ではありません。その結果、全体の構造を考慮せず「エラーが出たステップだけを局所的に直す」といった対応になりがちで、それが運用の大きな課題だと感じています。

伊藤：なるほど、環境が複雑な分、テスト実行前の切り分けが重要になるわけですね。事前の検知によって無駄な実行を減らせるのは大きなメリットかと思います。また、エラー箇所の修正だけでなく背景まで踏まえて、より簡単に、かつ正しく直せるようなサポートも今後は重要になりそうですね。

川瀬：おっしゃる通りです。その「直すためのサポート」という点では、現在提供されているMagicPod Autopilotについて、共有ステップに対応していただけるとさらに強力になると感じています。現時点でもデータパターンを使用していれば関連する変数を適切に取得してくれることは確認できており、この点は活用できそうです。普段使わない計算ロジックなど、細かな使い方も任せやすい印象です。

伊藤：先ほど影響範囲の特定でCursorとMCPの話をしましたが、さらにもう一歩進んだ使い方もあります。運用フローとの兼ね合いもあるかと思いますが、AIエディタ上でコードをレビューし、その結果をMCP経由でそのままテストの修正に反映させるような使い方はされていますか？

川瀬：今のところ、そういった形では活用できていません。

伊藤：実は最近、MCPからAutopilotを呼び出せるようになり、エディタから「このレビュー結果をテストにも反映して」と指示するだけでテストの新規作成や修正を自動で行ってくれるようになりました。ただ、現時点の仕様ではテストのブランチではなくメインブランチに直接変更が反映されるため、実行履歴を見て問題がないか確認していただくひと手間が必要になります。

川瀬：新規作成のテストであれば、メインブランチへの直接反映でも全く問題ありません。それは非常に便利ですね、ぜひ試してみます。ありがとうございます。

最近はAIによるコード生成などで機能開発のスピードが劇的に向上しており、QAが旧来のマニュアルテストのままではリリース全体のボトルネックになるという危機感が社内にもあります。

伊藤：開発スピードがAIで加速していく中、QAがいかにそれに追いつくかは業界全体の大きなテーマですね。単にスピードを求めた使い捨てのテストではなく、変化に強く安定運用できるテストこそこれから求められてくるはずです。MagicPodもアップデートを続けていきます。

---

最後に

川瀬：導入当初のミーティングで、よくある失敗事例や運用のコツを事前に共有いただいたおかげで、最初から長期運用を見据えた構造を設計できました。この2年間の歩みを振り返ると、あの最初の土台作りがしっかりできていたことは本当に良かったと感じています。

リグレッションテストを自動化する意義自体は、いまや多くのエンジニアが理解していると思います。ただ、それを「個人の技術力に依存せず、誰が触っても一定の品質で実現できる」という点にこそ、真の価値があるのではないでしょうか。組織全体に自動化の文化を根付かせ、属人化を防ぐツールとして、MagicPodを採用して正解だったというのが私の率直な感想です。

---

株式会社Hacobu

• コーポレートサイト：https://hacobu.jp/
• 採用情報：https://career.hacobu.jp/
• テックブログ：https://zenn.dev/p/hacobu
• テックエントランスブック：https://hacobu.notion.site/entrance-book-engineers

セミナー概要

「自動テストを導入したものの、画面改修のたびにスクリプト修正に追われる」「検証端末の管理やOS更新などのテスト以前の作業に時間がとられる」……。
こういった、自動テストの「運用」で挫折していませんか？
本ウェビナーでは、AIによる自動修復（MagicPod）とクラウド実機（Remote TestKit）を組み合わせることで、モバイル検証のボトルネックとなる「メンテナンス工数」と「端末管理」をどう解消するか、実機デモを中心に詳しく解説します。

本セミナーのポイント

【デモ】AI自動修復 × クラウド実機実行
UI変更があってもAIがテストを自動で直し、クラウド上の実機を動かす――実際の操作画面を通して、連携による圧倒的な効率化を体感いただきます。

運用フェーズの「3大負」を解消
スクリプト修正・端末管理・OSアップデート追従。実際に自動化に取り組んでいるからこそ直面するこれらの課題への解決策を提示します。

現場のリアルな解決アプローチ
複数の実機×自動化を運用している現場で、どのようなステップで導入・定着が進んでいるか、ケーススタディを交えてご紹介します。
※ウェビナーの内容は変更になる場合がございます。

プログラム

モバイル自動テスト、運用の壁をどう突破するか？
【プロダクト紹介】MagicPod × Remote TestKitそれぞれの強み
【連携デモ】AIテスト自動化ツール×実機クラウドで変わる、これからのテスト運用
【導入事例】事例から学ぶ、AIテスト自動化ツール×実機クラウドの導入効果
Q&A・個別相談（連携トライアル）のご案内

登壇社紹介

猪狩 智之
株式会社MagicPod / セールス
AIを活用したノーコードE2Eテスト自動化サービス「MagicPod」のセールス。モバイルアプリ・Webサービスに対して、多くの企業のテスト自動化導入を支援。QA現場で発生する「テスト作成」と「運用負荷」の課題に対し、AIとノーコードを活用した実践的な解決方法を提案している。

奥田 淳平
NTTレゾナントテクノロジー株式会社 / セールス＆マーケティング部
デバイスクラウドサービス「Remote TestKit」のセールス。Remote TestKit導入から導入後の活用設計まで一貫して支援し、「手動テストの効率化」や「自動化の立ち上げ」など、顧客のテスト業務効率化に伴走。Remote TestKitベトナム事業にも従事