3行でいうと

  • 公式の「Use cases」のページは、8つの役割（営業のアウトバウンド、人材探し、広告運用、経費、プロダクトの性能調査、バグの再現、顧客の状態確認、秘書役）を、それぞれ「任せる範囲」「つなぐ道具」「最初に頼む文」「やらせないこと」の形で載せています。どれも、まず読み取りと下書きから始め、送信や変更は承認の後ろに置く形です。
  • 最初の仕事の頼み方は、公式のGet startedに書かれています。強い依頼には、結果、資料、制約、成果物、見直しの時点の5つが入ります。道具につなぐ前に試すなら、文書を添付して5項目の要約を頼む方法が公式の例です。
  • 慣れてからの順番も公式が書いています。まず1回の仕事を安全な範囲で動かし、直し、スキルとして保存し、2つ目の入力で試し、失敗の扱いを決めてから、ルーティン（定期実行）にします。ルーティンのテスト実行は「本物の作業をする」と公式が警告しています。
  • 制限と注意で押さえるのは、1つのBotは画面で一度に1つのコンピュータ操作しかできないこと、全Botが1台のクラウドパソコンとログイン状態を共有すること、背景で始まった承認は約10分で期限切れになること、Auto Reviewはモデルによる点検で万能ではないこと、の4点です。

この記事は、実際に使って確かめた記録ではありません。運営者はGrok Botを入れていますが、使い心地はこの記事には書いていません。この記事は、公式ドキュメントを2026年10月24日に読んでまとめたもので、実際に使って確かめた記録ではありません。運営者はGrok Botを入れていますが、使い心地はこの記事には書いていません。ボタン名、設定名、数字は公式の英語表記を写しただけで、動作確認はしていません。公式の文章は要約の形で取得したため、ほとんどを言い換えていて、引用は数か所の短いものだけです。使う場面は、公式が例として挙げているものを並べただけで、「これで必ずうまくいく」という保証ではありません。

先に結論

前提：用語をそろえる

用語の基本（Bot、共有クラウドパソコン、コネクタ、スキル、ルーティン、Take over、Auto Review）は、前のガイド（01）に書いたとおりです。ここでは、この記事で何度も出てくる言葉だけ、公式の説明に沿って短く補います。

公式が挙げる使い方の場面

公式の資料のなかで「何に使うのか」が書かれているのは、主に次の5か所です。①Overview、②Use cases、③2026年8月11日の発表ブログ、④x.ai/bot、⑤公式ガイド「Grok Bot 101」（2026年9月11日）。このほかにTag @bot on Xのページに、Xから頼む例があります。それぞれ書き方が違うので、順に見ます。

Use casesのページ：8つの役割

Use casesのページ（ページ上の最終更新は2026年8月11日）の冒頭の考え方は、いちばん強い役割は、繰り返せる成果を1つ持つこと、というものです。始め方は、読み取りと準備の仕事から入り、結果を見てから、承認つきの操作や定期実行を足す、と書かれています。8つの役割を、表に整理します。「つなぐ道具」の列は、公式が製品名でなくカテゴリで書いているものを写しました。最初に頼む文は、僕らが読んだのが要約だったので、公式の文そのものではなく、言い換えです。

