【Linux講座】インフラエンジニアのためのネットワーク切り分けとログ調査！実践編（第3回）

第1回の「基礎編」、第2回の「管理編」とお付き合いいただきありがとうございました。フォルダ構成の基本から、特権権限の扱い方、本番環境でのシャットダウンの重みまで、インフラエンジニアとしての土台は確実に強固なものになっています。

全3回講座の締めくくりとなる今回は、いよいよ「実践編」です。

もしまだ、基礎編、管理編の記事を読んでいない方は、先にそちらの記事をみてLinuxの基礎を確認してみてください。

現場に配属されると、毎日のように「サーバーが外のシステムと通信できない！」「自動実行しているバッチスクリプトが動いていない！」といった、突発的なトラブル対応が飛び込んできます。

こうした大ピンチのとき、優秀なエンジニアとそうでないエンジニアの差は「切り分けのスピード」で一瞬にして決まります。

今回は、私が18年のキャリアで培った「障害を10分で鎮めるための正しい手順」と、ChatGPTやClaudeなどの「生成AIを駆使した最新のログ解析ワークフロー」まで、現場のリアルな知恵をすべて詰め込んでお届けします！

ネットワークトラブルを最速で鎮める手前からの切り分け術（ip・ss・dig）

「サーバーが急に外のシステムと通信できなくなりました！」 障害発生の連絡を受け、慌てて本番サーバーへログインした若手エンジニア。彼は真っ青な顔で、宛先に対して ping コマンドをただ盲目的に連打し、画面が固まったままフリーズしていました。

ネットワークが繋がらないとき、最もやってはいけないのが「原因を勘で探ること」です。ネットワークの切り分けは、「まずは自分の手前から順番に、外側に向かって確認していくこと」が鉄則です。

私がチームのメンバーに叩き込んでいる、最速で原因を特定するための9つの思考プロセスを、実務コマンドとともに紹介します。

ifconfigはもう古い？現代のネットワーク確認はipコマンド

まずは自分の足元（ネットワークカード）をチェックします。昔は ifconfig が主流でしたが、現代のLinuxでは標準から外れつつあるため、モダンな ip コマンドを使うのがプロの常識です。

# 自サーバーのIPアドレスとサブネットマスクを表示
$ ip addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 192.168.1.10/24 bcast 192.168.1.255 scope global eth0

pingの連打は卒業！手前から外側へ進める「9つの切り分けステップ」

• ステップ1：IPアドレス、サブネットマスクが正しく設定されているか確認 上記の ip addr show で、割り当てられたIPが正しいか目視します。
• ステップ2：Default Gateway（DefaultGW）が設定されているか確認 外の世界へ出るためのルーターのIPが登録されているか確認します。

# ルーティングテーブルを確認
$ ip route show
default via 192.168.1.1 dev eth0 proto dhcp metric 100

• ステップ3：DNSサーバーが設定されているか確認 名前解決のためのDNSサーバーのIPが指定されているか、設定ファイルを見ます。

$ cat /etc/resolv.conf
nameserver 8.8.8.8

• ステップ4：pingでループバックアドレスに飛ぶか確認 そもそも自分のOSのネットワーク機能が健全に生きているかを確認します。

$ ping -c 3 127.0.0.1
3 packets transmitted, 3 received, 0% packet loss

• ステップ5：pingで自ホストのIPアドレスに飛ぶか確認 ステップ1で確認した自分のIP（192.168.1.10）に向けて飛ばし、LANカードが正常に反応するか見ます。
• ステップ6：pingで同一セグメントのdefaultGWに飛ぶことを確認 ステップ2で確認したルーター（192.168.1.1）へ飛ばします。ここが通れば、自分からルーターまでの物理的な社内LAN設備は正常だと証明できます。
• ステップ7：pingで異なるセグメント（通信相手）のIPに飛ぶことを確認 ルーターを越えて、目的地のサーバーの「IPアドレス」に直接飛ばします。ここが通らない場合は、途中のファイアウォールやクラウド側のルーティングの設定に原因があります。
• ステップ8：名前解決ができることを確認 IPではなく、ドメイン名（例: api.example.com）で通信相手のIPを正しく割り出せるかを確認します。実務では古くからある nslookup も使われますが、より詳細な情報が返ってくるモダンな dig コマンドをセットで覚えましょう。

