1. イントロ：AI分析の「新しい視点」 —— 予測から構造学習へ

「AIで解約予兆を予測する」「チャーンレート（解約率）を下げるためにAIを活用する」

こうした言葉が飛び交う中、多くのチームがAIによる「未来の予測（Prediction）」に大きな期待を寄せています。
しかし、高価なCRM（顧客管理システム）や専門のAIツールを導入しなければ、それは実現困難な「遠い未来の話」だと感じてはいないでしょうか。

ですが、本当に価値のあるデータは、未来ではなく「確定した過去」にあります。

顧客が「更新します」と連絡をくれたGmail。
あるいは「今月で解約します」と伝えられたGoogle ドキュメント上の議事録メモ。

これらは実は単なる結果報告ではありません。
AIの視点から見れば、顧客との関係性が「なぜ継続し、なぜ途絶えたのか」を示す、もっとも生々しく、価値のある「関係学習データ」です。

本記事の目的は、AIを使って「なぜ解約されたか」という原因（Reason）を必死に探ることではありません。

重要なのは、「なぜあの顧客は契約を更新してくれたのか」というポジティブなデータと、解約データとをAIで比較分析し、その差分（Difference）を明らかにすることにあります。

AIの本当の役割は、「未来の予測」や「犯人探し（原因特定）」ではなく、顧客との関係性を維持・発展させるための「構造（Structure）」そのものを学習することにあります。

本記事では、専用ツールを一切使わず、多くの方々にとって日々の業務基盤であるGoogle Workspace（Gmail, ドキュメント, Forms, スプレッドシート）とGeminiだけを使い、「確定した過去」のログから「関係維持の構造」を読み解き、次の改善アクションに繋げる実践的な手法を解説します。

2. あなたの「解約ログ」はどこにあるか？

さて、AIで「関係学習データ」を分析するといっても、多くのチームにとって最初の壁は「分析すべきデータが、そもそも存在しない（あるいは、どこにあるか分からない）」ことです。

高価なCRMやMAツールを導入していれば、顧客の行動ログやステータスは一元管理されているかもしれません。
しかし、本記事の前提は「Google Workspaceだけで戦う」チームです。

その場合、貴重な「更新」や「解約」のログは、どこにあるでしょうか？

• 顧客から直接届いたGmailの受信トレイ
• 営業担当者が走り書きしたGoogle ドキュメントの議事録
• CS担当者が個別にメモしているスプレッドシートの（属人化された）管理表

データは「専用フォーム」に綺麗に蓄積されているのではなく、日々の業務の中に「テキスト」として散在しているのです。

一見、これらは分析しようのない、ただの「非構造データ」に見えます。
しかし、これこそがAI分析のスタートラインとなる「原石」です。

重要なのは、これらの散在した情報を「AIが読める形」に集約し、構造化すること。
次のセクションから、その具体的なステップを見ていきましょう。

3. Geminiが読み解く「関係維持の4階層」

Gmailの本文やドキュメントの議事録（非構造データ）を、AIが分析可能な形（構造化データ）にする。
そのために、本記事では「関係維持の4階層」というシンプルな分析フレームワークを提案します。

AI、特にGeminiは、単なるテキストを以下の4つの要素（タグ）に分解して読み解くことを得意としています。

1. Emotion（感情）

顧客が更新・解約に至った背景にある「感情」です。

• タグ例:[満足], [不満], [期待], [無関心], [感謝]
• 分析例:「解約グループは[不満]だけでなく、[無関心]の割合も高い」

2. Reason（要因）

感情を引き起こした具体的な「理由」です。

• タグ例:[価格:高い], [機能:不足], [サポート:満足], [成果:出た], [担当者:変更]
• 分析例:「更新グループは[サポート:満足]が突出して多い」

3. Timeline（時系列・頻度）

いつ、どのタイミングで、どれくらいの頻度で接点があったか。

• タグ例:[接点:月1回], [接点:なし], [導入支援:あり], [契約:3年目]
• 分析例:「解約グループは[接点:なし]が半数を占める」

4. Org（組織・担当者）

誰が（顧客側・自社側）関係していたか。

• タグ例:[顧客担当:A氏], [自社CS:佐藤], [決裁者:部長]
• 分析例:「[自社CS:佐藤]が担当した顧客の更新率は高い」

