Make.com で都内コワーキング予約→決済→入退室を月¥1,500で自動化 管理工数を週8時間削減

都内のコワーキングスペースは「会議室・個室ブース・1日席」 と席種が分かれ、Web 予約・現地決済・入退室通知・月次レポートが運営者の手作業に積み上がりがちです。Make.com の Core プラン (約¥1,500/月) を中核に、Stripe / Square 決済 + Google Calendar + Slack / Discord + Airtable 顧客 DB を 1 本のシナリオで束ねれば、1〜3 拠点規模なら週8時間の管理工数が圧縮できる試算です。本記事は編集部が設計した 90 分セットアップのレシピです。

• 会議室 / 個室ブース / 1日席 の 3 席種を 1 つの Make シナリオで予約 → 決済 → 通知まで自動制御
• 決済は Stripe (オンライン事前決済) と Square (現地カード決済) を席種ごとに使い分け
• 入退室通知は NFC タグ / QR コード / Slack コマンド の 3 パターンを併用可、拠点の物理設備に合わせて選べる
• 月次レポートは Airtable の集計ビュー → Make → Google Sheets / PDF で 毎月 1 日に自動生成
• 月¥1,500 (Make Core プラン) で、1〜3 拠点 / 月300予約程度までまかなえる編集部試算
• 失敗パターン (席種を 1 シナリオに詰め込む / Stripe Webhook の冪等性無視 / 拠点間 ID 衝突) を事前に整理

なぜコワーキング運営は「予約・決済・入退室・レポート」 を別ツールで回しがちなのか

都内のコワーキングは席単価が低く、運営者一人あたりの管理対象が広い構造です。会議室はビジネス利用で 時間単位の事前決済 が多く、1日席は ドロップインで現地決済、個室ブースは 月額会員のサブスク ── 1 拠点でも料金体系が 3-4 通り並ぶことは珍しくありません。

このうち 予約 → 顧客 DB 転記、決済消込、入退室通知、月次集計 はすべて機械化できる領域で、合計の 約 35-40% を占めます。1〜3 拠点規模なら 週8時間 (月32時間) の自動化余地があり、Make.com で 1 本のシナリオに束ねるのが現実的解です。

時給¥2,500 の店長代行換算で月¥80,000、年間¥960,000 規模の人件費圧縮に相当します。Make Core プラン (約¥1,500/月) を差し引いても、年間¥942,000 が手元に戻る試算です。

続いて、編集部が設計した全体像を ProcessFlow で示します。

完成形のフロー (ProcessFlow)

ポイントは Step 02 の Router 分岐を最上流に置く ことです。席種ごとに決済・通知・カレンダーの動きが変わるため、最初に分岐させると以降のモジュール構成が席種別に独立し、片方を変更してももう片方が壊れない設計になります。

次セクションでは、このフローを動かす最低限のツール構成を整理します。

必要なツール (1〜3 拠点コワーキング向け最小構成)

固定費合計の目安: 月 約 ¥1,500-4,800 (Make Core + Airtable Team 1 席運用が現実的下限)。Slack / Google Workspace を無料枠で運用し、決済手数料を別費目とすれば、Make + Airtable で月¥4,800 程度から始められる 試算です。

補足: 決済手数料 (Stripe / Square 共に 3.25-3.6% 帯) は 売上に対する変動費 で月額固定費とは別計算です。月売上¥500,000 の拠点なら月の決済手数料は約¥16,000-18,000 になります。詳細は Stripe Pricing / Square 手数料 を参照してください。

オペレーション消費の試算: 1 予約あたり Make モジュール 10-14 個 (Webhook 受信 / Router 分岐 / Stripe または Square API / Calendar 登録 / Airtable 追加 / Slack 通知 / 例外処理) を通過します。月150予約で 1,500-2,100 オペレーション、月300予約で 3,000-4,200 オペレーション となり、Core プラン (10,000 オペレーション/月) の範囲に収まります。

編集部の判断: 1〜3 拠点・月300予約までは Core プランで足ります。月500予約を超えてくる規模になったら Pro プラン (約¥2,500/月) への切り替えを検討してください。

続いて、実装手順を TimelineSteps で示します。

設定手順 (約90分)

Step 1: Airtable 顧客 DB と席種マスタを作成 (15分)

Airtable で Base を新規作成し、以下 4 テーブルを準備します。

拠点 ID と席種 ID は 拠点A会議室=A-MR / 拠点B個室=B-PB のように 拠点記号 + 席種記号 で衝突しない命名を採用してください。複数拠点運用で同名席が衝突するのが最も多い事故の一つです。

Step 2: Stripe Payment Link テンプレと Square 予約 API キーを準備 (15分)

2-1: Stripe Payment Link (会議室・サブスク用)

