本文へスキップ
Ankole

シグナルルーティングルール

AI Agent 向け: このページの Markdown 版は https://ankole.agentbull.com/ja-JP/docs/signal-bindings/index.md にあります。ドキュメント索引は https://ankole.agentbull.com/ja-JP/llms.txt にあります。

シグナルルーティングルールは、どの Agent がメッセージを受け取るかを決定します。現在は、1 つのルールが 1 つのチャットアプリを 1 つの Agent に直接接続します。Agent は複数のルールを使って複数のチャットアプリに接続できます。

「signal」という言葉には、チャット以外への余地が含まれます。将来のルールでは、ルーティング式を使って channel、会話、その他の条件で Agent を選択できます。また、Salesforce などの system からのイベントを配信することもできます。

Slack、Microsoft Teams、Lark、Feishu、DingTalk のアプリをまだ準備していない場合は、先に Quick start の channel provider の手順を完了してください。

ルーティングルールを作成する

  1. Console で Signal Routing を開き、New routing rule を選択します。
  2. メッセージを受け取る Agent と Channel Provider アダプターを選択します。
  3. support-slack のような分かりやすいルール名を入力します。
  4. グループメッセージモードを選択します。
  5. チャットアプリの credential と接続情報を入力し、ルールを保存します。
  6. そのチャットアプリで bot にメッセージを送信し、選択した Agent が返信することを確認します。

各 bot アカウントに、それぞれ独自のチャットアプリとルーティングルールを割り当ててください。複数の Agent が異なる bot アカウントを使う必要がある場合は、各 bot に別々のアプリを作成し、ルールを 1 つずつ作成します。

こうすることで Agent の identity とメッセージを分離し、credential を個別にローテーションできます。

グループメッセージモードを選択する

Console には、選択した Channel Provider がサポートするモードだけが表示されます。

モード Agent を宛てていないグループメッセージに何が起こるか
Addressed messages only Agent はメッセージを見ず、返信もしません。
Observe unaddressed messages メッセージは会話 context に入りますが、Agent は起動しません。誰かが Agent を宛てた後、Agent はそれを context として使えます。
May intervene Agent はまず、会話に参加することが役立つかを判断します。発言すると判断した場合にのみ返信します。

Slack、Microsoft Teams、Lark、Feishu は 3 つのモードすべてをサポートします。DingTalk と WeCom は、bot を明示的に宛てたグループメッセージしか受信できないため、Console はこれらに最初のモードしか提供しません。WeCom にはこれ以外にも多くの制限があります(recall 不可、グループ内ファイル不可、Agent が会話を開始不可)。そのため、最初の channel としては推奨しません。Quick start の WeCom タブを参照してください。

May intervene は、Agent があらゆるメッセージに返信することを意味しません。いつ発言するかを Agent に判断させ、新しいメッセージのバッチごとに一度だけ判断されます。あるグループでいつ発言すべきかを Agent に伝えるには、そのグループ内で channel 常駐指示を直接与えます(例: 「CI が赤になった時だけ発言して」)。それでも発言しすぎる場合は、まず常駐指示または役割指示を厳しくします。判断の挙動と常駐指示については アンビエント介入 を参照してください。

質疑応答のみが必要なグループでは、Addressed messages only を使用します。

不明な送信者の扱いを選択する

Ankole は送信者を既知のアカウントへ自動でマッピングします。ディレクトリ同期やログインで取り込んだアカウントはプラットフォーム ID で一致し、新しいアカウントでも、プラットフォームが報告するメールアドレスや携帯番号が既存アカウントと一致すれば同じ人物に統合されます。このマッピングはベストエフォートです。ディレクトリ外の外部ユーザーや、チャットアカウントを一度も紐付けていないローカルログインのユーザーは一致しません。

アカウントの自動マッピングに失敗した場合で、その送信者の扱いを選びます:

オプション 動作
手動レビュー(既定) 送信者はコンソールのアイデンティティ → 保留中のマッピングに表示されます。管理者が紐付けを終えるまで、Agent 宛のメッセージには「管理者に連絡してアカウントを紐付けてください」という固定の返信だけが返り、それ以外の処理は一切行われません。メッセージはコンテキストにも Brain の学習にも入りません。
独立アカウントを自動作成 Ankole が送信者用の独立アカウントを作成し、すぐに応答します。誰でも Agent と話せるオープンなチャンネル向けです。送信者のプラットフォーム ID がすでに既存アカウントの識別子である場合、たとえばメールアドレスを識別子とするローカルログインアカウントの場合、Ankole は何も作成せず送信者を手動レビューに保留します。同一人物かどうかを判断できるのは管理者だけだからです。

