AIエージェントを「チームメンバー」として迎える時代——天工3.2「Skywork Tags」が示す次の一手
AnthropicがClaudeをSlackチャンネルに常駐させる「Claude Tag」を発表したのとほぼ同時期に、中国のAIサービス「天工（Skywork）」もまったく同じ方向へ踏み出した。その名も「Skywork Tags」。この動きは偶然の一致ではなく、AIエージェントの次の主戦場がどこにあるかを示す、かなり明確なシグナルだと私は受け止めている。
出典: 天工 3.2 重磅升级：Skywork Tags 上线，给 Agent 一张工牌，邀其加入你的工作群聊
要点 (事実のみ)
- 天工3.2のアップデートとして「Skywork Tags」が正式リリース。Slack・飛書（Lark）・钉钉・Discord・Telegramへのボット参加をサポート。
- Karpathyは「LLMとのインタラクションの第三の範式転換——AIが組織内の持続的エンティティになる」という見解を示したと記事は引用している。
- Skywork Tagsはチャンネル共有型。1チャンネルに1エージェントが常駐し、全メンバーが同一エージェントを使う設計。
- 天工開発チームが社内実験として、個人専用ボットとチーム共有ボット（100人規模の群組）を数ヶ月間比較。最初は個人専用が優位だったが、2〜3週間後には共有版が逆転したと報告。
- 「コンテキストを新しいワークスペースへ移す」ではなく「エージェントを既存の職場環境へ連れていく」という設計思想を明示。
徐 聖博の見解
この機能の本質は、インタフェースの話ではなくコンテキスト設計の話だ。
多くのエージェント製品が「チャット履歴やドキュメントをインポートしてください」と求めるのは、エージェントにとって都合のよいコンテキスト形式に変換する必要があるからだ。しかし現実の業務コンテキストは、Slackのスレッド、スプレッドシートのコメント、承認フローの添付ファイル——と至る所に散らばっている。「搬運コスト（移送コスト）」が高すぎて、現場はいつまでも試験運用を抜け出せない。
Skywork Tagsが採ったアプローチ——エージェントを既存のコミュニケーションツールにインサートする——は、この摩擦を根本から削ぐ。私がXincereでエージェントの業務実装を支援してきた経験から言っても、導入の障壁になるのは技術よりも「ツールを変える心理的コスト」であることが圧倒的に多い。Slack/Teamsにボットを招待するだけでよいなら、その壁はほぼ消える。
もう一つ注目しているのは「共有型」という設計だ。個人の私的コンテキストではなく、チャンネル上の会話を蓄積することで、エージェントが「組織の暗黙知」を拾い始める。記事中の実験結果——個人専用版が共有版に2〜3週間で逆転された——は、直感に反するが理屈は明快だ。エージェントの精度は学習データの多様性と量に依存する。100人の多様な問いかけは、1人の精緻なプロンプト調整を情報量で上回る。
一方で実装者目線で引っかかる点もある。共有チャンネルにエージェントが「ずっといる」ということは、権限管理とデータスコープの設計が非常に難しくなる。Slackの全メッセージを読めるエージェントをどう制御するか、秘密情報の扱いをどう定義するか——この部分の設計が甘ければ、組織にとってリスクに変わる。エージェントを「同僚」と呼ぶ前に、情報アクセス境界の設計を先に固めるべきだ。
AnthropicのClaude TagとSkywork Tagsが同時期に登場したことは、業界の収束を意味する。次の問いは「チャットツールにエージェントを入れるかどうか」ではなく、「どう入れるか・何を読ませ何を読ませないか」のアーキテクチャ設計に移っている。
(編集レンズ: 実装・運用視点 / 発注側・中小企業への含意 / AIを「作る側」の目線)
