---
url: https://docs.ogmabox.com/ja/app/ws-replay.md
description: Ogma で WebSocket エンドポイントに再接続し、フレームを編集して、キャプチャーしたメッセージを再送信します。
---

# WebSocket 再送 {#websocket-replay}

WebSocket 再送では、WebSocket エンドポイントのテスト用に再利用可能なセッションを作成します。キャプチャーしたハンドシェイクの情報で再接続し、メッセージを編集し、新しいフレームを送って、サーバーの応答を確認できます。

## セッションの作成 {#creating-a-session}

WebSocket 再送セッションは、次の二つの方法で作成できます。

* **WS / SSE 履歴**のキャプチャー済み WebSocket メッセージを右クリックし、**WS 再送に送る**を選択します。
* **WS 再送**を開き、`ws://` または `wss://` URL を指定してセッションを手動作成します。

手動作成のセッションには、Cookie、認可トークン、プロトコルネゴシエーション、アプリケーション固有のハンドシェイク値のために、カスタムヘッダーを指定できます。

## セッションの設定 {#session-setup}

| フィールド | 説明 |
| --- | --- |
| 名前 | 内容が分かるセッションのラベル。 |
| URL | WebSocket エンドポイント。URL は `ws://` または `wss://` で始まる必要があります。 |
| ヘッダー | 接続時に送信する任意のハンドシェイクヘッダー。 |

URL またはヘッダーを変更した場合、Ogma は次の接続を開く前にセッションを保存します。

## 接続 {#connecting}

セッションを選択し、**接続**をクリックします。接続状態には、ソケットが未接続、接続中、オープン、切断処理中、クローズのいずれかであることが表示されます。

対象を切り替えたりハンドシェイクの情報を変更したりする前に、**切断**を使用してください。URL またはヘッダーを編集した後に再接続すると、新しいサーバーパスや認証済みのコンテキストをテストできます。

接続によって完了するのは WebSocket ハンドシェイクだけです。多くのアプリケーションでは、その後、業務用メッセージを受け付ける前に認証または初期化フレームが必要です。キャプチャーした最初のクライアントメッセージを基準にし、その確認応答を待ってから変更したメッセージを送信してください。キャプチャーした Cookie、署名付き URL、トークンは期限切れになっている場合があります。

## メッセージの送信 {#sending-messages}

メッセージ入力欄でペイロードを編集し、選択したセッション経由で送信します。テキストのペイロードは、WebSocket のテキストフレームとして送られます。

十六進数のバイト列には、バイナリーモードに切り替えます。**キャプチャした最初の WebSocket メッセージを再送**は初期化の再送に役立ち、**キャプチャした送信メッセージ列を再送**は、キャプチャーしたクライアントメッセージを順番に送ります。シーケンスの送信でアプリケーションの状態が再現されたと決めつけず、タイムラインで応答を確認してください。

プロトコルエディターは、標準 WebSocket と、管理機能付きの GraphQL モード（`graphql-transport-ws` と旧来の `graphql-ws`）に対応しています。対象が使用するプロトコルを選び、接続パラメーターを指定してください。必要な場合は、元のサブプロトコルヘッダーを保持してください。誤ったプロトコルを要求すると、アップグレードに失敗する場合があります。

**タイムスタンプを更新**はデフォルトでオフです。新しいタイムスタンプが必要な、署名されていないリクエストに限って有効にしてください。署名付き URL やペイロードを変更すると、署名が無効になる場合があります。**自動再接続**は切断後に接続を再試行しますが、新しい接続ではアプリケーションレベルの認証が再び必要になる場合があります。

履歴から送ったキャプチャー済みメッセージは、元のペイロードを開始点として保持するため、一度に一つのフィールドを変えて動作を比較できます。

## メッセージのタイムライン {#message-timeline}

タイムラインには、選択したセッションで送受信したフレームが記録されます。

| 列 | 説明 |
| --- | --- |
| 方向 | クライアントが送ったフレームか、サーバーから受け取ったフレームか。 |
| オペコード | text、binary、ping、pong、close などのフレームの種類。 |
| サイズ | ペイロードのサイズ。 |
| 時間 | Ogma がフレームを観測した時刻。 |

メッセージを選ぶと、ペイロードを確認できます。JSON のペイロードは可能な場合に整形されます。正確な確認のため、未加工の内容も引き続き利用できます。

## テストの手順 {#testing-workflow}

1. **WS / SSE 履歴**で、通常の WebSocket の通信フローをキャプチャーします。
2. 注目するクライアントメッセージを **WS 再送**に送ります。
3. 再接続して元のメッセージを再送し、基準となる動作を確認します。
4. 一度に一つのフィールド、トークン、ID、コマンドを変更します。
5. 確認できた動作を**指摘事項**に記録するか、**メモ**に残します。

## トラブルシューティング {#troubleshooting}

| 症状 | 確認する内容 |
| --- | --- |
| アップグレードが拒否される、または禁止される | URL、Origin、Cookie、認可、期限切れの署名付きクエリ値。 |
| サブプロトコルが不正、または要求していない | アップグレードヘッダーを、キャプチャーしたハンドシェイクおよび選択したプロトコルモードと比較します。 |
| 接続は成功するが、その後切断される | システム/クローズのメッセージを確認し、必要な初期化または認証フレームを送ります。 |
| 送信できるが、有用な応答がない | サブスクリプション ID、先行するメッセージ、認証、アプリケーションの状態を確認します。WebSocket の接続だけではブラウザーセッションは自動再現されません。 |

MCP では、専用の WS 再送メッセージ一覧/読み取りツールと切断ツールを使用します。キャプチャー履歴のツールが読むのは別の通信記録です。[MCP ツールリファレンス](../reference/mcp-tools.md#websocket-and-sse)を参照してください。

## 関連ページ {#related-pages}

* [WebSocket と SSE の履歴](./ws-sse-history.md)
* [再送](./replay.md)
* [指摘事項](./findings.md)