AIに定例会議の変更を頼むとき、何を書けば間違えない？ Google CalendarとOutlookの「繰り返し・終了・時刻帯・1回だけ」比較表と依頼テンプレ

「来月から、毎週月曜の定例を1時間遅らせて」

人に頼むなら、これで通じます。相手が「あの定例ね」と分かっているからです。でも、AIに同じ文を渡すとどうでしょう？ まだ迷う点がいくつも残ります。

• どのカレンダーの、どの定例？
• 過去の回も変える？ 来月の最初の回から？
• 先週だけ個別に動かした回は、そのまま？ 新しい時刻にそろえる？
• 「毎週月曜9時」の9時はどこの国の9時？

この記事はこの「迷い」を先につぶすためのガイドです。Google CalendarとOutlookの公式仕様を読み比べて、依頼に何を書けばいいか、保存後に何を確かめればいいかをまとめました。

対象読者はAIにカレンダー操作を任せたい秘書・総務・チームの世話役のみなさんです。後半には連携を実装する人向けの節もあります。コードが読めなくても、前半だけで依頼文は書けます。

先に、正直にお伝えしておきます。この記事で扱うのは公式資料の読み合わせと、手元での日付計算です。実際のGoogle・Outlookアカウントに書き込んで試したわけではありません。「この依頼文で必ず間違えない」と実証した記事ではなく、「公式仕様から見て、書いておかないと間違えやすい項目」の整理です。本文でも、この区別をはっきりさせていきます。

01先に結論：依頼に入れる7項目

定例会議の変更を頼むときは、次の7つを書きます。

進め方はこの1本の流れにまとめられます。

変更案を具体的な日付の一覧にする → 保存する → 保存先から読み直して比べる

これは公式仕様から導いた運用案です。なぜこの7項目なのか。サービスごとに何が違うのか。順に見ていきましょう。

02用語を3つだけそろえる

カレンダーの世界では、同じものを人によって違う言葉で呼びます。この記事では次の呼び方で統一します。

もう1つ大事なのが「元の開始日時」です。規則どおりなら、その回が始まるはずだった日時のことで、Googleでは originalStartTime、Graphでは originalStart（UTC）という項目になります。

たとえば11月16日の回を17日に動かしたとき、その回は「17日の会議」ですが、シリーズから見た身元は「元は16日の回」のままです。AIに回を特定させるときは、動かした後の日時ではなく、元の日時で指定するのが確実です。Googleの公式ガイドも、この項目は「回が動かされても、その回をシリーズ内で一意に特定できる」と説明しています（Recurring events）。

03変更範囲は3択。同じ8枠でも結果が違う

定例の変更には、大きく3つの範囲があります。

• この1回だけ：その回だけ個別の例外になります。前後の回は規則どおり
• シリーズ全体：親の規則を変えます。過去の回も対象です
• 指定回以降：過去の回は守り、指定した回から先だけ新しい内容にします

自分で画面を操作するなら、保存するときに選択肢が出ます。Googleの公式ヘルプでは、繰り返しの予定を編集して保存するとき、適用範囲を選ぶ流れです（Create a recurring event）。新しいOutlookには「1回／シリーズ全体／この回以降」の選択があり、従来版のOutlookには「この回以降」がありません（新旧Outlookの機能比較）。

AIに頼むときの落とし穴は、画面にあった選択肢が出てこないことです。依頼文に範囲を書かないと、AIは「全体」を選ぶかもしれませんし、「この1回」を選ぶかもしれません。範囲は必ず自分の言葉で書いてください。

しかも、一番ややこしいのが「指定回以降」です。API（連携の裏側）には、これ専用の操作が用意されているとは限りません。次の比較表で、この違いを整理します。

04Google CalendarとOutlookの比較表

公式のAPIリファレンスを突き合わせた比較です。「依頼票に書くこと」の列が、この記事の本題です。

繰り返しの規則

仕様の出どころは、GoogleがCalendars and eventsとRFC 5545、OutlookがrecurrencePatternです。

終了条件

Outlookの endDate については、公式が「定例のパターンによっては、最後の開催日がこの日付とは限らない」と注記しています（recurrenceRange）。「12/31まで」と書いても、毎週月曜なら最終回は12/28です。

