第7章運用（ログ解析・障害報告・手順書）

この章で学ぶこと

システムの運用では、障害が起きたときこそ、正確な記録と報告が求められます。

ところが、慌ただしい中で作る報告書は、「推測」と「確認できた事実」が混ざりやすいものです。 AIに任せれば、もっともらしい文章に整えてくれますが、推測を事実のように書いてしまうことがあります。

この章では、運用の仕事を題材に、次の3つを練習します。

時系列の整理では、「事実」と「仮説」を分ける
根拠となるログの行を引用させ、人が確認できるようにする
同じ障害を、読み手（顧客・社内）に合わせて書き分ける

第1章の5要素（目的・入力・制約・出力形式・検証）は、この章でも使います。素材はすべて架空のログです。実務でログをAIに貼るときは、ユーザー名・IPアドレス・内部のサーバー名など、識別できる情報を伏せてください。

本コースは実務練習用の教材です。AIの出力は必ず人が検証してください。

このユースケースが起きる場面

Webサービスの障害対応、バックアップの失敗、システム更改の手順書づくり。運用担当者は、次のような場面で悩みます。

大量のログから、事象の流れを整理して報告する必要がある
原因が分かる前に、暫定の報告を求められる
顧客向けと社内向けで、書く内容を変えなければならない

AIは、ログの読み取りと整理に役立ちます。ただし、原因の断定を、AIに任せてはいけません。ログに書かれていない原因を、「おそらく〇〇」と決めてしまうと、再発防止の方向を誤ります。

プロンプト設計シート（再掲）

**目的**：誰に・何のために・何を作るか
**入力**：AIに渡す素材は何か（機密は伏せたか）
**制約**：やってはいけないこと・守るルール
**出力形式**：表・箇条書き・文字数など
**検証**：出力が正しいか、何と突き合わせるか

この章では、「制約」の中心が、「事実と仮説を分ける」「ログにないことは『ログからは不明』と書く」ことになります。「検証」では、根拠の行番号を出させて、人が元のログを見て確かめます。

実例：ログから、障害の報告書を作る

状況と素材

ある朝、Webサービスでログイン画面が、約20分間、使えなくなりました。運用担当のあなたは、原因の調査と報告を任されました。手元にあるログは、次のとおりです（行番号は、このコースで付けたものです）。

L1  08:50 INFO  deploy   deploy #1043 applied (changed: config/schedule.yml)
L2  09:05 INFO  batch    monthly_report started
L3  09:11 WARN  db       connection pool usage 70%
L4  09:14 WARN  db       connection pool usage 90%
L5  09:16 ERROR web-01   login request timeout (5000ms)
L6  09:17 ERROR db       connection pool exhausted (100/100)
L7  09:24 INFO  ops      restart web-01 (by operator)
L8  09:26 INFO  web-01   started
L9  09:27 WARN  db       connection pool usage 85%
L10 09:31 INFO  batch    monthly_report finished
L11 09:33 INFO  db       connection pool usage 20%
L12 09:35 INFO  web-01   login request normal (avg 320ms)

運用担当の同僚の話：「monthly_reportは、いつもは深夜2時に動くバッチのはずだけど」

悪い指示とその失敗

このログから障害報告書を書いて。

返ってくるのは、次のような文章です。

障害の原因は、データベースの接続数が上限に達したことです。バッチ処理のスケジュール設定ミスが原因であり、担当者の確認不足でした。再発防止策として、デプロイ時のレビューを強化します。

失敗が3つあります。

「スケジュール設定ミスが原因」と断定しているが、ログには設定の中身が書かれていない
「担当者の確認不足」という、ログに一切ない責任の所在が書かれている
どの行が根拠なのか分からず、人が確かめられない

改善したプロンプト

あなたは、システム運用の記録を整理する担当です。以下の「ログ」と「補足」から、社内向けの障害報告書のたたき台を作成してください。

**目的**
障害の経緯を、確認できた事実と、まだ確認できていない仮説に分けて、上長が把握できる状態にする。

**制約**
- 「事実」には、ログに書かれていることのみを書く。各記述の末尾に、根拠の行番号を付ける（例：［L2］）
- 原因は断定しない。「仮説」として、複数挙げてよい。各仮説に、支持する根拠の行と、まだ確認できていない点を書く
- ログに書かれていないこと（設定の内容、担当者の責任など）は、「ログからは不明」と書く
- 再発防止策は、原因が確定するまで、確定した対策としては書かない。「調査後に検討」とする