役割 任せる範囲（公式の書き方） つなぐ道具（公式はカテゴリで書く） 最初に頼む文の要旨 公式が付けている「やらせないこと」や注意
Sales Outbound アカウントの調査、連絡先の優先づけ、レビュー前提の営業文面 CRM、製品への関心の情報源、会社のサイト、メール、職業系SNS（規約が許す範囲） CRMの25社を調べ、理想の顧客像と最近の動きで点数をつけ、1社あたり最大3人を選び、メールと職業系SNSの下書きを添付の例の文体で作り、レビュー用の一覧にする。すでに営業の流れに入っている先は除く 文中に「送らない、登録しない」。慣れたら夜間の調査ルーティンを足してもよいが、レビュー用の一覧で止める
Talent Scout 候補者探し、調査、連絡文の下書き、日程調整の準備 採用管理システム（ATS）、承認された探索の道具、メール、カレンダー 必須条件を満たす20人を探す。すでに採用管理システムにいる人は除き、根拠を示し、本人の文体で下書きを作る 文中に「連絡しない」。外部への連絡の前に承認を置く。候補者のプライバシー、地域の要件、情報源の規約を守る
Paid Media 広告キャンペーンの監視と予算の提案 広告のサービス、分析、予算の表計算、Slack 現在の費用と成果をキャンペーンごとに集め、月の予算と目標の獲得単価と比べ、配分の変更案を数字つきで出し、Slackの連絡の下書きを作る 予算を変えない、送らない。ルーティンにしても、キャンペーンの変更は承認の後ろ
Expense Manager 毎週の経費の突き合わせと、足りない情報の確認 経費システム、メール、共有ドライブ、経理の表計算 経費システムと添付の規程から、その週の経費の要約を作る。経理の受信箱のレシートと突き合わせ、分類の漏れや規程の例外に印をつけ、担当者ごとに確認の下書きを1通ずつ作る 送らない、精算を変えない。例外ごとに規程を示す。合計は元のデータと合うこと
Product Performance 根拠つきの性能調査 観測用の道具、分析、インシデント対応の道具、ソース管理のリンク リリース以降の決済画面の遅延を調べる。ダッシュボード、トレース、フレームグラフを見て、最も確からしい原因を絞り、スクリーンショットとリンクつきの短い報告にする。事実と仮説を分ける アラートや本番の設定を変えない。ルーティンは定期の健康報告だけで、人が見ていない本番の変更には使わない
Bug Reproduction バグ報告から、再現できる一式を作る 課題管理、ステージング環境、ブラウザ、ネットワークの道具 バグ報告を読み、ステージング環境で新しいテスト用アカウントを使って再現する。手順、期待と実際の動き、スクリーンショット、ブラウザとOS、コンソールやネットワークの記録を返す 本番のお客様データを使わない。テスト用の認証情報は、チャットに書かず、安全な引き渡しで渡す
Account Health 顧客全体のリスクと拡大の兆し CRM、製品の利用データ、サポート、請求、カスタマーサクセスのメモ 利用状況、サポートのエスカレーション、更新時期、相手側の動きをまとめ、順位つきの注意リストにする。各社に根拠、重要な理由、次の一手を付ける 顧客に連絡しない、顧客管理システムを編集しない。毎週の結果をそろえるため、リスクの基準をBotの説明に書く
Chief of Staff 前日からの変化と、対応が要ることの、出典つきの要約 Slack、メール、カレンダー、会議メモ、計画の文書 前日以降の、許可したチャンネル、受信箱、予定、会議メモを見る。名前を挙げた計画文書の優先事項に関係するものだけ返す。各項目に出典、重要な理由、次の一手、自分の判断が要るか、を付ける メッセージを送らない、会議を変えない。役に立った項目と雑音を伝えて育てる。見直せる時刻に届くよう予約する

公式は、この表の使い方も書いています。どの役割でも、Botの説明に「仕事、使う情報源、出力の形、いつも守る境界」を書き、現実の仕事を1つ安全な範囲で動かし、結果をレビューできるところまで直し、うまくいった手順をスキルとして保存し、2つ目の入力で試し、再試行と失敗の場合を決めてからルーティンを作り、外に影響する操作は承認の後ろに置く、という7段階です。

Overviewのページ：「最初に渡す仕事」の例

Overview（ページの最終更新は2026年10月22日）の「最初に渡す仕事」の例は、週次のパイプラインレビューの一覧です。CRMから今週のレビュー用の一覧を取り、すでに営業の流れに入っている人を除き、上位5社をウェブとSlackで調べ、連絡先を選び、自分の文体で連絡の下書きを作り、翌朝までに承認用の下書きを残す、という内容です。（進み具合の報告や音声メモの扱いは、Overviewの取得結果からは確認できませんでした。）

