情シス担当者が生成AIとRAGで障害切り分けを短縮するまで

午前八時五十五分。青空部品の執務室には、空調の低い音とキーボードをたたく音が流れていた。始業のチャイムが鳴る前から、Microsoft Teamsの通知音が、机の上で小さく震え始めた。

情シス担当の高瀬ユイは、湯気の消えかけたマグカップを端へ寄せた。画面には、短い相談が次々に並んでいる。「ログインできない」「画面が白い」「いつもより遅い」。ユイは椅子を少し前へ引き、ひとつ目の投稿を開いた。

「営業一課の佐伯です。部品発注の画面が開きません。つながらないです」

「いつからですか。佐伯さんだけですか。ほかの画面は使えますか」

返事が届くまでの間にも、通知音が重なった。別の社員からは、「さっきまで使えていたのに落ちました」と書かれている。その下には、「入力したら固まりました。戻されます」と続いていた。

ユイはメモ帳を開いた。時刻、名前、部署、使っている端末。対象のサービス名。そして、どの操作をしたときに起きたのか。聞くことは決まっているのに、相談する人の言葉は毎回少しずつ違った。

「製造二課の森です。つながらないというか、すごく遅いです」

「森さん、会社のほかのサイトは開きますか。Wi-Fiの表示はいつもどおりですか」

「ニュースは見られます。でも発注画面は、白いままです」

ユイは「ネットワークは使えている。対象サービスで白い画面」と入力した。だが、そのすぐ横で別の相談が跳ねた。

「パスワードを入れると、またログイン画面に戻ります」

「アカウントがロックされた表示はありますか。別の端末でも同じですか」

「表示はありません。自分のパソコンではだめで、隣の席でもだめでした」

ユイは眉を寄せた。端末の故障なのか。アカウントの問題なのか。それとも、社内ネットワークか、発注サービスそのものなのか。似た症状に見えても、最初に確かめる場所が違う。

静かな部屋の中で、通知音だけが忙しく走った。チャットの右下には未読の数字が増え、電話の着信ランプも赤く点滅した。ユイが一つの返事を書いている間に、別の部署から「止まっています」と投稿が入った。

「高瀬さん、これ、みんな使えないんですか？」

「いま確認しています。使えない画面の名前と、起きた時間を教えてください」

「画面の名前は……いつものやつです。朝から遅くて、いまは開きません」

ユイは一度、息を吐いた。「いつものやつ」では、調査する人に渡せない。サービス名がない。何時に始まったかも、どの人に起きたかも、まだぼんやりしている。

執務室の壁際には、社内FAQのリンクをまとめた紙が貼られていた。けれど、ログインの手順は共有フォルダにあり、ネットワーク確認の手順は別のフォルダにある。過去の障害記録は問い合わせ管理システムの中で、古いチケットに埋もれていた。

ユイは共有フォルダを開き、「ログイン」「発注」「ネットワーク」と順番に検索した。似た名前のファイルがいくつも表示される。更新日を確かめている間にも、Teamsの画面には新しい投稿が届いた。

「さっきの人と同じです。白い画面です」

「こちらは入れますが、ボタンを押すと固まります」

「私はログイン後に落ちました」

同じ障害かもしれない。別の障害が重なっているのかもしれない。ユイは三人の名前をメモの上で線でつないだが、確信は持てなかった。

十数分前に終わった別の障害を思い出し、過去のチケットを探した。そこには、「認証サーバーの応答遅延」「特定時間帯に発生」「サービス側へ確認」と書かれていた。けれど、その記録が今回にも当てはまるのかを確かめるには、今の発生時刻と対象サービスをそろえなければならない。

「まず聞き取りだけで、こんなに時間がかかるんだ……」

ユイは小さくつぶやいた。原因を探す担当者へ渡すころには、待っている社員の声がさらに増えている。復旧のために動きたいのに、最初の情報を集める作業で手が止まっていた。

画面の端で、また通知が光った。ユイは新しい相談を開き、いつもの質問を入力する。

「いつからですか。みなさんも同じですか。何をすると止まりますか」

問いかけるたび、返事は少しずつ違った。それでもユイは一件ずつ、端末、アカウント、ネットワーク、対象サービスを確かめていった。

「最初の聞き取りがそろえば、原因を探す人にすぐ渡せるのに」

