bugAgent

公式

bugAgentをMCP互換のAIクライアントに接続。AIコーディングアシスタントから直接、バグや機能リクエストなどをファイル化、分類、管理できます。コンテキストの切り替えやコピーペーストは不要—問題を説明するだけで、bugAgentが残りを処理します。

bugagent.com で表示

Bug Agent MCPで何ができますか？

自動分類付きバグ報告の作成 — アシスタントに依頼して、create_bug_report を使用してバグ、機能リクエスト、または改善を報告します。サーバーが自動的に19種類のいずれかに分類し、説明を充実させます。
既存報告の一覧表示とフィルタリング — list_bug_reports を使用して、特定の条件（プロジェクト、重要度、ステータス、種類、報告者）に一致する報告を取得します。1ページあたり最大100件までページネーション対応。
報告のステータス、担当者、解決方法の更新 — update_bug_report を呼び出してバグのライフサイクルを遷移させ、ステータスを設定し、チームメンバーを割り当て、解決方法と根本原因を記録します。
スレッド形式のコメントの追加と閲覧 — add_comment を使用して報告にコメントを投稿し、list_comments でスレッド形式の議論全体を読み取ります。
関連報告のリンク — link_bug_reports を呼び出して、2つの報告間に意味的な関係（重複、依存、関連）を作成し、list_bug_report_links でそれらを表示します。
セキュリティおよびパフォーマンステストの実行 — run_security_scan または run_performance_test をトリガーし、get_security_results または get_performance_results で結果を取得します。

ドキュメント

MCP v1

ナビゲーション

Model Context Protocol

MCP

bug_Agent_ を任意の MCP 対応 AI クライアントに接続します。

バグ、機能リクエストなどを AI コーディングアシスタントから直接、ファイル作成、分類、管理できます。コンテキストの切り替えやコピー＆ペーストは不要です。問題を説明するだけで、bug_Agent_ が残りを処理します。

Discord コミュニティ support@bugagent.com

はじめに

bug_Agent_ MCP サーバーを使用すると、AI クライアントは Model Context Protocol を通じてバグレポート、機能リクエスト、機能強化などを作成、照会、管理できます。ローカルで実行され、bug_Agent_ のクラウド API と通信します。

API キーを取得する

app.bugagent.com にサインアップし、コンソールから API キーを生成します。

AI クライアントを設定する

クライアントの設定に bug_Agent_ を MCP サーバーとして追加します（以下のセットアップを参照）。

バグの登録を開始する

自然言語でバグを説明すると、bug_Agent_ が自動的に分類、強化、保存します。

クイック例

# Create a bug report
"File a bug: Login button is unresponsive on iOS Safari.
Steps: tap login, nothing happens. Expected: navigate to
dashboard. Severity: high."

# bugAgent auto-classifies as UI bug, severity high

# File a feature request
"Feature request: Add dark mode toggle to the
settings page. Users have asked for this in surveys."

# Auto-classified as feature-request, severity medium

セットアップ

インストール

グローバルインストールは不要です。npx を使用して MCP サーバーをオンデマンドで実行します。

npx @bugagent/mcp-server

API キーを設定する

初回接続時に、bug_Agent_ が API キーの入力を求めます。環境変数で設定することもできます。

export BUGAGENT_API_KEY=ba_live_your_key_here

bug_Agent_ コンソールから API キーを取得してください。

MCP クライアント設定

MCP クライアントの設定ファイルに以下を追加します。

mcp.json

{
  "mcpServers": {
    "bugagent": {
      "command": "npx",
      "args": ["-y", "@bugagent/mcp-server"],
      "env": {
        "BUGAGENT_API_KEY": "ba_live_your_key_here"
      }
    }
  }
}

💡

ba_live_your_key_here をコンソールから取得した実際の API キーに置き換えてください。

サーバーに接続する

bug_Agent_ MCP サーバーは、Streamable HTTP トランスポート経由で https://mcp.bugagent.com/mcp で稼働しています。以下の 8 つのクライアントのいずれかから接続します。ワークフローに合ったものを選択してください。

🔑

最初に API キーを取得してください。 app.bugagent.com/dashboard/settings/api-keys にサインインし、API キーを作成 をクリックして、値をコピーします（ba_live_ で始まります）。一度しか表示されないため、安全な場所に貼り付けてください。以下のすべての例でこのキーを使用します。

オプション 1 — MCP Inspector (Web UI、初回テストに推奨)

公式の Anthropic ツールです。ローカルの Web UI を起動し、すべてのツールをクリックしてパラメータを入力し、応答を確認できます。設定不要で、IDE も必要ありません。

macOS (ターミナル)

ターミナル

npx @modelcontextprotocol/inspector

Windows (PowerShell または CMD)

PowerShell

開いたブラウザ UI で:

トランスポートタイプ: Streamable HTTP を選択
URL: https://mcp.bugagent.com/mcp
接続タイプ: Proxy を選択（デフォルト — Inspector はブラウザの CORS を回避するためにローカルの Node プロセスを介してプロキシします）
認証タブをクリック → カスタムヘッダーを追加:
- ヘッダー名: Authorization
- 値: Bearer ba_live_YOUR_KEY_HERE
接続をクリックします。左側のパネルに 60 以上の bug_Agent_ ツールが表示されます。
任意のツール（例: list_bug_reports）をクリックし、パラメータを入力して ツールを実行 をクリックします。右側に応答が表示されます。

前提条件: Node.js 18 以降。インストールされていない場合は nodejs.org からインストールしてください。

オプション 2 — Claude Desktop (Mac + Windows)

Claude Desktop アプリを使用している場合、bug_Agent_ を永続的な MCP サーバーとして追加できます。これにより、すべての会話で Claude がすべての bug_Agent_ ツールを利用できるようになります。

macOS

Claude Desktop を開く → メニューバー Claude → 設定 → 開発者 → 設定を編集。~/Library/Application Support/Claude/claude_desktop_config.json が開きます。
mcpServers の下に bug_Agent_ エントリを追加します。 claude_desktop_config.json

{  
  "mcpServers": {  
    "bugagent": {  
      "type": "http",  
      "url": "https://mcp.bugagent.com/mcp",  
      "headers": {  
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"  
      }  
    }  
  }  
}

ファイルを保存し、Claude Desktop を完全に終了します (Cmd+Q、ウィンドウを閉じるだけではありません)。
Claude Desktop を再起動します。チャット入力下部のツールハンマーアイコンに bug_Agent_ ツールが表示されるはずです。
試してみてください: “直近 5 件のバグレポートをリスト表示して” — Claude が自動的に list_bug_reports を呼び出します。

Windows

Claude Desktop を開く → ファイル → 設定 → 開発者 → 設定を編集。%APPDATA%\Claude\claude_desktop_config.json (通常は C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json) が開きます。
macOS セクションに示されているものと同じ JSON ブロックを追加します。
ファイルを保存し、システムトレイから Claude Desktop を完全に終了 し (Claude アイコンを右クリック → 終了)、再起動します。
ツールハンマーアイコンに bug_Agent_ ツールが表示されます。

オプション 3 — Claude Code (CLI)

ターミナルから Claude Code (CLI 版 Claude) を使用している場合、1 つのコマンドで bug_Agent_ サーバーを登録します。macOS、Linux、Windows で同じように動作します。

ターミナル / PowerShell

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp \
  --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

その後、Claude Code セッションを再起動します。接続を確認します。

claude mcp list

リストに bugagent が緑色のドットで表示されるはずです。任意のチャットでツールを使い始めてください: “今月の探索使用状況を表示して。”

後で削除するには:

claude mcp remove bugagent

オプション 4 — OpenAI Codex CLI

OpenAI Codex CLI を使用している場合、永続的な登録のために bug_Agent_ を ~/.codex/config.toml に追加するか、1 回限りのセッションのために設定をインラインで渡します。

永続的な登録 (設定に追加)

~/.codex/config.toml

[[mcp_servers]]
name = "bugagent"
type = "http"
url  = "https://mcp.bugagent.com/mcp"