**出力形式**
1. 影響（いつからいつまで、何が使えなかったか）
2. 時系列（時刻／出来事／根拠の行）の表
3. 原因の仮説（仮説／根拠の行／未確認の点／確認方法）の表
4. 未確定の事項

**ログ**
（ここにログを貼る）

**補足**
（ここに、同僚の話を貼る。ログではない情報だと明記する）

AIの出力と、人が確認した点

影響：ログ上、09:16〜09:35の間、ログインリクエストにタイムアウトが発生［L5］。09:35に正常化［L12］。
仮説1：デプロイ#1043が、バッチの実行時刻を変え、日中にmonthly_reportが実行されてDBの接続を占有した。根拠：L1で設定変更、L2で09:05に実行、L3〜L6で接続数が上昇、L10でバッチ終了後にL11で低下。未確認：schedule.ymlの変更内容、バッチの通常の実行時刻（同僚の記憶のみ）。
仮説2：web-01の問題（接続の解放漏れなど）。根拠：L5でweb-01のタイムアウト。反対の材料：L7の再起動後も、L9で接続数が85%のまま。未確認：web-01の接続状況の詳細。
不明：schedule.ymlの変更内容、バッチが接続を使った量、L7の再起動の判断根拠

人が確認する点は、次のとおりです。

各記述の行番号が、実際のログと合っているか（L11がL10の後か、など）
仮説1の「通常は深夜2時」が、「同僚の記憶」と明記され、事実として扱われていないか
「担当者の責任」が、書かれていないか

根拠の行番号を付けさせると、AIが事実を書いているのか、想像で書いているのかが、すぐに見分けられます。

設計メモ：なぜこの書き方か

要素	実例での書き方	効いた理由
目的	「事実と仮説に分けて、上長が把握できる」	原因を断定する必要がなくなる
入力	ログ（行番号つき）と、補足（ログ以外の情報と明記）	情報の出どころが、区別できる
制約	「事実には行番号」「原因は断定しない」「ログにないことは『不明』」	推測を、事実と混ぜない仕組みを作った
出力形式	影響／時系列／仮説／未確定の4つ	報告に必要な項目を、漏れなく揃えられる
検証	行番号を辿って、元のログと突き合わせる	人が、数分で正誤を確かめられる

「担当者の責任」のような、ログにない評価を、AIが書き足すことがあります。 障害報告書は、責任を問う文書ではなく、原因を探る文書です。制約で、書かせないようにします。

練習問題

進め方は全問共通です。

素材を読み、プロンプト設計シートの5要素を自分で埋める（AIはまだ使わない）
埋めた内容をもとにプロンプトを書き、普段使うAIで実行する
出力をルーブリックで自己採点する
解説を開き、自分の設計と比べる

サンプルファイルのダウンロード

問1と問2で使う、架空のログやメモを、1つのZIPファイルにまとめました。

ch7-sample-logs.zip をダウンロード（約10KB）

ZIPを解凍すると、説明のREADME.txtと、8つのテキストファイルが入っています。ファイルの中身は、AIに添付するか、貼り付けて使います。実在の会社やシステムとは関係のない、架空のデータです。練習が終わったら、解凍したファイルは、削除してかまいません。

問1 複数サーバーのログから、異常を探して時系列の表にする

状況：Webサービスの3台のサーバー（web-01、web-02、api-01）のログが届きました。どれかで問題が起きたようですが、どのサーバーかは分かっていません。

成果物：異常があったサーバーの特定と、事実だけの時系列表（時刻／出来事／根拠のファイル名と行番号）。原因は書かない。

このサンプルは、章の冒頭の「サンプルファイルのダウンロード」のZIPに入っています。使うのは、web-01.txt（300行）、web-02.txt（300行）、api-01.txt（301行）の3つです。ファイルは、AIに添付するか、内容を貼り付けて渡します。

ログは、次のような形式です（api-01.txtの一部）。

2026-10-05 14:07:44 INFO  api-01  api    request /cart ok (110ms)
2026-10-05 14:08:31 ERROR api-01  api    /orders 500 NullPointerException (OrderService:88)
2026-10-05 14:10:05 INFO  api-01  ops    rollback release v2.4.1 -> v2.4.0 started

ルーブリック（自己採点）

異常があるファイルは api-01.txt だけで、web-01.txt と web-02.txt には「WARN・ERRORの行がない」と答えた（誤検知がない）
api-01.txt のエラー2件を、2件とも、ファイル名と行番号つきで抽出した
api-01.txt の末尾にあるリリースの行（14:03:12）を、時刻順の正しい位置（エラーより前）に置いた
ロールバックの開始と終了、その後の正常なリクエストを、行番号つきで記録した
「v2.4.1のリリースが原因」と断定していない（「リリースの後にエラーが発生した」という事実にとどめている）
AIが挙げた行番号が、実際のファイルの行と一致している（行番号が作られていない）
プロンプトに、「時刻順に並べ替える」「原因は書かない」「根拠のファイル名と行番号を付ける」と指示した

