情報システム部門のヘルプデスクにかかってくる電話を文字起こしし、症状・端末・試したこと・対応をチケットの項目に起こす

処理の起点を決める

電話の設備が録音を保管場所に書き出したことを起点にします。 対象は、ヘルプデスクの番号にかかってきた通話だけです。通話が終わってから数分で下書きが届けば、担当者は申告者の声を覚えているうちに確かめられます。

通話が20秒未満のものは対象から外します。「〇〇さんいますか」「かけ直します」だけの通話に下書きを作っても、チケットの一覧が埋まるだけです。 折り返しの電話（担当者からかけたもの）も対象にし、同じ申告者の未完了のチケットがあれば、新しい下書きではなく、そのチケットへの追記の案として作ります。

処理が終わった録音には「処理済み」の印を付け、印の無い録音の数が未処理の数になるようにします。印を付けるのは、下書きの登録に成功したときだけにします。

入力データを集める

質を決めるのは、社内の用語の一覧です。 「シュッカシジ」が「出荷指示」なのか、社内の基幹システムの画面名なのかは、一覧が無ければ音声認識には分かりません。社内のシステム名、画面の名前、拠点の呼び名、端末の型番を一覧にし、フレーズリストとして渡します。公式の目安では、フレーズリストは2,000語句を超えないようにし、長いほど品質と待ち時間に影響するとされています。

発信元の番号は、申告者の手がかりに使います。 共用の電話からの通話もあるので、番号から決めた申告者は「候補」として扱います。

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

文字起こしは、Azure Functions から高速文字起こしの API を呼ぶだけです。

1チャンネルでしか録音できない電話の設備では、話者の分離に切り替えます。 diarization を {"maxSpeakers": 2, "enabled": true} で指定し、発話ごとの speaker で分けます。ただし speaker の番号は人と結び付いていないので、最初に名乗った話者を担当者とする決まりが要ります。 2チャンネルで録音できるなら、こちらは使いません。

AIへ渡す前に整形する

1. 通話の選別 … 20秒未満の通話と、ヘルプデスクの番号以外の通話を外します
2. チャンネルの確認 … 録音が2チャンネルかを確かめます。1チャンネルなら話者の分離の設定で呼びます
3. 保留と無音の区間を外す … 申告者がPCの裏のラベルを探しに行くあいだの保留を外します
4. フレーズリストの用意 … 社内の用語の一覧をまとめて渡します。システムの入れ替えがあった月は、一覧を先に更新します
5. 時刻の付いた発話の並べ直し … 2つのチャンネルの発話を時刻順に並べ、staff／caller の印を付けて1本の会話にします
6. 伏せ字の下準備 … 「パスワード」「暗証番号」「ワンタイム」「認証コード」の言葉の前後の発話に印を付けます

5番目で並べ直すのは、生成AIに会話の流れとして読ませるためです。 チャンネルごとの全文を別々に渡すと、「しました」がどの問いへの答えかが分からなくなります。

6番目は、この題材に固有の手当てです。 パスワードの再設定の問い合わせでは、申告者が古いパスワードを口にしたり、担当者が仮のパスワードを読み上げたりします。その発話は、下書きにも、生成AIへの入力にも残しません。 印の付いた発話の数字と英字の並びを、生成AIに渡す前に伏せます。

AIに処理させる

させるのは、会話の文字起こしを、チケットの項目に分けて写すことです。 原因を推定すること、優先度を決めること、分類を確定することはさせません。

「試したこと」を、通話の前と通話の中で分けるのが要です。 申告者が電話の前に自分で再起動していたのか、担当者に言われて再起動したのかで、二次対応の担当が次に頼むことが変わります。 分けて書かれていれば、同じことをもう一度頼まずに済みます。

影響の手がかりは、言葉と時刻だけを写させます。 「優先度：高」のような評価は書かせません。担当者は、申告者の「ラインが止まってる」という言葉を読めば、自分で優先度を選べます。 AIの評価が先に書かれていると、担当者はそれを追認しがちです。

1行目が、間違えたときにいちばん遠回りになる失敗です。 生成AIは、症状からもっともらしい原因を書き添えます。二次対応の担当は、チケットに書かれた原因を出発点にして調べ始めます。 外れていれば、その分だけ解決が遅れます。

指示内容を固定する

あなたは社内の情報システム部のヘルプデスクで、電話で受けた問い合わせの
文字起こしから、チケットの下書きを作る立場です。
文字起こしに書かれていることだけを使ってください。

【話者】
- staff はヘルプデスクの担当者、caller は問い合わせをした社員の発言です。

【書く項目】
- caller_name, site, extension ... caller が名乗った名前、拠点、内線
- device_words ...... 資産番号・PC名・型番として言われた文字。そのまま写す
- system ............ 社内の用語の一覧から1つ選ぶ。選べなければ other
- symptom ........... caller が言った症状。caller の発言だけから書く
- since ............. 発生の時期を表す言葉。そのまま写す
- impact_quotes ..... 業務への影響に関わる caller の言葉と、その offset_ms
- tried_before_call . caller が電話の前に自分で試したこと
- tried_in_call ..... 通話の中で staff が頼んで caller が試したことと、その結果
- staff_actions ..... staff が自分で行った操作（遠隔操作、アカウントの解除など）
- outcome ........... resolved／escalated／pending／unknown
- next_steps ........ 引き継ぎ先、折り返しの約束、caller が待つこと
- not_asked ......... 【チケットの項目の定義】のうち、通話の中で触れていない項目