[mcp_servers.headers]
Authorization = "Bearer ba_live_YOUR_KEY_HERE"

インライン — 1 セッション

ターミナル

codex \
  --mcp-server '{"name":"bugagent","type":"http","url":"https://mcp.bugagent.com/mcp","headers":{"Authorization":"Bearer ba_live_YOUR_KEY_HERE"}}' \
  "list the last 5 bug reports"

Codex は自然言語のプロンプトからツール呼び出しを自動的に解決します。試してみてください: “未解決のバグを重要度順にリスト表示して。”

オプション 5 — Cursor (Mac + Windows)

Cursor には MCP サポートが組み込まれています。bug_Agent_ を一度追加すると、Cursor 内の AI アシスタントがエディターを離れることなく、バグの登録、レポートの一覧表示、スキャンの実行などを行えます。

Cursor を開く → 設定 (Mac では Cmd+, / Windows では Ctrl+,) → 左サイドバーの MCP。
+ 新しい MCP サーバーを追加 をクリックします。
トランスポートタイプとして HTTP を選択します。
以下を入力します:
- 名前: bugagent
- URL: https://mcp.bugagent.com/mcp
- ヘッダー名: Authorization
- ヘッダー値: Bearer ba_live_YOUR_KEY_HERE
保存をクリックします。接続されると Cursor に緑色のインジケーターが表示されます。
Cursor のチャット (Cmd+L / Ctrl+L) を開き、“「ログイン不具合」というタイトルのバグレポートを重要度高で作成して” と入力します。Cursor は create_bug_report を呼び出します。

代替手段: Cursor は ~/.cursor/mcp.json (Mac) または %USERPROFILE%\.cursor\mcp.json (Windows) も読み取ります。Claude Desktop セクションに示されているものと同じ JSON 形式を追加します。

オプション 6 — Continue 拡張機能付き VS Code (Mac + Windows)

VS Code を好む場合、Continue 拡張機能は MCP サーバーをネイティブにサポートします。

VS Code マーケットプレースから Continue 拡張機能をインストールします。
Continue の設定を開きます: コマンドパレット (Cmd+Shift+P / Ctrl+Shift+P) → Continue: config.json を開く。ファイルの場所:
- macOS: ~/.continue/config.json
- Windows: %USERPROFILE%\.continue\config.json
mcpServers エントリを追加します: ~/.continue/config.json

{  
  "mcpServers": [  
    {  
      "name": "bugagent",  
      "type": "streamable-http",  
      "url": "https://mcp.bugagent.com/mcp",  
      "requestOptions": {  
        "headers": {  
          "Authorization": "Bearer ba_live_YOUR_KEY_HERE"  
        }  
      }  
    }  
  ]  
}

保存します。Continue は自動的にリロードされ、サイドバーに bug_Agent_ ツールが表示されます。
Continue チャットパネルを開き、試してみてください: “セキュリティスキャンを一覧表示して。”

その他の MCP 対応 VS Code 拡張機能: Cline、Roo Code、Windsurf (フォーク) はすべて、mcpServers キーと HTTP トランスポートを使用した同様の JSON 設定パターンに従います。

オプション 7 — OAuth 対応ホスト (例として Claude.ai Web を示します)

一部の MCP ホストは OAuth 2.0 で認証し、ベアラー API キーを受け入れる代わりに、事前に静的な client_id と client_secret を要求します。これらのホストでは、bug_Agent_ ダッシュボードからワークスペーススコープの OAuth 認証情報ペアを生成し、ホストのコネクタフォームに貼り付けます。認証情報は MCP ホストに依存しません。認証コード + PKCE をサポートするすべての OAuth クライアントが使用できます。以下の手順では、最も一般的な例として Claude.ai Web アプリを使用します。

bug_Agent_ で: 設定 → 開発者 → MCP コネクタ を開きます。コネクタを生成 をクリックし、ホストを説明する名前 (例: “Claude.ai (work)”) を付け、MCP ホストが必要とするリダイレクト URI を貼り付け (Claude.ai Web アプリの場合は https://claude.ai/api/mcp/auth_callback です。他のホストについてはホストのコネクタドキュメントを確認してください)、認証方法として Confidential を選択します。成功画面に一度だけ表示される client_id と client_secret をコピーします。
MCP ホストのコネクタ / OAuth 設定で、以下を貼り付けます:
- サーバー URL: https://mcp.bugagent.com/mcp
- クライアント ID + クライアントシークレット: 手順 1 から
- 認証 URL: https://mcp.bugagent.com/authorize
- トークン URL: https://mcp.bugagent.com/token Claude.ai の場合: claude.ai/customize/connectors に移動し、MCP コネクタを追加 をクリックします。
保存します。ホストは bug_Agent_ にリダイレクトしてサインイン (Google またはメール/パスワード — ダッシュボードに使用する方法) し、同意を承認してから、OAuth ハンドシェイクを完了します。
同じ設定ページから、生成されたコネクタを管理および取り消します。取り消しは即時に行われ、そのコネクタからの次のリクエストは invalid_client を返します。

注: Claude Code、Cursor、VS Code、MCP Inspector はこのフローを必要としません。これらは動的クライアント登録 (RFC 7591) を自動的に処理し、上記のように API キーで認証します。MCP コネクタフォームは、静的な OAuth 認証情報を必要とするホスト専用です。

オプション 8 — curl を使用した直接 HTTP (ターミナル)

クライアントなしでサーバーを直接テストしたい場合、またはスクリプトに統合したい場合は、curl で HTTP エンドポイントにアクセスできます。MCP プロトコルは、Streamable HTTP 上の JSON-RPC 2.0 です。

macOS / Linux

ターミナル

# Set your API key as a variable
export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

# 1. List all available tools
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

# 2. Call a tool — list 5 reports from a specific project
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc":"2.0",
    "id":2,
    "method":"tools/call",
    "params":{
      "name":"list_bug_reports",
      "arguments":{"project":"bugagent","limit":5}
    }
  }'

Windows (PowerShell)

PowerShell

# Set your API key
$env:BUGAGENT_API_KEY = "ba_live_YOUR_KEY_HERE"

# Use Invoke-RestMethod (PowerShell's curl equivalent)
$headers = @{
  "Authorization" = "Bearer $env:BUGAGENT_API_KEY"
  "Content-Type" = "application/json"
  "Accept" = "application/json, text/event-stream"
}

# 1. List all tools
$body = '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" `
  -Method Post -Headers $headers -Body $body

# 2. Call list_bug_reports for a specific project
$body = @{
  jsonrpc = "2.0"
  id = 2
  method = "tools/call"
  params = @{
    name = "list_bug_reports"
    arguments = @{ project = "bugagent"; limit = 5 }
  }
} | ConvertTo-Json -Depth 5

Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" `
  -Method Post -Headers $headers -Body $body

応答は Server-Sent Events (MCP Streamable HTTP 標準) として到着します。各チャンクは data: で始まり、その後に JSON オブジェクトが続く行です。Accept: application/json, text/event-stream ヘッダーは必須です。これがないとサーバーはリクエストを拒否します。

ℹ️

トラブルシューティング 401 Unauthorized: 設定 → API キーで API キーが取り消されていないか確認してください。キーは ba_live_ で始まります。それでも解決しない場合は、キーを再生成して再試行してください。

試してみる — 平易な英語のプロンプト

接続したら、ツール名やパラメータを知る必要はありません。平易な英語でやりたいことを説明すれば、AI アシスタントが適切な bug_Agent_ ツールを自動的に呼び出します。

バグレポート

AI アシスタントに依頼する

List my 5 most recent bug reports
Show all open critical bugs in the Auth project
Create a bug titled "Login broken on Safari" with severity s2
Update TEST-451 status to in-progress and assign it to me
Add a comment to TEST-451: "root cause confirmed — null check missing in auth middleware"
Show me everything filed this week, grouped by severity

テスト管理

Create a test suite called "Smoke Tests" with cases for login, checkout, and account settings
Run the Regression suite and list all failures
Show failing test cases from the last 7 days
Which test cases have never been run in the past 90 days?
Get a pass-rate trend for this month vs last month

