Grok Botの使い方｜Iron Giantさんの10ステップを、人が握る線の順に読み直す

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Iron Giantさんが2026年10月11日にXの記事で公開した、Grok Botで暮らしを自動運転にする10ステップのガイドを読んで、解説します。

Grok Botは、名前を付けたBotがクラウドPC（ネット上にある作業用のパソコン）と、つないだアプリ、保存した手順を使って、いくつもの段階がある仕事を進めるものです。私は8月にGrok Botを検証し、9月にはクラウドPCに入れたアプリのログインで止まりました。これまで自分の記事に書いてきた線と、Iron Giantさんの10ステップを並べると、どこから真似するかが見えてきます。

読み方の筋はこうです。10ステップは、AIに任せる範囲を広げる手順ではなく、人が握る線を一つずつ置く手順として読めます。朝のブリーフの終わり方、役割の混ぜてはいけない線、ログインの手渡し、承認の線、週次レビューの順に並べていきます。

Iron Giantさん（@irongiantXBT）のXの記事「GROK BOT AGENTS」のステップ01

the first chat defines the finish line. the brief needs AGENDA, SOURCES, and OPEN QUESTIONS. include all three.

Iron Giantさんは、最初のチャットで終わりの形を決める、と書いています。ブリーフには、AGENDA、SOURCES、OPEN QUESTIONSの全部を入れます。

最初の仕事に翌朝のブリーフを選ぶ理由は、元の資料と見比べて確かめられる大きさだからです。Daily Chiefという名前のBotを1体作り、実際の仕事を一つ頼むところから始めます。

ブリーフとは、翌朝に見る要点を一枚にまとめたものです。AGENDAは、予定と約束と準備。SOURCESは、カレンダーやメッセージ、メモへのリンク。

OPEN QUESTIONSは、足りない資料、食い違う内容、まだ答えのない問いです。

Iron Giantさんは、OPEN QUESTIONSの行に目を向けさせます。ほとんどのブリーフが見落とすのは、まだ分かっていないこと、足りないこと、食い違っていることだからです。ここが大事です。

原文のプロンプトには、元の資料が使えない時の指示もあります。欠けた所を名指しして、使える部分は仕上げる。返信は送らず、予定も変えず、ブリーフはその場に置いて見直しを待つ。

読み切れる短さに収めることも求めています。

AI氣道『Grok Botの新機能をまさおさんが解説。Proactiveで声をかけられても、返信は私が見てから出す』より

「先に声をかけてもらえるのは、助かります！ただ、分からない所を埋めて進められるより、空欄のまま待ってもらうほうが、私は安心です。」

空欄のまま待ってもらうほうが安心だという話を、私は『Grok Botの新機能をまさおさんが解説。Proactiveで声をかけられても、返信は私が見てから出す』で書いています。

Iron Giantさんは、大きな仕事に進む前に、この一枚を確かめるよう書いています。大事な内容を元の資料までたどれるか。空欄は見えているか。実際の出力を一つ直して、その直しを次に決める役割に使います。

空欄を名指しする指示は、地味です。でも私は、ここが一番大事だと読みました。抜けた所が最初から見えていれば、埋める作業に入れるからです。原文は、出力を信じて渡すのではなく、確かめてから渡す流れで書かれています。

Iron Giantさん（@irongiantXBT）のXの記事「GROK BOT AGENTS」のステップ02

write its charter like a first-day brief. the role contract in the illustration has four fields: ROLE, INPUTS, OUTPUT, and WHEN TO ASK.

Botの役割は、入社初日の説明のように書く、と原文は言います。役割契約には、ROLE、INPUTS、OUTPUT、WHEN TO ASKの四つの欄があります。

ROLEは何を持つか、INPUTSはどこで働くか、OUTPUTは何を返すか、WHEN TO ASKはどの判断が本人に戻ってくるか。この四つで、任せる範囲が決まります。

名前は、持つ責任に合わせて付けます。原文の例は、Daily Chief、Inbox Lead、Research Scout、Life Adminです。

同じ会話に戻り続けると、直しが前の仕事の上に積み上がる、とIron Giantさんは書いています。

Iron Giantさんは、最後の欄を具体的に書くよう勧めています。添付が足りないなら、ブリーフの中で名指しする。仕事全体が変わるほど大事な事実が欠けているなら、作業を続ける前に質問する。

下書きは作れても、送るのは承認を待つ。

AI氣道『Grok Botの使い方。1体に全部任せず、役割ごとにBotを分ける』より

「役割を決めるとき、私は「やること」と同じ重さで「混ぜてはいけない線」を書いています。」

