AIエージェントは、​チャット欄から​「チームの​作業場」に​引っ越した​ ──Claude Tagが​示す、​次の​競争軸は​“作業場設計”

技術ノート ｜ AIの最新動向を、現場目線で

AIを使うとき、私たちはずっと「別タブ」を開いてきた。ChatGPTやClaudeを開き、必要な背景を貼り付け、返ってきた答えを別のツールへ書き戻す。Claude CodeやCodexが開発者の手元に入ってからも、作業の多くは「自分ひとりのセッション」のままだった。

2026年6月23日、Anthropic が発表した Claude Tag は、その境界を越えにいく。Slackのチャンネルに @Claude として常駐し、選んだチャンネルとツールの文脈でタスクを受ける、Team / Enterprise 向けの beta だ。^[1] ニュースを「ClaudeがSlackで使えるようになった」と読むと、半分しか見えない。本当に動いたのは、AIのUIが「個人のチャット欄」から「チームの作業場」へ引っ越したことだ。

私たち電脳技巧集団（AI職人ギルド）は、LINE WORKSや自社サイトのチャットにAIを常駐させる仕組みを実際に作ってきた。だからこの発表は、新機能の紹介ではなく、「次のAI導入の競争軸は、promptの上手さではなく"作業場設計"になる」サインとして読む。以下、外部の機能・数値は各社の公式発表や報道に基づくもので、CAGが再現・検証したものではない点は先に断っておく。

01​「Slackで​Claudeが​使える」では、​半分しか​読めていない

これまでのAI活用は、人間が文脈を運ぶ作業の連続だった。課題を見つけたら、関連するやり取りや仕様を探し、AIの画面へコピーし、出力をまたツールへ戻す。AIは賢くても、仕事が流れている場所の外にいた。文脈を運ぶ手間と、運び忘れによる勘違いが、毎回そこにあった。

Claude Tagは、その運搬作業を反対側から消しにいく。Slackという、会話・意思決定・タスク・障害対応・顧客対応・コードの相談が流れる場所に、AIが共有メンバーとして入る。^[1] 人間がAIのところへ文脈を持っていくのではなく、AIが文脈の流れている場所へ来る。違いは小さく見えて、運用の形を変える。チャットAIは「開いて使う道具」だったが、常駐AIは「すでにその場にいる相手」になる。

02個人チャットから、​組織の​作業場へ

この移動は、ある日突然きたわけではない。ここ半年、各社が同じ方向へ少しずつ寄っていた。流れで見ると、Claude Tagがどの地点にあるかが分かる。

道具立てはClaude Tagだけではない。Slackは Agentforce / AI agents として、チャンネル・DM・スレッドの中でagentをチームメイトのように使う方向を、すでにプラットフォーム戦略として打ち出している。^[2] GitHubは社内データ分析agent「Qubot」の設計を公開し、Slackやエディタから呼んで、結果をMarkdownレポートやPRとして残す形を見せた。^[3] Anthropic自身も、危険な操作は止めて安全な操作は自動で進めるauto modeの方向を出している。^[4] 入口はそれぞれ違うのに、「AIをチームの作業場に置き、必要なときに呼んで、結果を同じ場所へ返す」という同じ地点へ寄っている。

03本当の​課題は、​promptではない​ ──記憶・権限・監査・担当範囲

AIを作業場に常駐させると、便利さと同じだけ、設計の重さが増える。Slackは会社の記憶そのものに近い。意思決定の経緯、顧客とのやり取り、まだ撤回されていない方針、private な相談まで、構造化されないまま流れている。そこにagentが住むなら、「便利だから全部読ませる」では済まない。何を読み、何を覚え、何を忘れ、どの操作で止まるかが、本体の設計になる。

「AI teammate」という呼び方は便利だが、設計としては権限を持ったサービスアカウント＋記憶＋ツール＋監査ログに近い。人間の同僚と同じ責任能力があるように聞こえるところが、いちばん危うい。実際の責任者・承認者・監査者は、人間側に残る。だから常駐AIの良し悪しは、賢さよりも「読むべき場所・覚えるべきこと・忘れるべきこと・止まるべき操作」がはっきり決まっているかで分かれる。情報を多く読ませるほど賢くなる、という方向はここでは通用しにくい。

04​私たちは​既に、​チャットに​AIを​住まわせてきた

この「作業場設計」は、私たちにとって新しい議論ではない。CAGはクライアントの LINE WORKS に、トークルームへ常駐するナレッジBotを実装している。チームの会話から知識を貯め、後から「Wi-Fiのパスワードは？」「請求はいつ？」に答えるAIだ。作ってみて分かったのは、常駐AIで難しいのはAIの賢さではなく、"何を知識として取り込むか"の境界だった。

