この記事はすきま経営からの転載です。

AIエージェントを業務に組み込む相談を受けるとき、最初のつまずきは「モデルの性能」ではなく「現場の入口をどこにするか」であることが多い。チャット画面を新しく作っても、現場の人はそこを開きにいかない。すでに使っているSlackやLINEの中にAIエージェントを差し込む方が、圧倒的に使われる。

ただし、この「差し込む」がやっかいだ。SlackとLINEは思想もAPIの制約もまったく違うツールで、同じ設計をそのまま持ち込むと片方で必ず破綻する。ここでは、私がクライアントワークで複数案件を通じて固めてきた、チャットツール経由でAIエージェントを組み込む際の設計の考え方を書く。

なぜ専用UIではなくチャットツールに組み込むのか

AI導入の初期フェーズで専用のWebアプリを作る案は、たいてい筋が悪い。理由は単純で、現場の人が新しいツールを覚えるコストと、それを毎日開きにいく習慣化コストの両方が発生するからだ。

一方、SlackやLINEはすでに現場の人が1日に何十回も開いている場所だ。そこにAIエージェントを差し込めば、「新しいツールを使う」のではなく「いつものやり取りの延長でAIが応答するようになった」という体験になる。導入初期に必要なのは高機能なUIではなく、この心理的なハードルの低さだ。専用UIは、チャットツール経由での運用が定着し、要求が明確になった後で検討すれば十分間に合う。

SlackとLINEでは「会話の単位」の設計が違う

複数の現場でSlack連携とLINE連携の両方を実装してきて一番痛感したのは、両者で「会話の単位」の扱いがまったく違うことだ。

Slackはスレッドという概念がある。1つの話題を1つのスレッドに閉じ込められるので、AIエージェント側もスレッドIDを会話コンテキストの単位として扱いやすい。チャンネル全体のノイズを拾わず、スレッド単位でコンテキストを区切れば、複数の話題が同時進行していても混線しない。

LINEにはスレッドがない。1つのトーク（個人・グループ）の中に、話題がすべて時系列で並ぶ。ここで「Slackと同じ発想でコンテキストを区切ろう」とすると詰まる。私が実務で採用しているのは、明示的なコマンド（「新しい相談」のような区切りワード）か、一定時間の無応答でコンテキストをリセットする、いずれかの仕組みを別途用意することだ。プラットフォームが会話の単位を用意してくれないなら、アプリケーション側でその単位を作るしかない。

権限とレスポンスタイムはツールの外で設計する

チャットツール経由の設計で見落とされがちなのが、権限管理とレスポンスタイムの制約だ。

権限について。SlackもLINEも「誰が話しかけてきたか」の情報は取れるが、「その人が何を聞いていいか」を判定するロジックはツール側にはない。チャンネルやグループ単位でAIエージェントが扱える情報の範囲を切り分け、社外秘の情報を扱うチャンネルとそうでないチャンネルでは、接続するバックエンドやコンテキストのソースを完全に分離する。これを後から直そうとすると、権限漏れを疑って過去ログを全部洗い直す羽目になる。最初の設計段階で切っておくべき境界線だ。

レスポンスタイムについて。Slack・LINEのどちらもWebhookには応答タイムアウトの制約がある。AIエージェントの処理（特にツール呼び出しを挟むエージェント型のフロー)が数秒で終わらない場合、Webhookの即時応答枠では収まらない。私が組む構成は、Webhookを受けたら即座に「受け付けました」的な仮応答を返すか受信確認のリアクションだけ返し、実際の処理は非同期のジョブキューに積んで、完了後に同じチャンネル・トークにメッセージを送り返す形にしている。同期的にAIの処理完了を待つ設計は、複雑なタスクを扱わせ始めた瞬間にタイムアウトで壊れる。

「AIが誤答したときの現場の被害」を運用で吸収する

チャットツールに組み込むと、AIエージェントの出力がそのまま人間同士の会話と同じ見た目で現場に流れる。これが便利さの正体であると同時に、リスクの正体でもある。

人間の担当者への質問なら「これは自信ないので確認します」という言い方が自然に混ざるが、AIエージェントは自信のない回答も断定的な文体で返しがちだ。現場のメンバーがそれを人間の回答と同じ重みで受け取ってしまうと、誤答がそのまま業務判断に混ざり込む。

私が必ず入れているのは、AIエージェントの発言だとひと目でわかる見た目の区別（Slackならbotアイコンと名前、LINEならリッチメニューや応答テンプレートの文言）と、回答の末尾に「間違っている可能性がある領域」を明示する一文だ。これは技術的な対策というより運用上の防御線だが、以前書いたLLMアプリの評価設計と同じで、誤答が起きること自体は前提にした上で、被害を最小化する設計を組んでおく方が現実的だ。

現場からのフィードバックをどう回収するか

もう1つ、実装してすぐ困るのが「AIエージェントの回答が現場でどう評価されているか」を知る手段がないことだ。専用UIならログを見れば済むが、チャットツール経由だと、良かった・悪かったの反応が絵文字リアクションや返信の中に埋もれてしまう。

私が実務で組み込んでいるのは、AIエージェントの回答に対する簡易フィードバック（Slackならリアクション絵文字、LINEならクイックリプライのボタン）を最初から仕込んでおくことだ。これがないと、AIエージェントの精度が実際に業務で足りているのかどうかを、感覚でしか判断できなくなる。回収したフィードバックは、前述の評価データセットの改善サンプルとしてもそのまま使える。

まとめ

専用UIより、現場がすでに使っているSlack・LINEにAIエージェントを差し込む方が習慣化コストが低く、導入初期は特にこちらが筋がいい
Slackはスレッド単位でコンテキストを区切れるが、LINEにはその概念がないため、区切りワードやタイムアウトなど自前の会話単位設計が必要
権限管理はチャンネル・グループ単位でバックエンドごと分離し、レスポンスタイムはWebhookの制約に合わせて非同期ジョブ化する
AIの発言だとわかる見た目の区別と誤答時の被害を吸収する運用、フィードバック回収の仕組みを最初から組み込んでおく

次回は、AIエージェントの導入効果を「使われているか」「業務が実際に速くなっているか」の観点でどう測るか、について書く予定だ。