社内ヘルプデスクのチケットを既知の障害・過去のチケットと突き合わせて分類し、既知事象への紐付けと回答の候補を付ける

処理の起点を決める

ITサービス管理ツールでチケットが作られたことを起点にします。 Webhookで AWS Lambda を呼び、1件ずつ処理します。定時のまとめ処理にはしません。 担当者がチケットを開く前に候補が付いていなければ、結局は手で探し始めてしまうからです。

もう一つの起点が、既知事象の台帳の更新です。 既知事象が登録・更新されたら、インデックスAをその1件だけ入れ直します。状態が「解決済み」に変わったものは、インデックスAの有効の印を外します。 外し忘れると、解決済みの不具合の回避策を、いまの問い合わせに返すことになります。

過去のチケットのインデックスBは、毎晩入れ直します。 前日に「解決済み」になり、解決方法の欄が埋まっているものだけを足します。解決方法が空のチケットは入れません。 引いても回答の候補にならず、上位を埋めて本当に役立つ記録を押し出すからです。

入力データを集める

質を決めるのは、既知事象の書き方です。 症状の欄に「VPN不具合」としか書かれていなければ、意味の近さで引いても当たりません。利用者が書きそうな言葉で症状を書くように、問題管理の担当と取り決めます。「接続ボタンを押すと『認証に失敗しました』と出て進まない」のように、画面の文言と操作の順で書くのが効きます。

「回避策を利用者に伝えてよいか」の項目は必ず持たせます。 回避策の中には「管理者権限で設定を変える」のように、利用者に伝えてはいけないものがあります。伝えてよくないものは、回答の候補に写しません。

カテゴリの定義に「迷う境目の例」を足すのは、第3章の（b）のためです。 「業務システムの画面がVPN経由でだけ開かないときはネットワーク」のように、担当者が迷った例を文章で残します。 AIへの指示にもこの例をそのまま渡します。

データの取得方法を決める

インデックスは2つに分けます。 引いたあとの使い方が違うからです。

検索は、ハイブリッドクエリに2つのサブクエリを入れて行います。 1つは本文の言葉の一致で、日本語の形態素解析を使った項目に match をかけます。もう1つは埋め込みの項目への knn です。絞り込みは、ハイブリッドクエリの filter に1つ書けば、すべてのサブクエリにかかります。 条件が複数あるときは Boolean クエリでまとめます。

{
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "symptom_text": "画面共有 ボタン 押せない 灰色" } },
        { "knn": { "symptom_vector": { "vector": [0.012, -0.031], "k": 20 } } }
      ],
      "filter": { "bool": { "must": [
        { "term": { "status_active": true } },
        { "terms": { "service_code": ["MEET", "PC"] } }
      ] } }
    }
  }
}

スコアの統合は、検索パイプラインの正規化プロセッサーで行います。 最初は min_max と arithmetic_mean、重みは言葉の一致0.4・ベクトルの近さ0.6で始めます。重みは合計1.0で、クエリ句の数と同じ長さにする必要があります。 エラーコードの多い領域では言葉の一致の重みを上げます。

ハイブリッドクエリを function_score や constant_score の中に入れないでください。 公式ドキュメントには、こうしたラッパーの中に入れると実行時エラーになるか、正規化のパイプラインが黙って飛ばされることがあると書かれています。新しい既知事象を優先したくて登録日で点数を足したくなりますが、それは検索のあとで Lambda の側で行います。

引く件数は、インデックスAから上位5件、インデックスBから上位10件です。 ページを送る必要は無いので from は使いません。from を0より大きくするときは pagination_depth が必須になります。

AIへ渡す前に整形する

1. 氏名と社員番号の除去 … 本文と署名から氏名を除き、所属だけを残します
2. 署名と定型文の除去 … 「お疲れさまです」や署名の行を落とします。残すと、挨拶の言葉で近いチケットが上位に来ます
3. 転送・返信の引用の除去 … メールで届いたものは、引用部分を落として最新の本文だけにします
4. サービス名の統一 … 「勤怠」「キンタイ」を正式名称にそろえ、対象サービスのコードを付けます
5. エラーメッセージの切り出し … 「」や英数字の並びから画面の文言を取り出し、言葉の一致の側に別に渡します
6. 長さの確認 … 埋め込みの入力は8,192トークンまたは50,000文字までです。ログが貼り付けられた本文は、先頭の説明部分と、エラーの行だけに絞ります
7. 重複の確認 … 同じ利用者が10分以内に同じ内容で起票したものは、先のチケットにまとめる候補にします

5番目に理由があります。 「0x80070005」や「AADSTS50076」のようなコードは、意味の近さでは近いものに寄りません。文字が一致したものだけが正解です。 本文と別に、コードだけを言葉の一致の検索語に足します。

4番目は、検索の前に絞り込みに使います。 対象サービスのコードが付けば、インデックスAの filter に入れて、別のサービスの既知事象が上位に来るのを防げます。 コードが付かなかったときは絞り込みをかけずに引きます。

AIに処理させる

させるのは、引いた候補とチケットの本文を読み比べて、4つの区分のどれに当たるかを決め、根拠にした候補の番号を返すことです。

あわせて、カテゴリの定義からカテゴリを1つ選ばせます。 迷う境目の例を渡し、それに沿って選ばせます。

2行目がいちばん起きやすい失敗です。 該当する既知事象が無いと、「キャッシュを削除してください」のような一般的な対処を回答に書きます。 一般的な対処が効く問い合わせもありますが、台帳に無いものを台帳の回避策のように見せることになります。

指示内容を固定する

あなたは社内ヘルプデスクで、届いたチケットを既知事象と過去のチケットに
照らして分類する担当です。渡した候補に書かれていることだけを使ってください。

