cometchat-calls

根拠となる情報源： 各プラットフォームの Calls SDK と docs/calls。公式ドキュメント： https://www.cometchat.com/docs/calls/javascript/overview · Docs MCP： claude mcp add --transport http cometchat-docs https://www.cometchat.com/docs/mcp（または MCP を使わずに URL を直接取得してください）。利用する前に、インストール済みのパッケージ／ソースでシンボルを確認してください。

このスキルを使用する場合

• トップレベルの cometchat ディスパッチャーの Step 3.0 で、product === "voice-video" または chat-messaging+voice-video によりここへルーティングされた場合
• ユーザーが通話機能を明示的に依頼した場合：「通話を追加して」、「ビデオ通話を追加して」、「音声通話を追加して」、「通話画面を設定して」、「Calls SDK を統合して」、「CallKit を追加して」
• ユーザーが既存のチャット統合を改良中に、イテレーションメニューから 「通話を追加」 を選択した場合（cometchat の Step 7）

これはすべての通話統合のエントリーポイントです。ファミリー別の cometchat-{family}-calls スキルを直接呼び出してはいけません。このディスパッチャーがファミリーを検出し、統合モード（単独または追加）を選んで、適切な事前条件を満たす正しいスキルへルーティングします。

対応ファミリー：

ファミリー	ファミリー別スキル	Calls SDK パッケージ	現在安定していますか？
Web（React / Next.js / React Router / Astro）	cometchat-react-calls	@cometchat/calls-sdk-javascript	はい
React Native（Expo + bare）	cometchat-native-calls	@cometchat/calls-sdk-react-native	はい
Angular（12–15）	cometchat-angular-calls	@cometchat/calls-sdk-javascript	はい
Android（V5 安定版）	cometchat-android-v5-calls	com.cometchat:calls-sdk-android:5.x（Cloudsmith）	はい — 本番環境に対応
Android（V6 GA）	cometchat-android-v6-calls	chatuikit-{compose,kotlin}-android:6.0.+ + 明示的な com.cometchat:calls-sdk-android:5.0.+ のピア依存関係（「Calls fold in」というマーケティング上の説明は不完全です）	はい — 2026-05-25 に GA。ただし、初期状態では動作しない状態で提供されます：**5 つの必須回避策（W1–W5）**が必要です。ピア依存関係や CometChatCallButtons を使わないことなどが含まれます。ファミリー別スキルを参照してください。
iOS（V5 安定版）	cometchat-ios-calls	CometChatCallsSDK（SPM / CocoaPods）	はい
Flutter（V5 安定版）	cometchat-flutter-v5-calls（すでに存在）	cometchat_calls_sdk（Cloudsmith）	はい
Flutter（V6 GA）	cometchat-flutter-v6-calls（すでに存在）	Calls は cometchat_chat_uikit: ^6.0.1 に統合されています	はい — 2026-05-25 に GA（MaterialApp(navigatorKey: CallNavigationContext.navigatorKey) の明示的な設定が必要です。ファミリー別スキルを参照してください）

ステータス： 9 つすべての通話スキル（このディスパッチャーと、react、native、angular、ios、android-v5、android-v6、flutter-v5、flutter-v6）は作成済みで、各ファミリーの実際の SDK の表面を使ってソース検証済みです（逆コンパイルした calls-sdk-android AAR、CometChatCallsSDK.swiftinterface、@cometchat/calls-sdk-{javascript,react-native} の .d.ts、および Flutter の cometchat_calls_* pub-cache）。Android V5 には、事前作成された 17 個のサブスキルが cometchat-android-v5-calls/references/ にまとめられています。実装に影響するファミリー別の注意事項：Android V6 には 5 つの回避策（W1–W5）が必要、Flutter V6 には MaterialApp(navigatorKey: CallNavigationContext.navigatorKey) の設定が必要、iOS には CometChatCalls.login() がありません（認証は generateToken によるセッションごとの処理です）。

質問に関する規約（すべてのコーディングエージェント対象） — references/asking-questions.md を読んでください。 このスキル内のすべての「質問」／「AskUserQuestion」は、この規約に従います。構造化された質問機能がないエージェントでは、質問を番号付きのテキストリストとして表示し、実際の回答を待ってください（既定値を選んだり推測したりしないでください。自動モードでも省略は認められません）。位置ではなく値／ラベルで対応付け、自由記述での回答も受け付けてください。

通話専用ディスパッチャーが必要な理由

チャットディスパッチャー（cometchat/SKILL.md）は、ユーザーがチャット用の画面を追加することを前提としています。配置に関する用語、コンポーネントカタログ、フレームワークのスキル、検証チェックリストは、すべてチャット向けです。通話は別の画面領域です。

