開発

スクエアの予約システム「Square 予約」をAPI連携する：料金プランと実装コード【2026年10月】

予約管理システム開発の重要性

スクエアの予約システム「Square 予約」は、Squareの決済と同じアカウントで来店予約を受けられるサービスで、2022年5月に日本で提供が始まりました。この記事では、無料・プラス・プレミアムの3プランで使える機能の差を2026年10月時点の公式ページに基づいて整理する内容です。そのうえで、Bookings APIを使って自社サイトから空き枠を検索し、予約を作り、取り消すまでをcurlのリクエストで示し、予約通知の署名を検証するPythonコードも載せます。キャンセル料を設定したメニューはAPIで予約できないといった、導入後に気づきやすい制約もここで扱います。

まとめ：Square 予約は無料で始め、自社サイトとの連携はBookings APIで組む

1店舗で、スタッフの指名やGoogleカレンダー同期が要らないなら、無料プランで予約サイトとリマインドまで回せます。複数店舗、スタッフ別の空き枠、無断キャンセル対策が必要になった時点で、1店舗あたり月3,000円のプラスへ移るのが基本の流れです。

自社サイトの予約画面からSquareへ予約を入れるなら、Bookings APIを使います。注意すべきは権限の差です。無料プランでも予約は作れますが、アプリが作った予約しか触れません。店舗の全予約を読み書きするにはプラス以上の契約が要ります。キャンセル料を設定したメニューはAPIから予約できないため、無断キャンセル対策とAPI連携を両立したい場合は設計を先に決めてください。基幹システムとの双方向連携や、Square以外の決済を使う予定があるなら、予約部分は自作を検討する段階です。

Square 予約の機能と料金プラン、無料・プラス・プレミアムで変わる範囲

Square 予約は、予約の受付・顧客管理・決済を1つの管理画面で扱えるのが特徴です。プランで変わるのは、店舗数・スタッフ・同期・無断キャンセル対策の4点にほぼ集約されます。

無料・月3,000円・月8,000円の3プランで使える機能の比較表と読み方

Square 予約の料金プランのページを2026年10月27日に確認した内容をまとめました。料金は1店舗あたりの月額です。

機能 無料 プラス プレミアム
月額（1店舗） 0円 3,000円 8,000円
店舗数 1店舗のみ 複数可 複数可
自動リマインド あり あり あり
事前決済 あり あり あり
複数スタッフの予約 なし あり あり
Googleカレンダー同期 なし あり あり
無断キャンセル対策 なし あり あり
リソース管理 なし なし あり

無料プランは1つのSquareアカウントにつき1店舗に限られます。プラスとプレミアムの差は、施術台や個室といったリソースの管理と、勤怠やシフト、人件費率のレポートを含むスタッフ管理です。個室の数が予約の上限を決める業態でなければ、プラスで足ります。2022年5月10日の提供開始時のプレスリリースでも同じ3プランと月額が示されており、提供開始時と2026年10月の料金は同額です。

予約と決済が同じアカウントで回る利点と、事前決済3.6%の手数料条件

Square 予約の強みは、予約と決済の売上・顧客情報が同じアカウントに入ることです。来店時にSquareの端末で決済すれば、予約した顧客の来店履歴と支払いがひもづいたまま残ります。

オンラインの事前決済は全プランで使え、料金ページではクレジットカード・Apple Pay・Google Payの決済手数料は3.6%です。カード情報の手入力や保存済みカードでの決済は3.75%で、無断キャンセル料の請求もこちらに含まれます。対面決済の料率と入金サイクルはSquare決済とは？手数料・入金サイクルとPOS・EC連携の判断軸を解説で整理しています。手数料の違いが効くのは、事前決済の比率が高い業態です。

Bookings APIで自社サイトから予約を受ける構成と、使う5つのAPIの役割

Square 予約の予約サイトをそのまま使うなら、開発は要りません。自社サイトの画面やアプリから予約を入れたい場合に、Bookings APIの出番になります。Squareの開発者ブログによると、Bookings APIは2022年5月12日に一般提供となり、日本の開発者も使えます。

拠点・スタッフ・メニュー・顧客・予約を5つのAPIに分けて扱う設計

Bookings APIの概要ページは、予約アプリを次のAPIの組み合わせで作る構成を示しています。予約そのものを扱うのはBookings APIだけで、残りは予約に必要なIDを引くために使います。

  • Locations API：予約を受ける店舗（location_id）
  • Team API：施術や対応をするスタッフ（team_member_id）
  • Catalog API：予約できるメニュー（商品種別がAPPOINTMENTS_SERVICEの商品のバリエーション）
  • Customers API：予約する顧客（customer_id）
  • Bookings API：空き枠の検索、予約の作成・変更・取消

メニューは商品本体ではなくバリエーションのIDで指定します。同じ「カット」でも、60分と90分を別のバリエーションとして登録する作りです。API認証の流れ、OAuthとアクセストークンの違いはSquare APIとは？決済統合の仕組み・実装フロー・Stripe/PAY.JPとの選び分けを開発視点で解説で扱っているため、本記事では予約に関わる部分に絞ります。

購入者レベルと販売者レベルの権限差、無料プランで書き込める範囲

Bookings APIには、購入者レベルと販売者レベルの2種類の権限があります。設計を左右するのは、どちらで呼ぶかです。

項目 購入者レベル 販売者レベル
見える予約 アプリが作った予約 店舗の全予約
営業時間外の予約 作れない 作れる
書き込みの契約条件 無料プランでも可 プラス以上
書き込みのスコープ APPOINTMENTS_WRITE 左記とALL_WRITE

概要ページによると、販売者レベルの作成・変更・取消はプラスかプレミアムの契約が前提で、無料プランのまま呼ぶと403と「Merchant subscription does not support write operations」が返ります。契約は店舗単位で、有効な全店舗に同じプラン料金がかかる仕組みです。スコープの一覧はOAuth Permissions Referenceで確認できます。自社サイトから新規予約を入れるだけなら購入者レベルで足り、電話や店頭で入った予約まで自社システムに取り込みたいなら販売者レベルが要る、と覚えておけば判断を誤りません。

Sandboxで空き枠を検索して予約を作る、curlで試す3つのリクエスト

ここからは、Squareの開発者コンソールで作ったアプリのSandbox用アクセストークンで試す手順です。ヘッダーのSquare-Versionは、APIリファレンスの例と同じ2026-09-16にそろえています。

Sandboxの接続先と、予約できるスタッフとメニューのIDを調べる手順

Sandboxの解説のとおり、接続先は本番のconnect.squareup.comではなくconnect.squareupsandbox.comです。テスト用ダッシュボードは本番の一部の機能しか持たず、予約サイトのURLは表示されません。画面での確認ではなく、APIの応答で確かめる前提で進めます。

export SQ=https://connect.squareupsandbox.com
export TOKEN=<Sandboxのアクセストークン>

# 予約の受付設定（booking_enabled やキャンセル可否）を確認する
curl -s "$SQ/v2/bookings/business-booking-profile" \
  -H "Square-Version: 2026-09-16" -H "Authorization: Bearer $TOKEN"

# 予約を受けられるスタッフだけを一覧する
curl -s "$SQ/v2/bookings/team-member-booking-profiles?bookable_only=true" \
  -H "Square-Version: 2026-09-16" -H "Authorization: Bearer $TOKEN"

# 予約メニュー（APPOINTMENTS_SERVICE）を探し、バリエーションIDとversionを控える
curl -s -X POST "$SQ/v2/catalog/search-catalog-items" \
  -H "Square-Version: 2026-09-16" -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_types":["APPOINTMENTS_SERVICE"]}'

3つ目の応答に含まれるitem_variation_dataのavailable_for_bookingがtrueのバリエーションだけが予約できます。そのIDとversionの値を、次の空き枠検索と予約作成で使います。

空き枠検索の範囲は24時間以上31日以内、担当スタッフを絞る指定方法

空き枠は/v2/bookings/availability/searchで引きます。Create and Manage Bookingsによると、検索範囲は24時間以上かつ31日以内でなければなりません。1か月分のカレンダーを一度に描く画面は、31日で区切って複数回呼ぶ作りにします。

curl -s -X POST "$SQ/v2/bookings/availability/search" \
  -H "Square-Version: 2026-09-16" -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "filter": {
        "start_at_range": {
          "start_at": "2026-11-05T00:00:00Z",
          "end_at": "2026-11-06T00:00:00Z"
        },
        "location_id": "<LOCATION_ID>",
        "segment_filters": [{
          "service_variation_id": "<SERVICE_VARIATION_ID>",
          "team_member_id_filter": { "any": ["<TEAM_MEMBER_ID>"] }
        }]
      }
    }
  }'