発表ブログ、x.ai/bot、Grok Bot 101

「公式が挙げる使い方」を読むときの注意

Use casesのページは、「ここに書いた8つだけができる」とは書いていません。書かれているのは、繰り返せる成果を持つ役割の例です。また、各例は、CRM、広告のサービス、経費システム、観測用の道具、ソース管理の道具などにつなぐ前提で、どの道具が実際に使えるか、日本からのつなぎやすさは、Use casesのページには書かれていません（Connect appsに並ぶ対応アプリの一覧は、僕らは読めていません）。最初の1回は、道具につながなくても試せる、書類の要約から始めるのが現実的です。この「現実的」は僕らの見立てです。

入口ごとの使い方

使う入口は、公式の記載では次のとおりです（入口の一覧と対応OSは、前のガイド（01）も参照してください）。

入口 公式に書かれている使い方 書かれている場所
デスクトップアプリ 入力欄に文字を打つ。音声入力は Start voice input（Cmd/Ctrl+D）。ライブの会話は Start voice chat。入力欄で / を打つとスキル、@ を打つとBot、グループ、ルーティン、アプリを呼べる Get started、FAQ、Skills and routines、Message and collaborate
モバイル（iPhone、Android） 文字、音声入力（Start dictation）、音声チャット、写真とファイルの添付、グループでの@メンション。Botが用意したメールやSlackの下書きを送るか捨てるか選べる。通知の受け取り、承認、画面を見て引き継ぐこともできる Grok Bot for Mobile（2026年10月17日更新）
モバイルでできないこと ルーティンの日程や指示の編集、ルーティンのテストはデスクトップ版が必要。デスクトップの一部の高度な設定や、実演で教える機能も、モバイルにはない Grok Bot for Mobile
グループチャット デスクトップでは New → New chat で2〜6のBotを選ぶ。モバイルでは + → New Group Chat。誰が次の担当かを最初に書く。1人に頼むなら @ でBotを選ぶ Message and collaborate（2026年10月22日更新）
Xで @bot 自分が持つBotがある、GrokアカウントにXをつないだ、Grok Botの権限がある、対応地域のXアカウント、が条件。確認の返信は公開で出る Tag @bot on X（2026年10月7日更新）
Team Bot 所有者が公開した1つのBotを、チームの人が各自の個人会話か、Slackで使う。各人の会話は別で、記憶にはチーム用と個人用がある Team Bots（2026年10月22日更新）

グループチャットについては、公式の注意が具体的です。1段階ごとに担当を1つに決めないと、重複した作業と通知の増加が起きる。@everyone は控えめに。Botに指示を変えてほしいときは、リアクションではなく文章で書く（安全に関わる判断をリアクションだけに載せない）。最初の合図には、やってよいことと、いけないこと（例：「何も公開しない」）を書く。また、承認の依頼、秘密やログインの依頼、メールやSlackの下書きは、グループ内には出てこない、とも書かれています。Bot間の引き渡しのメッセージは今のところ文字だけで、画像を見せたい場合は、そのBotに直接送ります。

最初の10分でやること

ここは、公式のGet started（2026年10月22日更新）の順番を軸に、僕らが時間の目安を付けた手順です。時間の割り振りは僕らの整理で、公式は分数を書いていません。

0〜2分：対象になるかを確かめる（公式の「Requirements」）

2〜4分：インストールとログイン（Get startedの1と2）

4〜6分：Botに「主な仕事」を1つだけ伝える（Get startedの3、Botsのページ）

会社の道具がなくても試せる最初の1回

