Grok Bot 設定：Studioなし、Model Pickerなし

今週、『私の Gro​k Bot スタジオ設定』——「my Gro​k Bot studio configuration」——という中国語の投稿が出回っている。そして、その言い回しこそが証拠だ。Gro​k Bot を実際に設定したことのある人なら、スタジオなど存在しないことを知っている。ドラッグ＆ドロップのビルダーも、ノードのキャンバスも、モデルを選ぶドロップダウンもない。Gro​k Bot は SpaceXAI の常時稼働エージェント製品で、2026年8月11日にローンチされた。その設定できる範囲はすべてテキストだ。説明フィールド、会話、そして話しかけて覚えさせられるものすべて。それは、ツールを乗り換えて回避できるような制約ではない。設定とはそもそも何なのかを変えてしまい、同じ構成を動かしているように聞こえる二人が、なぜまったく異なる結果を得るのかを説明してくれる。

タイミング的に、これは今書き留めておく価値がある。10月7日、イーロン・マスクはXへの投稿で、Gro​k BotはSpaceXAI自社のモデルに限定されるのをやめ、「あらゆるタスクに最適なバックエンドモデル」を求めるようになると述べ、Claude Opus 5.5、Midjourney、Sunoを挙げた——これは複数の媒体によって発言として裏付けられているが、料金表も変更履歴の項目も外部による測定も依然として伴っていない。2日後の10月9日には、Botごとのメールアドレスで、末尾が@mail.grokbot.comのものが展開され始めた。つまり、あなたの設定の土台にある製品は動いており、その動きがあなたの役に立つかどうかを決めるものは、昔から変わらず同じ、すなわちBot自体がどれだけ適切に指定されているかである。

手渡された信号とは実際には何なのか

この投稿は、ユーザーが自分のセットアップを披露しているもので、有益な読み方は字義通りではなく構造的だ。パターンはこうだ。機能するGrok Botの構成とは、書かれた職務記述書に加えて少数の保存された手順であり、一度だけ訪れる設定パネルではない。SpaceXAI自身のドキュメントは、この点について異例なほど率直だ。あるページには「セットアップはメッセージであり、ワークフロービルダーではない」と書かれている。スキルは「タスクの実行方法に関する再利用可能な一連の指示」と定義され、ルーティンは「1つのBotに、いつワークフローを実行するかを伝えるもの——スケジュールで、またはサポートされている場合はイベント後に」と定義されている。ドキュメントが示す推奨順序は、その方法全体を一行にしたものだ。「まず単発のタスクから始める。それを信頼できるものにし、方法をスキルとして保存し、そうして初めて自動化する。」

他のすべてのエージェント製品がビルダーUIを出荷していたから、という理由でビルダーUIを探していたのなら、その一文が答えです。ここでの設定成果物は、実際のタスクに触れても生き残る文章であり、ドキュメントには、良いものに何が含まれるべきかが正確に示されています。つまり、そのスキルをいつ使うか、必要な入力とアクセス、作業の順序、結果を検証する方法、何を返すか、そして何に承認が必要かです。

モデルピッカーは存在しない。そして、そこが興味深いところなのだ。

特定の Bot について Grok 4.7 と Claude Opus 5.5 のどちらを選ぶのかと尋ねると、ドキュメントはそっけなくこう答えます。「モデル選択は Cursor が管理するため、モデルピッカーはありません。」Bot ごとのモデル設定はなく、ルーティンごとのモデル設定も、スキルごとのモデル設定もありません。Bot 設定ページで扱うのは名前、ラベル、説明、アバター、通知設定で — これが Bot 単位の設定項目のすべてです — タイムゾーンは、ルーティンがスケジュールに必要とするため、アカウント レベルにあります。

つまり、マスクが10月7日に説明したルーティングは、自分で回すダイヤルではない。私たちが読めるドキュメントを見る限り、それはプラットフォーム側の決定であり、出力品質として、そして後で使用量メーターが示すものとして以外は、あなたには見えない。Grok Bot の上に設定を組もうとする人にとって、これは最も重大な単一の制約であり、率直に言っておく価値がある。あなたが制御するのは作業であり、エンジンではない。そのトレードオフを受け入れられるなら、製品は一貫している。あなたのワークフローが、コストのために、ライセンスのために、再現性のために、特定のモデルを意図的に必要とするなら、Grok Bot はその要件にとって間違った層であり、設定がそれを表現することは決してない。

