チャット連携

チャット連携を使うと、Multica を開かなくても、エージェントへの質問、グループチャットでの @メンション、チャット画面からのタスク作成ができます。

現在は Feishu/Lark、Slack、DingTalk、WeCom、Telegram に対応しています。セッション、ユーザー識別、実行の仕組みは共通ですが、インストール方法が異なります。

プラットフォームを選ぶ

新規接続は現在、中国本土版の Feishu でのみ利用できます。既存の国際版 Lark 接続は、引き続き利用および管理できます。

各 Bot は 1 つの Multica エージェントに紐づきます。同じチャットプラットフォームで複数のエージェントを使う場合は、エージェントごとに Bot を接続してください。

DingTalk、WeCom、Telegram はコミュニティメンテナンスです。各リリースに含まれますが、公式サポート SLA はありません。問題は GitHub issues で報告してください。

WeCom が現在扱えるのはテキストメッセージのみです。音声、画像、ファイルのメッセージにはその旨の短い返信が返り、エージェントには渡されません。

Telegram が現在扱えるのはテキストメッセージのみです。未対応のメディアにはその旨の短い返信が返り、エージェントには渡されません。

詳しい手順:

• Feishu / Lark Bot 連携
• Slack Bot 連携
• DingTalk Bot 連携
• Telegram Bot 連携

メッセージが処理される流れ

1. Multica が Bot に対応するワークスペースとエージェントを特定します。
2. グループやチャンネルでは、Bot を明示的に @メンションしたメッセージだけを処理します。DM では @メンションは不要です。
3. Multica が送信者のアカウント連携とワークスペースのメンバー資格を確認します。
4. メッセージがエージェントとのチャットセッションに追加され、作業が作成されます。
5. エージェントの返信が元の DM またはスレッドに返されます。

Bot を @メンションしていないチャンネルメッセージは、エージェントをトリガーせず、会話コンテキストにも追加されません。

通常のメッセージはこの流れで処理されます。/issue はコマンドであり、チャットのターンではありません。Multica は元のプラットフォームに結果を返しますが、コマンド自体は Multica Chat に追加しません。Slack のネイティブスラッシュコマンドは、独立した非同期の作業作成フローで処理されます。

会話コンテキストを操作する

/new は新しい Multica Chat を作成し、その外部会話からの後続メッセージを新しい Chat へルーティングします。/new <メッセージ> では、そのメッセージが最初のターンになります。以前の Chat は Multica に保存され、引き続き利用できます。

/clear は現在の Multica Chat を維持したまま、エージェントから見えるコンテキストだけを新しくします。Chat の全履歴は Multica に残りますが、エージェントは境界より前のメッセージを取得できません。/clear <メッセージ> では、そのメッセージが新しいコンテキストの最初のターンになります。引数なしの /clear は次の実メッセージに適用されます。

Slack の DM では、/new と /clear はネイティブスラッシュコマンドです。ネイティブ slash command payload ではチャンネル内の対象スレッドを特定できないため、対象スレッドで @Multica /new [メッセージ] または @Multica /clear [メッセージ] を送信してください。

セッションの分離

• Feishu/Lark はチャットごとにセッションを分けます。同じチャットの後続メッセージは同じセッションを継続します。
• Slack は DM をチャンネルごとに分けます。チャンネル内では、スレッドごとに独立したセッションが保持されます。
• DingTalk は conversation ごとにセッションを分けます。DM とグループはそれぞれのセッションを継続します。
• WeCom はチャットごとにセッションを分けます。DM とグループチャットはそれぞれのセッションを継続します。
• Telegram はチャットごとにセッションを分け、forum topic は topic ごとに分離します。

チャンネルで追加の依頼を送る場合も、Bot を再度 @メンションする必要があります。エージェントが受け取るのは自分宛てのメッセージだけで、チャンネルの履歴全体を自動的に読み取ることはありません。

アカウント連携

メンバーが初めて Bot にメッセージを送ると、アカウント連携用のリンクが届きます。Multica にログインすると、チャットプラットフォームのアカウントが現在のワークスペースのメンバー資格に紐づきます。

Multica がエージェントを実行するのは、アカウント連携が完了した後だけです。メッセージを受け取るたびにアカウント連携とワークスペースのメンバー資格を再確認するため、ワークスペースから退出した後は Bot 経由でアクセスできません。

接続を管理する

ワークスペースの owner と admin は Bot を接続または切断できます。Feishu/Lark Bot の場合は、エージェントの所有者も接続と切断ができます。通常のメンバーは接続済みの連携を確認し、自分に実行権限があるエージェントを利用できます。

切断すると、Bot は新しいメッセージを受信しなくなります。既存の Multica の会話と実行記録は保持されます。

セルフホスト

セルフホスト環境では、Multica が接続エンドポイントを有効にする前に、プラットフォームごとに 32 バイトの暗号化キーを設定する必要があります。

MULTICA_LARK_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_SLACK_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_DINGTALK_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_WECOM_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_TELEGRAM_SECRET_KEY=<base64-encoded 32-byte key>

これらのキーは、保存された Bot の認証情報を暗号化します。生成、保管、ローテーションの方法は環境変数を参照してください。Multica Cloud ではすでに設定済みです。

WeCom の送信経路は、1 つのプロセスが保持する WebSocket だけです。別のレプリカで生成された返信がどうなるかは、リアルタイムリレーのモードによって決まります。

• シャード / デュアルリレーモード（REDIS_URL を設定、Redis がある場合のデフォルト）：返信は接続を保持するレプリカへ転送されて配信されます。マルチレプリカ運用に対応しています。
• レガシーリレーモード、または Redis なし：返信は破棄されます。この構成では WeCom を有効にしたバックエンドを単一レプリカで運用してください。

どのモードでも、どのレプリカも接続を保持していない瞬間（全て再接続中）に生成された返信は配信されません。ただし計測はされます。転送したレプリカが後からその配信をどのレプリカかが引き受けたかを確認し、誰も引き受けていなければ multica_wecom_outbound_dropped_total{reason="no_live_connection"} を加算するため、この窓の大きさは実測できます。この損失が許容できない場合は、単一レプリカが最も保守的な構成です。

次のステップ

• Feishu / Lark Bot 連携
• Slack Bot 連携
• DingTalk Bot 連携
• Telegram Bot 連携
• エージェントとチャットする