# ドメイン名からIPを割り出す（正引き確認）
$ dig api.example.com
;; ANSWER SECTION:
api.example.com.    300    IN    A    203.0.113.5

• ステップ9：pingでホスト名指定で飛ぶことを確認 最後にドメイン名で ping api.example.com を飛ばします。これが通ればネットワークは完全復旧です。

ポートの待ち受け状態を調べるssコマンドの使い方（旧netstat）

「ネットワークは繋がっているのに、Webサービスだけが応答しない」という時は、特定のポートが待ち受け状態（LISTEN）になっているかを調べる必要があります。こちらも昔ながらの netstat ではなく、現代は ss コマンドを使うのがモダンな作法です。

# Webサーバー（80番ポート）が正常にサービスを待ち受けているか確認
$ ss -antp | grep :80
LISTEN 0      128          0.0.0.0:80        0.0.0.0:* users:(("nginx",pid=1234,fd=6))

巨大な本番ログから真因を最短で見つけるコツと生成AI活用術

障害のネットワーク切り分けが終わったら、次に行うのはサーバー内部の「ログ調査」です。しかし、何万行、何ギガバイトもある巨大な本番ログを、上から順に眺めていては1日があっても足りません。

障害調査の鉄則！エラーメッセージの「数分前」のログを読む

エラーが発生したタイムスタンプを特定したら、「エラーメッセージが記録された時間の数分前からログを読み直す」のがベテランの鉄則です。 なぜなら、エラーという結果が出力される直前に、その引き金となったエラーのトリガーや「真因」が必ず記録されているからです。

tail -f と grep コマンドを駆使した高速ログスキャン

実務では、ログが更新される様子をリアルタイムに画面に流し続ける tail -f や、特定の時間帯をスマートに絞り込む grep を駆使します。

# messagesログの末尾をリアルタイムに監視する（障害検証時の必須技）
$ tail -f /var/log/messages

# 15時30分〜35分までのログだけをピンポイントで抜き出す（パイプの応用）
$ cat /var/log/messages | grep "Jun 10 15:3[0-5]"

ChatGPTやClaudeで初動を爆上げする最新のログ解析ワークフロー

今の時代、暗号のようなエラーログを自力で1行ずつ解読して頭を抱える必要はありません。現在、私のチームでは「エラーメッセージを含む前後数分間のログを一括りでChatGPTやClaudeなどの生成AIに読み込ませる」手法を取り入れています。

AIに対して「各行の意味を解説し、エラーの根本原因と対策をセットで解析して」とプロンプトを投げるだけで、人間が数時間かけるログ解析を一瞬で終わらせてくれます。

1. AIにログを解析させ、エラーの真因に「当たり」をつける。
2. その解析結果（AIのレポート）をログと共に「保守ベンダー」へ送付する。
3. ベンダーに「この解析の通り、設定のバグで間違いありませんか？」と確証を得る。

この最新のワークフローを実践することで、障害対応の初動スピードを劇的に向上させることができます。AIを賢く道具として使いこなすことこそ、現代のプロのスキルです。

新人が100%やらかす「手動では動くのにcronだと動かない」自動実行の罠

インフラエンジニアの仕事の醍醐味は、面倒なルーティン作業を自動化することです。Linuxには、指定したスケジュールでスクリプトを自動実行してくれる cron という大変便利な機能があります。

crontab -e による定期実行スクリプトの基本設定

設定は crontab -e というコマンドを叩き、viエディタと同じ要領で書き込みます。

# cronの設定画面を開く
$ crontab -e

