🛸
MagicPod MCPサーバー × Claudeで始めるテストケースAIレビュー

ikenyal
2026/03/29に公開
Model Context Protocol
 テスト自動化は進んだ。レビューもセットで回っている？MagicPodのようなノーコードツールでE2Eテストを自動化するチームは増えています。テストケースの作成ハードルは確実に下がりました。では、作られたテストケースの品質は、誰がどう担保しているでしょうか。
プロダクト開発におけるソースコードであればGitHubのPull Requestという、コード管理とレビューが一体化した場があります。一方、ノーコードのテスト自動化ツールには同等の場が整っていないことが多く、レビュー体制の構築はチームの意思と工夫に委ねられています。テストケースの作成者がそのまま最も詳しい人であり続ける。その状態が属人化につながっていないか、一度立ち止まって考える価値はあるでしょう。
本記事では、MagicPodが公式に提供しているMCPサーバーとClaudeを組み合わせて、テストケースのAIレビューの仕組みを紹介します。セットアップから実際のレビューまで、そのまま再現可能な形でまとめました。

 本記事の対象読者MagicPodでテストケースを運用しているが、レビューが回っていないチーム
QAエンジニアに限らず、開発者やPdMでテスト品質に課題感を持っている方
MCPサーバーやAIエージェントに興味はあるが、具体的な活用イメージがない方
ターミナル操作に慣れていない方でも再現できるよう、GUIベースの手順も併記しています。

 全体像：何をどうやるのか仕組みの全体像はシンプルです。
MagicPod MCPサーバーをClaude Desktopに接続する
レビュー観点を定義したSkillファイルを用意する
「レビューして」と指示するだけで、AIがテストケースを取得・分析・レポート出力する
MagicPod MCPサーバー は、AIエージェント（Claude、Cursor、Cline等）からMagicPodの各種機能を操作するための公式モジュールです。GitHubでMITライセンスのOSSとして公開 されており、MagicPod側の追加費用は発生しません。
2026年3月時点でMCPサーバー経由でできることは主に4つです。
Web API経由でのテスト実行
テストの実行情報（統計情報など）の取得
ヘルプページを参照した使い方やトラブル解決の提案
Autopilot経由での自然言語によるテストケース作成・編集
本記事のAIレビューでは、このなかの「テストケース情報の取得」を使います。テストケースの読み取りのみで、既存のテストに変更を加えることはありません。なお、テストの作成・編集・実行はクラウド環境のみ対応で、ローカルPC環境には対応していない点は制約として認識しておく必要があります。必要なのはMagicPodの契約と、Claudeのサブスクリプションだけです。
なお、公式ヘルプでは、MCPサーバーを使った 不安定なロケータの特定方法 も紹介されています。本記事のレビュー観点にも含まれている内容であり、MagicPod側もMCPによるテストケース品質改善を想定していることがわかります。
!MCPサーバー経由でユーザーの情報が機械学習に使用されることはなく、入力されたプロンプト情報をMagicPod社が保持することもないと 公式ヘルプ に明記されています。Web APIのトークンはMCPサーバーのconfigファイルに記載しますが、AIエージェントには渡らない設計です。

 なぜClaude Desktopで説明するのか本記事ではClaude Desktopを使って手順を説明しています。理由は、CLIやターミナルに慣れていない方でも導入しやすい環境だからです。ターミナル操作は設定ファイルの編集1箇所だけで、あとはチャットUIで完結します。GUIベースで設定でき、MCPの接続状態も画面上で確認できるため、MCPサーバーに初めて触れる方の最初の一歩として適しています。

 他のツールを使っている場合MagicPod MCPサーバーはMCP（Model Context Protocol）に準拠しているため、MCPをサポートする任意のAIツールから利用できます。本記事のレビュー観点やプロンプトは、ツールに依存しない汎用的な設計にしています。
