【MagicPod Autopilot活用】効率的にAIクレジットを使おう(後編:テスト対象の”クセ”を伝える)


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

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

前編「すぐに使えるテクニック5選」では、効率化のテクニック5選を紹介させていただきました。
後編ではそのテクニックの中の「対象アプリの注意点を事前にまとめる」についてより詳しく解説します。実際に消費したクレジットも共に掲載しますので、皆様のテスト対象アプリケーションに沿って運用してもらえればと思います。

とはいえ、Autopilotは初めて触るアプリの独自仕様までは事前に知ることができません。テストを作成しながら仕様を探って、試行錯誤を繰り返します。
これは人間のテスターも同じですよね。初めて担当するアプリをテストするときは、先輩や仕様書からアプリの"クセ"を教えてもらうと思います。同様に、Autopilotも事前に情報を渡してあげることで、本来の力を発揮しやすくなります。

どのようにその情報をAIにわかりやすいように渡すかということですが、それもAutopilotの力を借りましょう🌟
本記事では、実際にテストケースを作成した後にAutopilotへフィードバックを求める手法をご紹介します。初回の実行では注意点を渡さず、そこで得た知見を次以降のAutopilot実行に活かすというコンセプトです。

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

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


目次

今回のテスト対象とその"クセ"

さて、このテクニックをご紹介するにあたって、ダミーのECサイトのページを作成しました。


作成したダミーのガジェットのECサイトのキャプチャ

作成したダミーのECサイト


商品の検索、カートに追加、購入者情報の入力、商品購入の確定までの一連の流れが、今回作成するテストケースのターゲットです。

しかし、このECサイトには、自動テストではなかなかハードな仕様が散りばめられています。
一例をお伝えします。

  • 「カートに追加」ボタンが商品カードをホバーしないと出現しない(opacity: 0 → hover で表示)
  • カテゴリのactive 状態に関するクラス名が 『active-x7q2』 などランダムな文字列
  • 商品カラー選択が select ではなく div ベースのカスタムドロップダウン
  • 配送日ピッカーが input type="date" ではなく完全カスタムカレンダー(div セル)
  • Toast通知がある(2.5秒で消えるため、Autopilot が検証に使いにくい) など・・・

何も"クセ"を伝えずテストする

さて、まずは何も伝えずテストを実施してみましょう。


「ヘッドホンを購入するまでのテストを作って」とAutopilotに指示を出しているキャプチャ

"クセ"を伝えずに普通にAutopilotを使う


数分が経過し、テストが完成したようです👀


Autopilotでテストが作成完了したキャプチャ

3.3クレジットを消費してテストを作成してくれました!


全体で33ステップで、今回は使用クレジットが3.3でした。(何回か試しましたが使用クレジットが5以上になるケースや3未満で済むケースもありました)

ログを見てみると、部分実行が仕様を探りながら実行した箇所がいくつかあるようでした。


カレンダーに関するステップ作成で失敗している様子のキャプチャ

やはりカレンダーの挙動は掴みにくかった様子・・・


(やはり完全カスタムカレンダーなので、Autopilotが迷いやすい特有の挙動があったようです😵‍💫)

Autopilotに注意点をフィードバックしてもらう

テストが商品購入まで完成したので、そのセッションで続けて以下のように送信します。

「このサイト固有の操作しにくい実装を洗い出し、
次回同じサイトでテストを作成する際に最初に私からあなたに伝えるべき注意点としてまとめてください」

作成時と同じセッションに続けて、プロンプトを送っているキャプチャ

作成時と同じセッションで、続けて送信してください


実際にAutopilotが初見では対処が難しかった箇所とそれをどのように対処したかがまとめてフィードバックしてくれます。


フィードバックのキャプチャ

リスト形式で、問題の箇所とその対処をまとめてくれました


Autopilotが把握しにくかった仕様について、うまくまとめてくれました👍
このままではプロンプトに含めるには少し長いため、続けて要約を依頼します。


要約を求めているキャプチャ