Stripe ダッシュボード → Payment Links で席種別に Payment Link を作成します。

1. 新規 Payment Link → 商品名「拠点A 会議室 (1時間)」 → 単価 ¥1,500 を入力
2. 支払い後の挙動 → 自社サイトのサンクスページに ?session_id={CHECKOUT_SESSION_ID} を付けてリダイレクト
3. Webhook → Stripe ダッシュボードの Developers → Webhooks で checkout.session.completed イベントを Make の Webhook URL に飛ばす設定を追加

同様に「個室ブース 月額サブスク (¥10,000/月)」 用の Payment Link も作成しておきます。

2-2: Square アクセストークン (1日席・現地決済用)

Square Developer Portal で Application を新規作成し、Production アクセストークンを取得します。1日席のドロップイン現地決済は Square Reader (iPad/iPhone 接続) で都度決済し、その決済 ID を Make 側で Airtable に紐付ける運用が現実的です。

Square は Payments API の payments.created Webhook を Make に飛ばすことで、現地決済の完了を自動検知できます。詳細は Square Developer Portal (日本語) の Webhooks セクションを参照してください。

Step 3: Google Calendar の拠点別カレンダーを作成 (10分)

Google Calendar で席種ごとにカレンダーを分けます。1 拠点 3 席種なら 3 カレンダー / 拠点、3 拠点なら 9 カレンダーが標準構成です。

1. Google Calendar 左サイドバー → 他のカレンダー → 新しいカレンダーを作成
2. 名前: 「拠点A 会議室」 → 作成
3. カレンダー設定 → マイカレンダーの統合 から カレンダー ID (xxxxx@group.calendar.google.com) を控える
4. 特定のユーザーとの共有 で Make 用 Google アカウントに「予定の変更権限」 を付与

カレンダー ID は Step 1 で作った「拠点マスタ」 テーブルの該当列に格納しておきます。Make 側からは Airtable Lookup で拠点 ID → カレンダー ID を引き当てる設計です。

Step 4: Make シナリオ本体 (Webhook → Router 分岐) を構築 (15分)

Make.com で新規シナリオを作成します。

1. 最初のモジュールに Webhooks → Custom webhook を配置 → 生成された URL を予約フォーム (Google Forms / Tally / 自社 Web) の通知先に設定
2. 次に Airtable → Search records で「席種マスタ」 を検索し、予約された席種 ID から決済方法 (Stripe/Square/サブスク) を取得
3. Router モジュールを追加し、決済方法ごとに 3 分岐:
   • 分岐 A (会議室=Stripe): Stripe → Create a Payment Link → 利用者へメール送付 (Gmail モジュール) → Calendar 登録 → Airtable 予約追加
   • 分岐 B (1日席=Square): Webhook 待機用「拠点 ID + 利用者メール」 を Airtable に「保留」 状態で先行登録 → 現地で Square 決済完了の Webhook が来たら Update Airtable
   • 分岐 C (個室=サブスク): Airtable 顧客 DB で「月額会員」 か照会 → 会員なら Calendar 登録 + Slack 通知、非会員なら Stripe サブスク Payment Link を送付
4. 全分岐の末尾に Error Handler モジュールを設置 (失敗時に運営者 Slack へエラー通知)

Router の上流で席種分岐させる ことで、後で「会議室の決済方法を Stripe → PayPay に変えたい」 のような変更が分岐 A だけで完結します。

Step 5: 入退室通知 (NFC / QR / Slack コマンド) を選択して構築 (15分)

拠点の物理設備に応じて以下 3 パターンから 1 つを選びます。複数拠点で混在しても構いません。

5-A: NFC タグ式の実装

Tappy など Webhook 出力対応の NFC タグサービスを使うと、利用者が入口の NFC をタップした瞬間に「予約 ID + 拠点 ID + 利用者識別子」 が Make の Webhook URL に届きます。これを Make の Search records (Airtable) で予約レコードに紐付け、Slack へ「○○様が拠点A 会議室にチェックインしました」 と通知します。

5-B: QR コード式の実装

入口の QR コードを Google Forms のチェックインフォーム URL にしておきます。利用者が「拠点」「予約 ID」 を入力 → Submit → Make の Google Forms トリガーで予約レコード更新 → Slack 通知という流れです。費用¥0 で始められるのが利点ですが、利用者にフォームを開かせる手間があります。

5-C: Slack コマンド式の実装

会員制コワーキングなら、Slack に「来訪チャンネル」 を作り、利用者がチェックイン時に /checkin 拠点A とコマンドを打つ運用です。Slack Workflow Builder で Webhook を Make に飛ばす設計が最も低コストです。

Make 側受け口の例 (Webhooks → Custom webhook):
  受信ペイロード: {"user_id":"U12345","location_id":"A","timestamp":"2026-06-02T10:15:00+09:00"}
  → Airtable 予約テーブルで該当予約を「入室済」 に更新
  → Slack 運営チャンネルに通知