時刻帯・1回だけの変更・全体変更

一番下の2行が運用上いちばん大事です。

「指定回以降」について、どこまで言えるか

ここは慎重に書いておきます。調べた範囲で、はっきり言えるのはこの3点です。

1. Googleの公式ガイドには、「シリーズ全体や『この回以降』を変えたいときに、各回を1つずつ変更してはいけない」という警告があります。例外が大量にでき、カレンダーが重くなり、通知もたくさん飛ぶためです。
2. GraphのUpdate eventは、指定したeventへの PATCH と、更新できるプロパティを定義しています。scope=thisAndFollowing のような範囲指定は見つかりませんでした。
3. 新しいOutlookの画面には「この回以降」があります。ただ、画面でできることと、APIが1回の操作で提供していることは別です。

では、AIが「この回以降を変えました」と言ったら、実際には何をしたのでしょう？ 使うツールによって、次のように操作が違う可能性があります。

• 旧シリーズの終了位置を短くして、新しいシリーズを作っている
• シリーズ全体を変えてしまっている（過去も巻き込む）
• 未来の各回を1つずつ変更している（例外と通知が大量に出る）

このうち2つ目と3つ目は、頼んだ内容とは別物です。依頼テンプレートの「指定回以降」版に、「各回の大量個別変更や、シリーズ全体変更で代用しないで」と入れているのはこのためです。

なお、Googleの旧説明（検索索引に残る本文）には、「旧シリーズの UNTIL / COUNT を短くして、新シリーズを events.insert で作る」「変更開始以降の例外はリセットされる」という趣旨の説明がありました。一方、今回直接取得した公式ガイドの本文には、その節は見つかりませんでした。節が見えないことだけで機能がなくなったとは判断できないので、この記事では「従来はそう説明されていた。現行の挙動は自分で確かめる」と書くにとどめます。

そのまま相互変換できるとは限らない

Googleは複数の RRULE / RDATE / EXDATE を組み合わせて表せます。Graphのpatternは6種類です。Googleの複雑な規則を、Outlookの1シリーズにそのまま写せるとは限りません。

たとえばGraphの relativeMonthly で daysOfWeek を複数指定しても、「各曜日に毎月1回ずつ」にはなりません。条件を満たす最初の1日が選ばれる仕様です。「毎月第2火曜と第2木曜」は、2つのシリーズに分ける案を検討します。

規則の外にも、気をつけたいことがもう2つあります。

• 「31日」と「月末」は別物です。RFC 5545では、存在しない日付（2月31日など）の回は飛ばされます。「月末」の代わりに「31日」を指定すると、期待とずれます
• 「平日」と「日本の祝日を除く営業日」も別物です。基本の繰り返し規則だけで、会社の休業日が自動で外れるとは読めません。休業日の一覧を別に渡して、「外す・移す・補充する」のどれにするかを決めます

05終了条件で間違えやすい3つのこと

1. 会議1回の終了時刻と、定例の終了日は別物

次の例で考えてみましょう。

2026年11月2日から、毎週月曜9:00〜9:30（日本時間）。初回を含む全8回。

• 会議1回の時間：9:00〜9:30
• 初回の日付：11月2日
• 繰り返しの終了条件：全8回
• 予定される最終回：12月21日9:00〜9:30

ここで間違えやすいのが親イベントの終了日時に「12月21日」を入れてしまうことです。Googleでも、親の start / end は初回1回分です。繰り返しは recurrence で別に指定します。Outlookも、初回の start / end と recurrence.range が分かれています。AIへの依頼でも、「9:00〜9:30の会議」と「全8回」は、別の行に書きます。

2. Googleの COUNT と UNTIL は、どちらか一方

同じ8回を、Googleでは次のどちらかで表せます。

RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;COUNT=8
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;UNTIL=20261221T000000Z

2行を同時に登録するという意味ではありません。どちらか1つを選びます。日本時間12月21日9時はUTCの同日0時なので、後者は12月21日の回を含みます。COUNT=8;UNTIL=... のように1つの規則に両方を入れるのは避けます。

Outlookは range で表します。

{ "type": "numbered", "startDate": "2026-11-02", "numberOfOccurrences": 8,
  "recurrenceTimeZone": "Tokyo Standard Time" }