そう思いながら、ユイはメモの空白を埋め続けた。窓の外では朝の光が明るくなっていたが、Teamsの通知音は、まだ途切れなかった。

給与明細を確認しようとした社員が、朝から社内ポータルに入れなくなった。青空部品のTeamsと代表電話には、ほとんど同じ時刻に相談が届き始めた。

午前八時三十五分、ユイの画面に最初のメッセージが表示された。営業部の藤田からだった。

「パスワードを入れても、またログイン画面に戻されます」

ユイが返信を打っている間にも、別の社員から通知が重なった。ある人は「画面が白い」と書き、別の人は「スマートフォンでは見える」と伝えてきた。短い言葉の間に、原因の手がかりが隠れていた。

「会社のネットワークだと開きません。自宅のスマートフォン回線なら、給与明細が見えます」

机の電話が鳴った。受話器の向こうでは、工場の総務担当が落ち着かない声で話していた。給与の確認を急ぐ社員が、窓口の前で順番を待っているという。

「パスワードを変えた人もいます。でも、変えていない人も入れません。何を案内すればいいでしょうか」

ユイは時計を見た。問い合わせは、もう一つの部署だけの話ではなかった。社内ポータルは多くの社員が使う入口であり、入口が閉じると、確認したい明細にも届かなかった。

まずは、試験導入中のAIチャットボットに聞いてみることにした。ユイは画面に、「社内ポータルへログインできない。会社のネットワークでは戻されるが、スマートフォンでは見える」と入力した。

少し待つと、チャットボットはなめらかな文章を返した。

「パスワードを再設定してください。改善しない場合は、管理者が認証情報のキャッシュを削除し、全利用者のセッションを再起動してください」

一見すると、手順がそろっていた。けれど回答の下には、共有フォルダに保存された古いPDFの名前が示されていた。そこには、現在とは違う認証の仕組みを前提にした復旧手順が書かれていた。

ユイはPDFを開いた。表紙には、以前使っていた認証サービスの名前が残っている。更新日も古く、現在のポータル画面とは違う図が載っていた。

「この手順を、そのまま案内してはいけない」

ユイの指が、管理者向けの操作欄の上で止まった。認証情報の削除や全利用者のセッション再起動は、利用者一人のパスワードを変える作業ではない。誤って実行すれば、ログインできない人を増やすおそれがあった。

そこへ、隣の席の佐伯リーダーが近づいた。ユイの画面を見て、静かに声をかけた。

「AIの答えを、そのまま復旧操作にしてはいけないよ」

「でも、手順らしい形にはなっています。どこが古いのかも、すぐには分かりません」

佐伯はPDFの末尾を指で示した。そこには、現在は使っていない認証基盤への連絡先が記されていた。共有フォルダには新しいFAQもあったが、過去の障害対応記録とは別の場所に置かれていた。

「AIは、見つけた文書をもとに答えます。でも、その文書が今も正しいかまでは、勝手に保証してくれない。しかも、過去の対応履歴とFAQがつながっていないと、根拠を比べることも難しいんだ」

ユイは、チャットボットの回答をもう一度見た。参照したPDFの名前は表示されているが、どの文章を根拠にしたのか、なぜ今回の症状に合うと判断したのかは分からなかった。

そのとき、ネットワーク担当の西野からTeamsに連絡が入った。

「スマートフォンのモバイル通信では正常です。社内ネットワークからだけ、認証先への経路でエラーが出ています。パスワードの問題ではなさそうです」

ユイの肩から、少しだけ力が抜けた。社員にパスワード再設定を頼む前に止められたからだ。西野が経路を確認し、佐伯がポータルの担当者へ状況を伝える間、ユイは問い合わせの時刻と端末、接続方法を一つずつ記録した。

「ログインできない、だけでは足りないんですね。どこから、いつ、何をすると戻されるのかが必要でした」

「そう。AIに任せたいのは、判断そのものではなく、情報を集めて候補を並べる仕事だよ」

佐伯は、画面の古いPDFを閉じた。

「社内の最新資料やFAQを探して、その根拠を示しながら答える仕組みなら、もっと安全に使える。RAGという方法で、AIの回答に社内資料の検索を組み合わせるんだ。ただし、最後に操作を決めるのは人だよ」