項目	チャットディスパッチャー	通話ディスパッチャー（このスキル）
パッケージ	chat-uikit-* + chat-sdk-*	chat-sdk-* + calls-sdk-*（スタンドアロンモードでは UI Kit なし）
初期化	Chat SDK の初期化 + ログイン	Chat SDK の初期化 + ログイン + Calls SDK の初期化（デュアル SDK の仕様。iOS ≥5.0.2 では、生の CallAppSettings ビルダーより、cometchat-ios-calls §2 を参照して、ai-agent テレメトリーのアトリビューションのために cometchat-settings.json を読み込むファイルベースの CometChatCalls.initFromSettings を優先してください）
配置に関する質問	「チャットはどこに配置しますか？」	「通話の起点はどこに配置しますか？」+「通話ログはどこに配置しますか？」
コンポーネント	Conversations、MessageList、Composer、Users、Groups	CallButtons、IncomingCall、OutgoingCall、OngoingCall、CallLogs
IncomingCall のマウント位置	チャット画面（ユーザーがチャット中でも着信音が鳴ります）	アプリのルート — 常時レンダリングされ、アプリ全体で着信を待ち受けます
VoIP プッシュ（モバイル）	追加機能（任意）	スタンドアロンモードでは必須 — 着信音の鳴らない通話は製品として成立しません
バックグラウンドのライフサイクル	通話機能を追加しない限り該当なし	必須 — Android のフォアグラウンドサービス / iOS の CallKit + PushKit

2 つのディスパッチャーで共有するのは cometchat-{family}-core（初期化 + ログイン + 環境変数 + テーマトークン）ですが、それ以外はすべて異なります。

v4.1 の通話統合の仕組み

チャットディスパッチャーと同じ対話モデル（検出、要件の収集、計画、実装、検証）を、通話の視点で適用します。

手順

ステップ 1 — ファミリーとモードの検出

トップレベルの cometchat ディスパッチャーから起動された場合、フレームワークと認証情報はすでに .cometchat/config.json にあります。検出をスキップして、次を読み取ります。

npx @cometchat/skills-cli config show --json

直接起動された場合（例：ユーザーが 「アプリに通話を追加して」 と入力した場合）は、次を実行します。

npx @cometchat/skills-cli detect --json

ファミリーの検出方法はチャットディスパッチャーと同じです（reactjs、nextjs、react-router、astro、expo、react-native、angular、android、flutter、ios）。

プロジェクトの状態を確認して統合モードを選択します。

シグナル	モード	実行内容
.cometchat/state.json が存在し、チャット画面が接続済み	追加 — 既存のチャットに通話機能を追加	追加セクションにあるファミリー別の -calls スキルを使用します。既存のプロバイダーにパッチを適用して、ルートに IncomingCall をマウントします。チャット画面に通話ボタンをインラインで追加します。VoIP プッシュは任意です。
.cometchat/state.json が存在しない（またはチャット画面がない）かつ product === "voice-video"	スタンドアロン — 通話が製品の主機能	スタンドアロンセクションにあるファミリー別の -calls スキルを使用します。チャット UI Kit はありません。CallButtons + IncomingCall + OngoingCall + CallLogs を使用します。VoIP プッシュを任意ではなく、組み込みます。通話ログ用に /calls ルートまたはプラットフォーム相当のものを設けます。
いずれにも該当せず、ユーザーが通話機能を求めているものの意図が曖昧	質問する	AskUserQuestion を使って、次のように尋ねます。「既存のチャット統合に通話機能を追加しますか、それとも通話を中心としたアプリを構築しますか？」

ステップ 2 — 認証情報の確認

通話機能では Chat SDK の認証情報を再利用します。.env（Web/RN）、local.properties（Android）、Secrets.swift（iOS）、lib/cometchat_config.dart（Flutter）、または src/environments/environment.ts（Angular）に appId / region / authKey がすでにある場合、認証情報の設定をスキップします。

認証情報がない場合は、cometchat/SKILL.md のステップ 2 に戻ります。認証情報の設定手順は、製品に関係なく同じです。ここで認証フローを重複して記載しないでください。

ステップ 3 — 通話固有の要件を収集

ステップ 3.0 — 通話モード（着信音またはセッション）★

これは、通話に関する最初の質問です。Calls SDK は、根本的に異なる 2 種類の UX に対応しています。他のすべてに先立って選択してください。ステップ 3 の残りの内容とファミリー別のスキャフォールドが、選択したモードによって異なるためです。

優先順位に従って判断します。

1. 明示的なシグナルからのみ推測します。 どちらかのモードをデフォルトにしないでください。質問を省略する前に、ユーザーが 2 つの形式のどちらかを明確に示す必要があります。

