「Zoho CRMと既存システムを連携できますか」

これは問い合わせでいちばん多い質問です。そして答えは、ほぼ必ず「できます。ただし、どの手段で繋ぐかで工数も運用の難易度もまったく変わります」になります。

Zoho CRMの外部連携には、設定画面でスイッチを入れるだけのものから、コードを書いて認証を通すものまで、何段階ものレイヤーがあります。ここを把握しないまま「APIで繋ぎましょう」と話が進むと、実は拡張機能をインストールすれば済んだ、ということが起こります。逆に、拡張機能で無理に済ませようとして、要件を満たせないまま運用が始まることもあります。

この記事では、Zoho CRMの外部連携の手段を6つに分けて整理し、どの要件をどの手段で解くべきかをまとめます。

※機能・制限は変更されることがあります。本記事は2026年11月時点の公式ドキュメントの情報をもとにしています。

Zoho CRMの外部連携は、大きく6つに分かれる

先に全体像を出します。

手段	コードの必要性	向いている用途
標準連携	不要	Google Workspace、Microsoft 365、電話など定番サービス
Marketplace拡張機能	不要	既に拡張機能が公開されているサービス
Zoho Flow	不要（画面で組む）	条件分岐を含む複数アプリ間の連携
Webhook	ほぼ不要	CRMの変更をリアルタイムで外部に通知する
外部連携（コネクター）＋Deluge	必要	CRM側から外部APIを叩き、戻り値を使って処理する
REST API	必要	外部システムからCRMを読み書きする

重要なのは、上の3つは「設定」の話で、下の3つは「開発」の話 だという点です。この境界線がどこにあるかを先に知っておくと、見積りの前提が揃います。

1. 標準連携：設定するだけで繋がるもの

まず確認すべきは、やりたいことが標準連携でカバーされていないかどうかです。

Google Workspace

Google Workspaceとの連携は、すべてのZoho CRMプランで追加費用なしに利用できます。 公式サイトに明記されています。

できることは広く、主なものは次の通りです。

• Gmail：顧客とのメールのやり取りをCRM上で確認し、CRMから返信できる。Chrome拡張機能を使えば、Gmailの画面側から見込み客・連絡先の追加、通話の記録、予定の登録、見込み客から連絡先への変換まで行える
• Googleカレンダー：予定・会議・タスクを双方向同期
• Googleドライブ：ドライブ上のファイルをCRMから参照し、レコードに添付できる（ファイルを移動させる必要がない）
• Google連絡先：メモを含めてCRMに取り込み、双方向でリアルタイム同期
• Googleタスク：双方向同期
• Googleサイト：CRMで作成したWebフォームをGoogleサイトに公開し、訪問者の情報をCRMに戻す
• Google広告：Webフォーム経由の見込み客をCRMに登録し、どのキャンペーン・広告グループ・キーワードが成約に繋がったかを把握できる。GCLIDを取得してオフラインコンバージョンも追跡可能
• Googleアカウントでのシングルサインオン

このうち実務でよく効くのは、Chrome拡張機能とGoogle広告のオフラインコンバージョン計測です。前者は「CRMを開かせる」という定着のハードルを下げられますし、後者は「どの広告が受注に繋がったか」を広告管理画面側で見られるようになります。

電話連携（Zoho PhoneBridge）

電話システムとCRMを繋ぐ仕組みです。利用前にCRM側で有効化が必要で、［設定］＞［チャネル］＞［電話］から「PhoneBridge（電話連携）を有効にする」 を押します。

ここを忘れてPBX側から接続しようとすると「Admin has not enabled Telephony in Zoho」というエラーになります。設定の順番が決まっているので、連携作業の最初に済ませてください。

その他

Microsoft 365／Outlook、各種チャットツールなど、定番サービスは標準またはMarketplace経由で用意されています。Zohoは製品群を自社開発しているため、Zoho同士の連携（Desk、Projects、Analytics、WorkDrive、Campaigns など）は、そもそも外部連携の枠組みを使わずに繋がります。

