現在、自然言語や画像・PDFから予定を読み取り、普段使っているカレンダーへの登録を支援する**AIカレンダーWebアプリ「GPT Calendar」**を開発し、実際に日々のスケジュール管理に使っています。
開発にはOpenAIのCodexを活用しました。
自分が「何を解決したいのか」「どのような動作にしたいのか」を考え、Codexと対話しながらWebアプリとして実装し、実際に動かして問題を見つけ、設計を修正する、というサイクルで開発を進めています。
開発を始めたきっかけは、かなり身近な悩みでした。
私はスケジュール管理がかなり苦手です。
大学、アルバイト、就職活動、プライベートなど、予定が増えるにつれて管理すること自体が負担になっていました。
以前はGoogleカレンダーとiOSのカレンダーを併用していました。
どちらも便利なのですが、複数のカレンダーを使っていると、「この予定はどちらに入れたか」「どちらを確認すればいいか」と、予定そのものとは別に管理するものが増えてしまいます。
そこで現在は、普段使っているiPhoneのiOS標準カレンダー（iCloudカレンダー）へ予定を集約しています。
GPT Calendarは、既存のカレンダーを置き換えるためのWebアプリではありません。
独自の予定データベースを持つのではなく、CalDAVというカレンダー連携の標準プロトコルを使ってiCloudカレンダーと連携させています。
そのため、WebブラウザからGPT Calendarで登録した予定もiPhoneの標準カレンダーに反映され、iPhone側に登録されている予定もGPT Calendarから確認できます。
つまり、
「予定を見る場所はiOSカレンダーに一本化し、予定を入力・整理する部分をWebアプリのGPT Calendarで便利にする」
という構成にしました。
一番の問題は「予定を見ること」ではなく「入力すること」だった
管理先を一つにしても、もう一つ問題が残りました。
自分にとって大変だったのは「カレンダーを見ること」以上に、届いた予定を正確にカレンダーへ入力することでした。
例えば、アルバイト先からシフト表をもらったとします。
そこから自分の勤務日を探して、
- 日付を確認する
- 開始時間を確認する
- 終了時間を確認する
- カレンダーを開く
- 一件ずつ予定を作る
という作業を繰り返します。
大学の時間割や試験日程、教習所の予定でも同じです。
手作業なので、日付や時間を間違えることもあります。登録したつもりで登録できていなかったこともあり、予定を見落としてしまうこともありました。
そこで、
「そもそも人間が予定表を見ながら、カレンダーへ転記する必要はあるのだろうか？」
と考えました。
シフト表をもらったなら、そのシフト表をそのままWebアプリに渡す。
大学の時間割をもらったなら、その画像やPDFをそのまま渡す。
試験日程がPDFで届いたなら、そのPDFをそのまま渡す。
あとはGPT Calendar側が、
読み取り → 日時の構造化 → 既存予定との確認 → 登録候補の作成
まで行い、人間は最後に内容を確認するだけにする。
確認した予定はCalDAV経由でiCloudへ登録され、そのまま普段使っているiPhoneのカレンダーに反映されます。
これなら入力の手間を減らすだけでなく、人間による転記作業そのものを減らすことで、入力ミスをできる限り排除できるのではないかと考えました。
