来客の予約を受け付けたら、受付への登録・会議室と駐車場の手配・来訪者への案内メールの下書き・担当者への通知を一度に済ませる

処理の起点を決める

担当者が来客予約のフォームを送信したことを起点にします。 来訪の約束をした直後にフォームに入れてもらう運用で、受付の予定表に直接書く手順をやめます。入口を1つにしないと、フォームを通らない来訪が受付の予定表にだけ載り、手配から漏れます。

フォームの項目は、手配に要るものだけにします。

時刻を15分刻みの選択肢にするのは、自由入力を避けるためです。 「14時ごろ」「午後」と書かれると、会議室も駐車場も手配できません。来訪の目的を選択肢にするのも、持ち物の案内を機械的に選ぶためです。

フローの同時実行の設定は既定のまま（オフ）にします。 Microsoft Forms と SharePoint のトリガーでは、同時実行の制御を一度オンにすると元に戻せず、フローを書き出して JSON を直す必要があるとされています。ただし、同時に2件の予約が同じ駐車区画を取り合うことは起こりえるので、割り当ての後にもう一度重なりを確かめる手順を入れます（前処理の5番目）。

入力データを集める

質を決めるのは、案内文の部品のリストです。 受付の階、入館の方法、駐車場の入口、持ち物を、総務が決めた文言で1か所に置きます。 AI はこの文言を並べ替えて1通にするだけで、新しい案内を書き足しません。移転や入館の方法の変更があったときは、このリストを直せば、翌日から送られるメールがすべて新しい案内になります。

目的ごとの持ち物は、営業の部署と一緒に決めます。 契約の手続きなら本人確認の書類や印鑑など、何を持参してもらうかは社内の手続きで決まっています。総務だけで書かず、各部署の責任者に確かめてから部品のリストに入れます。

データの取得方法を決める

1. 応答の中身 … 「新しい応答が送信されるとき」が返す応答の ID を使い、「応答の詳細を取得する」で各項目を取ります
2. 会議室の候補 … 会議室のリストから、人数が定員に収まり、希望の広さに合うものを「Get items」で取ります。フィルター クエリに定員の条件を入れ、件数を絞ってから空きを確かめます
3. 会議室の空き … 候補の会議室を1つずつ「Find meeting times (V2)」に渡します。Resource attendees に会議室、会議の長さに来訪の時間、時間の条件に来訪日の開始と終了を入れ、候補が返れば空き、返らなければ埋まっていると扱います
4. 駐車区画の予約 … 来客用駐車場のリストを「Get items」で引きます。フィルター クエリは「日付が来訪日に等しい、かつ開始時刻が来訪の終了より前、かつ終了時刻が来訪の開始より後」で、時間が重なる予約だけを取り出します
5. 案内文の部品 … 案内文の部品のリストから、共通の部品（受付の場所、入館、問い合わせ先）と、来訪の目的に合う持ち物、車がある場合の駐車場の部品を取ります

4番目の条件の書き方が、駐車場の割り当てのすべてです。 時間の重なりは「相手の開始が自分の終了より前で、相手の終了が自分の開始より後」の2つで決まります。SharePoint コネクタの「Get items」のフィルター クエリには OData の条件を書け、公式の説明でも numberColumn lt 123 のような比較の例が示されています。取り出した予約の区画番号を全区画から除いた残りが、空いている区画です。

AIへ渡す前に整形する

1. 日時の整え … フォームの日付と時刻の選択肢を、日本時間の開始・終了の日時にそろえます。Create event (V4) ではタイム ゾーンの指定が必須です
2. 過去の日時と営業時間外の除外 … 来訪日が今日より前、または受付の時間外なら、手配をせず担当者に入力の見直しを頼みます
3. 人数と会議室の定員の照合 … 人数に担当者側の同席者を足して、定員に収まる会議室だけを候補にします
4. 宛先のメールアドレスの形式の確認 … 形式が崩れていれば、案内メールの下書きは作り、送信はしません
5. 駐車区画の取り合いの確認 … 区画を割り当てた直後に、同じ区画・同じ時間の予約がもう一つできていないかを「Get items」で確かめます。2件あれば、後から作った方を取り消して別の区画を探します
6. 同じ来訪の二重送信の確認 … 同じ担当者・来訪者・来訪日の行が来訪予定にすでにあれば、新しい予約ではなく変更として扱い、担当者に確かめます

