前回の続き——運用の第一歩は「観測」
前回のS-01では、開発と運用を区別し、運用の3責務が安全・安定・適正費用の継続提供であることを確認しました。その運用の第一歩は、アプリの中で何が起きているかを見る観測です。観測が無ければ、S-01で見たように、止まっていることにも気づけません。この講義では、観測のいちばん基本の道具であるログを扱います。
このスライドのポイント
- S-01: 開発と運用を区別し、運用の3責務＝安全・安定・適正費用の継続提供を確認した
- 運用の第一歩は「アプリの中で何が起きているかを見る」観測
- 観測が無ければ、S-01で見たとおり障害に気づけない
- この講義は観測の最も基本の道具、ログを扱う
構造化ログとログレベル
運用で使うログは、調査に耐える形が必要です。第一に構造化ログ。これは文章ではなく、時刻やレベルといった項目の決まった形式で書くログで、K-04で学んだJSONの形にすると、機械で検索や集計ができます。第二にログレベル。これは記録の重要度を段階で表すもので、失敗を示すERROR、注意が必要なWARN、通常の記録であるINFOの3つを使い分けます。J-08でログを書く、P-09でログを読むを学びましたが、ここではその設計と運用の決め方に進みます。
このスライドのポイント
- 構造化ログ＝文章でなく、項目の決まった形式で書くログ（K-04のJSON形式にすると機械で検索・集計できる）
- ログレベル＝記録の重要度の段階
なぜ必要か——形が悪いと調査に使えない
ログがあっても、形が悪いと調査に使えません。自由文で書かれたログは、grepで探しても目当ての1行が見つからず、時間だけがかかります。またレベルを設計していないと、本当のERRORが日常のノイズに埋もれてしまいます。こうなると、P-10で学んだ障害の切り分けを、いざというときに始められません。ログがあることと、調査に使えることは別なのです。
このスライドのポイント
- 自由文のログ: grepで探しても目当ての1行が見つからない
- レベル設計なし: 本物のERRORが日常のノイズに埋もれる
- どちらも、いざというときP-10の障害切り分けを始められない
- 「ログはある」と「調査に使える」は別
構造——2つの対比とレベルの使い分け
ログの設計は、2つの対比で捉えます。1つ目は、自由文ログと構造化ログの対比です。自由文は人には読めても機械では絞り込めず、構造化なら項目ごとに検索できます。2つ目は、レベル3段の使い分けです。ERRORは人の対応が要る失敗、WARNは要注意の兆候、INFOは通常の記録です。運用ではERRORだけを通知の対象にし、これは次回S-05の監視への伏線になります。INFOは通知せず、後の調査用に保存しておきます。
このスライドのポイント
- 対比1: 自由文ログ（人には読めるが絞り込めない）vs 構造化ログ（項目で検索できる）
- 対比2: レベル3段の使い分け
具体例——「先週金曜の障害」を調べる
経費アプリで、先週金曜の障害を調べる場面を考えます。構造化ログがあれば、時刻の範囲と、レベルがERROR、対象が申請APIという3つの条件で、該当する記録を数秒で絞り込めます。自由文のログでは、この絞り込みができません。ここで大切な注意が2つあります。個人情報をログに書かないこと、これはQ-09で学んだ守りです。もう1つ、認証情報であるAuthorizationヘッダーを書かないこと、これはD-07で確認したとおりです。調査のために記録を増やすほど、この2つの再確認が必要になります。
このスライドのポイント
- 経費アプリ（社内50人・公開済み）で先週金曜の障害を調査
- 構造化ログなら「時刻範囲 × レベルERROR × 申請API」で数秒で絞れる
- 自由文ではこの絞り込みができない
- 注意（再確認）: 個人情報をログに書かない（Q-09）／Authorizationを書かない（D-07）
技術サンプルカード——構造化ログの3行
サンプルは構造化ログの3行です。いずれもtime、level、route、messageという同じ項目で揃えてあり、末尾のrequest_idはここではダミーの値を入れています。読み方の要点は2つです。項目が揃っているから、レベルやrouteで機械的に絞り込めること。そしてrequest_idは、同じ1回のリクエストに同じIDを刻んでおくための鍵で、次回S-04のトレースで追跡に使います。AIには、このアプリのログを構造化形式に統一し、何をERRORにするかの基準を提案してください、と頼めます。
混同しやすい——ERROR と WARN/INFO（狼少年ログ）
混同しやすいのは、ERRORと、WARNやINFOの区別です。ERRORは人がいま対応すべき失敗、WARNとINFOは記録に留めるものです。ここで陥りがちなのが、心配だからと何でもERRORにしてしまうことです。すると本物の緊急がERRORの山に埋もれ、やがて誰もERRORを見なくなります。これを狼少年ログと呼びます。嘘の警報を出し続けると、本当の警報が信じてもらえなくなる、という失敗です。レベルは、対応の要否で厳しく分けてください。
このスライドのポイント
- ERROR（人がいま対応すべき失敗）vs WARN/INFO（記録に留める）
- 心配だからと何でもERRORにすると、本物の緊急が埋もれる
- これが「狼少年ログ」——嘘の警報を出し続けると本当の警報が信じられなくなる
- レベルは「対応の要否」で厳しく分ける
バイブコーディングでの確認点——ログの秘密監査
確認点です。ログを増やすときは、AIに、個人情報や秘密情報がログに出力される箇所はないかを監査させてください。これはQ章で学んだ安全の考え方を、運用に持ち込む作業です。氏名やメールアドレス、経費の金額、そしてD-07のAuthorizationのような認証情報が、messageに紛れ込んでいないかを点検します。質問例は、このコードのログ出力の中に、個人情報や認証情報が含まれる箇所を挙げてください、です。
このスライドのポイント
- ログを増やすときは、AIに「個人情報・秘密情報がログに出力される箇所はないか」を監査させる
- Q章で学んだ安全の考え方を、運用に持ち込む作業
- 点検対象: 氏名・メール・経費の金額、そしてD-07のAuthorizationのような認証情報
- 質問例:「このコードのログ出力の中に、個人情報や認証情報が含まれる箇所を挙げてください」
一問一答とまとめ
一問一答です。機械で検索や集計ができるログの形式は何でしょうか。（間）答えは、構造化ログです。項目の決まった形式で書くことで、条件を指定した絞り込みができます。30秒まとめです。運用のログは、構造化ログで項目を揃え、ERROR・WARN・INFOのレベルを対応の要否で使い分け、個人情報と秘密情報は書かない。この3点が、ログを観測装置へ格上げする型です。次回S-03では、出来事の記録であるログに対して、数の傾向を見るメトリクスへ進みます。関連資料は、ログ設計入門と、監査ログと変更履歴入門です。
このスライドのポイント
- 一問一答:「機械で検索・集計できるログの形式は？」→ 構造化ログ
- 30秒まとめ: ①構造化ログで項目を揃える ②ERROR/WARN/INFOを対応の要否で分ける ③個人情報・秘密情報は書かない
- 次回S-03: 出来事の記録（ログ）に対し、数の傾向を見るメトリクスへ
- 関連資料:「ログ設計入門」「監査ログと変更履歴入門」
