Grok Botの始め方：インストールから最初の成果物の確認まで
Grok Botの資格確認、導入、ログイン、Bot作成から最初のファイル検収まで。公式資料を基に、承認・保存先・定期実行の違いと課題テンプレートを説明。
Ofox 
2026年10月9日に確認した公式資料に基づく手順です。掲載する課題は独自のテンプレートであり、当サイトが製品上で成功させた実行記録ではありません。画面名はクライアントの版によって異なる場合があります。
Grok Botは、利用するアカウントの資格を確認し、対応するデスクトップ版をインストールしてログインし、担当業務を定義したBotを作るところから始めます。最初は開いて内容を確認できるファイルを成果物とする小さな仕事を任せ、それからアプリ接続や定期実行を増やします。これならアカウントの問題と課題の問題を分けて調べられます。
Grok Botは持続的に働くエージェント製品で、GrokモデルAPIの別名ではありません。公式資料は、クラウドコンピューターでファイルやアプリを扱い、一回の会話を超えて仕事を続ける仕組みを説明しています。同一アカウントの複数Botはコンピューターを共有し、会話の文脈は別々です。名前を増やすことは役割の追加であり、ファイルのセキュリティ境界を新設することではありません。公式概要。
最初に、何を納品してほしいか決める
最初の仕事は、助手の説明を信じなくても正否を判断できる大きさにします。「マーケティングを全部担当して」には調査、非公開情報、執筆、予約、外部公開が混ざります。「承認済みインタビューから社内要約と投稿案を三つ作って」なら、入力と終点が明確です。
共有してよい入力ファイルを用意し、成果物のチェック項目を作ります。インタビューに段落・行番号があれば、根拠を指し示せます。無関係な個人情報は除きます。適切な資料がなければ合成インタビューと明記した材料を使えますが、架空の顧客発言を実際の推薦文として公開してはいけません。
返答だけでよいのか、ファイルも必要なのかを指定します。コンテンツならファイル名と内容、調査なら許可する出典と引用項目、表なら列名と欠損値の扱いまで決めます。これにより、編集できる資料が欲しかったのに説明文だけ届く、という食い違いを減らせます。
1. 既存アカウントの利用資格を確認する
公式プランページには、対象の有料Cursor契約と、対象となるGrokまたはX契約を関連付ける経路が記載されています。法人やEnterpriseには別の条件があります。二つ目の契約が必要だと思い込まず、まず既存の利用資格を確認します。プランと請求。
契約を関連付ける場合、確定する前に両側のアカウントを確認してください。文書では関連付けは恒久的で、自由に解除・移動できないと説明されています。対象契約を複数持っても利用枠が自動で加算されるわけではありません。誤った関連付けは、一時的なログイン失敗とは異なります。
組織ではユーザー席（シート）の条件と管理者ポリシーも確認します。個人の資格から組織アカウントの権限を推測しないでください。使うアカウント、プラン、クライアント版、日時を非公開で記録すると、後の使用量調査に役立ちます。請求情報を公開スクリーンショットへ入れる必要はありません。
入門資料には、必要なクラウド保存とlegacy Privacy Modeの互換性に関する注意もあります。これはアカウント方針の判断です。初期画面を進めるために組織の設定を黙って弱めず、承認済み環境と合わなければ管理責任者と解決します。公式入門。
2. 対応するクライアントを入れ、ログインする
公式入門ページのダウンロード先を使い、OSとCPUアーキテクチャを合わせます。資料にはmacOSのIntelとApple Silicon、Windowsの選択肢、Linuxのdeb・rpm・AppImageが挙げられています。「Mac」「Linux」とだけ書かれていることでは適合を判断できません。
macOSではダウンロードしたパッケージを開き、アプリをApplicationsへドラッグします。Windowsでは対応インストーラーを実行し、Linuxではディストリビューションに合うパッケージを使います。起動後、初期画面の Sign in を選び、ブラウザーで確認を終えてからデスクトップアプリへ戻ります。これは公式資料の経路であり、表示名が変わっていれば導入した版の表示を確認してください。
SSOを使う組織では正しい認証経路を使い、何度も別の個人アカウントを作らないようにします。戻ったら、表示されるアカウントが資格を確認したものか照合します。違うアカウントや資格不足なら、課題を始める前にそこを直します。再インストールは不足する利用権を追加せず、二重契約も誤った関連付けを修復しません。トラブルシューティング。
版の記録も重要です。10月2日にMarketplaceはConnect Appsへ改名され、10月7日には旧式の/メニューが廃止されました。古い説明どおりのメニューが出ないだけで、インストール失敗とは判断できません。変更履歴。
3. 担当範囲を明示してBotを作る
公式の初期画面では Meet a future teammate から Create your own を選びます。新版で配置が変わった場合は対応するBot作成入口を探し、旧ラベルがないことを直ちにエラーとしないでください。
名前は担当が分かるものにします。「Bot 1」より「インタビュー編集担当」のほうが明確ですが、名前だけでは指示になりません。担当内容、優先する資料、保存先、判断を求める場面を短く定義します。
編集担当なら、承認済み素材から内部草稿を作り、引用では原文の表現を保ち、不明な事実を挙げる役割にできます。公開日や価格を勝手に決めたり、無断公開したりする役割にはしません。添付文書を読むだけの課題に、メール全体への接続は不要です。初回から権限を広げるほど失敗の切り分けが難しくなります。
共有環境にも注意します。他のBotが同じファイル、ブラウザーのログイン、認証情報を使う場合があります。課題ごとのフォルダーと分かりやすい名前は整理には有効ですが、強制的なBot別隔離と説明してはいけません。コンピューターとアプリ。
4. 最初の課題を一式で渡す
資料には入力、音声入力、音声対話が説明されています。方法が違っても、目的、資料範囲、制約、成果物、確認点は必要です。利用開始。
次は独自の課題テンプレートで、実行済み会話ではありません。角括弧の入力名を実際に渡す資料に置き換えます。
[approved-interview.txt]だけを使用してください。
新しいinterview-draftsフォルダーに社内用コンテンツ一式を作成してください。
納品物：
1. summary.md：提供済み機能、将来計画、未決定事項を別の節にする。
2. posts.md：異なる読者の疑問に答える草稿を三つ作り、出典を示す。
3. actions.json：各項目にaction、owner、deadline、source_linesを含める。
原文で担当者や期限が確定しない場合はnullを使う。
料金、日付、引用、性能結果、登録リンクを創作しない。
原文を保持し、公開、メール送信、他者への草稿送信はしない。
入力を読めなければ不足する資料を具体的に報告して停止する。
ファイル、保存先、確認が必要な事実一覧を返す。指示は正しさを保証するものではなく、検収可能にするものです。見出し三つだけでファイルがなければ未達です。正しいJSONでも期限が架空なら不合格です。助手の自己報告ではなく、出力を原文と照合します。
公開調査が必要なら資料範囲を明示的に変更し、URL、分かる場合の公開日、取得日、根拠となる主張を要求します。古い記事を今日取得したことと新発表を区別してください。インタビューだけを使う指示のまま、外部資料の利用可否を推測させないようにします。
5. 必要になった認証と承認を処理する
ログイン、承認、情報不足で待機することがあります。何を待っているか読んでください。待機表示だけでコンピューター停止や利用枠切れとは判断できません。
Webサイトへのログインは、製品の操作引き継ぎ機能を使い、自分で行います。パスワード、ワンタイムコード、セッション情報を普通の会話へ貼り付けないでください。コネクターはアカウントとスコープを別に確認します。ブラウザーのログインとコネクターの認証は異なります。アプリへのアクセス。
承認時は操作、宛先、範囲を読みます。内部草稿の仕事で突然公開を求められたら、待機を消すために承認するのではなく指示を修正します。製品の承認規則に加えて組織の制限も適用され得ます。承認とプライバシー。
必要な引き継ぎが終わったら既存課題を再開し、止まっていた操作を確認します。仕事全体を新規で始め直すと、元の問題を残したままファイルや外部操作が重複する場合があります。
6. 会話ではなくファイルを検収する
各成果物を開き、存在、内容、編集・ダウンロード可否を確認します。引用、欠損項目、計画を提供済みとした誤りを確認し、修正前の出力を保存します。
文書では /workspace が永続保存先です。テンポラリ領域、手動インストールしたパッケージ、未保存状態に同じ保証はありません。後日戻る仕事では、入力と成果がどこに保存されたか確認します。会話にファイル名が出たことは、永続ファイルの存在証明ではありません。保存先の説明。
この例の合格条件は、三つのファイルが読める、入力が維持される、事実に根拠がある、外部公開されていないことです。行番号不足や架空の日付など具体的な修正を残すほうが、「理解した」という印象より役立ちます。
別のBotを追加したら、承認済みファイルと引き継ぎ規則を渡します。共有ファイルは継続性を支えますが、最初のBotの会話を知っているとは限りません。
7. 一度完成してから再利用と予約へ進む
有効だった資料確認、ファイル命名、検収方法を再利用可能な手順にします。Grokではskillが方法を保存し、routineが時刻や対応イベントによる起動を扱います。方法を保存しても自動で予定が作られるわけではありません。Skillsとroutines。
定期インタビュー処理なら新入力の判定と、新しい素材がない場合の挙動を決めます。フォルダーが変わらないのに同じ内容を繰り返し公開・改稿させないためです。一度だけ安全な実行を予約し、タイムゾーン、有効状態、実際の記録と成果を確認します。
手動テストは現在の指示を確かめます。実際の定時実行が、トリガーの確認になります。会話で登録を約束しただけで自動化が稼働中と報告しないでください。
最初の仕事が終わらない場合
| 状態 | 最初に区別すること | 次の対応 |
|---|---|---|
| ログイン後にアクセス不可 | アカウント違いか資格不足か | 購入前にアカウントとプランを確認 |
| 初期設定が止まったように見える | 進行中か明確なエラーか | 現在の状態と公式手順に従う |
| 出力せず待機 | 承認、ログイン、入力不足、作業中 | 必要な対応を確認する |
| 完了とあるがファイルがない | 説明文か保存済み成果か | 正確なパスを求めて開く |
| 後でファイルが見つからない | 永続保存か一時状態か | 保存先と検収済み成果を確認 |
| routineはあるが成果がない | 登録か実行か | 有効状態、時刻、実行記録を見る |
破壊的なResetを万能の初手にしないでください。公式資料は再試行、アプリ再起動、利用可能なRecover、コンピューター更新、Resetを分けています。Resetでは最後のスナップショット以降の変更を失う可能性があります。重要な成果を守り、該当する警告を確認します。問題解決。
サポートには版、OS、エラー原文、日時とタイムゾーン、利用可能なタスク識別子、試した操作を伝えます。秘密情報と無関係な非公開資料は除きます。「使えない」だけより調査しやすい報告になります。
関連するGrok Botガイド
よくある質問
- Grok APIを使えればGrok Botも使えますか？
- そのようには推定できません。モデルAPIとエージェント製品のアクセス経路は別なので、製品の資格を確認してください。
- 最初から複数のBotを作るべきですか？
- まず一つの課題を検収します。責任が実際に分かれる段階で役割を追加し、コンピューター共有と会話分離の両方を考慮します。
- skillを保存すると定期実行されますか？
- いいえ。再利用手順とroutineは別の要素です。登録と実際の実行も別に検証してください。
- 実測済みの導入手順ですか？
- 公式資料と独自課題に基づくガイドです。当サイトのアカウントでインストール、ログイン、例題が成功したとは主張していません。
