Grok Botの使い方は、一つの仕事に一つずつ割り当てるのが基本

出典: How to Build & Sell Grok Bots (Full Course for Grok 4.7)

AIの窓が大きくなった、と聞くと、全部読ませれば片づく気がしますよね。資料も過去のやり取りも、まとめて渡せば済みそう。本当にそうでしょうか？ 動画は、ここから話を始めます！

動画は、この一本で Grok と Grok Bot が分かる、と宣言して始まります。シリーズの一本で、司会は Ansh Mehraさん。

実演で作るのは、食品のD2Cブランドの繁忙期向けの提案づくり。リサーチ、画像と広告、ウェブサイト、問い合わせ対応、法人客探しの5つを、AIのチームで作る、と紹介します。

最初の土台は、文脈窓の話。Grok 4.7 は約50万トークン、他社の最新モデルはその倍ほどの窓がある、と司会は話します。ただ、窓が大きくても良い結果は約束されない、とすぐに続けます。

Ansh Mehra（動画 6:17〜）

Big context windows do not guarantee better results.

説明では、入力に入るのは質問だけではないんですよね。システムの指示、メモリ、アップロードした文書、過去のチャットも、全部が窓に積み重なります。出力の上限は別枠。

窓が満杯になると、古い所を切り捨てる、要約する、必要な所だけ検索する、新しい文脈で始める、のどれかになります。要約の結果は盲信しない、と念を押します。

AIの出力は、仕上がりではなく出発点。つまり初稿として扱う、と司会は説明します。AIの優劣は、文脈の容量、検索の正確さ、推論の質で測る、とも話します。

チャットと Bot の違いは、動画では電話にたとえられるんですよね。チャットは、毎回電話で頼む形。Bot は、目標と道具と権限を渡すと自分で動く、24時間のアシスタントです。

Parth（動画 15:54〜）

So while the chatbots work on a do-it-yourself model, these always-on AI agents or persistent AI agents work on a done-for-you model.

ここで Parthさんに交代して、実演に入ります。動画の終わりには、ブランドの代わりに働く Bot のチームができていて、外に出る物は全部、人が承認してから出る、と約束します。

正直、この章の芯はここなんですよね。窓の大きさより先に決めるのは、何を渡して、どこまで任せるか。その順番の話。

実は私、指示の書き方ひとつで、AIが読むかどうかが変わった場面があります。2026年9月25日の計測です。書く前に手順書を読む、とやわらかく書いた1行は、4回の試しでどれも読まれませんでした。

書き始める前に必ず読む、読まずに書かない、と強めたら、新しく始めたAI2本とも読みました！ といっても、4回と2回の小さな試し。一般化はしていません。

引用元（AIに覚えさせる手順を増やしすぎると、動きが重くなる理由を整理し、指示書の1行が読まれるかを測った記事・AIに使い捨てで作らせて棚から参照させる、第3の道の節）

2026年9月25日の計測です。指示書に、書く前に SKILL.md を読む、とやわらかく書いた1行は、4回の試しではどれも読まれませんでした。書き始める前に必ず読み、読まずに書かないと強めたあと、新しく始めたAI2本とも読みました。必ず読む、まで強く書かないと読まれませんでした。4回と2回の小さな試しで、一般化はしていません。

引用のとおり、やわらかい1行は、窓の中にあっても読まれていなかったんですよね。入れたことと、読まれたことは別！ 大きな窓は良い結果を保証しない、という動画の話と、同じ向きを見ていると私は判断しています。

で、私の見方はこうです。窓の大きさは、賢さの数字ではなく、置ける量の数字。渡す量を増やすより、読ませたい1行を強く書く方が先かな。

広げるのはAIの得意な所で、縦に掘るのは人。どこを深く掘るかまで、AIに決めてもらう気はありません。

広げる所はAIに任せて、深く掘る一点だけは、人の手に。

