Contents
概要と推奨方針(短い要約)
TimeTree と Google カレンダーの連携は、閲覧用の購読(Google→TimeTree)や ICS による一方向の移行が実務上の基本です。即時かつ安全な双方向の自動同期は期待できないため、運用方針を明確にしてから公式 API を優先し、セキュリティと法務チェックを行ったうえで自動化を検討してください。
事前準備と実務チェックリスト
作業を始める前に権限やテスト環境、バックアップ方針、トークンの扱いなどを揃えておくと手戻りが減ります。ここでの確認不足が最もトラブルの原因になりますので、必須項目を確実にチェックしてください。
必要なアカウント・権限と環境確認
以下は最低限揃えるべきアカウントと権限です。組織ポリシーや管理者設定によっては追加の対応が必要になります。
- Google 側
- 対象カレンダーの「設定と共有」にアクセスできる編集権限(シークレット iCal の取得やカレンダー作成権限を含む)。
-
Google Workspace で公開制限がある場合は管理者承認が必要です。
-
TimeTree 側
- 対象カレンダーの主催者/管理者権限。
-
Web 操作が必要なケースが多いため、TimeTree Web のアクセス権を確保してください。
-
自動化・スクリプト関連
- Google Apps Script(GAS)を作成・デプロイできる権限。
- Cloud Console で API を有効化できる権限(Advanced Calendar API を使う場合)。
-
組織のセキュリティポリシーに沿った OAuth スコープ確認。
-
環境
- ブラウザは最新の Chrome/Edge/Safari、アプリは最新バージョンを推奨。
- モバイル単体ではできない操作(エクスポート等)がある点に注意。
導入前の実務チェックリスト
導入作業前に順に確認してください。テストから本番へ展開する流れを決めておくと安全です。
- 編集の「マスター」を決める(Google か TimeTree のどちらで編集を行うか)。
- 影響範囲を確認する(共有相手、参加者、重要予定)。
- 移行前に .ics のバックアップを取得する。
- 小さなテストカレンダーで手順を検証する。
- 通知やリマインダーは移行後に再確認・再設定する。
- タイムゾーンを統一し、DST の影響を確認する。
- 作業担当者と問い合わせ窓口を決める。
- iCal シークレット URL の共有ルールを文書化する。
iCal シークレット URL と OAuth トークンの運用ルール
シークレット URL や OAuth トークンは情報漏洩のリスクが高いため、運用ルールを定めてください。
- 保存場所:組織環境では Google Cloud Secret Manager 等の安全なシークレットストアを推奨します。GAS の PropertiesService を使う場合はアクセス制限を厳格にしてください。
- 共有範囲:最小限の担当者に限定し、パブリックチャットやドキュメントに貼らないこと。
- ログ管理:アクセスログ・監査ログを有効にし、保存期間と承認フローを定義してください。
- ローテーション:定期的にキーをローテーションし、アカウント停止時に即座に無効化する運用を組み込んでください。
- 利用規約・法務チェック:画面スクレイピングや非公式 API 利用は利用規約に抵触する可能性があるため、事前に法務・情報セキュリティ担当の承認を得てください。
Google カレンダー → TimeTree(閲覧) — プラットフォーム別手順
Google を閲覧マスターにする運用では、Google の iCal(.ics) URL を TimeTree に購読させる方法が一般的です。以下は Web とモバイルそれぞれの手順と確認ポイントです。
Google Calendar(Web)で iCal URL を取得する
想定所要時間:2〜5 分。必要権限:対象カレンダーの設定にアクセスできる編集権限(Workspace 管理者が公開を制限している場合は管理者対応が必要)。
- ブラウザで calendar.google.com を開きます。
- 右上の歯車アイコン → 「設定」を開きます。
- 左サイドの「マイカレンダー」から対象のカレンダーを選びます。
- 「カレンダーの統合(Integrate calendar)」欄を探します。
- 「公開用アドレス(iCal 形式)」または「シークレットアドレス(iCal 形式)」をコピーします。
補足(公開用/シークレットの使い分け等)
非公開カレンダーは「シークレットアドレス」を使用してください。シークレット URL は流出すると第三者に予定が見られるため、共有範囲を厳密に管理してください。組織で共有を制限している場合は管理者に依頼する必要があります。
TimeTree(iOS/Android アプリ)で外部カレンダーを購読する
想定所要時間:3〜10 分。必要権限:TimeTree のカレンダー管理権限および端末でのアプリ操作権限。
- TimeTree アプリを起動します。
- メニュー(画面下の「その他」など)を開きます。
- 「カレンダーを追加」または「カレンダーの管理」を選びます。
- 「外部カレンダーを購読」や「iCalで購読」を選択します。
- コピーした iCal URL を貼り付け、表示名と色を設定して保存します。
- テストイベントを Google で作成し、TimeTree に表示されるか確認します。
TimeTree Web で購読する
想定所要時間:3〜10 分。必要権限:TimeTree Web のアカウントで対象カレンダーの管理権限。
- TimeTree Web にログインします。
- 対象カレンダーの設定メニューを開きます。
- 「外部カレンダーの購読」や「iCal を追加」を選び、iCal URL を貼り付けて保存します。
- ブラウザで iCal URL を直接開き、.ics ファイルが取得できるか確認します。
簡易検証チェックリスト(購読の確認)
購読後の短い確認手順です。時間は数分です。
- Google でテストイベントを作成する。
- TimeTree 側でそのイベントが表示されるか確認する。
- 表示されない場合は iCal URL をブラウザで開いて .ics が取得できるかを確認する。
- 重複や古いイベントがある場合は、購読とインポートの二重登録を疑い、不要な方を解除する。
TimeTree → Google カレンダー(予定の移行)と自動化ワークアラウンド
TimeTree の予定を Google に移すには主に ICS エクスポート→インポートが使われます。継続的に大量移行するには自動化の代替手段が必要になることがあります。
ICS エクスポート → Google にインポートする手順と注意点
想定所要時間:小規模なら 5〜30 分。必要権限:TimeTree Web のエクスポート権限、Google のインポート権限。
- TimeTree Web にログインし、対象カレンダーから「エクスポート(ICS)」を実行して .ics をダウンロードします。
- Google カレンダー(Web)→ 歯車 → 「設定」→「インポートとエクスポート」を開きます。
- 「インポート」でダウンロードした .ics を選び、インポート先カレンダーを指定して実行します。
- インポート後に参加者・通知・繰り返しの整合性を目視で確認します。
注意点・落とし穴(まとめ)
- インポートはスナップショットです。以後の TimeTree 側の更新は自動では反映されません。
- 参加者情報、リマインダー、添付ファイルは完全に移行されないことがあります。
- 繰り返しルール(RRULE)やタイムゾーンの解釈差に注意してください。重要予定は個別確認を推奨します。
- 同じ .ics を何度もインポートすると重複します。初回は新しい空の Google カレンダーへインポートして確認してください。
実務向け自動化(概要)
想定所要時間:プロトタイプは数時間、本番化は数日〜。必要権限:GAS の作成・デプロイ権、対象カレンダーの編集権限、組織での承認が必要な場合あり。
自動化の基本は「TimeTree 側のデータを安全に取得 → Google Calendar API に差分を反映する」です。取得方法は公式 iCal(公開・シークレット)を使うか、あるいは非公式な DOM 抽出ですが、後者はリスクが高いので原則として公式手段を優先してください。
法務・ブランドリスク(自動化を検討する際の必須確認)
自動化で次の点を必ず確認してください。承認なしに画面スクレイピング等を行うと利用規約違反や法務リスクが発生します。
- TimeTree と Google の利用規約で自動取得が許可されるか。
- 個人情報や機密予定の扱いが適切か。
- 外部サービスやスクリプトを使う場合はコードレビューとセキュリティ審査を実施する。
- 管理者承認・ログ保存ポリシー・ロールバック手順を文書化する。
CalendarApp と extendedProperties の扱い(重要)
GAS の標準サービス CalendarApp では extendedProperties を直接操作できません。イベントに独自の ID を埋めて差分同期を行いたい場合は、Advanced Calendar API(Apps Script の「Calendar」サービス)や直接の REST API を利用してください。これが実装上の重要な分岐点です。
Apps Script(Advanced Calendar API)での最小安全サンプル
以下は安全性を意識した最小構成の例です。実運用前に必ずテストとセキュリティレビューを実施してください。
- 前提:Cloud Console で Google Calendar API を有効化し、Apps Script の「サービス」から Calendar(Advanced)を有効にする。
- スコープ例(appsscript.json に設定):
- https://www.googleapis.com/auth/calendar(カレンダー操作)
- https://www.googleapis.com/auth/script.external_request(外部リクエストがある場合のみ)
サンプル(Apps Script)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
/** * doPost 受信例(JSON body を想定) * 前提: Script Properties に 'WEBHOOK_SECRET' と 'TARGET_CALENDAR_ID' を保存する * 必要: Advanced Calendar API を有効化(Calendar.Events を使用) */ function doPost(e) { var secret = PropertiesService.getScriptProperties().getProperty('WEBHOOK_SECRET'); try { var payload = JSON.parse(e.postData && e.postData.contents ? e.postData.contents : '{}'); if (!payload || payload.webhookSecret !== secret) { return ContentService.createTextOutput('Unauthorized').setMimeType(ContentService.MimeType.TEXT); } var calendarId = PropertiesService.getScriptProperties().getProperty('TARGET_CALENDAR_ID'); var resource = { summary: payload.summary, description: payload.description || '', start: { dateTime: payload.start }, // ISO 8601 end: { dateTime: payload.end }, extendedProperties: { // ここは Advanced API で扱える private: { timetreeId: payload.timetreeId } } }; // 重複検出(privateExtendedProperty を使った検索) var existing = Calendar.Events.list(calendarId, { privateExtendedProperty: 'timetreeId=' + payload.timetreeId, maxResults: 1 }); if (existing.items && existing.items.length > 0) { var ev = existing.items[0]; // 更新例 ev.summary = resource.summary; ev.description = resource.description; ev.start = resource.start; ev.end = resource.end; Calendar.Events.update(ev, calendarId, ev.id); return ContentService.createTextOutput(JSON.stringify({ status: 'updated', id: ev.id })) .setMimeType(ContentService.MimeType.JSON); } else { var created = Calendar.Events.insert(resource, calendarId); return ContentService.createTextOutput(JSON.stringify({ status: 'created', id: created.id })) .setMimeType(ContentService.MimeType.JSON); } } catch (err) { // エラーハンドリング(ロギングと安全なエラーレスポンス) console.error(err); return ContentService.createTextOutput('Error').setMimeType(ContentService.MimeType.TEXT); } } |
注意点:
- Webhook 秘密は Script Properties や Secret Manager に保存し、決してクライアント側にハードコーディングしないでください。
- デプロイ時は「自分として実行(Execute as: Me)」、アクセスは組織ドメインに限定することを推奨します。
- CalendarApp では extendedProperties を扱えないため、上記のように Advanced Calendar API(Calendar.Events)を使います。
ブックマークレットの安全な最小例
画面スクレイピングではなく、ユーザー入力でイベントデータを送る簡易的なブックマークレット例です。シークレットをブックマークに埋め込むのは危険なので、実行時にプロンプトで入力する方式を推奨します。
ブックマークレット(例)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
javascript:(function(){ var url = prompt('Webhook URL を入力'); if(!url) return; var secret = prompt('Webhook secret を入力'); if(!secret) return; var title = prompt('タイトル'); var start = prompt('開始日時 (YYYY-MM-DDTHH:MM)'); var end = prompt('終了日時 (YYYY-MM-DDTHH:MM)'); var payload = { webhookSecret: secret, summary: title, start: start, end: end, timetreeId: Date.now().toString() }; fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload) }) .then(r => r.text()).then(t => alert('送信結果: ' + t)).catch(e => alert('エラー: ' + e.message)); })(); |
重要:上記は説明用の最小例です。DOM から自動抽出するスクレイピングは利用規約違反の可能性があるため、事前に必ず確認・承認を取ってください。
権限スコープ例と有効化手順
想定所要時間:10〜30 分(初期設定)。必要権限:Cloud Console で API を有効にする権限。
- Cloud Console で Google Calendar API を有効化する。
- Apps Script の「サービス」から Calendar(Advanced)を追加する。
- appsscript.json に必要な oauthScopes を列挙し、最小権限に留める。
- Web アプリとしてデプロイし、アクセス範囲を組織内に制限する。
テスト手順とエラーハンドリングのポイント
想定所要時間:数時間(テストケース作成と確認)。必要権限:テスト用カレンダーの編集権限。
- 小さなテストカレンダーを用意し、作成/更新/削除を検証する。
- API レスポンスのステータスコードを確認し、429/403/500 等に対して指数バックオフを実装する。
- 冪等性の担保は extendedProperties に外部側 UID を入れて検索・更新する方式が現実的です。
- ログに外部 UID と Google イベント ID のマッピングを残し、障害時にロールバックできるようにします。
外部連携サービスの可否(IFTTT/Zapier 等)と運用判断
中小規模の自動化では Zapier や IFTTT といったサービスが便利です。ただし、TimeTree に公式コネクタがない場合は中間で iCal を扱うなどの工夫が必要です。運用要件(即時性、双方向、繰り返しルールの完全再現)によって適切さが変わります。
できることと限界
外部自動化サービスで一般的にできることと限界は次の通りです。
- できること:新規イベント作成や単純なフィールド同期などの一方向の自動化。
- 限界:繰り返しルールや参加者、通知の完全再現は期待しにくい。即時性が必要なケースでは遅延や制限が問題になる。
- TimeTree の公式コネクタがない場合、iCal を中間にして処理する必要があり、変換ロジックが必要です。
認証・安全性・コストに関する注意点
- 多くの自動化サービスは OAuth を使うためパスワードは不要ですが、接続済アプリの権限を定期的に見直してください。
- 中間サービスや Webhook を使う場合、保存先やログ、保存期間を確認し、機密予定が含まれる場合は慎重に運用してください。
- 無料プランは実行頻度や件数に制限があるため、大量イベントや高頻度同期は有料プランか自社実装を検討してください。
トラブルシューティング/バックアップ/FAQ・参考資料(実務向け)
問題発生時はまずここを確認してください。主要な症状と対処法、バックアップ手順、よくある質問を整理しています。
よくある問題と対処法(表示されない・重複・タイムゾーン等)
購読しているのに TimeTree に表示されない場合や、変更が反映されない場合の原因と基本的な対処法を示します。
- 表示されない
- 原因例:iCal URL の誤入力、シークレット URL の無効化、権限不足。
-
対処:ブラウザで URL を開き .ics が取得できるか確認し、購読を削除して再追加します。
-
変更が反映されない/遅い
- 原因例:購読はポーリング方式でポーリング間隔はサービス依存。
-
対処:重要予定は手動で同期するか別ワークフローを用意します。反映を待てない場合は移行を検討してください。
-
重複して表示される
- 原因例:同じイベントを購読とインポートで二重に扱っている。
-
対処:どちらをマスターにするか決め、不要な方を解除します。
-
タイムゾーンのずれ/繰り返し予定の差異
- 原因例:RRULE の解釈差、イベントに TZ 情報がない。
- 対処:双方のタイムゾーンを統一してから移行し、重要な繰り返しは個別確認を行います。
ICS によるバックアップと復元手順
想定所要時間:小規模なら 5〜30 分。必要権限:各サービスのエクスポート・インポート権限。
- Google のエクスポート(バックアップ)
- Google カレンダー(Web)→ 歯車 → 「設定」へ。
- 左メニューの「インポートとエクスポート」→「エクスポート」を実行。
-
カレンダーごとの .ics が ZIP でダウンロードされます。安全な場所に保管してください。
-
TimeTree のエクスポート
-
TimeTree Web の対象カレンダー設定から「エクスポート(ICS)」を実行して .ics をダウンロードします。
-
復元(インポート)
- Google カレンダー(Web)→ 設定 → 「インポートとエクスポート」→「インポート」を選ぶ。
- .ics を指定して、新規カレンダーなどにインポートしてから確認します。
移行時の簡易チェックリスト(手順別の確認項目)
移行作業の各段階で必ず確認すべきポイントを列挙します。
- エクスポート前:テストイベントでエクスポート→インポートの一連を検証する。
- インポート直後:重要なイベントの参加者・通知・繰り返しが正しいか目視確認する。
- 自動化適用前:ログ出力、冪等性(UID マッピング)、エラーハンドリングを確認する。
- 本番適用後:しばらくはログと結果を監視し、問題が起きたら直ちにロールバックできる手順を用意する。
FAQ(抜粋・拡充)
Q: 双方向自動同期はできるか?
A: 公式の完全な双方向自動同期は期待しにくいです。業務で必須なら CalDAV/Exchange 対応サービスへの移行や運用ルールの明確化を検討してください。
Q: 管理者が iCal 公開を禁止している場合の代替は?
A: 管理者に申請して一時的に許可を得るか、TimeTree 側からのエクスポート→Google の定期バッチでスナップショット移行する方法が考えられます。必ず管理者と合意を取ってください。
Q: モバイルで制約はあるか?
A: 多くのモバイルアプリはエクスポート機能を持たないため、Web 経由での操作が必要になるケースが多いです。
Q: よくある API エラーメッセージと対処例は?
A: 403(権限不足)→権限・スコープを確認。429(レート制限)→指数バックオフを実装。409(競合)→ID マッピングで冪等処理を行う。500 系→リトライとログ確認。
参考リンク(公式を優先、非公式は参考扱い)
- TimeTree(公式):https://timetreeapp.com/ (公式サイト)
- TimeTree Developers(公式 API がある場合の参照):https://developers.timetreeapp.com/ (公式ドキュメントを優先)
- Google Calendar API(Events リファレンス、extendedProperties 等):https://developers.google.com/calendar/api/v3/reference/events (公式)
- Apps Script Advanced Calendar Service(利用方法):https://developers.google.com/apps-script/advanced/calendar (公式)
- 実装例(非公式・参考): https://www.choge-blog.com/programming/googlecalendar-timetree/ (非公式ブログ、内容は変更される可能性あり)
- 実装例(ブックマークレット+GAS、非公式・参考): https://sananeblog.com/timetree-to-googlecalender/ (非公式ブログ、参考情報)
まとめ(要点)
TimeTree と Google カレンダーの連携は「閲覧用購読(Google→TimeTree)」と「ICS による一括移行」が主要手段です。双方向自動同期は公式機能に頼れないことが多いため、運用方針を明確にしてから自動化を設計してください。自動化する場合は公式 API を優先し、シークレットや OAuth トークンの取り扱い、利用規約・法務チェック、監査ログや冗長解除ポリシーを必ず組み込んでください。