Cursorを使っている場合
CursorにはProject Rulesという仕組みがあり、本記事のSkillファイルをそのままRuleとして配置できます。Hacobu社の記事（Cursor × MagicPod MCPサーバーで、AIレビューの仕組みづくりに挑戦してみた話）がCursor向けの先行事例として参考になります。MCPサーバーの設定方法はCursorの公式ドキュメントを参照してください。
Claude Codeを使っている場合
Claude CodeもMCPサーバーに対応しています。CLAUDE.md にSkillファイルの内容を記載するか、--mcp-config オプションでMCPサーバーを指定することで同等の運用が可能です。ターミナルに慣れている方にはこちらの方が手軽かもしれません。
ChatGPTを使っている場合
ChatGPTは2025年9月以降、Developer ModeでMCPサーバーに対応しています。ただし、リモートサーバー（SSE / streaming HTTP）のみ対応で、ローカル実行（stdio）には対応していません。MagicPod MCPサーバーはローカルで npx 経由で起動するstdio方式のため、ChatGPTから直接接続するにはngrok等でトンネルを張る必要があります。手軽さの点では、Claude DesktopやCursorの方がセットアップが簡単です。
その他のMCP対応ツール（Cline、Windsurf等）
MCPサーバーの設定ファイル（claude_desktop_config.json に相当する設定）にMagicPod MCPサーバーを追加すれば、どのツールでも動作します。レビュー観点のプロンプトはプレーンテキストなので、ツール固有のフォーマットに変換する必要もありません。
!本記事の手順はClaude Desktop前提で書いていますが、レビュー観点の設計とSkillファイルの中身がこの仕組みの本質です。ツールは好みで選んでください。

 セットアップ（5分）以下の手順は初回のみの作業です。一度セットアップが完了すれば、以降はSkillファイルに従ってAIが自律的にレビューを実行します。

 前提MagicPodのアカウントがあり、レビュー対象のプロジェクトにアクセスできること（無料トライアル も可）

Claude Desktop がインストールされていること（Mac / Windows対応）
Claude Pro以上のサブスクリプションに加入していること

 Step 1: MagicPod APIトークンを取得https://app.magicpod.com/accounts/api-token/ にアクセスし、トークンを発行してコピーします。

 Step 2: Node.jsをインストール（未導入の場合）MCPサーバーの実行に npx が必要です。https://nodejs.org/ からLTS版をインストールしてください。

 Step 3: Claude Desktopの設定ファイルを編集Claude Desktopを開く
メニューバーから Claude → 設定... を選択
左メニューの 開発者 → 設定を編集 をクリック
設定ファイルがあるフォルダがFinder（Windowsの場合はエクスプローラー）で開くので、claude_desktop_config.json をテキストエディタで開く（Macの場合：右クリック →「このアプリケーションで開く」→ 普段使用しているエディタを選択）
以下の内容に書き換えて保存：
{
  "mcpServers": {
    "magicpod-mcp-server": {
      "command": "npx",
      "args": ["-y", "magicpod-mcp-server", "--api-token=ここにStep 1のトークンを貼る"]
    }
  }
}
ここにStep 1のトークンを貼る の部分を、Step 1でコピーしたAPIトークンの文字列に置き換えてください。--api-token= の後ろにトークンが直接続く形です（例：--api-token=abc123def456）。
既に他のMCPサーバーが設定されている場合は、mcpServers の中に追記してください。

 Step 4: 再起動して接続確認Claude Desktopを一度完全に終了し、再起動します。
!再起動後のMCPの確認は、チャット入力欄の下にある ＋ → コネクタ のなかを確認してください。magicpod-mcp-server が表示されていればOKです。既に開いているチャットで表示されない場合は、新しいチャットを開いてから確認してください。
動作確認として、以下をチャットに入力します：
MagicPodに接続できていますか？利用可能な組織とプロジェクトの一覧を教えてください。
組織名とプロジェクト一覧が返ってくれば、セットアップは完了です。

 Skillファイルの導入セットアップが完了したら、次にやることはSkillファイルの配置です。

 SkillファイルとはSkillファイルとは、AIエージェントに特定のタスクの実行方法を教えるMarkdownファイルです。Claude Codeが提唱した概念ですが、2026年3月時点では Agent Skillsオープンスタンダード として標準化が進んでおり、Claude Code、Cursor、Gemini CLI、Codex CLIなど複数のツールで同じ SKILL.md フォーマットが利用可能です。
本記事で配布するSkillファイルには、以下の内容が1ファイルにまとまっています。
レビュー対象の組織名・プロジェクト名
レビュー観点（何をチェックするか、重要度はどうか）
出力フォーマット（テストケースごとの指摘 + サマリ）
レポート生成（Slack/Confluenceへの共有形式）
観点もフォーマットもファイルに定義済みなので、毎回プロンプトを書く必要がありません。AIは「レビューして」の一言で何をすべきか理解できます。

 配置方法Skillファイルの配置先は、使用するツールによって異なります。


ツール
配置先


Claude Desktop / claude.ai
プロジェクトを作成し、ナレッジとしてファイルを追加

Claude Code

.claude/skills/magicpod-review/SKILL.md に配置

Cursor

.cursor/rules に配置（Project Rulesとして読み込まれる）

その他MCP対応ツール
各ツールのルール/ナレッジ配置場所に追加

手順としては以下の通りです。
本記事末尾のSkillファイル全文をコピー

magicpod-review.md というファイル名で保存
ファイル内の {組織名} と {プロジェクト名} を自分の環境に書き換え
上記の表に従い、使用しているツールの配置先に追加
複数プロジェクトがある場合は、Skillファイルの「基本設定」セクションを以下のように書き換えてください。
## 基本設定

- 対象組織: MyOrganization
- 対象プロジェクト（指定がなければ全プロジェクトを順にレビュー）:
  - ProjectA（ブラウザ）
  - ProjectB（モバイルアプリ）
  - ProjectC（ブラウザ）
この形にしておくと、「レビューして」で全プロジェクトを横断レビューし、「ProjectAだけレビューして」で特定プロジェクトに絞ることもできます。
Claude Desktopの場合、具体的な手順は以下です。
左サイドバーの「プロジェクト」から新規プロジェクトを作成（名前は「MagicPod レビュー」等）
プロジェクトの設定画面で「ナレッジを追加」を選択し、保存した magicpod-review.md をアップロード
そのプロジェクト内で新しいチャットを開く

 Skillファイルの中身：レビュー観点の設計Skillファイルの核心は、レビュー観点の定義です。ここではMagicPod公式ブログ「自動テストのレビューどうしてる？レビュー観点アイデア10選」の10観点をベースに、AIが検出しやすいものと人間の判断が必要なものを分類しています。
この分類がSkillファイルの精度を左右する重要なポイントです。AIに「なんでもチェックして」と投げても動きはしますが、的外れな指摘と有用な指摘が混在して、結果の取捨選択に手間がかかります。「これはAIに任せる」「これは人間が見る」を事前に決めておくことで、出力の信頼性が上がり、レビュー結果をそのままチームに共有できる品質に近づきます。

 AIで自動検出可能な観点

観点
何を検出するか
重要度


アサーション欠落
確認コマンドが1つも含まれないテストケース
High

固定時間待機
「〇秒待つ」系コマンドの使用
Medium

不安定ロケータ
XPathのindex依存（div[2]/button[1] 等）
Low

命名不備
テストケース名が空、説明欄が空
Medium

機械的UI要素名
「ボタン要素(1)」等の自動生成名
Medium

無効ステップ放置
「一旦無効」のまま残っているステップ
Low

長大テスト
200ステップ超
High

共有ステップ未活用
同一操作パターンのベタ書き
Medium


 人間の判断が必要な観点（AIは情報提示のみ）

観点
AIが提供する情報


アサーションの妥当性
使用中のアサーション一覧（適切かはチームで判断）

テスト間の依存関係
セッション再起動未使用のテストケースリスト

一つ補足すると、MagicPod Web APIの human_readable_steps にはステップの行番号が含まれず、無効化ステップかどうかも判別できません。これはHacobu社の記事（Cursor × MagicPod MCPサーバーで、AIレビューの仕組みづくりに挑戦してみた話）でも指摘されている制約です。指摘箇所の特定はステップ内容ベースになる点は、現時点の限界として認識しておく必要があります。

 この10観点で十分か結論から言うと、AIレビューの一次スクリーニングとしては十分に機能しますが、万能ではありません。実際に複数プロジェクト・60件超のテストケースをレビューした結果から、この10観点の強みと限界を整理します。
よくカバーできている領域：構造的な問題
10観点のうち、アサーション欠落（観点1）、命名不備（観点4）、長大テスト（観点7）、共有ステップ未活用（観点8）は、テストケースの「形」を見れば判定できる問題です。AIはこの種のパターンマッチが得意であり、実際のレビューでも高い精度で検出できました。特に「説明欄が空」は多くのテストケースで該当し、この1観点だけでもレビューを実施する価値があったと言えます。
盲点になりやすい領域：テスト設計の妥当性
一方、公式ブログでも「その他の観点」として触れられていますが、テスト設計書との整合性やテストデータの妥当性は10観点に含まれていません。これはMagicPod単体のレビューでは判断が難しく、テスト設計書やプロダクト仕様との突合が必要になるため、現時点のMCP経由のAIレビューには荷が重い領域です。
10観点の外から見つかったもの
今回のレビューでは、10観点に含まれない指摘も出てきました。いずれもMagicPodの挙動を確認するために作られたテストケースに対する指摘ですが、こうした残骸をAIが拾い上げた点は注目に値します。
壊れたステップ（UI element: not configured）。設定未完了のまま放置されていた
テストデータにパスワードが平文で含まれていた
MagicPodの挙動確認用のテストと本番のリグレッションテストが同一プロジェクトに混在していた
これらはAIがプロンプトの観点リストに縛られず、文脈から追加の問題を拾い上げた例です。つまりプロンプトで10観点を指定しつつも、AIが自律的に拡張してくれる余地がある、ということです。観点を厳密に限定しすぎず、余白を残しておくことが、AIレビューの実用的な運用では重要だと感じています。
まとめると、10観点は「テストケースの実装品質」をカバーする観点としてバランスが良く、AIレビューのベースラインとして推奨できます。テスト設計の妥当性やプロダクト固有のドメイン知識が求められるレビューは、引き続き人間の役割です。

 使い方Skillファイルの配置が完了していれば、使い方はシンプルです。

 基本：レビューの実行チャットに以下のいずれかを入力するだけです：