セキュリティとパフォーマンス

Run a security scan on https://app.example.com
Get this month's security scan results — show only high and critical findings
Create a performance test for the landing page and check Lighthouse scores
What are the Core Web Vitals for our checkout flow?

Playwright 自動化

Create a Playwright script that logs in and verifies the dashboard loads
Run the checkout automation on iPhone 15 Pro on a real device
Optimize the login automation script
Show runs for the checkout automation — any failures?
Schedule the smoke test suite to run every weekday at 6 AM UTC

探索的 AI

Run an exploratory AI session on https://app.example.com with 5 parallel agents
Get the latest exploration run results — list any bugs that were filed
What testing strategies did the agents use and which found the most issues?

使用状況と統計

Check my plan usage for this month
Show team bug stats for this week broken down by severity and type
List all team members and their roles
How many security scans do I have left this month?

クイックリファレンス

8 つのクライアントすべての設定ファイルの場所。すべてのクライアントは、Streamable HTTP 経由でヘッダー Authorization: Bearer ba_live_YOUR_KEY_HERE を使用して https://mcp.bugagent.com/mcp に接続します。

クライアント設定場所 / コマンド

MCP Inspector ファイルなし — npx @modelcontextprotocol/inspector の後、ブラウザ UI で URL と認証ヘッダーを入力

Claude Desktop — macOS ~/Library/Application Support/Claude/claude_desktop_config.json

Claude Desktop — Windows %APPDATA%\Claude\claude_desktop_config.json

Claude Code (CLI) claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_..."

Codex CLI ~/.codex/config.toml

Cursor — macOS 設定 → MCP UI、または ~/.cursor/mcp.json

Cursor — Windows %USERPROFILE%\.cursor\mcp.json

VS Code + Continue ~/.continue/config.json (macOS) / %USERPROFILE%\.continue\config.json (Windows)

直接 HTTP (curl) curl / Invoke-RestMethod — Accept: application/json, text/event-stream を含める

トラブルシューティング

症状修正方法

401 Unauthorized キーが間違っている、期限切れ、または取り消されています。設定 → API キーを確認してください — キーは ba_live_ で始まります。必要に応じて再生成してください。

クライアントにツールが表示されない設定を編集した後、クライアントを完全に終了して再起動してください。Claude Desktop では、Cmd+Q (ウィンドウを閉じるだけではありません)。Cursor では、設定 → MCP で緑色のドットを確認してください。

Accept header required 直接 HTTP 呼び出しには Accept: application/json, text/event-stream を含める必要があります — Streamable HTTP 仕様で要求されています。これがないとサーバーは 406 を返します。

間違ったワークスペースのデータ各 API キーは 1 つのワークスペースにスコープされています。設定 → API キーで、クエリを実行するワークスペースから新しいキーを生成してください。

ツールは表示されるが呼び出しが暗黙的に失敗するサーバーが到達可能であることを確認します: curl -I https://mcp.bugagent.com/health は 200 を返すはずです。タイムアウトする場合は、ネットワーク/ファイアウォールルールを確認してください。

MCP Inspector CORS エラー Inspector UI で接続タイプとして Proxy (Direct ではない) を選択します。Inspector はブラウザの CORS 制限を回避するためにローカルの Node プロセスを介してプロキシします。

Codex CLI — ツールが認識されない ~/.codex/config.toml が [[mcp_servers]] (二重括弧、配列構文) を使用していることを確認します。Codex CLI のバージョンが MCP をサポートするのに十分新しいことを確認します (codex --version)。

MCP 機能

bug_Agent_ MCP サーバーは以下のツールを提供します:

🐛

バグレポート管理

create_bug_report — バグ、機能リクエスト、改善、技術的負債など19種類に自動分類される新しいレポートを提出します（タイトル: 3〜500文字）。オプションの attachments 配列は、それぞれ最大400MBのbase64エンコードされたファイル（画像、動画、音声、PDF、テキスト/JSON）を受け付けます。format_description: true を設定すると、AIを使用して説明を構造化テンプレートに自動整形します。QA作業を追跡するには time_spent_seconds を渡します。priority (urgent / high / normal / low) を渡して、重大度とは独立して修正の緊急度を設定します。レスポンスには project_id、project、short_id、legacy_short_id、project_short_id が含まれます。
list_bug_reports — レポートを一覧表示およびフィルタリングします（1ページあたり最大100件）。プロジェクトフィルターはページネーションの前にサーバーサイドで適用されます。project (UUID、スラッグ、完全一致の名前、またはチケットプレフィックス)、project_id、project_slug、project_prefix、workspace (UUID、完全一致の名前、またはワークスペースチケットプレフィックス)、workspace_id/team_id、type (19のダッシュボードカテゴリのいずれか)、severity (s1-s4 または従来の critical/high/medium/low)、status (ダッシュボードの正確な値を使用: new、awaiting-triage、confirmed、in-progress、blocked、resolved、retesting、closed、reopened — ハイフンは意図的なものです)、resolution (fixed / duplicate / works-as-designed / cannot-reproduce / will-not-fix / need-more-info / unresolved)、root_cause (オープンエンドのケバブケースタグ — 一般的な値: regression、missing-requirement、documentation、incomplete-refactor、not-a-bug、requirements-mismatch)、または reporter_user_id (レポートを提出したチームメンバーのUUID — 名前をUUIDに解決するには最初に list_team_members を呼び出します) でフィルタリングします。各結果には reporter_user_id、project_id、project、short_id、legacy_short_id、project_short_id が含まれるため、エージェントは正しいプロジェクトスコープのレポートにリンクして更新できます。
pick_next_bug — エージェントループが次に取り組むべきバグを優先順位順（S1 → S2 → S3、各バケット内で最も古いものを最初に）に返します。自動的にワークスペースにスコープされ、status new、awaiting-triage、または confirmed と重大度 S1-S3 のチーム内の全プロジェクトにわたるチケットを返します。読み取り専用 — チケットをアトミックに要求しません。オプションの severity (単一階層)、limit (1-50、デフォルト1)。ツールの構成可能性のために list_bug_reports と同じ形状の行を返します。読み取り後要求パターンのために claim_bug とペアにします。
claim_bug — バグを status new、awaiting-triage、または confirmed から status='in-progress' にアトミックに移行し、assigned_to を呼び出し元ユーザーに設定し、claimed_at=NOW() を刻印します。PostgresのUPDATE-WHERE-RETURNINGパターンにより、同時呼び出し元間で競合がありません — 2つのエージェントが同じIDで claim_bug を短い間隔で呼び出した場合、正確に1つがバグ本文を含む claimed:true を取得し、もう1つは理由文字列を含む claimed:false を取得します。pg_cronリーパーは、古い要求（status=in-progress かつ claimed_at が30分以上経過）を自動的に new に解放するため、クラッシュしたエージェントのチケットは手動介入なしでキューに再投入されます。入力: id (UUID または短縮ID)。
get_bug_report — IDでレポートの完全な詳細を取得します。ID形式: UUID (例: 1fb72a2c-87c7-...)、ワークスペーススコープの短縮ID (例: WRKID-545)、またはプロジェクトスコープの短縮ID (例: WRKID-APP-042) のいずれかを受け付けます。短縮IDルックアップはチームスコープです — 別のワークスペースの短縮IDを推測すると404が返ります。project_id、project、short_id、legacy_short_id、project_short_id、ticket_number、project_ticket_number、qualityScore (整数 1–10)、および qualityBreakdown (10のディメンションスコアを持つオブジェクト: reproductionSteps, expectedVsActual, environmentDetails, evidence, rootCauseAnalysis, impactAssessment, contextAndHistory, heuristicsAndOracles, clarityAndStructure, actionability — 各0.0–1.0) を返します。
update_bug_report — 既存のレポートのフィールドを更新します。UUIDまたは短縮ID (WRKID-545) を受け付けます。更新可能なフィールドには title、description、type (19のダッシュボードカテゴリのいずれか)、severity、priority (urgent / high / normal / low — 重大度とは独立した修正緊急度)、status (ダッシュボードと完全に一致: new、awaiting-triage、confirmed、in-progress、blocked、resolved、retesting、closed、reopened — ハイフンは意図的なものです)、resolution (fixed / duplicate / works-as-designed / cannot-reproduce / will-not-fix / need-more-info / unresolved)、および root_cause (オープンエンドのケバブケースタグ — 一般的な値: regression、missing-requirement、documentation、incomplete-refactor、not-a-bug、requirements-mismatch) が含まれます。エージェントループの規則では、status が new から移行するたびに resolution と root_cause の両方を設定する必要があります。ダッシュボード、分析、および将来の claude-bot トレーニングコーパスはすべてこれらのフィールドに依存しています。また、assigned_to (list_team_members からのユーザーID) とタイマー追跡用の time_spent_seconds も含まれます。assigned_to を変更すると、アプリ内ベル通知と新しい担当者への案内メールが自動的にトリガーされます（アカウント設定でのユーザーごとのオプトアウトを尊重します — ダッシュボードエンドポイントと同じパイプラインです）。
add_comment — バグレポートにコメントを追加します（UUIDまたは短縮ID、本文1〜10000文字）。レポートがJiraと同期されている場合、コメントはリンクされたJira課題に自動的にプッシュされます。
list_comments — レポートの完全なコメントスレッドを古い順に一覧表示します — 各コメントには作成者名、parentId (スレッド返信)、タイムスタンプが含まれます。コメントは get_bug_report の一部ではないため、これがチケットのディスカッションを読む方法です。UUIDまたは短縮IDを受け付けます。
link_bug_reports — 同じワークスペース内の2つのバグレポート間に方向性のあるセマンティックリンクを作成します。link_type は duplicate-of、parent-of、related-to、depends-on、または testing-blocked-by のいずれかです。逆の視点 (duplicated-by / subtask-of / blocks / blocks-testing) は読み取り時に導出されるため、保存する必要があるのは1行だけです。from_report_id と to_report_id はどちらもUUIDまたは短縮ID (WRKID-545) を受け付けます。
unlink_bug_reports — 以前に作成されたバグレポートリンクをそのUUID (link_id、link_bug_reports または list_bug_report_links によって返される) で削除します。
list_bug_report_links — バグレポートに関連するすべてのユーザーキュレーションリンクを一覧表示します。各リンクを、提供されたレポートの視点から読み取ったとおりに返します — 例: このレポートがターゲットである保存された duplicate-of 行は duplicated-by としてレンダリングされ、このレポートがターゲットである parent-of は subtask-of としてレンダリングされ、このレポートがターゲットである depends-on は blocks としてレンダリングされ、このレポートがターゲットである testing-blocked-by は blocks-testing としてレンダリングされます。related-to は対称的です。get_bug_report によって返される自動検出された similar_reports フィールドを補完します。
classify_bug — 説明を19のレポートタイプ（バグ、機能、改善など）のいずれかに信頼度スコア付きで分類します
flush_reports — 古いレポートを一括削除します（管理者のみ）

