障害対応の初動をAIで加速する

はじめに

深夜のアラート通知。サービスダウンの連絡。インフラエンジニアにとって障害対応の初動は、原因特定までの時間がそのまま復旧時間に直結します。

初動で最も時間がかかるのが「ログの読み解き」です。大量のログの中からエラー行を探し、関連するメッセージを前後で追い、原因を推測する。経験が浅いうちは、どのログを見ればよいかの判断すら難しく、初動に30分以上かかることも珍しくありません。

この作業にAIを活用すると、初動の時間を短縮できます。ログをAIに渡して分析させることで、原因候補の絞り込みと対処手順の提示を数十秒で得られます。ただし、AIの出力は必ず人間が検証する必要があります。AIは「もっともらしい誤り」（ハルシネーション）を出力することがあり、鵜呑みにすると誤った対応につながります。

ログ解析に特化したプロンプトの設計方法と、3つの障害シナリオでの実践例を取り上げます。前シリーズ①で解説したプロンプトの6構成要素を、ログ解析という具体的な用途に適用する内容です。

この記事を読むと、以下の3つができるようになります。

1. ログ解析に適したプロンプトの4要素（役割・状況・ログ・出力形式）を組み立てられる
2. 機密情報をマスキングしてから安全にAIへログを送信できる
3. AIの分析結果を検証し、障害対応の初動に組み込む判断ができる

前提条件

この記事は、以下の前提知識を持つ方を対象としています。

• 前シリーズ①のプロンプト設計の基礎知識（6構成要素の理解）
• Linuxのコマンドライン操作ができる（journalctl（systemdのログ管理コマンド）、grep、sed等の基本操作）
• systemdによるサービス管理の基本を理解している

検証環境

記事中のプロンプト例はすべてClaude Sonnet 4.6で動作確認しています。ChatGPTなど他のモデルでも基本的な考え方は共通ですが、XMLタグによる構造化はClaude固有の強みであるため、他モデルでは効果が異なる場合があります。

• コマンドはroot権限またはsudo権限で実行する前提です
• SELinuxはデフォルトのenforcing状態を想定しています
• nginx/httpdは dnf install でインストール済みの前提です
• /var/log/secure はrsyslogがインストールされている環境で存在します。minimal環境では dnf install rsyslog が必要な場合があります

ログをAIに渡す際の注意点

障害シナリオの実践に入る前に、ログをAIに送信する際の注意点を3つ確認します。この内容はすべてのシナリオに共通する基盤です。

機密情報のマスキング

業務ログには、IPアドレス、ホスト名、ユーザー名など、組織の内部情報が含まれています。これらを外部のAIサービスにそのまま送信すると、情報漏洩のリスクがあります。

日本でもAI関連の法整備やガイドライン策定が進んでいます。総務省・経済産業省の「AI事業者ガイドライン」などで、AI利用時のデータ取り扱いに関する指針が示されています。所属組織のセキュリティポリシーを必ず確認してください。

以下のsedコマンドでマスキングを行います。

# ネットワーク部を残し、ホスト部をマスキング
sed -E 's/([0-9]{1,3}\.[0-9]{1,3})\.[0-9]{1,3}\.[0-9]{1,3}/\1.xxx.xxx/g' /var/log/secure > masked_secure.log

# IPv6アドレスのマスキング
sed -E 's/[0-9a-fA-F:]{2,39}/[IPv6_MASKED]/g'

sed 's/server-[a-z0-9]*/server-MASKED/g' masked_secure.log > masked_secure2.log

sed 's/user=tanaka/user=USER_A/g; s/user=suzuki/user=USER_B/g' masked_secure2.log > masked_final.log

マスキング後のログでも、エラーの種類やタイムスタンプは保持されるため、AIによる原因分析には十分な情報が残ります。

ログサイズの制限

ログの抽出には、journalctl（systemdのログ管理コマンド）のフィルタオプションが有効です。

# 特定のサービスの直近5分間のエラーログを抽出
journalctl -u nginx.service --since "5 min ago" -p err --no-pager

# 優先度warning以上のログを時間帯指定で抽出
journalctl -p warning --since "2026-03-13 03:00" --until "2026-03-13 03:30" --no-pager