やることと同じ重さで、混ぜてはいけない線を書く話を、私は『Grok Botの使い方。1体に全部任せず、役割ごとにBotを分ける』で書いています。

原文のプロンプト例では、WHEN TO ASKに、送る前、買う前、公開する前、消す前、約束を変える前は聞く、と入っています。やろうとする行動を先に見せてから聞く、とも書かれています。

出力の欄にも決まりがあります。返信の下書きは、ブリーフと分けて返す。足りない情報や食い違いは、Open questionsに置く。最後に、自分の判断を待つ項目の一覧を付ける。

直しは、役割に残します。たとえば、期限を先に置いて、という訂正は、その役割へのずっと効く指示になる、という考えです。

四つの欄のうち、私が目を止めたのはWHEN TO ASKかな。やることを書く欄は思いつきやすいんです。人に戻す判断を、役割の中に書く。この線の引き方が、役割契約の芯だと読みました。

Iron Giantさん（@irongiantXBT）のXの記事「GROK BOT AGENTS」のステップ03

your bots share one account-level cloud computer, including files and signed-in browser sessions. connectors are account-wide too.

Botたちは、アカウント単位の一つのクラウドPCを共有する、と原文は書いています。ファイルも、ログイン済みのブラウザの状態も同じです。コネクタ（外のアプリとつなぐ口）も、アカウント単位です。

役割を分けても、アクセスの境界は分かれない。役割は責任を絞るためのもので、アクセスを分けるものではない、とIron Giantさんは書いています。

チームが本当に要る資料だけを選び、共有ファイルには分かりやすい名前を付ける。

最初に、仕事で使う資料を選んでつなぐ、と原文は言います。あとで専門役を足した時に、同じ作業場所を使える、とも書いています。

AI氣道『Grok BotとClaude Codeの使い分けは？StockSunの会議の答えと、私の検証でわかった3つの落とし穴』より

「私の8月の検証では、2体のBotの作業PCとログイン状態は別でした。10月には、クラウドPCに手で入れた管理ツールが消えた例もありました。」

Botごとに作業PCとログイン状態が別だった検証を、私は『Grok BotとClaude Codeの使い分けは？StockSunの会議の答えと、私の検証でわかった3つの落とし穴』で書いています。

Iron Giantさんの書きぶりと、私が見た結果は、同じ形ではありません。どちらが正しいかは決めず、事実を並べて置きます。自分のBotで確かめてから使う。私はそう考えています。

ステップ04は、ログインの手渡しです。サイトがサインインや確認を求めたら、Agent Computer（Botの作業画面）を開いて操作を引き取り、止まった所を済ませて、Botに返します。

チャットに「Signed in. Continue.」と書くと、Botは止まった所から再開します。

パスワードや一回限りのコードは、認証の流れの中に置く。会話には、止まった仕事と状況だけを書く。Iron Giantさんは、そう書いています。

私も、この向きの場面を通りました。9月12日、AIと一緒に、Grok BotのクラウドPCにLinux版のCockpitを入れました。Cockpitは、複数のAIを一つの画面で動かすアプリです。

9月13日、ブラウザでの認可は通るのに、アプリへ戻らず、ゲスト状態のまま止まりました。

9月15日に公式の.deb（Linux用のインストールファイル）の4.80.0を入れ、サインインのURLを固定の場所にあるアプリへ直接渡して、通りました。詰まりの原因は、カスタムURLの開け方でした。

この間、パスワードはチャットに書きませんでした。クラウドPCのUpdateやResetも、しませんでした。原文の、パスワードを会話に置かない向きと同じだと読んでいます。

Iron Giantさん（@irongiantXBT）のXの記事「GROK BOT AGENTS」のステップ05

save the decisions behind the clicks: what to check, what counts as complete, and how to handle a missing source.

クリックの裏にある判断を残す、と原文は言います。何を確かめるか、何をもって完了とするか、元の資料が欠けた時にどう扱うか。

ステップ05は、見せて、方法を保存する話です。繰り返す仕事で、入力がはっきりしていて、結果を確かめられるものが向いている、とIron Giantさんは書いています。

カレンダーを開き、受信箱を見て、ブリーフを作る。出発点にちょうどいい、とも書いています。

Teach a task（やり方を見せて教える機能）が使える時は、ブラウザの作業を実演して、できたスキル（保存された手順）を見直します。使えない時は、終わった仕事と書いた指示から、Botに方法をまとめさせます。

保存したスキルは、別の日の入力で動かして試します。毎回、新しい入力を使います。そうして初めて、一回限りの例ではなく、使い回せる方法になっているかが分かる、という流れです。

