【社内LLM Bot】新しく出たSlack Agent APIと従来のAPIを比較してみた

こんにちは！今週はDX Solution 事業本部 VPoE の丸尾が担当します。

先日、社内の取り組みでSlack上で応答できるLLMチャットBotのデモを作っていました。Slack上でLLMのチャットを実現すること自体は二番煎じ感が否めないですが、Slack Appには Agents & AI Apps という、LLMによるチャットを主用途とする機能が 2024/9 にリリースされ、せっかくなので調査をしました。

新しいAPIであることから、まだWebの記事も豊富ではなく、今回はその結果をまとめて、LLMを用いたSlack Botを作ることを検討している方に参考になったら幸いです。

従来のBot APIで実現する
Agent APIを利用する
まとめと比較
We're hiring!

従来のBot APIで実現する

従来のBot APIで、LLMによるユーザーとの対話を実現するには、ユーザーがBotにメンションを行い、そのスレッドでやり取りをするという方式が良いと考えました。

Slack Appはメンションを受けた時のイベント（app_mention）と、チャンネルのメッセージを受け取るイベント（message）を購読する必要があります。ここで注意すべき点として、messageイベントはBotが所属しているチャンネルの全てのメッセージを受け取ってしまいます。どのメッセージに返信するかを区別するため、最初にメンションを受けたメッセージがどれなのかを記憶しておく必要があります。そのためステートフルな実装になってしまうことが前提になり、運用の難易度が上がります。

@app.event("app_mention")
async def mention_handler(body, say, client, logger):
   # メンションを最初に受けた時の処理
    logger.info("user mention received")
    event = body["event"]
    thread_memory.add_thread(event["ts"]) # 返信すべきスレッドを記憶
...

@app.event("message")
async def handle_thread_message_events(event, say, client, logger):
   # 所属しているチャンネルの全てのメッセージを受けた時の処理
    if "thread_ts" in event and thread_memory.has_thread(event["thread_ts"]): # 返信すべきスレッドなのかを判定
        logger.info("user thread message received")

次に、Agent APIを利用する方法と比べてみます。

Agent APIを利用する

まず、Agent APIを利用するためには、下のスクリーンショットのように、Slack Appの開発画面で「Agents & AI Apps」の画面から、「Agent or Assistant」を有効化します。

すると、Slackのアプリ上で当該のアプリと1対1でチャットを始めることができます。

Agent APIはユーザーとの対話のインターフェースを提供するのみで、ユーザーのメッセージからLLMをどのように利用するかは開発者側に委ねられています。

開発時は公式のサンプルをベースに開発すると良いと思います。 github.com

@assistant.thread_started や @assistant.user_message でユーザーのスレッドの開始やメッセージの受け取りのイベントを処理することができます。

from slack_bolt import Assistant

assistant = Assistant()

@assistant.thread_started
def start_assistant_thread(
... スレッド開始の処理

@assistant.user_message
def respond_in_assistant_thread(
... スレッドでメッセージを受け取った時の処理

従来の方法で課題であった、「どのメッセージを返信すべきかの判定」が不要になり、ステートレスな実装を実現することが可能です。

Agent APIを利用した方法の欠点としては、DMの形式になってしまい、メンバーがLLM Botをどのように利用しているかがわかりにくい、そのため社内に浸透しにくいという点が挙げられます。

まとめと比較

以上をまとめると以下のような表にまとめられ、それぞれの手法のメリット・デメリットが浮き彫りになりました。

手法	実装面	利用状況の可視性
従来のAPI	ステートフルな実装が必要	メンバーの利用を可視化できる
Agent API	ステートレスな実装になる	メンバーの利用が見えない

今回、私が最終的に実装した方法は、従来のAPIを利用した手法をとりました。新しい取り組みはやはり可視化したほうが社内に浸透すると予想したからです。せっかく出たAgent APIを利用できなかったのは惜しいですが、DMの形式でなければならない用途が出てきたらそちらの実装も検討していきたいと考えています。