時刻はUTCで渡します。上の例は日本時間の11月5日9時から翌6日9時までです。応答のavailabilitiesには、開始時刻と担当スタッフ、メニューの所要時間を持つ枠が並ぶ形式です。search-availabilityのリファレンスの例では、スタッフの絞り込みにanyで複数のIDを渡しています。指名なしの予約なら、予約できる全スタッフのIDをanyに並べます。

予約作成に冪等キーとメニューの版番号を入れ、取消は版の一致で通す

空き枠の応答から1つを選び、同じ値で予約を作ります。create-bookingのリファレンスで必須なのは、location_id・start_atと、各区間のteam_member_id・service_variation_id・service_variation_versionです。

# 予約を作る。通信が切れて再送しても二重予約にならないよう冪等キーを付ける
curl -s -X POST "$SQ/v2/bookings" \
  -H "Square-Version: 2026-09-16" -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "idempotency_key": "'"$(uuidgen)"'",
    "booking": {
      "location_id": "<LOCATION_ID>",
      "start_at": "2026-11-05T01:00:00Z",
      "customer_id": "<CUSTOMER_ID>",
      "appointment_segments": [{
        "team_member_id": "<TEAM_MEMBER_ID>",
        "service_variation_id": "<SERVICE_VARIATION_ID>",
        "service_variation_version": 1613077495453,
        "duration_minutes": 60
      }]
    }
  }'

# 予約を取り消す。booking_version は予約の現在の version と一致させる
curl -s -X POST "$SQ/v2/bookings/<BOOKING_ID>/cancel" \
  -H "Square-Version: 2026-09-16" -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"idempotency_key": "'"$(uuidgen)"'", "booking_version": 0}'

冪等キーは、ブラウザの再送やタイムアウト後の再試行で同じ予約が2件できるのを防ぎます。メニューのservice_variation_versionは、管理画面でメニューの料金や所要時間を直すと変わるため、古い値を画面に持ち続けると予約が失敗します。予約の変更と取消は、予約のversionを使った楽観ロックです。他の操作で予約が先に更新されていれば、送った版が古いのでエラーが返ります。そのときは予約を取り直してから操作し直してください。

予約の通知をWebhookで受け、署名を検証して自社システムへ反映する実装

Square 予約の管理画面や店頭で予約が変わったとき、自社システムに反映するにはWebhookを使います。一定間隔で予約一覧を取りに行く方式より、変更の取りこぼしと無駄な呼び出しが減ります。

booking.createdとbooking.updatedの通知対象と未通知分の扱い

予約の通知はbooking.createdとbooking.updatedの2種類です。booking.createdのリファレンスでは、通知のdata.object.bookingに予約ID・状態・開始時刻・version・区間・顧客IDが入っています。購読にはAPPOINTMENTS_READ、販売者レベルではさらにAPPOINTMENTS_ALL_READのスコープが必要です。

見落としやすいのは、概要ページの制約の欄にある記述です。アプリが通知を受けられるのは、そのアプリが作った予約か、APIで作られたあとに更新された予約に限られます。管理画面や店頭で入った予約を確実に取り込みたい場合は、通知だけに頼らず、販売者レベルの権限で予約一覧を定期的に照合する処理を併せて置きます。

PythonのSDKで署名を検証し、偽の通知を403で捨てる受信コード

通知の検証手順では、x-square-hmacsha256-signatureヘッダーの値を、署名キー・通知URL・受け取った本文から作ったHMAC-SHA-256と照合し、一致しなければ403を返すよう求めています。SquareのPython SDKは、この照合をverify_signature関数として持っています。PyPIのsquareup 46.0.0.20260916（2026年9月15日公開）で動かす前提のコードです。

# pip install squareup flask
import json
import os

from flask import Flask, abort, request
from square.utils.webhooks_helper import verify_signature

app = Flask(__name__)
SIGNATURE_KEY = os.environ["SQUARE_WEBHOOK_SIGNATURE_KEY"]
# 開発者コンソールに登録した通知URLと1文字も違わない値にする
NOTIFICATION_URL = "https://example.com/square/webhook"
processed = set()  # 本番はDBの一意制約で持つ