8つの役割はすべて会社の仕事ですが、最初の1回に会社の道具は要りません。公式のGet startedの最初の試しは、道具につながずに、文書を添付して要約を頼むものです。個人で試すなら、手元の公開資料や自分の書類（機密や他人の個人情報を含まないもの）を使えます。公式のGrok Bot 101には、個人向けの例として、Xでフォローしている人の名簿づくり（公開のプロフィール情報だけを使う）と、フリマのサイトで中古の機器を探す例が出ています。ただし、買い物のサイトにログインしたままだと、人間が買えるものはBotも買えてしまう、と公式は警告しています。個人の最初の1回では、買い物やお金に関わるサイトにはログインしません。これは公式の警告を読んだうえでの、僕らの整理です。

6〜9分：最初の仕事を、強い依頼の形で頼む（Get startedの4）

公式が言う「強い依頼」は、①結果（何が欲しいか）、②情報源（どこを見るか）、③制約（やってはいけないこと、先に聞くこと）、④成果物（どんな形で返すか）、⑤見直しの時点（いつ、誰が確かめるか）の5つです。

公式が挙げる最初の試しは2つです。

  1. 道具につながずに試す。 文書を添付して、5項目で要約してもらいます。公式の例は、日付、決まったこと、未解決の質問を別の欄にし、各項目に元の節を示し、元のファイルは変えない、という条件つきです。
  2. 分析画面で試す。 分析画面を開き、今週の新規ユーザーのアクティベーション（new-user activation）を、その前の4週間と比べ、段階ごとの最大の変化を見つけて、調査の計画の下書きを作る。ダッシュボードは変えない。ログインが要るなら知らせる、という例です。

添付できるファイルの条件は、Files and resultsのページ（2026年10月22日更新）に、1回に6つまで、文書、画像、音声は1つ25MBまで、動画は200MBまで、と書かれています。対応する種類は、画像、音声、動画、PDF、テキスト、Word、Excel、PowerPoint、CSV、JSON、YAML、ソースコード、HTML、メール、Jupyterノートブックです。暗号化された、または壊れたファイルは読めないことがあり、その場合は PDF、CSV、テキスト、画像にして出し直します。ただし、2026年10月14日の変更履歴には「添付は最大250MB、動画は最大1GB、1メッセージに20個まで」と書かれていて、ドキュメントと数字が違います。どちらが今の仕様かは確認できていません（あとの「食い違い」の章を見てください）。

僕らの整理です。 5つの要素を埋める雛形は、たとえば次のようになります。これは公式の文そのものではなく、僕らが上の5要素に当てはめた例です。

[結果] 添付の議事録から、決まったこと、期限、未解決の質問を5項目でまとめてください。
[資料] 添付のPDFだけを見てください。ほかのサイトやアプリは開かないでください。
[制約] 元のファイルは変えない。メールやSlackは送らない。分からない点は推測せず「不明」と書く。
[成果物] 箇条書き5つと、各項目の元のページ番号。
[見直し] まとめを会話に出して止まってください。私が確認してから次の指示をします。

9〜10分：結果を見て、直す（Get startedの6、Files and results）

もしログインを求められたら

アプリがログインを求めると、Botがコンピュータの操作を頼んできます。Take over を選び、パスワード、パスキー、二段階認証、CAPTCHAを自分で入力して、I'm done を選び、続けてよいことをBotに伝えます。Botはパスワードを見ません。ブラウザのログインは共有パソコンに残り、ほかのBotが使うことがあります（Get started）。対応するサービスには、サイドバーの Connect apps → Add でプラグインを足す道もあります。

慣れてからの一歩：スキルとルーティン

