場面1．問い合わせを「回答する前」にAIで仕分ける

　メールやチャット、チケットで届く問い合わせを内容ごとに分類します。生成AIに問い合わせ文を読み込ませ、ITSMに登録されたSLAや対象システムの重要度、利用者属性などと組み合わせれば、カテゴリ、緊急度、影響範囲、回答期限の候補を提示できます。不足している情報があれば、ユーザーに問い合わせるためのテキストをAIに下書きさせたり、過去のナレッジから回答候補を検索させたりすることもできます。

　ここで大切なのは、全件を同じ深さで人が確認する体制を見直すことです。AIによる分類結果や信頼度を基に、影響の小さい定型案件は簡易確認とし、重要案件や分類に確信を持てない案件を人が優先して確認します。運用が適切であれば、対応件数が減らなくても、担当者の負荷を抑えられる可能性があります。実際、ITSM（ITサービス管理）ツールの中には、問い合わせ内容の要約や対応メモの自動生成に対応するものも登場しており、こうした機能を持つツールを併用する選択肢もあります。

場面2．過去の手順書を「質問できる社内ヘルプデスク」に変える

　社内の手順書やFAQ、過去のチケット、構成資料をAIの検索対象にしておくことで、従業員が自然文で質問できる窓口を用意できます。この際、AIの回答には参照元の文書と更新日を必ず表示させ、回答できない場合は情シスへ引き継ぐルールにしておくことが重要です。さらに、検索対象にする文書は、機密区分や閲覧権限、保存期間を整理し、利用者が本来閲覧できない情報をAI経由で取得できないようにします。

　古くなった文書や重複する手順を定期的に検出させたり、寄せられた問い合わせから新しいFAQの下書きを自動生成させたりすれば、ナレッジそのものを育てていくこともできます。ITSMツールのナレッジ管理機能などは、こうした自己解決の窓口としても使われ始めており、有人対応が必要な問い合わせを減らす効果が期待されています。窓口としてAIを使える状況を作った後も、放置せずに更新を続けられる体制まで含めて設計しておくことがポイントです。

場面3．ログ調査と障害の一次切り分けを高速化する

　障害対応では、初動の速さが復旧までの時間を左右します。長いログからエラーや警告、発生時刻を抽出させたり、障害発生前後の変更内容を時系列に並べさせたりするだけでも、原因の絞り込みにかかる時間は変わってきます。想定される原因と追加確認項目をAIに洗い出させ、「ユーザー向け」「経営層向け」「ベンダー向け」と説明文を書き分けさせることも有効です。

　復旧後は、原因・対応・再発防止策をまとめた報告書の下書きも任せるようにします。ただし、AIが示した原因を全面的に信用し、そのまま採用するのは危険です。ログや製品資料に照らして「人間が検証する」工程は必ず残します。

　IT管理者を対象にした実証実験でも、サインイン調査やデバイスのトラブルシューティングにおいて、AIの支援によって精度と対応速度の両方が向上したという結果が報告されており、初動の質を底上げできる可能性は小さくありません。

場面4．定型スクリプトの作成とレビューをAIに手伝わせる

　アカウントや端末、ライセンスの棚卸し用スクリプト、CSVの整形や重複確認、設定値の比較といった定型作業は、生成AIに作らせやすい領域です。既存スクリプトの処理内容や危険な箇所を説明させたり、エラーの原因を分析させて修正案を提示させたりすることもできます。コメントや利用手順、ロールバック手順まで一緒に作らせておけば、後から見返したときの安心感も違います。

　ただし、本番環境での実行前には「検証環境で試したか」「権限は適切か」「対象件数や変更内容に誤りがないか」などを、必ず人間の目で確認するようにします。ここを省略すると、便利さが一転してリスクに変わります。作業のスピードを上げるほど、確認のプロセスは意識して手厚くしておく必要があります。

場面5．会議、ベンダー対応、稟議の文書作成を任せる

　会議の文字起こしから決定事項や課題を抽出させたり、ベンダー提案を機能・費用・契約条件・リスクの観点で比較させたりする作業も、AI向きです。また、製品導入の稟議書や社内通知、FAQの下書き、技術的な内容を経営層向けの表現に変換する作業、障害やメンテナンスの案内文を対象者別に作る作業も任せられます。

　ここで情シスが人間の手に残すべき仕事は、事実、数値、契約条件が正しいかどうかを最終確認することです。文章を一から書く時間を減らせれば、確認や判断に時間を振り向けられる可能性があります。その時間を有効活用することこそが、AIを活用していることにつながっていると考えましょう。

場面6．定期業務を「AIに尋ねる」から「AIが実行する」に変える

　プロンプトを都度入力してAIに尋ねるだけの使い方から一歩進めると、「毎朝の障害・アラート・未処理チケットの要約」「毎週の退職予定者や不要アカウント」「未使用ライセンスの抽出」「毎月の端末更新状況や脆弱性対応の進捗報告」といった業務を、AIが定期的に実行する仕組みに変えられます。契約更新日や証明書の期限を確認させ、対応候補をあらかじめ作らせておくことも可能です。

　ここで欠かせないのは、条件に合う案件を優先通知し、その他も一覧と監査ログに残す、削除・停止・権限変更などの操作には必ず承認プロセスを残しておくことです。個別のプロンプト利用から、こうした自動実行の仕組みへと段階的に発展させていく流れは、働き方全体のトレンドとしても指摘されています。

AIだけで確定・実行させてはいけない判断を、先に線引きしておく

　一方で、次のような判断はAIに任せるべきではありません。

• 管理者権限の付与
• 退職者や不審アカウントの停止判断
• 本番環境の変更
• セキュリティインシデントの封じ込め
• バックアップの削除や復元
• 法令、契約、個人情報に関する最終判断
• ベンダー選定や予算の最終決定

　これらはいずれも、間違いが発生した際の影響が大きく、取り返しがつかないことが起きやすい領域です。AIに作業を任せる範囲を広げるほど、こうした最終判断の線引きをあらかじめ決めておくことの重要性は増していきます。線引きを曖昧にしたまま任せる範囲だけを広げると、便利さと引き換えに大きなリスクを抱え込むことになります。

まとめ

　ここまで見てきたように、生成AIを使いこなす情シスと、相談相手として使うだけで終わる情シスの違いは、ツールの性能ではなく、業務の切り分け方にあります。問い合わせの仕分けから、ナレッジの窓口化、障害対応の初動、スクリプト作成、文書作成、そして定型業務の自動実行まで、任せられる作業は思っている以上に広がっています。

　一方で、管理者権限の付与や本番環境の変更、法令や契約に関わる最終判断のように、人が担い続けるべき領域もはっきりしています。これまで複数人で分担すべきとされていた作業を生成AIに肩代わりさせ、限られた人数でも役割を回せる体制をつくることがポイントです。

　成果を測る際は、削減時間という指標だけを追いかけないようにします。未処理件数がどれだけ減ったか、対応にかかる時間がどう変わったか、同じトラブルの再発率がどう推移したか。こうした複数の指標を組み合わせて見ていくほうが、現場の実感に近い成果をつかめます。

　始め方に迷う場合は、いきなりすべての業務を変えようとせず、まず自社の情シス業務を一覧にし、それぞれが「判断」なのか「作業」なのかを仕分けるところから着手します。作業に分類できたものから、小さな範囲でAIに任せてみる。うまくいけば対象を広げ、うまくいかなければ人の手に戻す。この繰り返しが情シスの働き方を少しずつ変えていく一歩になります。