まとめ方があまり上手くない...
【技術検証】Gemini × Googleカレンダー連携の限界と運用定義
本検証の総括：Gemini APIの制約により「プライマリ・カレンダー」以外の新規作成は不可能である。本資料は、この制約下で作業ログを別アカウントで管理するための構成案を定義する。
1. 技術的制約（検証済みの失敗事例）
以下の構成は、いずれもGoogle Gemini（API）の仕様により実行不可能であることが確認された。
| 試行アプローチ | 結果と原因 |
|---|---|
| セカンダリ所有枠への共有 | 【不可】Geminiは、実行アカウント以外がオーナーのカレンダーへの書き込み権限を持たない。 |
| カレンダーID直接指定 | 【不可】エンドポイントにIDを指定しても、Primary以外の新規作成はAPIレベルで拒絶される。 |
| 多段権限共有 | 【不可】Googleカレンダーの権限モデルは連鎖しない。 |
2. 構成定義：唯一の実行可能フロー
APIが「Primary（最上位カレンダー）」しか操作できない以上、「書き込み先」を固定し、「閲覧場所」を分離するのが唯一の解決策となる。
● 手順1：メインアカウント（書き込み側）の共有設定
メインアカウントのPrimary（自分の名前）カレンダーの設定を開き、別アカウントを「特定のユーザーとの共有」に追加。権限を「予定の変更権限」に指定する。
● 手順2：Geminiへの指示出し（テンプレート）
環境構築後、Geminiへ以下のプロンプトを送信し、記録ルールを固定する。
作業ログの自動記録を開始する。書き込み先はメインアカウントのプライマリ・カレンダーに固定。他の予定と混ざらないよう、タイトル先頭に必ず [LOG] と付け、予定の色はグレーにして記録しろ。以後、このルールを全記録に適用すること。
● 手順3：セカンダリアカウント（閲覧側）の表示管理
別アカウント側で自身の予定を非表示とし、共有されたメインアカウントのカレンダーのみを表示。これによりログ専用ビューを確立する。
検証日：2026年01月16日 / 執筆：Gemini & ユーザー共著
0 件のコメント:
コメントを投稿