エージェントカレンダー調整

エージェントカレンダー調整 は何をしますか？

会議を交渉し、集中時間を保護し、カレンダーデータからコンテキストを推論するAIエージェントを構築します。タイムゾーンの複雑さをナビゲートし、エージェント間のスケジュール調整を実装し、GoogleカレンダーAPIとMCPを使用してカスタムカレンダーロジックを設計します。

決定ポイント

競合が検出された場合

受信した会議リクエストが既存のイベントと競合
├─ 送信者 = マネージャー/役員 → 自動承認、既存イベントの移動を提案
├─ 会議 = 1:1/緊急タグ付き → 24時間以内の代替案を提案
├─ 集中ブロックの衝突
│  ├─ ブロック優先度 = 高（深い作業） → 自動辞退
│  └─ ブロック優先度 = 中 → 代替時間を提案
└─ 同僚との会議と重複 → 3つの代替スロットを提案

自動辞退 vs 代替提案の決定

要素: 送信者階層（役員/マネージャー/同僚/社外）× 会議タイプ（1:1/チーム/全体）× 集中ブロック優先度
役員 + 任意のタイプ → 常に代替案を提案
マネージャー + (1:1 または 緊急) → 代替案を提案
同僚 + 定期 + 出席率低 → 自動辞退
社外 + 事前関係なし → 「カレンダーリンクを使用」で自動辞退
高優先度集中ブロック中 → 送信者に関わらず自動辞退

タイムゾーンを考慮したスロット選択

複数参加者のスケジュール調整:
├─ 全員同じタイムゾーン → 現地の勤務時間（9-17）を使用
├─ 2つのタイムゾーン、時差 <6h → 重なりウィンドウを検索
├─ 2つのタイムゾーン、時差 >6h → 早朝/夕方分割（1人は午前8時、もう1人は午後6時）
└─ 3つ以上のタイムゾーン → 非同期代替案または交代制スケジュールを提案

エネルギーモデルによるスロットランキング

時間帯の優先順位（降順）:
1. 9-11時（ピーク認知） → 深い作業用に予約、ルーチン会議は辞退
2. 11-12時（持続的集中） → 重要な会議のみ許可
3. 14-16時（コラボレーションの最適時間） → チーム会議に推奨
4. 16-17時（締めくくり） → 1:1、ステータス更新に適している
5. 13-14時（昼食後の低迷期） → 複雑な会議は避ける

障害モード

タイムゾーンを考慮した定期予定の競合

症状: 毎週午前9時の会議が冬に競合し夏に競合しない、DST変更後にクロスタイムゾーンの定期予定が失敗する 検出: if 定期イベント && タイムゾーン変換 && 競合パターン季節性 修正: 常にsingleEvents: trueで定期予定を展開し、各インスタンスをUTCに変換して競合チェックを行い、DST移行後に再評価する

バッファ強制のスラッシング

症状: エージェントがバッファを作成しようとして同じ会議を繰り返し再スケジュールする、会議がスロット間を行き来する 検出: if 同じ会議が24時間以内に2回以上バッファ理由で再スケジュール 修正: 最初の再スケジュール後に会議を固定し、会議の重要度に基づいてバッファ要件を動的に調整する

エネルギーモデルのコールドスタート

症状: 新しいエージェントがユーザーの最も認知効率の悪い時間に会議をスケジュールする、確立されたパターンを無視する 検出: if エージェントがスケジュールした会議の満足度スコア < 3 修正: 明示的なユーザー設定でブートストラップし、辞退パターンから学習し、自動スケジュール前に2週間の観察期間を必要とする

スキーマ肥大によるプライバシー漏洩

症状: エージェントが外部システムと過剰なカレンダー詳細を共有する、イベント説明がLLMに漏洩する 検出: if 外部API呼び出しに event.description または attendee.email が含まれる 修正: データ最小化レイヤーを実装し、外部呼び出しの前にPIIを除去し、スケジュールには空き時間情報のみを使用する

再帰的交渉ループ

症状: 2つのエージェントが際限なく対案を出し合う、会議時間に収束しない 検出: if 交渉ラウンド > 3 && 受け入れられたスロットがない 修正: 2回の対案後に人間にエスカレーションし、「十分良い」受入閾値を実装し、交渉に時間制限を設ける