重要なのは、このフレームワークが「解約ログ（例：価格への不満、接点なし）」だけでなく、「更新ログ（例：手厚いサポート、定例会の実施）」の分析にも全く同じように適用可能であるという点です。

競合他社やAIツールの多くが「解約理由（Reason）」という点の分析に終始する中、この4階層でログを捉え直すことで、顧客との関係性を構造として理解する準備が整います。

4. CRM不要！「Gmail」から始めるログ構造化テンプレート

セクション2で「ログはGmailやドキュメントに散在している」と述べ、セクション3で「4階層のフレームワーク」を提示しました。

ここで、多くの方がこう考えるかもしれません。
「散在しているのは分かった。しかし、過去の膨大なメールや議事録を探し出し、整理するのは現実的ではない…」

ご安心ください。
AI分析は、過去のログ全てを完璧に集めることから始める必要はありません。

重要なのは、

1. まず、AIが読み込める「データベースの箱」を作ること。
2. そして「今日（あるいは今週）発生した1件のログ」から入力を始めること。
   です。

過去の膨大なデータは後回しでも構いません。
「これから発生するログ」を確実に蓄積する仕組みを作ることが、AI活用の第一歩です。

このセクションでは、CRM不要、Gmailのコピペから始める「ログ構造化テンプレート」を、3つのシンプルなステップで解説します。

ステップ1：【箱づくり】 社内入力用の「Google Forms」を作成する

まず、AI分析の「箱」となるGoogle Formsを作成します。

⚠️ 注意点

これは顧客に送るアンケートではありません。
Gmailやドキュメントに散在するログを、社内の営業・CS担当者が「コピペ入力」するためのデータベースです。

セクション3の「4階層」を意識し、以下のような項目を設定します。

📌 フォーム作成例：顧客関係ログ（更新・解約）データベース

1. **顧客名:**[記述式]
2. **ステータス:**[選択式]（ `更新`, `解約` ）
3. **ログ本文（コピペ欄）:**[段落]
  - ※Gmailの本文、ドキュメントのメモなどをそのまま貼り付ける場所
4. **発生日:**[日付]
5. **自社担当者（Org）:**[選択式]（ `佐藤`, `鈴木`, `高橋` ）
6. **（任意）所感メモ:**[記述式]
  - ※担当者が感じたこと（Emotion）や背景（Reason）を補足

ポイントは、担当者の負担を最小限にすることです。
詳細なタグ付け（Emotion, Reason）は、次のステップでGeminiに任せます。
担当者は「顧客名」「ステータス」「本文コピペ」を埋めるだけで良いという簡潔なルールにしましょう。

ステップ2：【入力】 GmailからFormsへ「コピペ」する運用ルール

次に、このFormsをチームで運用します。

「顧客から更新・解約の連絡（あるいはそれに準ずるメモ）が発生したら、必ずステップ1のFormsに入力（コピペ）する」

このシンプルなルールを徹底するだけです。
Formsの回答先を「新しいスプレッドシートを作成」に設定すれば、自動的にGoogle スプレッドシートにデータが蓄積され始めます。

ステップ3：【自動化】 Gemini in Sheetsで「自動タグ付け」

ここからが本題です。
ステップ2で作成されたスプレッドシートを開くと、以下のようになっているはずです。

この「ログ本文（D列）」という非構造データを、Geminiを使って「4階層」のタグに自動で構造化します。

新しい列（G列、H列）を追加し、=GEMINI() 関数（またはGeminiサイドバー）を使って、以下のようなプロンプト（指示）を実行します。

📌 G列（Emotionタグ）のセルに入力する関数例

=GEMINI("セルD2のテキストから、顧客の感情として最も近いものを[満足, 不満, 期待, 無関心, 感謝]から1つだけ選んでください。")

📌 H列（Reasonタグ）のセルに入力する関数例

=GEMINI("セルD2のテキストから、主な要因を[価格, 機能, サポート, 成果, 担当者]から1つ選び、[高い, 不足, 満足, 出た, 変更]などの状態と組み合わせて「項目:内容」形式で答えてください。例：価格:高い")