# JSON形式で出力（AIが構造を解析しやすい）
journalctl -u sshd.service -p err --since "1 hour ago" -o json-pretty --no-pager

journalctl -xeu の各オプションの意味は以下のとおりです。

• -x: カタログから補足説明を表示する
• -e: ログの末尾から表示する
• -u: 指定したユニット（サービス）のログに絞り込む

AIに渡すログは、50〜200行程度に絞るのが実用的です。それ以上の量が必要な場合は、複数回に分けて送信するか、時間帯・優先度・ユニットで段階的にフィルタします。

ハルシネーション対策

ハルシネーションを抑制するために、プロンプトに以下の制約を含めます。

• ログの行番号・タイムスタンプを引用させる ― AIが根拠を示すことで、人間が検証しやすくなる
• 「不明な場合は『不明』と回答する」を明示する ― 無理に推測させない
• 原因候補に確度（高・中・低）を付与させる ― AIの確信度を可視化する

これらの制約は、後述するプロンプトテンプレートにすべて組み込んでいます。

ログ解析プロンプトの設計

前シリーズ①の6要素からログ解析4要素への再編成

前シリーズ①で解説した6構成要素（役割・タスク・制約・コンテキスト・出力形式・例）のうち、ログ解析では以下の4要素が核となります。

6要素との対応関係は以下のとおりです。

• 役割 → 前シリーズ①の「役割」と同じ
• 状況 → 前シリーズ①の「コンテキスト」＋「タスク」を統合。障害対応では「何が起きているか」と「何をしてほしいか」が密接に結びつくため
• ログ → 前シリーズ①の「例」に相当するが、ログ解析では分析対象そのものとして独立した要素になる
• 出力形式 → 前シリーズ①の「出力形式」＋「制約」を統合。ハルシネーション対策の制約も出力形式の中で指定する

Before/After: プロンプトの改善例

ログ解析でよくある「悪いプロンプト」と「改善したプロンプト」を比較します。

問題: ログをそのまま貼り付けて「原因を教えて」と聞いても、AIは漠然とした回答しか返せません。

以下のログの原因を教えてください。

[2026-03-13 03:14:22] ERROR connection refused to 192.168.1.50:3306
[2026-03-13 03:14:23] WARN connection pool exhausted
[2026-03-13 03:14:24] ERROR upstream timeout

このプロンプトの問題点は4つあります。

1. AIの役割が指定されていない（どの視点で分析すべきか不明）
2. 障害の状況（いつから、何が起きているか）が不明
3. 出力形式が未指定のため、散文的な回答になる
4. IPアドレスがマスキングされていない

<role>
あなたはLinuxサーバーの障害対応エンジニアです。
nginx + MySQL構成のWebアプリケーション基盤を担当しています。
</role>

<situation>
2026年3月13日 03:14頃から、Webアプリケーションで502 Bad Gatewayが
断続的に発生しています。直前にデプロイや設定変更は行っていません。
</situation>

<log>
[2026-03-13 03:14:22] ERROR connection refused to xxx.xxx.xxx.xxx:3306
[2026-03-13 03:14:23] WARN connection pool exhausted
[2026-03-13 03:14:24] ERROR upstream timeout
[2026-03-13 03:14:25] INFO retry attempt 3/5
[2026-03-13 03:14:26] ERROR 502 Bad Gateway returned to client
</log>

<output_format>
以下の形式で分析結果を出力してください:
1. 原因候補（確信度: 高/中/低 を付記、最大3つ）
2. 各候補の根拠（ログのどの行が根拠か引用）
3. 推奨対応（優先度順に列挙）
4. 追加で確認すべきログやコマンド
不明な点がある場合は「不明」と回答してください。推測で断定しないでください。
</output_format>

改善のポイント:

• 4要素（役割・状況・ログ・出力形式）をXMLタグで構造化した
• IPアドレスをマスキングした
• 確信度の付与と根拠の引用を求め、ハルシネーション対策を組み込んだ
• 「不明な場合は不明と回答」の制約を明示した

プロンプトテンプレート

