毎朝6:50、AIが社内をひと通り見て何もしない──『読むだけ』ブリーフィングという設計

僕の朝は、AIが書いた1通のメッセージから始まる。

毎朝6:50、専用のチャンネルに「朝のブリーフィング」が届く。

天気、今日の全予定、今日ある講義セッションの前回宿題、要返信の未読メール。

一日の地図が、僕が起きる前にもう組み上がっている。

これは派手な自動化ではない。

むしろ地味だ。自分宛ての要約を1通投稿する以外は、外へメールを送るわけでも、誰かの承認を代行するわけでも、予定を動かすわけでもない。

ただ「あちこちに散らばっている今日の情報」を一箇所に集めて、要点だけ並べる。

それだけの cron を半年運用してきて、僕はこの「集めるが、何もしない」という制約こそがこの仕組みの一番大事な設計だと思うようになった。

この記事では、その1本のパイプラインを時系列で開けてみる。

毎朝6:50に何が起きているか

朝のブリーフィングは、決まった時刻に1回だけエージェントを起こす cron ジョブだ。

起きたエージェントは、6つのステップを上から順に踏む。

1. 天気。 東京の天気・気温・風を天気APIから取り、傘が要るかまで一言添える。

2. 今日の予定（全件）。 カレンダーの今日の予定を時系列で箇条書きにする。予定が無ければ「フリー」と書く。

3. 今日の講義セッションの下ごしらえ。 予定のタイトルから講義系のものを抜き出し、それぞれについて「前回の議事録」を探して、前回やったこと・宿題・今日やる予定を引き出す。ここがこのブリーフィングの心臓部で、単なる予定表ではなく「今日この打ち合わせに何を持っていけばいいか」まで先回りする。

4. 受講者情報。 申込データから、今日のセッションに紐づく参加人数だけを確認する（名前は出さない）。

5. 未読メールの仕分け。 直近2日の未読メールを取り、人からの直接の質問・依頼・日程調整・承認だけを「要返信」に選ぶ。メルマガ・広告・自動通知は捨てる。

6. 1通に組む。 以上を、天気→スケジュール→講義の詳細→要返信メール→今日のうちにやること、という決まった型に流し込んで、チャンネルに投稿する。

所要はエージェントのターン1回、数分。

僕がやることは、コーヒーを淹れながらそれを1回読むことだけだ。

このパイプラインは「全部を見て、何もしない」

改めて手順を眺めると、このエージェントはかなり広い範囲に触れている。

カレンダー、メール、申込データ、過去の議事録。

普通に考えれば「じゃあ日程調整メールに返信もさせれば?」「予定の重複を勝手に直させれば?」となる。

でも、この仕組みは意図的にそこへ踏み込まない。

集めて、選んで、並べて、その要約を自分宛てに1通投稿する。そこで止まる。外に向けて返信したり、予定を書き換えたり、何かを削除したりはしない。

これは機能の不足ではなく、僕が引いた線だ。

というのも、エージェントに権限を渡すのは、一人の新しいメンバーに合鍵を渡すのに近い。

自立して動く相手だからこそ、「どこまでは自分でやっていい」「どこからは必ず人間に投げる」の境目を、仕組みの側で決めておかないと後で怖い。

朝のブリーフィングでは、その境目を一番手前に引いた。

読むところまではAI、決めるところからは人間。

未読メールは「要返信」のラベルまで付けてくれるが、返信は僕が書く。

予定の準備メモは作ってくれるが、予定そのものは動かさない。

正直に言うと、これは技術的に権限を剥奪しているというより、指示で禁じているレベルの制約だ。だから「絶対に起きない」とまでは言い切れない。それでも、外部システムを変更する操作――AIが勝手に外へメールを返した、予定を書き換えた、データを消した――を頼んでいないぶん、僕はその種の事故のリスクは下がっていると考えているし、実際、少なくとも僕のところでは半年、そうした事故は一度も起きていない。書き込みらしい書き込みは、自分宛ての要約1通の投稿だけだ。（指示だけに頼らずもっと硬くしたいなら、渡すツール自体から書き込み系を外してしまうのが次の一手になる。）

拒否権は、僕が毎朝メッセージを読むその一点に集約されている。

もっと自立度の高いエージェント――僕は用途ごとに権限レベルを分けて何体か持っている――にはもっと広い裁量を渡しているが、こと「毎朝、社内の情報をひと通り横断する」仕事に関しては、触れる範囲が広いぶん、行動はさせない方針にしておくのが釣り合う。

