ooligo
mcp-server

会話とディール risk の質問に答える Gong MCP サーバー

Difficulty
上級
Setup time
60min
For
revops · gtm-engineer · sales-enablement
RevOps

Stack

Gong のアカウントに対して、Claude に範囲を限定した読み取り専用アクセスを与える Model Context Protocol サーバーです。コールの検索、tracker の定義、コール単位の解析済みシグナル、rep ごとのインタラクション統計、そしてどのリスク tracker がどのコールで発火したかを、顧客が言ったのか自社の rep が言ったのかで分けて報告する派生ツールを提供します。scaffold はアーティファクトバンドル apps/web/public/artifacts/mcp-server-gong-revops/ にあり、README.mdpyproject.tomlsrc/gong_revops_mcp/server.py を同梱していて、pip install -e . でインストールできます。

まず API に「ない」ものから始めます。それが他のすべての形を決めるからです。Gong の公開 API には、ディールボードのデータを読み取るエンドポイントが存在しません。 CRM エンドポイント (GET /v2/crm/entities) が返すのは、登録済みの汎用 CRM 連携経由で事前にアップロードしたオブジェクトだけで、Gong 自身のドキュメントもこのエンドポイントを開発フェーズの検証用と位置づけています。つまり「Gong のディールについて Claude に聞ける」とうたうサーバーは、UI をラップしているか、代わりに CRM を読んでいるか、推測しているかのいずれかです。本サーバーはディールの risk を会話から導出し、そのことを明示します。deal_risk_digest は tracker のヒットを返し、stage・金額・クローズ日については call_id を CRM に join せよという注記を添えます。

使うべきとき

RevOps の定例的な質問が、人間のクリック作業 10 分を消費している場合に使ってください。先週どのアカウントが価格に難色を示したか、どのコールで競合の名前が出たか、伸び悩んでいるセグメントの rep が一方的に話し続けていないか。これらはいずれも Gong 自身のデータ内での join であり、UI では目視でやらされる作業です。効果が大きいのは 2 つのロールです。週次の pipeline review を回す RevOps リードは自然言語で尋ね、構造化された答えをそのまま資料に貼れます。新しい質問が来るたびに /v2/calls/extensive に対する使い捨てスクリプトを書いていた GTM engineer は、contentSelector、カーソルページネーション、rate limiter、話者の帰属付けがすでに配線された状態から始められます。

すでに Salesforce RevOps MCP サーバーClari のもの を動かしていて、会話レイヤーを同じチャット面に置きたい場合にも適したパターンです。「顧客は何と言ったか」から「それはどの stage か」へ、タブを切り替えずに横断できます。この横断が本当の利点で、どちらのシステムも単独では答えられません。

使うべきでないとき

  • Gong は公式 MCP サーバーをすでに提供しています。 Gong は 2026 年に MCP 対応を発表し、Gong 自身がホストする MCP サーバーをドキュメント化しています。どの Gong プランでも利用でき、テクニカル管理者が設定し、アクセスはシート階層で制御されます。Claude・ChatGPT・Microsoft Copilot からアカウントやディールについて質問し、Gong の AI が生成したインサイトを取得できます。まずそちらを試してください。 ファーストパーティで、ホストするプロセスが不要で、Gong のシート階層の権限を尊重します。本 scaffold はそれをしません。自己ホスト版を作るのは、固定された監査可能なツール面が必要なとき — 自分で管理する contentSelector、文字起こしの kill-switch、ページ上限、話者帰属付きの tracker 出力 — あるいは管理者がホスト版を有効化してくれないときです。
  • API キーを発行してくれる管理者がいない。 認証情報は Company Settings → Ecosystem → API から取得し、作成できるのはテクニカル管理者だけです。ユーザー単位のキーはありません。
  • ユーザー単位のコール可視性が重要である。 アカウントレベルのキー 1 本で、対象ワークスペース内のすべてのコールが見えます。誰がチャットしているかは関係ありません。誰が誰のコールを聴けるかを Gong 側で制限しているなら、本サーバーはそれを迂回します。アナリストごとに狭いスコープのキーで動かすか、動かさないでください。
  • 文字起こしをデフォルトでモデルに渡したい。 ここではオフであり、それが正しいという前提で設計しています。文字起こし前提のワークフローなら、scaffold と戦うことになります。
  • 質問が月に 1〜2 件しかない。 Gong の UI のフィルターのほうが、保守が必要なセットアップより速いです。

公開しているもの