ユーザーの発言の例…	モード
「1 対 1 の通話」「ユーザー同士の通話」「電話」「友人に電話をかける」「連絡先に電話する」「FaceTime のような通話」「WhatsApp 風の通話」	リンギング
「友人同士のグループ通話」「最大 N 人の電話会議」（少人数のグループで、発信者 1 人が呼び出す）	リンギング
「ミーティング」「Google Meet」「Zoom のようなもの」「予定済みのミーティング」「リンクから参加」「ミーティングルーム」「会議室」「ウェビナー」「タウンホール」「バーチャル教室」	セッション
「ハドル」（Slack 風の、チャンネルからすぐに参加する形式）	セッション
「通話」「電話をかける」「通話を統合する」「通話を追加する」「通話を設定する」「音声／ビデオ通話」のみで、リンギングかミーティングかについての追加情報がない場合	曖昧 — 質問する（デフォルトで決めない）
混在する手がかり（「通話とミーティング」「電話またはビデオ会議」）	曖昧 — 質問する

下の行が最も重要です。**「通話を統合したい」や「アプリに通話機能を追加したい」のような一般的な表現は、リンギングの手がかりではありません。ユーザーがまだ伝えていないという手がかりです。**質問してください。

明確な手がかりがある場合は、ユーザーが訂正できるように、1 行で確認してください。

「了解しました。リンギング（着信画面が表示される 1 対 1／グループ通話）を設定します。代わりにミーティングルームの URL が必要な場合は、そのようにお知らせください。切り替えます。」

**2. 利用可能であれば、Tier 4 のユースケースのコンテキストを使用します。**ユースケースからモードを判断できます。

ユースケース	モード
遠隔医療の医療提供者／患者（1 対 1 の診察）	リンギング
マーケットプレイスの購入者 ↔ 販売者	リンギング
カスタマーサポート（エージェント ↔ 顧客）	リンギング
ブロードキャスト／ウェビナー／タウンホール	セッション
チームのハドル／スタンドアップ	セッション

3. 判断できない場合に限り、質問してください。このプロンプトをそのまま使用してください。言い換えたり、選択肢を入れ替えたりしないでください。選択肢 1 は「セッション」、選択肢 2 は「リンギング」です。

• question：「どのような通話体験を構築していますか？」
• header：「通話モード」
• multiSelect： false
• options（この順序で正確に表示：セッションが先、リンギングが後）：
  1. label：「セッション — ミーティング／会議室」、description：「複数のユーザーが ID またはリンクを使って同じセッションに参加します。呼び出しはありません。Google Meet、Zoom、Slack ハドルのような形式です。例：予定済みのミーティング、ウェビナー、チームのハドル、教室での通話。」
  2. label：「リンギング — 1 対 1 またはグループ通話」、description：「あるユーザーが別のユーザー（または少人数のグループ）に電話をかけます。受信者のデバイスが鳴り、応答または拒否できます。電話のような形式です。例：WhatsApp、FaceTime、アプリ内で連絡先同士が行う音声／ビデオ通話。」

**順序の厳守：**上記の選択肢 1 を選択肢 2 より前に表示してください。順序を入れ替えないでください。セッションを先にする順序は、CometChat 製品全体で標準化されています。

モード値へのマッピング：

• 「Ringing」 → mode === "ringing"
• 「Session」 → mode === "session"

この値に基づいて、ステップ 6 で読み込むファミリーごとのリファレンスが決まります。

モード	リファレンス（ファミリーごと）	リファレンス（Android V5）
ringing	cometchat-{family}-calls/references/ringing-integration.md	cometchat-android-v5-calls/references/ringing-integration.md
session	cometchat-{family}-calls/references/call-session.md	cometchat-android-v5-calls/references/join-session.md

キットに組み込み済みの UI（以前のドキュメントで「Standard」モードと呼ばれていたもの）に関する注記：UI Kit の <CometChatCallButtons /> + <CometChatIncomingCall /> + <CometChatOngoingCall /> は、キットが提供するリンギングの実装であり、3 つ目のモードではありません。ユーザーがリンギングを選択し、キットに組み込み済みの UI も希望する場合（最も一般的なケース）、ファミリーごとのスキャフォールドではキットのコンポーネントを使用し、リンギングのリファレンスをアーキテクチャ上の信頼できる基準として扱います。チャット SDK のシグナリング上にカスタム UI を構築する場合は、リンギングのリファレンスを実装ガイドとして使用します。 ⚠️ グループ通話では Ringing チャネルを使用しません（2026-05-15 に検証済み。すべてのキットに適用されます）。キットの <CometChatCallButtons group={g}> は、CometChat.initiateCall ではなく、type: "meeting" を指定した CometChat.sendCustomMessage を使って、カスタムミーティングメッセージをグループに送信します。他のグループメンバーは、キットベースの受信側では <CometChatMessageList /> にミーティングカードを受信し、カスタム UI の受信側では category: CATEGORY_CUSTOM と type: "meeting" を含む MessageListener.onCustomMessageReceived を受信します。CallListener.onIncomingCallReceived チャネルが呼び出されるのは、1 対 1 のユーザー通話のみです。ユーザーがグループ通話を希望している場合は、ringing-integration.md に加えて references/group-calls.md を読み込んでください。顧客は「グループ向けの着信」と考えていても、グループ通話には独自のアーキテクチャがあります。

