こんにちは。MagicPodエバンジェリストのYoshiki Ito / 伊藤由貴です。普段ユーザーさんや導入を検討中の方とさまざまな話をする機会も多いのですが、テスト自動化の推進がうまくいくかどうかを左右する重要なポイントに（改めて）気づきました。それは、ツールおよびそれに関連するプラクティスを組織に定着させるには、普及推進活動と、それを担う主体が必要だということです。そしてこの「技術を普及・推進する活動」の考え方は、特定のツール導入に限らず、開発組織をよくしていく過程で広く応用できる知見でもあります。私自身、以前はテスト会社でテスト自動化技術を普及させる組織を立ち上げ、社内のエンジニアのべ約200人に技術研修を行うなどの推進活動をしていた経験があります。その経験も含めて、本記事では技術推進の現場でぶつかる「壁」と、その乗り越え方をお伝えしたいと思います。

こんにちは。MagicPod カスタマーサクセスのHaradaです。「気づいたらAIクレジットをたくさん消費していた・・・」という経験をお持ちの方もいるのではないでしょうか？Autopilotを使いこなす⚠️ 注意：目次 -->目次クレジットを多く使うのはどんな時？効率化のコツを理解するには、まずAutopilotがどのようにクレジットを消費するかを知っておくことが大切です。「Autopilotが迷わず・失敗せず動ける状況を作ること」がAIクレジットの効率的な使用につながります。テクニック①：失敗が続いたらAutopilotを自動停止させるCopy※部分実行中に同じステップで2回目の失敗が発生した際、起きている現象と試行した内容をまとめて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 自体が失敗**考えられる原因：**- 前回のテスト実行後に画面がお支払い画面まで進んだ状態

こんにちは。MagicPodエバンジェリストのYoshiki Ito / 伊藤由貴です。先日QA Success Panel #2 というオンラインイベントを開催しまして、多くの方にご視聴いただきました。QA Success Panel 〜品質を上げるための「いつもどおり」を変える〜 - connpassイベントレポート記事はこちらです。QA Success Panel 〜品質を上げるための「いつもどおり」を変える〜お昼休み1時間のイベントで、実際のディスカッションの時間は正味45分程度だったので、アンケートでも「もっと聞きたかった」という反応をたくさんいただきました。実はパネリスト・モデレーター側も同じ気持ちでして、開催後に「もっと話そうぜ！」ということになり、先日3人でアフタートークを開催しました。今回はそのアフタートークの際に話した内容を、いくつかのトピックに分けて共有します。当日「もっと聞きたかった！」と感じた方はもちろん、この記事をご覧になっているけれどもQA Success Panel #2 には参加していなかったという方はぜひ配信動画のほうも見ていただけると、より普段のQA業務に役立つヒントが得られるのではないかと思います。

こんにちは。MagicPod カスタマーサクセスのIshiiです。あなたのアイディアがテストの未来を作る！キャンペーンを開催中です🎉目次 -->目次ヘルススコアをSlackチャンネルに定期的に通知するMagicPodにはテスト結果のSlack連携機能があり、簡単にテスト結果を通知させることができます。何時に通知する？ヘルススコアの集計期間は？といった指示が不足している部分についてはClaudeが質問してくれました。（ありがたい、そして適当な指示でごめんなさい。。）スケジュール設定はサクッと完了！毎日10:00にこの内容のヘルススコアレポートが届くようになりました🎉ダッシュボードを自動生成する自動テスト運用改善のために、プロジェクトごとのテスト数や成功率、よく失敗するテストケースなど一覧で見たいケースがあると思います。そんな時、Claude Cowork x MagicPod MCPで簡単にリアルタイムダッシュボードを作成できます。よく失敗するフレーキーなテストケースを把握するために、失敗ランキングも作ってもらいました。実行履歴の一覧も確認できます。ダッシュボード作成用のプロンプト(Instructions)はGitHubリポジトリにて公開しておりますので、参考にしていただければ幸いです。組織全体の状況がわかるダッシュボードが欲しいコードベースを元にスモークテストを自動生成する次はテスト作成に挑戦してみましょう。Copy---name: magicpod-smokedescription: MagicPodを使ったスモークテストの作成・登録を行う。「スモークテスト作って」「MagicPodにテスト追加して」「重要な画面のテストをMagicPodで作りたい」「smoke test」「MagicPodテスト」など、MagicPodを使ったテスト自動化に関するリクエストが来たらこのスキルを使う。argument-hint: [テスト対象のURL または 画面名]---# MagicPod スモークテスト作成スキル## 前提確認## デフォルト設定## ステップ 1: テスト情報のヒアリング## ステップ 2: スモークテストシナリオの設計## ステップ 3: MagicPod MCPでテストケース作成## ステップ 4: 結果の報告## エラーハンドリングClaude ...