はじめから「プロンプト内で伝える予定」と伝えてもいいです


追加のやりとりでの使用クレジットは、0.3ほどでした。

次からのAutopilotでのテスト作成の際は、このような注意点を事前に伝えることで今回Autopilotが試行を重ねた箇所についてはヒントが与えられた状態から始まるので、スムーズにテストの作成がうまくいくことが多いです。
(生成AIの特性上、必ずしもうまくいくと断言はできませんが・・・)

次の章からは、同様のテストケースを新規に作成し、この注意点を伝えることで、AIクレジットをどれだけ効率的に利用できるかを示していきます。

注意点の伝え方①:プロンプトに含める

作成したいテストケースをプロンプトに記載したあとに、注意点として追記する方法です。


プロンプト内に先程の注意点を含めているキャプチャ

ちょっとプロンプトが長くなるのが難点ですね


こちらは、使用クレジット2.7ほどでテストケースの作成ができました。0.6ほど消費クレジットが減ったので効率的な使い方ができたのではないでしょうか。

「私が最初に伝えた注意点にさらに足すべき点はありますか?」などと追加でやりとりすることで、注意点のプロンプトをブラッシュアップしていくのもいいかもしれませんね。


「私が最初渡した注意点にさらに足すべき点はありますか?」と送信しているキャプチャ

テストケースの編集ではないので、大きなクレジット消費はありません


また、プロンプトで追記する以外にもオススメの方法があります。

注意点の伝え方②:ステップ内のコメントとして記載する

Autopilotは実行時にテストケースの内容を把握しますが、これはコメントのステップも同様です。
よって、注意点をコメントとして残すというのがかなり効果的です。

コメント上の記載という都合上、最初に詳細に出力してもらったものを記載しようと思います。
また0から同様のテストケースを作成していきます。


ステップ内のコメントに注意点を記載しているキャプチャ

場合にもよりますが、今回は1つのステップにまとめて記載します


詳細な内容を記載する場合はAutopilot使用時のキャッシュ上限にご注意ください。コメントが長くなりすぎないよう適度に要約することをおすすめします。

そして、プロンプト内にもステップ1に注意点があることを明記しましょう。


ステップ1に注意点があることを明記して新規にテスト作成を依頼しているキャプチャ

冒頭で注意点について把握してくれてます


テスト作成が完了したキャプチャ

作成時間も30%ほど削減できていました


使用クレジットは約2.56でした。0.7ほど減ったので、より効率化ができているのではないでしょうか。

MCPでAutopilotを使う場合

MCPサーバーを経由してAutopilotを使用する場合も、ClaudeのSkillsやCursorのAgent skills、ClineのClinerulesなどを活用して注意点を渡す方法が考えられます。

ただし、ツールによっては注意点がAutopilotにうまく伝わらないケースもあるため、確実に伝えるという意味では②のテストケース内にコメントとして記載する方法が現時点ではおすすめです。

まとめ

今回は「対象アプリの注意点を事前にまとめる」というテクニックを、実際のクレジット消費数値とともにご紹介しました。
注意点の伝え方をまとめると以下の通りです。



方法 消費クレジット 削減効果
(何も伝えない) 約3.3
プロンプトに含める 約2.7 約0.6削減
コメントに記載する 約2.56 約0.7削減

アプリ固有の注意点を一度まとめてしまえば、以降のテスト作成で繰り返し活用できます。
前編でご紹介した5つのテクニックと組み合わせることで、さらに効率的なAutopilot活用が実現できます。ぜひ試してみてください!

それでは、よいMagicPodライフを!


Harada

Harada

MagicPodカスタマーサクセス。自身のプログラミングの原点はノーコードツールのNode-RED。IoTエンジニア、自治体システムコンサルティングなどのプロジェクトに携わってきた。
これまでのキャリアを通じて、コーディングの時間の大半をテストコードに費やしてきた経験から、テスト導入の課題と向き合うお客さんに寄り添うサポートを心がけている。