ClaudeのAmplitudeコネクタで利用が落ちた契約を更新前に洗う
Amplitudeコネクタで契約(アカウント)単位の利用推移を引き、更新90日前の担当者メモにする手順です。Accountsアドオンの要否、ツール名の食い違い、読み取り専用に絞る権限設定までを扱います。
Amplitudeコネクタで契約ごとの利用推移を引き、更新の90日前に担当者へ渡すメモまで作る手順です。Amplitudeが持っているのは製品の利用データで、契約の更新日は持っていません。更新日は手元の台帳をClaudeに渡して突き合わせます。
この組み合わせでうまくいくかは、Amplitude側で契約を「グループ」として集計できるかどうかでほぼ決まります。先にそこを切り分け、そのうえでメモの作り方に進みます。
Amplitudeコネクタに頼める範囲と、頼めない範囲
コネクタページの説明は「Amplitudeのデータを検索・取得し、インサイトを得る」です。カテゴリはSales & marketing、サインインは必須で、ディレクトリへの追加は2025年11月です。
Amplitude側の説明では、チャート・ダッシュボード・ノートブック・実験・コホート・イベント・プロパティを自然言語で検索し、クエリできるとしています。セグメンテーション、ファネル、リテンションの臨時の分析も対象です。
更新前メモに使うのは、この読み取りの部分だけです。ツールの一覧に、契約や請求、更新日を扱うものはありません。
| 材料 | 出どころ | Claudeへの渡し方 |
|---|---|---|
| 契約ごとの利用の増減 | 出どころAmplitude | Claudeへの渡し方コネクタ経由で取得 |
| 更新日・契約金額・担当者 | 出どころ契約台帳やCRMの書き出し | Claudeへの渡し方CSVやExcelを会話に添付 |
| 利用低下の定義 | 出どころチームの取り決め | Claudeへの渡し方プロンプトに書く(後述) |
台帳からの更新日の拾い方は、保険の満期を扱ったClaudeで保険の満期管理の考え方がそのまま使えます。3か月前を90日前に読み替えるだけです。
接続する前に確認する条件
接続の手順自体は短く、Amplitude側のClaude向けガイドは約2分としています。ただ、後で効いてくる条件がいくつかあります。
Claudeに接続する流れ
- 1
コネクタのディレクトリを開く
Settings > Connectorsから「Browse」を選び、Amplitudeを検索します。「Anthropic verified」表示のコネクタです。
- 2
TeamとEnterpriseは先にオーナーが有効化する
Organization settingsでオーナーが有効にしたあと、メンバーが各自のAmplitudeアカウントで接続します。
- 3
OAuthで認可する
認可ページが回り続けて見えても、認証は完了しています。タブを閉じて構いません。
- 4
つながったか試す
「What Amplitude projects can I access?」と聞き、プロジェクトの一覧が返れば接続できています。
押さえておく条件は次の4つです。
- リージョン: ディレクトリのコネクタが向くのは米国サーバーです。データがEUにある場合は、接続前にAmplitudeの担当へ連絡するよう案内されています。コネクタページにはEU用のURLも載っていますが、ディレクトリ経由の接続は米国側という説明です
- 権限: 接続したユーザーの権限がそのまま引き継がれます。見られないプロジェクトは、Claudeにも見えません
- 管理者の設定: Amplitudeの組織設定(Settings > Content Access > MCP)で、MCPの利用を組織全体で止められます。個人が上書きすることはできません
- プラン: Amplitude側のガイドは、ディレクトリのコネクタはClaudeのすべてのプランに含まれると説明しています
契約単位で引けるか — ここが最初の分かれ目
Amplitudeは既定ではユーザー単位で集計します。契約(会社・アカウント)単位で見るには、Accountsアドオンを入れ、イベントやユーザーをグループに紐づけておく必要があります。
アドオンはPlus・Growth・Enterpriseの各プランで追加できる形で、Freeプランには含まれません。プロジェクトあたり5つまでのグループタイプを設定できます。
見落としやすいのは、グループの設定変更が新しいデータにだけ効く点です。過去のデータには遡って付与されません。今月アドオンを入れた場合、利用の「落ち」を比べられる過去の期間がまだ溜まっていないことがあります。
契約単位の利用低下を引けるかの切り分け
- QAccountsアドオンが入っていますか?答えがいいえのとき答えがはい
契約単位の集計はできません。ユーザー単位の増減で代用するか、契約の所属ユーザーの一覧を台帳側に持ち、ユーザーの動きを束ねる方法になります。後者は精度が落ちるので、メモに「ユーザー単位の推計」と明記します。
- Q契約を表すグループ(契約IDなど)がイベントに付いていますか?答えがいいえのとき答えがはい
アドオンがあっても、付与されたデータが無ければ引けません。付与の設計は開発側の作業です。
- Q比べたい期間より前から、グループが付いたデータがありますか?答えがいいえのとき答えがはい
溜まった期間の中で比べるしかありません。比較期間を短くし、メモにも「比較できた期間」を書きます。
契約単位で引けます
台帳の契約IDとAmplitudeのグループIDが対応していれば、次の手順に進めます。
ツール名はコネクタページとAmplitudeの説明で食い違う
コネクタページのツール一覧は get_charts、query_dataset、get_notebook などの14個です。一方、Amplitude側の説明には get_amplitude_charts、query_amplitude_data、use_amp_notebooks といった別の名前が載っています。
同じ操作に見えるのに名前が一致しないものが多く、どちらが現行の表記かは両方のページから判断できません。依頼文にツール名を書き込む運用は、名前が変わった時点で壊れます。
手順としては、ツール名を指定せずに「この契約の直近の利用を比較して」のように目的で頼みます。何を呼んだかを知りたいときは、実行後に「使ったツールとパラメータを一覧にして」と聞けば、その場の名前が分かります。
契約単位の問い合わせで主役になるのは、Amplitude側の説明では次のツールです。
get_amplitude_context: ユーザー、組織、アクセスできるプロジェクトを返す。プロジェクトIDを渡すと、タイムゾーンや通貨、セッションの定義、AI Contextも返るquery_amplitude_data: イベントのセグメンテーション、ファネル、リテンションなどの臨時クエリ。既存チャートをIDで呼ぶこともできるget_group_types: プロジェクトのグループタイプ(Company、Team、Accountなど)の一覧get_amp_user_data: ユーザーのプロファイル、プロパティ、活動の時系列
最初に get_group_types 相当のことを聞き、契約を表すグループタイプがあるかを確かめると、上の切り分けが1回で済みます。
手順 — 台帳と利用データを突き合わせ、更新が近い順にメモにする
ここからが本題です。会話の流れは次の5段で組みます。
更新90日前メモの作り方
- 1
台帳を渡す
契約ID、顧客名、更新日、担当者の列を持つCSVかExcelを添付します。契約IDはAmplitudeのグループIDと同じ表記に揃えておきます。
- 2
利用低下の定義を決める
「直近28日のアクティブな契約内ユーザー数が、その前の28日より3割以上減った」のように、数と期間で書きます。定義が曖昧だと、依頼のたびに基準が変わります。
- 3
更新まで180日以内の契約に絞る
全契約の利用を引くとクエリが重くなります。台帳の更新日で先に絞ってから、Amplitudeに問い合わせます。
- 4
利用の増減を契約ごとに取る
絞った契約について、定義した期間の利用を取得させます。取得できなかった契約は、行を落とさず「取得不可」と書かせます。
- 5
更新日が近い順に並べてメモにする
更新日の昇順に並べ、更新まで90日以内で利用が落ちた契約を先頭の枠に置きます。
次のような依頼文が出発点になります。数値やしきい値は、自社の契約形態に合わせて置き換えます。
添付の契約台帳(契約ID・顧客名・更新日・担当者)のうち、
更新日が今日から180日以内の契約だけを対象にしてください。
Amplitudeで、各契約IDに対応するグループについて、
直近28日と、その前の28日のアクティブユーザー数を比べてください。
減少率が30%以上のものを「利用低下」とします。
結果は更新日の昇順の表にし、列は
契約ID/顧客名/更新日/更新まで何日/担当者/前28日/直近28日/減少率
としてください。
Amplitudeで取得できなかった契約は行を残し、「取得不可」と書いてください。
数値はAmplitudeから取れたものだけを使い、原因の推測は別枠で
「仮説」と明記してください。結果を受け取ったら、同じ会話で担当者向けのメモに整えます。メモの型は次のようにします。
【契約名】更新日:YYYY-MM-DD(あと◯日) 担当:◯◯
事実:直近28日のアクティブユーザー数が前28日の◯人から◯人に減少(−◯%)
比較できた期間:◯月◯日〜◯月◯日
Amplitudeで確認できない点:契約の利用目的、担当者の入れ替わり、他製品への移行
仮説(未検証):◯◯
更新前に聞く質問:◯◯メモの「事実」と「仮説」を別の行に分けておくと、数字の裏付けがある部分と推測の部分を、受け取った担当者が見分けられます。Amplitudeの数字は利用の量しか語らないので、原因は顧客に聞くまで確定しません。
利用低下の定義はAI Contextに置くと揃えやすい
毎回の依頼文に定義を書く代わりに、Amplitudeの「AI Context」に置く方法があります。AI Contextは、組織とプロジェクトの単位でMarkdownのテキスト指示を登録する機能です。get_amplitude_context にプロジェクトIDを渡すと、その内容が返ります。セッションの最初に呼ばせておくと、指標の定義や用語がその後のクエリに反映されます。
注意点が1つあります。AI Controlsにアップロードしたファイルの中身は、MCP経由では返りません。定義はテキスト指示に書く必要があります。
テキスト指示の例は次のとおりです(Amplitudeの文書に載っている例ではなく、この用途向けに組んだ書き方です)。
## 契約単位の利用
- 「契約」はグループタイプ Account(キー:契約ID)を指す
- 「利用」は、契約内ユーザーの「主要操作」イベントの実行ユーザー数
- 「利用低下」は、直近28日が前28日より30%以上少ない状態
- 期間の境界はプロジェクトのタイムゾーンで数えるイベント名は自社のものに置き換えます。ここで決めた「主要操作」が、メモ全体の説得力を左右します。ログインのような軽いイベントを選ぶと、実際には使われていないのに低下が出にくくなります。
読み取りだけに絞って使う権限設計
この用途で必要なのは読み取りです。ところがAmplitudeのMCPには、チャート・ダッシュボード・実験・コホート・フラグの作成や、タクソノミーの削除といった書き込みのツールも含まれます。
権限はAmplitude側のロールで絞れます。「Use MCP (read)」と「Use MCP (write)」の2つのアクションがあり、プロジェクトごとに付け外しできます。既存のロールは、全ロールが読み取りを持ち、Member・Manager・Adminは書き込みも持つ状態が既定です。
CS部門向けには、読み取りだけを持つロールを作り、対象プロジェクトに割り当てる形が候補になります。ツールの一覧は見えたままで、権限のない呼び出しは実行時に失敗します。Admin権限のユーザーでも、ロールがアクションを許可していなければ失敗する、という説明です。
つまずきやすい点
- 大きな結果が切り詰められる: AIプラットフォーム側で大きなチャートが途中で切られることがあります。契約数が多いときは、更新日の範囲で分けて依頼します
- ダッシュボードのチャートの設定: ダッシュボード内のチャートを引くと、保存されたダッシュボードのフィルタでなく、チャートの既定設定が使われることがあります。ダッシュボードの数字と合わないときの疑いどころです
- トークン上限・タイムアウト: Amplitude側の案内は、新しい会話に切り替えるか、MCPクライアントのトークン上限を上げることです。契約数が多い依頼は、更新日の範囲で分けると上限に当たりにくくなります
- 複数組織へのログイン: OAuthの途中で複数のAmplitude組織にログインしていると、認証が不安定になることがあります。1組織だけにして接続し直します
- 契約IDの表記ゆれ: 台帳の「ABC商事」とAmplitudeのグループIDが一致しないと、取得不可の行が増えます。突合用の対応表を先に作っておくと安定します
近い用途の記事との違い
Amplitudeを週次のマーケティング指標に使う話はCowork Amplitude自動化の週次レポートにあります。CS側のヘルススコアから解約リスクの顧客を洗う流れはClaudeとGainsightの連携が扱っています。
ここで作るのは、その中間にあたる、利用データを更新日に結びつけたメモです。出来上がった一覧を毎朝の通知に載せたい場合は、Coworkで契約更新日をリマインドする手順に台帳を渡す形で続けられます。
まとめ
Amplitudeから引けるのは利用の量で、更新日も原因も別に用意するものです。最初に確かめるのは、契約がグループとして付いていて、比べられる期間が溜まっているかどうか。そこが揃っていれば、台帳を渡して180日以内に絞り、事実と仮説を分けたメモにするところまで、1つの会話で進められます。