経験者の仕事は、手順書だけで引き継げるのか。AI時代に会社が残したい「判断」

手順書には、こう書かれています。

該当ジョブのログを確認する。

担当者は手順どおりにログを確認しましたが、ログは一切出ていませんでした。

確認場所も手順も間違っていないのに、次に何を確認するのかは、この一文だけでは分かりません。

以前の記事では、夜間バッチの障害対応を例に、経験者が確認結果を受けながら調査先を変えていった過程を紹介しました。

今回は障害の原因そのものではなく、対応が終わった後に判断の流れを分解した資料から、手順と最終原因の間に何があったのかを見ていきます。

「ログを見る」は、残す必要がある

最初に確認しておきたいのは、手順書が必要だということです。

「該当ジョブのログを確認する」という情報が残っていなければ、次の担当者は、どのログを見るのか、どの処理を確認し、どの順番で作業するのかという調査の始め方から探さなければなりません。

こうした手順が整理されていれば最初の確認へ進みやすくなり、社内AIやRAGから手順書を検索する場合にも、必要な手順が文書として残っていることが前提になります。

問題は、その手順を実行した後です。

ログを確認した結果、何も出ていなければ、手順書に書かれた作業はそこで終わり、次に何を見るのかを考える仕事が始まります。

「ログがない」と「外部からの強制終了を疑う」は別の情報だった

今回の障害では、該当ジョブのログが一切出力されていませんでした。

経験者はこの結果を受けて、プログラム内部の異常だけを見るのではなく、外部から強制終了された可能性へ調査を移しています。

通常の異常終了であれば、エラーコードやスタックトレースなど何らかのログが残る場合がありますが、今回はそれがなかったため、ログを出力する猶予もないままプロセスが終了した可能性を考えました。

後からこの対応を分解すると、四つの情報に分かれます。

確認項目
該当ジョブのログを確認する。

確認結果
ログが一切出力されていない。

次の判断
外部からの強制終了を疑う。

判断根拠
通常の異常終了なら何らかのログが残る可能性があり、今回はログを出力する前にプロセスが終了した可能性を考えた。

「ログがない」という事実から「外部からの強制終了を疑う」という判断へ移る間には、なぜそう考えたのかという判断根拠があります。

障害対応を一連の仕事として見ている間は一つの流れに見えても、次の担当者へ残そうとすると、それぞれ別の情報だったことが分かります。

確認結果によって、次に見る場所が変わっていた

今回の障害対応では、その後も確認結果を受けながら調査対象が変わっています。

実行時刻をさかのぼると、三つ前のジョブから約2時間の遅延が発生していましたが、そのジョブ自体は正常終了していたため、単純なエラーではなく、データ量やリソース競合、ロック待ちによって処理が長引いた可能性を考え、調査の軸を処理の「詰まり」へ移しています。

次にOSやアプリケーションのイベントログを確認したところ、異常を示すアラートはありませんでした。

アラートがないだけでハードウェアやOSの異常を完全に否定することはできませんが、今回の状況ではその可能性の優先度を下げ、日常的に行われているサーバー停止の仕組みへ確認先を移しました。

さらに調べると、サーバーは仮想基盤側から制御されており、基盤側の制御時刻とジョブ停止時刻が一致していたことから、実行中のジョブがサーバー停止処理へ巻き込まれたと分かりました。

経験者が多くの確認先を知っていたというだけではありません。

ログがないことで外部からの停止を疑い、正常終了しているのに遅延していたことで処理の詰まりへ目を向け、異常アラートがないことでHW／OS異常の優先度を下げる。最後に二つの時刻が一致したことで、基盤側の停止処理による巻き込みへたどり着いています。

次の確認先は最初から決まっていたのではなく、それぞれの結果を受けて変わっていました。

対応後に分解して、初めて見えたものがある

今回使用した判断基準マトリクスは、経験者が障害対応中に見ていた資料ではありません。

対応が終わった後、実際に何を確認して何が分かり、その結果としてどこへ調査を移したのかを振り返り、経験の浅いメンバーでも熟練者と同じように「アタリ」をつけやすくするため、確認項目、確認結果、次の判断、判断根拠へ分解した資料です。