読み取り 6 ツール、書き込みは 0 です。公開 API の書き込み面はコールのアップロードと汎用 CRM オブジェクトのアップロードで、どちらもチャットプロンプトの背後に置くべきものではありません。読み取り専用にすれば「モデルが誤読して記録システムを変更した」という障害クラスがまるごと消えます。

  • find_callsGET /v2/calls。メタデータのみ (id、タイトル、開始、長さ、方向、Gong の URL)。まずここで質問の範囲を絞ります。
  • list_trackersGET /v2/settings/trackers。tracker の定義のみです。このエンドポイントは一致件数を返さず、そこで驚く人が多いところです。発生回数は extensive のコールエンドポイントから取得します。
  • call_signalsPOST /v2/calls/extensive。主力ツールです。参加者、tracker の一致、tracker の発生箇所、Spotlight の brief、key points、自動判定のコール結果、トピック、発話時間、人物ごとのインタラクション統計、公開コメント。
  • call_transcriptPOST /v2/calls/transcriptGONG_ALLOW_TRANSCRIPTS=true でない限りオフ、3 コールが上限、理由の記述が必須です。
  • rep_interaction_statsPOST /v2/stats/interaction。最長モノローグ、最長の顧客ストーリー、インタラクティビティ、忍耐、質問率。
  • deal_risk_digest — 派生ツール。日付範囲にわたって tracker の定義と発生箇所を join し、各ヒットを customerinternalunattributed に分類します。

エンジニアリングの立場

話者の帰属付けが digest の存在意義そのものです。「Pricing Pushback」を自社の rep が言ったなら、それは rep の行動シグナルです。顧客が言ったなら、ディールのシグナルです。両者を合算した tracker 件数は間違った理由で動き、誰も行動に移せない risk 数値を生みます。deal_risk_digestcontent.trackerOccurrences を読み、各 speakerId をそのコールの parties 配列で引き当て、パーティの所属で分けます。だからこのサーバーは件数だけでなく発生箇所を要求します。そして、汎用的な Gong ラッパーが代わりにやってはくれない唯一の点でもあります。

メディアは一切要求しません。 server.pycontentSelector は固定で、呼び出し側から変更できず、media を含みません。キーは api:calls:read:media-url を保持していません。したがって Gong の 8 時間有効な署名付き音声/動画リンクを生成することがありません。登場した会話より長生きするリンクは、スクリーンショットを待っている漏洩です。

文字起こしは kill-switch であり、プロンプトではありません。 call_transcript は実行前に環境変数を確認し、3 コールを上限とします。理由の文字列だけを信頼する設計では、顧客の逐語発話がコンテキストウィンドウから「自信を持った誤読 1 回」の距離にあります。フラグにすることで、「そもそも許可するのか」がデプロイ時の判断になり、質問ごとの判断ではなくなります。

ページネーションには上限があり、その上限が報告されます。 GONG_MAX_PAGES は既定 5 なので、1 回のツール呼び出しで読むのは最大 500 レコードで、早期に停止した場合は truncated: true を返します。データの半分だけを黙って見たモデルは、間違った質問に自信を持って答えます。

リクエストは直列化し、リトライしません。 Gong は既定で 1 秒あたり 3 リクエスト、1 日あたり 10,000 リクエストに制限し、超えると Retry-After ヘッダー付きで 429 を返します。scaffold は並列に投げて 429 に反応するのではなく、リクエスト間に 0.34 秒待ちます。リアクティブなリトライの嵐は、どうせ失敗するリクエストに 1 日分のクォータを使ってしまうからです。

コストの実際

3 つの費目と、費目ではないもの 1 つです。

  • Claude のサブスクリプション。 すでに払っている分です (Pro は $20/ユーザー/月、Max は $100〜200/ユーザー/月、または API 従量)。このサーバーで変わりません。
  • 自己ホスト。 Claude Desktop ユーザーごとのローカル Python プロセスなら、インフラコストはゼロです。共有サービスにするなら、どのクラウドでも小さな VM で月 $20〜50 程度です。
  • Gong API のクォータ。 Gong 契約に含まれ、ドルでは課金されませんが有限です。既定で 1 社あたり 1 秒 3 リクエスト、1 日 10,000 リクエストで、Gong サポートに連絡すれば引き上げられます。ここは見積もってください。コール 4,000 件のワークスペースで 90 日分の deal_risk_digest を回すと、100 件 × 40 ページ = 40 リクエストです。この種の質問を 1 日 10 件でも 400 リクエストで、上限には余裕があります。予算を壊すのは上限のないカーソルループで、それを防ぐために GONG_MAX_PAGES が存在します。
  • Gong のシート。 Gong は定価を公表しておらず、プラットフォーム費用を伴うシート単位の見積もりです。支払額はこのサーバーで変わりません。シートを増やさないからです。

