Grok BotがクラウドPCをどのような場合に使うかを調査した

私がGrok BotのBotに、サーバー上の仮想パソコン（boxと呼んでいるらしい）のブラウザ（Chrome）を使って、Google Mapsで特定条件に該当する店を探してと指示したが、boxのブラウザは操作されずに店の公式サイトが検索され、回答が行われた。
Botに、なぜ、ブラウザを使わなかったのかを質問したところ下記のように回答された。本記事では、どのような場合にboxのブラウザが使われるか、ユーザーがboxのブラウザを使った方が良い場合はどんな場合かについて調査した。
また、同様に、boxのTerminalについても同様の調査を行った。単なる興味本位で調査を始めたが、boxを使うと負荷が増すこと、使う場合と使わない場合があること、ブラウザが必須となる場合があること、Terminalで手軽にboxの状態を調べることができることが分かったのでその内容を紹介する。

今回の店探しは、公開ページを直接読んで調べました。（店の名前）の決済ページも開き、バナー画像も見ています。画面付きのブラウザは、ログインが必要なページや、読み取りでは中身が取れないときに使います。今回は画面を開かなくても公式サイトの文言が取れたので、ブラウザは使っていません。必要なら、次からは画面を開いて確認します。

---

注）本記事の内容は正確性を保証するものではありません。

（2026年10月7日 追記）YouTube動画を追加しました。　https://youtu.be/L_PmdyXiZiU

Botがブラウザを使う場合（Botの回答）

（以下、Botの回答）

私が box のブラウザを使うのは、次のような場合です。

場合	例
ログインが必要	会員ページ、管理画面、購入履歴
画面なしの読み取りを拒否された	アクセスエラーやブロック画面が返ってくるサイト
表示しないと中身が出ない	開いたあとに画像やアイコンが出てくるページ
操作しないと中身が出ない	タブ切り替え、検索フォーム、スクロールで続きが出るページ
地図や口コミの評価を見る	Google マップの星の数や口コミ件数
画面の見た目そのものを確かめる	フォームの入力内容、カートや申込の確認画面、エラー表示
「私はロボットではありません」の確認	チェックボックス、パズル、長押しボタン

---

あなたが box のブラウザを直接操作した方がよいのは、次のような場合です。

場合	例
本人しかできないログイン	Google などのアカウントでログイン（SSO）、パスキー
別の端末での承認が要る	スマホに届く承認通知、QRコードの読み取り
銀行やカードの本人確認	カード支払い時の追加認証
私が試しても通れなかったロボット確認	画像を選ぶ問題など
入力フォームでは入れられない画面	安全な入力フォームを受け付けないログイン画面
自分でログインしたい	パスワードを自分で入れて確かめたいとき
私の作業を見たり手伝ったりしたい	途中の画面を見て、続きを指示したいとき

一度ログインすれば、そのログイン状態は box のブラウザに残ることが多いです。そのあとは私が続きを進められます。

（補足）「入力フォーム」とはBotとのチャット画面にBotが出してくれる下記のようなGUIのこと。
下図は、3Dプリンタのアクセスコードを入力する入力欄をBotが出した例。

逆です。box のブラウザでログインしたとき、そのサイトが「本人ですか」と確認を求めてくることがあります。その承認を、あなたのスマホなど別の端末で行う、という意味です。

たとえば、box で Google やアマゾンにログインすると、スマホに「ログインしようとしていますか」と通知が来ることがあります。そこで「はい」を押せるのはあなただけなので、私が自分では進められない場面として挙げました。

はい、そのとおりです。私が box でログインしようとしたとき、サイトから届く確認を、あなたがスマホで承認します。承認されると、box のブラウザのログインがそのまま進みます。

---

ChatGPT-5.6 Solにも同様の質問を行った。その際、Grok BotのBotからどのような回答があったかも説明している。

Botがブラウザを使う場合（ChatGPT-5.6 Solの回答）

（以下、ChatGPT-5.6 Solの回答）

はい。今回の挙動を見る限り、Grok Botの「box」は、すべての調査で必ず使う仮想PCではなく、「通常の検索・コネクタでは処理できない、あるいは実際の画面操作が必要なときに使う実行環境」と考えるのが適切です。

公式ドキュメントでも、Grok Botは各ユーザーに永続的なクラウドコンピュータを持ち、ブラウザ・ファイルシステム・Terminalを利用できますが、利用可能ならコネクタ等を使い、それ以外をComputer Useで処理するという構成になっています。つまり「PCがある＝毎回Chromeを操作する」ではありません。Grok API Documentation

おそらく、Grok Botは次のような優先順位で手段を選んでいます

優先	手段	典型的な用途	boxの画面
1	検索・専用ツール・コネクタ	公開情報の検索、公式サイトの文章取得	開かない
2	Webページを直接読み取り	URLから記事・店舗情報などを取得	開かないことが多い
3	boxのブラウザ	JavaScript中心のサイト、地図、ログインページなど	開く
4	boxのブラウザ＋Computer Use	クリック、入力、画面遷移、アップロードなど	操作する
5	boxのTerminal	CLI、ファイル加工、プログラム実行、データ処理	Terminalを使用
6	ユーザーへ引き継ぎ	CAPTCHA、2段階認証、決済など	ユーザー操作