ステップ 3.1 — 通話開始の配置場所（どこから通話を開始するか）

チャットディスパッチャーのステップ 3a にあるアーキタイプの質問とは異なります。通話画面における配置の意図を尋ねます。

ユーザーに尋ねます（構造化された形式 question／header／multiSelect／options[].label／options[].description を維持してください）。

• question: 「アプリで通話をどのように開始しますか？」

• header: 「通話開始方法」

• multiSelect: false

• options（選択肢はモードによって異なります。ステップ 3.0 の mode に一致する行のみを表示してください）：

  mode === "ringing" の場合 — 次を表示します：

  1. label: 「ユーザー／連絡先プロフィールの通話ボタン」、description: 「ユーザー名の横に音声通話とビデオ通話のボタンを表示します。マーケットプレイス、ソーシャル、出会い系、ヘルスケアに最適です。」
  2. label: 「常時表示の「/calls」ルート」、description: 「「通話を開始」する相手を選ぶピッカーと通話履歴を備えた専用の通話ページです。遠隔医療、バーチャルイベント、コンタクトセンターに最適です。」
  3. label: 「チャット画面への埋め込み」、description: 「チャットヘッダーに通話ボタンを表示し、メッセージスレッドの横に音声通話とビデオ通話のボタンを配置します。すでにチャット機能があるアプリに最適です。（追加モードのみ。）」
  4. label: 「フローティングウィジェット」、description: 「Zoom のフローティングウィンドウのように、常に表示される通話バブルです。サポート／営業ツールに最適です。」

  mode === "session" の場合 — 代わりに次を表示します：

  1. label: 「ミーティングリンクルート（「/meet/:sessionId」）」、description: 「リンクを知っている人なら誰でも参加できる共有可能な URL です。スケジュール済みのミーティング、ウェビナー、授業に最適です。」
  2. label: 「チャンネルに紐づくハドル」、description: 「チャットチャンネル／グループ ID に紐づくセッションで、チャンネル内の誰でも進行中のハドルに参加できます。チームコラボレーションアプリに最適です。」
  3. label: 「ロビー／待機室ルート」、description: 「ユーザーは待機画面に移動し、ホストが参加を許可します。遠隔医療、カスタマーサポートに最適です。」
  4. label: 「カスタム — 自分で接続します」、description: 「SDK の接続部分だけを提供してください。画面は自分で決めます。」

選択された項目に応じて、読み込むファミリー別の -calls スキルセクションと、スキャフォールドの内容が決まります。

続けて、通話履歴について別に尋ねてください — 通話履歴の画面は、通常、通話開始場所とは異なります。

• question: 「通話履歴をどこに表示しますか？」
• header: 「通話履歴」
• options:
  1. label: 「専用の /calls ルート（または画面）」、description: 「推奨 — 通話履歴全体を表示し、絞り込みや発信者のプロフィールへの移動ができます。」
  2. label: 「通話開始画面の中」、description: 「通話ボタンの下にコンパクトな一覧を表示します。通話数が少ない場合に最適です。」
  3. label: 「通話履歴を表示しない」、description: 「省略 — 通話を開始するだけで、履歴画面は表示しません。」

ステップ 4 — モバイルで必須となる前提条件を検出する

モバイルのファミリー（android、ios、expo、react-native、flutter）では、スタンドアロンモードで VoIP プッシュは必須です。これがないと、不在着信時に着信音が鳴りません。すでに設定されている項目を検出し、ファミリー別の -calls スキルが追加する項目とスキップする項目を把握できるようにします。

Android:

• Firebase Cloud Messaging — app/ 内の google-services.json と、app/build.gradle{.kts} 内の id("com.google.gms.google-services") を探します
• サービスの登録 — AndroidManifest.xml 内の <service android:name=".YourFirebaseMessagingService" ...> を探します
• ConnectionService — AndroidManifest.xml 内の android.permission.MANAGE_OWN_CALLS と BIND_TELECOM_CONNECTION_SERVICE を探します
• フォアグラウンドサービスのタイプ — <service android:foregroundServiceType="phoneCall|microphone|camera"> を探します（Android 14+ では、phoneCall がないと警告なしにクラッシュします）

iOS:

• CallKit — ソース内の import CallKit と、設定済みの CXProvider を探します
• PushKit — ソース内の import PushKit と、PKPushRegistry リスナー（VoIP プッシュトークンの登録）を探します
• 機能 — Info.plist と entitlements 内の Background Modes に voip、audio、remote-notification が設定されているか探します
• マイクとカメラの Info.plist 使用目的の説明文

React Native:

• package.json 内の react-native-callkeep（CallKit + ConnectionService ブリッジ）
• @react-native-firebase/messaging（Android）と PushNotificationIOS の設定
• iOS の VoIP プッシュトークン用の react-native-voip-push-notification

