Salesforce チャーン分析パイプラインの構築：Claude Code と CData CLI で実現するマルチステップ AI エージェントワークフローの設計

マルチステップという課題

AI エージェントは問題を推論しながら解決していくのが得意ですが、現実世界のワークフローの多くは、単一のプロンプトにきれいに収まるものではありません。外部システムへの照会、結果の分析、コンテンツの生成、データベースへの書き戻し、レポートの作成といった複数の段階にまたがるプロセスでは、1 つのエージェントとの会話はすぐに限界に達してしまいます。前のステップで生じたノイズでコンテキストが埋まり、エージェントは相容れない推論モードを同時にこなさなければならず、しかも全体を再実行することなく 1 つのパーツだけをテストしたり改良したりする手段がありません。こうしたマルチステップの問題に AI エージェントは本来うってつけなのですが、ワークフローをどう構成するかは、エージェントの能力そのものと同じくらい重要なのです。

私がもっとも効果的だと感じているアーキテクチャは、2 層構成の設計です。ワークフローを調整するオーケストレーターエージェントが、それぞれが明確に定義された 1 つのステップを担うモジュール化されたスキルを呼び出していきます。各スキルにより、エージェントは構造化されたデータを読み込み、自分の仕事を完了し、次のステップが利用できる構造化された出力を書き出せます。

この記事では、具体的な実装例として Salesforce のチャーンリスク検出パイプラインを取り上げ、なぜこのモジュール化パターンがマルチステップのエージェントワークフローにうまく機能するのかを解説していきます。

アーキテクチャ：オーケストレーター + モジュール化スキル

この設計は 2 つの層で構成されています。

レイヤー 1：オーケストレーターエージェントは、ワークフローの順序を制御し、各ステップの完了後に進捗を報告し、人間が介在する確認ゲートを管理し、エラーを処理する単一のエージェント定義です。操作の順序は把握していますが、実際の作業はすべてスキルに委譲します。

レイヤー 2：モジュール化スキルは、それぞれが 1 つのステップを担う、独立して完結したスキル定義です。各スキルは独自のツール権限、独自の指示、そして独自の出力ファイルを持ちます。オーケストレーターエージェントは、ディスク上の JSON ファイルを通じてスキルの出力を読み取ります。

データの流れは次のようになります。

個別のスキルがうまく機能する理由

モジュール化されたスキルが、単一のコンテキストを持つ 1 つのエージェントよりも良い結果を生み出すのには、具体的で実践的な理由があります。

1. 推論モードの違い：データベースへのクエリ実行や、ルーブリックに照らしたアカウントのスコアリングは、分析的で構造化された作業です。共感を込めた顧客向けアウトリーチメールの下書きは、創造的で言語的な作業です。重複チェックを伴う CRM へのレコード挿入は、正確でトランザクショナルな作業です。エグゼクティブサマリーの作成は、統合（シンセシス）の作業です。スキルを分離することでエージェントは専門特化でき、システムプロンプト、ツール権限、コンテキストのすべてが、その 1 種類の推論に最適化されます。
2. 独立してテストできる：どのスキルも単独で実行できます。スコアリングのルーブリックを微調整したいですか？メール送信や CRM への書き込みを発生させることなく、監査スキルだけを実行し、JSON 出力を確認し、調整して再実行できます。各スキルは明確な契約を持っています。すなわち、JSON ファイルを読み込み、JSON ファイルを書き出すのです。
3. ワークフローは成長していく：今日は 4 ステップですが、来月には Jira チケットと相互参照したり、Slack に投稿したり、請求システムをチェックしたりするステップを追加するかもしれません。モジュール化されたスキルなら、ステップの追加は新しいスキルファイルを 1 つ作成し、オーケストレーターに 1 行追加するだけです。既存のスキルには手を加えません。
4. 障害の切り分け：ステップ 3 が失敗しても、ステップ 1 と 2 の出力はディスク上に安全に保存されています。オーケストレーターはエラーを報告し、リトライするかスキップするかを尋ねて処理を続行できます。中間結果が失われることは決してありません。
5. 必要に応じた人間の介在ゲート：オーケストレーターはスキルとスキルの間で自然に一時停止するため、CRM へのレコード書き込みのような影響の大きいアクションの前に確認ステップを挿入するのも簡単です。

