API連携とは何ですか？

API連携とは、異なるソフトウェア同士がAPI（Application Programming Interface）を介してデータをやり取りし、業務プロセスを自動化することです。営業領域ではCRM・MA・チャットツール間のデータ連携に活用されます。

REST APIとSOAP APIの違いは何ですか？

REST APIはHTTPベースで軽量・シンプルな設計が特徴で、JSON形式のデータ交換が主流です。SOAP APIはXMLベースで厳密な型定義と高いセキュリティが強みですが、実装コストが高く、現在のSaaS連携ではREST APIが主流です。

API連携にプログラミングスキルは必須ですか？

Zapier・Make・n8nなどのiPaaSを使えばノーコードでAPI連携が可能です。ただし、CRMのカスタムオブジェクト操作やバッチ処理など高度な連携にはPython・JavaScriptの基礎とAPIリファレンスの読解力が必要になります。

APIのレートリミットとは何ですか？

レートリミットとは、一定時間内に送信できるAPIリクエスト数の上限のことです。HubSpotは1アプリあたり秒間10リクエスト、Salesforceは24時間あたりのリクエスト総数に制限があり、超過するとエラーが返されます。

WebhookとAPIの違いは何ですか？

APIはこちらからリクエストを送ってデータを取得する『プル型』、Webhookはイベント発生時に相手側から通知が送られる『プッシュ型』です。リアルタイム性が求められる営業プロセスの自動化にはWebhookが適しています。

API連携の基礎知識｜GTMエンジニアが押さえるべきREST APIの実践

API連携は、GTMエンジニアの実装力の核となる技術だ。CRM・MA・チャットツール・BIなど、営業組織が利用するSaaSは年々増え続けている。これらのツール間でデータが分断されていれば、営業プロセスの自動化も、正確なレポーティングも実現できない。API連携はこのデータの分断を解消し、営業プロセス全体を一つのデータフローとして設計するための基盤技術である。本記事では、GTMエンジニアの視点から、REST APIの基本構造、CRM APIの実践的な使い方、Webhookの活用パターン、そしてセキュリティとエラーハンドリングまでを体系的に解説する。

APIとは何か——GTMエンジニア視点での位置づけ

API（Application Programming Interface）とは、ソフトウェア同士がデータをやり取りするための「窓口」だ。レストランのウェイターに例えるなら、客（クライアント）がメニュー（リクエスト）を伝え、厨房（サーバー）が料理（レスポンス）を返す——その間を取り持つのがAPIの役割である。

GTMエンジニアにとってAPI連携が重要な理由は明確だ。営業組織で使われるツール群——HubSpot、Salesforce、Slack、Zoom、MAツール、BIツール——はそれぞれ独立したデータベースを持っている。これらを手動でつなぐと、CSVエクスポート・インポートの往復や、ダブルエントリーによるデータ不整合が生まれる。APIを介して自動連携すれば、データはリアルタイムに流れ、人の手を介さない分だけ正確性と速度が向上する。

CRMデータ設計の教科書で述べた通り、データの品質は設計の品質に依存する。API連携はその設計を「実装」に落とし込む行為であり、GTMエンジニアのスキルセットの中核を成す。

営業領域でのAPI連携の典型的なユースケースは以下の通りだ。

リード情報の自動同期: Webフォームの入力データをCRMにリアルタイム登録
商談ステージの変更通知: CRMのディール更新をトリガーにSlackへ自動通知
レポートデータの自動集約: 複数ツールのデータをBIダッシュボードに集約
顧客スコアの自動更新: 行動データをもとにリードスコアをCRM上で自動計算

REST APIの基本構造——HTTPメソッド、エンドポイント、認証

現在のSaaS連携でデファクトスタンダードとなっているのがREST（Representational State Transfer）APIだ。REST APIを理解するには、4つの構成要素を押さえればよい。

HTTPメソッド

REST APIでは、操作の種類をHTTPメソッドで表現する。

メソッド	操作	営業での具体例
GET	データの取得	CRMからコンタクト一覧を取得する
POST	データの新規作成	新しいリードをCRMに登録する
PUT / PATCH	データの更新	商談ステージを「提案済み」に変更する
DELETE	データの削除	重複コンタクトを削除する

GETとPOSTの違いを直感的に理解するなら、GETは「見せてください」、POSTは「作ってください」だ。PUTは既存データの全体を上書きし、PATCHは一部のフィールドだけを更新する。営業データの更新にはPATCHを使うケースが多い。