Flutter:

• pubspec.yaml 内の flutter_callkit_incoming、またはネイティブの CallKit/ConnectionService へのプラットフォームチャネルブリッジ
• FCM 用の firebase_messaging
• ネイティブの Info.plist と AndroidManifest.xml のエントリ（Flutter はこれらを自動追加しません）

設定済みの項目と不足している項目を提示します。ファミリー別の -calls スキルは不足分を追加します。設定済みだと決めつけることはありません。

ステップ 5 — 計画を提示して承認を得る

何かを書き込む前に、次の内容を正確にユーザーに提示します。

• インストールするパッケージ
• 新規作成するファイル、変更するファイル、変更せずに残すファイル
• 着信トリガーを配置する場所（ファイルパスを含む）
• 通話ログを保存する場所（上記のオプション 3 を選択した場合は「スキップ」）
• モバイルの場合：追加する VoIP プッシュ関連の成果物（FCM サービス、CallKit プロバイダー、フォアグラウンドサービスの登録、マニフェストの権限、Info.plist のエントリ）
• スキルでは実行できず、ユーザーが手動で行う必要があること（Android：Firebase コンソールで FCM を有効にする、iOS：App Store Connect に VoIP Services 証明書を追加する、Flutter：minSdkVersion がプラットフォームの最低要件を下回る場合は引き上げる）

明示的な承認を待ちます。その後、ファミリー別の -calls スキルを読み込み、スキャフォールドを実行します。

Step 6 — ファミリー別スキルに引き継ぐ

コンテキストから一致するスキルを読み込みます。

検出されたファミリー	読み込むスキル
reactjs / nextjs / react-router / astro	cometchat-react-calls
expo / react-native	cometchat-native-calls
angular	cometchat-angular-calls
android + android_version === "v5"	cometchat-android-v5-calls
android + android_version === "v6"	cometchat-android-v6-calls
flutter + flutter_version === "v5"	cometchat-flutter-v5-calls（既存）
flutter + flutter_version === "v6"	cometchat-flutter-v6-calls（既存）
ios	cometchat-ios-calls

収集したコンテキストを渡します。mode（Step 3.0 の ringing | session）、単独導入か既存実装への追加か（Step 1）、トリガーの配置（Step 3.1）、ログの配置、モバイルの前提条件の状態です。

ファミリー別スキルは、一致するモードのリファレンスを主要な設計指針として読み込みます。

mode	ファミリー別スキル内で読み込むリファレンス
ringing（1対1のユーザー通話）	references/ringing-integration.md（Android V5 では同じ名前）
session（ミーティングルームの URL、チャット側のシグナリングなし）	references/call-session.md（Android V5 では references/join-session.md）

さらに、収集したコンテキストで groupCalls === true の場合（ユーザーが「グループ通話」「チームミーティング」「ハドル」と言及した場合、または Step 3.1 で通話対象に group を選択した場合）、ファミリー別スキルから references/group-calls.md も読み込みます。グループ通話では、1対1の着信とは異なるシグナリングチャネルを使います。CometChat.initiateCall の代わりに、カスタムの "meeting" メッセージをブロードキャストします。ringing-integration.md だけを読み込むと、1対1では動作するコードが生成されますが、カスタム UI の受信側でグループ通話が気付かないまま動作しなくなります。group-calls.md のリファレンスは8つすべてのファミリーにあります。基礎となる意味については、上記の Step 3.0 の説明を参照してください。

ファミリー別スキルがコードを作成します。このディスパッチャーは作成しません。

ファミリー別スキルがエージェントのコンテキストに読み込まれていない場合（つまり、ユーザーが v4.1 より前に @cometchat/skills をインストールし、その後 npx @cometchat/skills add --family <family> を再実行していない場合）、ユーザーには一度だけ次のように伝えます。

「{family} 通話スキルをワークスペースにインストールしました。続行するには /cometchat-calls を再実行してください。設定は .cometchat/config.json に保存されているため、次回の実行では配置に関する質問を再度行わず、コード生成から再開します。」

チャットディスパッチャーと同じホットリロードの制約があります。エージェントはセッション開始時にスキルの一覧を取得し、セッション中には再読み込みしません。このセッションを続けると、ファミリー別スキルが明示的に禁じている、学習済みの知識に基づいた通話コードの作成になってしまいます。

Step 7 — 検証する

ファミリー別スキルがコードを作成したら、次を実行します。

npx @cometchat/skills-cli verify --calls --json

（検証フラグ --calls は、このディスパッチャーと合わせて CLI 2.4.0 で追加されます。二重 SDK 初期化、IncomingCall のルートへのマウント、モバイルでの VoIP プッシュの配線、およびユーザーが選択した通話トリガー／ログの配置を確認します。）

検証に合格したら、ユーザーをイテレーションメニューに進めます。チャットディスパッチャーの Step 7 と同じ形式で、通話向けの選択肢を用意します。