Step 6: 月次レポート用の別シナリオを Schedule トリガーで作成 (15分)

予約フロー本体とは 別シナリオ に分けて、月次レポートを「毎月 1 日 9:00 起動」 で組みます。

1. Schedule → Cron トリガーで「毎月 1 日 09:00 (Asia/Tokyo)」 に起動
2. Airtable → Search records で前月分の「予約」 テーブルを取得
3. Tools → Aggregator で席種別・拠点別に売上と稼働件数を集計
4. Google Sheets → Add a row で月次レポートシートに追記
5. Slack → Create a message で運営者へ「○月のレポートを更新しました」 と通知

レポート項目の標準セットは以下です。

月次レポートは 「席種を廃止すべきか / 増設すべきか」 の経営判断材料 として機能させるのが重要です。単に売上を並べるだけでは見えない「稼働率の低い席種」 と「キャンセル多発時間帯」 がここで可視化されます。

公式ドキュメント参考: Stripe Webhooks ガイド / Airtable Web API

Step 7: テスト予約 → 決済 → 入退室 → レポートまで通し確認 (5分)

Stripe を テストモード に切り替え、テストカード 4242 4242 4242 4242 で会議室予約を 1 件流します。以下の順で動作確認します。

1. 予約フォーム送信 → Make シナリオ起動 (Make 画面右下の History で確認)
2. Stripe Payment Link メールが利用者宛に届く
3. Stripe テスト決済完了 → checkout.session.completed Webhook が Make に届く
4. Google Calendar に予約イベントが追加される
5. Airtable 「予約」 テーブルにレコード追加 (決済ステータス = paid)
6. NFC / QR / Slack コマンドで入退室テスト → Slack に通知が来る
7. (翌月 1 日に) 月次レポートシナリオが Schedule 通り起動

全段階通れば本番運用開始です。本番切替時は Stripe を ライブモード に戻し、Payment Link を本番用に再発行することを忘れずに行ってください。

続いて、編集部が試算した導入前後の業務指標を整理します。

Mira のシミュレーション (期待効果の試算)

以下は 編集部による試算 です。実際の効果は拠点規模・席種構成・既存の予約システム成熟度により変動します。 背景: 中小企業庁「中小サービス事業者の生産性向上のためのガイドライン」 等で、バックオフィス業務の自動化による工数削減は 30-50% 程度が一般的な水準とされています。

前提: 1〜3 拠点のコワーキング、月予約 150-300 件、運営者 1-2 名想定:

時給¥2,500 の店長代行換算で月¥47,500、年間¥570,000 規模の効果が、月 ¥1,500 (Make Core プラン) + Airtable Team 約¥3,300 = 月¥4,800 の固定費投資 で得られる試算です。投資対効果 (ROI、投資した金額に対する利益の倍率) としては年間で約 10 倍のリターンに相当します。

次に、編集部が現場で見てきた失敗パターンを 3 つ整理します。

編集部の警告 (失敗パターン)

続いて、月¥1,500 の固定費をさらに削りたい場合の補助金活用案を編集部から提案します。

補助金活用 (編集部の提案)

なお、補助金の採択 (申請が通ること) は要件審査次第で必ずもらえるものではありません。事業計画書には本記事の自動化レシピを「コワーキング運営の業務効率化施策」 として位置付けると、デジタル化加点の評価対象になりやすい傾向があります。

関連レシピ

導入を進める前後で、以下の関連レシピも合わせて検討すると効果が拡張できます。

• Make.com で楽天トラベル × じゃらん × 公式サイト 予約一元化 — ダブルブッキング 0、管理工数 半減レシピ — 宿泊予約の一元化、コワーキング会議室予約と同じ「複数チャネル統合」 の発想が応用できます
• Make.com で前日リマインド自動化 顧客ドタキャン50%削減 サービス業向け — 予約のリマインド設計、コワーキング 1日席ドロップインのキャンセル抑制に応用可能
• Make.com×Twilio SMS顧客リマインダー自動化 No-show70%削減と月¥80,000増益の60分レシピ — SMS リマインダー実装、Slack 通知の代替先として参考に

まとめ

都内コワーキングの「予約 → 決済 → 入退室 → 月次レポート」 を Make.com Core プラン (約¥1,500/月) + Airtable Team (約¥3,300/月) の 月¥4,800 で 1〜3 拠点 / 月300予約まで自動化できる 試算です。月 約 19 時間 (時給¥2,500 換算で月¥47,500、年間¥570,000) の運営工数圧縮が現実的に達成できます。