【区分の選び方】
- known_issue ...... 既知事象の候補のどれかと、症状が同じと読める。
                     対象サービスと、画面の文言または操作の順が一致すること。
- similar_ticket ... 既知事象には当たらないが、過去のチケットの候補に
                     同じ症状で解決方法の書かれたものがある。
- new_issue ........ どの候補とも症状が一致しない。
- needs_human ...... 本文から症状が読み取れない。または一致する候補が
                     2つ以上あり、1つに決められない。
迷ったときは known_issue を選ばないでください。

【厳守事項】
- known_issue_id と ticket_ids には、渡した候補の番号だけを入れてください。
  候補に無い番号を書かないでください。
- 回答の候補 reply_draft は、既知事象の「回避策」または過去のチケットの
  「解決方法」の文をもとに書いてください。書かれていない手順を足さないでください。
- 既知事象の「利用者に伝えてよいか」が「不可」のものは、reply_draft に
  回避策を書かず、「担当者から連絡します」とだけ書いてください。
- 原因を断定しないでください。区分は症状が同じかどうかで決めてください。
- evidence には、一致したと判断した本文の文言と、候補の文言を
  そのまま書き写してください。
- カテゴリは定義の中から1つ選んでください。迷う境目の例があれば
  それに従ってください。
- 利用者の氏名を書かないでください。

【カテゴリの定義と迷う境目の例】{category_rules}
【チケットの本文】{ticket_body}
【画面の文言として切り出したもの】{error_strings}
【既知事象の候補（上位5件）】{known_issue_candidates}
【過去のチケットの候補（上位10件）】{ticket_candidates}

「迷ったときは known_issue を選ばない」を書かないと、近いものを既知事象に寄せます。 候補の中にいちばん近いものがある以上、それを選ぶのが自然な読み方だからです。選ばせたいのは「いちばん近いもの」ではなく「同じもの」です。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。 output_config.format に type: "json_schema" とスキーマを渡すと、スキーマに沿った応答が返ります。

{
  "classification": "known_issue | similar_ticket | new_issue | needs_human",
  "category": "",
  "known_issue_id": "",
  "ticket_ids": [""],
  "symptom_summary": "",
  "evidence": [
    { "ticket_text": "", "candidate_id": "", "candidate_text": "" }
  ],
  "reply_draft": "",
  "reason": ""
}

classification と category は enum で値を縛ります。 スキーマで使える機能のうち、enum と required が効きます。すべてのオブジェクトに additionalProperties: false を付ける必要があります。

known_issue_id は、enum にしません。 候補の番号は毎回変わるので、スキーマで縛れません。Lambda の側で、返った番号が渡した候補に含まれるかを確かめ、含まれなければ needs_human に書き換えます。

数値や文字数の制約もスキーマでは縛れません。 構造化出力では minimum・maximum のような数値の制約と、minLength・maxLength のような文字列の制約がサポートされていません。回答の候補の長さは、指示とLambdaの確認で抑えます。

JSONで受け取る理由は3つあります。 1つ目は、区分ごとに後の処理を分けられることです。known_issue なら回答の候補を欄に入れ、new_issue なら新しい事象の集計に回します。2つ目は、番号の確かめが機械でできることです。3つ目は、evidence があるので担当者の確認が速くなることで、チケットと既知事象の両方を開かなくても、どの文言で一致したかが一目で分かります。

システムへ連携する

書き戻すのは「AI候補」の欄だけです。 既知事象の紐付けの欄、チケットの状態、担当者の割り当ては、この構成からは変えません。 紐付けの欄は担当者が「確定」を押したときに、ITサービス管理ツールの機能で埋まるようにします。

利用者への回答も送りません。 回答の候補は欄に入れるだけで、送るのは担当者です。回避策が古くなっていた場合に、誤った手順が利用者へそのまま届くのを防ぎます。

人が確認する

担当者は、チケットを開いたときに「AI候補」の欄を最初に見ます。

1. 区分を確かめる … known_issue なら、一致した文言の対を読み、同じ事象かを確かめます
2. 紐付けを確定するか外す … 同じなら「確定」、違えば別の既知事象を選ぶか外します
3. 回答の候補を直して送る … 利用者の状況に合わせて直します。回避策の手順が今も有効かは、台帳の更新日で確かめます
4. new_issue と needs_human は通常どおり調べる … 候補が付かなかったことも記録に残ります

目標は、1,800件をならして1件2分です。 known_issue と similar_ticket で候補が正しければ1分以内で済み、new_issue と needs_human は従来どおりの調査に入ります。調査そのものの時間は、第10章の2分には含めていません。

確定・変更・外したの3つは、必ず記録に残します。 どの候補を外したかの記録は、既知事象の症状の書き方を直す材料になります。

例外に対処する

7行目に注意が要ります。 大きな障害のときは、同じ症状のチケットが数十件まとめて届きます。1件目の分類をほかのチケットにも写したくなりますが、しません。 同じ時間帯でも、別の症状のチケットが混ざっているからです。

記録を残す

• チケットの番号、前処理のあとの本文、切り出した画面の文言
• 検索で引いた候補の番号とスコア（言葉の一致・ベクトルの近さ・統合後）
• Claude API に渡した指示と、返ったJSONの全文
• 担当者の操作（確定・別の既知事象を選んだ・外した）と、その日時
• 送った回答と、回答の候補との差分
• 新しい事象の候補として通知した件数と、その後の既知事象の登録

4つ目が、この仕組みを育てる記録です。 外された候補が特定の既知事象に偏っていれば、その既知事象の症状の書き方が利用者の言葉とずれています。 毎月の振り返りで、外された回数の多い既知事象から書き直します。