WebSocket (プロフェッショナル)

スキル本体は 英語 で記述されています。ルールまたは会話で指定された場合は、ユーザーの希望言語で答えてください。

標準規格の真実として公式の RFC 6455、MDN WebSocket API、WHATWG WebSockets を使用してください。このスキルは 本番信頼性のデフォルト、メッセージコントラクト規律、および 運用障害モード をエンコードしています。プロジェクトから デプロイメントトポロジ(単一ノード vs クラスタ)、クライアント動作、および 配信/レイテンシ要件 を確認してください。

範囲

websocket-pro は 接続セマンティクス、メッセージコントラクト、再接続/バックプレッシャーパターン、および トランスポート vs SSE/long-poll の選択をアーキテクチャレベルで担当します。deployment-pro / network-infra-pro は イングレス/LB/プロキシ の詳細を担当します。security-pro は 脅威/悪用対策 を深掘りして担当します。api-design-pro は重複配信に対する べき等コマンド 設計を担当します。

関連スキル(本リポジトリ)

スキル	組み合わせる場合
security-pro	チャネル認証、トークン/セッション処理、悪用制御、レート制限
performance-tuning-pro	ファンアウト、負荷下でのスループット、レイテンシ
deployment-pro	イングレスアイドルタイムアウト、TLS ターミネーション、スティッキーセッション
network-infra-pro	L4/L7 タイムアウト、TCP vs アプリケーションハートビート
api-design-pro	べき等ハンドラ、最低限1回配信向けの重複排除キー
stream-rtc-pro	WebRTC シグナリング vs メディアパス

使用する場合

• 永続的なクライアント・サーバー間ソケット接続を持つリアルタイム機能を設計する。
• WebSocket 信頼性(ハートビート、再接続、順序、重複処理)を確認する。
• インスタンスとリージョン全体で pub/sub ファンアウトをスケーリングする。
• WebSocket エンドポイントを悪用、リーク、運用不安定性から強化する。

使用しない場合

• 主な話題が Kubernetes ネットワークポリシー — deployment-pro / network-infra-pro を使用し、ハートビート整合性のセカンダリ参照としてこのスキルを使用してください。
• WebRTC メディアパス全体 — stream-rtc-pro を使用。このスキルは シグナリングチャネル パターンのみに使用してください。

必須入力

• スケール目標(同時接続数、ファンアウトパターン)。
• プロキシ/LB クラス(既知の場合)(ベンダーはアイドルタイムアウト動作を形成します)。

期待される出力

推奨応答形式(厳格) に従ってください — コンテキストから残存リスクまで。

ワークフロー

全体を通じて Karpathy の原則 を適用してください: コーディング前に思考、シンプルさ優先、外科的変更、目標駆動実行。

1. 確認 — ランタイム、ゲートウェイ/プロキシ動作、ロードバランサーポリシー、接続スケール目標、信頼性保証。 → 検証: [コンテキスト文書化]。
2. 仮定を述べる — 要件、制約についての仮定(コーディング前に思考)。
3. 最小限のソリューションを適用 — 正当化されるまでのみエスカレーション(シンプルさ優先)。
4. 外科的変更を行う — リクエストに直接関連するコードのみを修正(外科的変更)。
5. 成功基準を定義 — 検証されるまでループ(目標駆動実行)。
6. 推奨応答形式を使用して応答 — 主なリスクを記載してください。

運用原則

• ライブラリについて議論する前に、接続ライフサイクル と配信保証から始めてください。
• プロキシ/ロードバランサー動作 について明示的に説明してください。多くの本番障害はネットワークエッジから来るためです。
• 製品ニーズを満たす 最もシンプルなトランスポート を優先してください。SSE で十分な場所に WebSocket を強制しないでください。
• ハートビート、再接続、重複処理、バックプレッシャー をコア設計関心事として扱ってください。
• トランスポート関心事をアプリケーションコマンドセマンティクスと認可の深掘りから分離しておいてください。

推奨応答形式

WebSocket 作業にこの構造を使用してください:

1. コンテキスト — ランタイム、スケール、トポロジ、レイテンシ/信頼性要件。
2. 接続モデル — ハンドシェイク、認証、ハートビート、再接続、メッセージフロー。
3. 主なリスク — アイドルタイムアウト、再接続ストーム、重複配信、認証リーク、ファンアウトボトルネック。
4. 推奨変更 — トランスポート、プロトコル、またはインフラ調整を優先順で表示。
5. 検証計画 — 切断、リトライ、プロキシ、負荷下でテストする内容。
6. 残存リスク — 残存する仮定またはまだ証明されていない動作。

このスキルのリソース

• references/websocket-connection-and-message-system-model.md — 接続とメッセージライフサイクルモデル。
• references/decision-framework-and-trade-offs.md — WebSocket vs SSE/long-poll とスケーリング選択。
• references/failure-modes-detection-mitigation.md — 一般的な本番障害モードと対策。
• references/edge-cases.md — タイムアウト、再接続、デプロイメント境界条件。
• references/quality-validation-and-guardrails.md — 検証と正確性ガードレール。

クイック例

ユーザーが尋ねます: 「CDN の背後でクライアントが数分ごとにループ再接続します。」

応答形式:

• ハートビートリズム、プロキシアイドルタイムアウト、再接続ポリシーを個別に検査します。
• 問題がエッジタイムアウト、認証リフレッシュ、またはクライアント再試行動作かを特定します。
• 最小限のトランスポートとインフラ変更をまず推奨します。
• 制御された切断テストと本番テレメトリで検証します。

スキルの完了前のチェックリスト

• トポロジ、スケール、ネットワークエッジの仮定が明示されている。
• 回答がトランスポート問題とアプリケーションレベルセマンティクスを区別している。
• リトライ、重複、バックプレッシャー動作が関連する場合にカバーされている。
• 検証が逆境ネットワークまたはプロキシシナリオを含む。
• 残存する仮定が述べられている。