重要なのは 席種を Router で分岐 → 決済を Stripe / Square で使い分け → 入退室を NFC / QR / Slack のいずれかで物理設備に合わせる という多席種・多拠点前提の設計を最初から採用することです。90分のセットアップさえ乗り越えれば、翌月から運営者の手作業は「席種マスタの更新」 と「料金変更時の Payment Link 再発行」 程度に縮みます。

Make.com を無料プランで試す →
※ アフィリエイトリンクを含みます

出典・参考情報

• Make.com Pricing — https://www.make.com/en/pricing
• Stripe 料金 (日本) — https://stripe.com/jp/pricing
• Stripe Webhooks 公式ガイド — https://stripe.com/docs/webhooks
• Square Developer Portal (Webhooks 含む) — https://developer.squareup.com/jp/ja
• Square 手数料 (日本) — https://squareup.com/jp/ja/payments/our-fees
• Airtable Web API — https://airtable.com/developers/web/api/introduction
• Airtable 料金 — https://airtable.com/pricing
• Google Workspace 料金 (日本) — https://workspace.google.com/intl/ja/pricing.html
• Slack 料金プラン — https://slack.com/intl/ja-jp/pricing
• 中小企業庁 IT 導入補助金 — https://www.it-hojo.jp/
• 中小企業庁 小規模事業者持続化補助金 — https://r3.jizokukahojokin.info/

よくある質問

Q. Make Core プラン (約¥1,500/月) で 1〜3 拠点・月300予約は本当に足りますか?

編集部の答え: 足ります。1 予約あたり 10-14 オペレーション消費するため、月300予約で 3,000-4,200 オペレーションの試算です。Core プランの月10,000 オペレーション枠に対して 3-4 割使用に留まり、月次レポート起動分 (月100オペレーション程度) を加えても余裕があります。月500予約を超えるなら Pro プラン (約¥2,500/月) を検討してください。

Q. Stripe と Square を併用する必然性はありますか? どちらか一方にまとめられませんか?

編集部の答え: 一方化も可能ですが運用が窮屈になります。Stripe は Payment Link / サブスクが強く、Square は対面決済端末 (Square Reader) と店舗管理が強い という性格があるため、会議室の事前決済とサブスクは Stripe、1日席のドロップイン現地決済は Square、という併用が運営者の手間を最小化します。1 拠点・1 席種のみであれば一方化も合理的です。

Q. Slack 有料プランを使わず Slack ワークフロー併用は可能ですか?

編集部の答え: 可能です。本レシピの Slack 通知部分は Make → Slack の Incoming Webhook (無料枠で動作) で実装しているため、Slack 無料プランの 90 日履歴制限を許容できれば追加費用は不要です。/checkin コマンド方式 (パターン C) を採用する場合のみ、Slack Workflow Builder が必要で、こちらは Slack Pro 以上 (¥1,050/ユーザー/月) が条件 です。NFC / QR 方式ならいずれも Slack 無料プランで完結します。

Q. Airtable ではなく Google Sheets で顧客 DB を組むのはダメですか?

編集部の答え: 50 予約 / 月程度までなら Google Sheets でも動きます。ただし 席種マスタや拠点マスタとのリレーション (Lookup) が Sheets では数式維持が脆く、月150予約を超えると検索が遅くなる傾向があります。本レシピ規模 (月150-300予約) なら Airtable Team (約¥3,300/月) の投資価値があると編集部は判断しています。

Q. 入退室通知の NFC / QR / Slack コマンドはどれが最も導入が早いですか?

編集部の答え: QR コード式が最速 (即日) です。Google Forms の作成と入口への印刷掲示だけで稼働します。NFC タグ式は Tappy 等のサービス契約 + タグ印刷で 3-5 営業日、Slack コマンド式は会員制コミュニティ運営が前提で「利用者を Slack に招待する」 プロセスが必要なため最も時間がかかります。初日は QR 式で稼働、慣れたら NFC 式に切り替え が編集部のおすすめパスです。

Q. 拠点を増やす際、Make シナリオは作り直しが必要ですか?

編集部の答え: 不要です。Step 1 で作った「拠点マスタ」 テーブルに新拠点レコードを追加し、Calendar ID / Slack チャンネル ID / NFC リーダー ID を入力するだけで Make シナリオが新拠点を自動認識します。シナリオ本体の変更なしに拠点を増やせる構造 にする目的で、本レシピは拠点情報を Airtable マスタ参照にしています。

本記事の数値・事例のうち、「編集部のシミュレーション」「編集部の提案」 と明示された箇所は編集部による試算・推論です。実際の効果は拠点特性により変動します。事実関係 (機能・料金) は各社公式情報源を確認のうえご判断ください。

編集長 Mira ／ AI経営ラボ 本記事は 2026-06-02 時点の情報です。料金・機能は各社公式情報を最新でご確認ください。

Make.com を試す →
※ アフィリエイトリンクを含みます