Cursor × Attio で実現するセールス主導のAI駆動CRM構築

「CRM に入力したら見積書が自動で作られ、署名が完了したら CS に自動で引き渡される」――こうした一気通貫の自動化は理想ですが、CRM のエコシステム内で実現しようとすると対応ツールの制約を受けますし、独自に連携を組もうとするとエンジニアリソースと相応の工数が必要になります。

本記事では、Cursor（AI コーディングエージェント）× Attio（AI ネイティブ CRM）を使って、セールス担当者自らがリード獲得から請求管理まで一気通貫でつながる CRM 環境を構築し、運用を始めた事例を紹介します。まだ始まったばかりで、これから磨き込んでいく途中のリアルな記録です。

CRM の「あるある」問題

なぜ営業基盤は形骸化するのか

CRM を導入したものの、こんな状態になっていないでしょうか。

• 使いこなせない: 高機能な CRM ほど設定項目が膨大で、結局デフォルトのまま使っている
• メンテできない: カスタマイズを担当していた人が異動・退職し、誰も設定を触れなくなる
• 活用されない: 「入力はしているが、データが意思決定に使われていない」

私たちも同じ課題に直面しました。CRM は導入されていたものの、設定・運用の知見を持っていた担当者が不在になり、事実上メンテナンスできない状態に。事業フェーズの拡大に伴い管理すべき項目は増えていくのに、CRM 側を柔軟にカスタマイズできない。現場の業務と CRM の構造が乖離していく一方でした。

構造的な問題は「分断」にある

もうひとつの問題は、業務プロセスの分断です。

リード管理は CRM、議事録は Google Docs、見積書は帳票ツール、契約は電子署名ツール、タスク管理はプロジェクト管理ツール――。それぞれのツールは優秀でも、ツール間のデータの受け渡しが手作業であれば、転記ミス、情報の抜け漏れ、ステータスの不整合が発生します。

「CRM に入力したら帳票が自動で作られ、署名が完了したら CS に自動で引き渡される」

こうした一気通貫の自動化が理想ですが、CRM のエコシステム内で実現しようとすると対応ツールの制約を受けますし、独自に連携を組もうとするとエンジニアリソースと相応の工数が必要になります。

なぜ Attio だったのか

API ファースト × 柔軟なデータモデル

CRM 環境を見直すにあたり、いくつかの選択肢を検討しました。その中で自分たちが重視したのは以下の3点です。

1. 柔軟なデータモデル: 固定的なオブジェクト構造ではなく、自分たちの業務に合わせてカスタマイズできること
2. API ファーストの設計: 外部サービスとの連携を前提とした拡張性があること
3. 導入・運用コストの現実性: 少人数チームでも無理なく始められること

Attio は、AI ネイティブな CRM として近年注目を集めているプロダクトです。カスタムオブジェクトを自由に定義でき、Workflow 機能から外部システムへ HTTP リクエストを送れる。「CRM の中にすべてを閉じ込める」のではなく、CRM を連携のハブとして、各プロセスを最適なツールでつなぐという設計思想が特徴です。

GitHub ワークスペースとの親和性

ROUTE06 は GitHub を開発だけでなく、全社ワークスペースとして採用しています。プロジェクト管理、ドキュメント管理、意思決定の記録――すべてが GitHub 上に集約されている。

Attio の API ファーストな設計は、この GitHub 中心のワークスタイルと自然にフィットしました。Attio でイベントが発生したら GitHub Actions が動き、GitHub で Issue をクローズしたら Attio に反映される。この双方向の連携が、特別な中間サーバーなしに実現できるという点が決め手でした。

iPaaS ではなく GitHub Actions + Attio Workflow を選んだ理由

ツール間の連携といえば、Zapier や Make といった iPaaS（Integration Platform as a Service）が選択肢に挙がります。ノーコードで手軽に連携を組めるのは魅力ですが、私たちはあえてGitHub Actions と Attio Workflow をベースにする判断をしました。