最初の仕事がうまくいったら、公式のSkills and routinesのページ（2026年10月22日更新）の順番で進めます。

  1. スキルとして保存する。 公式は、役に立つスキルには、いつ使うか、必要な入力とアクセス、作業の順番、結果の確かめ方、返すもの、承認が要るもの、が入る、と書いています。入力欄で / が出ないときは、Connect apps で接続数の表示を開き、Private skills で、そのBotに対して有効にします。
  2. 画面の操作を見せて教える（Teach a task）。 使える場合、1対1のBotの会話でコンピュータの画面を開き、Teach a task を選び、結果を説明し、手順を1回実演し、録画を止め、できたスキルを確認します。録画は最大10分で、マイクの音声は撮りません。できたスキルは下書きで、判断のルール、失敗時の扱い、承認の境界を足し、安全な例で試してから使う、とされています。この機能は段階的に展開されていて、ない場合は、文章の手順と完了した仕事からスキルを作るよう頼む、と書かれています。認証情報は、画面に出さず、安全な引き渡しで扱います。
  3. ルーティンを作る。 仕事を持たせたいBotに、チャットで頼みます。確認する項目は、担当するBot、日程とタイムゾーン、入力の出どころ、期待する結果、承認の境界、情報源がないときの動き、の6つです。Botは次の実行時刻を表示します。ルーティンは、パソコンを閉じていても動きます。確認する6項目を、最初からチャットに書いておく雛形は、たとえば次のとおりです。公式の文ではなく、僕らが6項目に当てはめた例です。
[担当するBot] 週次アカウント状態レビューのBot
[日程] 毎週月曜の朝8時（日本時間）
[入力の出どころ] 顧客管理システムの今週のリスト、サポートのエスカレーション一覧
[期待する結果] 注意が必要な顧客の順位つきリスト。各社に根拠と次の一手を付ける
[承認の境界] 顧客への連絡と、顧客管理システムの編集はしない。結果は会話に出すだけ
[情報源がないとき] 推測で埋めず、「取得できなかった」と書いて止まる
  1. テストする。 作ったあとと直したあとに Test を使います。公式は、テストがウェブの操作、ファイルの変更、道具の呼び出しを含む本物の作業をする、と書き、安全な入力を使い、書き込みの操作は承認の後ろに置くよう勧めています。
  2. 管理する。 デスクトップでは、Botの名前をクリックして Details のタブを開き、Pause／Resume、Test、Edit、削除ができます。モバイルでは、Botのプロフィールにルーティンと Run history が出ます。

イベントで動かすルーティン（SlackのメッセージやGitHubの通知など）は、Cursorのアカウントの連携で作ります。これらはSlackやGitHubのアプリとは別で、別の接続が要ることがあります。公式は、合致の条件を狭くするよう書いています。広い待ち受けは、雑音と使用量の増加を招き、関係のない入力に反応する危険も増えるからです。

ルーティンの数字は、2つの資料で食い違っています。Skills and routinesのページには、1つのBotは50個まで、各ルーティンは直近20回の実行記録を保持、実行の間隔は5分以上、とあります。いっぽう、2026年10月23日の変更履歴には「ルーティンは合計で1時間に300回まで（1つにつき200回）」という趣旨の記載があり、どう両立するかは読めていません。

公式が書く制限

