守るだけの情シスから、社内の活用と改善を進める情シスへ

情報システム担当者、いわゆる情シスの仕事は、社内システムを止めないことだけではありません。社員がITを安全かつ円滑に使える環境を整え、新しい仕組みを導入し、業務改善を前に進める役割も担っています。

一方、現場では、障害や問い合わせへの突発対応、アカウント管理、端末設定、資料探し、ベンダーとの確認などが次々に発生します。目の前の依頼に対応するほど、中長期の改善や導入計画に使える時間が減ってしまうこともあります。

業務AIエージェント Jiteraは、許可された運用資料、問い合わせ履歴、システム情報、導入検討資料などをもとに、情報の抽出・整理、回答や文書の初稿作成、比較、確認事項の洗い出しを支援します。情シスに代わって運用判断や導入判断を行うものではなく、担当者が根拠を確認し、より早く適切に判断するための土台を整える仕組みです。

情シスの役割は「問い合わせ窓口」だけではない

情シスは、社員からの質問に答える窓口として見られがちです。しかし実際には、既存環境を安定させる仕事、利用者を支援する仕事、将来の業務を支える仕組みを導入する仕事を並行して進めています。

3領域は独立していません。たとえば、新しいSaaSを導入すると、アカウント管理や問い合わせ対応が運用業務に加わります。導入段階で運用手順やFAQを整えなければ、開始後の問い合わせが増え、改善業務に使える時間がさらに減ります。

情シスの1日と、突発対応が計画業務を圧迫する構造

情シスの一日は、監視結果と問い合わせの確認から始まり、運用作業、利用者対応、導入案件、ベンダー調整、報告へと続きます。ただし、障害や緊急のアカウント対応が発生すると、予定していた調査や改善は後ろ倒しになります。

時刻別の業務フロー

突発対応そのものをなくすことはできません。問題は、必要な資料や過去の対応を探す時間、同じ内容を何度も説明する時間、対応後の記録を作り直す時間まで重なることです。日々の記録を次の対応で再利用できる形に整えることが、計画業務の時間を確保する第一歩になります。

繰り返し発生する定型作業

情シスが抱える3つの課題

1. 運用・保守の属人化

システム構成図や手順書が存在していても、「なぜこの設定なのか」「障害時にどの条件で切り分けるのか」「どこまで影響したら誰へ連絡するのか」といった判断の背景までは残っていないことがあります。

設定値、操作手順、障害記録が別々に管理され、過去の判断が個人のメールや記憶に閉じると、担当者の異動や退職のたびに調査がやり直しになります。また、古い手順を現行環境へ適用すると、誤った対応につながる可能性があります。

必要なのは、手順だけでなく、対象環境、適用条件、前提、例外、判断理由、確認者、更新日を一緒に残すことです。AIで整理する場合も、現行情報と旧情報を区別し、実環境や正式な手順と照合できる状態が欠かせません。

2. ヘルプデスクの繰り返し対応

「ログインできない」「権限がない」「申請方法が分からない」といった類似の問い合わせでも、利用者、端末、対象サービス、発生時刻、エラー表示などの条件は異なります。そのため、過去回答をそのまま再送するだけでは解決できません。

一方で、毎回ゼロから文章を作り、関連する手順を探し、確認項目を並べ直すのも非効率です。問い合わせ内容と過去の対応履歴、FAQ、利用ルールを照合し、回答案と追加確認事項を分けて作ることで、担当者は個別条件の確認に集中しやすくなります。

回答案は、利用者へ送る前に担当者が確認します。本人確認、権限変更、認証情報、セキュリティ事象、個人情報に関わる内容は、定められた本人確認、申請、承認、エスカレーションの手順を優先します。

3. 導入プロジェクトの情報整理負荷

SaaSや新規システムの導入では、利用部門の要望、機能要件、セキュリティ質問票、契約条件、費用、連携仕様、移行計画、ベンダー回答など、多くの情報を扱います。資料がメール、表計算、会議記録、提案書に分散すると、同じ項目を転記し、回答の差分を確認する作業が増えます。

さらに、製品ごとに資料の構成や表現が異なるため、単純に横並びにしても比較できないことがあります。要件を共通の観点にそろえ、確認済みの事実、ベンダーへ確認中の事項、自社で判断すべき事項を分ける必要があります。

Jiteraによる比較結果は、製品選定や契約の最終判断ではありません。最新の公式資料、契約条件、見積もり、セキュリティ評価、法務・購買・利用部門の確認を経て、責任者が導入可否を決定します。

Jiteraで変わる業務

Jiteraは、情シスが許可した範囲の資料をコンテキストとして参照し、情報整理と初稿作成を支援します。資料にない事実は推測で補わず、不足情報や確認先を分けて示す運用が重要です。

コンテキストを登録するときの注意点

• 対象システム、対象環境、版、更新日、所有者、確認者を明記する
• 現行手順と旧手順、正式情報と検討中情報を区別する
• 個人情報、認証情報、秘密情報は社内規程と権限に従って扱う
• 参照してよい部署、案件、利用目的の範囲を定める
• 出力には根拠となる資料と、不足している情報を示す
• 古い資料の更新、利用停止、削除の運用を決める