エンドポイント

エンドポイントは、APIリクエストの送り先となるURLだ。たとえばHubSpotのコンタクトAPIであれば以下のようになる。

GET https://api.hubapi.com/crm/v3/objects/contacts
POST https://api.hubapi.com/crm/v3/objects/contacts
PATCH https://api.hubapi.com/crm/v3/objects/contacts/{contactId}

URLの構造を見ると、/crm/v3/objects/contacts という「リソースのパス」が操作対象を示し、HTTPメソッドが操作の種類を示している。このリソース指向の設計がRESTの特徴であり、URLを見るだけで何のデータに対する操作かが直感的にわかる。

認証方式

APIにアクセスするには認証が必要だ。主要な認証方式は3つある。

APIキー認証: リクエストヘッダーやクエリパラメータにAPIキーを含める最もシンプルな方式。HubSpotのPrivate Appトークンがこれにあたる。手軽だが、キーが漏洩すると全権限が奪われるリスクがある。

OAuth 2.0: ユーザーの認可を得てアクセストークンを発行する方式。Salesforce、HubSpot（パブリックアプリ）、Google APIなどで採用されている。トークンの有効期限があり、リフレッシュトークンで更新する仕組みだ。セキュリティは高いが、実装がAPIキーより複雑になる。

ベーシック認証: ユーザー名とパスワードをBase64エンコードして送る方式。現在はセキュリティ上の理由からほとんど使われないが、レガシーなシステムとの連携で遭遇することがある。

GTMエンジニアとしての判断基準はシンプルだ。社内ツール間の連携であればAPIキー認証で十分なケースが多い。外部パートナーやサードパーティアプリとの連携ではOAuth 2.0を選択する。

レスポンス構造

APIのレスポンスはJSON形式が標準だ。HubSpotのコンタクト取得APIを例にすると、以下のような構造が返される。

{
  "results": [
    {
      "id": "12345",
      "properties": {
        "email": "[email protected]",
        "firstname": "太郎",
        "lastname": "田中",
        "company": "株式会社サンプル"
      },
      "createdAt": "2026-01-15T09:30:00Z",
      "updatedAt": "2026-03-20T14:22:00Z"
    }
  ],
  "paging": {
    "next": {
      "after": "12346"
    }
  }
}

results に実データが入り、paging にページネーション情報が含まれる。大量のデータを取得する際は、この after パラメータを使って次のページを取得するループ処理が必要になる。

HubSpot APIの実践例——コンタクト作成と取引更新

理論を押さえたところで、実際のCRM APIの実装に入る。ここではHubSpotのAPIを例に、GTMエンジニアが日常的に行う操作を見ていこう。

コンタクトの作成

Webフォームからリード情報を受け取り、HubSpotにコンタクトを自動作成する。最も基本的なAPI連携のパターンだ。

curl -X POST https://api.hubapi.com/crm/v3/objects/contacts \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "properties": {
      "email": "[email protected]",
      "firstname": "花子",
      "lastname": "佐藤",
      "company": "株式会社テスト",
      "lifecyclestage": "lead"
    }
  }'

ポイントは lifecyclestage を明示的に設定している点だ。これを省略すると、後のワークフローやスコアリングで不整合が起きる。API経由のデータ投入でも、CRMデータ設計で定めたルールを遵守することが重要である。

取引（ディール）のステージ更新

商談の進捗に応じてディールステージを自動更新する。たとえば、電子署名ツールで契約書が送付されたタイミングで、CRMのステージを「契約送付済み」に変更する。

curl -X PATCH https://api.hubapi.com/crm/v3/objects/deals/{dealId} \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "properties": {
      "dealstage": "contractsent",
      "notes_last_updated": "電子署名送付完了 - API自動更新"
    }
  }'

このようなAPI連携を設計する際の鉄則は、「誰が見てもデータの出所がわかる」状態を維持することだ。notes_last_updated にAPIからの自動更新であることを記録しておけば、営業担当者がCRM上で「なぜこのステージが変わったのか」を追跡できる。

バッチ処理——大量データの一括操作

HubSpotのBatch APIを使えば、1回のリクエストで最大100件のレコードを一括操作できる。月次のデータクレンジングや、イベント参加者リストの一括インポートに有効だ。