対応していた本人にとっては、ログを見て実行時刻を確認し、イベントログから停止処理へ調査を進めるまでが一つの連続した仕事だったはずです。

作業記録だけを残せば、

ログを確認した。

実行時刻を確認した。

イベントログを確認した。

停止処理を確認した。

という記録になります。

最終的な障害記録には、

基盤側の停止処理に実行中ジョブが巻き込まれた。

という原因が残ります。

しかし、手順と最終原因の間にあった「なぜ次にそこを見たのか」は、意識して分けなければ記録から抜けます。

後から判断を分解したことで、経験者がどの確認結果を受け、どこで考え方を変えていたのかが見えるようになりました。

手順書と障害記録の間に残りにくいもの

手順書には、ログやアラート、実行時刻を確認するといった「何をするか」が残り、障害記録には、今回であれば基盤側の停止処理にジョブが巻き込まれたという最終的な結果が残ります。

どちらも必要な情報ですが、次の担当者が似た事象へ対応するとき、最終原因だけを知っていれば十分とは限りません。

「今回もログがないから、すぐに仮想基盤を見る」と覚えてしまえば、条件の違う障害でも同じ確認をすることになります。

次の仕事で使いたいのは、ログがないことでなぜ外部からの停止を疑ったのか、正常終了している遅延をなぜ処理の詰まりと結び付け、異常アラートがない結果からどの可能性の優先度を下げたのかという判断のつながりです。

この情報が残っていれば、次の担当者は過去の原因をそのまま当てはめるのではなく、今回の条件と比較しながら考えられます。

経験者の仕事を引き継ぐなら、手順と最終回答の間で判断がどう変わったのかも、会社が残す知識の対象になります。

AIに何を読ませるか。その前に、会社は何を残しているのか

社内GPTやRAGを検討すると、「どの文書を読ませるか」という話が出ます。

手順書や過去の障害記録、チケット、社内規程、業務文書を検索対象にし、関連する情報へ人が近づきやすくする。

ディーシステムでも、生成AIを活用した社内文書検索の仕組みを構築しています。

今回の障害対応を見ると、その前に会社として何を知識に残しているのかを確認する必要があります。

手順書に「該当ジョブのログを確認する」と残っていれば、AIはその手順を探して提示でき、過去の障害記録に最終原因が残っていれば、関連事例として見つけられる可能性があります。

一方で、ログがなかったため外部からの強制終了を疑ったことや、正常終了している遅延から処理の詰まりを疑ったこと、異常アラートがなかったためHW／OS異常の優先度を下げたことがどこにも残っていなければ、自社でなぜその調査先へ移ったのかを、会社の確定した知識として検索することはできません。

生成AIが、与えられた状況から似た仮説を作る可能性はあります。

この記事で扱いたいのはAIの推論能力ではなく、過去に自社で行われた判断を次の担当者にも組織の知識として使ってほしいなら、その判断が残っているかという問題です。

AIは、残っていない経験を自社の確定知識として復元できるとは限らない

生成AIは大量の記録を整理し、複数の情報を比較して共通するパターンを探したり、仮説を出したりできます。

だから、AIには判断できず、人間にしかできないという話ではありません。

ただ、ある経験者が過去の障害で、なぜその時点で調査先を変え、どの確認結果からある可能性の優先度を下げ、その環境固有のどの条件を見ていたのかが本人の頭の中にしかなく、記録にも残っていなければ、後から文書をAIへ渡すだけで、その判断を自社の確定知識として完全に再現できるとは限りません。

AIへ大量の資料を読ませる前にも、次の仕事で使いたい判断がどこにあるのかを見つけ、再利用できる形へ変えるという会社側の仕事が残ります。

すべての判断を文書化する必要はありません。

一度しか起こらない軽微な事象まで詳細な判断過程を残せば、記録する仕事そのものが増えるため、重大なインシデントや例外対応、調査方針を大きく変えた場面など、次の仕事で使う可能性が高い判断から残す方法も考えられます。

