個人で複数のプロジェクトを進めていると、作業そのものよりも情報の移し替えに時間を取られることがあります。
- ChatGPTで決めた内容をNotionへ転記する
- Notionの次の作業をGoogleカレンダーへ登録する
- カレンダーの説明欄に目的や手順を書く
- 作業後にNotionの状態を更新する
- 進捗をSlackへ通知する
- 次回の予定を再びカレンダーへ登録する
四つのサービスを連携しても、これらを毎回自分で入力するなら、管理対象が増えただけです。
目指すべき状態は、入力先を増やすことではありません。
人間は目的、制約、判断だけを伝え、情報整理、予定作成、記録、次回設定はシステムに処理させる。
この記事では、ChatGPT、Notion、Slack、Googleカレンダーを役割分担させ、一度入力した情報が実行と記録まで流れる仕組みを組み立てます。
カレンダーは入力場所ではなく、実行予定の出力先にする
一般的なタスク管理では、人間がGoogleカレンダーを開き、予定名、日時、説明文、通知を入力します。
しかし、プロジェクトの目的、次の作業、期限、所要時間がすでにNotionに保存されているなら、同じ内容を再入力する必要はありません。
ChatGPTが次の情報を読み取れば、予定は自動的に作れます。
- 次に実行する作業
- 優先度
- 期限
- 必要な作業時間
- 実行できる曜日と時間帯
- Googleカレンダーの空き時間
- 参照する資料
- 完了条件
ChatGPTは、これらをもとに適切な作業枠を選び、予定タイトルと説明文を生成し、権限が許可されていればGoogleカレンダーへ登録します。
この構成では、Googleカレンダーは手入力するタスク帳ではありません。
Notionに保存された実行候補と、実際の空き時間から生成される実行計画です。
四つのサービスに役割を一つずつ持たせる
同じタスクを四つのサービスへ複製すると、どれが最新情報なのか分からなくなります。役割を明確に分けます。
| サービス | 主な役割 | 人間が行うこと | 自動処理すること |
|---|---|---|---|
| ChatGPT | 情報の整理、判断支援、サービス間の処理 | 目的、制約、承認を伝える | 分類、優先順位付け、予定作成、更新案生成 |
| Notion | プロジェクトの状態と知識の保存 | 必要な判断を確定する | 状態、次の作業、成果、予定IDの保存 |
| Slack | 簡単な入力と例外通知 | 思いつきや結果を短く送る | 未処理情報の収集、判断が必要な問題の通知 |
| Googleカレンダー | 実行時間の確保 | 必要なときだけ予定変更を承認する | 空き時間への配置、説明文生成、通知 |
Notionがプロジェクトの正式な状態を持ち、Googleカレンダーは実行予定を持ちます。Slackは一時的な情報と通知を扱い、ChatGPTが三つの間をつなぎます。
全体の流れ
情報は次の順序で処理します。
flowchart TD
A[SlackまたはChatGPT<br>一度だけ入力] --> B[ChatGPT<br>分類・構造化]
B --> C[Notion<br>状態と次の作業を保存]
C --> D[ChatGPT<br>優先度と空き時間を確認]
D --> E[Googleカレンダー<br>作業予定を自動作成]
E --> F[作業・成果物]
F --> G[ChatGPT<br>結果整理・次回判定]
G --> C
G --> H[Slack<br>例外だけ通知]この流れの基本原則は四つです。
- 人間による入力は一度だけにする
- プロジェクトの正式な状態はNotionに集約する
- カレンダー予定はNotionの情報から生成する
- Slackには人間の判断が必要な場合だけ通知する
人間の入力は一行でもよい
新しい情報を登録するときに、最初から項目を埋める必要はありません。
SlackまたはChatGPTへ、たとえば次のように入力します。
この内容を今週中に検討したい。1時間程度。平日の夜に進めたい。
ChatGPTは、この文章から次の項目を抽出します。
{
"action": "内容を検討する",
"due_period": "今週中",
"estimated_minutes": 60,
"allowed_time": "平日夜",
"status": "ready"
}
対象のプロジェクト、完了条件、必要資料などが既存情報から判断できる場合は自動的に補います。判断できない場合だけ質問を返します。
すべての入力に質問を返すのではなく、予定作成に必要な情報が不足している場合だけ確認することが重要です。
Notionを自動処理できるデータ構造にする
Notionに長い文章だけを保存しても、ChatGPTは優先順位や予定日時を安定して決められません。予定作成に使う項目をデータベースのプロパティとして持たせます。
最低限必要な項目
| 項目 | 型の例 | 用途 |
project_id | テキスト | プロジェクトを一意に識別する |
next_action | テキスト | 次に実行する一つの作業 |
status | 選択 | 未整理、実行可能、予定済み、完了、保留 |
priority | 数値または選択 | 予定配置の順序を決める |
estimated_minutes | 数値 | 必要な作業時間を表す |
due_date | 日付 | 期限を表す |
allowed_time | テキストまたは選択 | 実行可能な曜日や時間帯 |
scheduling_mode | 選択 | 自動登録、承認後登録、手動管理 |
calendar_event_id | テキスト | 二重登録を防止する |
completion_condition | テキスト | 作業の完了条件を表す |
result_link | URL | 成果物への参照を保存する |
visibility | 選択 | 公開可能、要確認、非公開を分ける |
last_updated | 日付 | 停滞判定に使う |
特に重要なのは、statusとcalendar_event_idです。
ChatGPTは、たとえば次の条件に一致する項目だけを予定作成の対象にできます。
status = 実行可能
calendar_event_id = 空欄
next_action = 入力済み
estimated_minutes = 入力済み
予定を登録したら、Googleカレンダーから返されたイベントIDをNotionへ保存し、状態を「予定済み」に変更します。これにより、次回の定期処理で同じ予定を重複作成することを防げます。
Slackは入力窓口と例外通知に絞る
一人で運用する場合、Slackに多数のチャンネルを作る必要はありません。最初は二つでも運用できます。
| チャンネル例 | 用途 |
#inbox | 思いつき、URL、依頼、作業結果を短く入力する |
#alerts | 期限超過、情報不足、判断待ち、処理失敗を受け取る |
必要になった場合だけ、判断専用の#decisionsを追加します。
#inboxへ送った情報の処理
ChatGPTは定期的に未処理メッセージを確認し、次の処理を行います。
- 既存プロジェクトに関係するか判定する
- 新しいタスクか、参考情報か、作業結果かを分類する
- 重複する情報を統合する
- 必要な項目を抽出する
- Notionの該当項目を作成または更新する
- 元のSlackメッセージへの参照を保存する
- 処理済みであることを記録する
分類に確信が持てない場合や、複数のプロジェクトに関係する場合だけ#alertsへ確認を出します。
通常処理の成功通知は送らない
「Notionを更新しました」「予定を作成しました」という通知を毎回送ると、重要な通知が埋もれます。
Slackへ通知するのは、次のような場合に限定します。
- 期限までに配置できる空き時間がない
- 所要時間または完了条件が不明
- 二つの情報源で内容が矛盾している
- 既存予定を移動しないと配置できない
- 同じ作業が繰り返し延期されている
- 一定期間、成果や次の作業が更新されていない
- 非公開情報を公開用成果物へ使う可能性がある
- 外部サービスへの書き込みに失敗した
Slackはすべての処理を見る場所ではなく、人間が対応すべき問題を見る場所にします。
Googleカレンダーの予定を自動生成する
ChatGPTは、Notionの実行可能項目とGoogleカレンダーの空き時間を比較します。
予定配置では、少なくとも次の条件を考慮します。
- 期限が近いものを優先する
- 優先度が高いものを先に配置する
- 指定された実行可能時間帯を守る
- 必要時間より短い空き枠には入れない
- 一日に配置する作業量の上限を守る
- 休憩や移動に必要な余白を確保する
- 同じ種類の作業を過度に連続させない
- 既存予定は許可なく移動しない
予定説明文もChatGPTが作成する
人間がカレンダーの説明欄を記入する必要はありません。Notionの項目と関連資料から、次の形式を自動生成します。
目的:
この作業が必要な理由
今回の成果物:
この時間内に残す文書、コード、表、判断など
参照先:
Notionページ、資料、ファイル、関連URL
最初の操作:
作業開始後、最初に行う具体的な操作
完了条件:
どの状態になれば完了とするか
対象外:
今回の作業では扱わない範囲
終了時の処理:
成果、判断理由、未解決事項、次の作業を記録する
管理情報:
project_id / calendar_event_id
予定作成後は、イベントID、開始日時、終了日時をNotionへ戻します。
定期実行する三つの処理
実用上は、一つの巨大な自動処理を作るより、責任の異なる三つに分けた方が管理しやすくなります。
1. 受信情報の整理
一定間隔でSlackやChatGPTへの新しい入力を確認します。
入力:
- Slackの未処理メッセージ
- Notionの既存プロジェクト
処理:
- 分類
- 重複確認
- 既存項目との関連付け
- 必要項目の抽出
- Notionの作成または更新
出力:
- Notionの更新
- 判断が必要な場合だけSlack通知
2. 作業予定の配置
一日一回または数回、Notionの実行可能項目を確認します。
入力:
- Notionの実行可能項目
- Googleカレンダーの予定と空き時間
- 作業可能時間帯と一日の上限
処理:
- 優先順位付け
- 空き時間との照合
- 予定タイトルと説明文の生成
- Googleカレンダーへの登録
出力:
- Googleカレンダーの予定
- Notionの状態、予定日時、イベントIDの更新
3. 作業結果の整理
終了した予定を定期的に確認します。
入力:
- 終了時刻を過ぎたカレンダー予定
- SlackやChatGPTへ入力された作業結果
- 関連する成果物リンク
処理:
- 完了判定
- 実績と当初予定の比較
- 決定事項と未解決事項の抽出
- 次の作業の生成
- 次回予定の要否判定
出力:
- Notionの結果と状態の更新
- 必要なら次回予定を作成
- 判定できない場合だけSlackへ確認
ChatGPTの定期実行機能を利用する
ChatGPTでスケジュールされたタスクを利用できる環境では、決められた時刻や間隔で処理をバックグラウンド実行できます。公式OpenAI Docsによると、Web上の定期タスクは接続済みのツール、スキル、プラグインを利用でき、ローカルフォルダを必要としない処理ならパソコンが停止していても継続できます。Scheduled tasks
また、OpenAIの公式ユースケースでは、ChatGPTが接続されたメッセージ、カレンダー、文書、プロジェクト管理情報を定期確認し、変化、期限、判断事項、返信が必要な連絡をまとめる運用が紹介されています。Set up a work chief of staff
プラグインやコネクタは、外部サービスの情報参照や操作をChatGPTへ提供します。利用可能な機能、書き込み操作、承認方法は、プラン、アカウント、プラグイン、権限設定によって異なります。Plugins
したがって、実際の構築では次の順に確認します。
- ChatGPTからNotion、Slack、Googleカレンダーを参照できるか
- 各サービスで利用できる書き込み操作は何か
- 自動実行できる操作と承認が必要な操作を分ける
- 通常チャットで処理内容を試す
- 結果が安定してから定期実行へ登録する
- 最初の数回は実行履歴を確認する
運用を始めるための設定プロンプト
次のような指示を、全体を管理するチャットまたは定期タスクの基礎として使えます。
あなたは、個人プロジェクトの情報整理と実行予定を管理してください。
使用する情報源:
- Notionのプロジェクトデータベース
- Slackの #inbox と #alerts
- Googleカレンダー
基本ルール:
1. プロジェクトの正式な状態はNotionを基準にする。
2. Slackの #inbox にある未処理情報を分類し、既存プロジェクトへ関連付ける。
3. Notionで status が「実行可能」、calendar_event_id が空欄の項目を予定候補にする。
4. 期限、優先度、所要時間、実行可能時間帯、カレンダーの空き時間を比較する。
5. 条件に合う場合、予定タイトルと説明文を生成してGoogleカレンダーへ登録する。
6. 登録後、イベントIDと予定日時をNotionへ記録し、statusを「予定済み」にする。
7. 通常処理の成功はSlackへ通知しない。
8. 情報不足、矛盾、期限超過、予定競合、処理失敗がある場合だけ #alerts へ通知する。
9. 事実、推測、判断が必要な事項を区別する。
10. 他人への送信、既存予定の削除、公開情報の変更は承認なしで行わない。
予定説明文には次を含める:
- 目的
- 今回の成果物
- 参照先
- 最初の操作
- 完了条件
- 今回扱わない範囲
- 終了時の処理
- project_id
重要な情報源へアクセスできない場合は、推測で補わず、その情報源を明示してください。
作業結果は短く入力し、残りを処理させる
作業後に人間が長い報告書を書く必要はありません。
次のような短い入力でも構いません。
完了。比較表を作成し、案Bを採用。追加確認が一件ある。
ChatGPTはカレンダー予定とNotionの情報を参照し、次の形へ展開します。
- 実施した作業
- 作成した成果物
- 採用した案
- 採用理由
- 未解決事項
- 次の作業
- 次回予定の必要性
- Notionの更新内容
成果物の場所や採用理由を特定できない場合だけ、追加質問を返します。
自動実行と承認を分ける
すべての操作を同じ権限で扱う必要はありません。影響範囲によって分けます。
| 操作 | 推奨する扱い |
| 自分用Notion項目の作成 | 自動実行可能 |
| Notionの予定ID・日時・状態更新 | 自動実行可能 |
| 自分用カレンダーへの作業枠追加 | 条件を限定して自動実行可能 |
| 自分宛てSlack通知 | 自動実行可能 |
| 作成済み作業枠の説明文更新 | 自動実行可能 |
| 既存予定の移動・削除 | 承認を求める |
| 他人を含む予定の作成・変更 | 必ず承認を求める |
| 他人へのSlackメッセージ送信 | 必ず承認を求める |
| 公開文書や公開ページの更新 | 必ず承認を求める |
| 非公開情報の外部出力 | 実行しない |
最初の運用では、低リスクの書き込みも「提案後に承認」として結果を確認できます。ただし、予定説明文を自分で入力するのではなく、ChatGPTが完成案を作り、人間は承認するだけにします。
結果が安定した処理から順に、承認を省略します。
定期実行とイベント発生時の実行を使い分ける
ChatGPTの定期タスクは、「毎朝」「毎晩」「一時間ごと」のような周期処理に向いています。
一方、次のように出来事の直後に処理したい場合は、各サービスのAPI、Webhook、Google Apps Script、ワークフロー自動化ツール、または小さなPythonプログラムを組み合わせます。
- Slackへメッセージが投稿された直後にNotionへ登録する
- Notionの状態が「実行可能」になった直後に予定を作る
- カレンダー予定が移動された直後にNotionへ反映する
- 成果物が更新された直後に完了判定する
構成は次のように分けられます。
| 実行方式 | 適した処理 | 特徴 |
| 定期実行 | 日次計画、停滞確認、週次レビュー | 構築が比較的簡単 |
| API・Webhook | 投稿や状態変更直後の処理 | 即時性が高い |
| Pythonによる統合処理 | 独自ルール、検証、ログ、複雑な条件分岐 | 制御しやすく拡張性が高い |
最初から大規模なシステムを作る必要はありません。定期実行で十分な処理と、即時処理が必要な部分を分けることで、構成を小さく保てます。
週次レビューも自動生成する
週次レビューのために、Notion、Slack、Googleカレンダーを自分で見比べる必要はありません。
ChatGPTへ次の処理を定期実行させます。
過去7日間のNotion、Slack、Googleカレンダーを確認してください。
次を集計してください:
1. 完了した成果物
2. 予定したが完了を確認できない作業
3. 作業時間を使ったが成果物へつながっていない項目
4. 次の作業が設定されていないプロジェクト
5. 一定期間更新されていないプロジェクト
6. 同じ理由で繰り返し延期されている項目
7. 来週の予定候補
処理ルール:
- 確認できた事実と推測を分ける。
- 新しいプロジェクトを勝手に追加しない。
- 続行、縮小、保留、終了の候補を理由付きで示す。
- 既存予定の移動や削除は提案だけ行う。
- 人間の判断が必要な項目だけSlackへ通知する。
週次レビューの目的は、全タスクを読み直すことではありません。処理が止まっている場所と、人間が判断すべき問題を抽出することです。
学習、制作、公開を一つの流れにする
この仕組みはタスク管理だけでなく、学習や制作にも利用できます。
flowchart TD
A[資料・疑問を入力] --> B[ChatGPTが学習項目へ分解]
B --> C[Notionへ構造化して保存]
C --> D[検証作業をカレンダーへ配置]
D --> E[検証・制作]
E --> F[ChatGPTが結果を整理]
F --> G[知識・手順・記事・ツールへ再利用]
G --> C学習内容を読んだだけで終わらせず、検証、記録、再利用へつなげます。
たとえば、資料のURLをSlackへ送ると、ChatGPTが次を処理します。
- 内容を既存テーマへ関連付ける
- 重要な主張、前提、確認事項を抽出する
- Notionへ参考情報として保存する
- 検証が必要なら次の作業を作る
- 空き時間へ検証予定を登録する
- 結果を手順、判断基準、記事案などへ変換する
人間は資料を保存した後、複数のサービスへ同じ情報を入力する必要がありません。
公開情報と非公開情報を処理前に分ける
仕事や技術開発では、公開できる一般知識と外部へ出せない情報が混在します。公開直前に削除するだけでは、見落とす可能性があります。
Notionにvisibility項目を用意し、情報の作成時点から分けます。
| 区分 | 内容 | 自動処理 |
| 公開可能 | 一般原理、自作例、公開資料に基づく情報 | 公開用成果物の入力に利用可能 |
| 要確認 | 経験を一般化した内容、引用、権利確認が必要な情報 | 人間の確認後に利用 |
| 非公開 | 顧客情報、社内資料、固有仕様、個人情報 | 公開用処理から除外 |
ChatGPTには、公開原稿を作るときに「公開可能」と確認された情報源だけを使わせます。非公開情報を後から取り除くのではなく、最初から処理対象へ入れない設計にします。
サービスを変更してもデータが残るようにする
長期間使う仕組みでは、特定のサービスだけに依存しないことも重要です。
次のルールを採用すると移行しやすくなります。
- 各プロジェクトにサービス外でも使える
project_idを付ける - 日時はISO 8601など一定の形式で保存する
- 状態名と優先度の定義を固定する
- 成果物はURLだけでなく種類と保存場所も記録する
- 処理履歴をJSONまたはCSVへ出力できるようにする
- 予定IDやページIDは外部参照として分離する
- 判断ルールを文章ではなく設定値として持つ
将来、Notionを別のデータベースへ変更しても、同じ項目とIDを維持すれば、ChatGPTやPythonの処理を再利用できます。
ありがちな失敗
四つのサービスすべてに同じタスクを保存する
どの情報が最新か分からなくなります。正式な状態はNotion、実行予定はGoogleカレンダーと決めます。
カレンダー入力を人間へ戻してしまう
予定説明文のテンプレートを用意しても、毎回人間が埋めるなら負担は残ります。テンプレートはChatGPTが埋め、登録まで処理します。
ChatGPTの会話を唯一の記録にする
会話だけでは状態を一覧化しにくく、古い前提も残ります。確定した状態と成果はNotionへ保存します。
成功通知を大量に送る
通知が増えるほど重要な問題を見落とします。Slackには例外、判断待ち、処理失敗だけを送ります。
イベントIDを保存しない
予定を作成した事実をNotionへ戻さないと、定期実行のたびに同じ予定が作られる可能性があります。外部サービスのIDを必ず保存します。
既存予定を自動的に動かす
予定の自動作成と、既存予定の変更は影響が異なります。移動、削除、他人を含む変更には承認を設けます。
一つの処理にすべてを詰め込む
入力整理、予定配置、完了処理を分けないと、失敗箇所を特定しにくくなります。責任ごとに処理とログを分けます。
最小構成
最初に必要なのは次の構成です。
Notion
- プロジェクトデータベースを一つ作る
- 次の作業、状態、優先度、所要時間、期限を持たせる
- カレンダーイベントIDと公開区分を追加する
Slack
- 入力用の
#inboxを作る - 例外通知用の
#alertsを作る
Googleカレンダー
- 自動登録してよい自分用カレンダーを決める
- 作業可能な曜日、時間帯、一日の上限を決める
- 既存予定の変更は承認制にする
ChatGPT
- Notion、Slack、Googleカレンダーへの接続と権限を確認する
- 受信情報整理、予定配置、完了処理を通常チャットで試す
- 安定した処理を定期タスクとして登録する
- 最初の数回は実行結果と重複登録の有無を確認する
この構成で、人間が繰り返し行う操作は次の三つに絞られます。
- 思いつきや作業結果を短く入力する
- 不明点や例外について判断する
- 他人や公開情報に影響する操作を承認する
まとめ
ChatGPT、Notion、Slack、Googleカレンダーを連携する目的は、情報の保存場所を増やすことではありません。
- SlackまたはChatGPTへ一度入力する
- ChatGPTが内容を構造化する
- Notionが正式な状態を保存する
- ChatGPTが空き時間と優先順位を判断する
- Googleカレンダーへ作業予定を自動作成する
- 作業結果からNotionと次回予定を更新する
- 人間の判断が必要な場合だけSlackへ知らせる
Googleカレンダーは、人間が予定説明文を入力する場所ではなく、プロジェクトの状態と実際の空き時間から生成される実行計画になります。
人間が担当するのは、目的を決めること、制約を与えること、重要な判断をすることです。転記、整形、予定作成、状態更新、定型通知はシステムへ任せます。
この役割分担ができると、四つのサービスは個別の管理ツールではなく、一度入力した情報を成果と次の行動まで運ぶ仕組みとして機能します。

