GeminiでITチケットの滞留を技術者の配車計画に変える方法

結論から言うと： ManageEngine ServiceDesk Plusから未解決の案件を書き出し、チケット本文に加えてSLA期限、拠点一覧、部品の在り処をGeminiに渡し、まず遠隔で直るものと現地対応が要るものに分け、次に現地案件を訪問ルートにまとめさせます。一週間分の計画が数分で出ます。地方都市の支店の近くに技術者を用意することはできません。

多拠点のIT運用には、毎週火曜に必ず現れる同じ問題があります。未解決のチケットが四十件ほどあり、そのいくらかは人が現地に行く必要があり、今週誰がどこへ行くかを一人が決めなければならない。その判断は、表計算と、どの拠点が近いかという記憶と、どのSLAが最も切迫しているかという大まかな感覚で下されます。

うまくいきません。担当者が不注意だからではなく、これが小さな組合せ最適化の問題であり、他に六つ仕事を抱えた人が時間に追われて解いているからです。結果は、ある拠点の前を通り過ぎて別の拠点へ向かう移動、二週間で同じ建物へ二度、そして誰も現地対応が要ると気づかないまま静かに古びていくP2案件です。

これは言語モデルに向いた仕事です。難しさの大半が、非構造のチケット本文を読んで構造化された判断に変えるところにあるからです。そして例によって、本当に難しいのは計画づくりではありません。

現地訪問のまとめ方が下手になる理由

三つあり、いずれも個人ではなく構造の問題です。

手がかりが文章に埋もれている。 チケットに「現地対応が必要」と書いてある欄はありません。書いてあるのは「プリンターから擦れる音がする」「会議室3のLANポートが使えないと利用者が言っている」です。一件ずつ読んで推し量るしかなく、時間に追われれば、明らかに緊急でないものについてはその推論が省かれます。

地理が記憶であってモデルではない。 計画する人は大きな拠点は覚えています。工業団地のどの二区画が徒歩十分なのかは怪しく、無駄な移動はまさにそこに積み上がります。

制約どうしが絡み合う。 SLA期限、部品の在庫、技術者の技能、拠点の入館可能時間、移動時間——五つの制約を目視で最適化するとは、一つを最適化して残りを願うことです。そしてその一つはほぼ常に「最も切迫したSLA」であり、だからこの計画は構造的に後手に回ります。

自動化すべき二つの判断——現地が要るか、そしていつ行くか

分けてください。壊れ方が違い、必要な入力も違います。

チケット本文から「遠隔で直る」と「現地が要る」を分ける

ServiceDesk Plusは未解決チケットの一覧を書き出せます。参照番号、拠点、分類、優先度、起票日、SLA期限、そして説明と対応メモ。重要なのは説明であり、そこはどんなフィルタも扱えない部分です。

チケット本文をGeminiに渡し、一件ごとに三つのいずれかを返させます。遠隔で解決可能、現地対応が必要、情報不足——加えて一行の理由と確信度。三つ目こそが、この方法を使えるものにします。二択を強いられたモデルは曖昧な案件で当て推量をしますが、曖昧な案件こそ、外れたときに無駄足かSLA超過を招く場所です。「説明に電源が入るかどうかが書かれていない」と言えるようにし、それは車ではなく電話に回してください。

手をかける価値のある改良が二つあります。自分たちの例を渡すこと——すでに分類済みで理由も付いたチケットを二十件——自社環境の慣習は、IT支援についての一般知識より効きます。そしてもう一つ、本文がより大きな根本原因を示唆するチケットに印を付けさせること。同じフロアから通信断のチケットが四件なら、それは訪問四回ではなく、訪問一回とスイッチ一台です。積み上がった案件全体を横断するこの気づきは、一件ずつ読む人間の計画者がめったにやらないことです。

計画を組む——SLA期限、拠点、部品、技能

ここで入力を切り替えます。二つ目の判断にチケット本文はほとんど要らず、運用上の前提がすべて要ります。現地案件がどの拠点のものか、拠点間の移動時間または距離、各案件のSLA期限、必要な部品の在庫と所在、技術者の空きと技能、そしてデータセンターの48時間前申請のような入館制約。