つまずきは、最初に2つ出た。ひとつはメタ会話の混入。受信したメッセージをそのまま知識の材料にすると、「Wi-Fiは？」という質問まで取り込まれ、「Wi-Fiは不明」という知識に化けてしまう。もうひとつは確定情報の上書き。新しい会話と既存の知識をAIにまとめさせると、曖昧な発言を根拠に、確定済みの値（例：Wi-Fiは gmj-2026）が「確認中」へ格下げされてしまうことがあった。便利さに任せて全部AIに委ねると、大事な情報が静かに壊れる。

対処は、AIの外側にコードの関所を置くことだった。会話を取り込む段階で、/コマンド・メンション・1対1のDMといった「人↔AIのやり取り」を知識の材料から外し、人間同士の業務会話だけを知識化する。さらに、AIがまとめた結果に対して、既存の確定値が消えたり曖昧語へ格下げされたらコードで強制的に元へ戻す。判定は純粋な関数に切り出し、「質問されても確定値が消えない」「格下げ攻撃を受けても復元する」をテストで固定した。AIには提案だけをさせ、最終確定はコード側のガードに通す。常駐AIの安全は、賢いpromptではなく、この境界の置き方で決まる。

05常駐AIを​置く​前に、​決めて​おく​こと

Slack / Teams / LINE WORKS のどれであっても、AIを作業場に置く前に確認すべき項目は共通している。自社で導入する前のチェックリストとして、6つを表にした。^[5]

決めること	悪い置き方	安全な置き方
席（範囲）	全チャンネルを読ませる	役割ごとに常駐先を限定し、最小権限で始める
記憶	会話を全部そのまま覚える	決定事項だけを構造化して残し、古い・撤回済みは忘れる
権限（ツール）	読み・書き・外部送信を一括で許可	操作ごとに分け、外部送信や破壊的操作は承認制
監査	「やったこと」だけ記録	何を読み、なぜそう判断したかまで残す
担当範囲	何でも屋にする	やる仕事・やらない仕事を明文化する
成果物	チャットに垂れ流す	レポート・PR・台帳など、決まった置き場に残す

※ Claude Tag固有の管理機能（監査ログの粒度、記憶の保持・削除、チャンネル間の分離、権限設計）の細部は、公開情報だけでは確認しきれない部分がある。本番導入の前に、各サービスの最新の管理者向けドキュメントで確認してほしい。

この表で効くのは、各行の向きだ。コストや事故につながる操作（外部送信・削除）は「迷ったら止める」側へ、社内の知識整理は「迷ったら欠落させる」側へ倒す。取り返せる失敗と、取り返せない失敗を分けて、層ごとに安全側の向きを決める。チャンネルの情報が散らかっていれば、agentの出力も散らかる。整った作業場が前提になる、という当たり前も、ここで効いてくる。

06​私たちなら、​どう​設計するか

もし「自社のチャットにAIを常駐させたい」と相談されたら、最初に話すのは賢いモデルの選び方ではない。どのチャンネルに、どんな権限で、何を記憶し、どこへ成果物を残すAIにするかから決める。これは、私たちが社内の知識基盤（kai_wiki）でやってきたことと地続きだ。AIは会話をそのまま覚えるのではなく、決定事項・作業ログ・次の一手を、種類ごとに分けて構造化された場所へ戻す。記憶先はチャットではなく、後から引き継げる形にしておく。

そのうえで、外部送信や金額が動く操作、契約に関わる判断には、人間の承認（HITL）を必ず挟む。これはCAGが受注・クライアント対応で掲げる運用原則そのものでもある。AIが一次対応で速く動き、取り返しのつかない判断だけを人間が引き取る。勝つのは「AI teammateを導入した会社」ではなく、「AI teammateに安全な席と仕事の境界を与えられた会社」だ。Claude Tagは、その設計力がこれから問われることを、はっきり示した。

AIの使い方	チャットAIを「開いて使う」	AIを「作業場に常駐させる」
文脈の運搬	人間が毎回コピーして運ぶ	AIが流れている場所にいる
勝負どころ	promptの上手さ	席・記憶・権限・監査・担当の設計
記憶	セッションで消える	構造化して引き継ぐ
責任	使った人が都度確認	承認・監査を設計に組み込む
成果物	画面の中で完結	決まった置き場へ残る

※ 上表はAIの運用形態の対比であり、特定製品の優劣比較ではない。

関連記事 ｜ 作業場設計の前提AIエージェント時代、強いリポジトリは「AGENTS.md」を持っている → 関連記事 ｜ チャット常駐AIの実装LINE WORKSに流れて消える知識を、AIで取り戻す →