ゲートウェイなしで
- 各チャネルには独自のエージェント統合が必要
- セッションとIDはエントリーポイント間で移動します
- ツールと権限は複数の場所で設定されます
- オペレーターはエージェントシステム全体を閲覧できません
マルチチャネルエージェント運用
ADK Gatewayはメッセージングチャネル、Webアプリケーション、その他のエージェントをADK-Rustエージェントチームに接続します。各リクエストをルーティングし、適切なコンテキストを復元し、運用ポリシーを適用し、開発者にシステムを一元管理する場所を提供します。
ユーザーとシステム
アイデンティティ · ルーター · ランナー
エージェントチーム
なぜゲートウェイが必要か?
ADK-Rust エージェントは推論し、ツールを呼び出し、イベントをストリームできます。実際の展開では実用的な課題にも対応しなければなりません。 リクエストはどこに届く?どのエージェントが受け取るべき?誰のセッションを復元する?そのエージェントは何が許可されている?
ADK Gatewayは共有運用レイヤーを提供します。Telegram、Slack、WhatsApp、Discord、Matrix、Webhook、エージェント向けWebリクエストはアダプターを通じて入り、ゲートウェイはそれらを単一のメッセージ形態に変換し、アクセスルールを適用し、システムまたは専門エージェントにルーティングし、進捗を元のチャネルに返します。
ゲートウェイはすべてのエージェントを1つのアシスタントに統合しません。開発者は研究、サポート、運用、コーディングエージェントを異なるモデル、ツール、ワークスペース、権限、チャネルバインディングで分けて管理しつつ、1つのコントロールサーフェスで操作できます。
アーキテクチャ
左から右へアーキテクチャを読みます。リクエストは人間またはエージェントチャネルから入ります。アイデンティティとルーティングが所属先を決定します。ADK-Rustは選択されたエージェントを独自の状態と機能で実行します。制御プレーンは会話に参加せずにすべての層を監視します。
エントリーポイント
信頼エッジ
Gatewayランタイム
エージェントチーム
機能
オペレーター制御プレーン
完全なリクエストパスを構成、承認、監視、復旧、監査します。
1つのリクエストを追跡する
すべての対応チャネルに同じフローが適用されます。アダプターと配信形式のみが変わり、ルーティング、セッション、エージェント実行、ポリシー、証拠は共有されます。
Telegram、Slack、WhatsApp、Discord、Matrix、およびWebhookは異なる形式で届きます。各アダプターはそれらを同じ受信メッセージ契約に変換します。
ペアリングルール、許可リスト、グループメンションポリシー、マルチユーザーアイデンティティ、レート制限、およびオプションのJWTチェックはリクエストがエージェントに届く前に実行されます。
ルーティングはチャネル、アカウント、個人またはグループをチェックします。最も具体的な一致が勝ち、システムエージェントが最終フォールバックです。
Runnerはエージェント実行開始前に正しいセッション、ユーザーコンテキスト、メモリ、キャンセル状態、モデルフォールバックチェーンをアタッチします。
選択されたエージェントはRustツール、MCPサーバー、知識、ワークフロー、または承認済みACPコーディングエージェントを使用できます。役割ポリシーは呼び出せる内容を制限します。
型付きイベントはタイピングインジケーター、進捗メッセージ、画像、または最終応答になります。メトリクス、ログ、タスク履歴、監査イベントが何が起きたかを説明します。
Rustでのルーティング
開発者はエージェントをチャネル全体、チャネル上の1アカウント、または特定の個人やグループにバインドできます。ルーターは最も具体的なルールを最初にチェックし、予測可能にフォールバックします。
例は読みやすさのためにソース実装を凝縮しています。リポジトリは正確なアカウントレベル、チャネルレベル、レガシー、デフォルトのルーティング動作をテストします。
/// Most-specific binding wins.
pub fn resolve_agent(&self, message: &InboundMessage) -> &str {
// 1. channel + account + person or group
if let Some(agent) = self.exact_binding(message) {
return agent;
}
// 2. channel + account, then channel-only
if let Some(agent) = self.account_binding(message)
.or_else(|| self.channel_binding(message))
{
return agent;
}
// 3. configured legacy rules, then the system agent
self.legacy_binding(message)
.unwrap_or(&self.default_agent_id)
}{
"agent": {
"model": {
"primary": "openai/gpt-5.4-mini",
"fallbacks": ["openai/gpt-5.4-nano"]
}
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "${TELEGRAM_BOT_TOKEN}",
"dmPolicy": "pairing"
}
},
"user_agents": [{
"id": "support",
"name": "Customer support",
"tools": ["order_lookup", "refund_request"],
"channel_bindings": [{ "channel_type": "telegram" }],
"role": {
"allow": ["order_lookup", "refund_request"],
"deny": ["refund_issue"]
},
"auto_start": true
}]
}埋め込みコントロールパネル
ReactコントロールパネルはRustバイナリにコンパイルされ、以下で提供されます /ui. It is the operator interface for configuration, agent lifecycle, approvals, sessions, memory, scheduled work, logs, and health.
モデルプロバイダーを選択し、資格情報を保存し、チャネルアカウントを接続し、ゲートウェイをユーザーに開放する前に検証します。
スペシャリストを作成し、ツールとチャネルを割り当て、プロセスを開始または停止し、どのエージェントが作業を委任できるかを定義。
機密ツール呼び出しをレビューし、ユーザーをペアリングし、セッションを終了し、同意を検査し、タスクを継続すべきでない場合に介入します。
チャネルとエージェントをリアルタイムで監視し、エラーを検査し、メモリを検索し、稼働中のゲートウェイの状態を追跡します。
プロトコル境界を開く
チャネルはゲートウェイと人を接続します。プロトコルはそれを機能や他のソフトウェアに接続します。各境界は明確な役割を持つため、開発者はランタイム全体を再設計せずに一つを追加できます。
MCP
ブラウザ、コンピュータ、メディア、データ、ビジネスシステム用の機能サーバーを接続。ゲートウェイはすべての統合をバイナリに組み込むことなく、設定済みのMCPサーバーを追加、一覧表示、削除できます。
ACP
監視された境界内でサポートされるコーディングエージェントプロセスを実行します。作業スペースポリシー、許可リクエスト、進捗、コスト、キュー状態、タスク履歴はゲートウェイに表示され続けます。
AWP
ディスカバリー、機能、ヘルス、同意、サブスクリプション、およびエージェントメッセージエンドポイントを公開し、他のソフトウェアがゲートウェイとの連携方法を理解できるようにします。
HTTP + WebSocket
インバウンドWebhookは他アプリケーションから作業を取り込みます。HTTP APIとライブWebSocketイベントが組み込みコントロールパネルと外部操作ツールを支えます。
現在の境界: ソースはAWPサーフェス下でagent-messageルートを公開しています。このページは別途検証された完全なA2Aサーバーサーフェスや本番AWPコマース実装を主張しません。
ガバナンス
エージェントの自律性は設定可能な運用判断であるべきです。ADK Gatewayはリクエストを運ぶ同じ実行パスにID、権限、制限、証拠を配置します。
ペアリング、許可リスト、マルチユーザーセッション、JWT/JWKS、および役割マッピングは誰がリクエストを行っているかを判定します。
エージェントごとの許可・拒否ルールとツール承認により、ユーザーやエージェントが使用可能な機能が決まります。
レート制限、リクエストタイムアウト、キャンセル、制限付きツールループ、ヘルスポリシーにより作業継続時間を制御します。
監査イベント、ログ、メトリクス、タスク履歴、ツール結果、ヘルス履歴が運用記録を提供します。
展開
開発者のワークステーション、内部サーバー、またはコンテナは同じゲートウェイ形態を実行できます。セッションストレージはローカル実験ではメモリに保持し、展開システムではSQLite、PostgreSQL、Redis、Firestoreに移行可能です。
Rustサービスはコンパイル済みのReactコントロールパネルを埋め込みます。実行ファイルを1つインストールまたはコピーし、その隣に設定を保持してください。
リポジトリにはDockerfileとコンテナ展開用のボリュームおよびポート契約のドキュメントが含まれています。
systemdユニットは起動時の自動起動、再起動ポリシー、準備完了、ログ、オペレーター管理の環境ファイルをサポートします。
launchd定義は開発者とワークステーションエージェントのために永続的なローカルゲートウェイを実行します。
マイグレーションと検証
このページの製品機能はローカルのGatewayソース、設定、ドキュメント、テストスイートから提供されています。ADK-Rust v2移行はライブラリ、プロパティ、統合、生成エージェント、コントロールパネルの検証を通過しました。
チャネルアダプター、メッセージルーティング、エージェントレジストリ、プロセスライフサイクル、セッション、メモリ、RAG、スケジュールタスク、ツール承認、アクセス制御、コントロールパネルルート、AWP、MCP、ACP 統合、デプロイ資産、およびテストはレビュー済みリポジトリに存在します。
すべての ADK 依存関係はローカルの 2.0 ワークスペースに解決されます。Rust 2024 と Rust 1.95 はすべてのターゲットと機能でコンパイルされます。845 件のライブラリテスト、276 件の単体プロパティおよび統合テスト、81 件のコントロールパネルテストがすべて合格しています。
検証済みの v2 状態は現在ローカルのソースマイグレーションであり、公開された adk-gateway v2 クレートではありません。インストールガイダンスは引き続きソースチェックアウトと crates.io の v1 リリースを区別する必要があります。
すべてのメッセージングプロバイダー、モデルプロバイダー、外部 MCP サーバー、永続バックエンド、ID プロバイダー、および本番デプロイメントは、オペレーターによる資格情報、インフラストラクチャ、およびセキュリティレビューがまだ必要です。
マルチエージェントコード生成はまだプレースホルダーの A2A エンドポイントを文書化しており、AWP コマースは宣言されていますが完全なトランザクションシステムとしては実装されていません。どちらもここでは本番対応として提示されていません。
レビューソース: すべてのADK依存関係はローカルのv2.0.0ワークスペースに解決され、プロジェクトはRust 2024をターゲットにし、MSRVは1.94です。すべてのターゲット・すべての機能のコンパイルが成功しています。検証では845のライブラリテスト、276の単体プロパティおよび統合テスト、81のコントロールパネルテストが通過しています。crates.ioは引き続きv1リリースを公開しています。
ADK Gatewayはウェブサイトホスティングサービスではなく、ソースベースのソフトウェアとして提供されています。ローカルのv2移行は検証済みである一方、crates.ioはv1のままです。メッセージングチャネル、モデルプロバイダー、外部MCPツール、永続的バックエンド、および本番環境のセキュリティはオペレーターの資格情報とデプロイ設定に依存しています。実験的なコード生成とAWPコマースはソースドキュメントで明示的に制限されています。
運用レイヤーを構築する
検証済みv2ソースから開始。リポジトリにはゲートウェイ、埋め込みコントロールパネル、設定リファレンス、チャネルガイド、デプロイ資産、テストスイートが含まれ、完全なシステムの理解と運用に必要です。