• 機能を追加する（録画、画面共有、PiP、通話中のチャット、カスタム UI）
• 通話画面／参加者リスト／コントロールパネルをカスタマイズする
• 本番環境向けの認証を設定する（サーバーでトークンを生成し、通話フローで Auth Key を使わない）
• 診断を実行する

ハードルール（各ファミリーの -calls スキルが必ず適用すること）

これらは本番運用において譲れない必須事項です。ディスパッチャーはステップ 5 の計画を確認し、各ファミリーのスキルがこれらを記述する責任を負います。

1. デュアル SDK の契約。 Chat SDK は initiateCall（MessageType.CALL を送信）を実行し、Calls SDK は joinSession を実行します。両者は互換性がありません。Android スキルではこれを最初に説明します。マルチプラットフォームの CometChat データで学習したエージェントは、com.cometchat.chat.core.Call と com.cometchat.chat.models.Call を混同し、コンパイルはできても気づかないうちに動作しなくなるコードを書いてしまうためです。
2. VoIP プッシュはスタンドアロンモードで接続し、説明だけで済ませないこと。 iOS では CallKit + PushKit、Android では ConnectionService + FCM high-priority、RN では react-native-callkeep、Flutter では flutter_callkit_incoming を使います。ドキュメントだけでは不十分です。プッシュが機能しなければ、不在着信時に呼び出し音が鳴りません。
3. フォアグラウンド／バックグラウンドのライフサイクルを正しく処理すること。 Android 14 以降では、通話中の foregroundServiceType が誤っていると、何も通知されずにクラッシュします。iOS ではバックグラウンド音声に CallKit による報告が必要です。これは「関連項目」の参照先ではなく、-calls スキルの本文に含めてください。
4. 通話フローではサーバー発行の認証トークンを使用すること。 本番環境の通話フローでは認証トークンを使用し、Auth Key は決して使用しません。このスキルでは既存のトークンエンドポイントを検出し（チャットのディスパッチャーと同じ方法）、loginWithAuthToken() を使用します。
5. 通話終了時にクリーンアップすること。 カメラのライトが点灯し続ける／マイクが有効なままになる問題は、「開発環境では問題なく見えるのに、レビューに通らない」典型的なバグです。各ファミリーのスキルには、明示的な終了処理のチェックリストを含めてください。
6. 理由を説明して権限を求めること。 マイク、カメラ、画面収録（対応している場合）、通知のすべてが必要です。4 項目すべてについて、用途を説明する文言を設定してください。
7. スタンドアロンモードでは IncomingCall をアプリのルートにマウントすること。 チャット画面ではありません。通話が製品全体となるため、リスナーはあらゆる場所で動作している必要があります。
8. ユーザーが SDK のみを指定した場合は「SDK のみ」の要望に従うこと（ENG-35711）。 開発者が UI Kit コンポーネントを使わず Calls SDK を使用するよう明示的に求めている場合（「純粋な SDK」、「UI Kit コンポーネントは使わない」、「通話 UI は自分で作る」、「SDK のみの方法」 といった表現）は、各ファミリーのスキルで CometChatCallButtons、CometChatIncomingCall、CometChatOutgoingCall、CometChatOngoingCall をスキャフォールドしてはなりません。シグナリングには Chat SDK の CometChat.initiateCall を使い、通話画面には Calls SDK の joinSession と手書きのボタン／画面を使ってください。「そのほうが簡単だから」という理由で、UI Kit コンポーネントに黙って切り替えてはいけません。 これは 2 人のテスターから報告された、明確な不満です。開発者の要望を UI Kit コンポーネントなしでは実現できない場合は、明示的に確認してください。「この部分にはキットの <CometChatXxx> が必要です。これを使ってもよいですか？ それとも手書きの代替実装にしますか？」 開発者に代わって判断しないでください。

アンチパターン