提案スケジュールを出させます。どの技術者が、どの拠点をどの順で、どの日に回り、各訪問でどの案件を閉じるか。そして決定的に重要なのは、どの案件がカバーされないかと、その理由です。この未カバー一覧が最も価値ある産物です。「遅れている」を「この四件は今週対応できない。その拠点の可達範囲に技術者がいないため」に変える——感覚ではなく、証拠のついた要員の話になります。

置いた前提と、各判断を縛った制約も述べさせてください。「拠点Bは木曜。部品の到着が水曜のため」は配車担当が反論できる計画です。素の時間割はそうではありません。

実例——一週間分の滞留を四つの訪問ルートに変える

ある小売のIT部門が、都市圏と隣接二州にまたがる34店舗と二つの物流センターを、三名の現地技術者で支えています。月曜の滞留は未解決46件。

分類の一巡で、遠隔で解決可能、現地対応が必要、情報不足の三つに概ね分かれます。遠隔の山は想定より大きくなり、これはよくある結果です。ハードウェア故障として書かれた何件かは、きちんと切り分けられていなかった設定の問題でした。情報不足の山はサービスデスクの架電リストになり、その半分ほどは電話で解決して、訪問計画から消えます。

まとめの一巡が残りを扱います。九店舗に訪問が必要で、うち三店舗は互いに二十分圏内。前週の計画では、その三店舗は別々の三日に訪問されていました。モデルは四つのルートを提案します。一日で複数店舗を回るルートが二つ、部品到着待ちの物流センターが一つ、そして遠方の一店舗——そこは十一日開いている案件が二件あり、専用の一日に値します。

未カバーは二件。同じ遠方店舗の、いずれも緊急度の低い案件で、理由も付いています。より近いSLAを捨てずにその場所へ届く経路が今週は存在しない。これこそ持ち帰る価値のある発見です。配車の失敗ではなく、カバー範囲という事実であり、同じ店舗で数週間おきに再発します。

計画者が実際にすることは、その五分の一ほどを上書きすることです。ある店舗の店長が休暇中であること、以前クレームのあった拠点に特定の技術者を送るべきでないこと、物流センターが午前十時前の訪問を好むことを、モデルは知りません。下書きを十分で直すのは、一時間かけてゼロから組むのとは別の作業です。

AI支援の配車計画 vs FSMソフトウェア vs 派遣パートナー

• 非構造のチケット本文を読んで訪問要否を判断する — AI支援の計画が明確に有利。FSMツールが手を出さず、人がばらつく部分です。
• 新システムなしで使える計画に至る速さ — AI支援の計画が有利。書き出しとプロンプトが、調達サイクルと競います。
• 経路最適化とリアルタイムの配車機構 — FSMソフトウェアが有利。専用ツールは本物の最適化を行い、技術者のモバイル打刻を扱い、日程が動けば組み直します。
• 計画を実行させる — FSMソフトウェアが有利。文書の中の計画は提案ですが、システムの中の計画は状態を持つ割り当て済みの作業です。
• 誰もいない拠点に到達する — 派遣パートナーが有利で、他に競合しません。計画は、その都市にいない技術者を生み出せません。
• 契約上の到着保証 — 派遣パートナーが有利。4時間の緊急対応または翌営業日の到着SLAは誰かが引き受ける約束であり、計画は意図にすぎません。

読み方はこうです。AI支援の計画は切り分けとまとめの問題を安く解き、FSMソフトウェアは実行の問題を解き、どちらもカバー範囲の問題を解きません。配車の問題があると感じている多くのチームは三つが混ざっており、実際に費用を生んでいるのがどれかを知る価値があります。

計画が前提とし、現実がそうでないこと

四つあり、いずれも日常的に破れます。

その日が予定どおり進むこと。 午前九時のP1が全部を書き換えます。計画の本当の価値は現実に耐えることではなく、書き換えを安くすることです。どの二件が最も制約が緩いかを知っていれば、五分で組み直せます。

チケットが問題を正しく述べていること。 利用者が伝えるのは症状です。「モニターが映らない」が実はドックの故障だったなら、部品も技能も違い、二度目の訪問になることもあります。

誰かが中に入れること。 入館は現地ITで最も一貫して過小評価される制約です。入館申請、同行者、貸主の荷物用エレベーターの予約、交代時間帯に来訪者を入れない工場。

部品がシステムの言う場所にあること。 支店が「あるはず」と思っている在庫に基づく計画は、技術者が現場に立った状態で破綻する計画です。計画が依存する部品については、数字を信じず在庫を確認してください。

