つづきの技術室システムの運用・保守にAIをどう使うか、保守を請け負う側が任せることと任せないこと
月曜の朝、受注管理の画面が真っ白になっている、と営業の方から連絡が来る。情シスの担当者がサーバーに入ってエラーログを開くと、見慣れない英語が何百行も並んでいます。最近は、ここでその数百行をそのまま生成AIに貼り付けて「何が起きていますか」と聞く人が増えました。
正直に言うと、これはかなり役に立ちます。ログのどの行が本題で、どれが巻き添えで出ているだけなのか、当たりをつけるのは生成AIの得意なところです。一方で、その答えを読んだあと「AIがこう言っているので、このコマンドを本番で打ちます」となると、話が変わります。
私たちは、OSやミドルウェアの更新、不具合の調査と修正、改修といった日々の保守を請け負っている会社です。この記事では、運用・保守の現場でAIに任せてよいことと、任せないほうがよいことを、保守をする側から書きます。読んでいただきたいのは、社内のシステムを内製や外注で回している情シスの方、保守会社にAIの使い方を聞かれた、あるいは聞きたいと思っている発注担当の方です。
大企業のAIOpsと、中小規模の保守は別の話
「運用にAI」で調べると、監視データを大量に集めて異常を自動で検知し、復旧まで自動化する、といった大規模な仕組みの話がたくさん出てきます。数千台のサーバーを抱える会社なら、それは筋のよい投資だと思います。
ただ、私たちが普段お預かりしているのは、サーバーが数台、業務システムが1つか2つ、作った会社とはもう連絡が取れない、といった環境が中心です。こういう現場で困っているのは、異常の検知より「異常が起きたあと、何が起きているのか読める人がいない」ことのほうです。AIが効くのも、まずはそこです。
任せてよいと考えていること
エラーログやメッセージの読み解き
冒頭の場面がこれです。PHPの警告、データベースの接続エラー、ディスクの容量不足、証明書の期限切れ。数百行のログから原因らしい行を拾い、意味を日本語で説明させるところまでは、時間の節約になります。
ただし貼り付ける前に、ログの中身を一度見てください。ログには、顧客のメールアドレスや注文内容、ときにはパスワードやAPIキーがそのまま出ていることがあります。社内でどのAIサービスに何を入れてよいかが決まっていない場合は、先にそちらを決めておくほうが安全です。決め方は「ChatGPTを業務で使う前に決めておく社内ルール」に書きました。
更新前の下調べ
OSやミドルウェアを更新するとき、変更履歴や移行ガイドを読んで「うちのシステムで壊れそうなところ」を探す作業があります。英語の長い文書を要約させたり、古いコードの中から非推奨になった書き方を探させたりするのは、AIに向いている作業です。
ここで気をつけたいのは、AIは自信のある書き方で間違えることがある、という点です。「この関数はバージョン8.4で削除されました」と言われたら、公式の変更履歴でその1行を確かめる。下調べの範囲を広げるのに使い、結論は元の資料で決める、というのが私たちの考える使い方です。PHPの更新で実際に壊れやすいところは「PHP 8.2から8.3・8.4への更新の進め方」で書いています。
引き継いだコードと設定を読む
他社が作ったシステムを引き継ぐと、資料がほとんど残っていないことがあります。このファイルは何をしているのか、この設定はどこから読まれているのか。こうした「読む」作業の最初の地図づくりに、AIはよく効きます。
ただし、AIが説明するのは「書かれているコード」であって、「実際にサーバーでどう動いているか」ではありません。本番のサーバーでは、コードに書いていない定期実行の処理が動いていたり、誰かが手で直した設定が残っていたりします。最後は実際の実行環境を調べて確かめる必要があります。
報告を分かる言葉に直す
技術的な調査結果を、エンジニアではない方向けの報告に書き直すのも、AIが手伝える部分です。ただ、報告に書く事実と判断は人が決めます。AIに任せるのは言い回しまで、と線を引いておけば、報告が実態とずれることはありません。
任せないほうがよいと考えていること
本番環境への反映を決めること
AIが出したコマンドや修正案を本番に適用するかどうかは、人が決めるべきだと考えています。理由は単純で、そのシステムが止まったときに業務で何が起きるかを知っているのは、AIではなくその会社の人だからです。月末の請求処理の直前に更新をかけてよいかどうかは、ログを読んでも分かりません。
総務省と経済産業省の「AI事業者ガイドライン（第1.2版）」は、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用を検討すること、そしてその人間の判断が「自動化バイアス」に左右されないように対策をとることを求めています。自動化バイアスは、自動化されたシステムや技術への過度の信頼や依存が生じる現象、と説明されています（総務省 AI事業者ガイドライン 本編 第2部）。
保守の現場に置き換えると、「AIの提案を人が確認する手順はあるが、毎回そのまま承認している」状態は、確認していないのとあまり変わらない、ということです。夜中に障害の連絡を受けて疲れているときほど、こうなりがちです。
サーバーへの権限を直接渡すこと
最近は、AIにサーバーへのログイン権限を渡して、調査から修正まで自分で動いてもらう仕組みも出てきました。便利なのは確かです。ただ、業務システムの本番サーバーで、管理者権限を持ったAIに自由に動いてもらうのは、今の時点ではおすすめしません。少なくとも、使うなら検証用の環境に限る、読み取りしかできない権限にする、といった区切りが要ると考えています。
認証情報や顧客データを含む内容をそのまま渡すこと
先ほどのログの話と同じです。設定ファイルには、データベースのパスワードや外部サービスのキーが平文で書かれていることがよくあります。設定ファイルを丸ごと貼り付ける前に、その部分を伏せる。手間に見えますが、ここを省くと、AIの使い方の問題がそのまま認証情報の管理の問題になります。
何をAIに聞いたかを残しておく
あまり話題にならないのですが、私たちが大事だと思っているのが記録です。障害対応のあとで「なぜこの設定を変えたのか」と聞かれたとき、「AIにそう言われたから」では、次に同じことが起きたときに何の手がかりにもなりません。
AI事業者ガイドラインも、検証可能性を確保するために、利用時の入出力などのログを記録・保存すること、記録方法や保存期間は事故の原因究明や再発防止の観点から検討することを挙げています。大がかりな仕組みは要りません。障害対応の記録に、AIに何を聞いて、どの答えを採用し、何で確かめたかを2〜3行書き足すだけでも、後から読む人の助けになります。
保守会社にAIの使い方を聞くなら
保守を外部に任せている会社の方から、「うちの保守会社はAIを使っているのか、使っていてよいのか」と聞かれることがあります。使っているかどうかより、次のことを聞いてみるほうが実態が分かると思います。
- 自社のログやコードを、どのAIサービスに入れているか。そのサービスは入力を学習に使わない契約や設定になっているか
- 認証情報や個人情報を含む部分を、入れる前にどう扱っているか
- AIの提案を本番に反映するとき、誰が何を確かめているか
- 障害対応の記録に、AIを使った経緯が残っているか
この4つにすらすら答えられる会社なら、AIを道具としてうまく使っているはずです。逆に「AIは使っていません」という答えだけが返ってきた場合も、担当者が個人で使っていないかは一度確かめておいてよいと思います。
AIは「読む人」を増やす道具
私たちの考えをまとめると、運用・保守でのAIは、システムを「読める人」を増やしてくれる道具です。ログを読む、変更履歴を読む、古いコードを読む。ここで時間を短くしてくれる効果は大きく、使わない理由はあまりありません。
その一方で、本番を変える判断、権限、記録は人の側に残しておく。この線を引いておけば、AIに詳しくない会社でも、保守の質を下げずにAIの恩恵を受けられるはずです。
自社のシステムにAIの機能を組み込みたい、社内向けのAI環境を整えたいというご相談は新規事業のMVP開発・AI受託開発で、OSやミドルウェアの更新、不具合対応といった日々の保守はサーバー運用保守サポートでお受けしています。「AIに聞いてみたけれど、この答えを信じてよいのか分からない」という段階でも構いません。info@directorz-libero.co.jp までご連絡ください。