xAIがTeam Botsを発表：チームの業務フローに入り、使うほどビジネスを理解するAI同僚

xAIは、チーム全体で共有し、実際のワークフローに参加させられるGrok Bot、Team Botsを発表した。「仮想の同僚を一人採用する」と考えると分かりやすい。通常のチャットアシスタントは、その都度プロジェクトの背景を説明し直す臨時コンサルタントに近い。一方、Team Botはチームの業務マニュアル、道具箱、アクセス範囲を限定した入館証、そして仕事のノートを持ち、どこで情報を探し、どのルールに従い、前回どこまで進んだかを把握する。

解決しようとしているのは「AIが質問に答えられない」という問題ではない。顧客の動向はGong、プロジェクトの決定はSlack、タスクはLinear、ガイドラインはNotion、データはウェアハウスというように、企業の業務コンテキストが分散していることだ。質問のたびに背景情報を運び直す必要があり、担当者が交代すれば、それまでの判断まで失われかねない。そこで、営業アカウント、エンジニアリングプロジェクト、ブランド審査、データ分析などを中心にTeam Botを作り、資料、ルール、アプリ連携、API権限、長期的な記憶を持たせることで、同じ仕事を継続して追えるようにする。

主な特徴

• 一つの役割や業務プロセスを中心に共有Botを作る： 毎回新しい会話を始めるのではなく、営業アカウント、開発プロジェクト、マーケティング審査、データQ&Aなどを継続して担当する役割を用意できる。
• コンテキスト、プラグイン、認証情報、記憶を一体化する： チームの仕事の進め方を理解し、業務システムに入り、許可された機能を使い、後から加わった決定や修正を覚えられる。
• Slackや業務アプリとつなぐ： Gong、Notion、GitHub、Linear、Databricksなどから変化を読み取り、ブリーフィング、チケット、プレビュー、分析結果をチームの協業の場へ戻せる。
• チームの能力は共有し、個人の会話は分ける： メンバーは同じ知識とスキルを利用するが、それぞれの個別会話と個人コンテキストは分離されたままになる。
• 使い続ける中で組織知を蓄積する： チームが確認した決定や修正を記憶し、次に同じ種類の仕事をするときに、毎回ゼロから説明し直す必要を減らす。

1. 共有コンテキストで、一つの役割の仕事の進め方をそろえる

Team Botは、チームで共有する役割や業務プロセスを中心に作られる。社内ファイル、作業手順、スキルを与えることで、その会社が顧客対応、コードの出荷、ブランドコンテンツの審査、データ解釈をどのように行うかを理解させる。

xAIは、この役割の能力を四つに分けている。

• コンテキスト（Context）： ブランドガイド、社内文書、納品プロセスなどのファイル、指示、スキル。会社がどのように仕事をするかをBotに伝える。
• プラグイン（Plugins）： Salesforce、Notion、GitHubなどとの接続。実際に仕事が行われるシステムをBotが読み取ったり操作したりできるようにする。
• 認証情報（Credentials）： 既製のプラグインがないチームのシステムに接続するための第三者API認証情報。呼び出せる範囲も制限する。
• 記憶（Memories）： 仕事を通じて蓄積した決定、修正、利用者のコンテキスト。後続タスクで、それまでの判断を引き継げるようにする。

「仮想の同僚」という比喩を続けるなら、Contextは入社時に渡される業務マニュアル、PluginsはSalesforce、Notion、GitHubなどを使うための道具、Credentialsは指定されたシステムにだけ入れる入館証、Memoriesは仕事のたびに更新されるノートだ。

四つの能力は、つながって初めて意味を持つ。業務マニュアルだけなら資料を調べるだけ。プラグインと認証情報だけならシステムには入れても、チームが望む進め方は分からない。記憶がなければ、前回直した判断を次回もまた説明することになる。四つがそろうことで、Botは「質問に一回答える」存在から「一つの仕事を継続して追う」存在へ変わる。まずルールを理解し、該当システムから情報を取り、許可された操作を行い、新しい決定と修正を次のタスクへ持ち越す。各メンバーがその場で組み立てていたコンテキストが、チーム全体で繰り返し使える仕事の土台になる。

2. アプリとAPIをつなぎ、情報を次の行動に変える

Team Botは資料を読むだけではない。プラグインとAPI認証情報を通じて複数のシステムの変化を追い、チームが定めた手順に沿って次のステップを進められる。

四つの事例は仕事の種類こそ違うが、基本の流れは共通している。

1. 文書、通話、Slack、チケット、監視システム、データテーブルから最新状態を読み取る。
2. ブランド基準、納品プロセス、指標定義、アカウント戦略を使って変化を解釈する。
3. 下書きを作る、チケットを作成する、実行Agentを呼び出す、コンテンツを更新する、または読み取り専用クエリを開始する。
4. ブリーフィング、プレビュー、証拠、ブロッカーをSlackへ戻し、チームが続きを処理できるようにする。
5. 新しい決定と修正を記録し、次のタスクに使う。