# 【実行サンプルの書き方】
# 分 時 日 月 曜日  実行したいスクリプトのパス
0 9 * * 1-5 /root/scripts/backup.sh
（※これで「毎週月〜金曜日の朝9:00に、backup.shを実行する」という意味になります）

しかし、この自動化には、新人が100%一度は泣きつく悪魔の罠が潜んでいます。それが、「自分で手動実行した時は完璧に動いたのに、cronに任せると全く動かない！」という怪奇現象です。新人が引き起こす、2大やらかし事例とその対策を伝えます。

【やらかし例1】ファイルの「実行権限（chmod +x）」の付け忘れ

「cronを設定したのに、毎朝バックアップが取れていません！」と新人が泣きついてきました。 ログを確認すると、悲しくも Permission denied というエラーメッセージが毎朝虚しく続いていました。

手動テスト時は、自分が bash backup.sh のようにプログラムを指定して動かしていたため動いていましたが、cronがスクリプト自身を直接実行しようとした際、ファイルに「実行権限の鍵」がかかっておらず、OSに拒否されていたのです。

# 自動実行させるスクリプトには、必ず実行権限を付与する！
$ chmod +x /root/scripts/backup.sh

【やらかし例2】環境変数の壁を破る「絶対パス指定」の鉄則

手動でスクリプトを作っているとき、ファイルの中に cp file.txt /tmp/ のように、現在のフォルダを基準にした「相対パス」や、コマンド名だけで処理を書いてしまうことがあります。

これがcronで動かない最大の原因、「環境変数の壁」です。 人間がログインしている画面には、どこからでもコマンドを実行できるように環境変数（PATH）の設定が最初から用意されていますが、裏方であるcronが動く世界は「ほぼ空っぽの、初期化された環境」です。

そのため、相対パスで書かれたファイルを見つけられず、コマンドの場所も分足らずに途中でスクリプトがクラッシュします。スクリプト実行のあるあるミスを防ぐためにも、パスの設定は絶対パスで指定することを心がけましょう。

【新人が書いたダメなスクリプト例】
cp data.txt /backup/

【プロが書く絶対パスのスクリプト例】
/bin/cp /root/scripts/data.txt /backup/

自動実行させるスクリプト内の記述や、cronの設定に書くパスは、「100%どこから見ても変わらない絶対パスで指定する」。これが自動化を成功させる鉄則です。

全3回講座のまとめ ＆ 最後に伝えたかったこと

お疲れ様でした！全3回にわたるLinux講座、これにて完全修了です。

• 第1回【基礎編】では、黒い画面の正体であるフォルダ構成と、作業前のバックアップルーティンを学びました。
• 第2回【管理編】では、神の権限の重み、実務で多発するアカウントロック解除、そして再起動コマンドを叩く前のホスト名確認の重要性を学びました。
• 第3回【実践編】では、トラブルを10分で鎮めるネットワークの切り分け手順、生成AIを使った高速ログ調査、 shadowの薄いcron自動化の罠を攻略しました。

最後に、18年間このインフラの世界にいる私から、これから羽ばたくあなたに一番伝えたいメッセージがあります。

それは、インフラエンジニアの本当の価値は「コマンドの暗記量」ではなく、「システムへの想像力と丁寧さ」にあるということです。

一歩間違えればシステムが崩壊する本番環境で、

「この権限を緩めたら、OSはどう反応するか？」
「このコマンドを叩いたら、画面の向こうのユーザーにどう影響するか？」
「いつでも1秒で元に戻せる準備はできているか？」

それをコマンドを打つ前に一瞬立ち止まって指差し確認できる丁寧さこそが、あなたを一流のエンジニアへと育て上げます。

この3回の講座で、あなたの「黒い画面への恐怖心」が消え、現場で自信を持って最初の一歩を踏出せるようになることを、心から応援しています。

この他に、インフラエンジニアを目指す方のロードマップを紹介した記事があります。この機会にインフラエンジニアを目指してみたい方は以下を確認してみてください。