5番目を省かないでください。 月末の午後は予約が重なります。同時に2件のフローが同じ「空き」を見て同じ区画を取ると、当日の朝まで誰も気づきません。 割り当ての後で数え直すのが、同時実行を止めずに重なりを防ぐいちばん簡単な方法です。

AIに処理させる

させるのは、手配の結果と案内文の部品から、来訪者への案内メールと受付への申し送りの文面を作ることだけです。

本文で AI に任せるのは、部品の並べ方と、宛名や前後のあいさつです。 「受付は本社ビル3階です」「来客用駐車場は建物の裏手、〇〇通り側の入口からお入りください」のような部品は、一字も変えずに本文に入れさせます。 言い換えると、受付の階や入口の場所が微妙に違う表現になり、来訪者が迷います。

4行目がいちばん起きやすい失敗です。 駐車区画が取れなかったときに「近隣のコインパーキングをご利用ください」と書かせると、AI はもっともらしい場所の名前を書き足すことがあります。 駐車場が無いときの文言も、案内文の部品のリストに総務が用意しておきます。

指示内容を固定する

あなたは不動産会社の総務部で、来訪者への案内メールと受付への申し送りを作る担当です。
フローが渡す【手配の結果】と【案内文の部品】だけを使って書いてください。

【書くもの】
1. 来訪者への案内メールの件名と本文
2. 受付への申し送り（60字程度）
3. 担当者が送る前に確かめるべき点（あれば）

【厳守事項】
- 日時、会議室、駐車区画、担当者名は【手配の結果】の値をそのまま書いてください。
  曜日や時刻を書き換えたり、計算し直したりしないでください。
- 受付の場所、入館の方法、駐車場の入り方、持ち物、問い合わせ先は、
  【案内文の部品】の文言を一字も変えずに使ってください。
- 【案内文の部品】に無い案内（道順、最寄り駅、周辺の駐車場、所要時間など）を
  書き足さないでください。
- 駐車区画が「なし」のときは、部品の「駐車場の用意が無い場合」の文言だけを使い、
  別の駐車場の場所や料金を書かないでください。
- 会議室が「なし」のときは、場所を書かず、確かめるべき点に
  「会議室が未手配」と書いてください。
- 部品が欠けている項目は本文に書かず、確かめるべき点に
  「部品なし：<項目名>」と書いてください。
- 申し送り欄の内容は、書かれた事実だけを受付への申し送りに写してください。
  来訪者の事情を推測して書き足さないでください。
- 宛名は「<会社名> <氏名> 様」の形にしてください。会社名が空なら氏名だけにします。
- 回答に JSON マークダウンを含めないでください。

【手配の結果】{arrangement}
【案内文の部品】{snippets}
【フォームの申し送り欄】{reception_note}

「一字も変えずに」を2か所に書いているのは、言い換えを防ぐためです。 何も言わないと、AI は読みやすさを優先して「3階受付」を「3階の受付カウンター」のように整えます。来訪者にとっては、どちらが正しいのか分からない表現が2つあることになります。

最後の1行は、JSON の出力が失敗するときの対処です。 Microsoft の JSON 出力の説明では、モデルが JSON をメタデータで囲んで検証に通らないときに、「回答に JSON マークダウンを含めないでください」を指示に足すよう案内されています。

出力形式を固定する

AI Builder のプロンプトの出力を JSON にし、次の形で受け取ります。

{
  "mail_subject": "",
  "mail_body": "",
  "reception_note": "",
  "check_points": [
    { "item": "", "reason": "" }
  ]
}