未マッピングの送信者によるグループ内の(Agent 宛でない)雑談は常に無視されます。

Telegram、Discord、LINE では、すべての送信者が最初は不明です。これらのコンシューマー向け IM には企業ディレクトリがなく、プラットフォームはメールアドレスも携帯番号も報告しません。手動レビュー のままにして、各人を一度だけアカウントにマッピングしてください。WhatsApp は送信者の検証済みの電話番号を報告するため、アカウントがすでにその携帯番号を所有している人は即時にマッピングされます。メールの送信者は、プロフィールのメールアドレスやローカルサインインのメールアドレスでは照合されません。From アドレスは何も証明しないためです。明示的なメールの identity 紐付けだけが送信者を受け入れます。この紐付けは、社員についてはディレクトリ同期が作成し、それ以外の人についてはこのページで作成します。Lark と Feishu では、同じページで外部グループもこの仕組みの対象です。外部テナントのメンバーには従業員 ID がないため、手動での紐付けか自動作成が必要です。同じコンソールページで、本人がメッセージを送る前にマッピングを登録することもできます。

チャットの内容が Brain の知識になる仕組み

ルーティングルールはメッセージの配送先を制御します。知識のアクセス範囲を選ぶ設定ではありません。Brain がチャットから学習するときは、会話の種類と既知の identity からアクセス範囲を決めます。

  • グループチャット: channel の現在の member group に属するメンバーと Agent が、学習した知識を使えます。member group がないグループからは学習しません。
  • ダイレクトメッセージ: 相手のユーザーと、ルールにバインドされた Agent が、学習した知識を使えます。他の Agent はデフォルトでは使えません。

公開情報はインスタンス共通の知識になることがあります。明示的に機密扱いを求める内容は、該当する発言者だけに制限できます。それ以外の内容は、上記のグループチャットまたはダイレクトメッセージのアクセス範囲を保ちます。モデル要件と検索動作については Brain を参照してください。

ルールを編集、無効化、または有効化する

リストには有効なルールだけがデフォルトで表示されます。以前のルールを確認または復元する場合は、無効なルールを表示 を有効にします。

編集 を選択すると、現在の機密情報以外の設定を確認できます。対象 Agent、グループメッセージモード、チャット credential を変更できます。別の Agent を選択すると、新しいメッセージはその Agent に送られます。

server は保存済みの token や secret をブラウザーに返しません。credential フィールドを空のままにすると、暗号化された既存の値を維持します。値を置き換える場合だけ新しい値を入力します。

無効化 を選択すると、ルール、チャットアプリとの関連付け、履歴を維持したまま、新しいメッセージの配信を停止します。復元するには、無効なルールを表示 で対象のルールを見つけ、有効化 を選択します。ルールを再作成する必要はありません。

Agent が返信しない場合

  • Channel Provider がない場合: Agent Library → Control Plane Plugins を開き、その plugin を有効にして、ページが指示したら control plane を再起動します。
  • bot がグループメッセージを受信しない場合: provider のイベント購読、権限、アプリのリリース状態を確認します。DingTalk と WeCom のグループメッセージは、bot への明示的な @ メンションが必要です。
  • WeCom が予期しない動作をする場合: 最初に Quick start の WeCom タブと動作を比較してください。よくある原因は、スーパー管理者が作成していない bot、信頼済み IP の未設定、ユーザーがまだアクティブ化していない会話です。
  • ルールは保存されたが返信がない場合: 対象 Agent が有効であること、model 設定が動作すること、ルールがルール一覧に存在することを確認します。
  • ダイレクトメッセージは動くがグループメッセージは動かない場合: グループメッセージモードを確認し、bot が対象グループに属していることを確認します。

provider 固有の権限、イベント、credential は Quick start を使用します。

DingTalk ルールでストリーミングカードの返信を使うには、DingTalk カードプラットフォームに AI カードテンプレートが 1 つ必要です。Quick start の DingTalk タブの詳細セクションで、その構築方法を示しています。