トークンコストはレスポンスのペイロードで決まるため、server.py は返す前にすべてのレスポンスを削ぎ落とします。call_signals を 20 コールに対して実行すると、全文ではなく brief と key points が返り、数万トークンの下限あたりに収まります。45 分のコール 1 件の call_transcript はそれ単体で同程度で、これが文字起こしをオフのままにする実質的な論拠です。

代替案との比較

  • Gong 公式の MCP サーバー。 上述のとおり、まずこれを試してください。ファーストパーティ、どのプランでも利用可、シート階層の権限、ホスト不要です。自己ホストの scaffold を選ぶのは、1 ファイルで読めてバージョンを固定できるツール面が必要なとき、あるいはホスト版が自社で有効化されていないときです。
  • コミュニティ製の Gong MCP サーバー。 GitHub や MCP ディレクトリに複数あり、多くはコールと文字起こしをラップしています。この scaffold を読むよりインストールは速いです。引き換えに、「コールと文字起こしをラップ」はたいてい文字起こしが既定でオン、ページ上限なし、話者帰属なしの tracker 件数を意味します。本 scaffold が意図的に別の判断をしている 3 点です。
  • /v2/calls/extensive に対する使い捨てスクリプト。 制御は最大ですが、Basic 認証、アカウント固有のベース URL、カーソルページネーション、rate limiter、parties との join を毎回手で作り直します。この scaffold は約 450 行で、そのすべてが配線済みです。
  • Gong 自身の UI と Spotlight。 単一コールならこちらが速く、データもそこにあります。ただし Gong のデータを Claude の他のコンテキストと join できません。そもそもこれらを動かす理由はその 1 点です。MCP サーバーと Skill のどちらが自分の課題に合う形か迷っている場合は、Claude Skill と MCP サーバーの比較 を読んでください。

注意点

README には 7 件すべてを記載しています。重要な 5 件は次のとおりです。

  • ベース URL を間違えると 404 ではなく 401 が返ります。 Gong の API ベース URL はアカウント固有で、https://api.gong.io はよくある既定値にすぎず、普遍的ではありません。問題のない認証情報のデバッグに午後をまるごと失うチームがあります。ガード: _raise_for_gong が 401 を捕まえ、実際に使ったベース URL を明示し、認証情報より前にベース URL の不一致を第一の原因として挙げます。
  • tracker のリネームは「良い知らせ」に見えます。 deal_risk_digest は tracker 名を完全一致で照合するため、Gong 側でリネームされると一致しなくなり、digest は risk ゼロと報告します。ガード: 部分的です。まず list_trackers を実行し、実際の名前を GONG_RISK_TRACKERS に貼ってください。同梱の既定値はプレースホルダーで、たいていのワークスペースでは何にも一致しません。設定した名前が実在の tracker に一致しないときに警告を出すのは README の TODO #3 です。
  • インタラクション統計はコール本数の少なさを罰します。 Gong の統計は Whisper が有効なコールからのみ導出されるため、録音が 3 件しかない rep は、本当に問題のある rep と統計的に区別できません。ガード: rep_interaction_stats はこの注意書きを毎回のレスポンスに含めて返すので、モデルがノイズを元にコーチングする代わりにその注意書きを繰り返します。マネージャーに数字を見せる前に find_calls の件数を突き合わせてください。
  • 黙って切り詰められる。 ページ上限で停止したカーソルループは、完全な回答と見分けがつきません。ガード: ページネーションするツールはすべて、早期停止時に truncated: true を返します。高価な質問をする前に件数を確認する安価な手段が find_calls です。
  • 同意のずれ。 録音に同意した顧客が、それによって第三者のモデルに要約されることに同意したわけではありません。ガード: 文字起こしは既定でオフ、メディア URL は生成しません。GONG_ALLOW_TRANSCRIPTS を切り替える前に DPA を確認してください。

スタック

  • Gong — conversation intelligence、tracker、Spotlight の brief、インタラクション統計
  • MCP Python SDKmcp>=1.2.0Serverstdio_server、ツールレジストリのデコレーターを提供します
  • httpx — 自社アカウントの Gong API ホストに対する非同期 REST クライアント。base64("key:secret") による Basic 認証
  • Claude Desktop または Claude Code — 自然言語インターフェースとツール呼び出し元
  • GONG_ALLOW_TRANSCRIPTS — 顧客の逐語発話がモデルに届くかどうかを決める環境レベルのロック
  • GONG_MAX_PAGES — クォータのガードであり、回答が不完全であることをモデルに可視化する仕組み

Files in this artifact

Download all (.zip)