【厳守事項】
- 原因を推定しないでください。「〜と思われる」「〜の可能性」を書かないでください。
- 優先度や分類を決めないでください。影響に関わる言葉を写すだけにしてください。
- staff の発言を symptom に入れないでください。
  staff が「画面が固まる感じですか」と聞き、caller が「はい」と答えた場合は、
  symptom に「担当者の問いに同意（画面が固まる）」と書き、
  confirmed_by_question を true にしてください。
- 資産番号、PC名、内線は、聞き取れた文字だけを写してください。
  桁を補う、似た番号に直すことをしないでください。
- ■ で伏せられた部分を復元しないでください。パスワードや認証コードを書かないでください。
- caller の言い方を専門用語に言い換えないでください。
- 信頼度の低い発話（low_confidence が true）を根拠にした項目は、needs_listen を true にしてください。
- 1回の通話で別々の問い合わせが2つ以上あるときは、issues を問い合わせごとに分けてください。

【チケットの項目の定義】{ticket_fields}
【社内の用語の一覧】{glossary}
【文字起こし（speaker、offset_ms、text、low_confidence）】{transcript}

「担当者の問いに同意」を分けて書かせるのは、聞き方の癖がチケットに出るからです。 担当者が「固まる感じですか」と聞けば、申告者はたいてい「そうですね」と答えます。申告者が自分で言った「固まる」と、問いに頷いた「固まる」は、二次対応の担当にとって重みが違います。

1回の通話で問い合わせを分けさせるのは、ついでの相談が多いからです。 「プリンターが動かない、あとメールの容量の警告も出ている」という通話は、担当が2つに分かれます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力（response_format に json_schema を strict: true で渡す方式）を使い、形を固定します。

{
  "call_id": "",
  "received_at": "",
  "staff_extension": "",
  "caller": { "name": "", "site": "", "extension": "" },
  "issues": [
    {
      "device_words": "",
      "system": "",
      "symptom": "",
      "confirmed_by_question": false,
      "since": "",
      "impact_quotes": [ { "text": "", "offset_ms": 0 } ],
      "tried_before_call": [""],
      "tried_in_call": [ { "action": "", "result": "" } ],
      "staff_actions": [""],
      "outcome": "resolved | escalated | pending | unknown",
      "next_steps": [""],
      "needs_listen": false
    }
  ],
  "not_asked": [""]
}

このあとに、ワークフローが照合の結果を足します。

1つ目の理由は、AIが写したものと、台帳で確かめたものを別の層に置けることです。 device_words は聞き取れた文字のまま残し、合っているかどうかは device_match が示します。 担当者は、合わなかった番号だけを録音で聞き直せば済みます。

2つ目は、not_asked で聞き漏れが分かることです。 端末や内線が空のまま起票されるのを、確認の画面で止められます。聞き漏れが続く項目は、担当者の聞き取りの型を見直す材料になります。

システムへ連携する

チケット管理の仕組みには「下書き」の状態でだけ登録します。 担当者が確かめて起票するまで、二次対応の担当の一覧には出しません。資産台帳と社員の一覧には書き込みません。 台帳に無い端末が見つかっても、台帳の更新は資産の担当が行います。

人が確認する

人が全件を確かめて起票します。 確かめ方は、下書きと文字起こしを並べた画面で、印の付いた項目から見ていく形にします。

1. device_match が matched でないものを先に見る … 録音の該当箇所を聞き直し、番号を確かめます。番号が分からないままなら、申告者に折り返して聞きます
2. 症状と試したことを読む … 申告者が言ったことと、担当者がしたことが分かれているかを確かめます
3. needs_listen の項目を聞き直す … 信頼度の低い発話を根拠にした項目です
4. 分類と優先度を選ぶ … 影響の手がかりの言葉を読み、社内の基準に沿って選びます
5. 伏せ字の漏れを確かめる … 下書きにパスワードや認証コードらしい並びが残っていないかを見ます

4番目は、AIに寄せません。 「ラインが止まっている」という言葉が、工場の1台の端末のことなのか、ライン全体のことなのかは、拠点の事情を知る担当者にしか判断できません。

目標は、900件をならして1件2分です。 超える月は、社内の用語の一覧が古いか、資産番号の復唱が守られていません。

例外に対処する

起きやすいのは、1行目と5行目です。 どちらも電話の設備と資産台帳の側の問題で、直すほうが文字起こしの精度を上げるより効きます。

記録を残す

• 録音（2チャンネル）と、伏せる前と伏せたあとの文字起こし（伏せる前のものは閲覧できる人を限る）
• 音声認識の応答の JSON と、Azure OpenAI に渡した入力と返ってきた JSON
• 照合の結果（device_match、caller_match、open_ticket）
• 担当者が下書きを直した記録 … どの項目を、どう直したか
• 起票したチケットの番号と、起票した担当者
• 項目ごとの not_asked の発生率

4つ目と最後の行は、指示と聞き取りの型を直す材料になります。 端末の欄が毎回空なら、復唱の決まりが守られていません。