打ち合わせの日程調整と予約受付は、AIでどこまで無人化できるか
日程調整は、作業としてはほぼ全部を機械に渡せる。
それでも無人化が崩れるのは、工程の一部を外部のサービスに預けたときだ。
うちは2026年8月16日、相談の入口から予約ツールを外し、メールに一本化した。
止まったのは、調整ではなく入口だった
日程調整の自動化というと、候補日を出す部分の話になりやすい。だが実際に手が止まるのは、その手前の入口と、後ろの当日運用のほうだ。
うちはサイトの相談の入口に予約ツールを置いていた。相手が空き枠を選べば会議のURLまで自動で発行される、いちばん無人化された形だ。ところが2026年8月16日、そのビデオ会議サービスを解約して別のサービスへ移すと決めた。決めた瞬間、予約の入口が使えなくなる。同じ日に入口をメールへ戻した。暫定と断ったうえでの後退だ。
工程そのものは何も壊れていない。壊れたのは、工程の一部を他社の契約に乗せていたという構造のほうだった。
工程分解表——「打ち合わせを1件成立させる」工程
| 工程 | 担い手 | 無人化度 |
|---|---|---|
| 相手からの申し込みを受け取る | 機械 | 完全無人 |
| 空いている候補日時を出す | 機械 | 完全無人 |
| 予定表への仮押さえと重複の検出 | 機械 | 完全無人 |
| 確定通知と会議URLの発行 | 機械 | 完全無人 |
| 前日・当日のリマインド | 機械 | 完全無人 |
| 相手からの変更・キャンセルの反映 | 機械 | 検品のみ人間 |
| 申し込み内容の要約と事前準備メモ | 機械 | 補助 |
| 会うべき相手かどうかの判断 | 人間 | 人間必須 |
| どのサービスの上に工程を載せるか | 人間 | 人間必須 |
できる側
候補日の抽出、仮押さえ、通知、リマインドは、規則を書けば機械が正確に繰り返す。ここは迷う要素がない。予定表を読んで空きを出す処理も、二重予約を弾く処理も、条件がはっきりしているので人間より速く、疲れず、揺れない。
申し込み内容の要約も機械に向く。相手が書いた文章から、業種、困っていること、既に使っている道具を抜き出して一枚にまとめておけば、当日の冒頭で聞き直す時間が要らなくなる。ただしこれは補助だ。要約が的を外していても機械には分からないので、目を通す人間が残る。
難しい側
難しいのは、工程をどこに載せるかの判断だ。
予約ツールも、ビデオ会議も、カレンダーも、他社のサービスの上で動く。契約を切り替えた日、値上げされた日、仕様が変わった日に、無人だったはずの工程が止まる。うちが8月16日に経験したのはこれで、自社のコードは一行も変えていないのに入口が機能しなくなった。外部サービスに載せた工程は、自社の設計ではなく他社の都合で止まる。
同じことは道具の版でも起きる。2026年7月28日、うちはビルドで使う道具のバージョンを指定していなかったために、ソースを一文字も変えていないのに本番の生成物が変わる事故を起こした。以後、その道具は版を固定してある。乗り物を選ぶのは人間の仕事で、選び直す日が来ることまで含めて設計する必要がある。
もう一つ、機械に渡せないのが「会うべき相手か」の判断だ。空いている枠を機械が埋めていけば予定は埋まるが、埋まったことは成果ではない。ここは最後まで人間に残る。
失敗はぜんぶ、AIの能力ではなく、人間の設計の穴だった。
自社の実例
うちでは毎朝03:00に講演コンテンツの制作工場が起動し、台本一式を無人で納品している。毎朝04:00には動画工場が起動し、台本から音声、字幕までが人の手を通らずに仕上がる。5分ごとにコレクターが全AI社員の稼働を記録し、mon-ai.jp の出勤板にライブ表示している。
この記事もそうだ。AI社員が書き、機械検品を通ったものだけが無人で公開される。台帳に無い数字が混ざれば、その日は公開されない。
一方で、相談の入口はいま人間の手が触れる形に戻してある。無人化率を落としてでも、他社の契約に依存する部分を最小にするほうを選んだ。
導入までの手順
- 日程調整を、受付・候補出し・仮押さえ・確定通知・リマインド・当日運用に分けて書き出す
- 各工程が、自社のコードで動いているのか、他社のサービスで動いているのかを分けて印を付ける
- 他社側に印が付いた工程について、契約が切れた日に何が止まり、どこへ戻すのかを先に決めておく
この線は、会社ごとに引き直せる。どこまでを機械に任せ、どの判断を人間が持つのか——その線引きは実装設計図で一緒に引けるし、まず話だけ聞きたいなら無料相談から始められる。