ITに詳しくなくても AIで何を手伝えるか

社内に専門家がいない会社のための読み方

※以下は架空の例です。特定の製品を試した結果や、実際の障害記録ではありません。

「予約画面がなかなか開かない」「注文の途中でお客様が帰ってしまう」。仕事で使うサイトが遅くても、社内に詳しい人がおらず、保守会社へ何を伝えればよいか困ることがあります。

このような場面では、AIにまず状況の整理を手伝ってもらいます。「いつから」「どの画面で」「何が困るか」をまとめ、使ってよい記録をもとに説明を補います。AIを導入するだけで不具合が直る、という意味ではありません。

AIと人が受け持つこと

会社の担当者は業務への影響を伝え、保守会社は原因と対応案を調べます。設定を変える前には、費用、止まる時間、改善しない場合の戻し方を説明してもらい、会社側が承認します。AIの説明で分からない点が残ったら、無理に判断せず専門家へ確認します。

自社に必要かを考える三つの確認

1 困りごとは何か　問い合わせへの説明や、保守会社とのやり取りに繰り返し時間がかかっているか。

2 任せる範囲はどこまでか　AIは確認と説明の補助にとどめ、設定変更や削除を勝手に行わないか。

3 誰が最後まで対応するか　情報の扱い、費用、原因不明の場合の相談先、変更後の確認まで決まっているか。

すでに保守会社が十分に対応していて困っていなければ、AIを追加すること自体を目的にする必要はありません。自分たちの手間が減る場面があるか、まずそこから確かめます。

ここからは、保守会社と話す際に使える詳しい例です。数値や専門用語をすべて理解してから読み始める必要はありません。

保守会社と確認する詳しい点検手順

※この記事は架空の机上演習です。企業、構成、数値、ログ、判断結果はすべて説明用に作成しました。実サーバーや特定製品で動作を確認した記事ではありません。

ここからは、保守会社と確認事項を共有するための詳細です。社内担当者が数値を判断しきれなくても、何を調べ、どこで止め、誰が元へ戻すかを確認できる構成にしています。

1 見てよい範囲を決める

演習の対象は、従業員30人、社内窓口1人で技術保守を外部へ委託する架空企業です。サーバーとは、サイトの情報や処理を支えるコンピューターのことです。今回は1台を対象に、CPU使用率（処理の混み具合を見る指標の一つ）、応答時間、処理待ち件数、個人情報などを除いたエラー記録（異常の履歴）をAIに渡します。再起動、ファイル削除、設定変更は任せません。

今回はサーバーへの接続自体を行わず、用意した架空データを読み取る設計です。実導入では、文章で禁止するだけでなく、接続先と権限でも操作範囲を制限できるか確認します。読み取り専用でも情報が外部へ送られる可能性はあるため、渡す情報と送信先の承認は別に必要です。

2 結論より先に根拠を確認する

架空の点検データでは、CPU使用率92％、応答時間の95パーセンタイル（計測した応答の95％が収まる時間）は0.9秒、処理待ち40件とします。AIの出力は「観測値」「考えられる原因」「不足している情報」に分けます。CPUが高いことだけで故障や原因を断定せず、測定時刻、継続時間、通常時との差も確認します。

3 変更と戻し方を一緒に承認する

対処候補は、一度に並行して処理する数（同時実行数）を8から4へ一時的に減らす案とします。負荷が下がる可能性はありますが、処理待ちが増える懸念もあります。保守会社が変更対象、確認時間、中止条件、元へ戻す方法を説明し、社内担当者が承認します。演習では「応答時間が2秒を超えたら中止し、8へ戻す」と決めます。これは説明用の基準であり、一般的な推奨値ではありません。

4 設定変更と改善の成否を分ける

変更後の架空データではCPUは70％に下がる一方、応答時間は2.4秒、処理待ちは120件に増えました。CPUだけを見れば改善に見えますが、承認時の失敗条件に当たります。そこで変更を中止し、保守担当者が元の設定へ戻す流れを確認します。

復旧後は設定値と利用者側の応答を再確認します。変更前の状態に戻っても、高負荷の原因が解決したわけではありません。未解決事項、次の調査担当、残した証拠を記録して演習を終えます。

AI活用の最初の評価軸は、自動化した操作の多さより、根拠を追えて、止める判断と復旧手順が明確になったかです。実機での権限制御、計測、設定変更、復旧は別途検証が必要です。

架空の設定と判断の時系列

以下はすべて架空の机上演習です。数値は入力例、操作は想定手順、結果はシナリオ上の期待判定です。実際の点検や設定変更、障害復旧は行っていません。

演習の前提

対象は架空のアプリサーバー app-01。社内担当者が業務への影響と変更の可否を判断し、外部の保守担当者が調査・変更・復旧を担います。AIは人が用意したデータの整理と提案だけを担当し、接続権限や変更権限は持たない想定です。実行数の初期値は8、変更案は4。評価時間は変更後5分、応答時間の95パーセンタイルが2秒を超えたら中止して8へ戻します。

入力例となる架空の観測記録

CPUと応答時間は各5分間の集計値、処理待ちは区間終了時の件数という設定です。実データ、製品の実測値、推奨しきい値ではありません。

承認から中止と復旧まで

09:06 点検結果の整理　AIがCPUの高負荷を示し、原因は未確定と明記。同時実行数を減らす案と、待ち時間が増える懸念を保守担当者へ提示します。

09:08 人の承認　社内担当者が保守会社から説明を受け、対象、8から4への変更、5分間の評価、中止基準、元の8へ戻す手順まで承認する想定です。承認内容と変更前の設定を記録します。

09:10 変更の実施　外部の保守担当者が変更する想定です。AIの提案だけでは実施しません。変更対象と反映後の設定値を確認します。

09:15 失敗の判定　応答時間2.4秒が中止基準を超えました。CPUの低下だけで成功とせず、改善失敗として追加変更を止めます。

09:16〜09:21 元の状態への復帰　外部の保守担当者が同時実行数を8へ戻し、設定値、応答時間、処理待ちを再確認する想定です。応答は元の水準に戻りますが、CPUの高負荷は未解決のまま残します。

実機では別途確認する事項

権限制御の有効性、情報の送信範囲、計測の正確性、実際の変更方法、復旧の可否と所要時間、データ整合性は未検証です。演習後の記録には観測値、承認内容、変更前後の設定、判定理由、未解決事項、次の担当者を残します。