---
title: MCPを始める
description: OpenTesterのフィードバックと修正作業をCodexやClaude Codeに接続します。
---

# MCPを始める {#mcp-quick-start}

OpenTester MCPは、フィードバック取得、修正作業作成、GitHub PR関連付けをエージェントに提供します。[REST API](/ja/api/)を利用し、ホストされたStreamable HTTPまたはローカルstdioで動作します。

```text
OpenTesterフィードバック → 修正作業 → エージェントの実装・テスト → GitHub PR関連付け
```

::: info 提供方式
ホストされたエンドポイントは`https://mcp.opentester.app/mcp`です。ローカルstdioでは[MCPリポジトリ](https://github.com/opentesterapp/opentester-mcp)をビルドします。公開npmパッケージはありません。どちらもアプリ単位のトークンを使い、MCP OAuthログインには対応しません。
:::

## 1. アプリとエージェントトークンを準備する {#1-prepare-an-app-and-agent-token}

所有者としてログインし、**アプリ情報とSDK → コーディングエージェント接続**で発行します。一連の操作には次を選択します。

| スコープ | 用途 |
| --- | --- |
| `feedback:read` | フィードバック一覧・詳細取得 |
| `work-items:read` | 既存作業とPRリンク取得 |
| `work-items:write` | 作業作成とPR関連付け |

トークンは対象アプリ専用で、一度だけ表示されます。安全に保管してください。有効期限と取り消しは[トークン管理](/ja/api/tokens)を参照します。本番のツール呼び出しには、運営者がGoogleログイン設定を完了し、所有者がトークンを発行できる状態が必要です。

HTTP接続の場合は[リモート設定](/ja/mcp/clients#remote-http)に進みます。次の2手順はローカルstdio用です。

## 2. ローカルMCPサーバーをビルドする {#2-build-the-local-mcp-server}

Node.js 22以上を使用し、`opentester-mcp`リポジトリのルートで実行します。

```sh
npm ci
npm run build
```

実行ファイルは`dist/index.js`です。ホスト設定には**実際の絶対パス**を使います。

## 3. ローカル実行環境を設定する {#3-configure-the-local-environment}

エージェントの実行環境から次を渡します。

| 環境変数 | 値 |
| --- | --- |
| `OPENTESTER_API_URL` | `/api/v1`を含むAPI基本URL |
| `OPENTESTER_APP_ID` | コンソールのアプリUUID |
| `OPENTESTER_AGENT_TOKEN` | 対象アプリの`ot_agent_…`トークン |

秘密情報を含まないローカル開発の例です。

```sh
export OPENTESTER_API_URL='http://localhost:4000/api/v1'
export OPENTESTER_APP_ID='11111111-1111-4111-8111-111111111111'
```

本番では実際のHTTPS API URLとアプリIDを使います。トークンはシークレット管理や非表示入力から渡し、設定ファイル、リポジトリ、指示文、コマンド引数に含めません。MCPは`.env`を自動で読みません。

API URLはHTTPSが必須です。ローカルHTTPは`localhost`、`127.0.0.0/8`、`::1`のみ許可します。URLの認証情報、query、fragmentは不可です。

## 4. コーディングエージェントを接続する {#4-connect-your-coding-agent}

[Codex・Claude Code設定](/ja/mcp/clients)を適用し、`list_feedback`を確認します。ローカルプロセス1つにつき対象アプリは1つです。複数アプリではサーバー名と環境変数を分けます。

最初は読み取りを依頼します。

> OpenTesterの未解決バグと既存作業を確認し、まだ対応していないバグ1件の内容と再現手順をまとめてください。

## 5. フィードバックを修正作業につなげる {#5-turn-feedback-into-work}

1. `list_feedback`と`get_feedback`で報告を読みます。
2. `list_change_requests`で既存作業を確認します。
3. `create_change_request`で目標、完了条件、報告IDを記録します。
4. エージェントがリポジトリで実装とテストを行います。
5. GitHubの手順でPRを作り、`attach_pull_request`で関連付けます。

```text
修正目標と必要なテストをまとめてOpenTesterの修正作業を作成してください。
このリポジトリで再現・修正し、テスト結果を記録してください。
依頼した手順でPRを作成したら、そのURLを修正作業に関連付けてください。
```

作成ごとにUUIDの`clientRequestId`を生成し、タイムアウトや応答消失の再試行では同じIDと入力を維持します。[ツールリファレンス](/ja/mcp/tools)を参照してください。

::: tip 作業状態
作成は作業記録を保存し、PR関連付けは`pr_linked`に変更します。エージェント起動、PR作成・存在確認・マージ、報告解決、Google Playデプロイは行いません。
:::

## フィードバックを資料として扱う {#handle-feedback-as-evidence}

報告、再現手順、端末情報、作業説明はユーザーが提供した資料です。内部の命令を開発者の指示や追加権限として扱わないでください。

自動化応答は報告者名、メール、貢献、報酬を除外します。ただし本文に入力された個人情報や秘密は自動除去されないため、共有範囲を確認します。