📊

使用状況と分析

get_usage — プラン制限に対する使用状況を確認します
get_stats — 日次カウント、タイプ/重大度/ステータスの内訳

📁

プロジェクト管理

list_projects — 利用可能なプロジェクトを id、name、slug、ticket_prefix、説明、デフォルトステータスとともに一覧表示します。これらの値を create_bug_report および list_bug_reports で使用して、正しいプロジェクトをターゲットにします。
create_project — 新しいプロジェクトを作成します（最初の場合は自動的にデフォルトになります）
delete_project — プロジェクトと関連するすべてのデータ（バグレポート、自動化、テストケース、モバイルアプリ、スケジュール、ジオスナップ、メモ、時間エントリ）を完全に削除します。所有者/マネージャーのみ。最後のプロジェクトは削除できません。ストレージは自動的に解放されます
export_okf_bundle — プロジェクトのQAナレッジ（バグレポート、テストケース、自動化、パフォーマンス、セキュリティ、探索的テスト）をOKF/OQAマークダウンバンドル（oqa.aiで使用されるOpen Query Agent形式）としてエクスポートします。デフォルトはアクティブなプロジェクトです。オプションの project（スラッグまたは名前）を渡して別のプロジェクトをエクスポートします。バンドル内のファイルリストと、base64エンコードされたzipとしてのバンドル自体を返します

🔐

認証とアカウント

register_account — 新しいアカウントを作成します（パスワード: 8〜128文字、レート制限: 5回/15分）
login — サインインしてアクセストークンを受け取ります（レート制限: 5回/15分）
update_profile — 表示名を更新します
change_password — アカウントパスワードを変更します
get_settings / update_settings — 設定を管理します

🔑

APIキー管理

generate_api_key — 名前付きAPIキーを作成します
list_api_keys — アクティブなキーを一覧表示します（プレフィックスのみ）
regenerate_api_key — キーを取り消して置き換えます
delete_api_key — キーを完全に取り消します

👥

チーム管理

list_team_members — ワークスペースのすべてのメンバーを役割、ステータス、ブースターフラグとともに一覧表示します
invite_team_member — メールでユーザーを招待します（マネージャーはコントリビューターとマネージャーを招待できます。管理者を招待できるのは所有者のみです）。5日間有効なリンク

🎯

統合

sync_to_jira — チームの共有接続を使用してレポートをJiraに同期します
push_to_claude — バグレポートの開発者ノート（根本原因、推奨修正、検証手順、リスク評価）を生成（または再生成）します。UUIDまたは短縮ID (WRKID-545) を受け付けます。プラットフォームキーを使用します — チームごとのClaude接続は不要です。適応型チェーンを実行します: s3/medium または s4/low のバグでは3ステップ（Sonnetドラフト → OpenAI gpt-5 批評 → Sonnet統合）、上位2つの重大度バケット — s1/critical または s2/high — では5ステップ（ドラフト → 批評 → Sonnet反論 → 完全なトランスクリプトを読み、独立した判断で最終ノートを作成するClaude Opus裁定者）。レスポンスはすべてのラウンドを公開します: analysis、draft、critique、rebuttal、challenger_model、adjudicator_model、および debated フラグ。いずれかのステップが失敗すると、次善の回答にフォールスルーします。バグ作成時に自動発火します。通常、手動再生成の場合にのみ呼び出されます。
analyze_fix_area — 開発者ノートの「推定修正領域」サブブロックを生成（または再生成）します — 修正が最も可能性の高いコードベース内の場所を指定する狭いSonnet出力です。UUIDまたは短縮IDを受け付けます。プラットフォームのAnthropicキーを使用します。チームに github_connections 行があり、プロジェクトに github_repo がマップされている場合、出力は接続されたリポジトリからの実際のファイルスニペットに基づきます。それ以外の場合は、リポジトリの接続を促す一般的なガイダンスにフォールバックします。likely_fix_area テキスト、generated_at、repo_used、および grounded フラグを返します。バグ作成時に自動発火します — エージェントは通常、手動再生成の場合にのみこれを呼び出す必要があります。
upgrade_plan — Stripe経由でサブスクリプションをアップグレードします

⚡

パフォーマンステスト* `create_performance_test` — URL、デバイス、仮想ユーザー数、実行時間、スコアしきい値、自動バグ作成の有効/無効を設定したパフォーマンステスト設定を作成します。Enterprise のみ

run_performance_test — Web パフォーマンステストのページ監査と負荷テストをトリガーします。結果をポーリングするための実行 ID を返します。モバイルアプリのプロファイリング実行はダッシュボードからトリガーします
get_performance_results — Lighthouse スコア（パフォーマンス、アクセシビリティ、ベストプラクティス、SEO）、Core Web Vitals（LCP、FID、CLS、FCP、TTFB、INP、TBT、SI）、負荷テストメトリクス（VU、リクエスト数、RPS、p50/p90/p95/p99 レイテンシ）を含む完全な結果を取得します
list_performance_tests — 現在のチームのすべてのパフォーマンステスト設定を一覧表示します
get_performance_usage — 月間パフォーマンステスト使用量を確認します。パフォーマンステストは Enterprise のみです。Free=0、Enterprise=無制限