この関数を下の行にオートフィル（コピー）するだけで、Geminiが全ての「ログ本文」を読み解き、自動で「Emotionタグ」と「Reasonタグ」を付与していきます。
※Timeline, OrgはForms入力時点である程度構造化されています。

これで、高価なCRMがなくても、Gmailのコピペから始まったデータが、AI分析可能な「構造化データベース」へと変換されました。

5. Geminiによる「差分」の発見と「知識化」

セクション4で、Gmailのコピペから始まった非構造データが、AI（Gemini）によって分析可能な「構造化データベース（スプレッドシート）」に変わりました。

しかし、分析のゴールはレポートを作ることではありません。
その分析結果から「再現可能な知見」を抽出し、組織の「知識」へと昇華させることです。

ここが本記事の核となります。
このセクションでは、スプレッドシートに蓄積されたデータを「差分分析」し、それをGoogle ドキュメントで「知識化」する2つのステップを解説します。

ステップ1：【差分分析】 Geminiサイドバーで「更新」と「解約」を比較する

=GEMINI()関数が行ごとの「タグ付け（構造化）」を得意とするのに対し、データ全体の「傾向分析」はGemini in スプレッドシート（サイドバー）の独壇場です。

スプレッドシートのサイドバーでGeminiを起動し、作成したデータベース全体（あるいは分析したい範囲）を選択した状態で、以下のようなプロンプトを投げかけます。

ここでの目的は、「更新グループ」と「解約グループ」の決定的な差分を発見することです。

📌 プロンプト例1：更新と解約の「差分」を発見する

「'ステータス'列が'更新'のグループ」と「'ステータス'列が'解約'のグループ」

上記2つのグループで、'Reasonタグ'列（H列）の出現頻度をそれぞれ比較し、もっとも差が大きい要因トップ3を教えてください。

📌 プロンプト例2：成功パターン（更新）の共通項を探る

「'ステータス'列が'更新'のグループ」に共通して出現する、'Emotionタグ'（G列）と'Reasonタグ'（H列）の「最も多い組み合わせ」を教えてください。

Geminiは、「解約グループはReason:価格:高いが40%を占めるのに対し、更新グループはReason:サポート:満足が55%を占める」といった明確な「差分」や「共通項（パターン）」を提示してくれます。
これが「知見のタネ」です。

ステップ2：【知識化】 Gemini in Docsで「CSプレイブック」に構造化する

ステップ1で得た「知見のタネ（＝Geminiの分析結果）」を、スプレッドシート上に放置してはいけません。
チーム全員がいつでも参照できる「知識」として定着させます。

ここで Google ドキュメントの出番です。

1. スプレッドシートのGeminiサイドバーから、得られた分析結果（例：「更新顧客はサポート満足度が鍵」）をコピーします。
2. Google ドキュメントで新規ドキュメント（例：『CSチーム・成功パターン集』）を開きます。
3. Gemini in Docs（サイドバーまたは @gemini）を起動し、コピーした分析結果を貼り付け、以下のように指示します。

📌 プロンプト例：分析結果を「知見（プレイブック）」に構造化する

以下の分析結果（ファインディング）に基づき、私（CS担当者）が明日から使える『再現可能な成功パターン』として、[顧客の状況][推奨アクション][期待される結果] の3項目でまとめてください。

## [ここにスプレッドシートで得た分析結果を貼り付け]
例：
・分析結果：更新顧客の55%が「Reason:サポート:満足」のタグを持つ
・分析結果：解約顧客の40%が「Timeline:接点:なし」のタグを持つ

Geminiは、単なる分析結果を、チームの行動指針（プレイブック）へと再構成してくれます。

📌 Geminiによる「知識化」の出力例

[顧客の状況]

• 契約更新が近いが、最近接点が持てていない（Timeline:接点:なし）顧客

[推奨アクション]

• 「最近お困りごとはありませんか？」という能動的なサポート連絡を入れる。
• 過去の（あるいはB社の）成功事例を共有し、活用を促す。

[期待される結果]

• 顧客のEmotion:満足を引き出し、Reason:サポート:満足というタグが付与されるような関係性を構築し、契約更新に繋げる。

これで、Gmailのコピペから始まったログが、分析（過去）を超え、チームの具体的なアクション（未来）を導く「知識」へと変わりました。

6. 改善サイクルへの還元 —— 構造学習から未来の行動へ