以下は、あらゆるログ解析に使い回せるテンプレートです。

<role>
あなたは【OS名】サーバーの障害対応エンジニアです。
【ミドルウェア構成（例: nginx + MySQL）】の運用を担当しています。
</role>

<situation>
【発生日時】から、【症状（例: 502エラーが断続的に発生）】が発生しています。
直前の変更: 【デプロイ・設定変更の有無と内容】
影響範囲: 【影響を受けているサービスやユーザー数】
</situation>

<log>
【マスキング済みのログをここに貼り付け】
</log>

<output_format>
以下の形式で分析結果を出力してください:
1. 障害概要（1〜2文で簡潔に）
2. 原因候補（確信度: 高/中/低 を付記、最大3つ）
   - 各候補の根拠（ログのどの行・タイムスタンプが根拠か引用）
3. 推奨対応（優先度順に列挙、各項目に実行コマンドを含む）
4. 追加で確認すべきログやコマンド
5. 再発防止策

不明な点がある場合は「不明」と回答してください。推測で断定しないでください。
根拠はログのタイムスタンプを引用して示してください。
</output_format>

実践: 3つの障害シナリオ

ここからは、3つの典型的な障害シナリオで実際にプロンプトを組み立て、AIの期待出力例と人間が検証すべきポイントをセットで示します。

各シナリオのログは検証環境（AlmaLinux 10）で実際に発生させたものです。AIに送信する前に、前述のマスキング処理を行ってください。

シナリオA: systemdサービス起動失敗（nginx）

状況: nginxが起動しない。systemctl start nginx を実行するとエラーになる。

ログ取得コマンド:

systemctl status nginx.service
journalctl -xeu nginx.service --no-pager

ケース1: ポート競合

取得されたログ（マスキング済み）:

Mar 13 03:14:22 server-MASKED nginx[12345]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 13 03:14:22 server-MASKED systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE
Mar 13 03:14:22 server-MASKED systemd[1]: nginx.service: Failed with result 'exit-code'.
Mar 13 03:14:22 server-MASKED systemd[1]: Failed to start The nginx HTTP and reverse proxy server.

プロンプト例:

<role>
あなたはAlmaLinux 10サーバーの障害対応エンジニアです。
nginx Webサーバーの運用を担当しています。
</role>

<situation>
2026年3月13日 03:14頃、nginxが起動しません。
systemctl start nginx を実行するとエラーで終了します。
直前の変更: 特になし（定期再起動の際に発生）
影響範囲: Webサイト全体がダウン
</situation>

<log>
Mar 13 03:14:22 server-MASKED nginx[12345]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 13 03:14:22 server-MASKED systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE
Mar 13 03:14:22 server-MASKED systemd[1]: nginx.service: Failed with result 'exit-code'.
Mar 13 03:14:22 server-MASKED systemd[1]: Failed to start The nginx HTTP and reverse proxy server.
</log>

<output_format>
以下の形式で分析結果を出力してください:
1. 障害概要（1〜2文で簡潔に）
2. 原因候補（確信度: 高/中/低 を付記、最大3つ）
   - 各候補の根拠（ログのどの行が根拠か引用）
3. 推奨対応（優先度順に列挙、各項目に実行コマンドを含む）
4. 追加で確認すべきログやコマンド

不明な点がある場合は「不明」と回答してください。推測で断定しないでください。
</output_format>

AIの期待出力例:

1. 障害概要
nginxがポート80のバインドに失敗し、起動できない状態です。ポート80が他のプロセスに占有されています。

2. 原因候補

• 候補1（確信度: 高） ― ポート80が別プロセスに占有されている
• 候補2（確信度: 中） ― 前回のnginxプロセスが正常終了しておらず、ゾンビプロセスが残っている
• 候補3（確信度: 低） ― Apache httpd等の別Webサーバーがポート80で起動している

3. 推奨対応（優先度順）

1. ポート80を使用しているプロセスを確認する：
   ss -tlnp | grep :80
2. 該当プロセスを特定し、停止するか設定を変更する
3. nginxを再起動する：
   systemctl start nginx
systemctl status nginx