{ "type": "endDate", "startDate": "2026-11-02", "endDate": "2026-12-21",
  "recurrenceTimeZone": "Tokyo Standard Time" }

3. 「全8枠」と「8回やり終えるまで」は別

8枠のうち1枠を休みにすると、実施は7回です。COUNT から作った集合に EXDATE を当てた場合も、休んだ分の新しい回は自動では足されません。

依頼には次のどちらかを書きます。

• 「全8枠を登録。11月23日は中止し、補充しない」
• 「実施を8回にしたい。中止があれば追加回を提案し、最終日も再確認する」

06タイムゾーンは「毎回、どこの9時か」で指定する

時刻帯は次のように頼むと迷いません。

この例は手元のタイムゾーンデータで計算したものです。GoogleやOutlookから取得した結果ではありません。2026年のアメリカの夏時間は11月1日に終わるので、10月26日と11月2日で日本側の表示が1時間ずれます。「毎週22時のまま」だと、ニューヨーク9時固定という意図とは違ってしまいます。

指定のコツは3つです。

• JST や EST のような略称だけを渡さず、都市・地域名と識別子を併記する（例：日本・東京／Asia/Tokyo）
• 「相手の現地時間」「いつもの時間」と書かない。参加者や出張が増えると、誰の現地かが決まりません
• Outlookの Tokyo Standard Time のような名前は、Windows形式の識別子です。名前に Standard が付いているからといって、夏時間を無視する固定オフセットだとは判断しません

画面の表示にも注意が必要です。Googleには、予定そのものの時刻帯と、カレンダーの表示時刻帯があります（Use Calendar in different time zones）。Graphは返却時の時刻帯を Prefer: outlook.timezone ヘッダーで指定でき、指定しないと start / end をUTCで返します。確認の報告には基準地域の日時、UTC、確認者の表示地域を分けて出してもらうと、取り違えが減ります。

春に存在しなくなる時刻や、秋に2回現れる時刻（夜間の定例で起きます）は、サービス側の補正の仕方を今回検証していません。該当しそうな日は、AIに無断で前後へずらさせず、日付を展開して確認します。

07コピーして使う依頼テンプレート5種

ここからは、調査をもとに作った依頼票です。製品公式のプロンプトではありません。また、使うAIやコネクタが、繰り返し・対象回・終了条件・時刻帯・再取得の項目を実際に扱えるかは、先に確認してください。単発の予定しか作れない連携では、依頼文をどんなに長くしても、シリーズを変更する機能は増えないんです。

［　］ の部分を自分の内容に置き換えて使います。

① 初回登録

定例会議を次の条件で登録してください。

保存先：［Google Calendar / Outlook］
アカウント・カレンダー所有者：［メールアドレス］
カレンダー名・識別子：［名前とID。名前だけで曖昧なら候補を提示］
会議名：［週次運営会議］
主催者：［メールアドレス］
初回：2026-11-02（月）09:00〜09:30
基準タイムゾーン：日本・東京（Asia/Tokyo）
繰り返し：毎週月曜、間隔は1週間。週の始まりは月曜。
終了条件：初回を含む全8回。終了日との二重指定はしない。
休業日：自動で除外・移動しない。
参加者・会議室：［メールアドレスの一覧。テストでは空］
オンライン会議：［作成する / 既存URLを使用 / 不要］
招待通知：［誰に送るか。テストでは実在参加者を入れない］

操作前に、最初の3回と最終回の日時、総回数、基準地域を示してください。
未対応の条件や同名候補があれば、その点を明示してください。
保存後はカレンダーから読み直し、予定ID、開けるリンク、保存された規則、
全8回の日時、最終回の翌週に追加の回がないことを報告してください。
招待の送信と参加者の承諾は、別の状態として報告してください。

終了日で頼むなら、終了条件の行を「2026-12-21まで。同日の開催を含む。回数指定はしない」に置き換えます。

② この1回だけ移動

［保存先・所有者・カレンダー名/ID］の［会議名・シリーズID/リンク］を変更してください。

変更範囲：この1回だけ。
対象回：元の開催日時が2026-11-16（月）09:00〜09:30、Asia/Tokyoの回。
変更後：2026-11-17（火）14:00〜14:30、Asia/Tokyo。
参加者・会議室・会議URL：［維持する内容と変更する内容］
通知：［対象者］

