セルフホスト型AIチケット分類器の構築

AIチケット分類器とは

AIチケット分類器は、受信したサポート依頼を読み取り、カテゴリ、優先度、感情、影響範囲、振り分け先キューなどの構造化項目を提案します。ワークフローでは元のメッセージを保持し、振り分け理由を説明できるようにしたうえで、不確実な案件や制限対象の案件を指定のレビュー担当者へ送ります。

「パスワードという語があればITへ送る」といった固定フレーズの規則だけでは、文脈を十分に捉えられません。たとえば同じ「フリーズ」でも、銀行では口座の凍結、SaaSでは画面の停止を指します。LLMを使う自動チケット分類器は依頼文全体を読み、こうした意味の違いを踏まえて分類します。

明確な案件は決定ルール、繰り返しの多い案件は類似度検索、判断が難しい案件は言語モデルで処理するように役割を分けられます。各段階の精度を個別に測り、信頼度が低い案件、機密性の高い案件、影響の大きい案件は人が確認します。

自社構築かSaaSか：チケット分類の導入方式を選ぶ

マネージド型とセルフホスト型を比較するときは、総コスト、データの流れ、連携作業、継続的な保守、レビュー管理、障害復旧を同じ条件で確認します。

1. 費用の内訳は導入方式によって変わります。 マネージドサービスはプラン料金、使用料金、サポート料金を組み合わせることがあります。セルフホスティングワークフローはインフラストラクチャ、モデル、エンジニアリング、監視、インシデント対応作業を追加します。実際のチケット数とレビュー量の両方を考慮してください。
2. データの流れを明確にします。 チケット本体、添付ファイル、ログ、モデル入力、レビュアーノート、バックアップがどこに送られるか、どれくらいの期間保持されているか、そして誰がアクセスできるかを確認しましょう。
3. 連携品質はワークフローごとに検証します。 認証、フィールドマッピング、識別、レート制限、再トライ、重複防止、書き込み権限、ロールバックを、必要なチケットの送信元と目的地ごとにテストします。

ランタイム、分類ロジック、コネクターの動作、運用管理を自社で持ちたいチームは、Zylosを検討できます。登録済みエージェント間で処理を引き継ぐ必要がある場合に限り、HxA Connectをエージェント間の引き継ぎに使います。まず一つのチケット入力元をシャドウモードで試し、範囲を広げる前に実装と確認に必要な工数を測定します。

ZylosでAIチケット分類器を構築する方法

Zylosは、チケット分類ワークフローの状態、ツール呼び出し、引き継ぎを管理するエージェントランタイムです。本番導入の可否は、分類体系、コネクター権限、人によるレビュー範囲、監視、復旧計画によって決まります。以下では、これらを確認できるパイロットの進め方を示します。

ステップ1：Zylosエージェントランタイムをセットアップする

まず公式のセットアップ手順を確認します。必要なOS、Node.jsのバージョン、ランタイム、認証情報は変更される可能性があるため、導入時点の公式情報に合わせて準備してください。

# 方法1：LinuxまたはmacOSで公式インストーラーを使用
curl -fsSL https://raw.githubusercontent.com/zylos-ai/zylos-core/main/scripts/install.sh | bash

# 方法2：Node.js 20以降で手動インストール
npm install -g --install-links https://github.com/zylos-ai/zylos-core
zylos init

# セットアップ後にサービス状態を確認
zylos status

テストメッセージを送信し、チケットデータやコネクタ権限を追加する前に、ランタイム、ログ、エラー経路を確認しましょう。

ステップ2：チケットの分類体系を定義する

分類体系では、ワークフローが返す項目と、その判断に使う業務ルールを定めます。カテゴリ名を明確にし、各カテゴリを承認済みのキューへ対応付け、必ず人が確認する案件を文書化します。以下は設計の出発点であり、すべての組織に共通する分類ではありません。