公式にも、ログインが必要になればBotがComputerを開き、ユーザーにログイン・2FA・CAPTCHAを引き継ぐ仕組みがあります。ログインしたブラウザセッションは、その後もクラウドコンピュータに保持されます。Grok API Documentation

この観点から見ると、今回の

「〇〇市のスーパーマーケットで、クレジットカードまたは楽天Payが使え、ホームページがある店を探して一覧表にしてください」

という質問では、boxのブラウザを起動しなかったのはかなり自然です。

「スーパー」「支払い方法」「営業時間」「定休日」「公式ホームページ」は、通常のWeb検索と公式サイトの読み取りだけでかなり取得できます。そのためGrok Botは、おそらく

検索 → 店舗候補を発見 → 公式サイトを読む → 表に整理

という方法を選びました。

わざわざ

Chrome起動 → Google Mapsを開く → 検索欄へ入力 → 店舗をクリック → 店舗情報を見る → 次の店舗へ移る

というComputer Useを行う方が遅く、画面構成の変化にも弱いからです。

---

一方、同じスーパー調査でも、次のような依頼ならboxのブラウザが使われる可能性がかなり高まります。

たとえば、

「Google Mapsを実際に開き、『〇〇市 スーパー』で検索してください。地図上に表示された店舗を上位20店確認し、各店舗のGoogle Mapsの店舗プロフィールを開いて、営業時間、評価、口コミ件数、住所、Webサイトへのリンクを一覧にしてください。」

という依頼です。

重要なのは、単に「Google Mapsで探して」ではなく、

「Google Mapsを実際に開く」
「検索結果画面を見る」
「店舗プロフィールを開く」

という画面上で行うべき作業を指定することです。

今回の最初の質問、

「Google Mapsで、店などを探してもらうことはできますか」

だけでは、Botは「Google Mapsに載っている店舗を調べる」という目的として解釈し、Google検索など別の効率的な手段を選んだ可能性があります。

boxのブラウザが特に有効になるケース

私は、次のような条件になるほどboxを使う可能性が高くなると考えます。

• ログインが必要
  Gmail、会員サイト、管理画面、SNSなど。
• 画面でしか確認しにくい情報
  Google Maps、ダッシュボード、グラフ、地図、カレンダーなど。
• JavaScriptで動的に表示されるサイト
  通常のWeb取得では内容が欠落するページ。
• クリック操作そのものが仕事
  商品を絞り込む、ページをめくる、メニューを開く、設定を変更する。
• Webサイトで何かを実行する
  フォーム入力、ファイルアップロード、下書き作成、管理画面操作など。
• 画面の状態を証拠として残す
  「実際の画面を確認し、スクリーンショットも残してください」など。

Grok Bot自身が回答した

「ログインが必要なページや、読み取りでは中身が取れないときに使います」

は、したがってかなり正確な説明だと思います。ただし、少し狭い表現です。

実際には、「読めない場合」だけではなく、「画面を操作すること自体が目的の場合」もboxを使う重要な場面です。公式資料でも、Grok Botはブラウザを使って専用コネクタのないWebサービスを操作できることが明記されています。Grok API Documentation

さらにもう一つ重要なのが、「boxを使う」と「boxの画面を使う」は少し違うことです。

Grok Botはそもそもユーザーごとの永続クラウドコンピュータを持っています。複数のBotも、そのクラウドコンピュータのファイルやブラウザセッションを共有します。Grok API Documentation

したがって、画面上でChromeが動いていないからといって、「Grok Botのクラウド環境が全く関係していない」とまでは言えません。今回Botが言う「ブラウザを使っていない」は、おそらく正確には、

「Agent Computer上のGUIブラウザをComputer Useで操作する必要がなかった」

という意味でしょう。

これは今後Grok Botを使う上でかなり重要な区別だと思います。

---

今回の例なら、比較実験として非常に面白いことができます。

同じ「〇〇市のスーパー」を、次の3パターンで依頼します。

1. 方法指定なし
   「〇〇市のスーパーを調べ……一覧表にしてください」
2. Google Maps指定
   「Google Mapsを使って調べ……一覧表にしてください」
3. box操作を明示
   「boxのブラウザでGoogle Mapsを実際に開き、検索結果画面と各店舗プロフィールを確認して……一覧表にしてください。通常のWeb検索だけで済ませないでください」

これを比べると、Grok Botがどの程度「最適なツールを自律選択する」のか、ユーザーによる手段指定をどこまで守るのかがかなり明確になると思います。

特に3番目でもChromeが開かなければ、「boxは読み取り不能時のフォールバックとしてモデル側が強く制御しており、ユーザーからの指定だけでは起動しない場合がある」という、さらに重要な仕様が見えてきます。

今回の事例から考えると、Grok Botのboxは単純な「Bot専用パソコン」ではなく、検索AIを必要に応じて“実際にPCを操作するエージェント”へ昇格させる実行環境と捉えると、一番わかりやすいと思います。