1. このディスパッチャーから apply-feature calls を追加しようとしないでください。 この CLI コマンドは v4 のチャットフロー向けで、npm のインストールコマンドを返すだけです。このディスパッチャーが統合をエンドツーエンドで実際に行います。ユーザーが chat-messaging+voice-video モードの場合、チャットフローはすでに実行されています。ここでは追加モードに入るだけです。このスキル内から apply-feature calls を呼び出してはいけません。
2. cometchat-components や cometchat-placement（チャットカタログ）を読み込まないでください。 これらはチャット向けです。各ファミリーの -calls スキルには、独自のコンポーネント一覧（CallButtons、IncomingCall、OutgoingCall、OngoingCall、CallLogs）と独自の配置用語（通話トリガー、ログ表示面、ルートリスナー）があります。チャットカタログを読み込むと、チャットの前提が通話コードに入り込んでしまいます。
3. チャットのアーキタイプに関する質問（「メッセージングアプリ／マーケットプレイス／SaaS／…」）をしないでください。 この分類は、チャットをどこに配置するかを判断するためのものです。通話の配置では、通話トリガーをどこに配置するか＋ログをどこに配置するか＋VoIP プッシュが必須かどうかを判断します。用語も推奨内容も異なります。
4. スタンドアロンモードでは、ユーザーが「後で追加します」と言っても VoIP プッシュを省略しないでください。 着信音が鳴らない通話は製品として成立しません。このディスパッチャーは、VoIP プッシュが接続されていない限り（または、少なくとも明確な TODO と通話画面の赤い警告バナー付きでスキャフォールドされていない限り）、スタンドアロンモードのスキャフォールドを拒否します。
5. V5 と V6 のコホートを混在させないでください（Android、Flutter）。Calls SDK の構成は異なります。V5 Android は calls-sdk-android を独立した Cloudsmith 依存関係として提供しますが、V6 では通話機能が統合パッケージ chatuikit-{compose,kotlin}-android に含まれます。Flutter も同様です。.cometchat/config.json から android_version／flutter_version を読み取り、対応するコホートのスキルに振り分けてください。

正確な情報源

各ファミリーの -calls スキルは、以下の情報源を参照します。ディスパッチャー自体はコードを記述せず、各ファミリーのスキルが記述します。各スキルが対象とする SDK シグネチャを確認するには、各ファミリーの公開済み SDK アーティファクトと公開ドキュメント（信頼できる情報源）を確認してください。以前の草稿では、現在は存在しないローカルの ~/Downloads/calls-sdk/ クローンを参照していました。代わりに、インストール済み／公開済みパッケージを使用してください。

• Android V5： com.cometchat:calls-sdk-android:5.x（Maven AAR を逆コンパイルするか、Gradle キャッシュ内のクラスで javap を実行）＋ドキュメント。17 のサブトピックは cometchat-android-v5-calls/references/{recording,screen-sharing,picture-in-picture,background-handling,voip-calling,audio-controls,video-controls,participant-management,custom-ui,in-call-chat,call-logs,session-settings,event-listeners,join-session,ringing-integration,setup}.md にまとめられています。
• iOS V5： CometChatCallsSDK 5.x — 解決済みフレームワーク内の .swiftinterface（SPM の .build/artifacts/… または CocoaPods の Pods/…。追加モードでは CometChatUIKitSwift 内にベンダー同梱されています）＋ドキュメント。
• JavaScript（Web）： @cometchat/calls-sdk-javascript@5 — パッケージの .d.ts（node_modules/@cometchat/calls-sdk-javascript/dist/index.d.ts）＋ドキュメント。
• React Native： @cometchat/calls-sdk-react-native@5 — パッケージの .d.ts ＋ @cometchat/calls-lib-webrtc（Cloudsmith）＋ドキュメント。
• Flutter： cometchat_calls_sdk（V5：対応する cometchat_calls_uikit:^5.0、V6：cometchat_chat_uikit:^6.0 に統合）— pub キャッシュ内のソースに加え、cometchat-flutter-v5-calls／cometchat-flutter-v6-calls スキル（ソースと照合済み）。
• Angular： Angular の Inputs/Outputs でラップした同じ JS Calls SDK（@cometchat/calls-sdk-javascript）— @cometchat/chat-uikit-angular の .d.ts と JS SDK の .d.ts で確認してください。

2 つの呼び出しモード（リング＋セッション）— リング用のキット標準搭載 UI

名称に関する補足（ENG-35699 のフォローアップ）： 以下のセクションでは「標準」「リング」「通話セッション」の 3 行に分けていますが、アーキテクチャ上のモードは 2 つだけです。リング（シグナリング駆動）とセッション（URL 駆動）です。「標準」はリング用のキット標準搭載 UI（<CometChatCallButtons> + <CometChatIncomingCall> を使用）であり、アーキテクチャ上の 3 つ目のモードではありません。上記のステップ 3.0 のプロンプトで尋ねているリングかセッションかの選択が、重要な判断です。「標準」の行は、リングモード内で最も一般的なレンダリング方法です。

CometChat は、基盤となる通話ワークフローを 2 つサポートしています。以下の表では、ルーティング上の都合に限り、リングを「標準（キット標準搭載 UI）」と「リング（シグナリング上のカスタム UI）」に分けています。

行	基盤となるモード	制御元	用途	ファミリーごとの参照先
標準	リング	UI Kit（CometChatCallButtons + CometChatIncomingCall）	80% のケース — 標準搭載 UI を使ったチャット起点の通話	ファミリーごとの SKILL.md に記載
リング（カスタム UI）	リング	Chat SDK の通話エンティティ + Calls SDK のセッション	CometChat のシグナリング上に構築するカスタムの着信／発信通話 UI	references/ringing-integration.md
通話セッション	セッション	Calls SDK の joinSession を直接使用（リングなし）	ミーティングルームの URL、スケジュール済み通話、会議室	references/call-session.md