理由はシンプルで、余計なツールを増やしたくなかったからです。

iPaaS を挟むと、連携ツールが増えるだけでなく、ロジックの管理場所も分散します。「この自動化はどこで動いているのか」が Attio・GitHub・iPaaS の3箇所に散らばり、結局それが新たな属人化の種になる。

GitHub Actions であれば、ワークフローの定義もスクリプトもすべてリポジトリの中にコードとして残る。変更履歴は Git で追えるし、レビューもできる。Attio Workflow はトリガーの設定に徹し、実際の処理ロジックは GitHub Actions 側に寄せる。この役割分担により、何がどう動いているかが一箇所で把握できる構造を実現しました。

そして、コードがリポジトリにあるということは、Cursor で開けば中身を説明してもらえるということでもあります。ソースコードが読めなくても、「このワークフローは何をしているのか」と聞けば Cursor が解説してくれる。自動化の中身がブラックボックスにならない。これは iPaaS の GUI では得にくい透明性です。

Cursor でセールスが自ら構築した

「自分の業務を自分で自動化する」という発想

このCRM環境を構築したのは、エンジニアではありません。セールス担当者です。

使ったのは Cursor――AI コーディングエージェントです。別の記事でも触れましたが、AI 駆動の開発環境があれば、非エンジニアでも自分の端末でシステムを構築できます。今回はそのアプローチを、自分たちの営業基盤の構築に適用しました。

Cursor との対話は、こんな流れで進みます。

1. やりたいことを日本語で伝える: 「Attio で Contract を作成したら、Board に見積書を自動生成したい」
2. コードが生成される: Python スクリプト、GitHub Actions ワークフロー、API 連携コードが提案される
3. テストする: 実際に動かして、期待通りの動作か確認する
4. 修正を依頼する: 「エラーが出た」「この項目も連携したい」と伝えると修正される

このサイクルを繰り返しながら、少しずつ自動化の範囲を広げていきました。

現時点での全体像

運用を始めた時点で構築しているのは、以下の規模です。これからも継続的に拡張・改善していく予定です。

運用マニュアルも Cursor との対話の中で生成しました。構築した仕組みの「何が自動で、何が手動か」を整理していく過程で、自然とドキュメントとして形になっていきました。

なぜセールスが作るのが合理的なのか

「エンジニアに依頼すべきでは？」と思われるかもしれません。しかし、CRM の構築で最も重要なのは業務プロセスの理解です。

• リードがどう流れてくるのか
• 商談のどのタイミングで何が必要になるのか
• 契約書の項目はどう帳票に反映されるべきか
• CS への引き渡しで何を伝える必要があるのか

これらを最もよく知っているのは、セールス自身です。従来は「セールスが要件を伝え、エンジニアが実装する」というプロセスでしたが、AI 駆動の開発環境があれば、要件定義と実装のギャップを限りなくゼロに近づけられる。自分の業務を言語化できれば、そのまま動くシステムになる。これが実感です。

リードから請求まで、一気通貫でつながる

ここからは、現時点で構築している CRM の全体像を紹介します。ポイントは、6つのフェーズがシームレスにつながっていること。そして、セールスの手動操作は最小限に抑え、残りはすべて自動化されていることです。まだ運用を始めたばかりで、実際に使いながら細かい調整を続けています。

ツール連携の全体図

Attio を中心に、6つの外部サービスがイベント駆動で連携しています。データの流れは一方通行ではなく、GitHub → Attio、Attio → GitHub のように双方向に自動同期されるのがポイントです。

Phase 1: リード獲得 ── 名刺交換の翌朝には Attio に

展示会やイベントで名刺を交換する。翌朝オフィスに来ると、Attio のリードリストに新しいレコードが並んでいる。

Sansan API から過去7日間の名刺データを毎朝7時に自動取得し、Attio の People / Companies レコードに登録します。氏名、メール、電話番号、役職、部署、会社情報まで。既存レコードとの重複チェックも自動です。

