1) ドメイン入力レイヤー
リード、ジョブ、見積、請求、レビュー等のイベントを受け取り、担当エージェントへ振り分けます。
ServiceHub エージェント設計
ServiceHub AIエージェントの実装アーキテクチャ
このページは実装・運用向けドキュメントです。機能紹介ではなく、実際の動作原則を扱います。
このページの目的
featuresページは価値訴求、ここは設計説明です。役割を分けることで内容重複を避け、運用チームが判断しやすくします。
- エージェント境界を定義して責務の混在を防ぐ。
- イベント引き継ぎと冪等性ルールを明文化する。
- テナント/店舗分離と制御要件を示す。
- 信頼性とコスト最適化の運用パターンを整理する。
現場での Human vs Agent 比較
サービス業の日常オペレーションで、どこが変わるかを比較します。
| シナリオ | 人手のみの対応 | LeadDuo Agent の対応 | ビジネス影響 |
|---|---|---|---|
| 技術者が屋根上作業中に着信 | 着信を取り逃し、折り返しが遅れて機会損失になりやすい。 | 即時テキスト返信、簡易トリアージ、見積/予約リンク送信を自動実行。 | 取りこぼしていたリードを回収できる可能性が高まる。 |
| 営業時間外の緊急問い合わせ | 翌朝まで未対応となり、競合へ流れやすい。 | 即時受付メッセージ送信と、ルールに基づく緊急ルートへ自動振り分け。 | 初動速度が上がり、緊急案件の成約率改善が期待できる。 |
| 見積送付後に顧客が無反応 | 手動フォローが抜け漏れしやすい。 | 停止条件までポリシーに沿った段階フォローを自動継続。 | 事務負荷を増やさずに見積回収率を改善。 |
| 請求期限超過 | 担当者が個別に督促対応を実施。 | 支払いリンク付きの自動督促シーケンスと監査ログを実行。 | 未回収日数を抑え、資金回収を安定化。 |
本比較は一般的な想定例であり、特定の売上成果を保証するものではありません。
参照アーキテクチャ
ServiceHub自動化は単一巨大関数ではなく、レイヤー化されたエージェント連携として設計します。
2) エージェント判定レイヤー
業務ルール、閾値、dry-run/auto、緊急時の例外処理を判定します。
3) 実行レイヤー
メッセージ送信、割り当て、リマインダー、支払い追跡などの副作用を冪等キー付きで実行します。
4) 観測・監査レイヤー
前後状態と実行結果を履歴に記録し、説明可能性と障害解析を担保します。
エージェント責務
各エージェントは単一ドメインを持ち、明確なイベント境界で連携します。
Concierge Agent
SMS/メールの顧客対応ハブ。受信分類、返信ルーティング、通知実行を担当。
Intake Agent
不足情報、写真、必須項目を回収し、要件未達ジョブの配車を防止。
Scheduling Agent
スキル、稼働、移動制約で割り当て。最適化は dry-run と適用を分離。
Billing Agent
見積・請求・デポジット連絡と入金追跡シーケンスを実行。
Reputation Agent
完了後レビュー依頼と感情分析を自動化。
Ops & Integrations Agent
スタッフ通知、集計、トークン更新など内部運用処理を担当。
責務マトリクス
| エージェント | 主トリガー | 主アウトプット | 制御方法 |
|---|---|---|---|
| Concierge | 受信メッセージ / リマインダー期限 | SMS/メール送信 | テンプレート + ゲーティング |
| Intake | 必須情報不足ジョブ | 入力回収イベント | 必須項目ポリシー |
| Scheduling | 新規/更新予定ジョブ | 割り当て/最適化プラン | dry-run / auto / 閾値 |
| Billing | 請求ライフサイクルイベント | 支払いフォロー連絡 | 頻度 + エスカレーション |
| Reputation | ジョブ完了 | レビュー依頼 + 分析 | 送信タイミング + 承認 |
| Ops/Integrations | 定期運用チェック | 内部通知 | 店舗/ユーザースコープ |
引き継ぎパターン
- ドメインイベント受信。
- 担当エージェントがテナント/店舗スコープ検証。
- ポリシー判定で実行内容を決定。
- 型付きイベント発行または副作用実行。
- 実行結果をアクティビティ履歴に記録。
- 再試行時は決定的な冪等キーを使用。
イベント契約の統一
エージェント間メッセージは共通エンベロープを使い、将来のハンドラ追加でも破壊的変更を防ぎます。
イベントエンベロープ例
{
"name": "servicehub.dispatch.optimization_requested",
"data": {
"userId": "user_abc123",
"storeId": "store_xyz789",
"idempotencyKey": "opt|store_xyz789|2026-02-06",
"payload": "{ mode: "dry_run", date: "2026-02-06" }"
}
}安全性・分離ガードレール
- すべての読み書きを userId + storeId でスコープ。
- 所有権が証明できない処理は即時拒否。
- 公開エンドポイントにレート制限を適用。
- OTPは試行回数制御と濫用抑止を適用。
- 高影響変更は前後状態を履歴記録。
信頼性パターン
- 送信・状態遷移に冪等キーを適用。
- 遅延/取りこぼしイベント用のキャッチアップ処理を維持。
- 外部API障害時は再試行とバックオフ。
- 履歴ログで再実行判断と障害解析を容易化。
効率と実行コストをどう改善したか
高頻度ポーリングからイベント駆動へ移行
可能な箇所はエンティティ単位の遅延イベントへ移し、cronは安全網として軽量化しました。
意味論を保ったままバッチ化
set-based の claim と batched emit を使い、1件ごとのステップ実行オーバーヘッドを削減しました。
重複トリガーのノイズを抑制
idempotency・debounce・rate-limit を適用し、上流ノイズで実行回数が増幅しないようにしました。
不要な読み込みを最小化
判定に必要なフィールドのみ取得し、CPU負荷とクエリコストを下げました。
実際の導入ステップ
Phase 1: 提案モードから開始
最初はエージェントが提案し、人が承認して実行する形で正確性と運用信頼を確認しました。
Phase 2: ハイブリッド自動化
低リスク定型処理を自動化しつつ、高影響な変更は明示的な適用操作を維持しました。
Phase 3: 制御付き自動モード
安定したフローは全面自動化し、ガードレール・監査ログ・キャッチアップ処理を前提に運用しています。
今回の実装で適用した設計方針
- 単一巨大関数ではなく、ドメインエージェントに責務分割。
- ユーザー入力で回避できない安定レート制限キーを採用。
- 適用時は再計算ではなく承認済みプランスナップショットを利用。
- 必須検証が使えない場合は fail-close で停止。
- 読み書き前に tenant/store スコープを必須検証。
- 重いcron走査を減らし、エンティティ単位スケジュール + 軽量キャッチアップへ移行。
FAQ
顧客リマインダーやフォローは誰が担当？
Scheduling/Billingが期限判定し、Conciergeが送信実行します。
配車最適化は毎ジョブ自動実行すべき？
通常は非推奨です。まず店舗/日付単位の手動起動 + dry-run確認を推奨します。
テナント漏えいをどう防ぐ？
全ハンドラでテナント/店舗スコープを強制し、曖昧な所有権は拒否します。
遅延イベントの取りこぼし対策は？
軽量キャッチアップ処理で期限超過エンティティを再キューします（冪等キー付き）。
この設計を実運用に展開する
定型業務は自動化し、高影響な操作は承認を残し、監査ログで追跡できる運用にします。
まず製品全体を確認したい場合は、機能ページをご覧ください。