したがって、その役割は一つの回答を生成するだけではない。分散した情報を、先へ進められる一つの仕事の流れにつなぎ直すことにある。

3. チームの能力を共有しながら、個人の会話は非公開に保つ

チームが共有するのは、Bot本体と、その役割知識、スキル、チーム設定である。Team Botは専用のSlackアカウントを持つこともできる。チャンネルに追加すれば、メンバーは質問し、情報を補い、回答を一緒に確認できる。

個人とTeam Botの直接の会話は非公開のままだ。xAIの説明では、Botは各利用者のコンテキストと記憶を分離して保ちながら、チーム所有のスキルを呼び出す。プラグインは個人が接続することも、チームで一括設定することもできる。

つまり、共有の中心は全員のチャット履歴を統合することではなく、仕事の進め方を共有することだ。公開チャンネルは共同作業を支え、個別会話はそれぞれの仕事の現場を保持する。

4. 継続利用の中で、決定と修正を蓄積する

記憶があることで、Team Botは長期的な仕事を続けられる。ただし「使うほど業務を理解する」という表現は、自動的に賢くなるという意味ではない。背後には具体的な循環がある。チームが提供した資料とルールを読み、Slackや業務システムでタスクに参加し、チームが確認した決定、修正、利用者コンテキストを残す。次に同種のタスクが来たとき、それらを再利用し、ゼロから推測し直さない。

xAIのデータチームは、正しいデータソース、分析方法、グラフ作成ルールを示すため、4万5,000を超えるテーブルを対象にスキルライブラリを構築している。Data Botはこの既存知識に接続したうえで、利用者がクエリに加えた修正も記憶する。ここでいう「学習」は、会社の全データを自動的に読むことでも、会話のたびに基盤モデルを再学習することでもない。原文が説明しているのは、スキル、記憶、クエリの修正を後のタスクで再利用する仕組みだ。Team Botが使うほど業務を理解するのは、組織知とフィードバックが残り続けるからであり、モデルが何もないところから業務常識を得るからではない。

四つの場面でTeam Botはどう働くのか

営業とカスタマーサクセス：毎日のアカウントブリーフを作る

xAIは重要な営業アカウントごとに専用Team Botを設け、アカウントエグゼクティブ（AE）、カスタマーサクセスマネージャー（CSM）、ソリューションアーキテクト（SA）、営業責任者が共同で使っている。従来は、それぞれが顧客状況の一部だけを持っていた。最近の通話内容を知る人、技術的な障害を知る人、アカウント戦略を知る人が分かれ、全体像はツールとメンバーの間に散らばっていた。

Team Botは毎晩、企業ニュース、直近のGong通話、Notion文書、関連するSlackの議論を確認する。翌朝、アカウントチャンネルにブリーフを投稿し、役割ごとの次の行動案と下書きを示す。日中、チームはアカウントデータと照らして判断を確認し、新しい決定を残す。そのため、Botはアカウントの「生きたリファレンス」に近づく。節約できるのは朝報を書く時間だけではない。背景を知る同僚を探し、最新状態を手作業でつなぎ、担当交代後に口頭で引き継ぎ直す手間も減る。

HarperのCEO、Dakotah Rice氏は、同社のチームが24時間でTeam Botを構築し、三つのプラットフォームをまたいで失効した保険契約の顧客を特定し、残高を確認して、個別メールを送ったと述べている。また、この仕組みにより数百件の契約で顧客に12万ドル超の損失を防げたとしている。これは顧客が提供した事例数値である。

プロダクトとエンジニアリング：チケット、Agent、納品証拠を調整する

xAIのエンジニアリングTeam Botは、プロジェクトのSlackチャンネルから情報を取得し、Notion、Linear、Hex、Datadog、Cursorに接続する。開発の流れはツール間で途切れやすい。プロダクト上の決定はチャットに残り、バグは誰かがチケットにまとめ、実行Agentがコードを修正した後には、テストと納品証拠を誰かが確認しなければならない。

Team Botはこの流れをつなぐ。決定を追跡し、不具合を分類し、明確なLinearチケットを作り、境界がはっきりした修正をCloud Agentsへ渡す。スキルを通じて、PRのレビュー方法、人にエスカレーションすべき時点、変更完了に必要な証拠を教える。実行Agentがチェック済みで検証証拠のあるPRを返すと、BotはSlackに進捗とブロッカーを報告する。置き換えるのは、ツール間で情報を運び、進捗を見張る調整作業であり、複雑な変更に対するエンジニアの判断ではない。

