Grok BotのTeam Botsは直せる人と使う人を分ける社内ツール。Matt Palmerさんの動画を私の仕組みと比べた

出典: Team Bots: Grok Bots for your whole team

AIで作った仕事のやり方を、チームにどう渡していますか？動画は、team bot は「社内ツール」のようなもの、という一言から始まります。Matt さんの手元の bot を見せながらの説明です。

冒頭で Matt さんは、team bot を社内ツールのようなもの、と言います。ロジックや手順を符号化して、チームに渡して使ってもらう。それでも、手順が変わった時に直す力と、ある程度の管理は手元に残す、という説明です。

team bot は、チームと共有した Grok Bot のこと。チームで使うプランに入っていれば、自分用に作った物を、チームの誰にでも共有できると続けます。

Matt Palmer さん（動画の中で・0:49〜）

historically there haven’t been many ways for us to share our AI workflows,

これまで、AIのワークフローを共有する方法は多くなかった、という話です。チャットをコピーして貼るか、メンバーごとに別々のツールへチャットが散らばるだけ、と続けます。人のワークフローには手が届きません。

Matt Palmer さん（動画の中で・1:03〜）

if you do a lot of stuff, you become sort of a bottleneck for getting more stuff done

たくさんの仕事をこなす人ほど、物事が進むうえでのボトルネックになっていく。Slack や Teams やメールにメッセージが溜まり、それがストレスになる、と Matt さんは話します。

作った物を、チームが使えるようにしたい。チームで共有する Grok Bot は、そのための1つの方法だと言います。

確認や依頼が一人に集まると、その人が仕事を止める詰まりどころになってしまうんですよね。私もここは同じ考えです。

私なら、確認が自分に戻ってくる数を、先に数えます。戻ってくるたびに、管理のボールが私に戻るから。

確認の数を数えた話は、10月22日の記事、AIエージェントを増やしても人の確認がボトルネックになる話に書きました。

私の記事より（AIエージェントを何体並べても、人が確かめる速さを超えては進まない）

私は、2026年10月9日から16日の8日間で、AIから戻ってくる確認の質問に、2,670件答えました。1日あたり約334件。そのうち自由入力は1,353件で、51%です。

8日間で2,670件。半分は、自分の言葉で書いて返した答えです。その8日間の中の10月16日、私のボトルネックをAIに洗い出してもらうと、いちばん重いのは私が答える確認の量でした。

Matt さんは、bot をチームに配って、自分への呼び出しを減らす方へ進みます。私の側に残っているのは、答えた件数でした。10月16日にAIに洗い出してもらうと、いちばん重いのは、私が答える確認の量だったんです。減らしたい物は同じです。

AIに文章の直しを頼んだ時、直した理由まで返ってきますか？動画が次に見せるのは、Matt さんの marketing review bot。とても単純な例です。

この bot は、送られた文を、Matt さんのマーケティングとコピーの好みでレビューします。スキルは2つだけ。文章の手直しと、マーケティングのコピーのレビューです。

コピーを送ると、直した所の Before と After、そして Why が返ってきます。画面に出るのは、直す前と後と、当てはめたルールが並ぶ表。

Matt Palmer さん（動画の中で・1:46〜）

The why is important because I want people to understand what my bot’s doing.

理由まで返すのは、bot が何をしているのかを、人に分かってほしいから。Matt さんはそう話します。

強みは、編集できる協力者として人を招けること。同僚の Eric さんを招いて、マーケティングのルールの組を直せるようにもできます。社内の誰でも、使う側として招けると言います。

Matt Palmer さん（動画の中で・2:11〜）

So, we have owners and we have users.

「直せる人」がいて、「使う人」がいる。そういう分け方です。Slack や Microsoft Teams に入れておけば、タグで呼んで使える、とも見せます。

直せる人と、使う人を分ける。この分け方は、私が自分の手元で道具を直す時に取っている形と、よく似ているんです！

私なら、直す人を一人に決めて、使う側は知らせるだけにします。共同責任にすると、ボールが誰の物か分からなくなるから。

私の手元では、共通の道具の誤りに気づいたAIが、直しを引き受ける担当へ知らせを送ります。どの道具が、なぜ止まり、どこで作業していたかを書いて送る形です。

その担当は受けた件を引き取り、誤りかどうか確かめます。直して動作確認し、結果を元の担当へ返す。本番に入れるのは、いつもどおり私の承認のあとです！

ルールの直しも同じ扱いです。10月4日には、ルールはその担当に聞いて直してもらうように、と私からAIに答えています。

直す人は一人だけ。使う人は、困った所を知らせるだけにします。この分け方にすると、同じ確認や直しの相談が、一人の手元に何度も戻ってこなくなるんです。本番へ入れる時の承認だけは、従来どおり私が持ちます。

