この記事は、生成AIを活用した自動生成フローで作成しています。

Microsoft Bookingsとは？M365 E3/E5で予約受付を作る実務設計を図解

この記事について
この記事は、生成AIを活用し、2026年9月17日時点のMicrosoft公式Service DescriptionとTeams管理ドキュメントを確認して整理しています。E3/E5でのBookings、Outlook/Exchange、Teams会議、Teams Premiumが必要なSMS、Microsoft Graphまでを分けて説明します。

検証ステータス：📘 Microsoft公式情報確認済み・実機未確認

Microsoft Bookingsは、メールで「いつ空いていますか？」を何往復もする代わりに、予約ページを相手へ渡し、空いている時間から予定を選んでもらうMicrosoft 365サービスです。

Microsoft 365 E3/E5はBookingsを利用できる対象プランです。ただし、Bookings本体が使えることと、Teamsオンライン会議やSMSまで同じ条件で使えることは別です。

先に覚える用語

E3/E5・Teams・SMSを分けて考える

Microsoft公式ではMicrosoft 365 E3/E5をBookings利用可能サブスクリプションとして案内しています。

Microsoftの現在のTeams管理ドキュメントではSMSテキスト通知はカナダ、英国、米国で利用でき、Teams Premiumの一部です。Service Descriptionでは「North America and United Kingdom」と表現されているため、実導入では最新の管理ドキュメントとテナント表示を確認してください。

flowchart LR
    A[予約者] --> B[Bookings予約ページ]
    B --> C[サービス/担当者/空き時間]
    C --> D[Exchange Online / Outlook予定]
    B --> E{オンライン会議?}
    E -->|Yes| F[Teams会議]
    E -->|No| G[対面等]
    B --> H{SMSを使う?}
    H -->|Yes| I[Teams Premium + 対象地域を確認]

身近な例：情シスの「30分PC相談」

情シス担当者へ「いつ空いていますか？」というメールが何度も届くケースを考えます。最初から全社公開せず、テスト用サービスを1つ作ります。

サービス名 : テストPC相談
時間       : 30分
担当者     : テスト担当者1名
公開範囲   : まず限定範囲
質問項目   : 相談概要だけ

1. テスト予約ページを作る

2. 担当者のOutlookに予定を1件入れる

3. 別ユーザーから予約ページを見る

4. 既存予定と競合する時間が候補に出ないことを確認する

5. 空いている時間へテスト予約する

6. 担当者側の予定と通知を確認する

ここを見る

• 予約者に不要なカレンダー詳細が見えていないか

• 既存予定と予約枠が競合しないか

• 予約後に担当者側へ予定が反映されるか

• 予約時に集める情報が必要最小限か

成功条件

予約者が空き枠を選べ、担当者の予定へ反映され、既存予定との二重予約を防げることです。

1か所だけ変える

lead timeを「直前まで」から「2時間前まで」に変更します。予約ページで直近の候補がどう変わるかを見ると、設定が利用者体験へ直結することが分かります。

一般利用者・事務職・情シスでは見る場所が違う

Teams会議を付ける場合の注意

BookingsはTeamsと統合できますが、Microsoft公式はオンライン会議を作るには予約対象スタッフ側にTeamsまたはSkype for Businessの会議作成を許すライセンスが必要と明記しています。

したがって「M365 E3/E5にBookingsがある＝必ずTeams会議付き予約が作れる」と単純化しません。Teamsを分離したSKUなど、現在の契約構成を確認します。

SMSを日本向け予約の前提にしない

SMSはメール通知と同じ条件ではありません。2026年9月17日時点のMicrosoft公式情報ではTeams Premiumの追加条件と地域制限があります。

日本国内の一般的な予約窓口を設計する際に、確認せず「BookingsならSMS通知できる」と要件へ入れない方が安全です。

Microsoft Graphはまず読み取り設計から

BookingsにはMicrosoft Graph APIがあります。APIを使えば予約業務をシステムと連携できますが、最初から予約の作成・変更・削除を自動化すると影響範囲が大きくなります。

概念的には次の順番で考えます。

sequenceDiagram
    participant A as 自動化アプリ
    participant G as Microsoft Graph
    participant B as Bookings
    A->>G: 認証・許可された読み取り要求
    G->>B: Bookingsデータ参照
    B-->>G: 許可範囲の結果
    G-->>A: 結果を返す

最初の検証では、Graph Explorer等のMicrosoft提供環境と公式ドキュメントを使い、必要な権限を確認してから読み取りを試します。本番アプリへ広い権限を与える前に、何を読む必要があるのかを決めます。

ここを見る

• 対象テナント・Bookingsページを間違えていないか

• 必要以上のGraph権限を要求していないか

• 取得した予約情報に個人情報が含まれることを理解しているか

成功条件

必要な情報だけを読み取れ、予約の作成・変更・削除が発生していないことです。

1か所変える

最初は取得件数や対象を小さく限定します。対象を絞ること自体が安全なAPI検証の基本です。

予約フォームは個人情報の入口でもある

Bookingsではカスタムフィールドを使って予約者から情報を集められます。しかし入力欄を増やせるからといって、何でも聞いてよいわけではありません。

たとえば「PC相談」で必要なのが端末種別と相談概要だけなら、生年月日や住所まで取得する理由はありません。

予約ページ公開前に「この項目を本当に保存する必要があるか」を1項目ずつ確認します。

管理者が確認する点

• Bookingsが組織・対象利用者で有効か

• Exchange Onlineメールボックス等の前提を満たすか

• 外部公開/テナント限定のどちらにするか

• Teams会議を使うスタッフのライセンスと会議ポリシー

• SMSを使う場合のTeams Premiumと対象地域

• 予約時に収集する個人情報

• 共有Bookingsの所有・引継ぎルール

• Microsoft Graphを使う場合の認証と最小権限

• Message centerで今後の変更を確認する運用

よくある誤解

E5ならSMSも自動的に使える？
いいえ。Microsoft公式ではSMSにTeams Premium追加条件と地域制限があります。

BookingsがあればTeams会議も無条件で作れる？
いいえ。予約対象スタッフには会議作成を許すTeams/Skypeライセンス等の条件があります。

予約ページだから機密性は低い？
予約者名、連絡先、相談内容などを扱う可能性があります。入力項目、アクセス、API利用を業務データとして設計します。

公式情報・一次情報

• Microsoft Bookings service description

• Manage the Bookings app in Microsoft Teams

• Microsoft Bookings documentation

Bookingsの導入で最初に決めるべきなのは予約ページの色ではありません。誰の時間を、誰に、どの条件で予約させ、どの情報を保存するのかを先に決めることが実務設計の中心です。