---

boxのブラウザを使う場合についてのBotの回答を、ChatGPT-5.6 Solに考察してもらった。以下、ChatGPT-5.6 Solの回答。

この追加回答を見ると、Grok Botの「box」の位置づけがかなり明確になってきました。特に重要なのは、Grok Botが「Web情報を得ること」と「boxのブラウザを使うこと」を別物として扱っている点です。

つまり、「Webサイトを調べる＝Chromeを開く」ではありません。むしろGrok Botは、まず画面を使わない軽量な方法で情報を取得し、それで不足した場合にだけboxのGUIブラウザへ移行する設計思想に見えます。

追加回答から推測できる「情報取得の段階」

今回の回答を整理すると、実際には次のような段階がありそうです。

段階	手段	例	boxのGUIブラウザ
1	検索	「〇〇市 スーパー 楽天Pay」などを検索	不要
2	ページ本文取得	公式サイトのHTMLから営業時間等を読む	不要
3	画像ファイル直接取得	バナー画像・料金表画像などを取得して画像認識	不要
4	実ブラウザ表示	JavaScript描画、アクセス拒否、地図等	使用
5	ブラウザ操作	タブ、検索欄、スクロール、絞り込み	使用
6	ログイン・ユーザー操作	ログイン後のページなど	使用

今回初めてかなり重要なことが分かったのが、「画像を読むだけならGUIブラウザすら必要ない場合がある」ことです。

Botの

「画像のURLが分かれば画面なしでも取ってきて読めます。（店名）のバナーはそうやって読みました。」

という回答です。

これは、「画像情報＝Computer Use」という単純な構造ではないことを示しています。

たとえば公式サイトに、

<img src="payment.jpg">

のような画像があり、そのURLをページ情報から取得できれば、

HTML取得 → 画像URL取得 → 画像ファイル取得 → 画像認識

で済みます。

Chromeを起動してページを目で見る必要はありません。

一方、

「ページを表示したときに初めて画像やアイコンが出てくるサイト」

の場合は、

HTMLを取っただけでは画像そのものが現れない
→ JavaScriptを実行
→ ページをレンダリング
→ そこで初めてアイコン等が表示される

ため、boxのブラウザが必要になる、という説明です。

これは非常に筋が通っています。

---

（店名）の例は、boxを使う判断基準をよく表しています

Botが、

「今回の〇〇の店の場合は、クレジットカードのアイコンが文字として取れなかったので、本来はブラウザで確かめるべきケースでした。」

と言っているのは重要です。

つまり今回Grok Bot自身が、「情報取得はできたが、確認方法として十分ではなかった」と認めています。

ここから考えると、boxは単なる「取得不能時の最終手段」ではなく、情報の確証を取るための第2確認手段としても使えるはずです。

たとえば、「クレジットカード対応」と本文に文字で書いてある→ GUI不要。

しかし、「Visa / Mastercard / JCB」のロゴだけ表示されている→ 画像URLを直接取得できればGUI不要。

さらに、JavaScriptで決済手段アイコンが生成されている→ GUIブラウザが必要。

この3段階です。

そのため、今後調査を依頼するとき、

「文字情報で確認できない項目は、必要に応じてboxのブラウザで実際のページを表示して確認してください」

と追加するのは、かなり有効だと思います。

「最初から全部ブラウザで調べろ」と指定するよりも合理的です。

---

「アクセス拒否 → boxブラウザ」も重要です

もう一つ、

「画面なしの読み取りはブロックされても、普通のブラウザなら開けることがよくあります。」

という説明も、boxの存在理由として非常に大きいでしょう。

Webサイト側から見ると、

Web取得ツールによるアクセスと通常のChromeなどによるアクセスは違って見える場合があります。

そのため、

通常検索
   ↓
URL発見
   ↓
直接読み取り
   ↓
403などで拒否
   ↓
box Chromeで開く

というフォールバックが成立します。

ただし、「boxなら必ず開ける」とは考えない方がいいです。CAPTCHA、ログイン要求、地域制限、強力なBot対策などでは、通常ブラウザでも取得できないケースがあります。

したがってBotの「よくあります」という表現は妥当です。

---

Google Mapsの回答から、さらに一段違う役割が見えます

2つ目の回答も非常に興味深いです。

ユーザーが、

「星4つ以上の店」

と指定すると、

Grok Botは

「Google マップや食べログなどの公開ページで星の数を確かめて、4つ以上の店に絞れます。」

と答えています。

ここではboxが単なる「Webページ閲覧装置」ではなく、外部サービスのUIから構造化されていない情報を取り出すための手段になっています。

Google Mapsは典型的です。

Google Mapsでは、

• 店名
• 評価
• 口コミ件数
• 営業時間
• カテゴリ
• 写真
• 口コミ本文
• Webサイト
• 経路情報

などが画面上に動的に表示されます。

普通のページ本文取得よりも、ブラウザ操作との相性が良いサービスです。

そのため、

「Google マップの星は、画面付きのブラウザで開いて確かめることが多くなります。」