午後、ポータルは復旧した。原因はパスワードではなく、社内ネットワーク側の経路にあったため、パスワードを変えた社員には元の設定へ戻す案内が必要になった。

ユイは対応記録に、古いPDFの参照元と、今回の問い合わせで分かった条件を書き足した。共有フォルダの奥で眠っていた資料が、次の誰かを迷わせないように、最新のFAQと過去の対応履歴を結び直す作業が始まった。チャットボットの画面には、まだ小さな注意書きが残っている。答えを実行する前に、根拠と現在の状況を確認するための注意書きだった。

佐伯リーダーは、古いPDFをもとに危険な復旧手順を出したAIチャットボットの画面を閉じた。雨上がりの窓から光が差す会議室で、ユイと新しい初動の流れを考え始めた。

「AIに、何でも答えさせるのはやめよう。まずは、探して、確かめて、案内する形にしよう」

佐伯はホワイトボードに、三つの箱を描いた。左に「質問」、真ん中に「社内文書を検索」、右に「根拠つきで回答」と書き、箱の間を太い矢印でつないだ。

「この順番なら、AIに全部を覚えさせる必要はない。質問を受けるたびに、許可された文書を探して、その内容をもとに答えるんだ」

「AIに全部覚えさせるのではないのですか」

「そう。これはRAGと呼ばれる仕組みだよ。難しく聞こえるけれど、意味は『探してから答える』に近い。社内FAQや承認済みの復旧手順、過去の障害履歴を、その都度検索するんだ」

ユイは、前章の失敗を思い出した。古いPDFの一文だけを信じたAIは、状況を確かめないまま、復旧操作をすすめてしまった。探した文書の名前と該当箇所が一緒に表示されれば、人が答えを確かめられる。

「回答には、原因候補だけでなく、確認する項目も入れましょう。安全な次の手順と、有人対応へ切り替える条件も必要です」

佐伯はうなずき、右端の箱に小さく「根拠」「確認」「次の一手」「引き継ぎ」と書き足した。

二人は、入口をMicrosoft Teamsに置くことにした。社員は新しい画面を覚えなくてよいし、いつもの会話のように相談できるからだ。Teams上の生成AIボットが、短い言葉も、まとまらない文章も受け止める。

「『つながらない』だけでも、追い返さないようにしましょう。ボットが、いつから、誰が、どのサービスで困っているかを聞きます」

「それから、どんな操作をすると起きるか、どの範囲に影響しているか、だね」

ユイはホワイトボードの端に、五つの問いを書いた。いつから。誰が。どのサービスで。何をすると。どの範囲に。相談する人が答えやすい順に、会話の中で一つずつ尋ねる形にする。

「『画面が白い』『遅い』『落ちる』という言葉も、そのまま原因にしないことです。アカウントの問題か、端末か、ネットワークか、サービス全体の障害か。AIには候補を整理させます」

佐伯は、画面に出す回答の見本を作った。そこには、「考えられる原因」「まず確認する項目」「安全な次の手順」「人へ引き継ぐ条件」「参照した社内文書」が並んでいた。復旧ボタンの代わりに、担当者が判断するための小さな道しるべが置かれている。

そのとき、佐伯は別の箱をホワイトボードに描いた。「監視・AIOps」と書き、利用者の相談から伸びる矢印と、同じ画面へ向かう線を引いた。

「社員の申告だけではなく、監視からのアラートも見たい。AIOpsは、監視の情報をまとめて、異常のつながりを見つける考え方だよ。利用者が『遅い』と言った時刻に、サーバーやネットワークにも異常が出ていれば、同じ画面で比べられる」

「人の感じたことと、システムの数字を、別々に追わなくてよくなるのですね」

「そう。ただし、AIが原因を確定するわけではない。仮説を出し、確認する場所を示す。復旧するかどうかは、私たちが決める」

ユイはうなずいた。AIに任せる範囲が、少しずつ見えてきた。情報を集めて整えるのはAI。危険な操作を承認し、例外を判断するのは人。その境目が、以前よりはっきりしていた。

二人は導入の条件も書き出した。相談欄には、パスワードや個人情報などの機密情報を入力しない。文書はアクセス権に合わせて出し分ける。入力データをAIの学習に使わない設定にする。質問、回答、参照文書、引き継ぎの履歴は、あとで確認できるように残す。