ワークフロー例

get_performance_usage → 残りのクォータを確認
create_performance_test → URL のテストを設定
run_performance_test → 監査 + 負荷テストをトリガー
get_performance_results → スコアとバイタルを確認

🛡

セキュリティスキャン

create_security_scan — セキュリティスキャン設定を作成します。Web スキャンは Quick Scanner + Nuclei（4,000 以上のテンプレート）を使用し、3 段階の深さレベルとオプションの認証スキャンに対応します。モバイルスキャンは APK/IPA バイナリ解析に MobSF を使用します。重大度しきい値による自動バグ作成を設定可能です。Enterprise のみ
run_security_scan — 脆弱性スキャンをトリガーします。Web スキャンには DNS ドメイン検証が必要です。モバイルスキャンにはアップロードされたアプリが必要です。結果をポーリングするための実行 ID を返します
get_security_results — セキュリティスコア（0-100）、CWE リファレンス、OWASP マッピング、エビデンス、修復ガイダンスを含む重大度（Critical、High、Medium、Low、Info）別に分類された検出結果を含む完全な結果を取得します
list_security_scans — 現在のチームのすべてのセキュリティスキャン設定を、最終スコアと認証/深さバッジとともに一覧表示します
get_security_usage — 月間セキュリティスキャン使用量を確認します。セキュリティスキャンは Enterprise のみです。Enterprise=無制限
list_security_schedules — チームのすべてのスケジュールされたセキュリティスキャンを、cron、タイムゾーン、有効状態、次回実行、通知設定とともに一覧表示します。親スキャン設定（名前、scan_type、target_url）と結合されます
create_security_schedule — セキュリティスキャンの定期的なスケジュールを作成します。scan_id と cron_expression が必要です。スキャン設定ごとに 1 つのスケジュール。オプションの timezone、notify_on_fail（none/email/slack/both）、notify_email、slack_channel_id。すべての実行は月間上限にカウントされます。管理者ユーザーは上限をバイパスします。スキャンの深さは常に実行時にスキャン設定から読み取られます
delete_security_schedule — スケジュールされたセキュリティスキャンを削除します。親スキャン設定や完了した実行には影響しません

get_security_usage → 残りのクォータを確認
create_security_scan → URL またはリポジトリのスキャンを設定
run_security_scan → 1 回限りの脆弱性スキャンをトリガー
create_security_schedule → 定期的な実行を自動化（例：メインブランチでの毎週の SAST）
get_security_results → 検出結果と修復方法を確認

📖

コードレビュー

list_code_reviews — チームの最近の AI コードレビューを一覧表示します。品質スコア、重大度カウント、PR 情報、タイムスタンプを返します。Enterprise のみ
get_code_review — すべての検出結果を含むコードレビューを取得します。各検出結果には、重大度、カテゴリ（bug/security/performance/style/logic/maintainability）、タイトル、説明、コード提案、ファイルパス、行番号が含まれます
get_code_review_usage — コードレビューの使用量を確認します。AI コードレビューは Enterprise のみです。Enterprise では無制限
get_code_review_analytics — レビュー分析を取得します：トレンド、検出カテゴリ/ソース、重大度の内訳、ベロシティメトリクス、トップリポジトリ/作成者。7/30/90 日間の振り返りをサポート

get_code_review_usage → 残りのレビュー数を確認
/dashboard/code-review のダッシュボードで PR をレビュー
list_code_reviews → 最近のレビューを表示
get_code_review → 検出結果と提案を取得

🔍

Exploratory AI

最大 10 の並列エージェントがそれぞれ異なるテスト戦略を使用する、マルチエージェント自律型 Web サイトバグ発見ツール。

list_explorations — チームの Exploratory AI 設定を一覧表示します
create_exploration — 新しい探索を作成します。agent_count（1～10、最大 10）を受け入れ、happy_path、edge_case、security、accessibility、error_path、performance、mobile、data_integrity、navigation、custom の独自戦略で複数の並列エージェントを実行します
get_exploration — エージェント設定と最近の実行を含む探索設定を取得します
get_exploration_run — エージェントごとの進捗、フェーズデータ、エージェント属性付きの検出結果（agent_index、agent_strategy）、リンクされたバグを含む実行結果を取得します
get_exploration_usage — 月間使用量を確認します。Exploratory AI は Enterprise のみです。Enterprise: 無制限（10 エージェント）

create_exploration と agent_count: 5 → 5 つの並列エージェントを設定
ダッシュボードまたは POST /api/explorations/run 経由で実行をトリガー
get_exploration_run → エージェントごとの進捗と検出結果をポーリング
ダッシュボードでエージェント属性付きの重複排除された検出結果を表示

📝

ノート

list_notes — オプションのキーワード検索、プロジェクトフィルター、作成者フィルター、日付範囲でノートを一覧表示します。ユーザーが所有するノート、またはチーム内で共有されているノートを返します。
create_note — 5 つの形式のいずれかでノートを作成します：markdown、plain_text、rich_text、checklist、outline。visibility を private または shared に設定します。タイトルが提供されない場合、最初の 30 文字から自動タイトルが付けられます。オプションの attachments 配列は、それぞれ最大 400 MB の base64 エンコードされたファイル（画像、動画、音声、PDF、テキスト/JSON）を受け入れます。QA 作業を追跡するには time_spent_seconds を渡します。
get_note — コンテンツと添付ファイルを含む完全なノート詳細を取得します。id が必要です。
update_note — タイトル、コンテンツ、形式、可視性、プロジェクト、または time_spent_seconds を更新します。attachments 配列を渡して、ノートの既存の添付ファイルを置き換えずに新しいファイル（それぞれ最大 400 MB）を追加します。作成者のみが更新できます。id が必要です。
delete_note — ノートとその添付ファイルを完全に削除します。作成者のみが削除できます。id が必要です。

create_note → テストセッションノートを開始
update_note → テスト中に観察結果を追加
list_notes → キーワードまたはプロジェクトで過去のノートを検索
get_note → 添付ファイル付きの完全なノートを取得

🤖

自動化