レビューして
テストケースをチェックして
Skillファイルに組織名・プロジェクト名・観点・出力フォーマットがすべて定義されているため、AIはこの一言で「テストケース一覧を取得 → 各ステップを分析 → 観点に沿ってチェック → フォーマットに従って出力」を自律的に実行します。
!Skillファイルを配置したプロジェクト内のチャットから実行してください。通常のチャット（プロジェクト外）で「レビューして」と打っても、Skillファイルが読み込まれないため「何をレビューしますか？」と聞き返されます。

 レポートの共有レビュー結果が出たら、共有用レポートも生成できます。
Slack用にまとめて
Confluenceに貼れる形でレポートにして
Skillファイルには Slack mrkdwn形式とMarkdown形式の両方のテンプレートが含まれており、共有先に応じたフォーマットで出力されます。
SlackのMCPコネクタが接続されている環境では、「Slack用にまとめて」と入力すると以下のような選択肢が提示されます。
チャンネルに直接投稿（チャンネル名を指定すればそのまま投稿）
ドラフトとして保存（投稿前に内容を確認したい場合）
mrkdwn形式のテキストだけ出力（自分でコピペする場合）
ConfluenceやJiraのMCPコネクタが接続されていれば、Confluenceページの作成やJiraチケットの起票もチャットから直接実行できます。MCPコネクタが接続されていない環境でも、コピペ用のテキスト出力は常に利用可能です。
実際にSlack用に出力されるレポートは以下のような形式です（プロジェクト名等はダミーに置き換えています）。
🔍 MagicPod テストケース AIレビュー結果
実施日: 2026/03/28　|　対象: SampleOrg（4プロジェクト / 60件超）

🔴 High: 3件　🟡 Medium: 多数　🟢 Low: 0件
━━━━━━━━━━━━━━━━━━━━━━━
🚨 優先改善アクション Top 3

1. 説明欄の記載 Medium
  対象テストケースの多くで説明欄が空。

2. 挙動確認用テストの整理 Medium
  oldフォルダに導入時の挙動確認用テストが残存。

3. 固定時間待機の置き換え Medium
  ProjectD全般で「3秒待つ」「5秒待つ」が多用。
━━━━━━━━━━━━━━━━━━━━━━━
1️⃣ ProjectA_Web（22件）
• 🏷 説明欄が空: ほぼ全件
• 🤖 機械的UI要素名: 「領域(8)」「領域(119)」等
• 💡 リグレッションテストはアサーション充実、コメント分けも適切

2️⃣ ProjectB_Web（23件）
• 🏷 説明欄が空: 全件
• ♻ 共有ステップ未活用: 画面確認パターンが10件以上で同一
• 💡 命名規則が全テストケースで統一されている点は良い

（他2プロジェクトの詳細はスレッドに👇）
優先改善アクション → プロジェクト別サマリ → 「スレッドに詳細」という3層構造で、チームが受け取ったときにまず何をすべきかが一目でわかる形式になっています。良い点（💡）も併記することで、指摘だけのレポートにならないよう配慮しています。

 カスタマイズ例oldフォルダは除外してレビューして
ProjectB_Webだけレビューして
前回との差分を出して
Skillファイルにはこれらの指示への対応ルールも定義されているため、自然言語で条件を追加するだけで動作します。

 実際にやってみた結果4プロジェクト・60件超のテストケースに対してAIレビューを実行しました。以下はその結果です。

 最も多かった指摘：「説明欄が空」が多数対象テストケースで説明欄が空なものが多数ありました。これはおそらく多くのチームで共通する状況でしょう。テストケース名だけでは意図が伝わらず、レビューも引き継ぎもAI活用も精度が下がります。
