1. はじめに：情シスの「一次対応」という底なし沼
「パソコンの画面が急に真っ暗になりました」 「VPNに接続できなくて、テレワークができません」 「Excelのファイルが開けなくてエラーが出ています（スクリーンショット貼付）」
社内の情報システム（情シス）担当者のSlackやメール受信箱には、毎日このような問い合わせが絶え間なく届きます。 一見シンプルな問い合わせのように見えますが、実際に解決するためには、エラーメッセージの意味を理解し、社内のシステム構成や過去の事例を思い出し、ユーザーに何度かヒアリングをして、最終的に手順を案内する——という複数のステップが必要です。
情シス部門の最大の課題は、この**「一次対応（トリアージ）業務」**が際限なく発生し、本来取り組むべきシステム設計やセキュリティ対策、DX推進といった戦略的業務の時間を根こそぎ奪ってしまうことです。
連載第7回となる今回は、**「ITヘルプデスク・障害一次対応」**という業務に、特に「画像認識」と「生成AI」の組み合わせがどのようなブレイクスルーをもたらすのかを解説します。
2. 現場のリアルな課題：チケット管理SaaSで「管理はできても、解決はできない」
情シス部門の業務効率化のために、ServiceNow、Freshdesk、Jira Service Managementなどのチケット管理SaaSを導入している企業は多くあります。これらのツールにより、問い合わせの受付・割り当て・進捗管理は格段に便利になりました。
しかし、チケット管理SaaSが提供してくれるのは「管理の仕組み」だけです。「問い合わせを解決すること」は、依然として情シス担当者の頭の中の知識に依存しています。
課題① 「スクリーンショットを読んで診断する」作業は自動化できない
ユーザーからエラー画面のスクリーンショットが送られてきたとき、従来のシステムではそれを「添付ファイル」として受け取ることしかできません。エラーメッセージの意味を解釈し、考えられる原因を診断するのは情シス担当者の人力です。
特に「0x8007005」のようなWindowsのエラーコードや、見慣れないアプリケーションのエラー画面などは、担当者が過去の記憶を頼りに「たしかこのエラーは権限の問題だったはず……」と手探りで対応することになります。
課題② 「社内Wikiの知識を検索して手順を案内する」作業が非効率
問題の原因が特定できたとしても、次に担当者は「解決手順をどこに書いたか」を社内Wikiで検索し、見つけたページをユーザーに案内する、という作業が必要です。これも小さいようで積み重なると大きな時間コストです。
3. 生成AIによるブレイクスルー：「見て、調べて、案内する」を自動化
近年の生成AIは、テキストを処理するだけでなく、「画像を理解して説明できる」マルチモーダル機能を備えています。この能力と社内Wikiへの参照機能（RAG）を組み合わせることで、まったく新しいヘルプデスクの形が実現します。
① スクリーンショットをそのままAIに送るだけで診断が始まる
ユーザーがSlackやTeamsのAIヘルプデスクBotに、「画面がこうなって困ってます」とエラー画面のスクリーンショットを貼り付けると、AIが以下のような形で即座に反応します。
AIヘルプデスク：「ご送付いただいたエラー画面を確認しました。 「Error Code: 0x80070005 Access is denied」というメッセージが表示されています。 これはアクセス許可（権限）の問題が原因であることが多く、以下のいずれかに該当する可能性があります。
- 対象ファイル/フォルダへの書き込み権限がない
- ウイルス対策ソフトが操作をブロックしている
- 管理者権限での実行が必要な操作をユーザー権限で行っている
まず、以下の手順をお試しください…（社内Wikiの解決手順が自動で挿入される）」
テキストだけでなく、エラー画面の「スクリーンショット」という視覚的な情報をそのまま処理して診断してくれるのが、生成AIの画像認識機能の強みです。
② 社内Wikiを参照した、自社環境に特化した解決手順の案内
汎用的な解決策ではなく、自社のシステム環境（使用しているOSのバージョン、VPNソフト、認証基盤など）に特化した解決手順を案内できるのが、社内Wikiと組み合わせたRAGの強みです。
「一般的なWindowsのエラー解決方法」ではなく、「わが社の環境でのみ適用される、社内Wikiに記載の正式な対処手順」をAIが選び出して案内してくれます。
③ 解決できない場合はエスカレーションの文脈も保持
AIが自動解決できない複雑な問題の場合も、「ここまで試したが解決しなかった」という会話履歴と「AIが行った初期診断の結果」を担当者に引き継ぐことができます。担当者は「どこまで試したか」をユーザーに再確認する時間が省け、すぐに高度な対応に取り掛かれます。
4. 具体的な業務フローのBefore / After
【Before】一次対応の全てが情シス担当者に集中
- 問い合わせ受信：ユーザーからSlackとメールに同時に問い合わせが届く（重複対応のロスが発生）。
- ヒアリング：「どんなエラーですか？」「どのソフトで起きましたか？」と担当者が何度もヒアリング。
- 診断・調査：エラーの意味を解釈し、社内Wikiや記憶を頼りに解決手順を調べる。
- 手順の案内：解決手順のリンクを送るか、リモートで画面に接続して直接対応する。
- 問題点：一人の担当者が同時に5件の問い合わせに追われ、全員の対応が遅れる。
【After】AIが一次対応を担い、担当者は複雑案件に集中
- 問い合わせ受信：ユーザーがSlackの統一チャンネル（AIヘルプデスクBot）にスクリーンショットを貼り付けて問い合わせ。
- AIが即座に診断・手順を案内：AIがスクリーンショットを解析し、社内Wikiを参照して解決手順を数秒以内に返答。24時間365日、受付直後に一次対応が完了する。
- 解決の確認：ユーザーが「解決しました」または「解決しませんでした」を返答するだけ。
- エスカレーション：AIで解決できない案件のみ、初期診断の文脈を付けて担当者に自動エスカレーション。
- 効果：情シス担当者に届く問い合わせ件数が激減。担当者は本当に専門的な判断が必要な案件だけに集中できる。
5. 導入に向けたステップと注意点
- 社内Wikiの整備と構造化 AIが社内Wikiを参照するためには、Wikiの記事がきちんと書かれていて、最新の状態に保たれている必要があります。「古くて使えない情報が混在しているWiki」はAIの誤案内のリスクを生みます。まずWikiの棚卸しを行い、誰でも読んでわかる形式に整えることが前提となります。
- AI解決率のモニタリングと継続的な改善 AIが解決できずにエスカレーションした案件の内容は、貴重なフィードバックデータです。「AIがうまく対応できなかったケース」を定期的に分析し、Wikiに解決手順を追記したり、プロンプトを改善したりするサイクルを運用として組み込みましょう。
- 社外公開の情報との分離 ヘルプデスクBotが社外からアクセスできる状態にならないよう、社内ネットワークやSSOへのアクセス制限を徹底してください。社内の機密情報が含まれるWikiを参照するシステムは、外部に漏れないよう厳格なセキュリティ設計が必要です。
6. おわりに
情シス部門は「攻めのIT（DX推進）」と「守りのIT（インフラ維持・ヘルプデスク）」の両方を担わなければならない、非常に負荷の高い部門です。 生成AIによるAIヘルプデスクは、「守りのIT」における定型的な一次対応業務の大部分を自動化し、情シス担当者がより創造的な「攻めのIT」業務に時間を振り向けられる環境を作ります。
次回、第8回は全部門に共通する課題として、**【業務ナレッジ・手順書の自動ドキュメント化】**をテーマにお届けします。「誰もWikiを書かない問題」を根本から解決する、チャット履歴からナレッジを自動生成するアプローチとは？ お楽しみに！