create_automation — カスタム Playwright スクリプトで新しい自動化を作成します（FAB 記録は不要）。name が必要です。オプション：target_url（省略された場合、スクリプト内の最初の page.goto(...) URL から自動導出）、script（Node.js/JavaScript/TypeScript または Python — 言語は自動検出され、デフォルトはプレースホルダー）、status（draft または active、デフォルト：draft）、project_id。自動化 id を返します。Team プランが必要です。ヒント — 自動化の複製: get_automation を使用して元のスクリプトを取得し、create_automation を呼び出して name を "[Copy] Original Name" に設定し、元の script、target_url、project_id を渡します。複製はバージョン履歴なしで draft ステータスで開始されます。
list_automations — Playwright 自動化スクリプトを一覧表示します。project_id または status（draft、active、paused）でフィルタリングします。名前、target_url、last_run_status、run_count を含む自動化の配列を返します。
get_automation — Playwright スクリプトと最近の実行を含む完全な自動化詳細を取得します。id が必要です。ライブ script、script_versions スタック（古い順、最大 100 の以前のエントリ、それぞれ { script, source, timestamp }）、および各実行が実行された script_version_label/script_version_source を持つ recent_runs 配列を含む自動化を返します。特定の履歴バージョンを選択する必要がある場合は、run_automation の前にこれを呼び出します。
run_automation — Playwright テストの即時実行をトリガーします。automation_id が必要です。仮想モード（デフォルト）：ビューポートエミュレーション用のオプションの device（例：desktop、iphone-15）。ライブモード：browserstack: true を bs_browser（chrome、firefox、safari、edge）、bs_os（Windows、OS X）、bs_os_version とともに設定して、実際のデスクトップブラウザで実行します。ライブ実モバイル: bs_os: "android"（デバイス："Samsung Galaxy S25 Ultra"、"Google Pixel 10"、"OnePlus 13R"）または bs_os: "ios"（デバイス："iPhone 17 Pro Max"、"iPhone 16 Pro Max"、"iPhone 15 Pro Max"）を設定し、bs_os_version でデバイス名を渡します。Node.js スクリプトは browserstack-node-sdk を経由します（デスクトップ + Android + iPhone をカバー）。Python スクリプトは browserstack-sdk（pytest-playwright）を経由し、デスクトップのみをカバーします — pytest-playwright の browser_type.connect() が BrowserStack の実モバイルエンドポイントを駆動できないため、Python 経由の実モバイルはサポートされていません。ビデオとネットワークログは自動的にキャプチャされます。コンソールログはデスクトップのみです。バージョンリプレイ: オプションの version_index（整数、0 インデックス）を渡して、自動化の script_versions 履歴から以前のエントリを実行します。デフォルト：version_index が省略されるか null の場合、現在のライブスクリプトが実行されます — 「現在を選択する」ためだけにプレースホルダー値を渡さないでください。範囲外、負の値、または整数でない値は拒否されます。実行レコードは実行された正確なスナップショットを保存し、失敗した実行から自動作成されたバグレポートはエディター内のそのバージョンにディープリンクします。
list_automation_runs — 自動化の最近の実行を一覧表示します。automation_id が必要です。ステータス、duration_ms、error_message を含む実行を返します。
list_schedules — cron、タイムゾーン、デバイス、通知設定を含む、スケジュールされたすべての Web 自動化実行を一覧表示します
create_schedule — スケジュールされた Web 自動化実行を作成します。automation_id と cron_expression が必要です。デバイス、タイムゾーン、notify_on_fail（email/slack/both）、Slack チャネルオプションをサポートします。スケジュールされた実行での BrowserStack Live：browserstack: true を bs_browser、bs_os、bs_os_version とともに渡します — run_automation と同じデバイスマトリックス（Node = デスクトップ + 実 Android + 実 iPhone; Python = デスクトップのみ）。
delete_schedule — スケジュールされた Web 自動化実行を削除します
list_mobile_schedules — デバイス、cron、タイムゾーン、通知を含む、スケジュールされたすべてのモバイル自動化実行を一覧表示します
create_mobile_schedule — 実デバイスでのスケジュールされたモバイル自動化実行を作成します。automation_id、cron_expression、devices 配列が必要です
delete_mobile_schedule — スケジュールされたモバイル自動化実行を削除します
optimize_automation_script — Playwright スクリプトを Sonnet 4 に送信して AI による最適化を行います。セレクター、待機戦略、アサーション、エラーハンドリング、認証パターン、モバイル互換性、strict モードを修正する 12 ポイントのチェックリストを適用します。automation_id が必要です。最適化前に現在のスクリプトバージョンが保存されます。最適化されたスクリプトと変更概要を返します。
undo_automation_script — 自動化スクリプトを以前のバージョンに戻します。最大 10 個の以前のバージョンが保持されます。automation_id が必要です。復元されたスクリプトと残りのバージョン数を返します。

create_automation → カスタムスクリプトでテストを作成
list_automations → 利用可能なテストを参照
get_automation → Playwright スクリプトを検査
run_automation → テストをトリガー
list_automation_runs → 結果と実行時間を確認

⏱️

時間追跡

list_time_entries — チームの時間エントリを一覧表示します。period (today, week, month, all)、project_id、category、sort (newest, oldest, most_time, least_time) でフィルタリングできます。Team プランのみ。
create_time_entry — QA タスクに費やした時間を記録します。description、category、duration_minutes が必須です。オプションで project_id と entry_date を設定できます (デフォルトは今日)。Team プランのみ。
update_time_entry — 既存の時間エントリを更新します。id が必須です。description、category、duration_minutes、project_id、entry_date を更新できます。Team プランのみ。
delete_time_entry — 時間エントリを完全に削除します。id が必須です。Team プランのみ。

create_time_entry → リグレッションテストの45分を記録
list_time_entries → 今週の時間エントリを表示
update_time_entry → 所要時間またはカテゴリを調整
delete_time_entry → 誤ったエントリを削除

☑️

テストケース

階層フォルダ、ネストされたスイート (最大3階層の深さ、実行時にサブスイートが自動展開)、ドラッグ＆ドロップでの並べ替え、AI支援によるケース生成、KPI トレンド、障害分析、スイートの健全性、カバレッジ、テスターの生産性を含む分析レポートタブを備えた、完全なテスト管理。すべてのツールは Supabase を直接呼び出します — HTTP ラウンドトリップなし、ダッシュボードと同じレイテンシ。

ハンズフリー実行: 実行レビューページはカルーセル形式で、一度に1つのケースが表示され、キーボードショートカット (P 合格 · F 不合格 · B ブロック · S スキップ) と音声コントロールが利用可能です。マイクをクリックし、「合格」「不合格」「ブロック」「スキップ」「次へ」「前へ」「メモを追加」(メモフィールドに文字起こし)、「メモを保存」「音声オフ」と話しかけます。成功結果の場合は次の未テストケースに自動的に進みます。不合格の場合はその場に留まり、テスターが詳細を口述してバグを生成できます。Chrome、Edge、Safari で動作します。

ケースとフォルダ

list_test_cases — テストケースを一覧表示します。オプションで search、priority (critical, high, medium, low)、type (functional, regression, smoke, integration, performance, security, usability, exploratory)、status (active, draft, deprecated)、sort (newest, oldest, name, priority) でフィルタリングできます。
create_test_case — テストケースを作成します。2つのテンプレートバリアント: steps (デフォルト) — steps 配列によるステップごとの { action, expected } グリッド。text — text_content による単一の自由形式の説明。両方のフィールドを同じ呼び出しで送信できます (プラットフォームはこれらを独立して保存するため、テスターが後で template_type を切り替えても、どちらかのデータが失われることはありません)。オプションの urls 配列 (最大10個の http/https URL) で参照リンクを添付します。name が必須です。オプション: description、preconditions、template_type、steps、text_content、urls、priority、type、tags、estimated_time (秒)。ファイル添付はダッシュボードの POST /api/test-cases/:id/attachments エンドポイント (マルチパート) 経由でアップロードされます — 現時点では MCP ツールとして公開されていません。
get_test_case — ステップや実行履歴を含むテストケースの完全な詳細を取得します。
list_test_case_folders — チームのフォルダを一覧表示します (folder_id によるケースごとに1つのフォルダ。多対多のテスト計画グループであるスイートとは異なります)。上限500。project_id および parent_folder_id フィルタを適用します (トップレベルのみの場合は "root" を使用)。
create_test_case_folder — フォルダを作成します (parent_folder_id により最大3レベルまでネスト可能)。bulk_update_test_cases を使用してケースをその中に移動します。
bulk_update_test_cases — 最大500件のケースに一度に1つのアクションを適用します: set_priority、set_status、set_type、add_tags、remove_tags、add_to_suite、pin、unpin。
link_test_case_to_bug — テストケースとバグレポート間のトレーサビリティを確立します (verified_by、covers、または relates)。
list_test_case_links — テストケースのすべてのトレーサビリティリンクを一覧表示します。
list_test_case_review_candidates — デッドテストフラグ: never_run (作成から90日以上経過)、always_passes (90日以内に5回以上の連続合格)、always_skipped (3回以上の連続スキップ)。
mark_test_case_review_flags — 現在のアーカイブ候補フラグを test_cases.review_flag に永続化します。pg_cron により毎週月曜日 09:00 UTC に自動実行されます。

インポート

Figma インポート (ダッシュボード UI + REST): Figma フレームの zip エクスポート (最大100 MB) をアップロードすると、Claude が各画面を分析し、選択または作成したフォルダにテストケースのドラフトを作成します。プロンプトキャッシング、429 リトライ、フレームごとのエラー分離を備えたマルチパスパイプライン (分類 → 画面ごとのケース → 共有プレフィックス画面にわたるフローレベルのケース → 自己批評) により、1つのフレームの不良がバッチ全体を失敗させることはありません。ケースは status=active として作成され、ai_generated=true のタグが付けられ、source='figma' と source_frame_name に元のフレームへのリンクが保持されます。プラットフォームの Anthropic キーを使用するため、チームごとの Claude 接続は不要です。エンドポイント: POST /api/test-cases/import/figma/request、POST /api/test-cases/import/figma/start、GET /api/test-cases/import/figma/:id。

