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

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

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

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

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

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

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

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

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

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

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

以下は編集部による引き継ぎ仕様の例です。Grokの設定APIや製品が読み込む正式スキーマではありません。

job: review_one_draft
inputs:
  draft: 公開可能な架空の原稿
  criteria: 文章基準の版と適用日
allowed_actions:
  - 基準に照らして修正案を作る
approval_required:
  - 公開
  - 外部送信
output:
  - 修正案
  - 変更理由と対応する基準
  - 未確認事項
  - 人が確認する箇所
status:
  missing_input: 必要資料が足りない
  ready_for_review: 修正案があり人の確認待ち
  verified_complete: 人が完成物を確認した

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

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

まとめ

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

出典

公式発表：Team Bots — 2026年9月28日。発表時点の公開ベータと事例。
公式資料：Shared Bots — 2026年11月2日確認。共有範囲・会話・接続先・承認。
公式資料：Create and manage Bots — 2026年11月2日確認。役割・資料・承認境界を持つBotの設計。

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

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

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