MagicPodにはAI要約機能が搭載されていますが、それはステップの動作を要約するものであり、「このテストで何を確認したいのか」という目的は人間が書く必要があります。

 学習用テストケースで見つかった典型的な指摘プロジェクト初期にMagicPodの挙動を確認する目的で作られたテストケースが、そのまま残っていました。本番のリグレッションテストとは別の「old」フォルダに格納されていたものですが、AIレビューはこれらの問題を正確に検出しています。
「Test 1」というテスト名。目的が不明で、説明欄も空
アサーション欠落。ログイン操作のみで、ログイン成功の確認ステップがない。操作を流しているだけで何も保証していない状態
「領域(119)」というUI要素名。MagicPodが自動生成した機械的な名前がそのまま残っており、第三者が読んだときに何の要素か判別できない
未設定ステップの放置。あるテストケースで UI element: not configured という壊れたステップが残っていた
いずれもMagicPodの挙動確認時に作られた残骸であり、本番運用しているリグレッションテストでは命名規則の統一やアサーションの整備がされていました。ただ、こうした「試した痕跡」がプロジェクト内に残り続けること自体が、一括実行時のノイズになりうるという指摘をAIが出してくれた点は有用でした。
これらは「レビューすれば誰でも気づく」類のものですが、レビュー自体が行われていなければ永遠に放置されます。AIレビューの価値は、こうした「見れば分かるが見る人がいない」問題を機械的に拾い上げる点にあります。

 観点外の発見なお、10観点に含まれない指摘も出てきました。
固定時間待機の多用。あるプロジェクトで「3秒待つ」「5秒待つ」が複数テストケースに散在していた
プロジェクト間の品質差の可視化。4プロジェクトを横断してレビューしたことで、説明欄の記載率がプロジェクトごとに大きく異なることが一目で分かった
AIは観点リストに従いつつも、文脈から追加の問題を拾い上げることがあります。これは人間のレビュアーと似た振る舞いであり、プロンプトを厳密に限定しすぎないことの利点と言えます。

 良い点も検出できるAIレビューは指摘だけでなく、良い実践の検出にも使えました。
コメント（//）によるセクション分けが適切に行われているテストケース
共有ステップが活用され、ログイン処理がDRYに保たれている構成
テスト名の命名規則が全テストケースで統一されているプロジェクト
改善指摘だけのレポートはチームのモチベーションを下げます。「ここは良くできている」を併記することで、レポートの受容性が上がります。

 限界と使い分けAIレビューは万能ではありません。以下の限界はあらかじめ認識しておく必要があります。
AIが得意なこと：
パターンマッチで検出できる構造的な問題（命名、アサーション有無、ステップ数）
プロジェクト横断の一括分析と比較
何度実行しても同じ基準でチェックし続ける一貫性
AIが苦手なこと：
「このアサーションはこのテストの目的に対して適切か」という意味レベルの判断
テスト設計書との整合性チェック（設計書がMagicPod外にある場合）
チーム固有のコンテキスト（「この固定時間待機にはやむを得ない理由がある」等）
実務的には、AIレビューをセルフレビューまたは一次スクリーニングとして使い、判断が必要な指摘のみ人間がレビューする、という二段構成が現実的でしょう。コードのPull RequestでAIレビューが先に走り、人間はそのサマリを見てから判断に集中する、という流れが広まりつつありますが、テストケースレビューでも同じ構造が成り立ちます。

 Skillファイル全文本記事で解説してきたレビュー観点・出力フォーマット・レポート共有機能が、すべてこの1ファイルに含まれています。{組織名} と {プロジェクト名} を自分の環境に書き換えて、前述の配置先に追加してください。
Skillファイル全文（クリックで展開）# MagicPod テストケース AIレビュー Skill

## このファイルについて

このファイルをClaude DesktopのProject KnowledgeやCLAUDE.mdに配置すると、
MagicPod MCPサーバー経由でテストケースの自動レビューが可能になります。

## 前提条件

- MagicPod MCPサーバーが接続済みであること
- 対象の組織名・プロジェクト名を把握していること

## 基本設定

- 対象組織: {組織名}
- 対象プロジェクト: {プロジェクト名}
- レビュー出力言語: 日本語

## レビュー実行方法

ユーザーが以下のいずれかを指示した場合、レビューを実行してください：
- 「レビューして」
- 「テストケースをチェックして」
- 「MagicPodのレビューお願い」

### 実行手順

1. MagicPod MCPサーバー経由で対象プロジェクトのテストケース一覧を取得
2. 各テストケースのステップ詳細を取得
3. 以下のレビュー観点に沿ってチェック
4. 結果をフォーマットに従って出力

