独立サイトのAPI連携：REST API、Webhook、外部システムとの接続方法
1. WordPress REST API：まず標準機能を理解する
WordPressは4.7以降、REST APIを標準搭載しており、プラグインなしで使えます。エンドポイントの形式は https://あなたのドメイン/wp-json/wp/v2/posts で、ブラウザで直接開けばJSON形式の記事一覧が表示されます。このAPIは標準で公開されており、誰でもあなたの記事、ページ、メディアライブラリを読み取れます。これは利点（連携が簡単）であると同時にリスク（内部データの露出）でもあります。
書き込み操作（記事の新規作成、注文の変更、ユーザーの追加）には認証が必要です。WordPressは2つの認証方式に対応しています。アプリケーションパスワード（Application Passwords、シンプル。ユーザープロフィール画面で生成でき、自社サーバーからの呼び出しに適する）とOAuth 2.0（複雑。サードパーティアプリの認可に適する）です。独立サイトを自社のCRMと連携するならアプリケーションパスワードで十分です。簡単だからといって、adminアカウントのパスワードをコードに直書きしないでください。
判断の枠組み：WordPressからデータを読み取るのか、書き込むのか。読み取りのみ（記事一覧や注文履歴の取得）なら、GETリクエストとアプリケーションパスワードで足ります。書き込み（注文の作成、ユーザーの更新、Webhookの送信）ならPOST/PUTリクエストが必要で、権限範囲は最小限にしてください。たとえば「注文の編集」権限だけを与え、「すべての設定の管理」権限は与えないこと。技術スタックの組み方は、こちらをご覧ください環形山テックスタック。
| エンドポイント | 方法 | 用途 | 認証要件 |
|---|---|---|---|
| /wp-json/wp/v2/posts | GET | 記事一覧を取得 | 公開（公開済み） |
| /wp-json/wp/v2/posts | POST | 記事を新規作成 | アプリケーションパスワード |
| /wp-json/wc/v3/orders | GET | WooCommerceの注文を取得 | コンシューマーキー |
| /wp-json/wc/v3/orders | POST | 注文を新規作成 | コンシューマーキー |
| /wp-json/wp/v2/users | GET | ユーザー一覧を取得 | 管理者パスワード |
| /wp-json/wp/v2/media | POST | 画像をアップロード | 上記のパスワードを編集 |
2. Webhook：イベント駆動のリアルタイム通知
Webhook と REST API の違いは、データの流れる向きが逆だという点です。REST は自分から相手のサーバーへデータを取りに行く方式で、Webhook はイベントが起きたときに相手のサーバーから自分のところへデータを push してくる方式です。たとえば WooCommerce で新しい注文が入ると、Webhook の設定に入力した URL へ POST リクエストを送り、body に注文詳細の JSON が入っています。毎分ポーリングして「新しい注文はないか」と確認する必要はなく、注文が入った時点で自動的に push されてきます。
WooCommerce は Webhook を標準でサポートしています。WooCommerce → 設定 → 詳細設定 → Webhooks から追加します。入力が必要な項目は次のとおりです。トリガーイベント（注文の作成、注文の更新、注文のキャンセル）、受信 URL（自分のサーバー上のエンドポイント。例: https://your-domain/wp-json/custom/v1/new-order）、署名方式（HMAC-SHA256。シークレットキーで、リクエストが本当に WooCommerce から来たもので、他人による偽造ではないことを検証します）。
直感に反する判断：Webhook の push が失敗しても、自分の側ではほとんど気づけません。WooCommerce が Webhook を push したときにサーバーが 500 を返すと、数回リトライします（デフォルトで最大 5 回、間隔は徐々に広がります）。しかし 5 回すべて失敗すると、そこで諦めてしまいます。自分の側ではデータを受け取れないうえ、アラートも一切ありません。だからこそ重要なデータを Webhook だけに任せてはいけません。定期取得によるフォールバックが必須です。CRM との連携方法は独立系サイトの CRM 連携。
| イベント | WooCommerceフック | push 先 | 優先度 |
|---|---|---|---|
| 新規注文の作成 | woocommerce_order_created | CRM + Slack通知 | 最高 |
| 注文ステータスの変更 | woocommerce_order_status_changed | 顧客へのメール + CRM 更新 | 高 |
| 決済成功 | woocommerce_payment_complete | 会員システムのアップグレード | 高 |
| 返金の開始 | woocommerce_order_refunded | CRM への記録 + 経理への通知 | 中 |
| 新規ユーザー登録 | user_register | メールマーケティングのリスト | 中 |
| 商品の公開/非公開 | woocommerce_product_set_visibility | 在庫システムの同期 | 低 |
三、REST による定期取得: 突合のフォールバック
Webhook は秒単位のリアルタイム通知を担いますが、そこに定期取得の層を必ず足して突合します。やり方は簡単です。WP-Cron のスクリプトを書いて 1 時間に 1 回実行し、WooCommerce REST API を呼んで直近 1 時間に作成または更新された注文を取得し、自分のデータベースにある注文と突き合わせます。Webhook が取りこぼした注文（Webhook の push 時にサーバーが 502 を返した場合など）があれば、定期取得が補完します。
定期取得のクエリパラメータにはタイムスタンプを付けます。たとえば GET /wp-json/wc/v3/orders?after=2026-09-21T10:00:00&per_page=100 は、10 時以降のすべての注文を 1 ページ 100 件で返します。100 件返ってきたら、まだ続きがある可能性が高いのでページをめくって取得を続けます。取得後は注文 ID で重複を排除し、すでにデータベースにあるものはスキップし、ないものだけを挿入します。これが最もシンプルな突合ロジックです。
シナリオ例：水曜午後3時にサーバーのSSL証明書が期限切れで525を返し、40分間続きました。この間、新規注文3件のWebhookがすべて失敗。Webhookだけならこの3件は失われます。しかし毎時ポーリングを設定しておけば、4時の実行で漏れた3件を補完し、顧客に確認メールが届きます。監視の設定方法はこちらサイト監視とアラート。
| 同期方式 | 頻度 | 遅延 | 失敗時の対応 |
|---|---|---|---|
| Webhookプッシュ | イベントトリガー | 秒単位 | 相手が5回リトライして諦める |
| 毎時ポーリング | 毎時0分 | 分単位 | 失敗したら次回自動リトライ |
| 毎日全件照合 | 毎日午前3時 | 日単位 | 差分レポートを生成し人が確認 |
| リアルタイムWebSocket | リアルタイム | ミリ秒単位 | 切断されたら再接続が必要 |
四、認証とセキュリティ：Keyはバックエンドに、リクエストは署名検証
API連携で最もよくあるセキュリティミスは、API KeyをフロントエンドのJavaScriptに書いてしまうことです。誰でもブラウザでF12 → Networkタブを開けばあなたのKeyが見え、それを使ってAPIを自由に呼べてしまいます。正しい方法は、フロントエンドは自分のサーバーのエンドポイントだけを呼び、サーバーがバックエンドでAPI Keyを付けて第三者へ転送する構成です。このバックエンドプロキシは、WordPressのカスタムRESTエンドポイントでも、簡単なNode.js/Pythonサービスでも構いません。
Webhookを受け取るときは必ず署名を検証します。WooCommerceがWebhookを送る際、HTTP HeaderにX-WC-Webhook-Signatureを付けます。これはあなたのWebhook SecretでbodyをHMAC-SHA256署名したものです。受け取り側で同じ署名を計算し、Headerの値と一致すれば処理します。一致しなければ誰かが偽造したリクエストなので、そのまま403を返します。検証しない場合、誰でもあなたのエンドポイントに偽の注文をPOSTでき、CRMにゴミのようなリードが大量に発生します。
シナリオ例：HubSpot Webhookを連携していて、誰かがあなたの受け取りURLを知り、偽の「新規リード」POSTリクエストを作成しました。署名検証がなければこの偽リードがHubSpotに入り、営業が半日フォローしてから偽物だと気づきます。HMAC検証を追加すれば、HubSpotのリクエストは正しい署名を持ち、偽リクエストは署名が合わず403でブロックされます。CRM連携の詳細はこちら独立系サイトの CRM 連携。
| セキュリティ項目 | 誤ったやり方 | 正しい方法 |
|---|---|---|
| API Keyの場所 | フロントエンドJSに記述 | サーバーの環境変数に保存 |
| リクエストプロキシ | フロントエンドから第三者APIを直接呼ぶ | フロントエンドは自分のサーバーを呼び、バックエンドが転送 |
| Webhook署名検証 | 検証せず、受信したら処理 | HMAC-SHA256でHeaderと比較 |
| HTTPS | HTTPでWebhookを受信 | HTTPS必須、TLS 1.2以上 |
| IPホワイトリスト | 送信元IPを制限しない | 第三者の公式IPレンジでホワイトリスト |
| エラーログ | 失敗しても記録しない | すべての非2xxレスポンスをログ記録 |
五、よくある第三者連携一覧
独立サイトでよく使う外部連携は5種類あります。CRM（HubSpot、Salesforce、Zoho）、メール配信（Mailchimp、ConvertKit、Klaviyo）、決済ゲートウェイ（Stripe、PayPal）、分析ツール（Google Analytics 4、Hotjar）、チャットサポート（Intercom、Zendesk）です。連携方法はそれぞれ違いますが、原則は同じです。Webhook でできるものは Webhook でリアルタイムに連携し、重要なデータは定期取得も組み合わせて取りこぼしを防ぎます。
まず自分でコードを書いて連携しようと考えないでください。WordPress のプラグインディレクトリに既成プラグインがないか探しましょう。HubSpot には公式プラグイン、Mailchimp には公式プラグイン、Stripe には WooCommerce 公式拡張があります。既成プラグインで8割のケースはカバーでき、残りの2割（カスタムフィールドのマッピングなど）は Webhook やカスタムコードで補います。2つのシステムを自分でコードでつなぐと、デバッグに20時間以上かかるのが普通ですが、既成プラグインなら1時間で完了します。CRM プラグインの選び方はこちらをご覧ください。サイトのリードから CRM へ。
| システムの種類 | 推奨プラン | 連携方法 | 想定工数 |
|---|---|---|---|
| CRM（HubSpot） | 公式プラグイン + Webhook | プラグインが自動同期 | 2〜4時間 |
| メール配信（Mailchimp） | 公式プラグイン | ユーザー登録でリストに自動追加 | 1〜2時間 |
| 決済（Stripe） | WooCommerce 公式拡張 | Webhook で注文ステータスを同期 | 1〜2時間 |
| 分析（GA4） | Site Kit by Google プラグイン | フロント側で自動計測 | 30分 |
| チャットサポート（Intercom） | 公式チャットプラグイン | フロント側のコードスニペット | 30分 |
| カスタム ERP | 自分で REST 連携を実装 | 定期取得 + Webhook | 20時間以上 |
FAQ よくある質問
REST API と Webhook は何が違う？どちらが優れている？
WordPress の REST API はプラグインが必要？
API Key はどこに置くべき？フロント側で使える？
Webhook の受信側でリクエストが本物かどうかを検証するには？
Webhook の送信が失敗したらどうなる？
第三者システムとの連携は既成プラグインを使うべきか、自分で書くべきか？
最後に
API 連携は複雑であるほど良いのではなく、信頼できるほど良いのです。目標はただ 1 つ、データを失わない、状態を間違えない、問題が起きたら調べられること。Webhook は速いが信頼性が低く、REST は遅いが制御しやすい。この 2 つを重ねて初めて本番レベルの仕組みになります。どちらか片方だけでは、いつか必ずデータを失います。
実装は 3 ステップです。重要な連携は Webhook でリアルタイム通知し、受信側で HMAC 検証を追加します。1 時間ごとの定期 REST 取得を追加して突合し、Webhook が取りこぼした分を自動で補います。すべての API Key はバックエンドの環境変数に置き、フロントエンドは自分のサーバーのプロキシエンドポイントだけを呼びます。
覚えておきたい一言。Webhookは「即時通知」、RESTは「定期照合」。通知だけに頼って照合をしないのは、チャイムの音だけ聞いて宅配ボックスを確認しないのと同じです。