2. Marketplace拡張機能：既にあるものを探す

Zoho Marketplaceには、Zoho CRM向けの拡張機能が多数公開されています。インストールすると、別アプリに切り替えずにCRMの同一画面上で処理を完結できる のが狙いです。

公式ヘルプに掲載されている代表的なものを挙げます。

• Shopify：オンラインストアの購入履歴をCRMに同期
• MailChimp／SendinBlue：メールキャンペーンと配信先情報を同期し、配信結果をCRMから確認
• GoToWebinar／Eventbrite：ウェビナー・イベントの参加者を見込み客としてCRMに追加
• Zendesk：サポートチケットと顧客情報を同期し、営業とサポートで最新状況を共有
• DocuSign／Adobe Sign：顧客に送付した書類の電子署名を依頼し、ステータスを追跡
• Kanban Board：各タブのレコードをカード形式で表示し、カテゴリごとに列分け

要件を聞いたとき、まずMarketplaceを検索するのは鉄則です。「自社システムとの連携」以外の、世の中にあるSaaSとの連携であれば、既に誰かが作っている可能性が十分にあります。

ただし注意点が2つあります。ひとつは、拡張機能の同期仕様は作った側が決めているため、「同期の方向」「同期の粒度」「同期のタイミング」が自社の要件と合わないことがある点。もうひとつは、提供元がZohoではないサードパーティ製のものも多く、サポート体制や更新頻度に差がある点です。検証環境で実際の動きを確認してから本番に入れてください。

3. Zoho Flow：画面で組む自動化

Zoho Flowは、アプリ間の連携をドラッグ＆ドロップで組めるiPaaS（連携自動化）サービスです。多数のアプリに対応しており、「Aで何かが起きたらBで処理する」というフローを、条件分岐やデータ加工を含めて画面上で構築できます。

Zoho CRMの標準ワークフローとの違いは、複数のアプリをまたぐかどうか です。CRM内で完結する処理（ステータスが変わったらタスクを作る等）はCRMのワークフローで済みますが、「CRMの商談が受注になったら、会計システムに請求データを作り、チャットに通知する」のような横断処理はFlowの領域になります。

Flowの詳細は別記事で解説しているので、ここでは位置づけだけ押さえておいてください。

4. Webhook：CRMの変更を外部に通知する

ここから開発寄りの話になります。

WebhookはZoho CRMでイベントが発生した瞬間に、外部アプリへHTTP通知を飛ばす仕組みです。作成した上でワークフロールールに紐づけて使います。

利用できるプランと制限

Webhookはプロフェッショナル以上のプランで利用できます。 無料・スタンダードでは使えません。あわせて、ユーザーのプロフィールに「ワークフローの管理」権限が必要です。

1日あたりの通知回数には上限があり、組織単位とユーザー単位の両方が設定されていて、少ない方が適用されます。

プラン	組織単位／日	ユーザー単位／日
プロフェッショナル	50,000回	100回
エンタープライズ	500,000回	500回
アルティメット	1,000,000回	1,000回

ユーザー単位の数字に注目してください。プロフェッショナルは1ユーザーあたり100回/日です。組織の上限が5万回あっても、10ユーザーなら実質1,000回で打ち止めになります。大量のレコード更新をトリガーに通知を飛ばす設計だと、ここに引っかかります。

上限を超えた場合、残りの通知は送信されず、管理者に通知が届きます。

技術的な制約

設計時に知っておくべき仕様をまとめます。

• 対応メソッド：POST（デフォルト）、GET、PUT、DELETE
• 対応ポートは80と443のみ
• 1つのワークフロールールに紐づけられるWebhookは最大6つ（即時実行1つ＋日時指定5つ）
• ヘッダーパラメーターは最大10個
• form-data形式：モジュールパラメーター25個、カスタムパラメーター10個、構造化パラメーターは最大10,000文字
• raw形式：最大15,000文字。form-dataとの併用は不可
• 通知が失敗した場合、15分後に1回だけ再試行し、その後は送信を停止
• 10秒以内に応答がないとタイムアウト
• 通話記録（Call Logs）とメモ（Notes）モジュールは非対応

