Slack・Teamsの@ChatGPTで何ができる？呼び出し方と情報の共有範囲

チームの会話から呼び出せる機能

@ChatGPTは、SlackやMicrosoft Teamsの会話の中に、ChatGPTを呼び出せるようにする仕組みです。掲載した公式画像は、メッセージ欄に「@ChatGPT、この議論をスライドにして」と入れた場面です。

機能ページでは、次の3つの使い方が紹介されています。

チームで一緒に作業する：チームのチャンネルやスレッドで@ChatGPTを呼び、ローンチの計画やバグの調査を進める。ほかのメンバーも、背景や質問、フィードバックを足せる

スレッドの外の情報も使う：接続したツールから、プロジェクトの詳細や関連ファイル、更新を探してもらう

議論を使える形にする：ごちゃついた会話を、概要、プレゼン、スプレッドシート、計画にまとめてもらう

そのほか、機能ページには、次のようなことも書かれています。

直接メッセージで、共有する前に、ひとりで作業を進めることもできる

接続したツールで何かを実行する前には、承認を求められる

繰り返す仕事は、定期的なチームタスクにできる（チームタスクの記事）

管理者向けに、監査ログと、活動の監視も用意されている

• 出典：OpenAI「DevDay 2026 の振り返り」（新しいタブ）

使い方の流れ

公式ドキュメント（Slack向けのページ）にある依頼の例を、要点だけ訳します。

続けて、同じスレッドで、こう頼みます。

ポイントは、同じスレッドで続けることです。関連する依頼は、同じスレッドで@ChatGPTを呼び直して続ける、と案内されています。

また、機能ページには、@ChatGPTは、チャンネルの過去のやり取り全体や、非公開の会話、個人のChatGPTの履歴に、自動ではアクセスできないと書かれています。必要な背景と、開けるリンクは、依頼のときに自分で伝えます。

• 出典：公式ドキュメント：ChatGPT in Slack（新しいタブ）

コードの作業は、Codex Cloudへ

Slack向けのドキュメントには、クラウド委任（Cloud delegation）の説明もあります。有効な場合、@ChatGPTは、リポジトリの作業を、別のCodex Cloudのタスクに送り、結果をスレッドに返します（Codex Cloudについては、Codex クラウドの記事）。

ワークスペースでCodex Cloudが有効で、公開済みの環境が、ワークスペースに共有されている必要がある

リポジトリの作業は、依頼した人のアカウントで、別のタスクとして動く

実行前に、依頼者だけに見える承認カード（Allow／Deny）が出ることがある

設定によっては、依頼者に「Follow along（追いかける）」と「Cancel（取り消し）」の操作が出る。Follow alongでタスクの中身を見られるが、チャンネルの返信だけでは、ほかのメンバーが中身を見られるわけではない

個人用のクラウド環境は、この流れの対象外。別の環境を使いたいときは、新しい会話で、リポジトリや環境の名前を書く

以前に「@Codex」を使っていた場合は、管理者がChatGPTアプリを有効にしたあと、新しい依頼は「@ChatGPT」で始める、と書かれています。

権限の仕組み：ここが一番大事

@ChatGPTで、いちばん間違えやすいのが、誰の権限で動くのかです。

公式ドキュメントの説明を整理すると、次のとおりです。

@ChatGPTは、設定された接続と、会話の内容を使う。個人のファイル、アプリ、非公開チャンネルへのアクセスは引き継がない

会社共通のアクセスは、管理者が用意した会社のアカウントの権限で動く。参加者の個人のアクセスと違うことがある

個人で接続したプラグインを使うには、対応している場合に、別の許可が必要

返信は、その会話の参加者に見える。ファイルやリンク先には、別の権限がある場合があるので、共有前に、チームの人が開けるかを確かめる

Slackの公式ドキュメントには、承認の画面が非公開でも、その結果の返信までは非公開にならないと書かれている。パスワードなどの秘密は、Slackの依頼に書かない

他の組織と共有するSlack Connectのチャンネルは、この使い方の対象外

開始時点では、@ChatGPTはメモリを使わない

「会社共通の権限」は、便利な反面、本人が見られない情報が、返信に混ざる可能性があります。公式ドキュメントも、接続先の権限を、管理者が事前に確認するよう案内しています。

導入する管理者の方へ

導入の流れは、公式ドキュメントに、役割ごとに整理されています。

ChatGPTのワークスペース管理者：プラットフォームをつなぎ、サーフェス（@ChatGPTを使える場所と、使える道具の単位）を作り、プラグインとワークスペースの接続を選ぶ

SlackまたはTeamsの管理者：権限を承認して、アプリを入れる。Teamsは、利用者への割り当てや、Microsoft側の同意も管理する

接続の担当者：承認された会社のアカウントを用意し、権限を確認する

パイロットの担当者：試す対象と、使えるべきでない人を決める

Slackの場合は、Slackのワークスペースごとに、サーフェスを1つ設定します。Enterprise Gridは、つないだワークスペースごとに1つです。

チャンネルで試験導入するときは「Selected channels only（選んだチャンネルのみ）」を選んで、承認したチャンネルだけに限定する、と案内されています。

ただし、これはDMを止めません。すでに「ChatGPT in Slack」を使っている組織は、Slack管理者が追加の権限を承認する必要があり、既存の設定は、開始時点ですぐには止まらないと書かれています。

公式ドキュメントは、広げる前に、上の4つを確認するよう勧めています。権限や接続を変えたときは、関係する確認を、やり直します。

使い始めるなら

利用例として、最初は読むだけ・まとめるだけの使い方から始めます。たとえば、長いスレッドを要約して、決まったことと未決の点に分けてもらう、といった使い方です。

Slackは、チャンネルの全員が読める場所です。@ChatGPTの返信も、そこに残ります。会社共通の接続を使うほど、返信に何が混ざるかを、事前に決めておきたいところです。

「どの接続を許すか」「どのチャンネルで試すか」を、小さく決めて始めるのが、公式が勧める進め方とも合っていると思います。

チャンネルの相談を頼むときの具体例

新商品の提案を相談したチャンネルで、決定事項だけを取り出したい場合を考えます。依頼には対象の会話、必要な形式、AIが決めてよい範囲を含めます。書きかけの案や、誰も承認していない予算まで確定事項としてまとめられると、その後の判断が変わってしまいます。

現在の管理者ガイドでは、@ChatGPTは接続した会社アカウントの権限を使い、会話の参加者それぞれの個人用アクセスを自動的に引き継ぐわけではありません。

使うツールが読める情報と、回答を見る人の範囲を確認します。共有される回答の中に、元のファイルを開けない人へ渡してはいけない情報がないかも見る必要があります。

最初の試用では、共有してよい公開資料や架空のデータで、読める範囲と返信する範囲を確認すると進めやすくなります。管理者が設定したチャンネルの制限と、ダイレクトメッセージの扱いは同一とは限りません。