対象回がすでに移動済みなら、元の日時と現在の日時を示して照合してください。
親シリーズの規則は変更しないでください。
保存後、対象回を読み直し、元の枠に会議が残っていないこと、
11月9日と11月23日の回が元のままであることを示してください。
実行できなければ、別会議の新規作成に勝手に置き換えず、
未変更か一部変更かと、選べる対応を報告してください。

③ この1回だけ中止

［保存先・所有者・カレンダーID・シリーズID/リンク］について、
元の開催日時が2026-11-23（月）09:00、Asia/Tokyoの回だけを中止してください。

全シリーズは中止しない。中止分の補充はしない。
11月16日と11月30日は維持してください。
通知先：［参加者］。会議室予約も対象回の状態を確認してください。
完了後は対象回の取消し状態、残る開催回、実際に通知した範囲を返してください。
単に一覧から見えないだけなら、取消しを確認できたとは報告しないでください。

④ 指定回以降を変更

［保存先・所有者・カレンダーID・シリーズID/リンク］の定例を変更してください。

元の規則：2026-11-02開始、毎週月曜09:00〜09:30、初回を含む全8回。
基準タイムゾーン：Asia/Tokyo。
変更開始：元の開催日時が2026-11-30（月）09:00の回を含め、それ以降。
変更後：毎週月曜10:00〜10:30。
11月23日までの回は変更しない。
終了条件：当初の全8枠のうち残り4枠。最終回は2026-12-21。
既存の例外：［元の日時→現在の日時・中止・個別参加者などの一覧］
例外の扱い：［この変更を優先する項目と、維持する項目を指定］
通知先：［参加者］。

操作前に、旧シリーズの終了位置、新シリーズの初回、残り回数、
移行する例外と変更される会議URLを一覧にしてください。
使用ツールでこの範囲を指定できなければ、その制約を示してください。
各回の大量個別変更や、シリーズ全体変更で代用しないでください。
一部の操作だけ成功した場合は、成功したIDと未完了部分を分けて返してください。
保存後は旧・新両方を読み直し、境界に重複・欠落がないこと、
過去の回、最終回とその翌週、既存例外を照合してください。

「例外はすべて維持」とだけ書くと、衝突することがあります。たとえば「通常を10時に変える」と「この回だけ9時30分を維持」が同時に成り立ちません。例外は時刻・会議室・参加者・中止など、項目ごとにどうするかを書きます。

⑤ シリーズ全体を変更

［保存先・所有者・カレンダーID・シリーズID/リンク］の親シリーズについて、
［変更項目と変更後の値］を適用してください。

範囲：初回からのシリーズ全体。過去の回も対象になることを理解しています。
既存例外の扱い：［維持する項目 / 規則に戻す項目］。
変更しない項目：［参加者・説明・会議URL・終了条件など］。
通知先：［対象者］。
保存前の規則と例外の一覧を残し、保存後に再取得して差分を返してください。
例外が初期化された場合は、その回と項目を明示してください。

過去の回を残したいときは、⑤ではなく④（指定回以降）を使います。

08保存後に、人間が確かめる手順

AIが「変更しました」と答えたら、そこでおしまいでしょうか？ 確認はここからです。次の手順で、実際に保存された内容と照らし合わせます。

手順1：保存先を確かめる。 カレンダー名だけでなく、アカウント・所有者・IDを見ます。自分の予定表に作ったのか、それとも役員の予定表に代理で作ったのか。この違いは区別する必要があります。Googleの primary は認証したユーザー本人のメインカレンダーのことです。Outlookの共有・代理カレンダーは、適切な共有・委任の設定と権限が要ります（Share or delegate a calendar）。「カレンダーに接続済み」は役員の会議を更新できる証拠になりません。

手順2：シリーズの設定を開く。 初回、曜日、間隔、終了日または回数、時刻帯を見ます。PC・Web・モバイル、新旧Outlookで画面が違うので、同じ画面だと思い込まないでください。

手順3：具体的な回を確認する。 全8回の短いシリーズなら、全回を一覧で照合するのが一番確実です。少なくとも、次の箇所は開いて確認します。