実務で効くのは、ポート制限と再試行の仕様です。自社システム側が80/443以外で待ち受けている構成だと、そのままでは繋がりません。また、再試行が1回しかないため、受け側が落ちていた時間帯の通知は失われます。欠損が許されないデータ連携にWebhook単独で寄せるのは危険 で、定期的な差分同期を併用するのが現実的です。

Webhookの向き

もうひとつ押さえておくべきなのが方向です。Webhookは「CRMから外部へ」の一方通行です。公式ヘルプにも、他アプリからZoho CRMへデータを取り込むことはできないと明記されています。外部からCRMを更新したい場合は、後述のREST APIを使います。

5. 外部連携（コネクター）とDelugeのinvokeUrl

CRM側から外部サービスのAPIを呼び出し、その戻り値を使って処理を続けたい 場合は、この組み合わせになります。

公式ドキュメントでは「外部連携は、Zoho CRMアカウントを任意の外部サービスアプリケーションに連携するためのシンプルな認証メカニズム」と定義されています。やっていることは認証情報の管理で、これを設定しておくと、関数やウィジェットから認証済みの状態で外部APIを叩けるようになります。

対応している認証方式

• Basic認証
• OAuth 1.0
• OAuth 2.0

サービスによって必要な方式が異なるため、3種類が用意されています。20以上の人気アプリケーションについては、すぐに連携できる定義が最初から用意されています。任意のアプリケーション向けに独自の連携を作ることも可能です。

必要な権限とスキル

ここは明記されています。設定できるのは管理者のみ です。そして想定利用者は「連携を設定するCRM管理者」と「REST APIおよびDelugeスクリプトのスキルを持つプログラマー」とされています。

つまりこの手段は、設定画面を触るだけでは完結しません。コネクターで認証を通したあと、Delugeのカスタム関数でinvokeUrlを呼び、返ってきたJSONをパースしてCRMのレコードを更新する、という実装が必要になります。

プランの前提

Delugeのカスタム関数はエンタープライズ以上 の機能です。したがって、この手段を前提にする場合、実質的にエンタープライズが下限になります。

公式ドキュメントに挙げられている利用例が、この手段の性格をよく表しています。CRMからEventBriteへイベントを送信する、Bomgarのリモートアクセスサービスと連携して技術者が顧客のデバイスをリモート制御できるようにする。いずれも「通知を飛ばす」では済まず、外部サービスの応答を使って次の処理を組み立てる必要があるケースです。

6. REST API：外部システムからCRMを読み書きする

最後は、外部システムが主体になるパターンです。自社の業務システムや基幹システムからZoho CRMのデータを取得・登録・更新する場合は、REST APIを使います。

1日あたりのAPIリクエスト上限

ここが設計上もっとも重要です。公式のAPI制限ページには、次のように記載されています。

プラン	1日あたりのAPIリクエスト数（組織単位）
無料	1,000
スタンダード	最小2,000／最大5,000（ユーザーライセンス1件あたり250で計算した値と比べて少ない方）
プロフェッショナル	最小3,000／最大10,000（同じく250／ライセンス）
エンタープライズ	最小4,000／最大25,000（500／ライセンス）

リセットは太平洋標準時（PST）の00:00です。日本時間の夕方前後に切り替わる計算になるため、「深夜のバッチで一気に流す」設計だと、意図した日付とカウントされる日付がずれる可能性があります。

そして上限そのものについて。エンタープライズでも最大25,000リクエスト/日です。1レコード1リクエストで回すと、2万件の同期で上限に達します。大量データを扱うなら、1件ずつのAPIコールではなく、複数レコードを1リクエストにまとめる方式やバルク処理を前提に設計する必要があります。

