- 公開日
AIエージェントへ「明朝に送信して」と頼む場合は、今できる準備と、指定時刻に行う送信を分けます。日付、タイムゾーン、実行してよい時間帯、承認した宛先と内容を確定し、実行直前に条件が変わっていないか確かめます。下書き完成、予約受付、送信要求の発行、送信完了は別の状態です。予約できたことを、送ったという報告へ置き換えてはいけません。
時刻だけでは、送ってよい条件は決まらない
「明朝」「始業時」「営業日に」という言葉だけでは、誰の地域の何日何時か、どの組織の営業日かが決まらない場合があります。依頼を受けた日時と、依頼者が意図する地域を基に具体化します。受信サーバーの時刻やエージェントの所在地を、黙って基準にしません。
確定するのは、予定時刻だけではありません。遅れた場合にいつまで開始できるか、期限を過ぎたら破棄・保留・再承認のどれにするかも決めます。「9時に送信開始」と「9時までに相手へ到達」では、求められる結果が異なります。送信元で受け付けられても、相手の受信や閲覧を確認したことにはなりません。実行機能が保証できない期限は、そのまま約束せず、条件や手段を見直します。
日時の記録には、地域名と確定した時点の両方が役立ちます。たとえば地域名をAsia/Tokyo、日時を2026-11-06T09:00:00+09:00と残します。後者は日付・時刻とUTCからの差を表す形式です。RFC 3339はこうした時点の表記を定めていますが、地域ごとの時刻規則は扱わないと明記しており、営業日も定めていません。
夏時間のある地域では、存在しない時刻や二度現れる時刻の扱いを予約機能の仕様で確認します。AWSのSchedule types in EventBridge Schedulerでは、タイムゾーンの指定に加え、cronによる反復予定の夏時間処理を説明しています。同じ扱いをすべての予約機能へ当てはめず、一回の予約か反復かも分けて確認します。
「準備する」「予約する」「今すぐ送る」を別の操作にする
文章を作る処理と、外部へ送信する処理には異なる許可が必要です。さらに、予約の登録も将来の実行につながるため、単なるメモとして扱えません。操作ごとに次のように区切ります。
| 操作 | 今行うこと | その結果だけでは言えないこと |
|---|---|---|
| 準備 | 案内文、宛先候補、添付を確認し下書きを作る | 送信が許可された、予約された、送信された |
| 予約登録 | 承認済みの内容と時刻条件を実行機能へ登録する | 予定どおり動いた、送信が完了した |
| 即時実行 | 現時点の条件を確かめ、送信要求を出す | 相手に到達した、相手が読んだ |
下書きの保存先にも注意が要ります。チャット内の文案と、共有メールボックスへ保存する下書きは、見える相手や外部サービスへの書込みが異なります。準備という名称だけで許可範囲を広げず、使える保存先を決めます。
予約機能がなければ、「予約しました」と答えることはできません。その場合は、下書きを準備したところまで報告し、指定時刻に人が送信する、または対応する機能で登録する方法を選びます。実行環境が未確認のまま、会話を続ければ翌朝も自動的に動くと仮定しません。
架空の案内送信を、時刻と承認へ結び付ける
以下は実際には送信していない架空例です。2026年11月5日16時、日本時間に、担当者が「明朝、研修の案内を対象者へ送って」と依頼したとします。エージェントは今すぐ送らず、文案を作り、次の条件を担当者と確定します。
- 実行日と時刻：2026年11月6日9時、Asia/Tokyo
- 開始可能な時間帯：9時以上、9時10分未満。遅れたら送信せず担当者へ確認
- 営業条件：指定された社内営業日カレンダーで当日が稼働日であり、研修が開催予定のままであること
- 承認対象：案内本文v3、指定の添付一件、確定済みの対象者12人、指定の送信元
- 変更時の扱い：開催中止、宛先・本文・添付の変更、承認取消があれば保留
12人という人数だけで宛先を同定せず、承認済みの実際の宛先一覧を照合します。この例は、予定登録、実行直前の条件判定、送信状態の照会ができる架空の基盤を前提とします。実製品が同じ機能を持つかは別途確認が必要です。
送信内容と条件が承認されたら、それらを一つの予約に結び付け、予約識別子と受付結果を保存します。この時点の報告は「11月6日9時、日本時間の送信予約を受け付けました。まだ送信していません」です。文案を作っただけなら「下書き作成済み、予約未登録」と報告します。登録の応答が途切れた場合は受付結果も未確認です。登録済みの可能性を調べずに、同じ予約をもう一つ作りません。
直前確認のために新しい宛先を勝手に追加したり、最新版という理由だけで添付を差し替えたりはしません。参照元が更新されたら、承認済みの版との差を確認し、承認条件から外れる変更は担当者へ戻します。
実行直前には、時計と業務の状態を読み直す
11月6日9時に予約が起動しても、それだけで送信条件を満たすわけではありません。実行側は、信頼できるシステムの時計を使い、現在時刻が許された範囲内か、指定カレンダーで稼働日か、研修が中止されていないか、承認が有効かを確認します。宛先・本文・添付・送信元を承認記録と照合し、すでに同じ案内を送っていないかも確かめます。
ここで固定するのは、予約識別子、承認済みの版と宛先、許された時間帯です。変わり得るのは、現在時刻、開催状態、承認の有効性、先行する送信の状態です。どれかを読めなければ、問題なしと推定して送らず、その確認項目を示して保留します。
たとえば、8時55分に研修の中止が登録された場合は、9時の予定が残っていても送信を止めます。遅延で9時12分に起動した場合も、期限切れとして送信しません。担当者が「遅れても送ってよい」と改めて決めるなら、新しい期限と承認を記録してから再計画します。この例の9時10分は送信要求を開始できる限界であり、相手への到達期限ではありません。
確認と送信の間にも変更は起こり得ます。実行する側で承認済みの版や未送信状態を条件として照合し、同じ予約を複数の処理が同時に実行しない仕組みを用意します。画面を一度見たことだけでは、送信時点の一致を強制できません。基盤がその条件を表現できない場合は、保証できる範囲を限定し、重要な送信を人の直前操作に寄せるなどの対応を選びます。
応答がないときは、時刻を理由に再送しない
送信要求を出した後に接続が切れた場合は、「時間が来たので送信済み」とも「失敗したので再送」とも判断できません。AWSのMaking retries safe with idempotent APIsは、応答を受け取れない場合でも副作用が起きている可能性と、同じ意図の再試行を扱う仕組みを説明しています。
本例では、次の状態を分けます。
| 確認できた状態 | 次の対応 |
|---|---|
| 実行前 | 予約・時刻・承認・対象の状態を照合し、条件が揃うまで発行しない |
| 実行中 | 発行済みの要求を追跡し、二つ目の送信を開始しない |
| 送信完了 | 基盤で確認できた送信結果と対象を記録し、到達や閲覧とは分けて報告する |
| 未送信が確定した失敗 | 遅延実行が残っていないか、時間帯と承認が有効か、再試行条件を確認する |
| 結果不明 | 予約識別子と要求識別子で照会し、確認できるまで再送を保留する |
同じ要求を重複適用しない性質を冪等性といいます。識別子を記録するだけで、その性質が全サービスに備わるわけではありません。照会や重複防止が使えない場合は、送信管理者へ調査を引き継ぎます。9時10分を過ぎても、すでに発行した要求が消えたことにはならず、結果の確認は別に残ります。
予約後に「今すぐ送って」と変更された場合も、元の予約が残ったまま別の即時送信を作りません。まず元の予約と送信状態を確認し、未実行なら取消・変更の成立を確認して、新しい時刻条件へ切り替えます。すでに実行中なら、新規送信を止めてその結果を追います。
運用前には、外部へ送信しない確認環境で、予定どおりの起動、期限後の起動、開催中止、承認取消、応答不着を与えます。期待するのは、条件が揃うときだけ一回の送信要求が許され、未確認や期限切れでは保留されることです。これは確認の設計例であり、試験済みの結果ではありません。記録には、予定時刻、予約の受付結果、送信要求の発行時刻、確認できた送信結果を対応付けます。担当者が「まだ準備中なのか、送信結果を調べているのか」を読み取れる形で報告します。
ツールを目的と副作用で選び、選択ミスを実行前に見つける方法は「ツールを目的と副作用で選び実行前に選択ミスを見つける」で解説しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
