LangBot 4.11：イベント駆動エージェントとプラグイン化された Runner
LangBot 4.11 の主要機能を実機スクリーンショットで紹介。イベントルーティング、AgentRunner のプラグイン化、Workspace Assistant、運用機能と移行手順を解説します。
LangBot は、複数のメッセージングサービス、大規模言語モデル、ナレッジベース、プラグインを接続し、AI アシスタントの構築・デプロイ・管理を支援するオープンソースの AI チャットボット・エージェントプラットフォームです。
チャットボットの基本は「メッセージを受け取り、返信する」ことです。ただ、実際のチームやコミュニティでは、会話以外にも作業のきっかけがあります。新しいメンバーの参加、回答へのリアクション、カードのボタンクリック。こうした操作も、次の処理につなげたい場面があります。
LangBot 4.11 では、これらのイベントを設定可能な入り口として扱い、エージェントに渡し、実行状況を追跡できるようになりました。 AgentRunner のプラグイン化と Workspace Assistant により、「何をきっかけに、どの実行方式で処理し、どう管理するか」を整理しやすくなっています。
1. イベント駆動：次のメッセージを待つだけではない Bot へ
Event-Based Agents（EBA）は、通常のメッセージに加え、参加・退出、メッセージの撤回、リアクション、カード操作などのプラットフォームイベントを処理対象にします。今回のリリースでは、13 のプラットフォームアダプターが EBA アーキテクチャに基づいて書き直されました。
すべてのプラットフォームで同じイベントが使えるわけではありません。受信できるイベントは、プラットフォーム、アダプター、Bot に付与した権限によって異なります。共通化されたのは、受信したイベントを適切なプロセッサーへ渡す仕組みです。
4.11 正式版リリースノートに掲載されたイベントルーティングの例。
まずは実現したいシナリオから
イベントルーティングでは、新規メンバーへの歓迎や退出時の処理といった、よく使うシナリオからルールを作成し、担当するプロセッサーを選べます。
たとえば、通常の質問はナレッジベースを使う Pipeline、新規参加者への案内は Agent、固定の業務ルールが必要なイベントはプラグインプロセッサーへ、と分担できます。これは構成例であり、そのまま動く設定ではありません。利用するイベントと権限を確認し、各ルートをテストしてから有効にしてください。
プラットフォームとの接続と業務処理を分けられるため、歓迎の手順が変わっても Bot の接続部分まで作り直す必要がありません。質問への回答方針も、ほかの振る舞いと一つのプロンプトに詰め込まずに管理できます。
Pipeline・Agent・プラグインプロセッサーの使い分け
この記事用に起動した LangBot 4.11.0 のプロセッサー作成画面。
- Pipeline：メッセージイベントを決まった順序で処理します。AI による直接返信、ナレッジベースへの質問、既存のメッセージ処理に向いています。
- Agent：イベントへの対応を自然言語で指示し、AI に判断と実行を任せるか、外部の Agent プラットフォームへ接続します。状況に応じた判断が必要な処理に適しています。
- プラグインプロセッサー：プラグインが対応を宣言したイベントをコードで処理します。決定的なルールや専用の連携処理に向いています。
すべてを Agent に置き換える必要はありません。明確なルールはコードへ、定型的な質疑応答は Pipeline へ、判断が必要な部分は Agent へ。役割を分けるほうが、運用時にも理解しやすくなります。
デバッグもイベントを中心に
イベントデバッガーでは、フォームでイベントデータを編集し、実行ログと詳細を確認できます。実際のチャットサービスで試す前に、入力フィールドや処理結果を確認する用途に便利です。ただし、デバッグ実行だけで接続・権限・実際のコールバックまで確認できるわけではありません。
関連するプラットフォーム改善には、Slack Socket Mode、DingTalk のカード操作、WeChat の入力中表示、OneBot WebSocket などがあります。対応範囲と設定方法は各プラットフォームのドキュメントを参照してください。
2. AgentRunner のプラグイン化：実行方式を独立して更新
これまで Core に組み込まれていた LocalAgent、Dify、Coze、n8n などの Runner は、拡張マーケットの公式プラグインへ移行しました。Codex、Claude Code、ACP などの Runner も追加されています。
実機から読み込んだ拡張マーケットの Official Runner セクション。掲載内容は Core と独立して更新されます。
利用者にとっての主な変化は、必要な Runner を選んでインストールし、個別に更新できることです。LocalAgent でモデル・ツール・知識検索を使う構成も、既存の Dify アプリや n8n ワークフローをチャットにつなぐ構成も、共通の Bot 接続基盤で扱えます。
開発者は AgentRunner Protocol v1 に基づいて独自の Runner を実装できます。特定の実行基盤向けの処理を Core に直接組み込む必要がなくなり、拡張の境界が明確になります。
正式版リリースノートの Runner 一覧例。必要なアカウント、API、実行環境は Runner ごとに設定します。
プラグイン化は、すべての権限を無条件に渡すことではありません。Runner が呼び出せるのは、現在のコンテキストで許可されたツールとプラットフォーム API です。マーケットには認証バッジが表示され、Core は認証プラグインの署名を検証します。出所の確認と権限管理に加え、導入前に説明を読み、自分の環境での動作条件も確認してください。
既存の Pipeline はどう移行する？
移行機能は必要なプラグインをインストールし、元の設定をバックアップします。アップグレード後に Pipelines 画面で移行を実行し、Runner、モデル、ナレッジベース、ツールの設定を見直してください。
移行後の Pipeline は新しいセッションから開始します。 旧式のカスタム Runner はプラグイン Runner として書き直す必要があります。オフライン環境では「データのみ移行」を選び、Runner プラグインを手動でインストールできます。詳しい対応関係は設定移行マップ（中国語）を参照してください。
3. Workspace Assistant：確認してから反映する対話型の設定
新しい Workspace Assistant は、Bot と会話するエンドユーザーではなく、LangBot を管理する人のための機能です。現在の Workspace にあるリソースを調べ、対話を通じて Pipeline やナレッジベースなどの作成・設定を支援します。
新しいインスタンスでの初期画面。利用には LangBot Account へのログイン、またはモデル設定が必要です。監視データのゼロ表示は、この新規 Workspace の実際の空状態です。
まずは「使えるモデル、ナレッジベース、Pipeline は？」といった読み取り専用の質問から始められます。そのうえで、ナレッジベースを使う質問応答アプリの作成を依頼します。単にフォームをチャットに置き換えるのではなく、現在あるリソースを確認したうえで設定案を出せる点が重要です。
書き込み操作は、確認を受けてから実行されます。 対象リソース、パラメーター、変更範囲を見てから承認してください。設定項目を探す手間を減らしつつ、変更の判断は管理者に残す仕組みです。
4. 新しい実行方式を支える運用機能
メッセージ数だけでなく、実行の流れを見る
一つのイベントが Pipeline、Agent、プラグインのいずれかへ渡るようになると、問題の切り分けには処理全体の見通しが必要です。4.11 では統一実行ビュー、ツール呼び出しの追跡、処理中のタスクを示すリアルタイムパネルが追加・更新されました。
調査するときは、イベントを受信したか、どのプロセッサーへ渡ったか、モデルやツールの呼び出しが完了したか、の順に確認すると整理しやすくなります。「返信がない」という現象だけで、接続とルーティングと実行の問題を一緒に扱わずに済みます。
アカウント保護と操作の追跡
実機のアカウント設定。撮影用アカウントでは Passkey と二要素認証をまだ有効にしていません。
WebAuthn による Passkey ログイン、TOTP による二要素認証に対応しました。また、変更内容を記録し、完全性を検証できる操作ログが追加されています。複数人で管理する Workspace では、ログイン保護と「誰が何を変えたか」の確認に役立ちます。Passkey はブラウザーのセキュアコンテキスト要件なども満たす必要があるため、適切な HTTPS 環境で設定してください。
メディアは内容に基づいて重複を排除して保存され、同じメディアによる langbot.db の肥大化を抑えます。さらに、lbctl と API Key による管理・診断が使えるため、コマンドラインを既存の運用手順に組み込むこともできます。
5. はじめての設定と、既存環境のアップグレード
実機の導入ウィザード。プラットフォームの選択から、Bot 設定、AI エンジンの設定へ進みます。
新規ユーザーはサイドバーのガイドとシナリオ別の Bot 作成ウィザードを使えます。最初にシンプルな質疑応答を確認し、その後にナレッジベース、ツール、イベントルートを足していくと、問題が起きたときに原因を追いやすくなります。
既存環境では、次の順序で進めることをおすすめします。
- バックアップを取得する。
data/または PostgreSQL データベースと、現在のデプロイ設定を保存します。最新の v4.10.x からの更新を推奨します。 - Core と対応する Runtime を更新する。 接続状態を確認してください。4.11.0 は SDK
0.7.11に固定されているため、古い Runtime を混在させないようにします。 - Pipeline を移行し、プラグインを更新する。 移行後の Runner 設定と、新しいセッションになる点を確認します。
- 実際の利用経路をテストする。 既存のメッセージ応答を先に確認し、その後でイベントルートや許可したツールを試します。
- テレメトリーと設定変更を確認する。 新しい実行テレメトリーは既定で有効ですが、メッセージ内容は含みません。このテレメトリーは
space.disable_telemetry: trueで無効化できます。設定にはmedia_cache、api.host、runner.admin_pluginsが追加され、force_box_session_id_templateは削除されました。データ収集ポリシー（英語）とリリースノートを参照してください。
LangBot 4.11 を使い始める
4.11 がつなぐのは、タスクのきっかけ、処理する実行方式、そして管理・観察の方法です。従来のメッセージ応答はそのまま活かしながら、コミュニティでのやり取りやイベント起点の処理を少しずつ追加できます。
開発、テスト、ドキュメント、フィードバックに協力してくださった皆さんに感謝します。本記事は主要な製品更新に絞って紹介しました。貢献者の一覧は正式版リリースノートをご覧ください。
画像について：イベントルーティングと Runner 一覧の二枚は v4.11.0 GitHub Release から引用しています。残る五枚は、この記事用に公式イメージ rockchin/langbot:v4.11.0 を独立して起動し、実際の画面から撮影しました。各言語版で見比べやすいように UI は英語で統一しています。本番 Bot への接続は行っていません。