ここを外さない——チケットデータ、入館、そしてITに相談すべき時

書き出す前に、実務上の三点です。

チケット本文は個人データの塊です。 説明と対応メモには利用者名、連絡先番号、座席位置、時には業務データのスクリーンショットまで入ります。必要な項目——参照番号、拠点、分類、優先度、日付、説明——だけを書き出し、氏名と連絡先はファイルがどこかへ行く前に削るか仮名化してください。分類が使うのは症状であって、誰が報告したかではありません。ビジネス版かエンタープライズ版を使い、実際に使っている階層の現行のデータ取り扱いと学習の条件を「たぶん」で済ませず確認してください。

拠点情報はそれ自体が物理セキュリティ情報です。 住所、入館可能時間、担当者名を含む顧客拠点の一覧は、それだけで保護に値する文書です。アップロードするファイルには拠点コードを使い、対応表は手元に置いてください。

計画は易しいほうの半分です。 すべての拠点の可達範囲に、正しい技能と正しい部品を持った技術者がいて、署名したSLAを満たす日に到着する——それが難しいほうの半分であり、現地IT派遣が解いている問題です。オンデマンドの技術者と、100か国以上での4時間または翌営業日の契約上の到着。私たちのAI+サポートとマネージドITサポートはその両側にあります。Brocentは2007年の北京での創業以来アジアでマネージドITを提供しており、本社はシンガポール、2016年から香港にも拠点があります。自社のカバー範囲がちょうど尽きる地方都市の拠点も含みます。同じ「まずチケット本文を構造化する」型は、支援チケットから不具合報告を起草すると併せて読む価値があります。

よくある質問

どのチケットに現地技術者が必要かを、AIは確実に判断できますか

役に立つ程度には確実で、無人で回せるほどではありません。三つ目の選択肢——情報不足——と確信度を与え、確信度の低いものは電話に回してください。自社の履歴に照らすと、多くのチームで、明確な案件では経験ある配車担当と一致し、不明確な案件では正しく判断を保留します。それが望ましい振る舞いです。

チケット本文に顧客や従業員の個人データは含まれますか

ほぼ必ず含まれます。説明には報告した利用者名が入り、電話番号や座席位置を含むことも多く、対応メモにはさらに多く入り得ます。チケットの書き出しは既定で個人データとして扱ってください。分類に不要な項目は落とし、必要な項目は仮名化し、そのファイルがどこで処理されるかを意識して決めます。

SLA超過のリスクはどう扱われますか

なくすのではなく、見えるようにします。各チケットのSLA期限をモデルに渡し、提案する計画が満たせないチケットをすべて理由つきで挙げさせます。漠然とした不安が短い一覧に変わります。できないのは能力を生むことです。計画がSLAを満たせないなら、組み直しでは解決しません。

現地の技術者がいない拠点ではどうなりますか

計画の層では何も助けになりません。これはカバー範囲の問題で、正直な選択肢は、出張費を負担する、その拠点については合意する応答時間を延ばす、あるいはその都市に既に技術者を持つ派遣パートナーを使う、の三つです。毎週その案件を明示的に挙げ続けることが、この問題を可視化する方法です。

急な案件が入ったとき、日中に組み直せますか

できますし、これは良い使い道の一つです。残りの計画、新しい優先案件、各技術者の現在位置を渡し、最小の混乱で何を変えるべきかを尋ねます。各変更がどの制約に触れるかを言い直せるので、配車担当は一日を作り直さずに素早く判断できます。

これをやればフィールドサービス管理ソフトは不要ですか

いま表計算で計画しているなら、この方法は明確な改善で、試すのに費用もかかりません。FSMソフトが解くのは別の部分です。作業の割り当て、状態の追跡、モバイル打刻、その場での組み替え。問題が「計画はよいが守られない」であれば、埋めるべきはそちらです。両者は重ねられます。切り分けとまとめはモデルに、実行はシステムに。

まずどこから

先週すでに完了した現地案件を取り出し、さかのぼって分類を回してみてください。どれが本当に訪問を要したかは既に分かっているので、精度の目安がただで手に入り、何回の訪問が避けられたはずかが、何かを約束する前に分かります。切り分けもまとめも問題ないが、特定の拠点にはそもそも手が届かない、という結論なら、それは計画ではなくカバー範囲の話です。お問い合わせください。