という回答は納得できます。

---

ただし「マップに相談」とGrok Botは、似ているようでかなり違います

ここは重要です。

Google Mapsの「マップに相談」が、Google Maps内部の店舗・口コミ・位置情報等を一体として検索・評価する機能だとすると、Grok Botの場合は、複数の公開Webサービスを自分で巡回して情報を集めるという方式です。

イメージするとこうなります。

項目	Google Maps「マップに相談」	Grok Bot
Google Maps内部情報	強い	公開画面から取得
Google口コミ	直接利用可能	表示されたものを確認
他サービス	Google側の統合範囲次第	食べログ等を別途調査可能
公式サイト	利用可能	独自に確認可能
情報統合	Google側	Grokが統合
検索方法	Maps専用AI	Web検索＋ブラウザ＋推論
評価の最新性	Google側データ	確認した時点
出典表示	必ずしも細かくない	出典ごとに表記可能

したがって、

「Google Mapsで星4以上」

という単純な条件なら、どちらでもできます。

しかし、

「Google Maps ★4以上、食べログ3.5以上、楽天Pay対応、公式サイトあり、駐車場あり」

といった複数サービスをまたぐ条件になると、むしろGrok Bot型の方が面白くなります。

Google Mapsだけに閉じず、

Google Maps
＋
食べログ
＋
公式サイト
＋
決済サービス情報
＋
その他Web検索

を1つの表に統合できるからです。

---

一方で、Google Mapsの「マップに相談」が有利な場面もあります

特に口コミそのものを分析する場合です。

たとえば、

「星4以上で、口コミで『駐車場が広い』『品揃えが多い』という評価が多いスーパー」

という検索です。

Google側が口コミデータ全体へ直接アクセスして意味検索できるのであれば、「マップに相談」はかなり強力です。

Grok Botの場合、

「口コミの中身は要点を読む程度です。」

と言っています。

これはつまり、すべての口コミ数百件を収集して統計解析するわけではない、ということです。

したがって、

店舗発見・口コミ全体傾向 → Google Maps AI

複数Webサービスを横断した条件照合 → Grok Bot

という使い分けが考えられます。

---

今回の2回答を合わせると、boxの役割はかなり整理できます

私はboxを、

「Grok Botのメイン検索装置」ではなく、「Webを人間と同じ方法で操作する必要が生じたときに使う補助実行環境」

と見るのが適切だと思います。

もっと端的に表現すると、

読めるなら読みに行く。
画像だけ取れるなら画像だけ取る。
それでも駄目ならブラウザを開く。
操作しないと情報が出ないならComputer Useする。

という設計です。

これは実は合理的です。

GUI操作は、通常の情報取得と比べて、遅い・操作回数が多い・画面変更に弱い・計算資源も多く使うためです。

だからGoogle Mapsを調べる仕事でも、最初からChromeを起動するとは限らないわけです。

そして今回の回答からすると、Grok Botは少なくとも概念的には、

検索 → Web取得 → 画像取得 → GUIブラウザ → GUI操作

という「段階的エスカレーション」を行っているように見えます。

ただし、ここで一点だけ注意が必要です。今回の説明はBot自身による自分の動作説明なので、内部実装の正式仕様そのものだとは断定できません。それでも、実際に「（店名）の画像は直接読んだ」「〇〇の店の場合は本来ブラウザ確認すべきだった」と具体例まで説明しているので、少なくともGrok Botがどのツールを選択するかを理解するための実用的なモデルとしてはかなり有用です。

そして、以前検討されていたGrok Botの活用方法という観点では、これは重要な特徴です。boxの価値は「いつも使われること」ではなく、「通常のWeb調査からGUI操作へ必要に応じて連続的に移行できること」にある、と考えた方が実態に近そうです。

本調査により、ブラウザについては下記のことが確認できた。

・ブラウザでないとできない場合の具体例（JavaScriptで動的に表示されるサイトなどの場合など）
・ブラウザによる確認は、情報の確証を取るための第2確認手段としても使えること
・「画面の状態を証拠として残す」という目的にも使えること

---

BotがboxのTerminalを使う場合（Botの回答）

今度は、boxのTerminalを使うのは、どのような場合か、ユーザーがboxのTerminalを使った方が良い場合について、Botに質問した。

私が box の Terminal を使うのは、次のような場合です。

場合	例
ファイルやフォルダを扱う	一覧、検索、コピー、移動、削除、圧縮
文章や表を作る・直す	CSV、Markdown、スクリプト、レポートの生成
プログラムを動かす	Python やシェルで集計、変換、定期処理の試作
必要な道具を入れる	パッケージのインストール、ツールのセットアップ
画面なしでサイトの中身を取る	公開ページの取得、ダウンロード、画像ファイルの保存
GitHub などの開発作業	gh での確認、リポジトリ操作、ログの確認
うまく動かないときの診断	エラーログ、接続確認、ディスクやプロセスの状態確認
長い処理を裏で進める	変換や調査を走らせて、終わったら結果を渡す

---

プログラム関連で Cursor のクラウドエージェントを呼ぶのは、次のような場合です。