こんにちは、MagicPodメンバーのIkariです。目次 -->目次パネルディスカッションパネリスト廣田 大騎（piro-chan）さん｜ 株式会社hacomono QAエンジニア村上 槙（murashi）さん｜株式会社estie QA Managerモデレーター伊藤 由貴｜ 株式会社MagicPod エバンジェリストセッションサマリーQAチームの役割とプロダクトとの関わり方冒頭では、両登壇者からそれぞれのQA組織体制や、開発チームとの関わり方についてお聞きしました。「プロダクトを作る全員が、全ての工程で品質に関わる状態を目指しています」(piro-chanさん)現在は、ドメインごとにQAが所属し、企画・設計段階から品質活動へ参加しているとのこと。いわゆる“最後の砦”としてではなく、開発の流れそのものに品質を組み込む動きに関するお話しが印象的でした。「高速な価値提供サイクルの支えになる、というミッションをまず決めました」(murashiさん)品質を守るだけではなく、“開発スピードを落とさずに品質を高める”という視点が、QA活動全体の軸になっているとのことでした。「プロダクトの信頼性と組織の生産性を上げるために品質課題を解こう」(murashiさん)という点で価値を出していくことがジョブの中心にあると語りました。QAの守備範囲は、AIによってさらに広がっているイベントを通して特に盛り上がったテーマが、「AIによってQAの役割はどう変わるのか」という話題でした。「AIってどこまでできるんだっけ？を測るために、何でもAIにやらせてみたんです」(piro-chanさん)テスト設計、テスト実装、資料作成、ブログ執筆まで、あらゆる業務をAI前提で試行したことで、AIが得意な領域・人間が介在すべき領域を組織全体で学べたと振り返りました。「AIでテスト設計や実施ができる時代だからこそ、人間はチームやプロダクトを深く洞察する力が必要になる」(piro-chanさん)AIによって“作業”の一部が代替される一方で、これからのQAにはより高い抽象度で課題を捉える力が求められていきそうです。「AIのおかげで、『やればできるじゃん』という成功体験が増えました」(murashiさん)AI活用によって、これまで技術的ハードルが高かった領域、E2Eテスト以外の領域についても、コード理解や実装補助を

こんにちは。MagicPod カスタマーサクセスのIshiiです。あなたのアイディアがテストの未来を作る！キャンペーンを開催中です🎉目次 -->目次MagicPodのスケジュール実行、もっと柔軟にできない？MagicPodには画面上からスケジュール実行を簡単に設定できる機能があって便利です。ただ、「実行ごとに共有変数の値を変えたい」といった柔軟な実行には、現状対応しきれていません。一括実行設定番号を使いながら一部設定を上書きしてテストを実行したいそんなときに役立つのが、Claude Desktop(Cowork)とMagicPod MCPの連携です。Claude CoworkでMagicPodの定期実行をしてみよう事前準備Claude Desktopアプリをインストールしてください。Claude Coworkの利用にはPro・Teamプランなどの有償アカウントが必要です。Claude DesktopにMagicPod MCPサーバーを接続してください。設定はヘルプページを参照してください（10分ほどで完了します）。 テストケースを作成する例として、ECサイトにクーポンコードを入力する機能があるとします。まずはMagicPodでテストケースを作成しましょう。これで入力したクーポンコードが問題なく適用されているか確認するテストケースができました。一括実行設定を作成するMagicPod上で一括実行設定を作成します。実行対象は今回作成したテストケースのみに絞るため、テストケース番号を指定しています。後ほどClaudeに「この一括実行設定番号で実行してほしい」と伝える必要があるため、一括実行設定の番号と名前は控えておきましょう。Claude Desktop(Cowork)でスケジュールタスクを作成するCowork上で平日11:00にテスト実行を行うようスケジュールを設定します。タスクの指示文は以下のとおりです。## タスク概要MagicPod MCPを使って、「DemoMCP」プロジェクトの「3: クーポンテスト」バッチランを実行します。共有変数 `coupon_code` は以下のリストから今日の日付に対応するコードを取得して渡します。---## ▼ クーポンコードリスト```json{ "coupon_codes": { "2026-04-15": "SAVE10", ...

こんにちは、MagicPodでエバンジェリストをしているYoshiki Itoです。E2Eテストの自動化を進めるなかで、「カバレッジをどう定義・計測すればいいか」という問いに直面することがあります。ツール導入の目標設定や、社内での効果説明に使いたいなど、さまざまな場面で必要となるようです。本記事では、E2Eテストにおけるカバレッジの考え方を、単体テストとの違いを踏まえながら整理します。