答え合わせ用：ログに仕込んだ異常の場所

AIが、正しく異常を見つけられたかを、次の行番号と突き合わせて確認します。ファイルの行数が多いので、異常は全体のごく一部です。

ファイル	行数	仕込んだ内容
web-01.txt	300行	異常なし（WARN・ERRORは0件）
web-02.txt	300行	異常なし（WARN・ERRORは0件）
api-01.txt	301行	93行目：ERROR（14:08:31）、95行目：ERROR（14:08:59）、99行目：ロールバック開始（14:10:05）、107行目：ロールバック終了（14:12:40）、108行目：終了後の最初の正常なリクエスト（14:12:43）、301行目：リリースの記録（14:03:12。ファイルの末尾にあり、時刻の順序が合っていない）

よくある失敗と解説

この問題の罠は3つです。

1つ目は、行数が多いログの、一部にだけ、異常があることです。 300行のうちの2行を見つけるには、全体を正しく読み取る必要があります。 AIが「異常なし」と答えたり、正常な行を異常と誤って挙げたりしていないか、答え合わせの行番号で確かめます。

2つ目は、301行目のリリースの記録が、ファイルの末尾に置かれていて、時刻順になっていないことです。「時刻順に並べ替えて」という指示を、明記します。

3つ目は、「リリースの直後にエラーが出た」を、「リリースが原因」と読み替えることです。時間が近いからといって、原因とは限りません。たしかに、v2.4.1を戻してから正常になっているので、疑わしいのは事実です。それでも、ログが示す事実は「リリースの後にエラーが発生し、ロールバックの後に正常になった」までです。制約に、「時間的に近い出来事を、原因と結びつけて書かない」と入れます。

このサンプルを、Claude Codeで試したところ、異常があるのはapi-01.txtだけだと特定し、エラーの93行目・95行目、ロールバックの99行目・107行目、末尾のリリース行の並べ替えまで、答えと一致しました。ただし、これはファイルを直接読めるツールで試した結果です。チャットに内容を貼り付ける場合は、AIが行を数え間違えることがあります。行番号は、エディタで行番号を表示して、必ず確かめてください。

実際の職場のログは、数万行になることもあります。その場合は、全体を貼る前に、期間やログのレベル（ERROR、WARN）で絞り込んでから渡すと、AIが扱いやすくなります。

問2 原因の仮説を、複数出させる

状況：夜間のバックアップが失敗しました。原因を調べるため、考えられる仮説を整理します。

成果物：仮説の表（仮説／支持する根拠のファイル名と行番号／反対の材料／追加で確認すること）。3つ以上。

次の5つのファイルを使います（同じZIPに入っています）。ログやメモが複数のファイルに分かれている、という実務に近い形です。

backup-nightly.txt：バックアップの実行ログ（20夜分、156行）
df-history.txt：ディスク使用量の記録（20行）
backup-list.txt：バックアップの保存先のファイル一覧（31行）
backup.conf：バックアップの設定ファイル（6行）
ops-notes.txt：運用担当者のメモ（3行）

ルーブリック（自己採点）

仮説が3つ以上あり、それぞれに「仮説」と明記されている
「設定は20世代なのに、実際は30世代ある」という食い違い（backup.conf と backup-list.txt）に、気づいている
「削除（clean）のログが、9月24日を最後に、出ていない」ことに気づいている
「設定ファイルの最終更新（9月25日）」と、「削除のログが止まった時期」が近いことを、事実として挙げているが、それだけで原因と断定していない
各仮説に、根拠のファイル名と行番号があり、その仮説に反する材料も書かれている
各仮説に、「これが確認できれば、仮説が否定または支持される」という、追加の確認事項がある
「原因は〇〇です」と、断定していない

答え合わせ用：ファイルに仕込んだ手がかり

ファイル	手がかり
backup-nightly.txt	155行目：ERROR（10/05 03:40「No space left on device」）、156行目：バックアップの中止。79〜80行目（9/24）が、削除（clean）のログの最後。9/25以降の夜には、削除のログがない
df-history.txt	1〜9行目（9/16〜9/24）は240GBのまま。10行目（9/25）から、毎日12GBずつ増え、19行目（10/04）で360GB（100%）。20行目（10/05）も100%
backup-list.txt	保存されているバックアップは30世代（9/5〜10/4）。すべて gen-日付の形式で、手動のコピーらしきファイルはない
backup.conf	5行目：保持世代数は20。2行目：最終更新は2026-09-25
ops-notes.txt	運用担当者のメモ（100%使用、30世代、設定は20世代）