CData CLI で外部システムに接続する

CData CLI は、CData の接続レイヤー全体を、シェルコマンドを実行できるあらゆるものに公開する単一のコマンドラインツールです。これには Bash ツールを備えた Claude Code エージェントも含まれます。エージェントの視点からすると、Salesforce とのやり取りは一連の CLI 呼び出しにすぎません。GUI が間に入ることもなく、プロビジョニングすべき MCP サーバーもなく、事前に組み込んでおかなければならないドライバーもありません。

具体的には、エージェントは人間の関与を最小限に抑えながら、次の 4 つのことを自力で実行できます。

1. ダウンロード：エージェントは利用可能なコネクタのカタログを調べ、必要なものをインストールします。ワークフローが Salesforce のデータを要求すると、エージェントは Salesforce コネクタの CLI インストールコマンドを実行します。
2. 認証：CLI はデータソースの認証フローをエージェントに案内します。Salesforce のような OAuth ベースのシステムの場合、ログインを開始し、人間がブラウザーで承認するためのワンタイム URL を提示し、その結果を取得します。
3. 接続：コネクタがインストールされ、資格情報が手元にあれば、エージェントは CLI を使って名前付きの接続を作成します。接続は実行間でもスキル間でも再利用できます。
4. クエリ：接続が存在すれば、エージェントはデータソースに対して SQL を実行します。SELECT、INSERT、UPDATE、スキーマの検出は、すべて単なる CLI 呼び出しです。エージェントは標準的な SQL を書き、CData がその裏側で API 変換、認証のリフレッシュ、ページネーション、レート制限を処理します。

これがエージェントワークフローにとって重要なのは、セットアップのステップがもはや人間の前提条件ではなくなるからです。従来、Claude を Salesforce に接続するということは、管理者が MCP サーバーをプロビジョニングし、ドライバーをインストールし、OAuth を設定し、完成した接続をエージェントに引き渡す、ということを意味していました。CLI を使えば、まっさらなリポジトリの新しいエージェントが、接続をエンドツーエンドで自力で立ち上げられるのです。

また、これは Salesforce をクエリするのと同じスキルが、Jira、HubSpot、Dynamics 365、ServiceNow、Snowflake、BigQuery など、CData が対応する数百種類のデータソースのいずれにも向けられることを意味します。

具体例：Salesforce のチャーンリスク検出

このパターンを説明するために、よくあるシナリオに取り組みました。Salesforce のアカウントをチャーンリスクのシグナルについて分析し、カスタマーサクセスのアウトリーチを自動化するというものです。

私たちは 4 ステップのパイプラインを構築しました。

1. アカウントの監査：Salesforce にリスクシグナルのクエリを実行し、各アカウントをスコアリングします
2. メールの下書き：高リスクのアカウント向けにパーソナライズされた CS アウトリーチを作成します
3. タスクの作成：フォローアップの Task レコードを（人間の承認を得たうえで）Salesforce に挿入します
4. ダイジェストの作成：CS リーダー向けのエグゼクティブサマリーを生成します

パイプライン全体は、単一のオーケストレーターエージェントのプロンプトを通じて実行されます。それでは、それぞれのパーツを見ていきましょう。

ステップ 1：アカウントの監査 — データ収集とスコアリング

これは分析的なステップです。監査スキルは、CData CLI 経由で Salesforce に対して SQL クエリを実行します。

1. 期限超過の進行中の商談：クローズ日が 30 日以上前なのに、まだオープンのままになっている商談
2. 非アクティブなアカウント：60 日以上にわたって記録されたアクティビティがないアカウント
3. 滞留している未解決のケース：14 日以上オープンのままになっているサポートケース
4. 最近のアウトリーチタスク：CS がすでに最近コンタクトを取っていないかを確認する重複チェック

データを収集した後、エージェントはルーブリックに照らして各アカウントをスコアリングします。

その後、アカウントはリスクの段階別に分類されます。HIGH（8〜10）、MEDIUM（6〜7）、LOW（1〜5）です。