直した理由を返す話に近いのが、AIに渡すルールを事故から育てる話。10月11日の記事、AIに渡すルールを事故から育てる、禁止と権限の作り方で書きました。

私の記事より（AIに渡すルールは、書くより先に「止める所」を決める。禁止と権限の作り方）

私が指摘した事故を、AIが「何があったか」「原因」「やること」の形で書き足してきました。福田卓馬さんの、実際に起きた問題をもとに決まりを育てる方法と同じ型です。

動画の bot は、直した所に理由を添えて返します。私の決まりも、起きたことと原因とやることを書き足しながら育ってきました。理由を残すところで、2つは重なります！

AIを使うたびに、自分のやり方を書いた写しを、道具ごとに配っていませんか？動画では、Grok Bot をいろいろな道具につなぐ話から、やり方の基準をどこに置くかへ話が移ります。

Grok Bot は、いろいろなアカウントやサービス、道具につなげられる、と Matt さんは話します。社内にある brand design bot は、Slack でタグを付けても、Grok Bot の中からでも呼び出せます。

この bot は、資料の手直しや、ブランドに沿った素材づくりを手伝います。チームで育ててきた bot です。こうした「社内ツール」を、自分のやり方の「正しい基準」にする、と話は続きます。

Matt Palmer さん（動画の中で・3:08〜）

give them to your team to make them more productive, break out of this AI silo, right?

チームに渡して、みんなの仕事をはかどらせる。そうやってAIのサイロから抜け出そう、という一言です。サイロとは、AIがそれぞれ閉じた囲いの中にある状態のこと。

作り方は簡単で、bot にこう言うだけ、と Matt さんは画面で見せます。

Matt Palmer さん（動画の中で・3:19〜）

Make a team bot copy of yourself for my team.

自分をチーム用にコピーして、という一言です。これで bot のコピーができます。個人用は消してもかまいません。あとは copy link を押して、チームに配るだけ。

基準は1か所。だから、チームの全員が同じ物を使えます！

私なら、写しを増やす前に、どのAIも同じ背景を読める場所を1つにします。渡したいのは、手順だけではなく、背景と意図まで。

私の手元では、Claude・Codex・Grok の3つが、同じ本人情報と既存資産へたどり着くための入口のファイルを1つ持っています。これは正本の写しでも、新しい記憶庫でもありません。

正本は1か所に置いたまま、入口のファイルはそこを指すだけです。

推測: AIごとに私の写しを配ると、写しの数だけ、今の私はどれかという確認が私に戻ってきます。入口を1つにして、正本へ行かせる。そうすれば、直すのは正本だけ。

複数のAIに同じ約束を読ませるやり方は、10月11日の記事AGENTS.mdで複数のAIに同じ約束を読ませる使い分けでも書きました。

私の記事より（AGENTS.mdと権限・フックの使い分けをチャエンさんが解説。「メールは送らないで」と書いても守られない時の止め方）

私の作業フォルダでは、AGENTS.mdが本文の実ファイル。CLAUDE.mdは、その同じ本文を指す別名になっています。Claude CodeとCodexに、名前を変えて同じ約束を読ませる形です。

呼び名は違っても、中身は1つの約束です。写しを配らずに入口を1つ置く今の形とも、向きがそろいます！

Matt さんは、bot のコピーを作ってチームに配り、個人用は消してもよいと話します。私は写しを配りません。正本を1か所に置いて、どのAIにも、そこへ行く道だけを配っています。

毎日、同じ頼まれ方をしている仕事はどれでしょう？動画では次に、少し複雑な例として social media review bot が出てきます。

social media review bot は、独自の API サーバーと API キーを持つぶん、仕組みが複雑な例です。SNS の投稿の管理には Typefully を使っている、と Matt さんは話します。

Matt Palmer さん（動画の中で・4:27〜）

The way I created this team bot is by introspecting over my workflows, what I was doing every day.

毎日のワークフローで自分が何をしていたかを振り返って、この team bot を作った、という一言です。

このSNSの文面を見て、予約して、投稿して。そう頼まれることがとても多いと気づいて、同じことをする team bot を作った、と話は続きます。

Slack で誰かが Matt さんをタグすると、見張っている bot がそのタグを見つける流れ。文面を marketing review bot と同じ基準でレビューして、Typefully に予約します。

Matt Palmer さん（動画の中で・5:01〜）

And so, this saves me a bunch of time. I can give this to all my teammates and it saves me from getting pinged.

時間がたっぷり浮いて、チームの全員に渡せる。そのうえ、呼び出されることも減る、と続けます。

画面に並ぶのは、スキル3つと鍵、30分ごとに回るルーティン。このルーティンが Slack を見て、タグされるはずだったのにされていない所を探す、と Matt さんは話します。