「便利さを先に追うと、また足元をすくわれますね」

「だから、小さく始める。まずはログイン、メール、社内ポータルの三つ。危険な復旧操作はさせず、回答と根拠だけを返すんだ」

ユイは、白いボードに並ぶ矢印を見つめた。朝から続く「ログインできない」という相談が、ただの一文ではなく、時刻や範囲を持つ情報に変わっていく。埋もれていたFAQや障害履歴も、必要なときに手を伸ばせる場所へ移せそうだった。

「やってみましょう。AIを、復旧の代わりにするのではなく、初動を整える案内役にします」

その日の夕方、ユイはTeamsに置く小さな案内役の設計書を開いた。最初の質問は、短く、やさしく。答えの最後には、必ず根拠と人への引き継ぎ先を添える。会議室のホワイトボードには、「AIは案内役、復旧の決定は人」という一行だけが、消されずに残った。

小さな試験運用は、社内ポータル、VPN、アカウントロックの三つに絞って始まった。ユイはMicrosoft Teamsに「情シス試験室」チャネルを作り、問い合わせを一件ずつ流した。AIには、社内文書を検索し、根拠を添えるRAGの案内役として働いてもらう。ただし、復旧の判断は人が行う約束だった。

「まずは、困っている人の言葉を、そのまま入れてみましょう」

佐伯リーダーがテスト用の端末を開いた。画面の横には、現在使っている手順書を置いた。最初の申告は短かった。

「社内ポータルに入れません」

AIはすぐに返事をした。パスワードの再設定を行い、Microsoft SharePointにある手順書を確認するよう促している。手順は三段階に整理され、根拠として文書のリンクも付いていた。

ユイがリンクを開くと、「旧認証方式を利用する場合」と書かれていた。ページの隅には、赤い「利用停止」の印がある。現在のポータルでは使っていない方式だった。

「答えは整っています。でも、根拠が古いです」

「検索できたことと、今も使えることは別ですね」

佐伯は静かにうなずいた。似た題名の文書が複数あり、AIは古い手順書も候補に拾っていた。速く答えたつもりが、利用者を遠回りさせるところだった。

二人は、文書を増やす前に、並べ方をそろえた。手順書の先頭に、対象システム、症状、前提条件、実施者を書く。その下に、危険な操作、エスカレーション条件、文書の更新担当者を置いた。

「エスカレーションは、上の担当者へ渡す条件です。たとえば、複数部署で同時に起きたら、個人の再設定ではなく障害対応へ切り替えます」

ユイは一枚ずつ内容を確認した。旧認証方式の文書には、SharePointの文書プロパティで「利用停止」を付けた。検索の条件には「承認済み」を加え、承認されていない文書はRAGの検索対象から外した。

それでも、すぐには安心できなかった。AIの返事を自由な文章のままにすると、重要な確認を飛ばすことがある。そこでユイは、回答を決まった箱に入れる仕組みを作った。

「決まった箱、というのは？」

「JSONという形式です。症状、確認したこと、根拠、安全な次の手順、人へ渡す条件を、決めた欄に入れます。必須の欄が空なら、回答を出さずに再検索か聞き返しへ戻します」

次のテストで、社員役の佐伯が入力した。

「ポータルが落ちます」

以前のAIなら、ブラウザーの再起動を勧めていたかもしれない。だが今度は、回答の前に確認が返ってきた。

「画面が消えるのですか。それとも、ログイン画面に戻るのですか」

「言葉の曖昧さを、そのままにしないんですね」

ユイは、質問の答えを選択肢でも返せるようにした。画面が白くなる、ログイン画面へ戻る、エラーメッセージが出る。症状が分かれれば、参照する手順も変わる。

別のテストでは、社員役の佐伯が誤ってパスワードとアクセストークンらしい文字列を貼り付けた。AIは内容を繰り返さず、「パスワードやトークンが含まれています。削除するか、伏せ字にして再入力してください」と表示した。ユイは、秘密の情報を回答や記録に残さない設定も確認した。

定型的な確認には、Power Automate DesktopとPowerShellを使った。VPNの通り道へ接続できるか、アカウントがロック状態かを、読み取りだけで調べる処理だ。アカウントの停止解除や設定変更は自動化せず、Teamsのカードでユイか佐伯が承認した後にだけ進むようにした。