スイートと実行

list_test_suites — テストスイートをケース数と最終実行ステータスとともに一覧表示します。
create_test_suite — スイートを作成します。parent_suite_id により最大3レベルまでネスト可能。
list_test_runs — テスト実行をスイート名、担当者、合格/不合格サマリーとともに一覧表示します。
create_test_run — スイートのスナップショットを取得し、新しい実行を作成します。親スイートを実行すると、すべての子孫サブスイート内のすべてのケースが自動的に含まれます (両方にリンクされているケースは1回だけ追加されます)。各 test_run_results 行には、ケースがどの元のサブスイートから来たかが記録されるため、結果ページで元のグループごとに表示できます。

レポート (Tier 1 + Tier 4 分析)

get_test_reports_overview — 期間の主要 KPI (合格率、完了した実行、実行されたケース) と、前の同等期間との差分。レポートタブの KPI ストリップに表示されるのと同じ数値です。
get_test_reports_failures — 4つの「修正すべき点」リスト: failing_cases (不合格率50%以上、最低3回の実行)、flaky_cases (合格/不合格の変動が最多)、failing_suites (不合格率30%以上、最低5回の実行)、regressed_cases (期間内に以前合格したが直近で不合格となったもの)。

create_test_case_folder → フォルダツリーを作成 (例: Smoke → Auth)
create_test_case → ケースを定義し、bulk_update_test_cases でフォルダに移動
create_test_suite → テスト計画を構築 (サブスイートはオプション、最大3階層の深さ)
create_test_run → 親スイートから実行のスナップショットを作成 — サブスイートは自動的に含まれる
get_test_reports_failures → 実行完了後、「今週修正すべき点は？」と質問
get_test_reports_overview → 合格率のトレンドを週ごとに追跡

⚡

チームブースター

scale_team — ブースターテスターで QA チームを即座に拡大します。アカウントはテスターアクセス権で自動的にプロビジョニングされます。team_size (1～10)、location、duration、budget を指定し、オプションで product_url、product_types、tech_levels を指定します。Team プランで利用可能。承認が得られるまで課金されません。

scale_team → 米国で5名のシニアテスターを1か月間プロビジョニング
list_team_members → 新しいテスターがチームに表示されることを確認
list_reports → ブースターテスターが提出したレポートを確認

📱

モバイルテスト

upload_mobile_app — 実機でのテスト用に APK (Android) または IPA (iOS) アプリをアップロードします。name、platform (android/ios)、file_url が必須です。iOS の場合: 実機実行用に IPA をアップロードし、録画を有効にするためにアプリ詳細ページでシミュレーター用の .app ビルドをアップロードします。
update_mobile_app — アプリのバイナリを新しいバージョンに置き換えます。キャッシュされた URL とシミュレータービルドをクリアし、次回の実行からすべての自動化が新しいバージョンを使用するようにします。app_id と file_url が必須です。オプション: version。
create_mobile_automation — テストスクリプトを作成します。name、app_id、script_type (YAML の場合は maestro、Appium Python の場合は appium、Appium JavaScript の場合は appium_js)、script (テストスクリプトの内容) が必須です。
import_mobile_script — 既存のモバイルテストスクリプトをインポートし、実行可能な自動化に変換します。開発者自身のロケーターを保持するため、実行時に要素が正確に解決されます。サポートされる方言: Appium‑Python、WebdriverIO、Maestro (YAML フロー)、Playwright (モバイルウェブ)。Android アプリのみ。name、app_id、script が必須。target_devices はオプション。自動化に加えて、action_count、検出された dialect、マッピングできなかったセレクターの warnings を返します。
list_mobile_runs — モバイルテスト実行の結果 (ステータス、デバイス、ビデオ、BrowserStack セッション、自動作成されたバグ) を取得します。モバイル実行はダッシュボードから、またはスケジュールでトリガーされます。オプションのフィルター: automation_id、status (queued, running, passed, failed, error, archived)、limit。アーカイブされた実行はデフォルトの一覧から除外されます。
create_mobile_credential — プロジェクトの名前付きログインプロファイル (例: “管理者”, “投稿者”) を作成します。モバイル自動化で使用されるユーザー名とパスワードです。両方の値は AES‑256‑GCM で暗号化されて保存され、書き込み専用です — ツールや API がこれらを返すことはなく、他のメンバーや UI には名前のみが表示されます。実行ごとにプロファイルを選択して、再録画なしで異なるロールとしてログインできます。project_id、name、username、password が必須です。Enterprise のみ。
list_mobile_credentials — ログインプロファイルを一覧表示します (オプションで1つの project_id)。非シークレットフィールド (id、name、プロジェクト、作成者、作成日) のみを返します — ユーザー名やパスワードは決して返しません。自動化の実行時に資格情報の選択として、返された id を使用します。
delete_mobile_credential — id でログインプロファイルを論理削除します。監査と実行履歴のために保持されますが、使用または一覧表示されなくなり、名前が再利用可能になります。

ワークフロー例 — Android

upload_mobile_app → APK をアップロード
ブラウザでテストを録画 → アクションが自動的にキャプチャされる
ダッシュボードまたはスケジュールから実機 (例: Google Pixel 8) で実行をトリガー
list_mobile_runs → ビデオとログで結果を確認
失敗時は、失敗スナップショットとステップ内訳を含むバグレポートが自動作成される

ワークフロー例 — iOS

upload_mobile_app → IPA をアップロード (実機実行用)
アプリ詳細ページでシミュレーター用の .app ビルドをアップロード (録画用)
ブラウザでテストを録画 → シミュレーターからアクションがキャプチャされる
ダッシュボードまたはスケジュールから実機 (例: iPhone 15 Pro、IPA を使用) で実行をトリガー
update_mobile_app → 準備ができたら IPA を新しいバージョンに置き換え

✅

コンプライアンスと証跡 (Enterprise)

collect_compliance_evidence — 接続されたサービス (Cloudflare、GitHub、Sentry、Supabase、Railway) からの自動証跡収集をトリガーします。実行 ID を返します。SSL/TLS 設定、WAF ステータス、Dependabot アラート、エラートレンド、デプロイ履歴などを収集します。
check_config_drift — 接続されたすべてのサービスで、ベースラインからのセキュリティ設定の逸脱 (SSL モード、TLS バージョン、HSTS、WAF ルール、セキュリティヘッダー) をチェックします。
generate_access_review — 四半期アクセスレビューレポートを作成します。チームメンバー、ロール、MFA ステータス、API キーの使用状況を監査し、推奨事項 (例: 非アクティブなキーの失効) を生成します。
get_security_events — クロスサービスのセキュリティイベントタイムラインをクエリします。ソース (cloudflare、sentry、github) と重大度 (critical、high、medium、low、info) でフィルタリングします。イベントはサービス間で自動的に関連付けられます。

コンプライアンスカバレッジ

これらのツールは、SOC2 (CC4.1, CC6.1, CC7.2, CC8.1)、ISO 27001 (A.5.18, A.8.8, A.8.9, A.8.15-16, A.8.29)、GDPR (Art. 5, 25, 32, 33) のコンプライアンス要件に対応します。## 対応クライアント

bug_Agent_ は、Model Context Protocol をサポートするあらゆるクライアントで動作します。以下は、主要なクライアント向けのセットアップガイドです。

🤖

Claude Desktop

設定 → 開発者 → 設定を編集を開き、以下を追加します。

claude_desktop_config.json

保存後、Claude Desktop を再起動してください。

✳️

Cursor

設定 → MCP サーバー → サーバーを追加を開くか、プロジェクトルートの .cursor/mcp.json を編集します。

.cursor/mcp.json

🌊

Windsurf

設定 → MCP → サーバーを追加を開くか、MCP 設定ファイルを編集します。

mcp_config.json

💻

Claude Code (CLI)

ターミナルから直接 bug_Agent_ を追加します。

claude mcp add bugagent -- npx -y @bugagent/mcp-server