見える範囲と、外部に手を出せる範囲は、別々に設計していい。

これが半年運用して一番腹落ちした点だ。

壊れ方を先に設計する

自動化で一番やってはいけないのは、壊れたときに黙って嘘をつくことだ。

朝のブリーフィングは、各ステップが独立して失敗できるように組んである。

議事録が見つからないセッションがあれば、「議事録未取得」とそのまま書く――推測で埋めない。

予定が無ければ「フリー」、要返信メールが無ければ「返信が必要なメールはなし」と、空を空として出す。

一箇所が取れなくても、残りは届く。全部を巻き添えにして沈黙しない。

「無いものを無いと書く」を制約として明文化してあるのは、ブリーフィングで一番怖いのが「議事録が取れなかったのに、それらしい要約をでっち上げる」ことだからだ。

もう一つ、これは苦い経験から学んだことだが――cron が「成功」と記録していても、それは『中身が届いた』の証明にはならなかった。

僕の環境で使っている実行ランナーは、エージェントのターンが例外を投げずに終わると「成功」と記録する挙動だった。中身が空でも、だ。実際、配信が2日連続で落ちていたのに実行ログは連日「成功」のまま、ということが起きた。

それ以来、この手の定期ジョブの健康状態を、ジョブの自己申告ではなく「毎朝ちゃんとメッセージが来ているか」という外から見える結果で確かめるようにしている。

自己修復というと大げさだが、要は「壊れても部分的に届く」「取れなかったものは正直に取れなかったと書く」「届いたかは外から確かめる」の3点を、賢さに頼らず設計と方針で下げている、という話だ。

自分の環境で作る最小レシピ

大掛かりに見えるが、骨格はとても小さい。

必要なのは「決まった時刻に1回、エージェントを起こす」仕組みと、「情報を集めて1通にまとめるだけ・外部システムは変更しない」という指示、これだけだ。

最小構成は、1本の cron ジョブにこう書く。

schedule: 毎朝6:50（自分のタイムゾーン）
宛先: 自分だけが見る専用チャンネル

やること（この順に、上から）:
  1. 天気APIで今日の天気を1行
  2. カレンダーから今日の予定を時系列で
  3. メールの未読(直近2日)を取り、人からの依頼・日程・承認だけ「要返信」に選ぶ
  4. 天気→予定→要返信メール の順に1通へまとめて投稿する

絶対にやらないこと:
  - メールに返信しない / 予定を変更しない / 何も送らない
  - 情報が取れなかったら「取得できず」と書く（推測で埋めない）

ポイントは3つだけだ。

第一に、集めるソースは最初は2〜3個で十分。天気・予定・未読メールから始めて、効いてきたら議事録や申込データを足す。

第二に、「やらないこと」を指示に明記する。「返信しない」「送らない」「無いものは無いと書く」を書いておく。僕が運用上いちばん気にしているのは、モデルが気を利かせて頼んでいないことまで動こうとする場面で、その芽を先に潰しておく意味がある。

第三に、宛先は自分だけが見る場所にする。試作段階の出力を人に見せる場所に流すと、失敗が事故になる。まず自分専用チャンネルで1〜2週間回して、型が固まってから共有範囲を広げればいい。

僕の環境では、この3点を守った最小構成から始めて、初日から「朝、一箇所を見れば今日のあらましがわかる」状態にはなった。あとはソースを足しながら精度を上げていけばいい。

まとめ

朝のブリーフィングは、AIにできる派手なことの見本ではない。

むしろ「見て回る範囲は広く、外部に手を出す操作はさせない」という、引き算で設計した仕組みだ。

集めるのはAI、決めるのは人間。

一部が取れなくても残りは届き、取れなかったものは取れなかったと明記する。配信そのものが落ちる失敗は、届いたかどうかを外から見て検知する。

この地味な1本を半年回してみて思うのは、エージェント運用でまず作るべきなのは、賢い自動化ではなく「読むだけの一枚」なのかもしれない、ということだ。

権限を渡す前に、まず“見せてもらう”。

僕の環境では、その順番で引いた「読むだけの一枚」が、半年ほど大きく壊れることなく回り続けている。少なくとも僕にとっては、これが一番費用対効果の高い最初の一歩だった。