def save_booking(booking_id, version, status, start_at):
    # 自社DBの version より新しい通知だけを反映する
    print(booking_id, version, status, start_at)


@app.post("/square/webhook")
def square_webhook():
    body = request.get_data(as_text=True)  # 加工前の本文で検証する
    signature = request.headers.get("x-square-hmacsha256-signature", "")
    if not verify_signature(
        request_body=body,
        signature_header=signature,
        signature_key=SIGNATURE_KEY,
        notification_url=NOTIFICATION_URL,
    ):
        abort(403)

    event = json.loads(body)
    if event["event_id"] in processed:
        return "", 200
    processed.add(event["event_id"])

    booking = event["data"]["object"]["booking"]
    save_booking(booking["id"], booking["version"], booking["status"], booking["start_at"])
    return "", 200

署名が合わない原因で多いのは2つです。1つは、JSONを読み込んでから文字列に戻した本文で検証してしまうこと。キーの順や空白が変わるため、必ず受け取ったままの本文を渡します。もう1つは、リバースプロキシの内側で受けて、通知URLのホスト名やスラッシュの有無が登録値とずれることです。SDKの実装は比較にhmac.compare_digestを使っており、手書きで照合するより安全に済みます。

Bookings APIで詰まる3つの制約、キャンセル料・電話番号・スタッフ割当

どれもリファレンスに書かれていますが、管理画面の設定と組み合わさって初めて表に出る制約です。設計の段階で確認しておくと、手戻りを防げます。

キャンセル料を設定したメニューはAPIから予約できない制約と回避策

Create and Manage Bookingsには、キャンセル料（no_show_fee）が0でないメニューはBookings APIで予約できないと書かれています。プラス以上の無断キャンセル対策でキャンセル料を設定すると、自社サイトからの予約だけが通らなくなるわけです。

回避するには、API経由で受けるメニューのキャンセル料を0にし、自社サイト側で事前決済やカード登録を受ける設計にするか、キャンセル料が必要なメニューだけSquareの予約サイトへ誘導します。前払いの扱いも注意が必要な点です。同じページに、デポジットが支払われた予約は区間（日時やメニュー）を変更できないとあり、日時変更は取消と再予約で組むことになります。

顧客の電話番号必須と、スタッフ割当はダッシュボードでしか変えられない点

予約する顧客には電話番号が必要です。電話番号の無い顧客で予約を作ると400が返ります。メールアドレスだけで会員登録できる自社サイトなら、予約フォームで電話番号を必須にし、Customers APIで顧客を作る段階で入れておきます。

スタッフとメニューのひもづけは、APIから変えられません。概要ページによると、あるスタッフをあるメニューで予約可能にするには、Squareのダッシュボードでそのスタッフをメニューに追加する必要があり、外部の開発者はAPIで変更できないとされています。スタッフの入れ替わりが多い店舗では、ダッシュボードの設定が運用手順の一部になります。

Square 予約のまま使うか、API連携か、予約システムを自作するかの判断基準

選択肢は3つです。Square 予約の予約サイトをそのまま使う、Bookings APIで自社サイトとつなぐ、予約システムを自作する。決め手は、決済をSquareで受け続けるかと、予約データを誰が持つかにあります。

標準機能とAPI連携で足りる条件と、Square 予約を選ばない場面

決済をSquareで受けていて、予約が1つの時間枠に1人の来店で完結するなら、Square 予約の標準機能で足ります。自社サイトの見た目に合わせた予約画面が欲しい、会員情報と予約をひもづけたいという段階が、Bookings APIの購入者レベルを使った連携に進む目安です。WordPressのサイトに予約を足す方法を比べる場合は、WordPressで予約システムを作る：プラグイン比較とカスタム投稿型・排他制御の実装も参考になります。

次のどれかに当てはまるなら、Square 予約は選びません。決済代行をすでにStripeなど別の会社と契約していて、Squareに切り替える予定が無い。LINEから予約を受けることが主な導線になっている（料金ページと公式ガイドに挙がる連携先はInstagram・Facebook・Google）。1回の予約で複数の部屋や機材を同時に押さえる必要があり、プレミアムのリソース管理でも表しきれない。この場合、Squareの制約に合わせて業務を曲げるほうが高くつきます。