名刺の「オーナー」情報も連携されるため、誰が交換した名刺かが Attio 上で自動的にわかります。

Phase 2: 商談管理 ── 「CRM への転記作業」が消える

リードリストで対象の People を開き、Run workflow ボタンをクリック。これだけで以下が自動的に起こります。

• Deal（商談）が自動作成され、リードのステータスが「商談中」に変更
• GitHub に親 Epic Issue が自動作成
• 初回商談用の Sub-issue も自動発行
• GitHub Projects のボードにも自動追加

商談後の議事録は、この Sub-issue に書きます。記入が終わったら Issue をクローズするだけ。すると GitHub Actions が起動し、Issue の内容が Attio の Deal に Note として自動連携されます。

「CRM に転記する」という作業が消える。議事録は GitHub に書く、それだけで CRM にも反映される。GitHub をワークスペースにしているチームにとって、これは自然な流れです。

Phase 3: 契約・帳票管理 ── 1アクションで4つの自動処理

商談が進み、見込み金額が見えてきたら Contract を作成します。契約サービス、契約種別、環境、プランを選択して保存。この1アクションで、以下の4つが自動的に実行されます。

1. Line Items 自動生成: Products マスタから条件にマッチする商品を検索し、契約明細を自動登録
2. Board 帳票自動作成: Board に顧客・案件を登録し、見積書・発注書（申込書）・請求書を自動生成
3. GitHub Issue 自動発行: 親 Epic に紐づく契約管理 Issue を自動作成
4. パイプライン自動変更: 商談ステージが「提案中」に自動変更

契約内容を変更した場合も、ワークフローを実行すれば Line Items と Board 帳票が自動で再生成されます。さらに、変更前後でデータにズレがあれば、Contract の Comments にアラートが自動通知される仕組みです。

Phase 4: 電子署名 ── 署名完了から PDF 保管まで自動

Board で見積書を確認し、DocuSign で先方に署名依頼を送信。先方が署名を完了すると、以下が自動的に処理されます。

• 署名済み PDF が Google Drive に自動アップロード
• Attio の Contract に契約書 URL が自動記録
• 署名完了の Note が自動追加

セールスが手動で行うのは「DocuSign で署名依頼を送ること」だけ。その後のファイル管理と CRM 更新はすべて自動です。

Phase 5: 受注確定 → CS 引き渡し ── 手動の伝達作業がない

署名完了を確認し、Contract のステータスを「有効」に変更する。これが受注確定のトリガーです。

この1操作で、以下が連鎖的に実行されます。

• Board のステータスが「受注済み」に自動変更
• GitHub の契約管理 Issue に契約書 URL がコメントされ、Issue が自動クローズ
• Deal のパイプラインが**「受注済（Won）」に自動変更**
• CS 管理ボードに**「営業引き渡し」ステータスで自動登録**
• アカウント発行 Issue が自動発行
• オンボーディング Issue が自動発行

セールスから CS への引き渡しに、手動の伝達作業がありません。CS 担当者は GitHub の Project ボードを見れば、自分に割り当てられた Issue が並んでいる。何をすべきか、どの顧客か、契約内容は何か――すべて Issue に記載されています。

Phase 6: 請求管理 ── 契約作成時に請求書も準備済み

Phase 3 で Contract を作成した時点で、Board 上に請求書データも自動生成されています。月次/年次の請求サイクルに応じた設定も、Contract の属性から自動で反映。

契約変更があった場合は、Attio でワークフローを実行するだけで、Line Items と Board 帳票（見積書・発注書・請求書）が最新の契約内容で再生成されます。

AI 駆動で構築するプロセスのリアル

Cursor との対話で何をしたか

この CRM 環境は、一度に完成したわけではありません。Cursor との対話を重ねながら、段階的に育てていきました。

初期フェーズ（スキーマ設計）:

まず Attio のオブジェクト構造を設計しました。Companies、People、Deals、Contracts、Line Items、Products――それぞれのオブジェクトにどんな属性が必要か、どうリレーションを張るか。Cursor に「商談管理で必要な項目は何か」と相談しながら、BANT 情報や SPIN 分析といったフレームワークも取り込んだ設計にしました。

連携フェーズ（スクリプト構築）:

次に、各ツールとの連携スクリプトを構築。Sansan → Attio の名刺同期、Attio → Board の帳票連携、DocuSign → Google Drive → Attio の署名フロー。それぞれ API の仕様を Cursor に調べてもらいながら、Python スクリプトを生成・テスト・修正していきました。

自動化フェーズ（ワークフロー構築）:

スクリプトが動くようになったら、GitHub Actions でイベント駆動の自動化を組みました。Attio Workflow から repository_dispatch で GitHub Actions を起動し、スクリプトを実行する。このアーキテクチャも Cursor との対話の中で設計しました。

運用フェーズ（マニュアル生成・移行）:

テストリポジトリで検証した後、本番リポジトリへ移行。移行時の動作確認も Cursor と進め、1,200行の運用マニュアルも対話の中で生成しました。「Step 1 で何が自動で起こるか」「エラー時はどうするか」――構築した仕組みを言語化する過程で、自分自身の理解も深まりました。

CRM は「導入するもの」ではなく「育てるもの」

この取り組みを進める中で実感しているのは、**CRM は「導入するもの」ではなく「育てるもの」**だということです。

事業フェーズが変われば、管理すべき項目も業務プロセスも変わります。新しいサービスが追加されれば契約テンプレートも変わる。CS のオンボーディング手順が改善されれば Issue テンプレートも更新する。この「変化に柔軟に追従できるかどうか」が、CRM が形骸化するかどうかの分岐点です。

AI 駆動の開発環境があれば、変更コストが劇的に下がります。「この項目を追加したい」「この条件で自動化したい」という要望を、Cursor に伝えるだけで実装できる。CRM を育て続けるサイクルが、セールス自身の手の中にある。運用を始めたばかりの今も、毎週のように小さな改善を重ねています。これが最大の価値だと実感しています。

おわりに

CRM が形骸化する原因は、ツールの良し悪しではなく、業務の変化にCRMが追従できなくなることにあります。事業フェーズが変われば必要な管理項目も業務フローも変わる。その変化に対応できなければ、どんな高機能な CRM もいずれ使われなくなります。

AI 駆動の開発環境は、この構造的な問題に対するひとつの解を示しています。セールス自身が業務プロセスを言語化し、Cursor に伝えるだけで CRM の構造もワークフローも更新できる。変化への対応コストが下がることで、CRM は「導入して終わり」のツールから「事業と一緒に育つ基盤」になる。

この先も進化は続きます。Attio は MCP（Model Context Protocol）を公開しており、AI エージェントから CRM のデータを直接読み書きできる世界がすでに見え始めています。GitHub Actions を介さずとも、AI エージェントが Attio のレコードを検索・更新し、商談の状況を要約して Slack に投稿する――そうしたワークフローが、MCP を通じて自然に実現できるようになるでしょう。

また、現在はセールスと CS の業務を中心に構築していますが、今後はパートナー管理への拡張も視野に入れています。販売代理店や紹介パートナーとの関係管理にも、同じ Attio × GitHub の基盤を活用していく予定です。

私たち ROUTE06 は、AI 駆動型のセールス組織の実現に向けて、営業基盤の構築・運用にも AI を積極的に活用しています。Cursor × Attio による CRM 構築は、その実践のひとつです。まだ道半ばですが、「自分たちの営業基盤を自分たちで育てる」という取り組みを、引き続き発信していきます。

「自社のセールスオペレーションを AI で変えたい」「一緒に検証したい」と思っていただけた方は、ぜひお気軽にお問い合わせください。

お問い合わせはこちら