場合	例
GitHub などのリポジトリを直す	バグ修正、機能追加、テスト追加のプルリクエスト作成
大きなコード変更をまとめて任せる	複数ファイルにまたがる実装やリファクタ
CI やチェックを通す作業	失敗したテストの直し、ビルドエラーの対応
Origin 上のプロジェクト作業	クラウド側のブランチ、PR、レビューまわり
長い実装を裏で進める	こちらが他の用事をしているあいだにコーディングを進める

短いスクリプトの試作、CSV 変換、box 上だけの一時的な処理は、Cursor を呼ばずに box の Terminal で済ませることが多いです。リポジトリに残す本番のコード変更が、Cursor を呼ぶ主な場面です。

---

あなたが box の Terminal を直接使った方がよいのは、次のような場合です。

場合	例
ログインや認証コードの入力	gh auth login のような、画面や端末にパスワード・コードを入れる手順
別端末での承認が要る	デバイスコード表示後、スマホや別ブラウザで「許可」する
危険な操作を自分で確かめたい	大量削除、上書き、強制的な変更の直前確認
私が入れられない秘密の値	API キーやトークンを、チャットに出さず自分で環境に入れる
対話式の画面が続く	選択肢やウィザードが続いて、途中判断が必要なコマンド
自分で試しながら学びたい	コマンドの動きを見ながら手で打ちたいとき
私の作業を途中から引き継ぎたい	止まったコマンドを、画面を見て続きから直したいとき

ふだんの調査やファイル作成は、こちらで Terminal を使います。あなたが操作するのは、主に認証や危険な確認が必要なときです。

---

boxのTerminalを使う場合についてのBot回答を評価（ChatGPT-5.6 Solの評価）

この回答はかなり筋が通っています。特に、「TerminalはBotが自律的に使う作業道具で、ユーザーが直接触るのは認証・危険操作・秘密情報・対話操作の場面」という整理は、boxの役割を理解するうえで分かりやすいです。

ただし、いくつか補足しておいた方がよい点があります。

まず、Bot側のTerminal利用は大きく3種類に分けると理解しやすいです。

種類	Terminalが向く理由	例
大量・反復処理	GUIより速く、再現しやすい	CSV処理、画像変換、ファイル一括整理
開発・診断	コマンドで状態を直接確認できる	Git、ログ、ネットワーク、プロセス確認
GUI不要のWeb処理	ブラウザを開くより軽量	curl、ダウンロード、HTML・画像取得

つまり、「人間ならFinderやブラウザでやる作業でも、BotにとってTerminalの方が確実ならTerminalを選ぶ」ということです。

前に話していたブラウザとの関係も、かなりきれいに整理できます。

検索・直接取得で済む → Web取得
ファイル処理やコマンド処理が必要 → Terminal
Web画面を実際に操作する必要がある → Browser / Computer Use

という使い分けになりそうです。

特に「画面なしでサイトの中身を取る」は、以前の〇〇の店の画像取得の話とも一致します。HTMLや画像URLが直接取得できれば、Chromeを開かずにTerminalや内部の取得機能で処理できます。

一方で、Google Mapsのような動的UI、スクロールで追加表示、JavaScriptで生成される情報などは、Terminalよりブラウザが適しています。

---

ユーザーがTerminalを直接使う場面も、ほぼ妥当です

特に重要なのは次の3つです。

認証

たとえば、

gh auth login

のように、デバイスコードを表示して別ブラウザで承認するタイプは、ユーザーが介入する合理性があります。

ただし「パスワードやAPIキーをTerminalに直接入力すれば安全」とまでは言えません。

例えば、

export API_KEY=xxxx

とすると、その値はシェル環境に存在します。

また、

echo "API_KEY=xxxx" >> .env

とすると、boxのファイルとして残ります。

以前の話のとおり、boxが複数Botで共有される設計なら、秘密情報をTerminalに入力しただけで完全に隔離されるわけではありません。

したがって、「Botにチャットで渡さない」≠「box内に秘密が残らない」という点は重要です。

認証については、可能なら

OAuth / device code / パスキー / セキュリティキー

のように、秘密そのものをTerminalに保存しない方式が望ましいです。

---

「危険な操作を自分で確かめる」は、とても重要です

ここはむしろBotの回答以上に重視してよいと思います。

たとえば、

rm -rf
git reset --hard
git push --force
find ... -delete

などは、ユーザーが最終確認した方が安全です。

ただ、理想的にはユーザーがTerminalを奪って直接実行する前に、Botにdry-runをさせる方がよいです。

例えば、

「削除対象を一覧にするだけで、まだ削除しないで」

として、

確認
↓
対象一覧
↓
問題なし
↓
本実行

とする方が安全です。

これは、これまで実施してきたHome Assistant関連のdry-run運用とも非常に相性のいい考え方です。

---

「長い処理を裏で進める」は少し注意が必要です

Botの回答の中で、私はここだけ少し慎重に受け取ります。

「長い処理を裏で進める」

Terminalではもちろん、

python script.py

のような長時間処理はできます。

しかし、