何を残すかも、知識を使う側の仕事から考える必要があります。

判断が残っていれば、過去の経験へ近づく時間を短くできる

次の担当者が、同じように「ログが一切出ていない」という状況に直面したとします。

過去の判断過程が残っていれば、RAGを利用した仕組みからログが出力されなかった過去事例を探し、そのとき外部からの強制終了を疑った理由が記録された資料へ近づく使い方が考えられます。

担当者は過去の結論をそのまま今回の原因として採用するのではなく、今回も同じ環境なのか、停止時刻は重なっているのか、通常の異常終了を示す別の記録はないのかを、過去の判断根拠と現在の条件を比べながら確認できます。

AIが「原因は外部強制終了です」と決める必要はありません。

過去の障害記録を一件ずつ探し、経験者へ「ログがない場合は何を確認しますか」と聞くところから始める代わりに、同じ組織で過去に行われた判断へ早く近づければ、現在の事象を比較する時間へ移れます。

AIが経験者になるのではなく、組織に残した経験者の判断へ人がたどり着く時間を短くする。

会社が判断を残していれば、AIやRAGはその知識を次の仕事へつなぐ入口になり得ます。

判断を残すことは、次の人が考え方を学ぶ材料にもなる

今回、判断基準マトリクスを作成した目的には、経験の浅いメンバーでも熟練者と同じように「アタリ」をつけやすくすることがありました。

最終原因だけを残せば、次の担当者は「この障害ではvSphere側を見る」という新しい手順として覚え、今回とは条件の違う障害でも同じ行動を取るかもしれません。

判断過程が残っていれば、何もログがないことをなぜ情報として扱い、正常終了しているという結果からなぜ単純な異常終了とは別の方向を見て、異常アラートがないことでどの可能性の優先度を下げたのかを、一つの流れとして追えます。

資料を読めば、誰でもすぐに熟練者と同じ判断ができるわけではなく、顧客環境やシステム構成を理解するには経験が必要ですし、障害ごとに条件も変わります。

それでも、最終原因だけを覚える場合と、過去の担当者がどの情報を見て考え方を変えたのかまで追える場合では、学べる内容が違います。

経験者が同じ説明を何度も口頭で繰り返さなくても、過去の判断過程を次の担当者が確認できる材料が増えます。

次の担当者が考え方を追える形で知識を残せば、人が学ぶ資料になり、AIから関連情報を探す際にも使いやすくなるため、AI向けのデータ整備と人材育成を完全に別の仕事として考えなくてもよい場合があります。

「ログを見る」の次に、何を残すのか

冒頭へ戻ります。

該当ジョブのログを確認する。

手順は残っていて、担当者もその通りに確認しましたが、ログはありませんでした。

ここで次の担当者が止まるのであれば、足りなかったのは手順の数だけではありません。

過去に同じような結果を見た担当者が何を疑い、どの可能性の優先度を下げ、なぜ次の調査先へ移ったのか。

会社がその考え方を次の仕事でも使いたいなら、判断が変わった場所まで知識として残す必要があります。

AIが社内知識を探す時間を短くできるのであれば、会社側には、次の人にも使ってほしい判断を残す仕事があります。

「ログを見る」の次に何を考えたのかまで残して初めて、過去の経験を次の仕事へ使いやすくなります。

経験者の判断を、次の仕事へ残すために

手順書や過去の障害記録を整備していても、経験者がどの結果を見て調査先を変えたのかまでは残っていないことがあります。

ディーシステムでは、IT運用の現場で行われている確認や切り分けを整理し、手順だけでは残りにくい判断過程を、次の担当者が使える知識へ変える取り組みを考えています。また、生成AIを活用した社内文書検索など、蓄積した知識へ人がたどり着きやすくする仕組みづくりにも取り組んでいます。

「経験者への依存を減らしたい」「手順書はあるが判断の引き継ぎが難しい」「社内AIへ何を参照させるべきか整理したい」といった課題があれば、現在の業務や知識の残し方からご相談ください。