Bot を作ると、あれもこれも頼みたくなりますよね。調べ物も、画像も、文面も、一体に任せたら早そう。でも、一体に詰め込むと、何が起きるんでしょう？

実演で最初に作るのは、リサーチ役の Bot です。画面の＋から新しい Bot を作り、職務を声で話して伝えます。文章で長く書くより早い、という見せ方。

チャットとの違いは、Bot が自分のクラウドPCと、つないだ道具と、ファイルで働くこと。Parthさんは、チャットは自分の手で進める形、Bot は代わりに進める形、と整理します。

つなぐ道具は、必要な物だけ。メールやカレンダー、ノートなどを選びます。決まった時刻や出来事で動く自動化は、ルーティンと呼ばれるんですよね。

ここで、動画の約束事が出ます。一つの仕事に一つの Bot。一体に何でも詰め込むと、文脈が膨らむから、という理由です。スライドには、One task、One bot の文字が並びます。

Parth（動画 17:58〜）

So, our rule is simple, one bot, one job.

仕事の分け方の目安も、画面で示されます。職務の文に、と、が入っていたら、その後ろは次の Bot の職務。画像を作ると調べる、を一体に頼まない、という例です。

Parth（動画 43:46〜）

in that sentence, if there is an and, for example, create images and research. So, anything after that and becomes a job description for the next agent.

この目安は、動画の後半でも出てきます。段取り役の Bot にスキルを作らせる場面で、くり返されるんです。

いやー、ここは線がはっきりしていますよね！ 役割を分けるのは、頭の良さの話ではなく、散らからないための設計。動画の見方は、そこにあります。

でね、私のアカウントの2体のBotにも、操作を頼んだことがあるんです。2026年10月22日のこと。

2体目には新しく作らせず、そのファイルがあるかだけを確認させています。結果は、2体目からも同じcookieと、同じファイルの中身が見える状態！ 私が確かめたのはここまでで、実際のサイトのログインまで共有されるかは、確かめていません。

引用元（Grok Botのクラウドや共有の仕組みを、公式の説明と2体のBotでの確認から整理した記事・複数のBotを作るとログインやファイルはどこまで共有されるのかの節）

同時に、/workspace に share-check-A.txt を作らせました。中身は A1022です。次に2体目には、新しく作らず、そのファイルがあるかを確認させました。2体目からも見えた。同じテスト用cookieと、同じファイルの中身です。

引用の場面は、役割で分けたつもりでも、作業場所とファイルが同じなら、境目は思ったより薄いということなんですよね。動画の、一つの仕事に一つの Bot、という話に、私はさらに一つ問いを足したくなります。仕事を分けたBotは、置き場まで分かれているのか？

役割は、名前で分けるだけでは足りません。作業場所と、見えるファイルまで含めて、分けたつもりを確かめてから任せる、という順番です。そこまでが、設計の範囲。

実際のサイトのログインが共有されるかは、私が確かめた範囲の外。ここは、言い切れる所だけを言い切っておきますね。

約束と期限を覚えて運ぶ仕事は仕組みに預けて、手元に戻すのは判断だけ。

Bot に任せたいのは、手を動かす作業ですよね。でも、メッセージや提案が外に出る瞬間は、誰が見るんでしょう？ 動画は、ここに一本の線を引きます。

動画が挙げる Bot の習慣は、3点です。職務記述をはっきり書くこと、必要なアプリだけをつなぐこと、そして外に出る物は人が承認すること。下書きは Bot、送信を押すのは人、と短く言い切ります。

Parth（動画 19:28〜）

The bot drafts, you press send.

人の持ち分も、はっきり言葉にします。日常の作業は Bot に任せて、判断と例外は人が持つ、という分け方。

Parth（動画 19:33〜）

My bots will do the routine work. I will handle the judgement as well as the exceptions.

続いて、段取り役の Bot も作ります。役どころは、プロジェクトマネージャー。グループチャットを作らせて、ほかの Bot を呼びながら進めます。