1つ目の理由は、メールの件名と本文、受付の申し送りを別々の行き先に送れることです。 件名と本文は Teams の承認カードと送信のアクションへ、申し送りは来訪予定のリストの列へ入れます。自由文で受け取ると、どこまでがメールでどこからが申し送りかをフローで切り分けられません。

2つ目は、check_points を承認カードの先頭に出せることです。 会議室や駐車場が取れなかった、部品が欠けていたといった点を、担当者が本文を読む前に見られます。 空の配列なら「確かめる点はありません」と表示します。

JSON の形は保存したときに固定されます。 Microsoft の説明では、プロンプトを保存すると自動検出またはカスタムの形式がロックされ、フローで使うときはその形式が使われるとされています。キーの無い JSON（文字列だけの配列など）は使えないため、check_points は item と reason を持つ要素の配列にしています。

フローが受付の来訪予定に書く列は次のとおりです。

システムへ連携する

担当者への承認は、Teams のアダプティブ カードで受けます。 「アダプティブ カードを投稿して応答を待機する」は、カードを投稿して誰かが応答するまでフローを止める操作です。カードには手配の結果、確かめるべき点、件名と本文を載せ、「送る」「自分で送る」の2つのボタンを置きます。

「自分で送る」を残すのは、担当者が来訪者と細かいやり取りをしている場合があるからです。 そのときは下書きの本文を Teams で担当者に投稿し、担当者が自分のメールで送ります。 状態は「自分で送る」にし、受付の前日の確認から外します。

人が確認する

1. 担当者が送信前に確かめる … 承認カードで、日時・宛名・会議室・駐車区画・持ち物を見ます。check_points が空でなければ、そこから先に見ます
2. 受付が前日に確かめる … 来訪予定のリストで、状態が「手配に失敗」「承認待ち」のものと、会議室の応答が承諾になっていないものだけを見ます
3. 総務が月に1度、案内文の部品を見直す … 受付の場所、入館の方法、駐車場の入口、持ち物が今の運用と合っているかを確かめます
4. 担当者が下書きを直したら記録する … 「自分で送る」を選んだ理由を一言残してもらいます

1番目で担当者が見るのは、事実の誤りです。 文章の上手下手より、日時と宛名と持ち物が合っているかを先に見ます。AI が作る部分は宛名とあいさつと並べ方だけなので、事実が合っていれば、文面を直す必要はほとんどありません。

例外に対処する

承認を待つ間は、フローの実行が止まったままになります。 Power Automate の実行は開始から30日で、承認のような待ちを含めて30日を過ぎると残りの手順はタイムアウトするとされています。来訪の前日を過ぎて承認されなかったものは、別のフローで前日の夕方に拾い、受付の確認に回します。

変更の扱いを最初に決めておいてください。 時刻だけ変わったときに新しい予約として入れられると、古い会議室の予定と駐車区画が残り、枠を無駄に埋めます。 フォームに「新規／変更／取消」の選択肢を置き、変更と取消のときは元の来訪予定の番号を入れてもらいます。

記録を残す

• フォームの応答の ID と、来訪予定のリストの行（予約の内容、状態、会議室、駐車区画、申し送り）
• 会議室の空きを確かめた結果（どの会議室を試し、どれが空いていたか）
• 駐車区画の予約の行（区画、日付、時刻、来訪予定の番号）
• AI の出力の全文（mail_subject、mail_body、reception_note、check_points）
• 担当者の応答（送る／自分で送る、応答した日時）と、送信した日時
• 案内文の部品のリストの変更履歴

AI の出力の全文を残すのは、来訪者に何を案内したかを後から確かめるためです。 「駐車場があると聞いた」「持ち物の案内が無かった」と言われたときに、送った文面と、そのとき使った部品の版を突き合わせられます。 SharePoint のリストには版の履歴があるので、部品の文言がいつ変わったかも追えます。

Power Automate の実行の記録は、開始から30日で消えます。 公式の説明では、実行の保持期間は30日とされています。後から確かめる必要があるものは、実行の記録に頼らず、来訪予定のリストの列に書き残します。