項目 内容 書かれている場所
同時のコンピュータ操作 1つのBotは、画面で一度に1つの操作。Botごとに画面は別で、複数のBotは並行して動ける Overview、FAQ、Use the computer and apps
承認の期限 自分が見ていないところで始まった作業（ルーティン、トリガー、他のBotからの依頼）の承認は約10分で期限切れ。期限切れのカードは Expired と出て、操作は実行されない Approvals, security, and privacy
添付 デスクトップで1回6つ、文書・画像・音声は25MB、動画は200MB（変更履歴は別の数字） Files and results、Troubleshooting
Teach a task 録画は最大10分。段階的に展開 FAQ、Skills and routines
ルーティン 1つのBotに50個、実行記録は直近20回、間隔は5分以上。削除は即時で、元に戻せない Skills and routines
グループチャット 作るときは2〜6のBot。最大の人数、引き渡しの回数の制限は書かれていない Message and collaborate
Team Bot 説明は140文字まで。秘密は1つのBotに25個まで、1つ8文字以上、4,096バイト以下。アップロードできるファイルは256,000文字まで Team Bots
Xの @bot オーストラリア、英国、EU、アイスランド、リヒテンシュタイン、ノルウェーのXアカウントでは、まだ使えない。判定はXに登録された国 Tag @bot on X
使用量 週ごとの使用枠。リセットの曜日や時刻は書かれておらず、使用量の画面に次のリセット日が出る。使い切ると追加の使用量（前払いの残高から）になる 料金ページ、Usage limits
追加使用の上限 月ごとの追加使用の上限（個人プランと自分で申し込むチームプラン）。上限か残高のどちらかに達すると追加使用は止まる。アラートは通知するだけで止めない。自動チャージは既定でオフ Spending caps and alerts（2026年10月11日更新）
保存期間 Files and resultsのページには書かれていない。バックエンドの保存はCursorの規約に従う Files and results、Bots
計算機の場所 米国で動いている、とSecurityのページにはあるが、データの保管場所を約束する文面ではないと書かれている Security（2026年10月22日更新）

公式が出している注意

共有パソコンと、ログインの共有

全Botが、1台のクラウドパソコンのファイル、ブラウザのセッション、コマンドラインの認証情報を共有します。Botごとに画面はありますが、Botどうしは安全の境界ではありません。Grok Bot 101は、より具体的に、1つのBotでサイトにログインすると他のBotも同じサイトに入れる、ショッピングのアカウントにログインしたままだと、人間が買えるものは何でもBotも買えてしまう、と書いています。使わなくなったら、サイトからサインアウトし、/workspace の機密ファイルを消し、コネクタの許可を元のサービスで取り消します。

承認は「取り消し」ではない

承認の選択肢は Allow once、Always allow、Deny です。承認は提案された操作だけに効き、すでに終わった作業を取り消しません。何をするのか分からない操作は承認せず、Botに説明か下書きを頼みます。公式は、承認の前に、対象、範囲、値を確かめ、対象や効果が分からない操作は承認しないよう書いています。Allow once を基本にする、という推奨は、読んだ範囲では見つかりませんでした。

承認の前に先に聞かせる操作

公式が先に聞かせる対象として挙げるのは、メッセージや招待の送信、公開、購入や送金、データの削除や上書き、権限の変更、本番環境の変更、法的な条件への同意の7つです。FAQは、Botの説明に常時の境界を書き、Auto Reviewの Ask first に、送信、公開、削除、購入、本番の変更を入れるよう勧めています。この5つを、Securityのページの「狭い規則」の形（動作と範囲を具体的に）で書く手がかりにできます。たとえば「送信」なら外部宛のメール、「削除」なら特定のフォルダ、と範囲を付けます。この書き分けは僕らの整理で、公式がこの5つについて規則の文面を載せているかは、読んだ範囲では確認できませんでした。

Auto Reviewは万能ではない

Auto Reviewは Settings → General → Auto-review で設定します。Ask first は必ず止め、Allow automatically は、ほかに止める理由がなければ通し、両方に合えば Ask first が勝ちます。個人の規則は、厳しい方向にしか変えられません。Securityのページには、Auto Reviewはメモリの書き込みや多くの設定変更のような副作用をすべて見るわけではない、と書かれています。また、プロンプトインジェクション（悪意のある内容による誘導）への対策は、危険を減らすが、なくすものではない、とも書かれています。

秘密の扱い

パスワード、パスキー、二段階認証のコード、CAPTCHA、支払いの確認は、普通のチャットに書かず、Take over（コンピュータの中では Take control）で自分が入力します。安全な秘密の入力は、対応する接続だけのもので、汎用のパスワード管理ツールではない、とされています。Bug Reproductionの例のように、テスト用の認証情報も、チャットに貼らず、安全な引き渡しで渡します。