4. 追加で確認すべきコマンド
nginx -t（設定ファイルの構文チェック）
ps aux | grep nginx（nginx関連プロセスの確認）

人間が検証すべきポイント:

• ss -tlnp | grep :80 を実際に実行し、ポート80を占有しているプロセスが存在するか確認する
• AIが挙げた「ゾンビプロセス」や「別Webサーバー」は、実環境に該当するか判断する
• ポート占有プロセスを停止する前に、そのプロセスが別のサービスとして必要でないか確認する

ケース2: 設定ファイルエラー

取得されたログ（マスキング済み）:

Mar 13 03:20:10 server-MASKED nginx[12346]: nginx: [emerg] unknown directive "server_nama" in /etc/nginx/nginx.conf:42
Mar 13 03:20:10 server-MASKED nginx[12346]: nginx: configuration file /etc/nginx/nginx.conf test failed
Mar 13 03:20:10 server-MASKED systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE
Mar 13 03:20:10 server-MASKED systemd[1]: Failed to start The nginx HTTP and reverse proxy server.

プロンプト例:

<role>
あなたはAlmaLinux 10サーバーの障害対応エンジニアです。
</role>

<situation>
2026年3月13日 03:20頃、nginxが起動しません。
設定ファイルを編集した直後に発生しました。
</situation>

<log>
Mar 13 03:20:10 server-MASKED nginx[12346]: nginx: [emerg] unknown directive "server_nama" in /etc/nginx/nginx.conf:42
Mar 13 03:20:10 server-MASKED nginx[12346]: nginx: configuration file /etc/nginx/nginx.conf test failed
Mar 13 03:20:10 server-MASKED systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE
Mar 13 03:20:10 server-MASKED systemd[1]: Failed to start The nginx HTTP and reverse proxy server.
</log>

<output_format>
以下の形式で分析結果を出力してください:
1. 障害概要
2. 原因候補（確信度付き、最大3つ、根拠ログ引用）
3. 推奨対応（実行コマンド付き）
4. 追加確認事項
不明な点は「不明」と回答してください。
</output_format>

AIの期待出力例:

1. 障害概要
nginx.confの42行目にタイプミス（server_nama）があり、設定ファイルのテストに失敗してnginxが起動できない状態です。

2. 原因候補

• 候補1（確信度: 高） ― server_name ディレクティブのタイプミス（server_nama）

3. 推奨対応

1. 設定ファイルの42行目を修正する（42行目の “server_nama” を “server_name” に修正）：
   vi /etc/nginx/nginx.conf
2. 構文チェックを実行する：
   nginx -t
3. nginxを起動する：
   systemctl start nginx
systemctl status nginx

人間が検証すべきポイント:

• /etc/nginx/nginx.conf の42行目を実際に開き、AIが指摘したタイプミスが存在するか確認する
• nginx -t で修正後の構文チェックを必ず実行する
• 設定変更前にバックアップを取得する（cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak）

シナリオB: SSH接続拒否

状況: クライアントからSSH接続ができない。Connection refused が表示される。

SSH接続拒否の原因は多岐にわたります。ここでは代表的な3パターンを取り上げます。

ログ取得コマンド:

# サーバー側のSSH関連ログ
journalctl -u sshd.service --since "30 min ago" --no-pager

# セキュリティログ（認証関連）
tail -100 /var/log/secure

ケース1: firewalldによるブロック

firewalldがSSHポートをブロックしている場合、サーバー側にログが残らないことがあります（パケットがdropされるため）。クライアント側では Connection refused または Connection timed out が表示されます。

プロンプト例:

<role>
あなたはAlmaLinux 10サーバーの障害対応エンジニアです。
firewalldとSELinuxが有効な環境を運用しています。
</role>

<situation>
2026年3月13日 10:00頃から、クライアント（xxx.xxx.xxx.xxx）から
SSHでサーバーに接続できません。クライアント側で「Connection refused」が
表示されます。サーバー側のjournalctl -u sshd にはこの時間帯のログが
ありません。sshdプロセスは起動しています。
</situation>

<log>
（サーバー側のSSHログにこの時間帯のエントリなし）