よくある失敗と解説

このファイルから言える確実な事実は、「容量が足りず、バックアップが失敗した」ことです。「なぜ、30世代も溜まったのか」は、ファイルからは確定できません。

ただし、手がかりはあります。

削除のログは、9月24日を最後に、出ていない
保存されている世代の数は、9月25日から、毎日1つずつ増えている
設定ファイルの最終更新も、9月25日である

これらから、次のような仮説が考えられます。

古い世代を削除するジョブが、9月25日から、動いていない、または失敗している
9月25日の設定変更が、削除の動作に影響した
削除は動いているが、ログに出なくなっただけ（ただし、世代数が増えているので、この仮説は弱い）
手動でコピーしたバックアップが、混ざっている（ただし、backup-list.txtは、すべて自動の形式なので、この仮説に反する材料がある）

どれが正しいかは、ファイルからは決められません。「設定ファイルの更新と、削除ログが止まった時期が近い」のは事実ですが、時期が近いことは、原因の証拠ではありません。確かめるには、設定の変更内容の履歴や、削除のジョブの実行状況の確認が必要です。

そのため、AIには「仮説を挙げさせ、各仮説について、追加で確認すべきことを一緒に出させる」のが、有効な使い方です。

制約の例です。

**制約**
- 仮説は、最低3つ挙げる
- 各仮説について、支持する根拠（ファイル名と行番号）と、その仮説に反する材料を書く
- 各仮説を確かめるために、次に何を調べるかを書く
- どれが正しいかは判断しない

「反する材料」を出させると、AIが、都合のよい根拠だけを並べることを、防げます。複数のファイルに情報が分かれているときは、「どのファイルの何行目か」を必ず付けさせて、人が確かめられる形にします。

問3 顧客向けと社内向けに、報告書を書き分ける

状況：問1の障害について、顧客向けのお知らせと、社内向けの報告書の両方が必要です。

成果物：顧客向けのお知らせ（200字程度）と、社内向けの報告のたたき台。

【ログ】問1の api-01.txt（エラーは93行目・95行目、ロールバックは99行目〜107行目、リリースの記録は301行目）

【追加の情報】
- 影響：注文画面のエラー応答は、ログ上2件（14:08台）。ロールバック（14:10〜14:12）の後は正常
- 原因は調査中。v2.4.1に含まれる変更のどれが影響したかは未確認
- 顧客向けの案内では、内部のバージョン名やクラス名（OrderService等）は出さない

ルーブリック（自己採点）

顧客向けのお知らせに、内部のバージョン名・クラス名が含まれていない
顧客向けのお知らせが、「いつ」「何が起きたか」「現在の状況」「調査中であること」を含んでいる
顧客向けのお知らせで、原因を断定していない（「調査中」と書かれている）
社内向けの報告に、時系列と、ログの行番号が含まれている
顧客向けが200字程度に収まっている（実際に数えた）

よくある失敗と解説

同じ事実でも、読み手によって、書くべき内容が変わります。

項目	顧客向け	社内向け
目的	影響と現状を、正確に伝える	経緯の把握と、次の調査の判断
内部の名前	出さない	出す（バージョン・クラス名など）
原因	断定しない。調査中と書く	仮説として整理し、未確認の点を書く
行番号	不要	根拠として付ける

顧客向けの文章で、AIが陥りやすい失敗は、安心させるために、確認していない情報を書くことです。「すでに原因は解消しており、再発の恐れはありません」のような、断定的な一文は、調査中の段階では、書けません。

制約に、「確認できている事実のみを書く」「『再発しない』『原因は解消』などの断定は、書かない」と入れます。顧客向けの文は、社内向けの報告書を、先に作ってから、そこから書き起こすほうが、事実がぶれません。

問4 手順書の抜けを見抜く

状況：バックアップからの復元手順のメモを、AIに整えさせた手順書が、届きました。チェックを頼まれています。

成果物：手順書の抜けの指摘リストと、AIに補わせるためのプロンプト。

元のメモ：

【バックアップからの復元（社内メモ）】
- 作業は夜間にやる
- 先にサービスを止める（web-01, web-02）
- /backup から最新の世代を選んで復元コマンドを実行
- 終わったらサービスを起動して動作確認
- 失敗したらDBチームに連絡