起動前に export BUGAGENT_API_KEY=ba_live_... で API キーを設定してください。

🔧

その他の MCP クライアント

MCP stdio トランスポートをサポートするクライアントであれば、bug_Agent_ は動作します。標準設定を使用してください。

コマンド: npx
引数: ["-y", "@bugagent/mcp-server"]
環境変数: BUGAGENT_API_KEY

CLI

CLI 入門

bug_Agent_ CLI を使用すると、ターミナルからバグレポート、機能リクエスト、プロジェクト、統合を完全に制御できます。以下の用途に活用できます。

ワークフローの自動化 — CI/CD パイプライン、スクリプト、cron ジョブにバグ報告を統合
一括操作 — ターミナルから離れることなく、レポートの一覧表示、フィルタリング、管理が可能
パイプ処理に適した出力 — jq や yq などのツールと連携するための JSON、YAML、Raw 形式
高速な反復 — ブラウザ不要で、数秒でレポートを作成・更新

インストール

npm install -g @bugagent/cli

インストールを確認します。

bugagent --version

認証

API キーを環境変数として設定します。

または、--api-key フラグで直接渡します。

bugagent reports list --api-key ba_live_your_key_here

🔑

bug_Agent_ コンソールから API キーを取得してください。キーは ba_live_ で始まります。

永続的な認証のために、シェルプロファイル（~/.bashrc、~/.zshrc など）にエクスポートを追加してください。

使用方法

コマンドは以下のパターンに従います。

bugagent <resource> <action> [flags]

リソースでは、サブリソースにコロン構文を使用することもできます。

bugagent reports comments add --report-id WRKID-545 --body "Reproduced on v2.1"

任意のコマンドで --help を使用すると詳細が表示されます。

bugagent reports --help
bugagent reports create --help

セッション例

ターミナル

# List your projects
bugagent projects list

# Create a bug report in your default project
bugagent reports create \
  --title "Checkout 500 on discount code" \
  --description "Applying SAVE20 returns HTTP 500" \
  --severity critical \
  --type logic

# View recent reports
bugagent reports list --limit 5 --format pretty

# Get full details on a report (use the short ID or UUID)
bugagent reports get WRKID-545

# Sync a report to Jira
bugagent jira sync --report-id WRKID-545

# Check your usage
bugagent usage get --format json

CLI 機能

CLI は以下のコマンドを提供します。

reports バグレポートの作成、一覧表示、取得、更新、フラッシュ

projects プロジェクトの作成、一覧表示、更新、削除

keys API キーの生成、一覧表示、再生成、失効

jira Jira 設定の接続、レポート同期、構成

usage プラン制限に対する現在の使用状況の確認

stats 分析と内訳の表示

profile プロフィールと設定の表示・更新

auth ログイン、登録、認証情報の管理

グローバルフラグ

フラグ説明

--api-key <key> このコマンドの API キーを上書きします

--format <fmt> 出力形式: json、yaml、pretty、raw

--debug トラブルシューティングのためにリクエスト/レスポンスの詳細を表示します

--help 任意のコマンドのヘルプを表示します

--version CLI のバージョンを表示します

出力形式

CLI は、さまざまなユースケースに合わせて複数の出力形式をサポートしています。

`json`

機械可読な JSON。jq や他のツールへのパイプ処理に最適です。

`yaml`

設定ファイルや可読性に適した、人間に優しい YAML 出力です。

`pretty`

デフォルト。ターミナル向けに色付けされ、整形された出力です。

`raw`

未整形の出力。スクリプト作成や自動化に役立ちます。

--transform によるフィルタリング

--transform と GJSON 構文を使用して、出力データをクエリおよびフィルタリングします。

# Default pretty output
bugagent reports list

# JSON for piping to other tools
bugagent reports list --format json

# YAML
bugagent reports list --format yaml

# Raw (no formatting)
bugagent reports get rpt_abc123 --format raw

# Filter with GJSON syntax
bugagent reports list --format json \
  --transform "items.#(severity==critical).title"

AI スキル

CLI は AgentSkill としても利用可能で、AI コーディングアシスタントがあなたの代わりに bug_Agent_ を使用できるようにします。

✨

AgentSkill とは？

AgentSkill を使用すると、AI コーディングアシスタント（Claude Code、Cursor など）が CLI ツールをコンテキストに応じて呼び出せます。bug_Agent_ スキルは、AI アシスタントにバグの報告、プロジェクトステータスの確認、Jira への同期を、あなたがコマンドを入力することなく実行する能力を与えます。

スキルのインストール

claude skills install bugagent --from @bugagent/mcp-server

インストールされると、コンテキスト認識型の AI アシスタントは、製品、テストガイドライン、アップロードされたドキュメントに関する完全な知識を持って、bug_Agent_ コマンドを自然に使用できます。

AI アシスタントプロンプト

"File a critical bug: the payment webhook is returning
a 403 after the latest deploy. It affects all Stripe
events. Assign it to the payments project."

スキルは自然言語を適切な CLI コマンドに変換し、実行します。

🎬

セッションリプレイ + AI アシスタント: セッションリプレイが有効（Team プラン）な場合、AI アシスタントはキャプチャされたユーザーセッション（過去 60 秒間のクリック、ナビゲーション、エラー、ネットワーク障害）を参照して、完全な再現コンテキストを含む、より豊富で正確なバグレポートを自動生成できます。

ヘルプ

サポートが必要ですか？お気軽にお問い合わせください。

Discord コミュニティ

Discord に参加して、リアルタイムのサポートやコミュニティディスカッションにご参加ください。

メールサポート

support@bugagent.com — 通常 24 時間以内にご返信いたします。

bugAgent

Bug Agent MCPで何ができますか？

ドキュメント

MCP

はじめに

セットアップ

インストール

API キーを設定する

MCP クライアント設定

サーバーに接続する

オプション 1 — MCP Inspector (Web UI、初回テストに推奨)

macOS (ターミナル)

Windows (PowerShell または CMD)

オプション 2 — Claude Desktop (Mac + Windows)

macOS

Windows

オプション 3 — Claude Code (CLI)

オプション 4 — OpenAI Codex CLI

永続的な登録 (設定に追加)

インライン — 1 セッション

オプション 5 — Cursor (Mac + Windows)

オプション 6 — Continue 拡張機能付き VS Code (Mac + Windows)

オプション 7 — OAuth 対応ホスト (例として Claude.ai Web を示します)

オプション 8 — curl を使用した直接 HTTP (ターミナル)

macOS / Linux

Windows (PowerShell)

試してみる — 平易な英語のプロンプト

バグレポート

テスト管理

セキュリティとパフォーマンス

Playwright 自動化

探索的 AI

使用状況と統計

クイックリファレンス

トラブルシューティング

MCP 機能

バグレポート管理

使用状況と分析

プロジェクト管理

認証とアカウント

APIキー管理

チーム管理

統合

パフォーマンステスト* create_performance_test — URL、デバイス、仮想ユーザー数、実行時間、スコアしきい値、自動バグ作成の有効/無効を設定したパフォーマンステスト設定を作成します。Enterprise のみ

ワークフロー例

セキュリティスキャン

コードレビュー

Exploratory AI

ノート

自動化

時間追跡

テストケース

ケースとフォルダ

インポート

スイートと実行

レポート (Tier 1 + Tier 4 分析)

チームブースター

モバイルテスト

ワークフロー例 — Android

ワークフロー例 — iOS

コンプライアンスと証跡 (Enterprise)

コンプライアンスカバレッジ

Claude Desktop

Cursor

Windsurf

Claude Code (CLI)

その他の MCP クライアント

CLI 入門

インストール

認証

使用方法

セッション例

CLI 機能

グローバルフラグ

出力形式

json

yaml

pretty

raw

--transform によるフィルタリング

パフォーマンステスト* `create_performance_test` — URL、デバイス、仮想ユーザー数、実行時間、スコアしきい値、自動バグ作成の有効/無効を設定したパフォーマンステスト設定を作成します。Enterprise のみ

`json`

`yaml`

`pretty`

`raw`