顧客セグメンテーション AI

顧客セグメンテーション AIは、関連するテキストの解釈をモデルが支援しながら、定義した特性に従って顧客記録を分類します。まず機微情報を使わないセグメントルールを定め、提供された記録に適用し、曖昧な情報や不足がある顧客は未分類であることを明示します。

このガイドでは、確認済みの所属一覧と、整合性を確認したセグメント別件数を作成します。モデルは解釈を提案できますが、その解釈を受け入れるかどうかは、明文化したルールと元の記録に基づいて決まります。

執筆：Ai Flowi · 公開日 2026-10-11

設定例であり、テスト実施の記録ではありません
カタログに記載されていますが、Ai Flowiによる本番環境でのテストは行われていません

1. 業務に役立つ問いに沿ってセグメントを定める

オンボーディングの支援を求めた顧客は誰か、提供されたアカウント種別のうち異なるレビューチェックリストが必要なのはどれかなど、利用できる記録で答えられる問いを選びます。目的とする結果を具体化します。セグメントは、レビュープロセスや承認済みコンテンツの分類に対応する必要があります。明確な目的のない、特徴をまとめただけのグループでは、ワークフローを作る必要がない場合があります。

この例では、各記録に主となるセグメントを1つ割り当てます。複数のルールに一致する場合の優先順位を定め、どのルールにも当てはまらない場合や、必要な根拠が欠けている場合は未分類とします。方針として複数ラベルを付ける分類も選べますが、その件数は個別の顧客数ではなく所属数を表します。1つの報告書で両者の定義を混ぜてはいけません。

2. 利用が許可されたフィールドと定義を確定する

分類への利用が承認された顧客スナップショット、ワークスペース、安定した顧客識別子、バージョン管理されたルール一式を準備します。属性は、この目的のために提供された、関連性があり機微情報に当たらない業務情報に限定します。名前、文体、所在地から、保護対象の属性、個人の資産、私生活上の事情を推測してはいけません。

データセットに実在するフィールドを使って、すべてのセグメントを定義します。ルール識別子、認められる値、除外条件、根拠の要件を含めます。欠損値と否定の回答を区別できるようにします。自由記述の要望に基づくルールでは、該当する表現と、確信をもって分類するには曖昧すぎる表現を指定します。

顧客メモの解釈には、接続リファレンスに従って自分のプロバイダーアカウントとAPIキーを設定します。解釈処理の利用料金は、そのプロバイダーから別途請求されます。構造化フィールドに正確な分類がすでにあれば、通常のルールで割り当てられます。カタログで、この所属方針に選んだ入力を確認します。

3. 分類用の基準データセットを準備する

JSON検証の手順を使って、読み込んだ顧客スナップショットが所属を定める要件に合っているか確認します。

架空の排他的分類方針として、「設定の支援が必要」と「対象範囲の確認が必要」を定義し、対象範囲の確認を優先するとします。設定を依頼しつつ追加要件が含まれるか尋ねる顧客メモは、両方の目的に一致します。主な所属を「対象範囲の確認が必要」に割り当て、設定の依頼は補足情報として残し、優先ルールを記録します。単に挨拶だけが書かれた別の顧客は未分類のままとします。こうすれば、曖昧な文章を購買意向の根拠として扱わずに、業務量に関する問いに答えられます。

集計前に、顧客識別子の重複を解決します。同じ顧客の2行は、2人の顧客ではなく、別々の観測記録を表している可能性があります。整合性を取る方針を記録し、除外した行を例外一覧に残します。重複排除の処理で、たまたま最初に現れた観測記録を黙って選んではいけません。

ルールを適用する前にフィールド型を確認します。文字列のカテゴリと自由記述メモは、表では似て見えても意味が異なります。セグメント定義は取り込んだ記録と分け、想定外のルール識別子を拒否して、元データのフィールドによって方針が知らない間に再定義されないようにします。

4. モデルは曖昧なテキストにだけ使う

任意のメモ解釈処理は、準備した顧客一覧から始めます。Data → DataFrameがTableをaMapのsourceに渡します。所属案と根拠の列を、aMapの必須入力であるschemaの表エディターで定義します。設定済みのLanguage Modelが、aMapのmodel入力を通じて解釈を行います。顧客識別子は、提供する記録の一部として保持します。

instructionsで、提案をルールで使う語彙に限定し、裏付けとなる抜粋を要求し、根拠が不十分な場合は未解決と表示するようにします。append_to_input_columnsを有効にして元の列を保持します。提案を集計報告に含める前に、架空の所属事例で返されたフィールドと顧客の同一性を確認します。