firewall-cmd --list-all の出力:
public (active)
  target: default
  services: cockpit dhcpv6-client
  ports:
  protocols:
</log>

<output_format>
以下の形式で分析結果を出力してください:
1. 障害概要
2. 原因候補（確信度付き、最大3つ、根拠引用）
3. 推奨対応（実行コマンド付き）
4. 追加確認事項
不明な点は「不明」と回答してください。
</output_format>

AIの期待出力例:

1. 障害概要
firewalldの許可サービスにSSHが含まれていないため、SSH接続がファイアウォールでブロックされています。

2. 原因候補

• 候補1（確信度: 高） ― firewalldでSSHが許可されていない

3. 推奨対応

1. SSHサービスをfirewalldに追加する：
   firewall-cmd --add-service=ssh --permanent
firewall-cmd --reload
2. 設定を確認する：
   firewall-cmd --list-all
3. クライアントから接続を再試行する

人間が検証すべきポイント:

• firewall-cmd --list-all で実際にSSHが許可リストに含まれていないことを確認する
• SSHのポートがデフォルト（22）以外に変更されている場合は、--add-port=22022/tcp のようにポート番号を指定する
• firewalld以外の原因（iptables直接設定、ネットワーク経路の問題）も切り分ける

ケース2: SELinuxによるポート変更の拒否

SSHのリスニングポートを変更したが、SELinuxの許可ポートに登録していない場合:

取得されたログ（マスキング済み）:

Mar 13 10:30:15 server-MASKED sshd[12345]: error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.
Mar 13 10:30:15 server-MASKED sshd[12345]: error: Bind to port 2222 on :: failed: Permission denied.
Mar 13 10:30:15 server-MASKED systemd[1]: sshd.service: Main process exited, code=exited, status=1/FAILURE

プロンプト例:

<role>
あなたはAlmaLinux 10サーバーの障害対応エンジニアです。
SELinux enforcing環境の運用経験があります。
</role>

<situation>
2026年3月13日 10:30頃、sshd_configのPortを2222に変更して
sshdを再起動したところ、起動に失敗しました。
SELinuxはenforcingモードで動作しています。
</situation>

<log>
Mar 13 10:30:15 server-MASKED sshd[12345]: error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.
Mar 13 10:30:15 server-MASKED sshd[12345]: error: Bind to port 2222 on :: failed: Permission denied.
Mar 13 10:30:15 server-MASKED systemd[1]: sshd.service: Main process exited, code=exited, status=1/FAILURE
</log>

<output_format>
以下の形式で分析結果を出力してください:
1. 障害概要
2. 原因候補（確信度付き、最大3つ、根拠ログ引用）
3. 推奨対応（実行コマンド付き）
4. 追加確認事項
不明な点は「不明」と回答してください。
</output_format>

AIの期待出力例:

1. 障害概要
sshdがポート2222へのバインドに失敗しています。SELinuxがポート2222をSSH用ポートとして許可していないことが原因です。

2. 原因候補

• 候補1（確信度: 高） ― SELinuxポリシーでポート2222がssh_port_tに登録されていない

3. 推奨対応

1. 現在のSSH許可ポートを確認する：
   semanage port -l | grep ssh
2. ポート2222をSSH用ポートとして登録する：
   semanage port -a -t ssh_port_t -p tcp 2222
3. sshdを再起動する：
   systemctl restart sshd
systemctl status sshd
4. firewalldにもポート2222を追加する：
   firewall-cmd --add-port=2222/tcp --permanent
firewall-cmd --reload

人間が検証すべきポイント:

• semanage port -l | grep ssh で実際にポート2222が未登録であることを確認する
• semanage コマンドが存在しない場合は dnf install policycoreutils-python-utils でインストールする
• firewalldへのポート追加も忘れずに行う（SELinuxとfirewalldは別のレイヤ）
• SELinuxのauditログ（/var/log/audit/audit.log）でdenialメッセージを確認する

ケース3: 認証失敗

取得されたログ（マスキング済み）:

Mar 13 11:00:05 server-MASKED sshd[12347]: Failed password for root from xxx.xxx.xxx.xxx port 54321 ssh2
Mar 13 11:00:08 server-MASKED sshd[12347]: Failed password for root from xxx.xxx.xxx.xxx port 54321 ssh2
Mar 13 11:00:12 server-MASKED sshd[12347]: Failed password for root from xxx.xxx.xxx.xxx port 54321 ssh2
Mar 13 11:00:12 server-MASKED sshd[12347]: Connection closed by authenticating user root xxx.xxx.xxx.xxx port 54321 [preauth]

このケースでは、AIに送信するプロンプトは省略しますが、同じテンプレートを使うと、AIは「rootパスワード認証の失敗（パスワード誤りまたはrootログイン禁止設定）」を原因候補として返します。

人間が検証すべきポイント:

• sshd_config で PermitRootLogin の設定値を確認する
• パスワード認証が禁止されている場合（PasswordAuthentication no）は公開鍵認証を使用する
• 短時間に大量の認証失敗がある場合は、ブルートフォース攻撃の可能性を疑い、fail2ban等の対策を検討する

シナリオC: ディスク容量不足

状況: サーバー上の各種サービスでエラーが発生し、ログの書き込みも失敗している。

ログ取得コマンド:

# systemd-journaldのログ（ディスク不足で一部欠損の可能性あり）
journalctl --since "1 hour ago" -p err --no-pager

