この記事はどんな人向けか
  • 共有フォルダの文書を、朝見たら変わっていた経験がある人
  • エージェントにメールや進捗表を任せたいと考えている管理者
  • 承認範囲は決めたつもりで、時間帯までは決めていない経営者

木曜の朝、進捗表の数字が昨夜と違って見えることがあります。自分は触っていない。誰かが悪いとも限らない。夜も動く側に、文書を渡していると、朝に差分だけが残ることがあります。

これは、公式が「寝ている間に共有表を更新する」と約束した話ではありません。あり得る摩擦です。公式が書いているのは、動く時間と、触れる作業の種類までです。そこから先の、共有正本をいつ触るかは、会社が決める話です。

更新できることは、便利です。便利なまま月曜を迎えると、「何が変わったか」を説明できません。説明できない更新は、進捗ではありません。夜の作業ログです。

公式が書いている範囲は、整理・下書き・更新である

Googleは2026年8月13日、Gemini 3.7 Flash を発表しました(Introducing Gemini 3.7 Flash)。同じ発表の中で、Gemini Spark がこのモデルを使い始める、と書いています。Spark は Google AI Pro / Ultra の契約者向けです。公式の表現は、24/7 で動き、指示の範囲で代理実行する 個人エージェントです。対象は160か国以上。会社の共有ワークスペース専用、とは書いていません。

3.7 Flash により Spark が効率化する例として、公式は次を挙げています。

  • ファイルの整理
  • メールの下書き
  • ステータス文書の更新

できることが増えた、という読み方もできます。増えたものの中身は、人が見ていない時間にも、渡した文書へ手が入り得ることです。個人の下書きなら、朝の自分が受け取れます。共有している進捗表や見積の正本に、同じ手が届くと、朝の会議資料が変わります。届くかどうかは、製品の既定ではなく、どこまで繋いだかです。

エージェントに任せる前に、承認なしで進めてよい範囲を決める話は、すでにあります(エージェントに任せる前に、承認なしで進めてよい範囲を決める)。あちらは権限の話です。今回足すのは、時間帯です。昼に承認した操作と、夜に同じ操作が残ることは、同じではありません。昼は止められます。夜は、結果だけが残ります。

チャットのAIが自分から話し始めるほど、黙っていてよいときを先に決める話もあります(チャットのAIが自分から話し始めるほど、先に決めるのは「黙っていてよいとき」)。文書の更新も、黙って進んでよいときと、朝まで止めるときを分けます。分けない承認範囲は、24時間同じ強さで効きます。同じ強さは、便利に見えます。便利な24時間は、朝の説明責任を増やします。

権限を決めても、時間帯を決めていないと昼の許可が夜まで残る

「下書きまでならよい」。昼にそう決める会社は多いです。決めた瞬間は、人が見ています。見ているあいだは、下書きのまま止まります。

夜になると、見ている人がいなくなります。許可の文面は、夜も同じです。同じ許可のまま、下書きが正本の横にあると、届く場所と書いてある範囲がずれます。ずれた範囲は、トラブルのあとでしか見えません。

公式の「指示の範囲で」は、指示した本人が起きていることを保証しません。指示は残ります。残った指示が、人がいない時間にも効く。そこを書いていない承認は、昼の会話です。昼の会話を、夜間の運用にしてはいけません。

個人エージェントを、共有フォルダへ繋いだとき、特にずれます。Spark は個人向けです。個人の整理は、本人の朝に回収できます。共有フォルダの確定列は、翌朝の会議で「事実」として読まれます。個人の道具を、共有の事実に繋ぐなら、時間帯を先に切ります。切らない接続は、便利に見えます。便利な接続は、朝の前提確認を増やします。

夜に更新してよいものと、朝まで触らせないもの

先に分けるのは、機能一覧ではありません。文書の種類です。

夜に更新してよい例

  • 自分だけが見る下書き
  • 収集したリンクのメモ
  • 「下書き」と名前が付いているフォルダ

朝まで触らせない例

  • 顧客に出す見積の正本
  • 共有している進捗表の確定列
  • 送る直前のメール本文

下書きと正本が同じファイルだと、夜の更新は正本を書き換えます。書き換えた正本を、朝の自分が送ります。送ったあとで、夜の変更に気づきます。気づきは遅いです。遅い気づきは、エージェントの性能の問題ではありません。置き場所の問題です。

ステータス文書は、特に慎重にします。公式が更新例に挙げているからです。進捗表は、朝の会議で「事実」として読まれます。夜に更新された数字は、誰の判断か分かりません。分からない数字を、会議の前提にすると、前提確認から始まります。前提確認は、エージェントを入れた理由の反対側です。

木曜にチームへ渡すのは、機能の説明ではない

入れる週に説明したくなるのは、何ができるかです。整理、下書き、ステータス更新。公式が並べている言葉は、導入説明に使いやすい。使いやすい言葉だけ渡すと、各自が手元の共有フォルダへ繋ぎます。繋いだ先は、人によって違います。

渡す説明は、短くて足ります。夜に触ってよいのは、このフォルダだけ。見積の正本と、進捗の確定列は朝まで触らない。個人の下書きは、朝に本人が移す。三つを口頭で済ませると、金曜には「たぶん共有も見てくれている」になります。たぶん、は運用ではありません。

繋がないものも、先に言います。顧客フォルダ。送信箱の横にある下書き。会議の当日資料。公式が禁止しているからではありません。朝説明できないからです。説明できない接続は、便利でも木曜には足しません。

木曜に残す一行

入れる前に書く一行は、これです。

人がいない時間に、更新してよい文書はどれか。

一行のあとに、フォルダを一つ作ります。名前は「夜間更新可」で足ります。エージェントに渡すのは、そのフォルダだけ。正本は、朝に人が移す。移す作業は遅いように見えます。遅い作業が、説明できる更新を残します。

公式が夜間に共有表を更新すると書いていなくても、この一行は要ります。書いていないことほど、現場は便利なほうへ倒します。倒れる前に、触ってよい文書を一つに限ります。一つも言えないなら、エージェントは昼だけにします。

朝の最初の仕事は、差分を見ることではない

夜に動かすなら、朝の最初は差分確認になりがちです。差分確認が毎日の仕事になると、エージェントは時間を返していません。確認の時間を、夜から朝へ移しているだけです。移した時間は、残業に見えません。見えない残業は、止まりません。

差分を見なくてよい状態は、更新してよい文書が少ない状態です。少ないほうが、設計としては前進です。多いほうが、導入としては派手です。派手な導入は、木曜の会議で「全部つながった」と報告できます。つながった翌朝、何が変わったかを言えないなら、つながりは設計ではありません。

朝の確認をゼロにできないなら、夜間は動かさない。動かさない判断は、機能を捨てることではありません。説明できない時間帯を、空けることです。空けた時間帯は、翌週また足せます。足す前に、触ってよい文書の名前が要ります。

夜も動く道具は、これから増えます。増える前に決めるのは、機能のオンではありません。人がいない時間に触ってよい文書、一つです。一つも言えないなら、昼だけにします。昼だけは、遅れではありません。説明できる速さが残ります。

価格が下がった週に、夜間の範囲まで広げたくなることがあります。安さは、触ってよい文書を増やしません。増やしてよいのは、朝に差分を見なくて済む文書だけです。見なくて済むか言えないなら、範囲はそのままにします。範囲を広げないことが、木曜の判断です。

夜も動くエージェントを入れる前に、触ってよい文書の境界を決めます。tugiloは、機能追加の前に、朝説明できる置き場所から入ります。