毎日の仕事を振り返り、頼まれ続ける仕事から先に形にしていく順番は、私も同じ向きで考えています！まずは順番からです。

私なら、頼まれ続ける仕事の判断軸を自分で掘ってから、実行と量産を1つの仕組みに渡します。何を大事にするかは、自分で決めて渡します。任せるのは実行だけです。

頼まれ方を記憶ではなく履歴で数えた話は、10月10日の記事繰り返す仕事を履歴から数えて専任のAIに分ける話に書きました。

私の記事より（履歴から専任を作る話（2026年10月10日の記事））

自動便は、決まった時刻に同じ仕事を回す専任役です。その75本のうち上位10本だけで296件。全673件の44%を占めていました。仕事は均等には広がっていませんでした。

決まった時刻に同じ仕事を回す専任のうち、上位10本に全体の4割あまりが集まっていました。仕事は均等には広がりません。繰り返しの多い所に偏ります！

Matt さんは、よく頼まれることに気づいて、そこから1つの bot を作りました。私は履歴を数えて、繰り返しが上位に集まる所を見ました。どちらも、毎日の仕事を振り返ってから作る物を決める順番。

team bot をいつ作るか。迷った時に Matt さんが目安に置くのは、社内ツール（internal tool）です。社内ツールという言葉は、いやな響きに聞こえる人もいる、と前置きもします。手元にも、誰かが作って、直し続けている共有の物はありませんか？

仕事をしたことがあれば、誰でも社内ツールを作っている、と Matt さんは話します。例は、共有のデッキのテンプレート、シート、メールのテンプレート、マクロ。画面には、デッキのテンプレートと、それを写したデッキのカードが並びます。

Matt Palmer さん（動画の中で・6:41〜）

And so, internal tools are things that you create and maintain that help your team get more work done.

社内ツールは、チームがより多くの仕事をこなせるように、作って保守する物だと Matt さんは話します。ロジックと手順を符号化して、人を助けるために渡す物。自分自身のコピーを作っているようなもの、とも言います。

Matt Palmer さん（動画の中で・6:52〜）

really AI is an internal tool and it hasn’t been officially democratized.

AIは社内ツールなのに、まだ正式には民主化されておらず、共有できるテンプレートにもなっていない、と続けます。team bot は、作った人が手を入れて更新しながら、チームに渡せる形。

Grok Bot は、仕事のための道具。team bot はチームの一部にも全員にも共有でき、権限も付けられます。含められるのは、ルーティン（routine）、鍵、スキル、記憶、コンピューターへのアクセスまで。Grok Bot の裏側は、コンピューターを持つエージェントだと話します。

道具は、作った後が本番！保守する人がいて、初めてチームの道具になります。

私なら、道具を配って終わりにせず、相手が自分で動ける場と持ち場まで渡します。

コンピューターを持つ bot の落とし穴は、10月11日の記事、Grok BotとClaude Codeの使い分けと、クラウドPCで分かった落とし穴で書きました。

私の記事より（Grok BotとClaude Codeの使い分けは？StockSunの会議の答えと、私の検証でわかった3つの落とし穴）

原因の記録はありません。推測: クラウドPCが作り直された。手元に残った学びは、「クラウドPCに手で入れたアプリは消えることがある。残るのは /workspace だけ」です。

コンピューターを持てるのは、bot の強み。でも、そこに何が残るかは、保守する人が確かめに行かないと分かりません。ログインできても、入れた物が残るとは限りません。

動画の終わりに出てくる Grok Bot の裏側は、コンピューターを持つエージェントです。そこに何が残るのか？ 私は、そのコンピューターに何が残るかを確かめてから、保守する持ち場を決めたいんです！

Matt Palmer さんの英語の動画は、Team Bots を、ボトルネック、直せる人と使う人、やり方の基準（source of truth）とチーム用のコピー、毎日の仕事を振り返って作る、AIは社内ツール、の5つの話で見せていました。

動画が配るのは、自分のやり方のコピー。私は配る前に、確認の数、直す人、正本の入口、繰り返しの偏り、保守する持ち場を、それぞれ一つに決めます。

AIの手順をチームに渡すなら、直す人は一人、使う人は知らせるだけ。コピーを配るか、同じ正本を読ませる入口を1つ置くかは、自分の仕組みで選べます！

動画の最後で、Matt さんはボトルネックにならず、自分と仲間の時間を空けようと呼びかけます。私の手元では、直す担当が一つです。共通の道具の直しはその担当が引き受け、使う側は知らせるだけ。

手元のAIのやり方のうち、チームに配りたい物と、一つに決めて持っておきたい物は、どこで分かれていますか？