「ChatGPTに聞いてみたけど、どこに何を貼ればいいか分からない」
AIチャットにLinuxのログを貼って質問する方法は広まっていますが、渡し方を誤ると精度が大幅に下がります。 ログの量が多すぎる、文脈が不足している、機密情報が混入している——こういった問題が、的外れな回答の主な原因です。
この記事では、journalctlやdmesgの出力をChatGPT・Claudeに渡す具体的な方法と、精度を上げるプロンプトの書き方を解説します。
この記事のポイント
・ログは「エラー行前後30行」に絞り、コンテキストとセットで渡す
・journalctl -xe --no-pager でページング解除して貼り付け可能な形式にする
・IPアドレス・ホスト名・パスは貼る前にマスキングする
・AIは「原因候補の列挙」には強いが「確定診断・対処コマンドの実行」には使わない
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AI解析の現在地
セミナーで「Linuxのエラーをどうやって調べますか」と聞くと、今では半数以上の受講生がAIチャットを使うと答えます。 それだけ現場への浸透が速い一方で、「使ってみたけど期待外れだった」という声も多く聞きます。現時点(2026年)のAI(ChatGPT・Claude等)は、次のような特性があります。
・得意なこと:エラーメッセージの意味解釈、原因候補の列挙、コマンドの説明
・不得意なこと:サーバー固有の構成・設定状態の理解(AIには見えていない情報が多い)
・やってはいけないこと:AIが提案したコマンドを確認なしに本番サーバーで実行する
つまりAIは「この症状から考えられる原因を整理する補助ツール」として使うのが正解で、 確定診断や実行コマンドは自分でドキュメントを確認してから判断するというスタンスが必要です。
どこまで聞くと精度が出るか
AIに質問するときに精度が上がるのは、次の3要素をセットで渡したときです。・症状の説明(1~3文):「何をしようとしたとき」「どんな問題が起きたか」
・環境情報:OSバージョン・サービス名・カーネルバージョン
・エラーログ:エラー行とその前後30行程度
「ログだけ貼る」は最悪のパターンです。 AIにはサーバーの構成が見えていないので、ログの断片だけでは文脈を推測するしかなく、的外れな回答になります。
質問のテンプレートはこのような形が効果的です。
【環境】 OS: Rocky Linux 9.4 サービス: nginx 1.24 カーネル: 5.14.0-427.xx.el9 【症状】 nginx起動時に「Address already in use」エラーが出て起動できません。 ポート80は使用中のはずはないのに、ssコマンドでも何も映りません。 【ログ】 (journalctl -xe の出力を以下に貼ります)
journalctl出力を渡すコツ
systemd-analyze で起動時間計測と同様に、systemdが管理するサービスのログはjournalctlで集中管理されています。 ログをAIに渡すときは、出力形式を整えることが重要です。1. ページング解除で貼り付け可能な形式にする
# disable pager(less を経由しない) journalctl -xe --no-pager # サービス名を絞り込む(nginx の場合) journalctl -u nginx --no-pager -n 50 # タイムスタンプを人間が読みやすい形式にする journalctl -u nginx --no-pager -n 50 -o short-iso # 今日のログだけ取得する journalctl -u nginx --no-pager --since today # 出力例(short-iso形式) 2026-05-13T09:23:11+0900 webserver01 nginx[12345]: 2026/05/13 09:23:11 [emerg] 12345#12345: bind() to 0.0.0.0:80 failed (98: Address already in use) 2026-05-13T09:23:11+0900 webserver01 nginx[12345]: 2026/05/13 09:23:11 [emerg] 12345#12345: still could not bind()
2. エラー行を中心に前後を絞り込む
ログ全体をそのまま貼ると、AIが重要な箇所を見落とすことがあります。 grepでエラー行を抽出してから、前後の文脈を付けるのが効果的です。# エラー行とその前後10行を取得する journalctl -u nginx --no-pager | grep -i "error\|failed\|fatal" -B 5 -A 10 # 直近のブート以降のログ(再起動後から確認する場合) journalctl -u nginx --no-pager -b # Priority別にフィルタ(err以上のみ表示) journalctl -u nginx --no-pager -p err
3. カーネルメッセージ(dmesg)を渡す場合
ハードウェアエラーやカーネルパニック、ネットワークドライバ関連の問題はdmesgを使います。# 直近のdmesgからエラー・警告を抽出する dmesg -T --level=err,warn # 出力例 [2026-05-13 08:15:22] EXT4-fs error (device sdb1): ext4_journal_check_start:61: Detected aborted journal [2026-05-13 08:15:22] EXT4-fs (sdb1): Remounting filesystem read-only # 特定のキーワードで絞り込む dmesg -T | grep -i "oom\|kill\|error\|panic"
dmesg・syslogのフィルタ
1. syslog(/var/log/messages)のフィルタ
systemdを使わない環境や、従来型のsyslogが残っている場合は/var/log/messagesを参照します。# 今日のエラーだけ抽出する grep "$(date '+%b %e')" /var/log/messages | grep -i "error\|failed" # 特定サービスのログを直近100行取得する grep "nginx" /var/log/messages | tail -100 # 出力例(マスキング後) May 13 09:23:11 [hostname_masked] nginx: 2026/05/13 09:23:11 [error] 1234#1234: *5 connect() failed
2. auth.logのフィルタ(不正アクセス調査)
SSH不正アクセスの調査でAIに聞く場合は、auth.logから抽出します。# 認証失敗をIPごとに集計してから貼り付ける grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn | head -20 # 出力例(マスキング後) 342 203.0.113.xxx # 外部IPはマスキングして貼る 85 198.51.100.yyy 3 192.168.1.10 # 内部IPはそのまま可
機密情報のマスキング
AIチャットに貼るログには機密情報が混入しやすいです。 貼る前に必ず確認・置換してください。・外部IPアドレス:203.0.113.xxx のように末尾をmaskする
・ホスト名:本番サーバー名は [hostname_masked] に置換する
・ドメイン名:example.com 等に置換する
・パスワード・トークン:[MASKED] に置換する
・内部ネットワークのIPアドレス:192.168.x.x はそのままでも可(ただし顧客情報に直結する場合は除く)
sedで簡単に一括置換できます。
# 外部IPをマスクする(末尾2オクテットを置換) journalctl -u nginx --no-pager -n 100 | \ sed 's/\([0-9]\{1,3\}\.[0-9]\{1,3\}\)\.[0-9]\{1,3\}\.[0-9]\{1,3\}/\1.xxx.xxx/g' # ホスト名を置換する(hostname が webprod01 の場合) journalctl -u nginx --no-pager -n 100 | sed 's/webprod01/[hostname_masked]/g'
プロンプト例
以下に、実際に使えるプロンプト例を示します。1. サービス起動失敗のプロンプト
以下のLinuxサーバーでサービスが起動できない問題について、 考えられる原因を整理してください。 【環境】 OS: Rocky Linux 9.4 サービス: nginx 1.24 カーネル: 5.14.0-427.xx 【症状】 nginx を systemctl start nginx で起動しようとすると失敗します。 ポート80・443は他のプロセスに使われていないはずです。 【journalctlのログ(最新50行)】 (ここにマスキング済みのログを貼る) 考えられる原因を列挙してください。 1つずつ確認するコマンドも教えてください(実行は自分でします)。
2. カーネルパニック後の調査プロンプト
Linuxサーバーが突然再起動しました。 以下のdmesgログから、原因として考えられるものを教えてください。 【環境】 OS: AlmaLinux 9.3 メモリ: 16GB 稼働中サービス: PostgreSQL 15、nginx 【dmesgログ(エラー・警告のみ)】 (ここにマスキング済みのdmesg -T --level=err,warn の出力を貼る) ハードウェア障害・ソフトウェアのどちらが原因として疑われるか、 可能性の高い順に説明してください。
3. 「確認だけ」に限定した質問の仕方
# よくある危険な質問パターン(NG) 「このエラーを直すには何を実行すればいいですか?」 # 推奨パターン(OK) 「このエラーの原因を確認するには、どのコマンドを実行して何を確認すればよいですか? 実行は自分でするので、まず調査手順を教えてください。」
AIトラブル解析でよくあるエラーと注意点
AIは非常に便利ですが、次のような判断をAIに委ねてはいけません。1. 本番環境への直接コマンド実行
AIが「このコマンドを実行してください」と言っても、必ず自分でmanやドキュメントを確認してから実行してください。 AIは自信を持って誤ったコマンドを提案することがあります。
2. ディスクやDBの障害診断・復旧判断
fsck・xfs_repairなどのファイルシステム修復は、状況を誤ると壊滅的なデータ損失につながります。 AIに「実行して大丈夫ですか」と聞くのは危険です。公式ドキュメントと専門家に確認してください。
3. セキュリティインシデントの最終判断
不正アクセスの有無・感染の範囲・対処方針はAIだけで判断せず、組織のセキュリティポリシーと専門家の判断を仰いでください。 Linux ポート確認の全コマンドと組み合わせてAIに状況を説明する際も、最終判断は必ず人間が行う、というスタンスを維持してください。
4. バージョン・機能の確実性が求められる情報
AIの学習データには古い情報が混在しています。 コマンドの具体的なオプション・設定ファイルのパス・パッケージ名は、dmidecode でハードウェア情報を取得のような公式・実測データと照合してから採用してください。
本記事のまとめ
AIを使ったLinuxトラブル解析のポイントをまとめます。| やりたいこと | コマンドまたは方法 |
|---|---|
| journalctlをページング解除で取得 | journalctl -u サービス名 --no-pager -n 50 |
| エラー行のみ抽出(前後5行付き) | journalctl --no-pager | grep -i "error\|failed" -B 5 -A 10 |
| dmesgのエラー・警告だけ取得 | dmesg -T --level=err,warn |
| 外部IPをマスクして貼る | sed で末尾2オクテットを xxx.xxx に置換 |
| 質問テンプレートの基本形 | 環境情報+症状説明+エラーログの3点セット |
| AIに依頼する範囲の上限 | 「原因候補と確認手順の提示」まで(コマンド実行の判断は自分で) |
Linux無料マニュアルを受け取る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:Linuxのファイル権限完全ガイド|chmod・chown・umaskの基礎と実務でよく使う設定
- 前のページへ:Linuxサーバーのパーティション設計ガイド|LVM・/var分離・スワップ容量の決め方
- この記事の属するカテゴリ:Linuxtips・Linuxトラブルシューティングへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます