Slack と Teams からエージェントに仕事を任せる

午前中の #payments のスレッド。誰かが @Archyl に webhook sender を呼び出しているのは何かと尋ね、ボットが答えます。Checkout と Billing の container で、どちらも Payments API を経由している、と。その 2 メッセージ後に、この手のスレッドが必ず行き着く一言が来ます。「そこにリトライを入れたほうがいいね、誰か拾ってくれる？」

そしてスレッドは静かになります。誰かが Archyl を開き、プロジェクトを探し、エージェントプロファイルを選び、3 メッセージ上に一字一句そのまま書いてあるタスクを打ち直さなければなりません。

6 月から、Archyl ボットは Slack と Microsoft Teams で質問に答えてきました。今日からは行動もできます。同じスレッドから、マネージドエージェントに仕事を渡せます。

@Archyl run [Payments API] add retries with backoff to the webhook sender

エージェントはこれを入力した人として実行され、ボットは pull request ができるまでスレッドで実行を追いかけます。

1 つのスレッドで、最初から最後まで

先ほどのやり取りの続きです。Archyl のメッセージは、ボットが実際に投稿する形式です。名前、質問、pull request は例です。

Marie:   @Archyl run [Payments API] add retries with backoff to the webhook sender

Archyl:  🚀 Agent `backend-fixer` started on Payments API. Follow it in Archyl
         — I'll post here when it needs you or when it's done.

「Follow it in Archyl」は実行ページへのリンクです。実行ページでは計画がチェックリストとして埋まっていき、ツール呼び出しはすべてアクティビティフィードに表示されます。誰もそのページを開いておく必要はありません。

20 分後、エージェントは自分だけで決めるべきではない判断に行き当たります。

Archyl:  @Marie ❓ The agent has a question:
         > Should retries also cover 4xx responses from receivers, or only
         > 5xx and timeouts?
         Answer in Archyl.

Marie はリンクを開き、提案された回答から「only 5xx and timeouts」を選んで、自分の作業に戻ります。実行が終わると、こうなります。

Archyl:  @Marie ✅ The agent finished and opened a pull request:
         https://github.com/acme/payments-api/pull/412
         See the run.

プロファイルで 先に計画をレビューする がオンになっていれば、コードが変更される前にもう 1 回立ち止まります。「📋 The agent proposed a plan and is waiting for your review」というメッセージが、リンク付きで届きます。実行が失敗したり、時間やコストの上限に達したりした場合は、最後のメッセージがその理由を伝え、それまでの作業を保持したドラフトの pull request へのリンクを示します。

Slack では、これらの更新のたびに実行を開始した人が @メンションされるので、その人の通知に届きます。Teams では、更新は同じスレッドへの返信として届き、メンションは付きません。

メッセージの合間に起きていたこと

スレッドに見えるのは 3 つのメッセージです。実行はそれよりずっと多くのことをしていて、このリリースの要点はそこにあります。

ファイルに触れる前に、実行はタスクが関わるアーキテクチャ要素、ここでは Payments API 内の webhook sender component に対して作業セッションを開きました。そこにリースを取ったので、後から同じ component で Claude Code を起動した開発者には、すでに誰かが作業中だと伝わります。ブリーフィングには、それらの要素に紐づく ADR、適合性ルール、API コントラクトに加えて、以前のセッションがその要素について覚えていたことが含まれていました。書き込んだファイルはすべて Guard を通り、Guard は critical な適合性ルールに違反する書き込みを拒否します。作業を終えると、要約は変更したファイルが実際に属する要素のメモリになり、記録した決定事項はそれぞれ Architecture Change Request（アーキテクチャ変更リクエスト）のドラフトを作成し、誰かがレビューできるようにしました。

どれもチャット特有のものではありません。Archyl の実行はすべてこうしています。変わったのは、依頼がどこから来るかです。

それがこの機能の背後にある賭けです。エージェントを動かすホスト型の場所は、リストから選ぶものになりつつあります。2 週間前に書いたとおり、今では Anthropic、OpenAI、Cursor がそれぞれ 1 つずつ提供しています。ランタイムが知らないのは、あなたのシステムです。webhook sender がどの container に属するのか、誰が担当しているのか、外向きの HTTP は共有クライアントを通すと定めているのはどのルールか、そして今そこで作業している別のエージェントは誰か。その知識はアーキテクチャモデルの中にあります。そして仕事が頼まれる場所はチャットです。このリリースはその 2 つをつなぎ、スレッドでの依頼が、エージェントがうまくこなすために必要なコンテキストを伴って届くようにします。

実行があなたとして作成される理由

ボットが質問に答えるときは、ワークスペースを接続した管理者の権限を使います。読むだけならそれで問題ありません。チャンネルにいる全員が同じアーキテクチャのビューを得ますし、チャンネルごとに絞り込んでいればその範囲に限られます。

行動するとなると話は別です。実行はコードを書き、pull request を開きます。もし @Archyl run がボットをインストールした人の権限を借りるなら、Slack チャンネルにいる誰もが、自分では編集できないプロジェクトをエージェントに変更させられることになり、実行履歴にはそのすべてに管理者の名前が残ります。

そのため、実行はコマンドを入力した人として作成され、その人のプロジェクトに対する編集権限の範囲に収まります。チャットのユーザーが Archyl の誰なのか、本人が伝えるまでボットにはわかりません。つまり、1 人につき 1 回だけの手順が必要です。

Archyl で プロフィール → チャットアカウント を開き、Slack アカウントを連携 または Microsoft Teams アカウントを連携 をクリックします。
表示されたコマンド @Archyl connect <code> を、そのプラットフォームでボットがいる場所ならどこからでも送信します。

コードは 1 回限りで 15 分間有効です。そして、サインインした状態のあなた自身が発行したものなので、それがチャットアカウントがあなたのものである証明になります。Slack と Teams は別々に連携します。@Archyl disconnect で連携を解除できます。解除してもボットは質問には答え続けますが、あなたとしてエージェントを起動することはなくなります。

この手順を飛ばしてそのまま run と入力すると、ボットは推測せずに、何が足りないかを伝えます。

I don't know who you are on Archyl yet, and agents run as the person who asks.
Generate a code in Profile → Chat accounts, then send @Archyl connect <code>.

コマンドの読み取り方

@Archyl run [Project name] <task> に、省略可能な要素が 2 つあります。

プロジェクトは角括弧で囲みます。 今のところ角括弧は必須です。そうすれば、プロジェクト名がどこで終わり、タスクがどこから始まるかをボットが推測する必要がありません。1 つのプロジェクトに絞り込まれたチャンネルでは、プロジェクトを省略できます。@Archyl run fix the flaky login test のように書きます。複数のプロジェクトに絞り込まれたチャンネルは、その範囲内のプロジェクトしか受け付けません。それ以外を指定すると、ボットはこのチャンネルの範囲ではそのプロジェクトが見つからないと答えます。

プロファイルはタスクの前に置きます。 指定がなければ、実行は組織のデフォルトプロファイルを使います。別のものを選ぶには、profile:<name> を先頭に置きます。

@Archyl run [Web] profile:frontend-fixer align the pricing cards

存在しないプロファイル名を指定すると、存在するプロファイルの一覧が返ってきます。

それ以外は、すべてアプリと同じように動きます。プロジェクトの編集権限が必要です。実行は、エージェントハブ → 実行一覧 から開始した実行と同じく、組織の月間エージェント実行数にカウントされます（アプリと同様、独自の AI プロバイダーを使っている組織はカウントされません）。プロファイルで 他のエージェントの作業を尊重する がオンになっていて、別のエージェントが同じ要素のリースを保持している場合、ボットはプリフライトゲートが実行を拒否したと返信します。ゲートが警告だけを出した場合は、実行は承認待ちで保留され、ボットがそこへのリンクを示します。

気を配った 2 つの小さなこと

信頼できないテキストで部屋中に通知を飛ばすことはできません。 タスク、プロジェクト名、エージェントの質問は、どれも引用としてチャンネルに戻ってきます。それぞれ投稿前にプラットフォームに合わせてエスケープされるので、Slack の <!channel> や Teams の <at> メンションを含むタスクや質問は、全員に通知されることなくプレーンテキストとして届きます。

実行の報告先スレッドは、クライアントから変更できません。 実行がどのチャンネルとスレッドに投稿するかは、実行の作成時にサーバー側に保存されます。API クライアントが書き込める実行のメタデータには保存しません。また、更新が届くのは、その実行を所有する組織に接続されたワークスペースだけです。

まだできないこと

計画のレビューと回答は、スレッドではなく Archyl で行います。 ボットはエージェントが待っていることを伝え、実行ページへリンクします。Slack や Teams から計画を承認したり、質問に答えたりはできません。これは見た目以上に重要です。1 時間以内に誰も答えなかった質問については、エージェントが自分の判断で先に進みます。1 時間以内に誰もレビューしなかった計画は、実行を失敗させます。@メンションは、その 1 時間が気づかれないまま過ぎないためにあります。

プロジェクト名は、ちょうど 1 つのプロジェクトに一致する必要があります。 あいまい一致はありません。2 つのプロジェクトが同じ名前の場合、ボットはどちらかの名前を変えるか、アプリから開始するよう求めます。

Teams の更新ではメンションされません。 更新はスレッド内の返信なので、どれだけ目に入るかは、そのスレッドをどうフォローしているかによります。

pull request には対応しているホストが必要です。 実行は github.com、gitlab.com、bitbucket.org で pull request を開きます。Bitbucket にはドラフトの pull request がないため、そこで失敗した実行は pull request を開かずにブランチを push します。セルフホストの Git サーバー上のリポジトリには pull request が作られないので、最後のメッセージはエージェントが完了したことを伝え、実行へリンクします。

試してみる

チャットから実行を開始するには、Scale プランと Custom プランで使えるマネージドエージェントと、接続済みの Slack または Teams のワークスペースが必要です。プロフィール → チャットアカウント でチャットアカウントを連携したら、誰かが小さくて明確な依頼をしたばかりのスレッドを選んで、@Archyl run と入力してください。

権限とチャンネルの範囲がどう適用されるかを含む完全なリファレンスは、Slack と Teams のボットのドキュメントの「Slack や Teams からエージェントの実行を開始する」セクションにあります。