AI氣道『Grok BotとHermesに同じ宿題を出したら、残ったのは文章じゃなかった』より

「問題は翌朝です。ファイルはどこにあるか。公開ボタンの手前で止まっているか。「できました」は、残った仕事ではありません。」

できましたの先に残る仕事の話を、私は『Grok BotとHermesに同じ宿題を出したら、残ったのは文章じゃなかった』で書いています。

ステップ06は、定期実行にする話です。出力が繰り返す価値のあるものになってから、時刻を決めます。担当のBot、タイムゾーン、元の資料、次の実行を確かめて、テストの結果を見てから任せます。

原文の朝の例は、平日の07:30 Europe/Moscowです。最初はDaily Chiefがブリーフだけを作ります。専門役を足したあとは、同じ定期実行で、各役の報告を集められる、と書かれています。

クラウドで動くので、ノートPCを閉じていても仕事は続きます。ただ、実行が始まる時刻と、終わる時刻は別です。固定の締切があるなら、早めに始める。Iron Giantさんは、そう書いています。

イベントで動く仕事は、あとで足せます。たとえば、新しい問い合わせが入ったら下書きを始める、という形です。ただ、対応するイベントには個別の設定が要ることがあるので、狭い条件で決めて、確かめてから頼ります。

Iron Giantさん（@irongiantXBT）のXの記事「GROK BOT AGENTS」のステップ07

split by responsibility before adding more bots. every specialist should have a deliverable you can recognize, and every shared assignment should have one final owner.

Botを増やす前に、責任で分ける。専門役ごとに、見て分かる成果物を持たせる。みんなで頼む仕事には、最終の持ち主を一人置く。Iron Giantさんは、そう書いています。

原文の4役はこうです。Inbox Leadは、下書きとやり取りを持つ。Research Scoutは、調べものと出典を持つ。Life Adminは、書類や予定の段取りを持つ。

Daily Chiefは、最終の成果物を持ちます。

Daily Chiefの仕事は、専門役の出力をまとめて、確かめて、一つのブリーフにして渡すことです。役ごとの指示文も、原文に載っています。Inbox Leadは、メッセージを送らない。

Life Adminは、予約も購入もしない。

専門役を分ける理由も書かれています。受信箱の役、調べものの役、事務の役が、それぞれ見直して直せる会話を持つ、ということです。

AI氣道『Grok Bot AI社員を何体も雇う前に、仕事ごとの持ち主を一人決める理由』より

「一つのボールは、人・AI・仕組みの誰か一人が全部持ちます。その一人が、やり切ります。共同責任にはしません。所有者を一人にするのが、私の線です。」

一つのボールを一人が全部持つ話を、私は『Grok Bot AI社員を何体も雇う前に、仕事ごとの持ち主を一人決める理由』で書いています。

ステップ08は、グループチャットです。仕事が複数の役にまたがる時に、関係するBotを一つの会話に入れます。目的と最終の持ち主を渡して、分担と引き継ぎを見える形にします。

例は、取引先への訪問の準備です。やり取り、調べもの、段取りが、一つの資料に集まる必要があります。この資料の名前が、Client Visit Packetです。

引き継ぎのたびに、終わった作業、出典、次の役がまだ解いていない問いを残します。

グループは調整に使い、最終の見直しは、Daily Chiefとの直接の会話で行います。原文の例は、Client Visit Packetと出典リンク、未解決の問いで終わります。

次の一手は資料の見直しで、外へ送る連絡と予約は止めたままです。

私が目を止めたのは、成果物とセットで持ち主を決めるところです。成果物が見て分かる形になっていれば、誰が最後まで持つかも決めやすい。私はそう読みました。

Iron Giantさん（@irongiantXBT）のXの記事「GROK BOT AGENTS」のステップ09

Ask before sending messages or invitations, booking, purchasing, moving money, publishing, deleting or overwriting source data, changing permissions, or accepting terms.

ステップ09の線は、この一覧から始まります。メッセージや招待を送る前、予約する前、購入する前、送金する前、公開する前、元のデータを消したり上書きしたりする前、権限を変える前、規約に同意する前には、聞く。

ステップ09は、チームが自分で終わらせる仕事と、本人の判断が要る行動を分ける話です。下書き、調べもの、要約、資料の準備は、すでに渡したアクセスと範囲の中で進めてよい、と原文は書きます。

出典リンクと、終わった作業の短い記録も残させます。

本人に戻す時は、具体的な申し出にします。ACTIONは、正確に何が起きるか。TARGETは、影響を受ける人・アカウント・ファイル・サービス。REASONは、なぜ必要か。関係する出典と、その結果も添えます。