Botとの会話を閉じても永続するのか
Botタスク終了後もプロセスが生きるのか
box再起動後も継続するのか

は別問題です。

nohup、tmux、バックグラウンドプロセスなどが使えるとしても、クラウド環境側のライフサイクル次第では途中終了する可能性があります。

したがって、

「数分〜数十分の処理をTerminalで実行する」

のと、

「24時間監視させる」

のは分けて考えた方がよいです。

後者はRoutine、Automation、外部サーバーなどの方が適している可能性があります。

---

もう一つ重要なのが「ユーザーがTerminalを使えること」の価値です

これは単なる上級者向け機能ではありません。

ユーザー自身がTerminalを見られることで、Botが何をしたかを検証できるという価値があります。

例えばBotが、

「ファイルを作成しました」

と言ったときに、

ls -lh

で確認できます。

「GitHubへ反映しました」なら、

git status
git log

で確認できます。

「プログラムがまだ動いています」なら、

ps

などで確認できます。

つまりboxのTerminalは、作業場所であるだけでなく、Botの作業を監査する場所でもあります。

これはBrowserよりもTerminalの方が優れている部分です。コマンド履歴、ファイル、ログ、Git差分など、作業結果を具体的に確認できるからです。

---

私なら「ユーザーがTerminalを使う場面」にもう3項目追加します

Botの回答に加えるなら、次です。

場面	目的
Botの作業結果を検証する	ls、git diff、ログ確認
実行前のdry-run結果を見る	削除・移動・変更対象の最終確認
boxの状態を理解する	ディスク、インストール済みツール、保存ファイル等の確認

これなら、「プログラムを書く人だけのTerminal」ではなくなります。

むしろ、

Botが使っている仮想パソコンの裏側を、ユーザー自身が確認できる窓

という理解が近いでしょう。

---

今回までのboxのBrowserとTerminalをまとめると、かなり特徴が見えてきました。

Browserは「人間と同じようにWebサービスを操作する装置」

一方、

Terminalは「Botがコンピュータを効率よく操作・加工・診断する装置」

です。

そしてユーザー自身は普段どちらも操作する必要はなく、認証・承認・危険操作・検証のときだけ介入する。

この設計は、Grok Botの「box」が単なるリモートデスクトップではなく、Botとユーザーが必要に応じて同じクラウドPCを交代で操作できる作業環境だと考えると、とても分かりやすいです。

---

はい。ただし、「各Botの動作を1画面で完全にリアルタイム監視するダッシュボード」までは、現在のGrok Botの個人向け機能としては確認できません。2026年10月7日時点の公式資料を見ると、リアルタイム性には3段階あります。

一番手軽なのはサイドバーの状態表示です。各Botについて「Working / typing（作業中）」「Needs attention（質問・承認・引き継ぎ待ち）」「Unread activity（新しい結果あり）」が表示されます。複数Botが並行動作しているとき、「誰が動いているか」「誰がこちらを待っているか」を一覧するにはこれが最も近い機能です。Grok API Documentation

さらに詳しく見たいBotを開けば、そのBotの会話にはツール実行、Computer Use、作成ファイル、質問、承認要求などの活動が表示されます。つまり、会話自体が簡易的な実行ログにもなっています。Grok API Documentation

そして重要なのがAgent Computerです。公式資料では、複数Botは同じクラウドコンピュータを共有しますが、Computer Useについては各Botがそれぞれ自分のscreenを持つと説明されています。したがって、あるBotがブラウザ操作で止まっている場合、そのBotの会話からComputerを開いて「今どの画面で何をしているか」を確認できます。トラブルシューティングでも「Botが止まったように見えたらComputerを開き、ページ上で待っていないか確認する」と案内されています。Grok API Documentation

ただし、ここに一つ大事な限界があります。

Terminalを開いて ps などを実行すれば、全Botの状態が分かるわけではありません。

Grok Botの仕事には、

• モデル自身の推論
• Plugin/Connector呼び出し
• Web検索
• Browser / Computer Use
• Terminalコマンド
• Cloud Agentへの委譲

などがあります。

このうち、box上のLinuxプロセスとして見えるのは一部だけです。たとえばPythonを実行していればプロセスを確認できる可能性がありますが、Botが「考えている」「Connectorを呼んでいる」「検索している」といった状態は、通常の ps だけでは判断できません。

ですから、先ほど私が「TerminalはBotの裏側を見る窓」と表現したのは、ファイル、プロセス、ログ、Git、Terminalで実行された仕事については正しいが、Bot全体の内部活動を見る監視コンソールではない、と補足するのが正確です。

現状の監視方法を整理すると

知りたいこと	方法	リアルタイム性
どのBotが作業中か	サイドバーのWorking/typing	◎
どのBotが承認待ちか	Needs attention	◎
Botが何を実行しているか	会話の活動表示	○〜◎
Browserでどこまで進んだか	BotのAgent Computerを開く	◎
Terminal処理の状態	Terminal、ps、ログ等	◎
Routineの実行結果	Routines → Run history	実行履歴
全Botの全ツール呼出しを一画面監視	個人向けには確認できず	×