「AIは判断材料をまとめます。小さな確認は機械に任せます。でも、扉を開ける操作は人が押します」

最後に、AIが止まった場合も試した。試験用の接続を切ると、Teamsの案内役は返事をしなくなった。ユイは同じチャネルにMicrosoft Formsの手動受付フォーム、既存の手順書、有人の電話連絡先を並べ、フォームへの入力後に担当者へ電話が届く流れへ切り替えた。

電話を受けた佐伯は、フォームの受付番号を聞き、手順書を開いた。AIがいなくても、受付と確認が止まらないことを二人は確かめた。失敗を記録する欄には、古い文書を拾ったこと、曖昧な言葉を確認できなかったこと、停止時の切り替えに時間がかかったことを書いた。

夕方、ユイは試験結果を見返した。最初のAIは、早く答えた。しかし、正しい答えへ進む前に、間違った道を示していた。

「答えを早くする前に、間違った答えを止める仕組みが要ります」

佐伯は、承認済みの文書一覧と、空欄を許さない回答欄を保存した。Teamsのチャネルには、手動受付への道も残った。翌朝からの案内役は、答えを急がず、分からないときに立ち止まることになった。

社内ポータルの障害が再び起きた朝、Teamsに「社内ポータルに入れない」という投稿が届いた。けれども、以前のように相談が一つずつ重なり、通知欄が波のように埋まっていくことはなかった。

画面の端で、青いAIボットが静かに返事をした。

「症状を教えてください。画面が表示されない、ログイン画面に戻る、読み込みが続く、のどれに近いですか」

投稿した社員が「ログイン画面に戻ります」と答えると、ボットは続けて尋ねた。

「発生した時刻、同じ部署での発生状況、使用している端末とネットワーク、試した操作を教えてください」

質問は、取り調べのようではなかった。短い返事にも合わせて、ボットは「別のブラウザーでも同じですか」「社内ネットワークとVPNのどちらですか」と、必要なところだけを聞き返した。

以前なら、ユイは「落ちる」「固まる」「戻される」という言葉を受け取り、同じことを何度も聞き直していた。今はAIボットが、利用者の言葉をアカウント、端末、ネットワーク、サービス側という四つの切り分け軸に並べていた。

「申告を整理しました。認証に失敗した利用者が複数部署にいます。社内ネットワーク以外からの接続でも同じ症状があります」

ユイは表示された一覧を見た。利用者の申告は、監視システムから届いた認証エラーのアラートと同じ障害記録にまとまっていた。発生時刻、対象サービス、影響範囲、利用者が試した操作が、一つの画面でつながっている。

通知の一つひとつを開く必要はなかった。ユイは全体の形を見ながら、どこまでが利用者側で、どこからがサービス側なのかを確かめた。

AIボットが、RAGで社内の最新資料を検索した。回答の横には「社内ポータル障害対応手順書」の「認証基盤の確認」と、「認証基盤障害・過去対応記録」の該当箇所が添えられていた。

「候補を分けて表示します。認証基盤側の障害の可能性。利用者側で確認する項目。復旧担当へ渡す情報」

候補の下には、根拠となる手順と、過去の類似障害で確認された状況が並んでいた。古い手順書をそのまま答えに使わないよう、承認済みの最新版だけが検索対象になっていることも表示されていた。

ユイは文書名と該当箇所を開き、現在の運用と合っているかを確認した。管理者操作を含む手順には、実行前の承認が必要だと明記されている。AIが候補を返しても、復旧処理を勝手に始めるわけではない。

「この確認は実行してよいです。変更操作は止めてください」

ユイが承認すると、RPAと安全確認用のスクリプトが動いた。アカウントロックの有無、認証基盤への到達状況、サービスの応答状態だけが調べられ、設定変更や再起動は行われなかった。

数分後、障害記録に確認結果が加わった。認証基盤への接続失敗が複数の利用者で重なり、サービス担当が調べるべき時間帯と対象範囲もそろっていた。

「この記録をサービス担当へ渡します」

ユイが送信すると、担当者からすぐに返事が来た。

「状況が見えています。こちらで認証基盤を確認します」

以前のように、ユイが一人で聞き取りを続ける必要はなかった。何が起きたのか分からない報告に追われる仕事から、根拠を確認して次の人へ渡す仕事へ、手の動きが変わっていた。