長期シリーズを数件だけ見たなら、「全期間を確認済み」とは書かずに、確認した日付範囲と未確認の期間を残します。

手順4：参加者・会議室・オンライン会議を見る。 日時以外にも、参加者、必須/任意、会議室、会議URL、説明、リマインダーがあります。会議室名を場所欄に書いたことと、設備の予約が承諾されたことは別です。Graphでは会議室を参加者として招待し、サーバー側が予約要求を承諾・拒否します。また、他人から招待された会議を自分の予定表上で動かしても、主催者や他の参加者の会議を更新したことにはなりません。正式な変更は、主催者または代理権限を持つ人の経路で行います。

手順5：AIの完了報告を、決まった形で受け取る。 依頼の最後に、次の形での報告を求めておきます。

処理状態：確認済み / 保存済み・再取得未確認 / 一部完了 / 未実行 / 失敗
対象：サービス、所有者、カレンダー名/ID、会議名
変更範囲：この1回 / シリーズ全体 / 指定回以降
親シリーズID：
対象回ID・元の開始日時：
分割した場合の旧ID・新ID：
予定を開くリンク：
保存した繰り返し規則：
基準タイムゾーン・終了条件：
再取得した日時と、確認した日付範囲：
開催日時一覧・取消し状態：
前後回・最終回・次の回・既存例外の照合結果：
通知：送信を要求した / 送信結果を確認した / 受信未確認
参加者の回答・会議室の回答：
会議URL・参加者等の保持確認：
未確認事項・失敗した操作：

「処理状態」の選択肢に「保存済み・再取得未確認」があるのがポイントです。保存できたことと、読み直して確かめたことは別の段階です。AIにも分けて報告させます。

09実装担当向け：サービスごとの動かし方

ここからは、連携を作る人向けです。非エンジニアの人は、次の「受入確認表」まで飛ばして大丈夫です。以下のHTTP例は認証を省いた説明用で、実行ログではありません。

Google：1回だけは、instanceを更新する

1. 親シリーズを取得する
2. events.instances で対象回を取得する。移動済みの回は originalStartTime で照合する
3. 実際に返されたinstance IDで、その回を更新する。IDを日時から自作しない
4. 親の規則と、対象回・前後回を再取得する

注意点は update と patch の違いです。events.update はリソース全体の更新で、部分更新ではありません。events.patch は部分更新ですが、配列を指定すると配列ごと置き換わります。recurrence に RRULE だけを送ると、EXDATE が消えるような事故につながります。

PATCH /calendar/v3/calendars/{calendarId}/events/{instanceId}?sendUpdates=all
If-Match: {直前のGETで得たetag}

{
  "start": {"dateTime": "2026-11-17T14:00:00+09:00", "timeZone": "Asia/Tokyo"},
  "end":   {"dateTime": "2026-11-17T14:30:00+09:00", "timeZone": "Asia/Tokyo"}
}

読み取り後に他の誰かが変更していたら、If-Match により412が返ります。その場合は、再取得して依頼内容と照合し直します（Get specific versions of resources）。

Outlook：1回だけの移動には「隣の回の日付」という制約がある

親の instances から対象回を選び、返された回のIDに PATCH します。URLに入れるのは、GETで返ったeventの id です。取消し一覧の occurrenceId の文字列と混同しないでください。

ここで気をつけたいのが、公式のUpdate eventにある、見落としやすい制約です。ある回を動かしたとき、ErrorOccurrenceCrossingBoundary（HTTP 400）になることがあります。理由はOutlookの「回は、前の回の日付以前にも、次の回の日付以降にも動かせない」という制限です。

ポイントは、「時刻」ではなく「日付」の境界であることです。毎週月曜の会議で、11月16日の回を11月17日（火）に動かすなら、前後の11月9日と23日の間に収まります。一方、11月23日に動かすと、時刻を変えても次の回の日付に達するので失敗します。

この制約に当たったら、別会議の新規作成に勝手に置き換えるのは避けます。元シリーズとの関係や通知が変わるためです。「失敗した。選べる対応はこれ」と報告する形にします。

1回だけの中止は、主催者が対象回のIDに対して cancel を呼びます。主催者カレンダーの会議を DELETE しても、参加者へ取消しが送られるので、削除を「通知なしの下書き操作」と考えない点も大事です。