AIが作った手順書：

1. サービス（web-01, web-02）を停止する
2. 最新のバックアップを復元する
3. サービスを起動する
4. 動作確認を行う

ルーブリック（自己採点）

「夜間に行う」という条件が、手順書から抜けていることを指摘できた
「失敗したらDBチームに連絡」が、手順書から抜けていることを指摘できた
「復元コマンドの具体的な内容」が、メモにもないので、手順書に書けないことに気づいた（「要確認」とすべき）
「何が確認できれば、動作確認が成功か」の基準が、ないことを指摘できた
「復元前に、現在のデータを退避する」「停止の確認」など、メモにない手順は、AIに勝手に足させず、「要確認の項目」として挙げさせる設計にした

よくある失敗と解説

手順書の抜けには、2種類があります。

1つ目は、メモにあったのに、消えてしまった情報です。今回でいえば、「夜間に実施」「失敗したらDBチームに連絡」です。整えようとして、AIが削ってしまいました。

2つ目は、メモにもなく、手順書には必要な情報です。復元コマンドの内容、動作確認の成功基準、失敗時の戻し方などが該当します。

注意したいのは、2つ目を、AIが勝手に埋めることです。それらしい復元コマンドを書くと、実行された場合に、データを破壊する恐れがあります。

依頼の型は、次のとおりです。

以下のメモから、復元手順書を作ってください。

**制約**
- メモに書かれている内容は、1つも削らない
- メモにない具体的なコマンド・数値・連絡先は、書かない。必要な箇所には「【要確認：〇〇】」と書く
- 各手順に、「確認すること（何が確認できたら次へ進むか）」の欄を設ける
- 手順の最後に、「失敗した場合の対応」を書く（メモにある内容のみ）

**出力形式**
手順ごとに、番号・作業内容・確認すること の表。最後に「要確認の項目」の一覧

手順書は、実行する人が、書かれたとおりに動く文書です。 AIが作った手順書は、必ず、テスト環境で、一度通して試してください。

プロンプト設計の確認問題

ここまでの内容を、選択式で確認しましょう。

問1. 障害報告書のたたき台をAIに作らせるとき、各記述に「根拠となるログの行番号」を付けさせる主な目的として、最も適切なものはどれか。

問2. ログに「デプロイ直後にエラーが増え、ロールバック後に正常になった」という経過が残っていた。報告書での書き方として最も適切なものはどれか。

問3. 同じ障害について、顧客向けのお知らせを作るときの注意として、最も適切なものはどれか。

問4. 復元手順のメモをAIに手順書へ整えさせるとき、メモにない具体的なコマンドや数値の扱いとして、最も適切なものはどれか。

繰り返し使う制約は、AIに登録して短くする

この章のプロンプトは、制約を毎回書き込む形で練習しました。同じ業務を繰り返すなら、変わらない制約は、AIにあらかじめ登録しておくことで、依頼を短くできます。

この章で登録しておくとよいのは、「事実と仮説を分ける」「根拠の行番号を付ける」「ログにないことは不明と書く」という制約と、顧客向け・社内向けの書き分けです。 ChatGPT・Claude・Geminiでの登録手順は、生成AIに社内ルールを覚えさせるスキル設定のやり方で解説しています。登録しても、最終確認は人が行うことに変わりはありません。

自分の職場に置き換える

この章の型を、自分の仕事に当てはめます。

最近あったトラブル、または手順書にしたい作業を1つ選ぶ
ログや記録を使う場合は、氏名・IPアドレス・社内の固有名詞を、伏せ字にする。使わない場合は、架空の記録を作る
「事実」と「仮説」を分ける制約を入れ、根拠の行番号を付けさせる
出力された記述の行番号を、元のログで確かめ、事実と仮説が混ざっていないかを見る

仕上げに、S.E.L.F.ループの「F（Forge it）」として、AIに「この報告書で、断定してはいけないのに断定している箇所」を探させ、自分の見落としがないかを確かめます。

この章のまとめ

運用の記録では、「事実」と「仮説」を分け、事実には根拠の行番号を付けさせる
ログにない情報（設定の中身・責任の所在）は、「ログからは不明」と書かせる
時間的に近い出来事を、原因と決めつけない。原因は、仮説として、反する材料も出させる
顧客向けと社内向けは、目的が違う。内部の名前・原因の断定の扱いを書き分ける
手順書は、メモの情報を削らせず、メモにない具体的な値は、「要確認」とさせる

次の章では、これまでの7章の型を使い、繰り返しの業務を、複数の工程にして仕組みにする練習をします。