実践例

クロスタイムゾーン会議交渉

シナリオ: あなたのエージェント（シカゴ）が同僚エージェント（東京）とAPIレビューのために30分の時間が必要です。両者にエネルギー制約があります。

ステップ1: 初期分析

• シカゴ: 午前9時-午後5時CST = 午前0時-午前6時JST（翌日）
• 東京: 午前9時-午後6時JST = 午後7時-午前4時CST（前日）
• 重なりウィンドウ: 午後7-8時CST = 午前9-10時JST

ステップ2: エネルギーモデルチェック

• シカゴ午後7時 = 勤務時間終了（エネルギー: 6/10）
• 東京午前9時 = ピーク認知時間（エネルギー: 9/10）
• 不均衡を検出 → 妥協が必要

ステップ3: 提案の生成

Agent Chicago → Agent Tokyo: 提案
スロット: [
  "2024-03-19T01:00Z" (Chi: 午後7時, Tok: 午前10時),
  "2024-03-19T23:00Z" (Chi: 午後5時, Tok: 午前8時),
  "2024-03-20T00:00Z" (Chi: 午後6時, Tok: 午前9時)
]
優先度: 通常
トピック: "APIレビュー - タイムゾーンの複雑さの議論"

ステップ4: 対案

Agent Tokyo → Agent Chicago: 対案
理由: "複雑な技術議論には後の東京の朝を希望"
代替案: [
  "2024-03-19T02:00Z" (Chi: 午後8時, Tok: 午前11時),
  "2024-03-20T01:00Z" (Chi: 午後7時, Tok: 午前10時)
]
制約: "JST午前11時30分のスタンドアップ前に15分のバッファが必要"

ステップ5: 解決 シカゴエージェントは午後8時CST / 午前11時JSTのスロットを受け入れ、説明に両方のタイムゾーンを含むイベントを作成: "APIレビュー - 午後8:00 CST / 午前11:00 JST+1"

初心者 vs エキスパート:

• 初心者: 東京の認知時間を確認せずにシカゴにとって都合の良い時間にスケジュールする
• エキスパート: エネルギーの不均衡を認識し、東京がフレッシュなシカゴの遅い時間帯を提案する

品質ゲート

• すべてのタイムスタンプは内部的にUTCで保存され、表示/API境界でのみ変換される
• IANAタイムゾーン名が全体で使用される（UTCオフセット文字列「-05:00」などは使用しない）
• 空き時間クエリはイベント詳細を削除し、外部エージェントとは時間ブロックのみを共有する
• バッファ強制は連続する会議の間に最低10〜15分の間隔を作成する
• 集中ブロックは「ビジー」としてマークされるが、交渉のための実際の会議よりも低い優先度を持つ
• エネルギーモデルはユーザーの認知ピーク時間と会議疲労パターンを考慮する
• OAuthトークンは保存時に暗号化され、自動リフレッシュフローが実装されている
• レート制限は指数バックオフを使用してGoogleカレンダーAPIクォータを処理する
• 定期イベントは競合検出の前に個々のインスタンスに展開される
• マルチカレンダー統合は、異なる権限を持つ個人/仕事カレンダー間でテストされている
• エージェント間の交渉は時間制限があり、失敗したラウンド後は人間にエスカレーションされる
• 監査ログはすべてのカレンダー変更をロールバック機能とともにキャプチャする

対象外の境界

このスキルは以下には適用されません:

• カレンダーUIコンポーネントの構築 → form-validation-architectを使用
• プロジェクトのガントチャートやマイルストーン追跡 → project-management-guru-adhdを使用
• ポモドーロタイマーや時間追跡アプリ → adhd-daily-plannerを使用
• 一般的なエージェントアーキテクチャパターン → agentic-patternsを使用
• ベースエージェントフレームワークの構築 → agent-creatorを使用

以下の場合は他のスキルに委任:

• ユーザーがADHD特化の時間管理を必要とする場合 → adhd-daily-planner
• 永続的なエージェントメモリの構築 → always-on-agent-architecture
• カレンダーを超えたマルチエージェント調整 → multi-agent-coordination
• バックグラウンドデーモンアーキテクチャ → daemon-development

このスキルは、カレンダーデータ構造、スケジュールアルゴリズム、会議調整ロジックに特化しています。