# ディスク使用状況の確認
df -h
df -i
du -sh /var/log/*
journalctl --disk-usage

取得されたログ（マスキング済み）:

Mar 13 02:00:05 server-MASKED kernel: EXT4-fs error (device sda1): no space left on device
Mar 13 02:00:10 server-MASKED systemd-journald[123]: Failed to create new system journal: No space left on device
Mar 13 02:00:15 server-MASKED nginx[12345]: open() "/var/log/nginx/access.log" failed (28: No space left on device)
Mar 13 02:00:20 server-MASKED nginx[12345]: open() "/var/log/nginx/error.log" failed (28: No space left on device)

プロンプト例:

<role>
あなたはAlmaLinux 10サーバーの障害対応エンジニアです。
ディスク管理とログローテーションの運用を担当しています。
</role>

<situation>
2026年3月13日 02:00頃から、サーバー上の複数サービスで
「No space left on device」エラーが発生しています。
Webサイトは503エラーを返しており、ログの書き込みも失敗しています。

df -h の出力（抜粋）:
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G   20G     0 100% /

df -i の出力（抜粋）:
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      1310720 125000 1185720   10% /
</situation>

<log>
Mar 13 02:00:05 server-MASKED kernel: EXT4-fs error (device sda1): no space left on device
Mar 13 02:00:10 server-MASKED systemd-journald[123]: Failed to create new system journal: No space left on device
Mar 13 02:00:15 server-MASKED nginx[12345]: open() "/var/log/nginx/access.log" failed (28: No space left on device)
Mar 13 02:00:20 server-MASKED nginx[12345]: open() "/var/log/nginx/error.log" failed (28: No space left on device)
</log>

<output_format>
以下の形式で分析結果を出力してください:
1. 障害概要
2. 原因候補（確信度付き、最大3つ、根拠ログ引用）
3. 緊急対応（即座にディスク領域を確保する手順、実行コマンド付き）
4. 恒久対応（再発防止策）
5. 追加確認事項
不明な点は「不明」と回答してください。
</output_format>

AIの期待出力例:

1. 障害概要
ルートパーティション（/dev/sda1）の容量が100%に達し、nginxのログ書き込みとjournaldの記録が停止しています。inode使用率は10%のため、inode枯渇ではなくブロック容量の枯渇が原因です。

2. 原因候補

• 候補1（確信度: 高） ― ディスクブロック容量の枯渇（Use% 100%）
• 候補2（確信度: 中） ― ログファイルの肥大化（特に /var/log 配下）

3. 緊急対応（ディスク領域の確保）

1. 大きなファイルを特定する：
   du -sh /var/log/* | sort -rh | head -10
2. journaldのディスク使用量を確認・削減する：
   journalctl --disk-usage
journalctl --vacuum-size=500M
3. 古いログファイルを圧縮・削除する：
   find /var/log -name "*.log" -mtime +30 -exec gzip {} \;
4. パッケージキャッシュを削除する：
   dnf clean all
5. ディスク空き容量を再確認する：
   df -h

4. 恒久対応

• logrotateの設定を確認・調整する（ローテーション頻度・保持世代数・圧縮の有無）
• journaldの最大ディスク使用量を設定する（/etc/systemd/journald.conf の SystemMaxUse=1G）
• ディスク使用率の監視アラートを設定する（80%で警告、90%で緊急）

人間が検証すべきポイント:

• du -sh /var/log/* | sort -rh | head -10 で実際に容量を消費しているファイルを特定する
• AIが提示した find コマンドを実行する前に、対象ファイルが本当に削除可能か確認する（アプリケーション固有のログが含まれていないか）
• journalctl --vacuum-size=500M は実行すると元に戻せないため、必要なログが含まれていないか事前に確認する
• inode使用率が低い（10%）ことをAIが正しく読み取っているか確認する

障害対応フローへのAI組み込み

ここまでの内容を踏まえ、従来の障害対応フローとAI活用フローを対比します。

従来の障害対応フロー

経験が浅いエンジニアの場合、ステップ2〜3で「どのログを見ればよいか」「このエラーメッセージはどういう意味か」の判断に時間がかかります。

AI活用の障害対応フロー

AIを活用する場合でも、ステップ5の「人間による検証」は省略できません。AIはログのパターン認識と原因候補の列挙を高速に行いますが、実環境の状態を直接確認できるのは人間だけです。

AI活用で短縮できる部分

• ステップ2〜3の短縮: ログのパターン認識と原因推測をAIが担い、エンジニアは検証に集中できる
• ステップ6の効率化: 報告書のテンプレート生成をAIに任せることで、記述作業が削減される

報告書の下書き生成

障害対応後の報告書作成もAIで効率化できます。

<role>
あなたはインフラエンジニアチームの障害報告書作成担当です。
</role>

<situation>
以下の障害対応が完了しました。報告書の下書きを作成してください。

障害発生日時: 【発生日時】
復旧日時: 【復旧日時】
影響範囲: 【影響を受けたサービス・ユーザー数】
対応者: 【対応者名】

対応経緯:
【時系列で対応内容を箇条書きで記載】

特定された原因:
【原因の要約】

実施した対応:
【対応内容】
</situation>

<output_format>
以下の構成で障害報告書の下書きを作成してください:
1. 障害概要（3行以内）
2. 影響範囲
3. 時系列（表形式: 時刻 | 事象 | 対応）
4. 原因分析
5. 対応内容
6. 再発防止策（短期・中長期に分けて記載）
</output_format>

まとめ

この記事で扱った内容を整理します。

• ログをAIに渡す前の3つの注意点: 機密情報のマスキング、ログサイズの制限、ハルシネーション対策。この3つは障害シナリオを問わず共通の基盤となる
• ログ解析プロンプトの4要素: 役割（Role）・状況（Situation）・ログ（Log）・出力形式（Output）。前シリーズ①の6構成要素を、ログ解析に特化して再編成したもの
• 3つの障害シナリオ: systemdサービス起動失敗・SSH接続拒否・ディスク容量不足。各シナリオでプロンプト例・AIの期待出力例・人間が検証すべきポイントを示した
• 障害対応フローへのAI組み込み: AIはログのパターン認識と原因候補の列挙を高速化するが、人間による検証は省略できない

次にやること

1. 自分の環境で1つの障害シナリオを再現し、テンプレートを使ってプロンプトを組み立てる。 検証環境でnginxの設定を意図的に壊し、ログ取得→マスキング→プロンプト送信→結果検証の一連の流れを体験する
2. マスキング用のsedコマンドを自環境に合わせてカスタマイズする。 組織固有のホスト名命名規則やユーザー名パターンに対応したマスキングスクリプトを作成する
3. 過去の障害対応記録から1件を選び、AIで再分析する。 当時の対応と比較し、AIの分析精度を評価する

前の記事・次の記事

前シリーズ → コンテキストエンジニアリング
次の記事 → ② 構成管理ドキュメントをAIで自動生成する