実務で使えるプロンプト例

以下は、登録済みのコンテキストを使って初稿や確認事項を作るための例です。実際の業務では、対象システムや社内ルールに合わせて項目を調整してください。

ヘルプデスク回答案

登録済みのFAQ、利用ガイド、申請ルール、過去の対応履歴だけを参照してください。
次の問い合わせに対する回答案を作成してください。

【問い合わせ】
ここに利用者からの問い合わせを入力

次の形式で整理してください。
1. 問い合わせの分類
2. 利用者へ送る回答案
3. 回答前に確認する情報
4. 利用者に追加で確認する質問
5. 参照した手順またはFAQ
6. 担当部署へのエスカレーションが必要な条件
7. 情報が不足している事項

資料に根拠がない操作や設定を推測で案内しないでください。
本人確認、権限変更、認証情報、セキュリティに関わる場合は、正式な申請・承認手順を優先し、「担当者確認が必要」と明記してください。

障害の一次調査

登録済みのシステム構成図、運用手順、監視定義、変更履歴、過去の障害記録だけを参照してください。
次の事象について、一次調査の観点を整理してください。

【事象】
発生時刻、対象システム、利用者への影響、エラー内容、直前の変更を入力

次の形式で出力してください。
1. 確認できている事実
2. 影響範囲を確認する項目
3. 優先して確認するログ、監視、構成情報
4. 過去の類似障害と相違点
5. 原因仮説と、それぞれを確認する方法
6. 暫定対応を検討する際の注意点
7. エスカレーション条件と確認先
8. 不足情報

原因を断定せず、事実と仮説を分けてください。
変更、復旧操作、再起動、切り戻しを自動実行せず、正式な障害対応手順と担当者の承認を前提にしてください。

SaaS導入比較

登録済みの業務要望、要件一覧、候補製品の公式資料、見積もり、セキュリティ質問票、ベンダー回答だけを参照してください。
候補となるSaaSを、次の観点で比較してください。

1. 必須要件への適合状況
2. 利用者・管理者向け機能
3. 認証、権限、ログ、データ管理に関する確認事項
4. 既存システムとの連携条件
5. 初期費用、継続費用、追加費用
6. 導入、移行、教育、運用に必要な作業
7. ベンダー回答間の差分
8. 未回答または根拠不足の項目
9. ベンダーへ追加確認する質問
10. 社内で判断・承認が必要な事項

資料に記載がない項目は「要確認」とし、推測で評価しないでください。
総合順位を自動で決めず、評価軸ごとの事実と差分を示してください。

JiteraとAIの役割分担

AIの出力は、障害原因、復旧操作、権限付与、セキュリティ評価、契約条件、製品選定、リリース可否の最終判断ではありません。情シス、システム責任者、セキュリティ、法務、購買、利用部門、ベンダーなど、必要な関係者が参照元と実環境を確認し、テスト、レビュー、承認を行います。

カプコン事例との関連

株式会社カプコンでは、担当者の入れ替わりや退職により、長期プロジェクトの開発経緯やインフラのノウハウが失われやすいことが課題でした。Jiteraを活用し、既存ソースコードのリバースエンジニアリング、仕様書や不具合対応の経緯を含むコンテキストの整理、IaCコードの解析・ドキュメント化を進めています。

この取り組みは、情シスにとっても参考になります。システム構成や手順だけでなく、変更の背景、不具合対応の経緯、構成の意図まで次の担当者が確認できる形にすることで、引き継ぎ時の再調査を減らしやすくなるためです。また、個人ごとに分散しがちなAI活用を、チームでコンテキストを共有・蓄積する取り組みへ広げる視点も共通しています。

詳しくは、カプコン様の導入事例とゲーム開発でのJitera活用ガイドをご覧ください。

製造・金融・SIer・ゲームへの展開例

製造業では、製造業のMES・基幹DBをJiteraで可視化する事例と組み合わせることで、現行システムの把握から改修前の影響調査までを具体化できます。

金融機関では、金融機関のレガシーコードをJiteraで解析する事例が、長期運用されているプログラムや周辺資料を起点に、保守に必要な情報を整理する参考になります。

ゲーム開発では、ゲーム開発でのJitera活用ガイドで、コードの仕様可視化、IaCのドキュメント化、担当者交代に備えた知識共有の例を紹介しています。

まとめ

情シスの役割は、システムを守り、問い合わせに対応するだけではありません。社員がITを活用できる環境を整え、運用から得た知識を次の改善へつなぎ、新しい仕組みを社内へ定着させることも重要な役割です。

Jiteraは、許可された運用資料、問い合わせ履歴、システム情報、導入資料などをコンテキストとして活用し、情報整理、回答案、一次調査の観点、比較表、文書の初稿作成を支援します。繰り返し作業をその場限りで終わらせず、確認済みの知識として蓄積・更新することで、担当者の経験をチームの業務資産へ変えていけます。

まずは、件数が多く回答基準を定めやすい問い合わせ、特定システムの障害記録、比較対象を限定したSaaS導入など、小さな範囲から始めます。入力資料、出力形式、確認者、承認手順、保存先を決め、AIが整理した内容と人が確認した内容を区別しながら、段階的に対象を広げることが大切です。