画面では、Bot が仮想のコンピュータを持っています。画面にはブラウザとターミナルがあり、ファイルも見えます。ライブの音声通話で指示を出す場面まであります！

途中で、前の作業の古い Bot が混ざっていた、と指摘が入る場面も。作り直しではなく、その場で直して進める運びです。

つなぐ道具の入り口は、プラグインという呼び名。X は組み込み済み、と話します。Bot のテンプレートが並ぶ市場も、画面で見せてくれるんですよね。

任せるのは作業。外に出る一歩だけは人が持つ、という一本の線。

動画が言っているのは、ここなんですよね。承認を増やす話ではありません。

実は、2026年10月5日から6日に、窓口役のAIに仕事を頼む試運転をしたんです。メール、カレンダー、ドライブを読むだけの棚卸しは、確認なしで進みました。

Mac でコマンドを動かす依頼と、週次の登録では、AIが止まって私の返事を求めました。そこで私が、いいよ、実行して、登録して、と送ったんです。

送信、返信、削除、予定変更、下書き作成は、指示文で禁止していました。AIの報告でも、どれも0件！

引用元（AIを置く場所と渡す権限を先に決める話を整理し、外に出る操作を指示文で閉じた試運転を書いた記事・仮想PCに渡す権限を、箱の中に絞る話と、Reiさんの勧め方の節）

私がBotに仕事を頼むときは、下書きと公開のあいだに、人が座る線を引きます。パスワード、確認コード、APIキーは会話に貼らせません。

下書きと公開のあいだに、人が座る線。動画の、Bot が下書きして人が送信を押す、という線と同じ場所を指しています。

パスワードや確認コードを会話に貼らせない、という後半も、外に出る手前の話。向きはそろっています。

正直、読むだけの仕事まで止める形にはしたくありません。止めるのは、外に出る一歩の前だけ。

成果物のたびに承認を挟むと、判断のボールが毎回私に戻ってきます。それだと、任せた意味が薄れますよね？

でね、承認の数を増やす話ではない、と私は言い切ります。

外に出る操作の直前の一か所だけを人が押す線にして、読むだけの仕事は止めません！

Bot が増えるほど、気になることがあります。全員が、同じ前提で動けているのか？ 1体ずつは賢くても、持っている情報がばらばらなら、出てくる物もばらばら。

動画は、仕事を始める前に、使う道具を先に決めます。画像と動画、サイト、サポート、法人客のリストの道具。

次は、ブランドの資料づくり。25ページ以内という指定で、出来上がりは14ページだった、と紹介します。データを預かる側の責任の話も、ここで出ます。

資料の最後には、検証済み、未検証、矛盾、の表。検証済みは公式サイトから取った情報で、全ての Bot がそのまま使える、と説明します。

Parth（動画 42:20〜）

The verified tags are the pieces of information that every bot can use as it is because these have been pulled from the official website.

Bot が作ったサイトも見せます。先頭の画面と、法人向けの贈答の案内。そして問い合わせフォームです。右下には、ElevenLabs の会話エージェントが付いていました！

頼んでいないのに、なぜ付いたのか？ 理由はメモリで、Bot が前に学んだ好みを覚えていたから、と説明します。

そこで、新しいサイトには ElevenLabs のエージェントを最初から入れる、というスキルを、段取り役の Bot に作らせます。スキルを公開するにはチームの要件が要る、という画面も。

良いスキルが答える六つの問いも、紹介します。いつ使うか、何が要るか、手順、見せる前の確かめ方、何を返すか、何に承認が要るか。

Parth（動画 44:54〜）

you need to keep in mind that a good skill answers six main things. When to use it, what it needs, like what are the inputs, the steps, how to check the work before showing me, and what to hand back, as well as what needs my approval.

確かな物と、まだ確かめていない物。動画は、資料の上でこの2つを最初に分けているんですよね。

Bot が何体いても、この線引きが資料に載っていれば、同じ前提から動き出せます。