こんにちは、MagicPodでエバンジェリストをしているYoshiki Itoです。テスト自動化を運用していると、避けて通れないのが「テストが失敗したときの原因調査」です。自動テストが増えるほど、失敗時に「なぜ失敗したのか」を確認する手間も増えていきます。スクリーンショットを一つひとつ確認したり、実行ログを確認したりしてプロダクトのバグなのか自動テストの問題なのか環境の問題かなどを切り分けるのはなかなか大変です。今回は、最近リリースしたMagicPodの「失敗分析機能」をご紹介します。実際に使ってみて「これは良いぞ」と感じたポイントや気づいたことをお伝えします。

こんにちは。MagicPod カスタマーサクセスのIshiiです。テストケースレビュー観点ワークショップで紹介している観点をもとに、実践的なレビューアイデアを10個まとめました。本記事の内容はMagicPodに限らず、自動テストツールを使う場合は参考になるかと思います。なお、本記事ではテストケース実装前のテスト設計書のレビューについては触れておりません。整理されたテスト手順や期待結果が存在することを前提として読んでください。目次 -->目次自動テストケースレビューの4つの軸テストケースのレビューには、以下の4つの軸があると考えています。目的を達成しているか安定性メンテナンス性可読性この記事では各軸に沿ってレビュー観点を整理しています。紹介する観点はあくまでアイデアなので、チームの規模や状況に合わせて取捨選択してください。レビュー観点アイデア10選本記事で紹介する10個のレビュー観点を表にまとめました。1つ1つの観点に関して、なぜこの観点が大事なのか、そして具体的にどのようなことを確認すべきかを説明していきます。目的を達成しているか観点1: 目的を達成するテストになっているか確かめたかったことを確認できるステップが実装されているかを確認しましょう。観点2: 不具合が発生したときに検知できるアサーションになっているか確認コマンド（アサーション）の選び方によって、不具合の検知力は変わります。MagicPodには確認コマンドが36種類（2026年3月時点）あります。（参考ヘルプページ：コマンド一覧）URLが一致するか確認画像差分がないか確認UI要素の値が一致するか確認UI要素が表示されているか確認ページのタイトルが一致するか確認どのコマンドをどの場面で使うか、チーム内で大まかに認識を合わせておくと、レビュー指摘が減り品質が安定します。「正常に画面が遷移したことは、このコマンドで確認する」といった共通理解が品質の底上げにつながります。安定性が高いか観点3: 不安定になりやすい箇所に待機コマンドが入っているか「ここ、待機ないと失敗しがち」という共通認識がある箇所には、必ず待機コマンドを入れるようにしましょう。画面の読み込みが遅い箇所や、外部API呼び出し後の表示更新など、タイミングに依存しやすい処理が主な対象です。テストの安定性を向上させるには観点4: 固定時間待機するコマンド

こんにちは、MagicPodメンバーのIkariです。目次 -->目次パネルディスカッションパネリストshutty（首藤 義景）さん｜テックタッチ株式会社 QA ManagerMAX（北村 駿）さん｜エン株式会社 QA Lead / Staff QA Engineerモデレーター伊藤 由貴 ｜ 株式会社MagicPod エバンジェリスト 1. 現在のポジションに至るまでの経緯まずは、お二人がどのようにして現在のポジションに至ったのか。「最初からQAマネージャーを目指していたわけではなくて、気づいたら“やるべきこと”が増えていった、という感覚に近いですね」（shuttyさん）「品質の課題に対して“誰かがやらないといけない”という場面で、自分がやるようになっていったのがきっかけでした」（MAXさん）役職としてのリーダーではなく、課題に向き合う中で自然にリーダーシップが形成されていくプロセスが印象的でした。2. 現在の業務内容QA Manager / QA Leadの業務は、単なるテスト管理にとどまりません。「テストだけを見ているというよりは、“プロダクト全体の品質をどう担保するか”を常に考えています」（MAXさん）「QAの仕事って、気づいたら開発やビジネスの話にも踏み込んでいることが多いんですよね」（shuttyさん）主な役割として挙げられたのは：テスト戦略・品質方針の策定品質リスクの可視化開発チームとの連携メンバー育成組織としての品質文化づくりQAは単なる実務ではなく、プロダクトと組織を横断する存在であることが強調されました。3. QA Manager / QA Leadの心掛けディスカッションの中で繰り返し語られたのが、「言語化」の重要性です。「『なんとなく不安』ではなくて、何がリスクなのかをちゃんと説明できることが大事だと思っています」（MAXさん）また、ステークホルダーとの関係性も重要なテーマでした。「品質を守るだけだと、どうしても開発のスピードと衝突するので、どこで折り合いをつけるかは常に考えています」（shuttyさん）さらに、リーダーとしての視点についても：「自分が全部やるのではなくて、チームとしてどう成果を出すかを考えるようになりました」（MAXさん）QAリーダーには、技術だけでなく“調整力”や“伝える力”が求められることが浮き彫りになりました。4. 大