セクション5で、Gmailのコピペから始まったログが、分析され、チームの「知識（CSプレイブック）」へと昇華しました。

しかし、Google ドキュメントにどれほど素晴らしいプレイブックが蓄積されても、それが読まれず、未来の行動に反映されなければ、分析は自己満足で終わってしまいます。

このセクションは、AI分析サイクルの最終ステップです。
「過去」の分析を、「現在」の顧客への具体的なアクションに繋げ、改善サイクルを回します。

「成功の鍵」を、他の顧客に横展開する

セクション5の分析で、私たちは以下のような「知見のタネ」を得ました。

• 成功の鍵（更新要因）: Reason:サポート:満足
• 失敗の鍵（解約要因）: Timeline:接点:なし

この「知識」を、まだ解約も更新もしていない「現在契約中の顧客」に活かしてこそ、AI分析の価値が最大化されます。
これを「知見の横展開」と呼びます。

📌 具体的なアクションプラン

1. （もし存在するなら）既存の顧客リスト（スプレッドシート）を開きます。
2. そのリストに「最終接点日」や「CS担当者」の列があるか確認します。（なければ、この機会に最低限の情報を整備します）
3. セクション5で得た「失敗の鍵（Timeline:接点:なし）」に基づき、顧客リストにフィルターをかけます。

• 例：「最終接点日から3ヶ月以上経過している顧客」を抽出

1. 抽出された「（解約予備軍かもしれない）顧客リスト」に対し、セクション5で作成したCSプレイブック（推奨アクション）を実行します。

• 例：「最近お困りごとはありませんか？」という能動的なサポート連絡を入れる。

これが、本記事が提唱する「構造学習」のゴールです。

高価なAIツールで「解約確率90%」といった予測に怯えるのではありません。
私たちが日々蓄積した「ログ（過去）」から学んだ構造（例：接点がない顧客は離れやすい）に基づき、未来の行動（例：接点がない顧客に連絡する）を変えるのです。

「構造」を学び、行動を改善し続けること。
それこそが、ツールに頼らずとも実現できる、もっとも効果的でローコストな「解約抑止」であり「LTV（顧客生涯価値）向上」に繋がる道筋です。

7. まとめ：「解約もまた学習ログ」 —— AIと共に構造を更新する時代へ

本記事では、高価なCRMや専門ツールを一切使わず、Google Workspace（Gmail、Forms、スプレッドシート、ドキュメント）とGeminiだけで「契約更新・解約ログ」を分析する実践的な手法を解説しました。

多くのAI分析が「未来の予測」を目指す中、私たちが焦点を当てたのは「確定した過去」です。

「解約」というネガティブに見える結果も、「更新」というポジティブな結果も、AIの視点から見れば等しく「顧客との関係学習データ」です。

そのログがGmailの受信トレイに散在していても構いません。
まず社内用の「Google Forms」という箱を作り、1件のコピペから始める。
=GEMINI()関数が、その「非構造テキスト」を「4階層のタグ」へと自動で構造化してくれます。

そしてもっとも重要なのは、Geminiサイドバーで「更新」と「解約」の差分を発見し、それをGoogle ドキュメントに「CSプレイブック（知識）」として蓄積・更新することです。

「解約ログ」は、顧客との関係の終わりを示すものではなく、次の顧客との関係をより良くするための始まりのデータです。
AIと共に顧客関係の「構造」を学び、更新し続ける。その第一歩を、今日のGmailから踏み出してみませんか。

💬 最終チェック

以下のチェックリストを、あなたの「顧客ログ分析」の仕組みづくりの起点として確認してみてください。

• ☐ Gmailやドキュメントに散在するログを、Google Formsという「社内用の箱」に集約する運用ルールができているか？
• ☐ 蓄積するログを、Emotion/Reason/Timeline/Org の「4階層」で構造化する視点（スプレッドシートの列）が用意できているか？
• ☐ スプレッドシート上で、Geminiを使い「更新」と「解約」の差分分析を行えているか？
• ☐ 分析結果を、Google ドキュメントに「CSプレイブック（再現可能な知識）」として蓄積・更新できているか？

これらが整えば、あなたのチームはすでに「AIと共に顧客関係の構造を更新し続ける組織」へと進化しています。

🧩 3秒まとめ