2026年9月29日の話です。AIが要約だけを見て、私の原液はこの分野に無い、と報告してきたんです。

私は聞き返して、LIVEの発言の記録から、95の分野ごとに数え直させました。私の発言55,297件、381回ぶんの記録です。

結果は、10回以上出る分野が55、3〜9回が12、1〜2回が11、0回が17。正確な言い回しで探すと0件でも、広い言葉で探すと137件出た分野までありました！

確かめた範囲を分けて言えば、次の直しが速くなります。要約だけで無いと言い切ると、あとで誤りが見つかりにくくなるんですよね。

だから、どこまで確かめたかを先に書く。人は、五感で感じた現場からしか縦に掘れません。要約の上だけで、無いと決めないこと。

確かめた範囲と、まだ確かめていない範囲。最初に分けて書くのが、共通の資料の土台です。

お客さんの問い合わせは、夜中にも、休みの日にも届きます。その窓口を Bot に任せる時、何を渡して、何を人の手に残すのか。第5章は、この分け方を見ていきます。任せたい気持ちと、任せきるのが心配な気持ち、両方ありますよね？

動画は、WhatsApp のサポートエージェントを作ります。ElevenLabs のエージェントに、役割、口調、人に引き継ぐ条件、価格表、知識の資料を入れます。

WhatsApp の番号との紐付けだけは、手作業。Bot が代わりにやらない所です。

実演では、実機のスマホで、挨拶の一言を送ります。返信は、すぐ。大口の注文はメールでの相談に回し、持病に関わる質問には、医師に確認するよう促します。

画面には、ガードレールの設定も映ります。話題から外れない、押し切られない、内容の制限、独自の制限、の四つの欄。

説明では、Bot 自身のメールアドレスは取得が一度きりで、変更も削除もできない、と話します。

次は、営業の調べ物。競合のニュースレターの購読と、X投稿の調査をリサーチ役に任せ、作業の一覧表を共有の置き場に置かせます。

仕上げは、問い合わせの自動化。フォームから入るとルーティンが動き、個別化した案内状と請求書を、メールの下書きにして返します。

Parth（動画 61:33〜）

the beauty of GrokBot by design is that it is not able to copy your webhook URL or the key and paste it like it would for other tasks it has been given to.

ここが、Parthさんの強調する所。webhook のURLとキーを、Bot は自分でコピーして貼れない作りだと話します。貼るのは人で、サイト側の作業です。責任の所在を、人の手に残す設計。

リサーチ役が作った提案資料が、貧弱だった場面も。実演では、資料作りは別の役の Bot の仕事、と差し戻します。このフィードバックは、メモリに残るそうです。

できたメールの下書きは、35通と紹介します。18社の分は、メールアドレスが分からないので作らなかった、という説明。

Parth（動画 65:15〜）

So, it does not assume them, which is a good thing.

窓口の返事は Bot、鍵を渡す一歩と、分からない所を埋めない線は人。この章で動画が見せた分け方は、ここだと私は見ています。

正直、作った下書きの数より、作らなかった分のほうに、この章の線引きがはっきり表れているんですよね。分からない相手に、それらしい宛先をこしらえないこと。ここが、窓口を任せる時の土台だと思います。

でね、窓口には二つの宛先があると、私は分けて考えています。お客さんが話しかける窓口と、自分が話しかける窓口。同じ窓口という言葉でも、決めることが違うんです！

お客さん向けで大事なのは、返事の速さと、人に引き継ぐ線です。Bot が決めきれない話を、どこで人へ回すか。その線を先に引いておくこと。

自分が話しかける窓口は、逆に数を絞りたいんです。窓口が増えるほど、どこに何を頼んだかを思い出す手間が、私の側に戻ってきますから。

お客さんを待たせる窓口と、判断を抱えて待つ自分。どちらも、できれば避けたいですよね？