{
  "classification_rules": {
    "categories": [
      "bug_report",
      "feature_request",
      "account_issue",
      "billing_question",
      "integration_help",
      "performance_degradation",
      "security_incident",
      "general_inquiry"
    ],
    "priorities": ["critical", "high", "medium", "low"],
    "routing": {
      "bug_report":        { "target": "engineering-bot" },
      "security_incident": { "target": "security-bot" },
      "billing_question":  { "target": "billing-bot" },
      "feature_request":   { "target": "product-bot" },
      "account_issue":     { "target": "account-ops-bot" },
      "default":           { "target": "support-review-bot" }
    },
    "confidence_threshold": 0.85
  }
}

confidence_threshold はルーティング制御であり、普遍的なデフォルトではありません。レビュー済みのチケットでキャリブレーションを行い、提案、支援ルーティング、自動割り当てに異なる閾値を適用してください。機密性や影響の大きいカテゴリは、信頼度に関わらず人間のレビューが必要になることがあります。

ステップ3：チケット入力元を接続し、振り分け先を提案する

各入力元は、チケットシステムの公式APIまたは承認済みコネクターを通じて接続します。キューへの割り当てやチケット更新は、そのコネクターの権限範囲内に限定してください。登録済みエージェント間で構造化結果を渡す場合、HxA Connectはエージェント間の引き継ぎに利用できますが、チケットシステム用コネクターそのものではありません。

// 疑似コード：利用するチケットシステムの公式APIに合わせて調整してください。
onTicketReceived(async (ticket) => {
  const result = await classify(ticket, taxonomyVersion);
  await recordEvidence(ticket.id, result, ticket.source);

  const needsReview =
    humanReviewCategories.has(result.category) ||
    result.confidence < thresholdFor(result.category);

  if (needsReview) {
    return sendToReviewQueue(ticket, result);
  }

  return proposeAssignment(ticket, result.targetQueue);
});

分類結果をエージェント、チーム、コネクターの間で受け渡す場合は、承認済みの引き継ぎ経路を使用します。課題の作成、アラート送信、ヘルプデスク更新など各プラットフォーム固有の操作は、受信側コネクターの権限範囲内で実行します。

ステップ4：展開・監視・改善

本番のルーティングを有効にする前に、権限、ログ、シークレット、キュー上限、ロールバックを確認できる環境へランタイムと分類器を配置します。

# Run Zylos with the official container image
docker run -d --name zylos \\
  -p 3456:3456 \\
  -v zylos-data:/home/zylos/zylos \\
  -e OPENAI_API_KEY=$OPENAI_API_KEY \\
  ghcr.io/zylos-ai/zylos-core:latest

分類の採用率、修正、再割り当て、エスカレーションの見逃し、レビュー工数、コネクター障害、復旧時間を監視します。カテゴリと言語ごとに結果を確認し、全体平均だけで問題のある経路を見落とさないようにします。

AIチケット分類器を比較：自社構築とSaaS

自己管理型ランタイムがチケット業務に適する場合

自己管理型ランタイムは、分類ロジック、コネクターのコード、導入時期、証跡をチームで管理したい場合に適しています。その一方で、安全な設定、更新、監視、復旧もチームの責任になります。

• 業務に合わせた分類。 サポート組織に合わせてカテゴリ、優先度、エスカレーション規則、レビュー範囲を定義します。すべての依頼を共通テンプレートへ無理に当てはめません。
• 監査可能な記録。 入力、分類バージョン、モデルまたはルール結果、信頼度、最終割り当て、査読者の訂正を記録し、誤ったルートを調査・再現できるようにします。
• 管理された引き継ぎ。 構造化した結果を承認済みのキューやコネクターへ渡し、受信側システムの権限範囲で具体的な操作を実行します。
• 運用管理。 自己管理型の構成では、バージョンと導入時期をチームで管理できます。その一方で、更新、セキュリティ、監視、復旧もチームが担います。

よくある質問