営業パイプライン分析

営業パイプライン分析は、商談ステージ、活動日、担当者、次のアクションを調べ、対応が必要なレコードを特定します。一貫したエクスポートと明示的な確認ルールを使い、データから事実に基づく所見を計算してから、元の商談に結び付いた説明を加えます。

この例では、提供されたレコードから根拠に結び付いたパイプラインの確認結果を作成します。活動の停滞と担当者の欠落を示しますが、売上予測やCRMとの同期は行いません。

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

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

1. 確認する問いとスナップショットを選ぶ

レポートでチームの何を支援するかを決めます。担当者のいない商談の割り当て、古い次のアクションの確認、レコードが同じステージに残る理由の調査などです。各問いを、利用可能なフィールドに対する確認として記述します。パイプラインの問題に見えても、エクスポートが不完全なだけかもしれません。日付の欠落と、実際に確認期間の外にある日付を区別してください。

分析のスナップショット日とタイムゾーンを明示して固定します。モデルが想定する現在日付で非活動期間を計算しないでください。未完了商談のみか全商談かなど、エクスポートの対象範囲を記録し、レポートでも保持します。スナップショット間の比較は、対象集合とフィールドの定義が一致する場合にのみ意味を持ちます。

2. エクスポートの要件を準備する

認可されたCSVエクスポート、ワークスペース、合意済みのパイプライン確認方針が必要です。有用な列には、商談識別子、ステージ、ステージへの移行日、最終連絡日、担当者、次のアクションがあります。アクションの期限は、元システムが提供する場合にのみ含めます。先頭のゼロや大文字・小文字が失われないよう、商談識別子をテキストとして保持します。

日付形式と、各活動タイムスタンプの意味を文書化します。メモの編集が、そのまま顧客との連絡を意味するわけではありません。ステージ移行日が空なら、そのステージの滞在期間は確定できません。タイムゾーンのない最終連絡日は、比較前に確認が必要です。正規化した確認用フィールドとともに元フィールドを保持します。

説明文を追加するためのモデル提供者へのアクセスは任意です。使う場合は、ご自身の提供者のアカウントとAPIキーを用意し、料金を別途支払います。データだけのレポートはモデルの前で終了できます。CSVの取り込みが検証も行うと想定せず、フィールド仕様は既存の Load CSVリファレンスに従ってください。

3. レコードを読み込み、データ品質の不足を分離する

選択したエクスポート入力には、 CSV読み込みの手順に従い、生成された商談レコードを確認します。

合成データによるパイプライン確認で、商談Aの最終連絡日は古いものの、合意済みの今後の確認が次のアクションに記録されているとします。商談Bには最終連絡日も担当者もありません。Aは連絡が古い商談の一覧に含められますが、関係が悪化したと主張する根拠にはなりません。予定された確認は営業担当者に状況を示します。Bはデータ不足と担当者の確認用一覧に含め、非活動期間は未解決のままにします。両方を一つの緊急商談件数にまとめると、観測された経過時間と根拠の欠落の違いが失われます。

そのJSONをJSON Operationsのdataに接続します。 "JQ Expression" を選択し、 query で利用できない行構造を拒否し、識別子を保持し、必須フィールドの欠落を業務上の所見と分けて分類します。エクスポートの形式に対して日付の解析と比較をテストしてください。このページは万能な日付パーサーを提供するものではありません。

活動停滞の確認にはチームが選んだしきい値を使い、レポートにその定義を含めます。最終連絡日がないレコードは、日付不明のグループに入れます。確認対象から除外するステージがあれば理由を示します。活動の古さ、期限超過のアクション、データ不足を、一つの限定条件のない「停滞」ラベルに混ぜないでください。

4. 再現可能な確認用の表を作る

得られたレコード一覧をData → DataFrameのdata_listに渡します。Table出力はTable Operationsのdfに渡せます。担当者のいない商談の一覧では、 "Filter" を operationで選び、 column_name を検証済みの担当者有無フラグに設定します。 filter_operator と filter_value は、そのフラグの実際の表現に合わせて設定します。

次のアクションの一覧では、別のTable Operations段階で "Sort"、選択した column_name 、 ascendingを使います。日付不明の行は別の例外一覧に残します。カタログにはフィルタリングと並べ替えがありますが、グループ化や集約の操作は記載されていません。このコンポーネントがステージごとの合計を計算すると説明しないでください。

件数は確認済みのJSON Operationsクエリで計算し、承認済み入力の対象集合と照合します。顧客の重複排除を明示的に定義して確認していない限り、ユニーク顧客数ではなくレコード数を数えます。確認担当者が元レコードに戻れるよう、フィルター結果には各元商談の識別子を保持します。

5. 必要に応じて根拠の範囲内の説明を加える

表からテキストへの整形リファレンスには、商談識別子、フラグの理由、元の日付を含むレポートの概要用のParser仕様が示されています。

Structured Outputのoutput_schema を、所見、対象識別子、引用フィールド、不足情報、提案する質問で設定します。 system_prompt では、新たな金額、日付、確率、結果を作ることを禁止します。設定済みのLanguage Model出力を modelに接続します。モデルは所見を説明できますが、確定的な確認用の表が引き続き正式な情報源です。

営業パイプラインのレポート自動化は、流暢な説明が相関関係を因果関係へ変えてしまうと失敗しがちです。ある日付以降に連絡がないとエクスポートが示しているなら、その観測事実を報告します。追加の根拠なしに、見込み客が関心を失った、営業担当者が行動しなかったと主張しないでください。

関連情報：売掛金管理自動化：提供データによるエイジング確認。

6. レポートを元データと照合する

出力には、スナップショット、承認済みの対象集合、方針の版、データ品質の例外、フラグ付き商談と元データへの参照を示します。Chat Outputで構造化された説明を表示し、配布前に確認用の表と比較します。説明内の識別子が元データになければ解消し、未回答の業務上の問いは見える状態に保ちます。

空のエクスポート、重複識別子、不明なステージ、スナップショットより後の日付、担当者の欠落、次のアクション文の欠落をテストします。受け入れには、承認済みの全行が説明され、データ不足が捏造された所見にならないことが必要です。プロジェクト状況のレポート自動化を追加する場合は、プロジェクト固有の依存関係と日付を別に定義します。商談ステージはプロジェクトの完了を表す代わりにはなりません。