なお、APIの仕様とバージョンは更新が続いています。開発に入る前に、必ず最新の開発者ドキュメントで対象バージョンの制限を確認してください。古い記事やまとめサイトの数値を前提に見積もると、途中で設計変更が必要になります。

結局、どう使い分けるか

判断の順番を整理します。上から順に当てはまるか確認していくと、過剰な開発を避けられます。

1. Zoho製品同士か？ → 標準の製品間連携を使う。開発不要

2. 定番サービス（Google、Microsoft、電話）か？ → 標準連携を確認する。Google Workspaceは全プランで無料

3. Marketplaceに拡張機能があるか？ → あれば検証して採用を検討。同期仕様が要件に合うかを必ず確認

4. 複数アプリをまたぐ処理で、運用担当者が後から条件を変えたいか？ → Zoho Flowで組む

5. CRMの変更を外部に知らせるだけか？ → Webhook（プロフェッショナル以上）。ただし通知回数とポート、再試行の制限を確認

6. CRMから外部APIを呼んで、戻り値を使いたいか？ → 外部連携（コネクター）＋Delugeのカスタム関数（エンタープライズ以上）

7. 外部システムが主体でCRMを読み書きするか？ → REST API。リクエスト上限を前提に設計する

外部連携でつまずきやすいポイント

最後に、実際の構築でよく起きることを挙げます。

プランの制約を後から知る

これがいちばん多いパターンです。スタンダードで契約したあとに「変更があったら自社システムに通知したい」という要望が出て、Webhookがプロフェッショナル以上だと判明する。あるいは「外部APIの結果を使って項目を埋めたい」という要望が出て、カスタム関数がエンタープライズ以上だと判明する。

契約前の段階で「1年後にどこまで繋ぎたいか」を洗い出しておくと、ここは避けられます。

リクエスト上限を無視した同期設計

1日1回の全件同期は、データ件数が増えると必ず上限に当たります。最初から差分同期で設計し、全件同期は初回移行時だけに限定するのが基本です。

エラー時の扱いを決めていない

Webhookの再試行は1回だけ、タイムアウトは10秒。APIも上限に達すれば弾かれます。「連携が失敗したことに誰がどうやって気づくか」 を設計に含めていないと、気づかないうちにデータがずれていきます。失敗を記録するログ用のモジュールを用意する、あるいは定期的に件数を突き合わせる仕組みを入れるなど、検知の手段を必ずセットで作ってください。

テスト環境を用意していない

外部連携は本番データを動かします。エンタープライズ以上で使えるサンドボックスを活用し、本番に影響を与えない状態で検証してから反映する流れを作っておくと安全です。

まとめ

• Zoho CRMの外部連携は、標準連携・Marketplace拡張機能・Zoho Flow・Webhook・コネクター＋Deluge・REST APIの6層に分かれる
• 上の3つは設定の範囲、下の3つは開発の範囲。この境界を先に見極める
• Google Workspace連携は全プランで追加費用なし。Gmail、カレンダー、ドライブ、連絡先、Google広告まで広くカバー
• Webhookはプロフェッショナル以上。ポートは80/443のみ、再試行は15分後に1回だけ、ユーザー単位の回数上限に注意
• コネクター＋Delugeのカスタム関数はエンタープライズ以上。外部APIの戻り値を使う処理はここ
• REST APIの上限はエンタープライズでも最大25,000リクエスト/日。バルク前提で設計する
• プラン制約・リクエスト上限・エラー検知の3点を先に決めておくと、作り直しが起きにくい

AndSoでは、Zoho CRMと既存システムの連携設計から、Delugeやウィジェットを使った独自連携の実装までを承っています。「APIドキュメントは読んだが、自社の要件をどの手段で解くべきか判断がつかない」という段階でも、お気軽にご相談ください。