出力は audit_results.json という名前の構造化された JSON ファイルで、リスクスコアの降順でソートされています。

ステップ 2：メールの下書き — 創造的な推論

このステップは、まったく異なる種類の作業です。ステップ 1 がクエリを実行し算術的なスコアリングルールを適用する分析的な作業だったのに対し、ステップ 2 は創造的で言語的な作業です。エージェントは、押しつけがましくならずに具体的なリスクシグナルに言及しながら、共感的でパーソナライズされたアウトリーチを書く必要があります。

このスキルは audit_results.json を読み込み、リスクスコアが 6 を超え、かつ最近アウトリーチを受けていないアカウントに絞り込み、それぞれに対してパーソナライズされたメールを下書きします。

メールのガイドラインでは、「パーソナライズされた」とは具体的に何を意味するのかを明確に定めています。

• 第 1 段落：アカウント名に触れる温かみのある書き出し
• 第 2 段落：具体的なシグナルへの言及。「ご様子をうかがいたく」ではなく、「［件名］に関する未解決のサポートケースがあることに気づきました」や「［日付］付のご提案がまだ確定していないことを確認しました」といった具合に
• 第 3 段落：プレッシャーを与えない行動喚起。短い通話を提案し、日程の柔軟性を申し出る

トーンも明示的に定義されています。プロフェッショナルで、共感的で、コンサルティング的なトーンです。

ステップ 3：タスクの作成 — 人間が介在するゲート

これはトランザクショナルなステップであり、Salesforce 内のデータを変更する唯一のステップです。この違いこそが、ここに確認ゲートを設けている理由です。

タスク作成スキルが実行される前に、オーケストレーターは監査結果とメールの下書きを読み込み、何が作成されるのかを正確に示すわかりやすいプレビューをユーザーに提示します。

挿入後、このスキルは各 Task を再クエリして実際に作成されたことを検証し、確認済みの Task ID をログに記録します。

ステップ 4：ダイジェストの作成 — 統合

最後のステップでは、それまでのすべての JSON 出力を読み込み、エグゼクティブ向けの markdown サマリーに統合します。ひと目で把握できるように設計されており、CS リーダーが 30 秒で状況を理解できることを目指しています。

ダイジェストには以下が含まれます。

• リスクのあるアカウントの総数、平均スコア、作成されたタスク数を示すサマリーヘッダー
• リスクの段階（HIGH、MEDIUM、LOW）別にグループ化され、アカウント名、スコア、主要なシグナル、タスクのステータスを示すテーブル
• 各 HIGH リスクアカウントについて、推奨される次のステップを添えた詳細な段落

オーケストレーター

各ステップが個別に意味をなすことがわかったところで、それらを結びつける接着剤の役割を見てみましょう。

オーケストレーターは Claude Code のエージェント定義であり、単一の markdown ファイルです。その全体構造は次のとおりです。

各スキルは Bash を通じて CData CLI を呼び出すため、オーケストレーターはデータソース固有のツールをフロントマターに組み込む必要がありません。Bash こそが、オーケストレーターに必要な唯一の統合接点なのです。

このパターンを Salesforce 以外にも応用する

Salesforce のチャーンパイプラインは、1 つの実装例にすぎません。その土台となるパターンは、複数のシナリオに応用できます。

オーケストレーター + モジュール化スキル + データ接続 + 中間ファイル

データソースを差し替えても、アーキテクチャはそのままです。同じ CData CLI を通じて到達できる他のシステムでは、次のような形になります。

HubSpot：商談パイプラインの健全性（ステージで停滞している商談、アクティビティのない商談）を監査し、フォローアップメールを下書きし、営業担当者向けのタスクを作成し、パイプラインの健全性レポートを作成します。

Jira：滞留しているチケット（2 週間更新がない、スプリント期限を逃したもの）をスキャンし、エンジニアリングリード向けにエスカレーションサマリーを下書きし、チケットの優先度を更新し、スプリントの健全性ダイジェストを生成します。

ServiceNow：インシデントの解決時間を SLA の閾値に照らして監視し、SLA に違反したインシデントについてステークホルダー向けの連絡文を下書きし、フォローアップタスクを作成し、SLA 遵守レポートを作成します。