基幹システムとの双方向連携や決済の変更で、予約システムを自作する目安

自作を検討するのは、予約を基幹システムや在庫、顧客台帳と双方向でつなぐときです。販売者レベルのAPIでも、スタッフとメニューのひもづけは画面でしか変えられず、キャンセル料メニューはAPIで扱えません。こうした制約を回避する処理が増えてきたら、予約の台帳を自社側に持つ構成へ移る合図です。自作する場合の設計と技術選定は予約システム開発の進め方｜自作の設計・技術選定・必須機能と費用を解説で、既製サービスを改修で延命するか作り直すかの線引きは予約管理システムのカスタマイズ｜直せる範囲を4段階に分けて改修と開発を決めるで扱っています。

Squareの決済は残し、予約の台帳と画面だけを自社で作る構成も取れます。決済はSquare APIで受け、予約の確定と空き枠の管理を自社のデータベースで行う形です。どこまでをSquareに任せるかの整理から相談したい場合は、一創の予約管理システム開発で、Square 予約から移行する構成も含めて提案しています。

よくある質問

スクエアの予約システムを導入・連携するときに、検討段階でよく出る質問をまとめました。

Square 予約は無料で使えますか？

使えます。無料プランは月額0円で、予約サイトの作成、自動リマインド、事前決済まで利用できます。制限は1つのSquareアカウントにつき1店舗であることと、複数スタッフの予約・Googleカレンダー同期・無断キャンセル対策が使えないことです。決済した場合は、オンラインのカード決済で3.6%の手数料がかかります。契約期間の縛りは無く、必要になった時点でプラスへ切り替えられます。

Square 予約とGoogleカレンダーは連携できますか？

プラスとプレミアムのプランで連携できます。無料プランでは使えません。料金ページの機能表で、Googleカレンダー同期はプラス以上の機能として記載されています。スタッフが個人のGoogleカレンダーで予定を管理している店舗なら、同期のためだけにプラスへ移る価値があります。Googleの検索結果から予約を受ける機能とは別物なので、混同しないよう注意してください。

Square 予約をLINEから受け付けられますか？

料金ページと公式の使い方ガイドに挙がっている連携先はInstagram・Facebook・Googleで、LINEは記載されていません。LINEのトーク画面から予約サイトのURLを案内することはできますが、LINEの中で予約を完結させるには別の仕組みが要ります。方式の比較は予約管理システムのLINE連携｜4つの実装方式と通知コストで決める選び方を参照してください。

Bookings APIの日本語ドキュメントや日本での提供状況はどうなっていますか？

Bookings APIは2022年5月12日に一般提供となり、米国・英国・カナダ・オーストラリア・スペインと並んで日本の開発者も使えます。ただし2026年10月時点で、Bookings APIの解説とリファレンスは英語版の参照が前提です。エンドポイント名やフィールド名は英語のままなので、本記事のcurlの例と英語版のリファレンスを並べて読むと迷いません。

APIで作った予約はSquare 予約の管理画面にも表示されますか？

表示されます。Bookings APIで作った予約は、Square 予約の予約と同じ台帳に入るため、スタッフは管理画面や端末のアプリで確認できます。逆方向は条件付きです。管理画面で入った予約をアプリが読むには販売者レベルの読み取り権限が必要で、Webhookの通知はアプリが作った予約などに限られます。店頭の予約まで自社システムに取り込むなら、定期的な照合処理も用意してください。

関連記事

お気に入りに入れた記事の一覧

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.23　テックブログ Renta!はいつ再開？不正アクセスでメールアドレス等が流出したおそれ・再開時のパスワード再設定と運営側の対応
  2. 2026.07.09　テックブログ Muse Imageとは？Metaの画像生成AIの使い方・API料金（1枚0.01ドル）と日本での提供状況【2026年10月】
  3. 2026.10.23　テックブログ Splunk 脆弱性CVE-2026-76299：影響版の確認と10.2.8などへの更新手順
  4. 2026.10.22　テックブログ Tomcatのバージョン一覧とサポート期限【2026年10月】最新版11.0.27、9.0系は2027年3月末終了・9.1系は2030年末まで
  5. 2026.10.21　テックブログ ユミルリンク不正アクセス第二報で延べ5,162万件：Cuenote FC利用企業と受信者の確認点

RELATED POSTS 関連記事

一覧へ戻る

目次