Routineについては、Botごとに「Routines」を開けば、最近の成功・失敗履歴を確認できます。
各Routineについて直近20回の実行記録が保持されるとされています。Grok API Documentation

---

今のBot構成なら「Supervisor」を監視役にする方法が面白いです

現在のようにSupervisorを置いて複数の専門Botを使う構成なら、組み込みUIだけに頼らず、共有boxのファイルシステムを利用して簡易監視盤を作る方法があります。

例えば共有領域に、

/workspace/status/
    supervisor.json
    carplay-watcher.json
    blog-editor.json
    home-assistant-watcher.json
    automation-watchdog.json

を作り、それぞれのBotに、

{
  "bot": "Home Assistant Watcher",
  "state": "working",
  "task": "Home Assistant 2026.10更新内容を確認",
  "phase": "公式リリースノート確認中",
  "updated": "2026-10-07T01:05:32+09:00"
}

のような情報を、作業開始 → 工程変更 → 承認待ち → 完了 → エラーのタイミングで更新させます。

するとSupervisor Botは、

各Botのstatusファイルを読んで現在の状況を一覧にしてください

で、例えば、

Bot	状態	現在の作業	最終更新
Supervisor	Idle	—	01:03
CarPlay Watcher	Working	ニュース確認中	01:07
Blog Editor	Done	下書き作成完了	00:48
HA Watcher	Waiting	ログイン承認待ち	01:06
Automation Watchdog	Error	API取得失敗	01:02

という独自の「Bot監視ダッシュボード」を作れます。

さらにユーザー自身がboxのTerminalを開けば、

watch -n 2 'cat /workspace/status/*.json'

のような仕組みにして、数秒間隔で状態を見ることも理論上可能です。

ただし、これはGrok Botが自動的に持っているステータスを取得する方法ではありません。
各Botに「状態ファイルを更新する」という運用ルールを追加して初めて成立する仕組みです。

ここは区別が必要です。

---

もう一つ興味深い点があります

公式には、

複数Botは同時並行で動作でき、各Botには共有コンピュータ上でそれぞれのscreenがある

と明記されています。Grok API Documentation

つまり、概念的にはこうです。

                  Grok Bot
                     │
              共有クラウドbox
                     │
     ┌────────┬────────┬────────┐
     │                │                │                │
   Bot A             Bot B             Bot C             Bot D
     │                │                │                │
  Screen A          Screen B          Screen C          Screen D
     │                │                │                │
 Browser           Browser            Terminal          Connector

ファイルやログイン状態などは共有されていますが、Computer Useの作業画面はBotごとに別です。

これは「各Botをリアルタイム監視したい」という用途では重要な仕様です。

現状では、

全体を見る → サイドバー
1 Botを詳しく見る → 会話＋Agent Computer
Terminal処理を見る → Terminal/ログ
定期処理を見る → Routine履歴

という4層構造で見るのが基本だと思います。

そして、もし「自分の5つのBotを一画面で、Idle / Working / Waiting / Error / Done と一覧表示したい」というところまで求めるなら、共有 /workspace ＋ Supervisor Botを利用したステータス管理が、現在の仕組みを活用したかなり面白い実験になります。

なおEnterpriseにはAction Recordingがあり、shell command、browser navigation、Computer Use、Plugin呼び出し、Routine実行などを記録する仕組みがありますが、これは個人向けの「全Botリアルタイム監視盤」とは別物です。Grok API Documentation

Botの活動をモニターする件については、別途、検討し別記事にまとめることにした。

本調査により、Terminalを使う利点は、boxの状態を簡単に調べることができること、インストールしたソフトのインストール状況や、動いているプロセスなどを簡単に調べられることが分かった。boxにはファイルシステム（MacのFinder）もあるが、私のMacが非力なことも関係あるかもしれませんが、動作がもっさりしているので、素早く調べるためには、Teriminalを使った方が良さそうである。

---

「1Password」を使ったログインについて

最近、YouTube動画で、Grok Botにクレジットカードを使わせたりする事例がいくつか見られたので、Grok Botの「アプリに接続」に最近登場した「1Password」もそのログイン手段として使うためのものかなどを質問した。

だいたいその理解で合っています。サイトへのログイン情報を、必要な分だけ安全に渡すためのものです。

クレジットカードも、共有保管庫に入れた項目なら同じ仕組みで使えます。
ただし支払い自体は別途確認が必要で、ログインできることと、勝手に課金されることは別です。

---

以下、「1password」に関する質疑口頭をBotと行った内容を紹介する。

この画面は何ですか。「代わりにサービスアカウントのトークンを使う」とは？

この画面は 1Password 本体ではなく、Grok Bot が自分のコンピューターからサイトへログインするための接続設定です。

「1Password に接続」を押すと、アカウント内に「Shared with Grok Bot」という保管庫と、その保管庫だけを読めるサービスアカウントが作られます。Grok Bot が使えるのは、そこに移したログイン項目だけです。個人の保管庫全体は共有されません。