Dynamics 365：エンゲージメントのシグナルに基づいてリードをスコアリングし、パーソナライズされたアウトリーチを下書きし、CRM にアクティビティを作成し、マーケティング向けのリード品質ダイジェストを書きます。

Snowflake / BigQuery：テーブル全体にわたってデータ品質（null 率、スキーマドリフト、鮮度）をプロファイリングし、異常レポートを生成し、データオーナー向けに Jira でチケットを作成し、データ品質ダッシュボードのサマリーを作成します。

いずれのケースでも、形は同じです。システムにクエリを実行し、見つかったものについて推論し、アクションを起こし、要約する。オーケストレーターが順序付けとゲートを処理します。スキルがドメイン固有の作業を処理します。そして CData CLI がシステムの統合、すなわちインストール、認証、接続、クエリを処理するのです。

学んだこと

まず 1 つのスキルから始める：オーケストレーターや他のステップを構築する前に、まずそれを単独で動かしてみましょう。私たちは audit-accounts から始め、他に手を付ける前に、実データに対してスコアリングのルーブリックを繰り返し改良しました。

JSON ファイルの生成がデバッグを簡単にする：メールの下書きに何かおかしいところがあれば、audit_results.json を開けば、メールスキルが何をもとに作業していたのかが正確にわかります。隠れた状態もなければ、調べるべき共有メモリもありません。あるのはディスク上のファイルだけです。

オーケストレーターは薄く保つ：その役割は順序付け、進捗報告、確認ゲート、エラー処理です。スコアリングのルーブリック、メールのガイドライン、SQL クエリ、重複チェックを含むすべてのドメインロジックは、スキルの中に置かれます。メールの書き方を変えたいときは、1 つのファイルを編集するだけです。

設計上の検討事項：複数エージェント

取り上げておく価値のある設計上の問いが 1 つあります。なぜ複数の独立したエージェントではなく、1 つのオーケストレーターエージェントが複数のコマンドを呼び出す形にするのか、という点です。このパイプラインでは、各ステップが前のステップの出力に依存しています。メールの下書きには監査結果が必要で、タスクの作成にはメールの下書きが必要で、ダイジェストにはそのすべてが必要です。単一のオーケストレーターエージェントなら、こうした逐次的なデータフローを自然に管理できます。各ステップごとに別々のエージェントを立ち上げると、エージェント間のコンテキストの受け渡し、実行順序の同期、引き継ぎの処理といった調整のオーバーヘッドが増えるだけで、作業が本質的に逐次的である以上、実質的なメリットはありません。

とはいえ、複数のエージェントのほうが理にかなうシナリオもあります。Salesforce のアカウントを監査しつつ Jira のチケットを同時にスキャンする必要がある場合、つまり共有する入力がない 2 つの独立したデータ収集ステップであれば、それらを並列のエージェントとして実行すれば、パイプラインの所要時間を半分に短縮できます。同様に、ワークフローが十分に複雑で、ステップによって異なるモデルの強みが活きる場合（単純な参照には高速なモデル、ニュアンスのある文章作成にはより強力なモデル）、別々のエージェントにすればステップごとにモデルを割り当てられます。

オーケストレーター + モジュール化スキルのパターンは、テストしやすく、拡張しやすく、理解しやすいマルチステップの AI エージェントワークフローを構築するための、構造化された方法を与えてくれます。各スキルが 1 つの仕事を担い、オーケストレーターが流れを担い、ディスク上の JSON ファイルがすべてを透明に保ちます。Salesforce でチャーンリスクを監視する場合でも、CData の豊富なカタログにある他のあらゆるデータソースのデータを分析する場合でも、パターンは変わりません。ステップを定義し、データに接続し、あとはエージェントに仕事を任せる、それだけです。

今すぐ始めましょう

CData JDBC Driver for Salesforce と CData CLI の無償 30 日間トライアルで、今すぐ構築を始めましょう。Claude Code と組み合わせれば、Salesforce のライブデータを照会し、スコアリングし、それに基づいてアクションを起こすマルチステップのエージェントパイプラインを作成できます。始めるにあたってさらにサポートが必要な場合は、サポートチームまでお問い合わせください。