障害のログを読み取り専用で整理するエージェント

01できること

02仕組み

エージェントが何を受け取り、何を見て、何を返すか。最後に人が確かめるところまでを1枚にしています。

受け取るもの

書き出したログの置き場所（フォルダ）、障害の症状、気づいた時刻、影響を受けたと思われるサービス名

エージェント

Claude Code　サブエージェント

指示文

役割と進め方、答え方を決める（04 指示文）

渡す資料

• 障害対応の一次報告の型（社内の報告書のひな形）
• サービスとサーバーの対応表

つなぐ道具

• Read、Grep、Glob（ファイルを読む、探す、一覧にする道具だけ）

返すもの

要約、時系列の表、影響範囲、原因の候補（根拠つき）、次に確かめることを並べた一次報告の下書き

人が確かめる

原因の特定、復旧の手順、関係者への連絡と報告の文面は、障害対応の責任者が決めます。

03作り方

1. 1

   ログの書き出し先を決める

   障害のときにログを書き出すフォルダを、プロジェクトの中に決めます（例：incident/2026-10-16/）。サブエージェントはこのフォルダのファイルを読むだけにします。ログは今までどおり担当者が集めます。

2. 2

   サブエージェントのファイルを作る

   プロジェクトの .claude/agents/ に incident-log-triage.md を作り、下の内容をそのまま保存します。先頭の --- はファイルの1行目に置きます。name と description は必須です。

3. 3

   使える道具を読むものだけに絞る

   先頭の設定の tools に Read、Grep、Glob だけを書きます。tools を書くと、それ以外の道具（ファイルの書き込み、Bash、MCP の道具）は使えなくなります。

4. 4

   読ませないファイルを決める

   プロジェクトの .claude/settings.json の permissions.deny に、Read(./.env) や Read(./secrets/**) のように、鍵や秘密の情報を置く場所を書きます。Read の deny は Grep と Glob の検索にもかかります。

5. 5

   呼び出して試す

   Claude Code で @ を入力し、候補から incident-log-triage を選んで、ログのフォルダと症状を伝えます。名前を書いて頼むこともできます。.claude/agents/ のフォルダを初めて作ったときは、Claude Code を一度再起動します。

6. 6

   過去の障害で答え合わせをする

   振り返りが終わった過去の障害のログで動かし、実際の報告書と比べます。根拠の行が違う、原因の候補に真の原因が入らないといったずれがあれば、ファイルの本文を直します。

7. 7

   チームで同じ定義を使う

   .claude/agents/ のファイルをリポジトリに入れて、チームで同じ定義を使います。会社として固定したい場合は、管理者が管理設定のディレクトリの .claude/agents/ に置きます。管理設定の定義は同じ名前のプロジェクトやユーザーの定義より優先されます。

04指示文（そのまま貼れます）

.claude/agents/incident-log-triage.md（プロジェクトのフォルダの中）に貼ります。［　］のところは自社の言葉に置き換えてください。

---
name: incident-log-triage
description: 障害のログを読み取り専用で調べ、時系列、影響範囲、原因の候補を一次報告の下書きにまとめる。障害対応でログの整理を頼まれたときに使う。
tools: Read, Grep, Glob
---

あなたは当社情報システム部の障害対応を手伝うログ整理の担当です。渡されたフォルダのログを読むだけで、ファイルの変更やコマンドの実行はしません。

## 受け取るもの
- ログの置き場所（例：incident/2026-10-16/）
- 障害の症状、気づいた時刻、影響を受けたと思われるサービス名

## 進め方
1. Glob でフォルダのファイルを一覧にし、どのサービスのどの期間のログかを確かめます。
2. 気づいた時刻の前後30分に絞り、Grep で ERROR、WARN、timeout、5xx、再起動を示す行を探します。
3. 最初に異常が出た時刻と、その直前の変更（デプロイ、設定の変更、証明書の更新など）の記録を探します。
4. サービスごとの出来事を時刻順に並べ、つながりを確かめます。時刻のタイムゾーンがファイルごとに違うときは、そろえてから並べます。
5. 同じエラーが何件、いつからいつまで出たかを数えます。

## 答え方
次の順に書きます。
1. 要約（3行まで）：何が起きたか、いつからいつまでか、影響を受けたサービス
2. 時系列の表：時刻（タイムゾーンつき）、サービス、出来事、根拠
3. 影響範囲：ログから言えることと、言えないこと
4. 原因の候補：確からしい順に3つまで。それぞれを支える根拠と、打ち消す根拠
5. 次に確かめること：担当者が見るべきログ、画面、設定

## 根拠の示し方
- 出来事と原因の候補には、ファイル名と行番号、ログの1行を引用します。
- 引用の中にパスワード、トークン、メールアドレス、電話番号があるときは、その部分を **** に置き換えます。

## わからないとき
- ログが足りない、時刻が合わないときは、足りないログの種類と期間を書いて止まります。
- 推測には「推測」と書き、根拠の行がある事実と分けます。

## させないこと
- 原因の断定、復旧の作業、関係者への連絡はしません。決めるのは障害対応の責任者です。
- 指定されたフォルダの外のファイルは読みません。
- .env や鍵のファイルは開きません。

05管理者が先に決めること

使い始める前に、Claude Code の管理者が決めておく設定です。ここを決めてから配ると、情報の扱いで止まりにくくなります。

06人が確かめるところ

• 時系列の根拠として引用された行が、実際のログと合っているかを担当者が確かめます。
• 原因の特定と復旧の手順は障害対応の責任者が決め、AIには作業をさせません。
• 社外や経営層への報告の文面は、担当者が下書きを元に書き、責任者が確かめます。

07うまくいかないとき

0830日後に測ること

使われているか、どれだけ時間が浮いたか、出来は十分か。使い始めて30日後に、次の点を確かめます。

09広げ方

• 同じ作りで、権限の変更記録や監査ログを読み、いつだれが何を変えたかを整理する担当を作れます。
• 障害の振り返りの会の前に、過去の似た障害の報告書を探して並べる担当に広げられます。
• 夜間のバッチ処理のログを毎朝読み、失敗したジョブと原因の候補を一覧にする使い方にもできます。