鍵を貼る一歩を人が持つのは、手間を残したいからではありません。責任をどこに置くか、という話です！誰がURLとキーを貼ったかが分かっていれば、何かあった時にも辿れます。

私の役目は、場を作り、耕し、繋ぐこと。その場の鍵は、場を作った側の手に残しておきたいと考えています。

窓口は任せても、鍵を渡す一歩と、分からない所を埋めない線は手元に。

作り方が分かったとして、それをどう仕事にするのか。最後の章は、売り方の話と、その先で学びをどう更新し続けるか、という話です。作れることと、届けられることは、同じでしょうか？

動画が示す売り方は、二つ。成果物と判断を売るか、Bot を設定して、型ごと渡すかです。

渡す時は、Bot の複製、create a copy で公開用のテンプレートを作り、共有リンクにします。受け取る側は、そこから自分の Bot を立ち上げる流れ。

画面では、画像と提案資料を作る役の Bot が、法人向けと発信者向けの二種類の資料を作ります。続いて、次の10社をリストにする場面まで。

Parthさんは、これは人の置き換えではなく、力の倍増だと話します。メールの下書きにリンクが入っていた所も直させ、その直しもメモリに登録。

Parth（動画 74:14〜）

Don’t email anyone. Don’t outreach to anyone right now.

Bot は新しく入った社員のようなもの、という例えも、説明に出てきます。手元に置き、仕事を見せ、教え、コツを伝える相手。

宿題は、資料を使って、好きなブランドを一つ選ぶこと。誰にもメールを送らず、Bot の出力を自分で検証します。

最後は、Ansh Mehraさんのまとめ。今日学んだことは2〜3か月で価値が下がる、と話します。更新を続ける学び方が要る、という締めくくりです。

Ansh Mehra（動画 75:52〜）

everything that you learn today is going to lose value in the next 2 to 3 months.

Bot を何体作れるかより、何を判断して、どんな型で渡すか。売る物は Bot の数ではなく、判断と型。動画が最後に見せたのは、この見方だと私は思っています。

版のことは、私の手元の記録にもあります。2026年10月11日に、手元の Grok Bot の版を確かめると、0.66.0でした。8月に検証した時は、0.24.0。

10月14日の公式の更新、v0.71.2では、プラグインから Bot が使える Skill が、24個から200個になっています！だから、動画と同じ操作ができるかは、自分の版で確かめてから使うことにしています。

8月に確かめた結果は、あくまで8月の版の話。今の仕様としては持ち出さないようにしています。

学びの賞味期限が短いのは、動画の締めくくりも、私の手元の記録も同じ向きです！大事なのは、古い答えを消すことより、重ね方。

当時はこう見えた、なぜ見え方が変わった、今はこう見える、という並べ方。この順で版として重ねておけば、古い結果をうっかり今の答えとして使わずに済みます。

版が上がるたびに、前の結果に日付の札を付けておくこと。それだけで、学び直す所が見えやすくなるんですよね。

動画の手順を読んだ日と、自分が手を動かす日。その間に、版は変わっていませんか？

私なら、動画の手順は手元の版で確かめてから使い、確かめた日付をメモに残します。

文脈窓の大きさは、賢さの保証ではないこと。一つの仕事に一つの Bot、外に出す一歩は人、分けた共通の資料、窓口は Bot で鍵は人、そして売る・渡す・学び直す。動画は、この順で話を運びます。

で、私が持ち帰ったのは、外に出る一歩の手前にだけ人の線を引くこと。役割を分けても、作業場所とファイルまで確かめること。確かめた範囲と、まだ確かめていない範囲を、最初に分けておくことです！

私の手元の記録にも、指示書の1行が読まれるかを測ったこと、2体の Bot から同じファイルが見えたこと、窓口役のAIが、Macでコマンドを動かす前に私の返事を求めて止まったことが残っています。どれも、動画の話と同じ向きに読めます。

自分の Bot が外に出す一歩の手前に、人の線は引けていますか？