たとえば、返信の下書きなら、宛先と元のやり取りが付いて届く。予約の申し出なら、日付と条件が付く。Iron Giantさんは、そう書いています。

AI氣道『Grok BotとdotsのAI秘書で迷ったら、窓口を1人に決めて最初の週は下書きまでにする』より

「下書きの先、送る・払う・消すに進みたくなっても、最初の週は踏み込みません。返事に「確認が必要」と出たら、自分に戻す合図です。」

最初の週は下書きにとどめて、確認が必要と出たら自分に戻す話を、私は『Grok BotとdotsのAI秘書で迷ったら、窓口を1人に決めて最初の週は下書きまでにする』で書いています。

承認の設定は、役割の指示に合わせます。見直しの依頼は、その役の直接の会話に届けます。資料が足りなくて止まった時は、Daily Chiefが足りない入力と、影響を受ける仕事を名指しします。

原文のプロンプトには、情報が足りない時は、足りない所を名指しして、ほかにできる準備は続ける、とも書かれています。

Iron Giantさんは、決めてもらう前に準備を終えておく、と書いています。承認しますか、という問いは、次に何が起きるかが見えて初めて役に立つ、という考えです。

線を引く場所が、行動の種類で決まっているのが分かりやすいんですよね。送る、予約する、買う、公開する、消す。私はこの並びを、止まる場所の一覧として読みました。

Iron Giantさん（@irongiantXBT）のXの記事「GROK BOT AGENTS」のステップ10

a routine earns another run when it reduces the work you carry, including the effort required to review it.

定期実行が次の一回に値するのは、本人が抱える仕事が減る時、見直す手間も含めて。原文はそう言います。

ステップ10は、週15分の振り返りです。カレンダーに時間を入れて、定期実行が動いたか、出力は正しかったか、止まったら困るかを確かめます。少なくとも一つは、完了した結果を元の資料と照らし合わせます。

分け方は、USED、REWORKED、IGNOREDです。使った、直した、無視した、ということ。毎朝のブリーフは、そのままで役に立つかもしれない。

調べものの記録は、指示を明確にし直す必要があるかもしれない。重複した通知は、仕事を減らすのではなく増やしているかもしれない。原文はそう書いています。

原文のプロンプトには、使われ方が分からないものは、分からないと書いて、本人に分類を聞くこと、とあります。節約できた時間や回数を作らないことも、書かれています。

AI氣道『AIにインタビューしてもらう方法｜自分の経験をコンテンツ化する問いの設計』より

「AIは何でもできてしまうので、私は焦点を当てないと毎回不安定になると見ています。だから、AIとやる前に軸を作っています。」

AIは何でもできてしまうので焦点が要る話を、私は『AIにインタビューしてもらう方法｜自分の経験をコンテンツ化する問いの設計』で書いています。

原文の続きはこうです。使える出力は残し、書き直し続けているものは直し、ノイズになっているものは止めます。

私が考えた頼み方は、次の一文です。「今週あなたが動かした自動の仕事を一つずつ挙げて、使われたもの・直したもの・無視されたものに分けてください。

使われ方が分からないものは分からないと書いて、私に聞いてください。節約できた時間や回数は作らないでください。」

AIは何でもできてしまうので、焦点を当てないと不安定になる。私はそう見ています。だから私なら、10ステップを全部同時には始めません。AIとやる前に軸を作って、その軸から、最初の一つを選びます。

Iron Giantさんの10ステップを、順に読みました。名前を付けたBotに、翌朝のブリーフという小さな仕事を持たせるところから始まります。

ブリーフは、AGENDA、SOURCES、OPEN QUESTIONSで終わりの形を決めます。役割契約は、ROLE、INPUTS、OUTPUT、WHEN TO ASKの四つの欄です。

Iron Giantさんは、Botたちがアカウント単位の一つのクラウドPCを共有する、と書いています。私の8月の検証では、Botごとに作業PCとログイン状態が別でした。ログインが止まったら、人が操作を引き取って済ませ、Botに返して再開させます。パスワードは、会話に置きません。

専門役は責任で分け、最終の持ち主は一人にします。送る・買う・公開する・消す・権限を変えるといった行動の前に、ACTION、TARGET、REASONを揃えて、人の判断に戻します。

週15分の振り返りで、使った、直した、無視した、に分けます。10ステップは、任せる範囲を広げる手順というより、人が握る線を一つずつ置く手順として読めます。私は、その線を先に決めてから、最初の一つを選びます。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！