Gemini Sparkを中間管理職で使ってみる

最近、自分用に作っている「研究所OS」が、また少し変わってきた。

研究所OSといっても、何か大げさなソフトを一本作っているわけではない。

僕がやっているのは、ChatGPTやCodex、Gemini Sparkなどを使いながら、

• サイトを確認する

• 生活に使えそうな制度を調べる

• カレンダーに入れる予定を整理する

• 記事を直す

• 調査結果を残す

• 必要な情報だけMacへ戻す

といった仕事を、なるべく僕自身が全部抱えなくて済むようにする仕組み作りだ。

最近は、それぞれの仕事に担当を作るようになった。

たとえばサイトを見る担当はSite Operations。

生活や行政制度を調べる担当はLife Research。

未来の日付を整理する担当はCalendar。

さらに、それぞれにGemini Sparkの専用スレッドをつけて、第二読や整理をしてもらっている。

少し会社っぽくなってきた。

ただ、ここで新しい問題が出てきた。

AIが働くほど、僕が報告を読むことになった

最初は、

「AIに仕事を任せれば、自分の仕事は減る」

と思っていた。

実際、作業そのものはかなり減った。

でも担当が増えてくると、

「Site Operationsは今どこまでやったんだっけ」

「Life Researchで何が見つかったんだっけ」

「Calendarは何が承認待ちなんだっけ」

「これはCodexに戻す必要があるんだっけ」

と、僕が各AIのところを回るようになった。

つまり僕自身が、

AI同士の廊下を走る人

になり始めた。

仕事をAIへ渡したのに、今度は「AIの仕事を管理する仕事」が生まれている。

これはちょっと違う。

研究所OSでやりたいのは、AIの数を増やすことではない。

僕がやることを減らすことだ。

そこで今、新しい流れを試そうとしている。

AIが仕事をしたら、小さな「作業レシート」だけ残す

考えているのはかなり単純だ。

それぞれの担当AIが仕事をした後に、長い日報を書くのではなく、数行だけ痕跡を残す。

たとえば、

このくらいでいい。

Life Researchなら、

という感じ。

調査ログを全部残すわけではない。

AI同士の会話を全部まとめるわけでもない。

今どこにいるのかだけ分かればいい。

そのために、Google側に一枚だけ「共通受付」のような場所を作ろうとしている。

各担当は、自分の欄だけ最新状態へ書き換える。

履歴はためない。

日報にも育てない。

そしてGemini Sparkの本部役が、そこを見る。

Gemini Spark本部は「中間管理職」になった

最近、Gemini Spark本部の役割も変わってきた。

最初は何を任せるか曖昧だった。

でも今は、

現場の仕事を指揮する人ではなく、現場から上がってくる情報を整理する中間管理職

みたいになってきた。

Site Operationsが普通に仕事を終えたなら、本部は何もしなくていい。

Life Researchが調べて「今回は該当なし」なら、それも静かに終わればいい。

本部が見る必要があるのは、

• 僕の判断が必要

• 調査がSTOPした

• 別の担当と情報がぶつかった

• Macへ正式に戻した方がいい

• Codexに確認してもらった方がいい

といった例外だけだ。

理想は、暇な中間管理職だと思っている。

何も問題がない日に忙しそうにしている本部はいらない。

18時になったら「今日の日報」ではなく「今の現在地」を見る

もう一つ試そうとしているのが、18時の自動確認だ。

最初は「今日AIたちが何をしたか日報にしよう」と考えていた。

でも途中で、それも違うと思った。

履歴を残さない仕組みなのに、一日の全作業を復元しようとすると、また日報管理が始まる。

だから見るのは、

18時現在で何が残っているか

だけにした。

たとえば、

• 僕の判断待ちが1件

• STOPが0件

• Codexへ戻す候補が1件

• Site Operationsはここまで終了

• Life Researchは次はここから

• Calendarには登録待ちが1件

これだけ分かればいい。

「今日AIが17回検索しました」

みたいな情報は、僕にはほぼ必要ない。

仕事量ではなく、未解決だけ見たい。

ここで一番大事なのが「正本」との切り分け

この仕組みで一番気をつけているのが、Google側に情報が集まりすぎることだ。

便利になってくると、

「もうここを見れば全部分かるじゃん」

となる。

そこから少しずつ、Google側の共通受付が正式な記録のようになってしまう。

これは避けたい。

僕の研究所OSでは、今のところMac側を正本にしている。

Google DocsやGemini Sparkは仕事場。

共通受付も仕事場。

そこに、

「DONE」

と書いてあっても、

「Macへ正式回収済み」

という意味ではない。

Google側で、

「この実験は成功した」

ように見えていても、正式なEXPの状態を変えるのは別の話だ。

本人の事実、正式なルール、実験の状態など、残す価値があるものだけCodexが原典と照合してMacへ戻す。

イメージとしては、

現場の仕事
↓
専用Spark
↓
共通受付
↓
Spark本部
↓
必要なものだけ
↓
Codex
↓
Mac正本

という流れだ。

全部を上へ運ばない。

それが重要だと思っている。

自動化するときほど「増えていないか」を見る

こういう仕組みは作っている最中が面白い。

自動化できると、さらに自動化したくなる。

9時にも確認しよう。

12時にも締めよう。

15時にも集約しよう。

メールも送ろう。

ダッシュボードも作ろう。

そうやっていると、気づいたらAIを管理するための巨大な会社ができる。

一人なのに。

だから今回は、かなり意識して止めている。

新しく作る予定なのは、

Google Doc一枚と、18時のSchedule一件だけ。

それ以上はいったん作らない。

しかも、まず3日間だけ試す。

便利そうだから正式採用、ではない。

実際に僕が楽になったら残す。

僕が結局すべてのAIスレッドを見に行っていたら失敗。

共通受付の修正作業が増えたら失敗。

18時のまとめが長すぎて読まなくなったら失敗。

失敗なら消せばいい。

研究所OSは「機能を増やす」と育つわけではない

最近ここが少し分かってきた。

研究所OSが育つというのは、AIや自動化が増えることではない。

むしろ、

僕が覚えていなくても回る。

僕が全部読まなくても分かる。

普通の仕事は勝手に閉じる。

困ったことだけ僕のところへ戻ってくる。

そんな状態に近づくことなんだと思う。

だから今後も、まず現場のAIに仕事を覚えてもらう。

その隣に専用Sparkを置いて、仕事のやり方を少しずつ整える。

そこから共通して使えそうなものが育ったら、本部が拾う。

さらに本当に残す価値があるものだけ、Codexを通してMacの正本へ戻す。

逆に、一度しか使わないやり方や、その日の作業報告まで全部保存しない。

広く働かせて、狭く残す。

そんな感じが一番合っている気がする。

今までは僕がAIを一つずつ呼び出して、結果を別のAIへ運んでいた。

今作ろうとしているのは、AI同士を完全自動で動かす仕組みというより、

僕が廊下を走らなくても、必要な情報だけ自然に上へ流れてくる仕組み

なのかもしれない。

それがうまくいけば、研究所OSはもっと複雑になるのではなく、

僕から見ると、逆に少しずつシンプルになっていくはずだ。