セットアップを実際に制約する数値

ほとんどの設定に関する助言が曖昧なのは、ほとんどのエージェント向けドキュメントが曖昧だからだ。これらは曖昧ではなく、一つひとつに設計上の帰結がある。

• ボットあたりのルーティン — 50。ボットは「最大50個のルーティン」を所有でき、アプリは「各ルーティンの直近20件の実行記録」を保持するため、監査証跡は設計上浅いものになっています。

• 最小スケジュール間隔 — 5分。「定期スケジュールは少なくとも5分間隔でなければならない」ため、短い間隔のポーリングループは排除され、代わりにイベントトリガーへと静かに誘導されます。

• ティーチングは10分間記録します。「ティーチングは、最大10分間、画面上のコンピューター操作を記録します。マイクの音声は記録しません。」長い手順は複数のセグメントに分割する必要があります。

• Team Bot ごとのシークレット — 25、値は出力時にマスクおよび墨消しされ、ドキュメントでは Bot が「どのチームメイトの会話にあるシークレットでもすべて使用できる」と警告されている。つまり、シークレットはチーム全体に付与されるアクセス権である。

• コンピューターはBotごとではなく、アカウントごとに1台です。「アカウント上のすべてのBotが同じコンピューターを使用し」、それは「個々のBotではなく、あなたのユーザーアカウントに割り当てられ」、ファイルは共有の/workspaceに置かれ、「ファイルはすべてのBotから見ることができます」。各Botが見る画面は「別々のセキュリティ境界ではなく、別々の作業面」です。

最後に挙げたものが、人が最後に気づく制約です。これは、構成がアカウント全体のオブジェクトであることを意味します。あるBotに付与した権限はフリート全体が持つ権限であり、あなたのリサーチBotが書き込んだ永続ファイルは、あなたのアウトリーチBotから読み取り可能です。

ジョブを設定する前に、境界を設定してください

ドキュメント自体の自動化ガイダンスは、新しいセットアップの最初の10分間に行う価値のあることをまとめた短いリストです。書き込みは承認を経てから行うようにしましょう。「送信、購入、削除、公開、または本番システムの変更には承認を必須にしてください。」イベントのマッチング条件を狭く定義し、「『すべての新規メッセージ』のような広範なリスナー」は避けてください。これらはノイズを生み、使用量を消費し、無関係な入力に作用するからです。「テスト実行」ボタンを使う際は、「テスト実行は実際の処理を行います。ウェブサイトを操作し、ファイルを変更し、接続されたツールを呼び出すことがあります」ということを理解しておいてください。最初の無人運用の朝を迎える前に、データなしポリシーと古いデータのポリシーを書き留め、再試行を冪等にして、再実行で二重送信が起きないようにしてください。

次に削除の扱いです。これは取り消しがきかない唯一の操作だからです。「ルーチンの削除は即時に行われ、取り消しはできません」、そしてBotを削除すると「アクティブなプロファイル、会話、ルーチンが削除される」一方で、コンピューター上のファイルとサインインはBotごとに分離されておらず、残存する可能性があります。元に戻せる代替手段は非表示です。また、後から気づくのではなく事前に知っておく価値のあるライセンス上の厄介な点もあります。Botsのドキュメントには、バックエンドでの保持は適用されるCursorの規約に従うと記されており、これは規制対象のものを共有ワークスペースに詰め込む前に読んでおくべき一文です。

何が引き継がれ、何が引き継がれないか

複製は、同じロールを異なるスコープで実行するための最も安価な方法であり、ドキュメントはその継ぎ目について正確に説明している。複製すると「プロフィール、設定、スキル、ルーチン、アバター」が引き継がれ、明示的に「会話履歴、学習済みメモリ、チャット添付ファイルはコピーされない」。共有はさらに進んで、テンプレートを作成し、公開またはチーム限定のアクセスを選択すると、受け取った人はそれをプレビューしてコピーを追加できる——「あなたのマシン、ログイン情報、履歴は受け取らない」。共有する前に API キー、内部 URL、顧客データを除去すること。テンプレートには設定が含まれ、設定こそ人々が認証情報を隠す場所だからだ。

