仕事はチャンネルで話され、実際の作業は別の場所で行われます。Zero はその隙間を埋めます。スレッドでメンションし、触れてよい範囲を承認すれば、答えのあるシステムまで届きます。ウェブで使っているのと同じエージェントとして。
仕事がすでに話されている場所で Zero をメンションすれば、そのスレッドを読みます。スクリーンショットも、やり取りも、決まったことも。返信はスレッドに入るのでチャンネルは散らからず、依頼も回答も誰かの訂正もチームから見え続けます。
@Zero先週からのカレンダー、メール、Linear のタスクを見て、チームに共有できる業務サマリーを書いて
3月16日〜24日の週の業務サマリーです。
チャンネルで報告されたバグが GitHub の Issue になり、そこからプルリクエストになります。そのどちらも同じスレッドに戻ってきます。Zero は承認されていないサービスに触れる前に必ず確認し、範囲は 1 つの権限と 1 つの期間に限られます。
Issue を作成しました: #11708 — bug: PWA menu overlaps status bar
@ZeroPR を出して直して、そのあとプレビューリンクを見せてくれる?
PR を提出しました: github.com/vm0-ai/vm0/pull/11709
仕事が持ち上がるのは Slack ですが、長い実行ログを読むのにチャンネルは向きません。Slack で始まったスレッドはウェブ上のスレッドでもあります。どこから来たかが記録され、元のメッセージまで 1 クリック。完全なログも、ファイルも、実行したすべての呼び出しもそこにあります。
さっき送ったスレッドで triage-bug-report を実行して。
#bug-report と同じワークフローです。やったことは次のとおりです。
仕事に関わる全員が自社の従業員とは限りません。クライアントや取引先と共有しているチャンネルに Zero を招待すれば、そのスレッドも同じように読みます。チケットの状況を引き出し、自社の誰かが送るための返信を下書きします。ゲストが受け取るのは答えであって、あなたのアクセス権ではありません。
移行はどこまで進みましたか?明日、こちらのチームに説明します。
@Zero移行チケットを確認して、送れる形の状況報告を下書きして
5 ステップ中 3 つ完了、4 つ目はレビュー中です。下書きは DM に置きました。 下書きを見る
チームのふだんのコミュニケーションは何も変わりません。サービスをつなぐのは、キーの受け渡しではなく承認です。
Zero を Slack に追加し、いてほしいチャンネルに招待します。招待されたチャンネルしか見えません。
チームに見せたい仕事はチャンネルで @Zero、下書きや内密な話は DM で。返信はスレッドに入るので、チャンネルは読みやすいままです。
承認されていないサービスが必要になると、Zero が承認依頼を送ります。コネクタ 1 つ、権限 1 つ、期間はあなたが選びます。
「@Zero triage-bug-report」で、保存済みのワークフローを今のスレッドに対して実行できます。予定実行のものは結果を自分で返してきます。
Zero は会話を仕切るためにいるのではありません。招待されたチャンネルに居て、すでに話されていることを追い、チームの仕事が決まって滞る数少ない場面で動きます。追いつく作業、報告されたきり登録されないもの、誰も書き残さなかった決定です。
チームの半分が眠っているあいだに 100 件のメッセージ。スレッドで尋ねれば、5 つの要点と、まだ決まっていない論点が返ります。
誰かがチャンネルにスクリーンショットを投げて、そのまま次へ行く。Zero は文脈が消える前に再現手順を抜き出し、Issue を作り、リンク付きで返信します。
スレッドで落ち着いた結論を、他の人が読むドキュメントやトラッカーに、理由と担当者を添えて記録します。
プロジェクトの途中でチャンネルに加わった人が、何があったのかを尋ねて経緯を受け取れます。誰かが手を止めて語り直す必要はありません。
顧客への返信、数字の確認、そして固まりきっていないものは DM へ。同じエージェント、同じワークフローで、あなたが決めるまで読み手はひとりです。
保存済みのワークフローはどれもスレッドから名前で呼べます。それはウェブアプリが動かすのと同じワークフローなので、誰かがうまくやれた版がチャンネル全体の役に立ち、Slack 限定のものは何もありません。
広いカタログが役に立つのは、接続がひと手間で済むときだけ。そして安全なのは、ワークフローをチームに出しても自分のアカウントまで出さずに済むときだけです。どちらも同じやり方で解いています。
承認されていないサービスが必要になると、Zero は黙って失敗せず、同じ Slack スレッドに依頼を投稿します。権限と有効期間を選んで承認すれば、ジョブは止まったところから続きます。管理画面も、管理者への依頼も要りません。
ワークフローをチームに公開しても、共有されるのは手順であって、あなたの Gmail や CRM ではありません。チャンネルからそれを呼び出した人は、自分の接続済みサービスと自分に与えられた権限で実行します。だから届く範囲は実行する人の範囲までで、それ以上には広がりません。
OAuth を承認してつなぐ場合も、キーを貼り付けてつなぐ場合も、認証情報はエージェントが動く環境の外に保管され、ネットワーク境界で付与されます。スレッドにも、ワークフローにも、エージェントが出力できるどこにもありません。
いいえ。Slack の AI アシスタントが見えるのは、招待されたチャンネルと、自分がメンションされたメッセージだけです。チャンネルから外せば、その履歴へのアクセスは即座に失われます。
誰に見えるかです。チャンネルでは依頼も回答も誰かの訂正もチームから見えます。DM はウェブのチャットと同じように動き、下書きや機微な内容に向いています。
はい。チャンネル、DM、ウェブは同じワークフロー、コネクタ、権限を持つ同じエージェントで動きます。保存済みのワークフローをスレッドから名前で呼べば、ウェブとまったく同じように動きます。
ウェブアプリが使うのと同じコネクタ経由です。承認していないコネクタが必要になったとき、Zero は黙って失敗せず、1 つの権限と 1 つの期間に絞った承認依頼を送ります。
カスタムコネクタは API を持つほとんどのサービスに対応し、社内システムも含まれます。組み込みカタログにない道具でも行き止まりにはなりません。到達も承認も、ほかと同じ手順です。
招待すれば使えます。共有チャンネルもほかと同じように読みますが、そこにいるゲストはゲストのままです。チャンネルに投稿されたものは見えますが、コネクタもワークフローも誰かのアカウントも受け継ぎません。
はい、そこが要点です。Slack のワークフローをひと言で説明してトリガーを付ければ、自動の Slack メッセージが自分で投稿されます。キャンバスもステップエディタもありません。
@メンションとダイレクトメッセージは、どの Slack プランでも使えます。Slack アプリ内の AI エージェント画面には、Slack の有料プランが必要です。
Zero は ワークフローと自動化、生成サービス、チームでの共同作業 にも対応しています。組み込みのウェブサービス、切り替えられる モデル、そして 料金 もご覧ください。
仕事が話されている場所で尋ねて、答えをスレッドに返してもらいましょう。