朝、メールはすでに届いている

1. 「複数立ち上げにくいな」という一言から始まった

ある朝、作業の途中でこんな言葉が出た。「複数立ち上げはしづらいんだろうな」。AIとの会話セッションは、原則として一つの文脈しか持てない。別のタブで新しい会話を始めれば、そこには記憶がない。直前まで積み上げたコンテキストは引き継がれず、毎回ゼロから始まる。

これはAIの欠陥ではなく、設計上の特性だ。だが「欠陥ではない」と理解することと、「では何をすべきか」を考えることは別の話だ。制約を受け入れた先に、新しい設計が生まれる。

2. AIが「いる」時間と「いない」時間

人間のアシスタントであれば、席を外している間も電話を取り、メールを仕分け、重要な連絡に付箋を貼っておいてくれる。AIにはそれができない。セッションが閉じれば、存在も閉じる。

ならば逆転させればいい。AIが「いない」時間を埋めるのではなく、AIが「いる」時間に最大限の価値を出せる状態を事前に整えるインフラを作る。メールはすでに取得済み。プロジェクトの状況はすでに整理済み。AIが起動した瞬間、すべての情報が揃っている。

3. GitHub Actionsは「眠らないエージェント」だ

GitHub Actionsは、コードのテストやデプロイのためのツールとして知られている。だが本質はもっとシンプルだ。「特定のタイミングで、特定の処理を、クラウド上で実行する」仕組みに過ぎない。

毎朝7時にIMAPでメールを取得する。プロジェクト管理ツールの最新状況を取得する。結果をプライベートリポジトリに保存する。これらは全て、AIが眠っている間に完了する。AIが目覚めた時——つまりセッションが始まった時——には、すでに今日の情報が揃っている。

毎朝 JST 7:00
→ GitHub Actions 自動起動
→ メール取得（複数アカウント）+ プロジェクト状況取得
→ プライベートリポジトリに保存
→ AIが起動したら既存データを読むだけ

4. IMAPという枯れた技術の選択

メール取得の実装に、あえて枯れた技術を選んだ。IMAPは1988年に設計されたプロトコルで、40年近く現役で使われている。派手さはない。SDKも不要だ。Pythonの標準ライブラリだけで動く。

新しい技術を使うことが設計の質を上げるわけではない。目的は「朝のブリーフィングにメールのインサイトを含める」こと。その目的に対して、IMAPは十分すぎるほど正確に機能する。複数アカウントにも対応できる。エラーが起きた時も、ログが読みやすい。

技術選択の基準は「新しさ」ではなく「目的への適合度」だ。

5. 「道具」と「インフラ」の違い

道具は、使う人が能動的に操作する。インフラは、使う人が意識しなくても機能し続ける。水道は使う前に準備しなくていい。蛇口を開けば水が出る。

AIを「道具として使う」設計では、毎回起動のたびに同じコンテキストを与え直す必要がある。AIを「インフラの一部として組み込む」設計では、AIが起動した時点で環境が整っている。この差は、積み重なると大きくなる。

今日何十回AIと会話しても、メールは一度しか取得されない。プロジェクトの状況は毎朝自動的に更新される。AIへの問いかけが「今日のメールを見て」から「今日のメールを読んだ上で、消防署への提案をどう組み立てるか」に変わる。

6. プライベートリポジトリが「記憶の置き場」になる

AIにはセッションをまたぐ記憶がない。だが、ファイルシステムには記憶がある。プライベートリポジトリに今日の受信箱を保存すれば、それは永続する。明日のセッションでも、先月の受信箱を参照できる。

これはAIの記憶制約への対処であると同時に、情報資産の蓄積でもある。どのメールがどの時期に届いたか。どのタイミングでプロジェクトが動いたか。それらが全てgitの履歴として残る。AIが変わっても、インフラは残る。

7. 「ゼロ秒で始まる朝」を設計する

ブリーフィングを頼んだ時、AIはすでに答えを持っている状態が理想だ。「少々お待ちください、今メールを取得します」ではなく、「今日の未読は3件です。うち1件は重要な返信です」と即答できる状態。

これを「便利な機能」として捉えるのは少し浅い。本質は、情報収集という作業コストをゼロに近づけることで、判断と実行に使える認知資源を増やすことだ。朝の最初の問いが「何が起きているか」ではなく「どう動くか」から始まる。その差は、一日の質を変える。

8. 制約は設計の出発点である

「複数立ち上げにくい」という制約を、問題として終わらせることもできた。だが、その制約を設計の出発点として受け取った時、新しいアーキテクチャが生まれた。AIが眠っている間に動くインフラ。AIが起きた瞬間に整っている環境。セッションをまたいで蓄積される記憶。

制約は創造の敵ではない。制約があるからこそ、設計に必然性が生まれる。自由すぎる環境では、何でもできるがゆえに何もしない選択が増える。制約の中でしか作れないものが、往々にして最も長く使われる。