## レビュー観点

参考: https://magicpod.com/blog/testcase-review-idea/

以下の観点は「自動検出」と「人間判断の支援」に分類されています。
自動検出の観点は該当があれば必ず指摘してください。
人間判断の支援は情報を提示し、判断はユーザーに委ねてください。

### 自動検出（該当があれば指摘）

#### 観点1: アサーション欠落
- 確認コマンド（assert系・「確認」系）が1つも含まれないテストケースを検出
- 操作だけで終わっているテストは何も保証していない
- 重要度: **High**

#### 観点2: 固定時間待機の使用
- 「〇秒待つ」「固定時間待機」系コマンドの使用箇所を検出
- 条件ベースの待機（「〜が表示されるまで待つ」等）への置き換えを推奨
- やむを得ず使用する場合はコメントで理由を残すべき
- 重要度: **Medium**

#### 観点3: 不安定なロケータ
- XPathでindex依存のロケータ（例: //div[@id='root']/div[2]/button[1]）を検出
- 個別作成されたロケータのみ確認対象（AI自動修復対象は優先度低）
- 重要度: **Low**（毎日実行していれば自然に発見されるため）

#### 観点4: テストケース名・説明の不備
- テストケース名が空、または命名規則に沿っていない
- 説明欄が空（テストの目的が文章で記載されていない）
- 重要度: **Medium**

#### 観点5: 機械的なUI要素名の残存
- 「ボタン要素(1)」「テキスト入力(2)」等の自動生成名がそのまま残っている
- 「メールアドレス入力欄」「ログインボタン」のような意味のある名前が理想
- 重要度: **Medium**

#### 観点6: 無効ステップの放置
- 「一旦無効」状態のまま残っているステップを検出
- 不要なステップはテストの意図を読み解く妨げになる
- 重要度: **Low**

#### 観点7: 長大テスト
- 200ステップを超えるテストケースを検出
- 可読性・安定性・メンテナンス性すべてに悪影響
- 重要度: **High**

#### 観点8: 共有ステップの未活用
- 複数テストケースで同一の操作パターンがベタ書きされている疑いを検出
- ログイン処理・テストデータ初期化などが典型
- 重要度: **Medium**

### 人間判断を支援（情報提示のみ）

#### 観点9: アサーションの妥当性
- 各テストケースで使用されているアサーション（確認コマンド）を一覧化
- 目的に対して適切かどうかの判断はユーザーに委ねる
- URL確認、画像差分、要素値確認、表示確認、タイトル確認のどれを使っているか

#### 観点10: テストケース間の依存関係
- セッション再起動を使っていないテストケースをリストアップ
- 依存関係がある場合、説明欄にその旨が記載されているか確認

### API仕様上の制約

MagicPod Web APIの `human_readable_steps` には以下の制約があります：
- ステップの行番号が返ってこない → 指摘時は「〇番目のステップ」ではなくステップ内容で特定する
- 無効化されたステップかどうかが不明 → 観点6の検出精度に限界がある旨を補記する

## 出力フォーマット

### テストケースごとの指摘

```
## テストケース: {テストケース名}

| # | 観点 | 指摘内容 | 重要度 |
|---|------|----------|--------|
| 1 | アサーション欠落 | 確認コマンドが存在しない | High |
| 4 | 命名不備 | 説明欄が空 | Medium |
```

### サマリ（レビュー末尾に必ず出力）

```
## レビューサマリ

- 対象テストケース数: X件
- 指摘あり: Y件
- 指摘なし: Z件

### 観点別集計
| 観点 | 件数 |
|------|------|
| アサーション欠落 | X |
| 固定時間待機 | X |
| ... | ... |

### 優先改善アクション Top3
1. ...
2. ...
3. ...
```

## セットアップガイド（ターミナル不要）

### Step 1: MagicPod APIトークンを取得
1. https://app.magicpod.com/accounts/api-token/ にアクセス
2. トークンの文字列をコピー

### Step 2: Node.jsをインストール（未導入の場合のみ）
1. https://nodejs.org/ にアクセス
2. LTS版をダウンロードしてインストール
3. これでMCPサーバー実行に必要な `npx` が使えるようになる

### Step 3: Claude Desktopの設定ファイルを編集
1. Claude Desktopを開く
2. メニューバーから Claude > Settings... を選択
3. 左メニューの「Developer」を選択
4. 「Edit Config」ボタンをクリック → 設定ファイルがあるフォルダがFinderで開く
5. 以下の内容に書き換えて保存:

```json
{
  "mcpServers": {
    "magicpod-mcp-server": {
      "command": "npx",
      "args": ["-y", "magicpod-mcp-server", "--api-token=ここにトークンを貼る"]
    }
  }
}
```

※ 既に他のMCPサーバーが設定されている場合は、`mcpServers` の中に追記する。

### Step 4: Claude Desktopを再起動
1. Claude Desktopを完全に終了（Cmd+Q）
2. 再度起動
3. チャット入力欄の下にMCPツールのアイコンが表示されていれば接続成功

### Step 5: 動作確認
チャットに以下を入力:
```
MagicPodに接続できていますか？利用可能な組織とプロジェクトの一覧を教えてください。
```

### コストについて
- MagicPod MCPサーバー自体: 無料（MITライセンスのOSS）
- 必要なのはMagicPod本体の契約 + Claude Proサブスクリプション（月$20）
- レビュー用途（読み取りのみ）ならMagicPod側の追加費用は発生しない


## レポート生成と共有

レビュー完了後、ユーザーが以下のいずれかを指示した場合、共有用レポートを生成してください：
- 「レポートにして」「まとめて」
- 「Slackに共有したい」「Confluenceに貼りたい」
- 「共有用にまとめて」

### 共有先に応じたフォーマット

#### Slack投稿用

Slackのmrkdwn記法で出力する。長文はスレッドに分割する前提で、本文は要点のみ。

```
*🔍 MagicPod テストケース AIレビュー結果*
実施日: YYYY-MM-DD

*対象*
• プロジェクト: {プロジェクト名}
• テストケース数: X件

*サマリ*
• 指摘あり: Y件 / 指摘なし: Z件
• 🔴 High: X件　🟡 Medium: X件　🟢 Low: X件

*優先改善アクション Top3*
1. ...
2. ...
3. ...

詳細はスレッドに👇
```

スレッドには各テストケースの指摘詳細を投稿する。

#### Confluence / ドキュメント用

Markdown形式でフルレポートを出力する。そのままConfluenceのマークダウン貼り付けで使える。

```markdown
# MagicPod テストケース AIレビューレポート

## 基本情報
- 実施日: YYYY-MM-DD
- 対象組織: {組織名}
- 対象プロジェクト: {プロジェクト名}
- テストケース数: X件
- レビュー観点: MagicPod公式ブログ10選ベース + 追加観点

## サマリ

| 指標 | 値 |
|------|-----|
| 指摘ありテストケース | Y件 (XX%) |
| 指摘なしテストケース | Z件 (XX%) |
| High指摘 | X件 |
| Medium指摘 | X件 |
| Low指摘 | X件 |
```

```markdown
## 観点別集計

| # | 観点 | 件数 | 重要度 |
|---|------|------|--------|
| 1 | アサーション欠落 | X | High |
| 2 | 固定時間待機 | X | Medium |
| 3 | 不安定ロケータ | X | Low |
| 4 | 命名不備（名前/説明） | X | Medium |
| 5 | 機械的UI要素名 | X | Medium |
| 6 | 無効ステップ放置 | X | Low |
| 7 | 長大テスト（200超） | X | High |
| 8 | 共有ステップ未活用 | X | Medium |
| + | セキュリティ（平文パスワード等） | X | High |
| + | 壊れたステップ（not configured） | X | High |

## 優先改善アクション Top3

1. **[アクション名]** — [理由と期待効果]
2. **[アクション名]** — [理由と期待効果]
3. **[アクション名]** — [理由と期待効果]

## 良い点

（AIが検出した良い実践も記載。改善だけでなく称賛も含める）

## テストケース別詳細

（各テストケースの指摘一覧をここに展開）

## 補足: レビュー観点の根拠

本レビューはMagicPod公式ブログ「自動テストのレビューどうしてる？レビュー観点アイデア10選」
（https://magicpod.com/blog/testcase-review-idea/）の観点をベースに、
AI検出に適した形に再構成したものです。
```

### 共有実行の指示

ユーザーが具体的な共有先を指示した場合の対応：

#### 「Slackに投稿して」
1. Slack MCPサーバーが接続されている場合 → `slack_send_message` でチャンネルに直接投稿
2. 接続されていない場合 → Slack mrkdwn形式のテキストを出力し、コピペを促す

#### 「Confluenceに貼って」
1. Atlassian MCPサーバーが接続されている場合 → `createConfluencePage` でページ作成
2. 接続されていない場合 → Markdown形式で出力し、Confluenceのマークダウン貼り付けを促す