ユーザーが「カスタムの着信通話 UI」と明示しない限り（→ リングのカスタム UI）、または「ミーティングリンク／sessionId で参加」と明示しない限り（→ 通話セッション）、リングのレンダリングは「標準」がデフォルトです。Tier 4 のユースケースから、希望するモードを判断できます。ブロードキャストとチームハドルには通話セッションを、テレヘルス、マーケットプレイス、サポートには「標準」またはリングのカスタム UI を使用します。

ユースケース別の統合パターン（Tier 4）

ユーザーがプロダクトについて明確に説明している場合は、推奨する CallSettings、UX、コンプライアンスに関する注意点をまとめた、該当ユースケースの参照ドキュメントに誘導します。

• テレヘルス／オンライン診療 → references/use-case-telehealth.md — 医療提供者と患者のフロー、二者間の同意に基づく録画、待合室、HIPAA に関する注意点
• マーケットプレイス（購入者 ↔ 販売者） → references/use-case-marketplace.md — 推測困難な UID、期間限定アクセス、不正防止のヒューリスティクス
• カスタマーサポート／ヘルプデスク → references/use-case-support.md — エージェントのキュー、品質保証のための自動録画、通話後の CSAT
• ブロードキャスト／ウェビナー／タウンホール → references/use-case-broadcast.md — 固定 SIDEBAR、デフォルトでミュートされた参加者、挙手機能を使った Q&A、100 人以上向けの RTMP ブリッジ
• チームハドル／スタンドアップ／共同作業 → references/use-case-team.md — TILE レイアウト、オプトイン参加、録画をチャンネルに自動投稿

各ユースケースのドキュメントでは、エンドツーエンドのフロー、推奨する CallSettings、ロールベースの UI、検証チェックリストを取り上げています。ファミリーごとの -calls スキルに追加する形で適用し、アーキテクチャに関する作業を重複させないでください。

移行ガイド

既存のチャットへの通話追加や、既存のチャット導入環境をアップグレードするお客様向けに、ファミリーごとの通話スキルには次のドキュメントが含まれています。

• references/migration-v4-to-v5.md — Calls SDK v4 → v5（そのまま置き換え可能。v5 の API では、より細かなイベントリスナーとシンプルな初期化が利用できます）
• references/add-calls-to-existing-chat.md — 既存のチャット画面への追加統合（初期化の順序、ログインの順序、IncomingCall のマウント、サーバープッシュの設定）

適切なファミリーのドキュメントを参照してください。Web の参照ドキュメント（cometchat-react-calls）が migration-v4-to-v5 の正式な参照先です。他のファミリーの関連ドキュメントには、各ファミリー固有の差分のみが記載されています。

サーバー側プッシュテンプレート（Tier 3）

VoIP プッシュの設定はプラットフォーム固有です。ファミリーごとの references/ に、標準テンプレートが3つ用意されています。

• iOS APNs PushKit（.p8 トークン認証）— cometchat-ios-calls/references/server-apns-pushkit.md
• Android FCM HTTP v1（データのみ、優先度 HIGH）— cometchat-android-v5-calls/references/server-fcm-voip.md（V6版は Compose IncomingCallActivity を使用）
• Web Push VAPID（ブラウザーでの呼び出し音はベストエフォート）— cometchat-react-calls/references/server-web-push-vapid.md（Angular版もあります）

ハイブリッドプラットフォーム（RN、Flutter）には、Platform.OS / Platform.is{iOS,Android} に応じて適切な標準テンプレートに振り分ける references/server-push-bridge.md が用意されています。

このディスパッチャーの対象外

• 実際のコード。 各ファミリーの -calls スキルが統合を実装します。このディスパッチャーは振り分けを行います。
• AI-Agent または BYO-Agent のフロー。 まったく異なる領域のため、対象外です。トップレベルの cometchat ディスパッチャーのステップ3.0で、これらをドキュメントに振り分けます。
• 通話のモデレーション機能（同意を求める録音プロンプト、通話中チャットの不適切な言葉のフィルターなど）。チャットのディスパッチャーと同様、モデレーションはダッシュボードのみで行います。
• 通話分析ダッシュボード — CometChat ダッシュボードに表示されるため、統合作業は不要です。

チャットディスパッチャーへの案内

ユーザーが /cometchat-calls を直接実行したものの、プロジェクトにまだ統合がまったくなく（.cometchat/config.json もチャット画面もない）、誤って追加モードを選んだ場合は、案内してください。

「CometChat がまだ統合されていないようです。通話を中心としたアプリであれば問題ありません。スタンドアロンの通話フローを今すぐ実行します。チャットも併用したい場合は、まず /cometchat を実行してチャットを設定してから、戻って通話を追加してください。」

ここから cometchat/SKILL.md に自動的に振り分けないでください。どの機能を主軸にするかはユーザーが決めることです（言葉遊びではありません）。