画面を離れても、Agent は仕事を続ける。
日々の主力となった dots でのデプロイや調査を中心に、過去に試した Muse、自前構成として検証した OpenClaw、公開資料を調べた Grok Bot を整理し、Agent の実行環境と停止点を考える。
研究ノート01
Agent が画面の外で働くとき、仕事はどこへ行くのか。
まず入口、環境、接続、停止点を見る。モデルの大きさから比べない。
以前は ChatGPT や Claude に一つ質問して、画面を閉じれば仕事も終わっていた。今の Agent は、ブラウザを開き、ファイルを読み、ツールを動かしながら、画面を離れた後も作業を続けられる。
だから新しい道具を見るときは、四つの問いから始める。どこから頼むのか、どこで動くのか、何に触れられるのか、どの時点で自分の確認に戻るのか。
これは製品ランキングではない。dots は現在、デプロイや日々のスキャンを任せる主力として使い方を模索している環境であり、Muse は過去の試用、OpenClaw は自前運用の検証、Grok Bot は公開資料の研究である。
- ENTRY
- どこから頼むか
- RUNTIME
- どこで動くか
- REACH
- 何に触れられるか
- REVIEW
- いつ戻るか
02
dots と Muse：読む量を先に整理しておく。
メール、授業資料、求人情報の最初の整理を任せても、送信は自分の手に残す。
dots は現在、日々の作業で最も使っている環境だ。GitHub から Vercel へのデプロイ補助、メールやリマインダーの確認、資料収集や調査、日々の定期スキャンを任せている。まだ使い方の可能性を模索している段階であり、勝手に本番へ反映させるのではなく、確認や下書きを自分の手元へ戻す形で使っている。
Muse が登場した頃には、Notion、Email、履歴書の資料を渡し、求職情報を整理して大量の機会を絞り込むテストをした。これは仕組みを理解するための試用であり、正式な応募や送信を任せたわけではない。
クラウドコンピューターは作業を続けられる一方、アプリの接続、ブラウザのログイン状態、履歴データも新しい境界になる。普通のチャットに近い入口ほど、権限は意識して開ける必要がある。
| 手順 | READ | DRAFT | RETURN |
|---|---|---|---|
| メール・授業資料・求人 | 含む | 含まない | 含まない |
| 要約・週記・選考メモ | 含まない | 含む | 含まない |
| 送信前に自分で確認 | 含まない | 含まない | 含む |
| 手順 | 位置づけ | 入口 | 実行場所 | 停止点 |
|---|---|---|---|---|
| dots | 現在の日常主力・運用を模索中 | ChatGPT / App | Cloud computer + browser | デプロイや外部反映の前に自分が確認 |
| Muse | 過去の試用（求人・資料整理） | App / WhatsApp | Secure VM + browser | 応募前に自分が確認 |
| Grok Bot | 公式資料の研究。実運用は未経験 | Bot / web | Cloud Linux + terminal | handoff と権限分離が必要 |
| OpenClaw | 自前運用の研究・比較対象 | Discord | Gateway + NAS | 外部操作の前に戻す |
03
Grok Bot：共有コンピューターを研究対象として見る。
Grok Bot を自分の使用経験として書かず、公開された構成だけを整理する。
xAI の資料では、Grok Bot は名前、仕事、Context を持つ AI teammate として、常時動く cloud computer、browser、filesystem、terminal の中で動き、Bot 同士で仕事を引き継げると説明されている。
一つの Bot が止まったところから別の Bot が続けられ、ファイルや状態を移し直さなくてよい点は魅力的だ。一方で、共有コンピューターではファイル、ログイン状態、handoff の範囲を直感的に判断しにくい。
まだ正式なワークフローには入れていないので、ここでは構成上の問いだけを残す。共有ディレクトリを誰が見られるのか、handoff でどの Context が渡るのか、どの操作を人に戻すのか。
HANDOFF
状態を移し直さない
CONTEXT
好みと仕事を続ける
BOUNDARY
ファイルとログインを分ける
04
自前運用の検証：Discord → OpenClaw → KIROKU / NAS。
クラウド製品と比べるための基準として、自前で構築した流れを振り返る。
一つの記録を残すために、複雑な管理画面を開きたくはない。Discord は軽い入口で、短い一言を OpenClaw Gateway が受け取り、固定スクリプトが形式と繰り返し取得を処理し、LLM が要約・分類・意味の整理を担う。
結果は KIROKU と NAS に書き込み、後から戻って検索し、分類が崩れていないか確認できる。決定的な処理と意味を理解する処理を分け、同じ形式を毎回モデルに推測させないようにした。
自前運用の代償も明確だ。Gateway の権限、plugin、shell、node execution、更新、バックアップを自分で維持する必要がある。自分の機械に置いたからといって、安全になるわけではない。
- 01
CAPTURE
Discord に一言
- 02
ROUTE
OpenClaw Gateway
- 03
SCRIPT
形式・取得・反復作業
- 04
LLM
要約・分類・理解
- 05
STORE
KIROKU / NAS → 人が確認
05
三つの停止点：任せても、最後の一歩は自分に残す。
自動化してよい仕事、見てから送る仕事、代行させない仕事に分ける。
メールを読み、授業資料を整理し、要点を抜き出し、分類し、ノートの下書きを作るところまでは自動化できる。結果は KIROKU に戻し、後から探せるようにする。
正式な返信、課題の最終稿、外部に公開する記事や PR は、自分が読んだところで止める。Agent が前半の整理を進めても、言葉、相手、タイミングは自分が確認する。
支払い、アカウント削除、認証情報の公開、正式なデータベースの削除や上書きは、一つのプロンプトだけで通してはいけない。そこはツールやシステム側に残す停止点だ。AI は画面を離れた後も働けるが、結果を受け入れ、責任を持つのは自分である。
- AUTO
- 整理・分類・下書き
- REVIEW
- 返信・課題・記事・PR
- BLOCK
- 決済・削除・認証情報・上書き