xAIは、この製品の開発中に一つのTeam Botが数百のCloud Agentsを編成し、5人のチームが数週間でリリースを完成させ、1日100件を超えるPRを提出するのを支援したとしている。これはxAIが自己申告した本番データであり、原文にはPRの規模、手戻り率、人だけで作業した場合との比較は示されていない。

マーケティング：共通ルールで審査し、プレビューまで届ける

大規模なマーケティングチームには、二つの待ち時間が生まれやすい。地域チームがコンテンツを書き終えても、時差をまたいで本社のブランド確認を待つ。WebサイトやSEOの文案が承認されても、サイトを変更するには開発チームへチケットを出して待つ。マーケティングBotにブランドガイド、ブログ記事、SNS文案を持たせれば、Slackに下書きが投稿された時点で、ブランドトーンと最新情報に照らして一次審査し、各地域が同じ基準を使えるようにする。

審査を通過した後は、WebサイトやSEOコンテンツを更新し、プレビューリンクを作り、最終確認のためSlackへ戻すところまで進められる。短縮されるのは「本社の一次審査待ち」と「開発チームの作業待ち」の二つだ。最終的な人の承認は残り、AIが独自に公開を決めるわけではない。

Amplitudeのマーケティング責任者Angela Ferrante氏は、同社が市場・顧客インテリジェンス、AI検索での可視性、リリース審査、効果判断にTeam Botsを活用する実験を進めていると述べている。

データ分析：読み取り専用権限で、その場の質問に答える

xAIのデータチームには、毎日数十件の臨時分析依頼が届く。従来の流れでは、事業部門がまずアナリストの順番を待ち、アナリストが指標の定義を確認し、正しいテーブルを探してクエリを書く。一度きりの質問でも、何往復もの調整が必要になることがある。

Data Botは共有の読み取り専用認証情報を使い、Databricksでアクセスを許可されたテーブルを照会し、Datadog、Hex、Statsigと連携して調査、分析、可視化を行う。社員はアナリストの順番を待ったり、自分でウェアハウスへのアクセスを申請・設定したりせずに、業務上の質問を直接できる。データチームが過去2年間に4万5,000超のテーブル向けに蓄積したスキルライブラリが、正しいデータの発見、指標の理解、社内基準に沿ったグラフ作成を助ける。誰かがクエリを修正すれば、後の利用者が同じ間違いを避ける助けにもなる。ただし、これはアクセス範囲が限定されていることが前提だ。Botは読み取り専用認証情報を使い、許可されたテーブルだけを照会できる。

四つの場面に共通する変化

表面的には、四つのBotは朝報を書き、チケットを作り、文案を審査し、データを調べている。しかし本当に共通する変化は、人が毎回「情報の運び手」にならなくてよいことだ。Botはチャット、文書、業務ソフト、データウェアハウスに散らばった情報を一つの仕事の流れへ戻し、明文化されたチームのルールに沿って次のステップを進める。

そこから三つの具体的な価値が生まれる。情報が別々のツールにあるために何度も探し直す必要が減る。担当者が異動・退職しても、確認済みの決定や進め方を引き続き使える。アナリスト、エンジニア、本社の審査担当者など希少な役割は、資料探し、チケットの中継、一次審査に費やす時間を減らし、本当に判断が必要な例外や複雑な問題へ注意を向けられる。

どのチーム業務からTeam Botにするとよいか

Team Botsは現在、TeamsおよびEnterpriseプラン向けにパブリックベータとして提供されている。既存のGrok Botをチームに共有できるほか、xAIが用意した営業、プロダクト管理、マーケティング、データ分析向けのプリセットBotから始めることもできる。

ある仕事がTeam Botのような仕組みに向いているか判断するには、五つを確認するとよい。

• 繰り返し発生し、コンテキストが分散しているか。 毎日複数のシステムを調べて変化をまとめる業務は、一度きりの質問より共有Botに向いている。
• チームのルールを明確に説明できるか。 ブランドガイド、PR完了基準、指標定義、エスカレーション条件が明確なほど、Botは安定して実行しやすい。
• 最小権限で仕事を完了できるか。 読み取りだけで済むなら、最初から書き込み権限を与えない。コンテンツ変更が必要なら、プレビューと最終承認を分ける。
• 共有と非公開の境界が明確か。 チームのスキル、公開チャンネル、個人の会話では扱う情報が異なるため、可視性と引き継ぎルールを先に決める。
• 結果を検証できるか。 生成量だけでなく、待ち時間、手戻り、エラー、人へのエスカレーション回数、既存の品質基準を通過したかを見る。

最も始めやすいのは、役割が明確で、資料を制御でき、結果を検証できるプロセスだ。Team Botsが示す方向もはっきりしている。企業向けAIは、個人のQ&Aツールから、チームが共同設定し、システムにつながり、仕事の記憶を継続的に蓄積する役割へ向かっている。