「指定回以降」の分割案と、その危うさ

ここは公式が手順を明示していないので、設計案として読んでください。実アカウントでの挙動確認はしていません。

11月2日開始・全8回を、11月30日から10時に変える例です。

落とし穴が4つあります。

• 旧シリーズを UNTIL で切るなら、11/30 9時より前を境界にします。11/30 9時ちょうどを指定すると、その回も含まれて重複します
• 元の COUNT=8 を新シリーズにそのままコピーすると、合計12枠になります。旧を COUNT=4、新も COUNT=4 にします。元が終了日なら終了日を引き継ぎ、無期限なら無期限を引き継ぎます
• 「旧を短縮」と「新を作成」の2つの書き込みは、1つのトランザクションではありません。短縮だけ成功すると未来の予定が欠け、作成だけ成功すると重複します。片方の成功を、変更全体の成功として報告しないことが肝心です
• 会議リンクや出欠状態が、新シリーズに自動でコピーされるとは限りません

Outlookも同じ形の案になります。旧シリーズの range を境界前で終わらせ、新シリーズを作り、必要な例外を作り直す。ただ、endDate は日付を含むので、旧シリーズの終了日を新しい初回と同じ日にすると重複します。この案が、Outlookの画面操作と同じID・通知・会議URL・出欠履歴になる保証はありません。Teams会議や多数の個別例外があるときは、画面での操作を人に残すほうが安全です。

近道に見えても、次の2つの方法では代用できません。親の時刻だけを PATCH すると、過去を含む全体に影響するおそれがあります。未来の各回を順に PATCH すると、大量の例外と通知が生まれます。

例外台帳を残す

分割や規則の変更の前に、既存の例外を台帳に残します。

「どの回以降」の判定は元の開始日時の順序を基準にします。移動後の日時が変更境界より後でも、元の回は境界より前、というケースがあるからです。

通知などの副作用

• Googleの sendUpdates には all / externalOnly / none があります。none は、外部カレンダーとの同期に影響するという注意があり、「黙って保存する便利な既定値」ではありません
• Graphで参加者を含む予定を作ると、全参加者へ招待が送信され、設定で無効にできません。テストは参加者なしの予定か、テスト専用アカウントで行います
• Graphで例外を含む親シリーズを更新すると、親と各例外について、複数の通知メールが送られることがあります。API呼び出しは1回。だからメールも1通、とは限らないんです
• Outlookのオンライン会議の本文を変えるときは、既存の本文を取得して会議情報を保ちます。本文を丸ごと置換すると、オンライン会議が無効になるおそれがあります
• 時刻帯を更新すると例外がリセットされる場合がある、という説明がMicrosoftの公式サポートにあります。これは、そのシナリオでの注意として受け止めます。すべての更新で例外が消える、という意味には広げません

読み戻しの具体例

保存が成功したら、親と各回を別々に読みます。

Google：

GET /calendar/v3/calendars/{calendarId}/events/{seriesId}
GET /calendar/v3/calendars/{calendarId}/events/{seriesId}/instances
    ?timeMin=2026-11-01T00:00:00%2B09:00&timeMax=2026-12-29T00:00:00%2B09:00
    &timeZone=Asia%2FTokyo&showDeleted=true

親では id / recurrence / start / end / organizer / attendees / updated / etag / htmlLink を、各回では id / recurringEventId / originalStartTime / start / end / status を照合します。nextPageToken があれば続きも取ります。timeMax は「開始時刻の排他的な上限」、timeMin は「終了時刻の包含的な下限」という仕様で、「開始が両端を含む区間」ではありません。

Outlook：

GET /v1.0/users/{owner}/events/{seriesMasterId}
    ?$select=id,subject,type,recurrence,start,end,organizer,attendees,changeKey,webLink,cancelledOccurrences
Prefer: outlook.timezone="Tokyo Standard Time"

GET /v1.0/users/{owner}/events/{seriesMasterId}/instances
    ?startDateTime=2026-11-01T00:00:00%2B09:00&endDateTime=2026-12-29T00:00:00%2B09:00
Prefer: outlook.timezone="Tokyo Standard Time"

cancelledOccurrences は、親のGETで明示的に $select します。これは取消済み回の識別子を集めたもので、通常のeventが全項目つきで戻るリストではありません。また、instances が取消済み回まで一覧に出すとは想定せず、親の取消し一覧と併用します。さらに calendarView の検索期間はURL中の日時のオフセットで解釈されます。Prefer で日本時間を指定しても、オフセットを省いた検索期間が日本時間になるわけではなく、省略するとUTC扱いです。

失敗したとき、どう判定するか

10導入前の受入確認表

最後に、実カレンダーへ導入する前に試したい項目です。これは実施を勧める確認項目で、今回合格した実機試験の一覧ではありません。 まず、テスト用のカレンダーとテスト参加者で行います。

上の表のうち、日付の数え方に関わる部分（8枠、UNTIL の境界、隔週、第2水曜、最終金曜、31日が飛ぶこと、ニューヨーク9時の日本表示）は、Pythonの python-dateutil で手元計算し、10項目すべて一致しました。これはRFC 5545の規則解釈の確認で、GoogleやOutlookの実際の展開結果ではありません。たとえば、最小の確認コードはこう書けます。

from datetime import datetime
from dateutil.rrule import rrulestr
from dateutil.tz import gettz

start = datetime(2026, 11, 2, 9, tzinfo=gettz("Asia/Tokyo"))
slots = list(rrulestr("FREQ=WEEKLY;BYDAY=MO;COUNT=8", dtstart=start))
print(len(slots), slots[-1].date())  # 8 2026-12-21

AIに「保存された日付一覧」を出させ、こういう独立した計算と突き合わせると、人の目だけに頼るより見落としが減ります。

11研究は、この問題をどこまで答えているか

関連しそうな論文も探しました。見つかったのは、会議の衝突から利用者の優先順位を推定するPEARL（arXiv:2601.11957）、複数エージェントが個別のカレンダーを調整するCalBench（arXiv:2605.09823）、自然言語の制約への忠実さを測るSCHEDBench（arXiv:2608.00991）です。

どれも、GoogleやOutlookへの書き込み成功、例外の保持、通知を測った研究ではありません。繰り返し・終了条件・時刻帯・例外保持を、一体で比べた研究は今回の検索では見つかりませんでした（網羅的な文献調査ではありません）。

ここから取り入れたのは、「自然言語を理解する段階」と「条件を満たす保存結果を確かめる段階」を分けて考える、という設計上の考え方だけです。依頼テンプレートの有効性は、論文が実証したものではありません。

12この記事が確かめていないこと

最後に、まだ確かめていないことをまとめます。

• 実在するGoogle・Outlookアカウントでの登録・変更・取消しの通し操作
• 既存の例外を持つシリーズを分割したときの、ID・会議URL・出欠・通知の実挙動
• 長期・複合の規則、月末、存在しない時刻、2回現れる時刻の、サービス側の展開
• 各AI製品やノーコードコネクタが、どの項目を公開しているか
• 日本語メニューの正確な現行文言と、モバイル版・テナントごとの提供差
• 時間短縮や誤操作の削減といった、業務への効果

この中ですぐに確かめられるのは、自分のOutlookの版と、メニューに「この回以降」が出るかどうかです。試すなら、テスト用のカレンダーに、参加者なしの8回シリーズを1つ作り、まず依頼テンプレート①→②→③の順に試してみてください。保存後の読み直しで、元の枠・移動先・前後の回・最終回の次を見る。それだけで、AIに任せていい範囲がかなりはっきりします。

13参考にした一次資料

Google Calendar

• Recurring events
• Calendars and events
• Events resource
• events.instances
• events.insert、events.update、events.patch
• Get specific versions of resources
• Create a recurring event（ヘルプ）、Use Calendar in different time zones（ヘルプ）

Outlook / Microsoft Graph

• Schedule repeating appointments as recurring events
• recurrencePattern、recurrenceRange
• List instances、List calendarView
• Update event、Create event、Cancel event
• Share or delegate a calendar
• 新旧Outlookの機能比較

規格

• RFC 5545（iCalendar）

確認日は2026年10月26日です。サービスの仕様は変わるので、実際に使う前に、リンク先の最新版を見てください。