モデルの提案は追加フィールドであり、元の顧客情報を置き換えるものではありません。レビュー担当者は、引用された根拠が提案されたルールを本当に裏付けるか確認しなければなりません。モデルが顧客識別子を書き換えたり行を落としたりした場合は、整合性確認を止め、集計前に対応付けを修正します。

5. 明示的なルールで所属を割り当てる

データだけを使う経路では、明文化したセグメントルールをJSON Operationsで適用します。支援を使う経路では、まずaMapが提案した解釈を確認し、受け入れた記録一覧を同じルール評価に渡します。適用したルールのバージョン、一致したルール識別子、最終セグメント、根拠の参照情報、未分類の理由を保持します。

Table Operationsでは、"Filter"または"Select Columns"で所属を表示できます。所属のTableをdfに渡します。column_nameでセグメントのフィールドを指定します。filter_operatorで所属の比較方法を選び、filter_valueに対象セグメントの値を入れます。こうした表示は割り当ての確認に役立ちますが、集約処理を提供するものではありません。

別途検証したJSON Operationsのクエリを使い、基準となるJSON所属一覧から件数を計算します。提案する手順では、受け入れた記録を最終セグメント別にまとめ、未分類も含めて各グループの件数を数えます。この排他的方針では、セグメント別件数の合計が、受け入れた一意の顧客数と一致しなければなりません。却下した重複記録や重複が未解決の記録は、その母数とは別に報告します。

6. 解釈できるセグメント報告を公開する

望ましい出力には、受け入れた各顧客の所属行と、母集団の定義を添えたセグメント別件数の概要が含まれます。ルールのバージョン、スナップショットの範囲、資料の参照情報、未分類の理由を加えます。報告では、説明のない予測としてセグメント名を提示するのではなく、所属の理由を説明する必要があります。

2つのルールに一致する記録、どれにも一致しない記録、必要な属性が欠けた記録、識別子が重複した記録、メモ内に指示が含まれる記録をテストします。優先順位が明示され、未分類が見えるままで、集計の整合性が保たれることを確認します。空のデータセットでは空の所属一覧を生成し、報告を埋めるために読者像を創作してはいけません。

ルールの改訂と顧客行動の変化を区別します。新しい優先方針で対象範囲の確認が主なセグメントになると、提供されたメモが変わっていなくても、顧客のセグメントは移動する場合があります。比較報告では、所属の移動を説明する前に、その方針変更を明示します。同様に、以前除外した記録を加えると母集団が変わります。改訂後の母数を照合し、以前のスナップショットを保持します。ルール、元データの収録範囲、顧客の根拠のうち何が変わったかを読者が判断できて初めて、セグメント別件数を解釈できます。

顧客セグメンテーションの制限と、分類が不要な場合は何ですか？

この提案は、新しい顧客の事実を発見したり、購入を予測したり、キャンペーンを配信したりするものではありません。明示された業務ルールと利用が許可された属性に従って分類するため、感情分類とは異なります。元のシステムに必要な分類がすでにある場合は、絞り込んだエクスポートだけで十分かもしれません。

セグメントへの所属は、その人に連絡する許可ではありません。見込み顧客の評価と見込み顧客の育成用下書きの準備は、それぞれ独自のレビュー基準を持つ別の判断として扱います。ルールや元データのフィールドが変わったら分類レビューをやり直します。古い所属件数が表すのは古いスナップショットです。

顧客の所属ルールと選択する入力

顧客セグメンテーション AI：選択するカタログ入力と設定値の案
部品	正確な入力名	準備する設定	出力ポート
Load CSV	csv_file	顧客スナップショットを取り込んでから、識別子の重複を照合します。	data_list
JSON Operations	data, operations, query	顧客の所属には、"JQ Expression"を使ってルールのバージョンを評価し、排他的なセグメント別件数の整合性を確認します。	data_output
Data → DataFrame	data_list	任意のテキスト解釈に向けて、受け入れた記録をTableとして準備します。	dataframe
aMap	source, schema, model, instructions, append_to_input_columns	セグメント案、元資料の抜粋、未解決の理由を追加し、確認のため元の列を残します。	states
Language Model	model, api_key	利用が許可されたモデルへのアクセスは、顧客メモの解釈にだけ提供します。	model_output
Table Operations	df, operation, column_name, filter_operator, filter_value	標準の集約処理があるとは述べず、所属を絞り込んだ表示を作成します。	output