#### 「Jiraチケットにして」
1. 指摘のうちHigh重要度のものをJiraチケットとして起票提案
2. ユーザーの承認後、`createJiraIssue` で作成

### レポートのカスタマイズ

ユーザーが以下を指定した場合、レポートを調整する：
- 「oldフォルダは除外して」→ 本番テストのみでレポート生成
- 「プロジェクト横断でまとめて」→ 全プロジェクト横断サマリを生成
- 「良い点だけ出して」→ 改善ではなく称賛レポートを生成
- 「前回との差分を出して」→ 前回レポート（knowledgeに保存済み）との比較

 既存記事との違いHacobu社が公開している「Cursor × MagicPod MCPサーバーで、AIレビューの仕組みづくりに挑戦してみた話」は、この分野の先行事例として参考になります。ここで書いた内容は、以下の点でHacobu記事を補完する位置づけです。

レビュー観点の体系化: MagicPod公式の10観点をベースに、AI検出可能/人間判断必要の分類を明示

Skillファイルとして配布: 観点・フォーマット・レポート共有を1ファイルにまとめ、「レビューして」で動く形にパッケージ化

実データに基づく結果: 複数プロジェクト・60件超の横断レビュー結果と具体的な数値

10観点の評価: どこまでカバーでき、どこに盲点があるかの考察付き
一方、Hacobu記事にあるCursor × Project Rulesの組み合わせや、プロンプト調整の試行錯誤の記録はここでは深掘りしていません。ツールの選択（Claude Desktop vs. Cursor）は好みの問題であり、レビュー観点の設計とSkillファイルの精度がより本質的と考えています。

 まとめテストケースのレビューが属人化する原因は、レビューの仕組みがないことから始まるでしょう。レビューの観点があいまいで、レビュアーの時間が足りず、結果としてレビューが行われなくなる。
MagicPod MCPサーバー × AIは、この問題に対して「完璧なレビュー」ではなく「一貫した一次スクリーニング」を提供します。今回の実験で多くのテストケースの説明欄が空だったという事実は、人間のレビューでも指摘はできます。AIがやったのは、見ることだけです。
MagicPodを既に使っている場合、セットアップは5分、Skillファイルの配置まで含めても10分。追加費用はClaude費用のみ。まず1プロジェクトで「レビューして」と打ってみて、出てきた指摘を眺めるところから始めてみてください。
ツール	配置先
Claude Desktop / claude.ai	プロジェクトを作成し、ナレッジとしてファイルを追加
Claude Code	`.claude/skills/magicpod-review/SKILL.md` に配置
Cursor	`.cursor/rules` に配置（Project Rulesとして読み込まれる）
その他MCP対応ツール	各ツールのルール/ナレッジ配置場所に追加
観点	何を検出するか	重要度
アサーション欠落	確認コマンドが1つも含まれないテストケース	High
固定時間待機	「〇秒待つ」系コマンドの使用	Medium
不安定ロケータ	XPathのindex依存（`div[2]/button[1]` 等）	Low
命名不備	テストケース名が空、説明欄が空	Medium
機械的UI要素名	「ボタン要素(1)」等の自動生成名	Medium
無効ステップ放置	「一旦無効」のまま残っているステップ	Low
長大テスト	200ステップ超	High
共有ステップ未活用	同一操作パターンのベタ書き	Medium
観点	AIが提供する情報
アサーションの妥当性	使用中のアサーション一覧（適切かはチームで判断）
テスト間の依存関係	セッション再起動未使用のテストケースリスト
GENDAPublication
『世界中の人々の人生をより楽しく』をAspiration（大志）に掲げたエンターテイメント企業『GENDA』（ジェンダ）
テスト自動化は進んだ。レビューもセットで回っている？

本記事の対象読者

全体像：何をどうやるのか

なぜClaude Desktopで説明するのか

他のツールを使っている場合

セットアップ（5分）

前提

Step 1: MagicPod APIトークンを取得

Step 2: Node.jsをインストール（未導入の場合）

Step 3: Claude Desktopの設定ファイルを編集

Step 4: 再起動して接続確認

Skillファイルの導入

Skillファイルとは

配置方法

Skillファイルの中身：レビュー観点の設計

AIで自動検出可能な観点

人間の判断が必要な観点（AIは情報提示のみ）

この10観点で十分か

使い方

基本：レビューの実行

レポートの共有

カスタマイズ例

実際にやってみた結果

最も多かった指摘：「説明欄が空」が多数

学習用テストケースで見つかった典型的な指摘

観点外の発見

良い点も検出できる

限界と使い分け

Skillファイル全文

既存記事との違い

まとめ

Discussion