ルーティンのテストと、Botの削除

ルーティンのTestは本物の作業をします。ルーティンの削除は即時で、元に戻せません。Botを削除すると、そのBotが持つルーティンも消えますが、共有パソコンのファイルとログインは残ることがあります。あとで見返す可能性があるなら、削除でなく隠す（hide）ほうを、公式は勧めています。隠してもBotやルーティンは止まりません。長く使わないでいると、ルーティンを続けるかを聞かれ、返事がないと止まる、とも書かれています。

Xの @bot

確認の返信は、Xに公開で出ます。初回は、タグをつけた依頼が自動で作業を始め、Grok Botの使用量に数えられる、という通知が出ます。動画やGIFを含む投稿、@grok を一緒にタグした投稿、審査に通らない投稿などでは、返事がないことがあります。

共有リンクとTeam Bot

Botの共有リンクは設定のコピーを渡し、パソコン、ログイン、会話履歴は渡しません。ただし、APIキー、社内のURL、顧客のデータは入れないよう書かれています。Team Botは、Slackのチャンネルでの会話が、1つの別のコンピュータを共有するため、機密は共有しないよう書かれています。

道具につなぐときの考え方

Securityのページは、Auto Reviewを「明示的な境界と最小権限」の補完として使うよう書いています。いちばん強い境界は依頼の文そのもので、Botに変更してよいことと、止まる場所を書かせる、という考え方です。Botは、持ち主の人より多い権限を持てません。Auto Reviewの規則は、具体的な操作に結びつけて狭く書きます。公式が挙げる例は次のとおりです（動作確認はしていません）。

狭い規則の例（公式の例）
  Ask first:           ask first before sending any external email
  Allow automatically: allow automatically when running `git status` in `/workspace/reports`

避けるよう書かれている広い規則の例
  allow everything in the browser

ローカル（自分のパソコン）での実行は、特別な理由がなければ Never allow にするよう、公式は勧めています。選択肢は Ask every time（既定、コマンドごとに承認）、Always allow、Never allow の3つです。管理者はチーム全体の上限を決められ、メンバー個人の厳しい設定はそのまま効きます。読み取りから始めることは Use cases に、出典のリンクや操作の記録を求めることは Files and results に書かれています。範囲を絞ったサービスアカウントを使うこと、コネクタやルーティンを定期的に見直すことは、Securityのページには、読んだ範囲では見つかりませんでした（書かれているのは、プロジェクトやログインが不要になったときに、関連するルーティンを止めるか消し、接続したアプリを外し、元のサービスで認可を取り消し、/workspace の機密ファイルを消す、という後始末です）。ネットワークは、チームの方針がなければ、すべて許可が既定です。アプリを止めても、そのサービスのウェブサイトは止まりません。

僕らの見立て：最初の1週間の進め方

ここからは、公式の記載を読んだうえでの僕らの見立てです。

日 やること 根拠（公式のどこか）
1日目 文書の要約を1回。次に、役割を1つ決めたBotの説明を書き、読み取りと下書きだけの仕事を1つ頼む Get started、Bots
2〜3日目 結果の直しを重ね、うまくいった手順をスキルにする。別の入力で再テストする Use cases の「7段階」、Skills and routines
4日目 Auto Reviewの Ask first に、送信、公開、削除、購入を入れる Approvals, security, and privacy
5〜7日目 失敗の場合（情報源がない、古い）を決めて、読み取りだけのルーティンを1つ作る。結果は、見られる時刻に届くよう予約する Skills and routines、Use cases（Chief of Staff）

「いつ外部に送らせるか」は、読み取りと下書きの結果を何度か確認して、自分がそのまま送れると感じてからで十分だと僕らは考えます。これは公式の推奨ではなく、僕らの見立てです。公式が書いているのは、承認の後ろに置くこと、レビューできる形に直すことまでです。

食い違い、読めていないこと

気をつけること

出典