curl -X POST https://api.hubapi.com/crm/v3/objects/contacts/batch/create \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": [
      {"properties": {"email": "[email protected]", "firstname": "一郎"}},
      {"properties": {"email": "[email protected]", "firstname": "二郎"}},
      {"properties": {"email": "[email protected]", "firstname": "三郎"}}
    ]
  }'

ただし、バッチ処理でもレートリミット（HubSpotは1アプリあたり秒間10リクエスト）は適用される。大量データを扱う場合は、リクエスト間に適切なウェイトを入れる設計が必要です。

Webhook活用パターン——イベント駆動型の営業プロセス

APIがこちらからデータを取りに行く「プル型」であるのに対し、Webhookはイベント発生時にサーバーから通知が送られる「プッシュ型」の仕組みだ。営業プロセスの自動化において、Webhookはリアルタイム性を担保する重要な技術である。

Webhookの基本的な仕組み

Webhookの動作は3ステップで説明できる。

登録: 通知を受け取るURLを事前に登録する
イベント発生: CRM上で商談ステージが変更される、フォームが送信される等のイベントが起きる
通知送信: 登録されたURLに対してPOSTリクエストでイベントデータが送信される

APIで同じことをやろうとすると、「変更がないか」を定期的にポーリング（確認）しなければならない。1分ごとにGETリクエストを送り続けるのは非効率であり、APIのレートリミットを消費する。Webhookなら変更があったときだけ通知が飛ぶため、リソース効率が格段に良い。

営業プロセスでのWebhook活用例

パターン1: 高スコアリード即時通知

リードスコアが閾値を超えた瞬間にSlackへ通知を飛ばし、営業の初動を最速にする。CRMのワークフローでWebhookをトリガーし、受信サーバーからSlack APIにメッセージを送る構成だ。

パターン2: 契約締結の自動後処理

電子署名の完了イベントをWebhookで検知し、CRMのステージ更新→カスタマーサクセスへのSlack通知→オンボーディングタスクの自動生成を一気に実行する。

パターン3: フォーム送信のリアルタイムCRM登録

Webサイトのフォーム送信をWebhookで受け取り、バリデーション処理後にCRM APIでコンタクト作成→営業担当者の自動アサイン→初回フォローメールのトリガーまでを自動化する。

これらのパターンを設計する際は、Zapier・Make・n8nのようなiPaaSをWebhookの受け口として活用するのが現実的だ。自前でWebhookサーバーを立てる必要はなく、iPaaSのWebhookトリガーで受信し、後続のアクションをノーコードで構築できる。

iPaaS vs カスタムAPI開発——判断基準

GTMエンジニアは、iPaaSで自動化するか、カスタムコードでAPI連携を実装するか、という判断を日常的に求められる。どちらが正解かは「ロジックの複雑性」と「保守体制」の2軸で決まる。

iPaaSが適するケース

ツール間の単純なデータ転送: CRMの新規コンタクトをSlackに通知する等
標準的なワークフロー: リード登録→スコアリング→担当者アサイン→通知の直線的フロー
非エンジニアが保守する: 営業チーム内でワークフローを修正・追加する運用
プロトタイプ段階: まず動くものを作って検証し、本格実装は後から

Zapier・Make・n8nで解説した通り、iPaaSの最大の価値は実装速度だ。数時間で動くワークフローが構築でき、ビジネスサイドのフィードバックを即座に反映できる。

カスタムAPI開発が適するケース

複雑なデータ変換: 複数APIのレスポンスを結合・加工してCRMに投入する
大量データのバッチ処理: 数万件単位のデータ同期でレートリミットの制御が必要
独自ビジネスロジック: 自社固有のスコアリングアルゴリズムやマッチングロジック
高い信頼性要件: 金融データや契約データなど、失敗が許されない処理

カスタム開発の場合、Python（requestsライブラリ）やNode.js（axiosライブラリ）が定番だ。GTMエンジニアがPythonスクリプトでHubSpot APIを叩き、データの変換・バリデーション・エラーハンドリングを細かく制御するパターンは実務上非常に多い。

最適解は「併用」

実際の営業プロセスでは、iPaaSとカスタムAPI開発を併用するのが最も現実的だ。標準的な連携はiPaaSで高速に構築し、iPaaSでは対応しきれない複雑な処理だけをカスタムコードで実装する。この判断を適切に行えること自体が、GTMエンジニアの技術力の指標である。

API連携のセキュリティとエラーハンドリング

