（※〔実装編〕からの続きです。）
〔実装編〕にて示した、各Conditionと対応するログレベルの一覧を再掲します。
Condition 終了ケース ログレベル（Log4j） 対応
担当
GREEN 成功終了／肯定的正常終了 INFO − YELLOW 失敗終了／否定的正常終了〔機能要件〕 WARN 業務 ORANGE 失敗終了／否定的正常終了〔非機能要件〕 WARN 業務 RED 異常終了〔外的要因〕 ERROR 基盤 BLACK 異常終了〔内的要因〕 FATAL 開発
ここで「対応担当」とは、ログ（の監視）に基づいた以下に示すような運用シナリオを想定して定めています。
＊
FATALとERRORは、品質保証・品質管理における「故障（failure）」の発生を直ちに意味する、ということを明確に表します。FATALは、プログラムコードの論理バグや永続化データの不整合検知を意味しています。FATALを検知したら直ちに開発チームを呼び出すべきです。ERRORは物理障害等を意味しています。ERRORを検知したら、まずは基盤チームに点検してもらうべきです。
失敗終了にWARNを割り当てています。（※ここでは“警告”の意味で割り当てている訳ではありません。単にLog4jの既定のログレベルを割り振ったため失敗終了＝WARNとなっています。）失敗終了は、処理の呼び出し側、ひいてはアプリケーションの利用者側の不手際を表します。よってWARNに対して直ちに為す必要のある運用対応は通常はありません。ただし、同種のWARNが頻発するような場合は、業務チームによる利用者の支援が必要かもしれません。
繰り返しになりますが、失敗終了そのものは“正常”の範囲であり、また、失敗終了は呼び出し側にエラーの要因を求めているため、WARNを検知しても通常は直ちに為すべき運用対応というものはありません。しかし、WARNの発生が一定頻度以上見られる場合、アプリケーション利用者に対するサービスレベルを損なわせる何かが潜在していることを示唆している可能性があります。
（例）「指定の商品は販売停止中である」という旨の失敗終了が頻発していたとします。これは、多くのユーザーが多くの頻度で、販売中だと思って操作していたら、操作の途中で突然それは販売停止だと言われる、という事態に遭遇している可能性があることを意味します。これはオペレーション上の非効率を生んでいたり、利用者の満足度を下げている可能性があります。この事態に対して、例えば下記のような手立てをとっておくべきでしょう。
a. そもそも販売停止中の商品に対する受発注操作が行えないようにUIを改修する。b. 当該商品をカタログ（商品一覧）から落とす。あるいは代替商品を案内する。
WARNの頻発が見られる場合は、なぜ呼び出し側はそのような失敗を何度も繰り返すのか？そこに何か利用のし難さが潜在しているのではないか？そういった観点でアプリケーションを見直してみるべきでしょう。何らか要改善点を見出せるかもしれません。
◆以上
（※〔ライブラリ実装編〕へ続きます。）