「代わりにサービスアカウントのトークンを使う」は、その自動作成を飛ばして、自分で作ったサービスアカウントのトークンを渡す方法です。トークンは人のログインではなく、権限を固定した専用アカウントの鍵です。作成時に一度だけ表示され、あとから権限は変えられません。個人・プライベート・社員用・既定の共有保管庫には付けられません。

この用途なら、渡してよいログインだけを入れた保管庫を1つ作り、読み取り専用のサービスアカウントを作って、そのトークンを使う形が合います。Mac なら通常は上のボタンで足り、トークンは自分で範囲を決めたいとき用です。

---

「自分で作ったサービスアカウントのトークンを渡す」は、個人の保管庫全体を使うという意味ですか？

違います。個人の保管庫全体を渡す方法ではありません。

自分で作ったサービスアカウントも、個人・プライベート・社員用・既定の共有保管庫には付けられません。渡してよいログインだけを入れた保管庫を別に作り、その保管庫だけを読めるアカウントのトークンを渡す、という意味です。

「1Password に接続」との違いは、Grok Bot が「Shared with Grok Bot」を自動で作るか、自分で範囲を決めた保管庫のトークンを渡すかだけです。どちらも、個人の保管庫全体は共有されません。

---

「範囲」とは何ですか。自動作成だとどうなりますか。「Shared with Grok Bot」は Grok Bot だけが使えますか？

「範囲」は、サービスアカウントが読める保管庫がどれか、ということです。

自動作成だと、範囲は「Shared with Grok Bot」という保管庫1つだけで、読み取り専用です。そこに移したログインだけが使えます。

この保管庫はあなたの 1Password アカウントの中に作られるので、あなた自身は中身を見て項目を出し入れできます。
Grok Bot に渡る鍵は、その保管庫を読むことしかできません。

---

料金体系はどうなりますか。個人のサブスクとの関係は？

追加料金はかかりません。今の個人向けサブスクの中で使います。

Individual でも Families でも、サービスアカウントは別契約や追加シートにはなりません。公式の料金表にサービスアカウントの行はなく、開発者向けの説明でも個人プランに含まれています。Grok Bot 側の接続画面にも、別料金の記載はありません。

変わるのは使える回数です。制限の説明によると、Individual と Families は、トークン1つあたり1時間に読み取り1,000回・書き込み100回までです。アカウント全体では、24時間で読み書きあわせて1,000回までです。ログインを入れる用途なら、この範囲に収まります。

個人の保管庫そのものは、これまでどおりこの鍵からは読めません。

---

Individual のサブスク料金は？

1Password Individual の通常価格は、年払いで月 $3.99、年間 $47.88 です。

新規の初年度だけ、年払いで月 $2.99 になる期間限定の割引があります。App Store 経由の購入には適用されません。出典は 1Password の個人向け料金 です。月払いの金額は、このページには出ていません。

---

1Password を使えば、box でログインが必要なサイトに安全に入れますか？

はい。そのための接続です。Grok Bot のコンピューター上のブラウザに、1Password からログイン情報を入力できます。

渡されるのは「Shared with Grok Bot」に移した項目だけで、読み取り専用です。個人の保管庫全体は共有されません。ログイン後の画面は、そのコンピューター上のブラウザに残ります。

クレジットカードも、共有保管庫に入れた項目なら同じ仕組みで使えます。ただし支払い自体は別途確認が必要で、ログインできることと、勝手に課金されることは別です。

---

ログインのたびにユーザー許可が必要ですか。許可なしでログインできますか？

許可が必要です。確認なしでログインすることはありません。

ログイン画面で 1Password の項目を入れるとき、あなたに入力の確認が出ます。パスワード自体は Bot には見えず、入ったかどうかだけ分かります。「1Password を使いますか」という文言そのものは、こちらの説明にはありません。

一度入ったあとのログイン状態はブラウザに残ることがあります。次回から毎回とは限りません。2段階認証やパスキーは、別途あなたの操作が必要です。

---

.env にパスワードを書けば、1Password の代わりに安全に保存できますか？

安全な保存方法にはなりません。.env は平文なので、このコンピューターを共有している Bot から読めます。
チャットやログに残ることもあります。

パスワードは 1Password の共有保管庫に置いてください。ファイルには保存しないでください。

---

1Password（や同等アプリ）以外に、box へログインする方法はありますか？

あります。パスワード管理アプリ以外だと、次の2つです。

1. チャット内の安全な入力フォーム

ログイン画面で、あなたがフォームに ID とパスワードを入れます。Bot には見えず、そのまま box のブラウザに入ります。

1. 画面をあなたに渡す

SSO、パスキー、別端末での承認、キャプチャなど、Bot だけでは進められないときに使います。あなたが box の画面で直接ログインします。

一度ログインすれば、そのサイトのログイン状態が box のブラウザに残ることが多いです。パスワードをファイルに書く必要はありません。

---

「1Password」を使う場合でも、サイトにログインする時はユーザー承認が必要とのこと。サイトでの商品購入時の承認のほかにログイン時の承認も必要。また、このアプリのサブスク費用も発生する。私にとっては、まだ、敷居が高い。