API連携を本番環境で運用する以上、セキュリティとエラーハンドリングは避けて通れない。ここを甘く見ると、顧客データの漏洩やデータ不整合という深刻な問題につながる。

セキュリティの基本原則

APIキーの管理: APIキーやアクセストークンをソースコードに直書きしてはならない。環境変数やシークレットマネージャー（AWS Secrets Manager、GCP Secret Manager等）で管理し、Gitリポジトリにコミットされないよう .gitignore に含める。これは初歩的だが、実際に営業ツールのAPIキーがGitHubの公開リポジトリに漏洩する事故は後を絶たない。

最小権限の原則: APIトークンに付与する権限は、必要最低限に絞る。HubSpotのPrivate Appでは、コンタクトの読み取りだけが必要ならコンタクトのReadスコープのみを付与する。全権限を付与したトークンは、漏洩時のリスクが最大化する。

通信の暗号化: API通信は必ずHTTPS経由で行う。HTTPでの通信は中間者攻撃のリスクがあり、認証情報が平文で傍受される可能性がある。現在のSaaS APIはほぼすべてHTTPS必須だが、自社開発のAPIエンドポイントではHTTPを許容する設定になっていないか確認が必要だ。

エラーハンドリングの設計

API連携は「動いて当たり前」ではない。ネットワーク障害、レートリミット超過、認証トークンの期限切れ、APIの仕様変更——さまざまな理由でリクエストは失敗する。堅牢なエラーハンドリングを設計するために、HTTPステータスコードの意味を理解しておく必要がある。

ステータスコード	意味	GTMエンジニアの対処
200	成功	正常処理を続行
201	作成成功	POST成功、作成されたリソースのIDを記録
400	リクエスト不正	リクエストボディのバリデーションエラー。ログを確認して修正
401	認証エラー	トークンの期限切れまたは無効化。再認証が必要
403	権限不足	スコープの見直し
404	リソース未発見	IDの存在確認。削除済みレコードへのアクセスの可能性
429	レートリミット超過	リトライ間隔を空ける（指数バックオフ）
500	サーバーエラー	API提供側の問題。一定時間後にリトライ

特に重要なのが 429（レートリミット超過） への対処だ。HubSpotは秒間10リクエスト、Salesforceは24時間あたりの総リクエスト数に制限がある。リトライの際は指数バックオフ（1秒→2秒→4秒→8秒とリトライ間隔を倍増させる）を実装するのが定石である。

import requests
import time

def api_request_with_retry(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)
        if response.status_code == 200:
            return response.json()
        elif response.status_code == 429:
            wait_time = 2 ** attempt
            time.sleep(wait_time)
        else:
            response.raise_for_status()
    raise Exception("最大リトライ回数に達しました")

このようなリトライロジックを共通関数として用意しておけば、個別のAPI連携ごとに書く必要がなくなる。

モニタリングとアラート

API連携を本番運用する以上、エラーの検知と通知の仕組みが不可欠だ。iPaaSであれば実行ログとエラー通知機能が組み込まれているが、カスタムスクリプトの場合は自前でログ出力とSlack通知を実装する。エラーが発生してから数日後に気づく——という状態は、営業データの欠損を意味する。

まとめ——API連携はGTMエンジニアの「実装言語」

API連携は、GTMエンジニアが営業プロセスの設計を「動くシステム」に変換するための実装言語だ。REST APIの4要素（HTTPメソッド・エンドポイント・認証・レスポンス構造）を押さえれば、HubSpotやSalesforceに限らず、あらゆるSaaS APIを扱える土台ができる。

重要なのは、APIの技術知識だけでは不十分だということだ。CRMデータ設計で定めたデータ構造を前提に、iPaaSとの使い分けを判断し、HubSpotなどの具体的なプラットフォーム上で実装する——この一連の流れを一人で設計・実行できる人材がGTMエンジニアだ。まずは自社で使っているCRMのAPIドキュメントを開き、GETリクエストを1本送ることから始めてみてほしい。

参考文献

HubSpot API Documentation — HubSpot公式APIリファレンス
Salesforce REST API Developer Guide — Salesforce公式REST APIガイド
MDN Web Docs — HTTP メソッド — HTTPメソッドの標準仕様解説
OAuth 2.0 — RFC 6749 — OAuth 2.0認可フレームワークの仕様書
Webhook.site — Webhookのテスト・デバッグツール