復旧の通知が届くと、AIボットは対応内容を時系列にまとめた。ユイは、事実と推測が分かれていることを確かめ、誤りのない部分だけを承認して、FAQとナレッジベースへの登録を進めた。

外部の参考値では、RAG検索結果に整理された導入効果として、ヘルプデスクの対応時間が30〜50％削減されるケースが示されている（出典：RAG検索結果「期待できる効果・具体的な数値／導入時の注意点」、調査名・企業名・URLは同データに記載なし）。また、情シス業務を生成AIで効率化する事例では、Slackの事例として1人あたり週97分の削減が紹介されている。

青空部品で同じ数字が出たわけではない。それでも、効果を測る前の朝と比べて、ユイの画面には根拠と担当先のある記録が残り、通知欄の音は短くなっていた。

始業のチャイムが鳴った。ユイは新しい相談を開き、落ち着いた声でボットの確認結果を読んだ。隣の席では、復旧担当が必要な情報だけを受け取り、静かに調査を始めていた。

朝、障害のない青空部品のオフィスに、やわらかな光が差していた。Teamsのボットには、いつものように短い相談が届いたが、その宛先は情シスの個人チャットではなかった。

「つながらないです」

ボットはすぐに返事をした。

「確認したいことがあります。使っている端末は何ですか。ほかの人も同じですか。別のサイトは開きますか」

相談した社員が答えるたび、症状と確認結果が会話の中で整っていった。ユイは隣の画面で、その流れを静かに見ていた。

「前なら、この一言が私のところに来ていたんだね」

「はい。今は、まずボットが聞き取りをしています」と、後ろから運用担当の森が言った。「人が読むころには、調べるための材料がそろっています」

ボットは社内FAQや手順書をRAGで探していた。RAGとは、質問に合いそうな社内文書を先に見つけ、その根拠を使って答える仕組みだと、ユイは森に教わっていた。

画面には、回答の下に参照した文書名が並んでいた。けれど、答えが見つからない相談は、そこで止まらない。

「この症状は、有人担当へ引き継ぎます。症状、影響範囲、確認済みの項目、参照した文書を添えて送ります」

ユイの受信箱に、整理された案件が届いた。以前のように「つながらない」という一行だけではない。対象の部署、発生時刻、試した操作、似た相談の数まで、ひとつのカードに収まっていた。

前日のポータル障害の記録を開くと、ユイは空いている欄に手を入れた。最初に表示された画面、社内Wi-Fiとモバイル通信での違い、復旧後に利用者が確認したことを追記する。

「これで、次に同じことが起きたとき、昨日の私たちに聞き直さなくてすむね」

森はうなずき、保存ボタンの横にある「確認待ち」の表示を指した。対応結果は、そのままAIに学習させない。ユイと担当者が内容と根拠を確認し、承認したものだけをFAQやナレッジベースへ登録する決まりだった。

新しく登録する文書には、更新担当者と見直し時期も記録された。古い手順書は、共有フォルダの奥へ戻る前に、次に見る人の名前を持つことになった。

画面の中央に、前日の記録から整理された手順の草案が表示された。「ログイン画面が白い場合」「一部の部署だけ遅い場合」と、症状ごとの入口が分かれ、各手順には参照元の文書が添えられている。

そのとき、別の通知音が鳴った。生成AIの応答が一時的に止まったという運用アラートだった。

ユイは慌てず、あらかじめ作っていた切替表を開いた。まずClaudeの公式ステータスを確認し、小さな動作テストを行う。必要なら手動受付へ切り替え、代替のGPT-4oを使う。それでも難しい案件は、既存の復旧手順と有人対応で受け止める流れになっていた。

「AIが止まっても、受付まで止めないようにしたんだね」

「はい。道具が変わっても、根拠と引き継ぎ方は残ります」と森は答えた。

やがて最初の相談の画面に、ボットの新しい問いが浮かんだ。

「確認したいことがあります。エラーメッセージは表示されていますか」

ユイはすぐには立ち上がらなかった。回答の根拠と、有人担当へ回す条件を画面で確かめてから、ゆっくりとキーボードに手を置いた。静かな朝のTeamsに、また小さな通知音が響いていた。