メモリにも同じ疑いの目を向けるべきだ。ドキュメントは、それを真実ではなく利便性として説明している。ソースシステム内の事実を変え続け、重要な判断ではBotに最新データを開き直させるか引用させ、安全制限はメモリが保持してくれると信じるのではなく説明文にエンコードする。チームBotは第2の層を加える — 全員の会話から読み取られるチームメモリと、特定の1人に紐づくプライベートノート — そして、課金に関する動かしがたい事実: 使用量は「そのチームメイト自身のGrok Bot利用枠に算入され、オーナーの利用枠には算入されない」。

ルーターがエージェントのふりをすることなく収まる場所

Gro​k Bot はサブスクリプション製品であり、サードパーティのエンドポイントを経由してルーティングできるようなものではありません。誠実な設定ガイドであれば、そう示唆することはないはずです。モデル希少性の問題が提起するのは、それとは別の問いです。エンジンを意図して選びたいのであれば、あなたは API アクセスを購入しているのであり、それは Bot とは別のレイヤーです。

そのレイヤーこそ、私たちが販売しているものです。OrcaRouterは、200以上のモデルに対応する単一のOpenAI互換エンドポイントであり、プロバイダーの定価にマークアップはありません。そのため、ベンダーによる値下げは当日ここに反映されます。Grok 4.7はその上に、SpaceXAI自身が公表しているレート、プロンプトトークン数が200K未満の場合で入力100万トークンあたり$2.00、出力100万トークンあたり$6.00で載っています。その閾値を超えると倍になります。投稿にあるような構成にとって重要なのは、実証されていないステップが本番インシデントになるのを防ぐ仕組みです。つまり、あるプロバイダーが劣化したときにプロバイダー間で自動フェイルオーバーすること、複数のモデルを1回の呼び出しに組み合わせるルーティングDSL、そして一緒に回答するパネル向けのモデルフュージョンです。そして「このBotはそもそもこの仕事をこなせるのか」という問いに対する実践的な一手は、地味なものです — スキルを書き、信頼しようとしていたモデルに対して一度手作業で実行し、それから初めて自動化するのです。フェイルオーバーがあるからこそ、まだコミットしていないモデルに対してステップを試すことが、賭けではなく生き残れる試みになります。

今週、あなたのセットアップを書いているなら

役割は職務名ではなく、運用テキストとして書く。この点に関するドキュメントの助言は、ほとんどの助言より優れている。Bot には明確な目的、ツールセット、スタイル、承認境界またはスケジュールがあり、専門担当を追加する前に、まず「最小限の有用なロスター」から始めて、1つの Bot がエンドツーエンドの成果を担うべきである。次に、ドキュメントが定める順序でその一連の手順を実行する。1つの実際のタスクを信頼できるものにし、その方法をスキルとして保存し、そうして初めてルーティンを作る。その際、Bot、スケジュール、タイムゾーン、入力元、期待される結果、承認境界、入力元がない場合の動作をすべて書き留める。テストは、あなたが見ている間に行う。最初のスケジュールを設定する前にタイムゾーンを設定する。ルーティンがそれを使うからだ。また、存在する小さな安全網に留意しておく。Grok Bot は、長期間不在だった後にルーティンを実行し続けるかどうかを尋ね、あなたが答えなければそれらを一時停止することがある。

あの投稿の構成はスタジオではないし、その言葉も害をなしているわけではない——実質的な制御手段が説明文、スキルライブラリ、スケジュールだけであるときに、実務家が作るものに付けた名前でしかない。次の製品変更では生き残らない部分は、モデルを自分で選んだことを前提にしているものすべてだ。マスク氏の10月7日の発言は依然として発言にすぎず、ドキュメントには今もピッカーはないと書かれている。仮にピッカーがいつか提供されるとしても、持つ価値のある設定は、最初からその仕事について具体的だったものになるだろう。