Grok Team Botsのその後――仕事の手順と、確認する人を分ける

初稿：2026年9月29日／公式発表：9月28日／再確認：11月2日。過去の発表を振り返る記事です。サムネイルはAI生成の概念イラスト、図解は説明用で、製品画面ではありません。

同じ背景や文章のルールをAIへ何度も説明する。その手間を減らすには、役割だけでなく、資料・権限・完成条件も共有する必要があります。Grok Team Botsを題材に、チームで使うAIの引き継ぎを考えます。

共有する手順と、個人の会話を分ける

9月28日の公式発表は、Team BotsをTeams／Enterprise向け公開ベータとして紹介しました。資料やスキル、アプリとの接続を持つBotをチームで使い、Slackへ招く構成です。これは発表時点の説明で、正式提供への移行を今回確認したという意味ではありません。[1]

図1：共通の手順を使い、個人の会話と記憶は分ける

現行のShared Bots資料では、各人の会話は非公開のまま、所有者が追加したアプリ・秘密情報・スキル・ファイルは共有先全員の利用に関わると説明されています。個人の会話が非公開でも、共有Botへ渡す資料まで個人専用とは限りません。[2]

共有前には「チーム全員に使わせてよい資料か」「その接続先で誰として操作するか」を確認したいところです。これは運用設計上の提案で、実機の権限試験結果ではありません。

下書きから、プレビューと確認へ

公式発表のマーケティング例では、文章をブランド基準で確認し、承認されたサイト変更をプレビューへ進め、最後の確認を人へ渡します。開発ではCloud Agentsとの調整も紹介されています。提供元の事例で、MORIが同じ成果を再現したわけではありません。[1]

図2：制作の確認からプレビュー、最終承認へ

現行資料は、共有Botでも危険を伴う操作の前に、その依頼者へ承認を求めると説明しています。[2] 「仕事を共有すること」と「誰でも無条件に実行できること」は別の設計項目です。

一つの文章業務から、引き継ぎを設計する

まずは架空の原稿と公開可能な文章基準を使い、「基準との照合と修正案の作成」だけを任せる案です。公開や送信までを一度に含めず、入力不足と確認待ちを区別して返してもらいます。

図3：制作に使う場合の小さな試行案

以下は編集部による仕事の分担案です。製品の設定や実行済みの手順ではありません。

渡すもの：公開可能な架空の原稿、文章基準の版と適用日。

任せること：基準との照合と修正案の作成。

人に残すこと：公開と外部送信の判断。

受け取るもの：修正案、変更理由、未確認事項、確認箇所。

この例の狙いは、下書きができた状態を、公開・確認まで済んだ状態と混同しないことです。基準が渡っていない場合は修正を推測せず不足として返す。未確認の数値がある場合は、その箇所を示して確認待ちにする。成果物を受け取る側が次の操作を判断できる形にします。

比較するなら、同じ原稿と基準を使い、説明のやり直し回数、修正の往復、見落としを記録します。速度や生成量だけで便利さを断定しません。この試行は未実施であり、自動実行する設定でもありません。

まとめ

チームで使うAIには、共通の仕事の進め方と、各人の情報の境界が必要です。今日できる小さな一歩は、一つの仕事について「渡す資料」「任せる操作」「確認する完成物」を一枚に書くこと。Team Botsの利用条件や組織の設定は、その設計と分けて確認してください。

出典

1. 公式発表：Team Bots — 2026年9月28日。発表時点の公開ベータと事例。

2. 公式資料：Shared Bots — 2026年11月2日確認。共有範囲・会話・接続先・承認。

3. 公式資料：Create and manage Bots — 2026年11月2日確認。役割・資料・承認境界を持つBotの設計。

本記事では製品の契約・連携・コード実行・独立した性能検証は行っていません。図3と仕様例は編集部の提案です。

文章業務の依頼文と確認手順を整えたい方へ

文章業務1種類について、専用プロンプトと運用マニュアルを整理するサービスです。BotやAPIの実装・自動送信は含みません。