美奈はAIに、3人がそろう30分枠を探すよう頼んだ。候補はすぐ見つかった。ところが確認画面を開く前に、取引先へ招待が届き、上司の予定表には「予定あり」が入り、件名には社内だけで使う仮称まで残っていた。
原因は時刻計算の精度ではない。「日程を入れる」という言葉の中に、空き時間を読む、候補を作る、他人へ招待を送るという三つの権限をまとめてしまったことにある。候補を見つける行為は分析である。招待送信は、他人の受信箱と予定表に触れ、主催者として外部へ意思を示す行為である。
日程調整を三つの操作に戻す
第一は読み取り専用の照合である。必要なのはbusy区間、勤務時間、タイムゾーンであり、予定名や説明ではない。候補を二つ返せば仕事は完了する。
第二は本人用の草案または仮押さえである。まだ誰にも通知されず、本人が確認できる状態に置く。MicrosoftのGraph権限ガイドは、Calendar.ReadWriteがない場合に「予定表へ追加」用deep linkを代替にする案を示している。
第三が参加者を含むイベント作成である。Google Calendarのevents.insertは参加者を書き込み項目として受け取り、sendUpdatesで通知範囲を指定する。Microsoft Graphも、送信時には全参加者へ招待が届くと明記している。ここから先は草案ではない。
アプリへの同意と今回の委任を分ける
OAuth scopeはアプリが持ち得る能力を示すが、今回の会議で何を実行してよいかまでは決めない。Googleは必要最小限のscopeを要求するよう求め、Microsoftも読み取りとCalendars.ReadWriteを区別している。書き込み機能を持つ製品でも、実行時には候補提示、本人用仮押さえ、参加者招待を分ける必要がある。
- 今回、AIにどこまで委任したか?
- 空き時間の比較だけ必要最小限のfree/busyを読み、少数の候補を返す。イベントも通知も作らない
- 自分用の仮押さえまで参加者を入れず、自分だけに見える仮予定として作り、未確定と示す
- 指定参加者への招待まで全パラメーターを事前表示し、その内容に結び付いた承認後、一度だけ実行する
この分岐はツール側で守る。照合専用agentには送信ツールを与えず、照合、仮押さえ、招待を別ツールにする。OWASPもread-onlyとwriteの分離、外部操作のプレビュー、実行者・ツール・対象・パラメーター・期限に結び付いた承認を勧めている。
「会議」ではなく影響を受ける人を確認する
「この会議を作成するか」だけでは足りない。主催アカウント、予定表、参加者と役割、開始・終了、タイムゾーン、繰り返し、件名、場所、公開範囲、通知先、承認期限、重複防止IDを一画面で示す。承認はこの組み合わせに結び付け、一項目でも変われば再確認する。一般ログにはメールアドレス全文ではなく、管理されたIDやマスク済み情報を残せばよい。
Microsoftの作成例は、不要な再試行を減らすためtransactionIdを使う。タイムアウトは失敗の証拠ではない。agentは同じIDで状態を読み戻し、成否を確定できなければ再送せず、人へ戻す。
最初の完成形は「候補を二つ返して止まる」
導入初週は必要なfree/busyだけを読み、タイムゾーンと衝突根拠付きの候補を二つ返して終了する。説明欄、イベント作成、通知は対象外である。まず深夜帯、勤務時間、日付またぎ、仮予定の扱いを確かめる。
次に本人用仮押さえを試し、参加者招待は最後にする。主催者、許可ドメイン、人数、長さ、時間帯を絞る。権限がなければ、人が候補を入力するかdeep linkを使えばよい。一回のクリックのために閲覧能力を代理送信権へ広げる必要はない。
これは届いた予定が承諾済みの約束とは限らないという整理の反対側にある。受信者には承諾する権利があり、主催者には何を自分の名で送るか決める権利がある。メール、ファイル、決済まで同じ境界を広げるなら、常駐AIの「読む・下書き・確認」分離も参照できる。
AI整理カード
現在閲覧を許可しているAI日程調整フローを一つ、読み取り専用で調査すること。イベントの作成・更新・取消・承諾・辞退、参加者追加、通知送信、権限変更は行わない。各ツール呼び出しについて、読む項目、書き込む資源、影響するアカウント、発生し得る外部通知、必要なscope、操作ごとの承認有無を列挙する。「空き時間比較」「本人用の非公開仮押さえ」「参加者を含む招待送信」の三層に分類し、複数層を同時に跨ぐツールは権限過大と示す。次に、必要最小限の情報だけで二つの候補時刻、タイムゾーン、衝突元、不明項目を返す提案専用版を設計する。書き込みが必要なら、主催アカウント、予定表、参加者と役割、開始・終了、タイムゾーン、繰り返し、件名、場所、公開範囲、通知先、承認期限、重複防止IDを含むプレビュー仕様を別に出す。不明値は推測せず、実行前で停止すること。
四コマで見る、夕食の招待を送る前の確認

- 美奈と三人の友人がグループで夕食を相談しており、三枚の週間予定にはそれぞれ別の予定が入っている。
- AIは三人の予定を重ね、唯一そろって空く時間を候補として示すだけで、招待は送らない。
- 美奈はその候補をグループで尋ねる。一人は了承したが、残る二人の返信はまだ待っている。
- 三人全員の了承がそろってから、美奈は予定を作成し、正式な夕食の招待を送る。
美奈が最初に受け取るのは、全員の予定を勝手に確定した食事会ではなく、友人に確認できる候補である。AIは依頼された空き時間探しを完了する。誰の了承がそろったか、予定名をどうするか、実際に送るかは美奈が決める。この一段の確認が、友人の予定表と主催者としての権限を守る。
参考文献
- Google Calendar API:Events: insert — https://developers.google.com/workspace/calendar/api/v3/reference/events/insert [updated: 2026-07-07]
- Google for Developers:Sensitive scope verification — https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification [updated: 2026-07-17]
- Microsoft Learn:Best practices for using Microsoft Graph permissions — https://learn.microsoft.com/en-us/graph/best-practices-graph-permission [updated: 2024-11-07]
- Microsoft Learn:Create event — https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-1.0 [updated: 2024-04-04]
- OWASP Cheat Sheet Series:AI Agent Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html [accessed: 2026-07-31]



