ON-SITE PRACTICE

現場で使えるLinuxコマンド実践集｜運用監視で即使えるコマンド30選

「教科書のコマンドは知っているけど現場でどう使うかわからない」を解決。障害対応・ログ調査・リソース確認で実際に使うコマンドを現役IT講師がユースケース付きで解説します。

📅 最終更新：2026年3月 👨‍🏫 監修：現役IT講師吉田宝志 ⏱ 読了目安：約15分

LPIC-1やAWS CLFの勉強をしていると「コマンドは覚えたけど現場でどう使うかイメージできない」という声をよく聞きます。この記事では実際の現場（運用監視・障害対応・定期メンテナンス）で頻繁に使うコマンドを、ユースケースと実行例付きでまとめました。

📚 目次

まず、この記事で解説する内容の全体像を把握しておきましょう。また、各ポイントを意識しながら読み進めることで理解が深まります。

システム状態の確認コマンド
CPU・メモリ・プロセス監視
ディスク・ファイルシステム確認
ネットワーク確認・疎通テスト
ログ調査・フィルタリング
プロセス管理・サービス操作
現場でのコマンド活用Tips

💡 この記事の対象読者

具体的には、Linux基礎コマンドは知っているが現場での実用イメージが薄いインフラエンジニア・SES運用監視担当者。LPIC-1取得済みまたは学習中の方にも参考になります。

① システム状態の確認コマンド

次に、具体的な内容について確認します。つまり、ここでの情報が実際の行動に直結するため、丁寧に確認してください。

uptime — サーバーの稼働時間と負荷平均を確認

サーバーがいつから動いているか、直近1分・5分・15分のLoad Averageを確認します。障害発生時の最初の確認コマンドとして必須。

$ uptime 10:42:15 up 127 days, 3:14, 2 users, load average: 0.15, 0.20, 0.18

Load Averageがコア数を大幅に超えている場合はCPU高負荷の兆候です。

uname -a — OSのバージョン・カーネル情報を確認

サポート対象のカーネルバージョンか、32bit/64bitかの確認に使います。パッチ適用前後の確認にも。

$ uname -a Linux server01 4.18.0-372.9.1.el8.x86_64 #1 SMP … x86_64 x86_64 x86_64 GNU/Linux

df -h — ディスク使用量の確認（人が読みやすい形式）

各パーティションの使用率を確認。使用率が80%を超えたらアラート設定しておくのが運用の基本。

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 35G 15G 70% / tmpfs 3.9G 0 3.9G 0% /dev/shm

② CPU・メモリ・プロセス監視

続いて、実践的なポイントをお伝えします。そのため、自分のケースに当てはめながら読むことが重要です。

top / htop — リアルタイムプロセス監視

CPU・メモリを消費しているプロセスをリアルタイムで確認。障害発生時に「何がリソースを食っているか」を素早く特定できます。

$ top # ‘P’でCPU使用率順、’M’でメモリ使用率順に並べ替え # ‘k’でプロセスをkillする（PIDを入力）

vmstat 1 5 — CPU・メモリ・I/Oの統計を定期表示

1秒間隔で5回サンプリング。「us（ユーザーCPU）」「sy（システムCPU）」「wa（I/O待機）」を確認して性能問題の原因を特定します。

$ vmstat 1 5 procs ———–memory———- —swap– —–io—- -system– ——cpu—– r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1234567 23456 987654 0 0 2 5 100 200 5 2 93 0 0

free -h — メモリ・スワップ使用量の確認

メモリ不足の確認に使います。「available」列が実際に使用可能なメモリ量です（buffersとcacheを含む）。

$ free -h total used free shared buff/cache available Mem: 15Gi 4.2Gi 8.1Gi 200Mi 3.0Gi 10.8Gi Swap: 2.0Gi 0B 2.0Gi

③ ディスク・ファイルシステム確認

また、重要な観点から説明します。なぜなら、ここで紹介する内容を知ることで、より確実な選択ができるからです。

du -sh * — ディレクトリごとのサイズを確認

ディスクフル調査で最もよく使うコマンド。どのディレクトリが大きいかを階層的に追って原因ファイルを特定します。

$ du -sh /var/* 1.2G /var/log 45M /var/cache 12G /var/lib

find / -size +100M -type f — 大きなファイルを検索

100MB以上のファイルをシステム全体から検索。ディスクフルの原因になっているログファイルや一時ファイルを特定します。

$ find /var -size +100M -type f 2>/dev/null /var/log/messages-20260101 /var/log/httpd/access_log

④ ネットワーク確認・疎通テスト

さらに、補足的な情報をお伝えします。なお、ここで紹介する内容は現場での実体験をもとにしています。

ss -tulnp — ポート・リスニング状態の確認

netstatの後継コマンド。どのサービスがどのポートで待ち受けているかを確認。新しいサービスを立ち上げた後の確認に必須。

$ ss -tulnp Netid State Recv-Q Send-Q Local Address:Port Process tcp LISTEN 0 128 0.0.0.0:22 users:((“sshd”,pid=1234)) tcp LISTEN 0 511 0.0.0.0:80 users:((“nginx”,pid=5678))

traceroute / tracepath — 経路確認

通信できない時の経路調査。「どこでパケットが止まっているか」をホップ単位で確認できます。ファイアウォール・ルーティングの問題切り分けに使います。

$ traceroute 8.8.8.8 1 192.168.1.1 (192.168.1.1) 0.5 ms 2 10.0.0.1 (10.0.0.1) 1.2 ms 3 * * * ← ここでパケットが止まっている

curl -v / wget — HTTPの疎通確認

Webサービスへの疎通確認。ステータスコード・レスポンスヘッダーを確認してサーバーやロードバランサーの動作を検証します。

$ curl -v -o /dev/null -s -w “%{http_code}” https://example.com 200 $ curl -I https://example.com # ヘッダーのみ確認

⑤ ログ調査・フィルタリング

加えて、実践的な観点から解説します。具体的には、ここで紹介する方法を活用することで成果を高められます。

tail -f / journalctl -f — リアルタイムログ監視

障害対応中の最重要コマンド。ログが流れる様子をリアルタイムで確認しながら原因を絞り込みます。

$ tail -f /var/log/messages $ journalctl -f -u nginx # Nginxのログをリアルタイムで追う $ journalctl -u sshd –since “2026-03-18 10:00” –until “2026-03-18 11:00”

grep / grep -E — ログのキーワード検索

大量のログから特定のエラーや事象を絞り込む。「-i」で大小文字を無視、「-n」で行番号表示、「-A/-B」で前後の行も表示できます。

$ grep -i “error” /var/log/messages | tail -50 $ grep -E “ERROR|WARN|CRITICAL” /var/log/app.log $ grep -n “Connection refused” /var/log/nginx/error.log

awk / cut — ログの特定フィールドを抽出

アクセスログのIPアドレスだけ取り出す・エラーコードの集計など、ログ分析で頻繁に使います。

$ awk ‘{print $1}’ /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20 # アクセス元IPのランキングを表示 $ awk ‘$9 == “500”‘ /var/log/nginx/access.log | wc -l # 500エラーの件数をカウント

⑥ プロセス管理・サービス操作

そのため、よくある疑問についてまとめました。また、同じ悩みを持つ方が多いため、ご自身の状況に照らして読んでください。

systemctl — サービスの起動・停止・状態確認

現代のLinux（RHEL7以降・Ubuntu 16以降）でのサービス管理の基本。障害時のサービス再起動・自動起動設定に必須。

$ systemctl status nginx # 状態確認 $ systemctl start nginx # 起動 $ systemctl restart nginx # 再起動 $ systemctl enable nginx # 自動起動を有効化 $ systemctl is-active nginx # active/inactiveを確認

ps aux — プロセス一覧の確認

すべての実行中プロセスを確認。「grep」と組み合わせて特定プロセスの状態やPIDを取得します。

$ ps aux | grep nginx www-data 1234 0.0 0.1 55680 2048 ? S 10:00 0:00 nginx: worker process $ ps aux –sort=-%cpu | head -10 # CPU使用率上位10プロセス

⚠️ killコマンドは慎重に

プロセスを強制終了する「kill -9」は最終手段です。まず「kill」（シグナル15：正常終了）を試し、それでも停止しない場合のみ「kill -9」を使ってください。本番環境では必ず上長・チームへの確認を取ってから実行しましょう。

現場でのコマンド活用Tips

最後に、全体のポイントを整理します。以上のように、ここまでの内容を振り返りながら行動に移してください。

💡 履歴を活用してコマンドを効率化

「history」コマンドで過去のコマンドを確認、「Ctrl+R」で逆検索できます。よく使うコマンドはaliasに登録しておくと作業効率が大幅に上がります。

コマンドを実行する前に「echo」や「–dry-run」で動作確認する習慣をつける
本番環境の作業前は必ず設定ファイルのバックアップを取る（cp -p / tar）
障害対応中は実行したコマンドと結果をメモ帳やチームチャットに残す
rootで作業するのは最小限に。sudoで必要な権限だけ使う
cronジョブの確認は「crontab -l」と「/etc/cron.*」の両方を確認する

よくある質問

最後に、全体のポイントを整理します。以上のように、ここまでの内容を振り返りながら行動に移してください。

Q. netstatとssどちらを使えばいいですか？

A. 現在の主流はssです。netstatは「net-tools」パッケージが必要で、RHEL8/Ubuntu 20以降ではデフォルトでインストールされていない場合があります。ssはiproute2パッケージに含まれており、ほぼすべてのディストリビューションで使用可能です。

Q. LPIC試験と現場で使うコマンドは違いますか？

A. 基本的なコマンドは共通ですが、現場ではLPICに出ないコマンドやオプションも多く使います。特にsystemctl・ss・journalctlはLPIC-1の範囲外ですが現場では必須です。試験合格後も実機で手を動かして慣れることが重要です。

Q. 自宅でLinuxの練習環境を作るには？

A. VirtualBoxやVMware Player（無料）を使ってCentOSやRocky Linux、Ubuntuの仮想マシンを立てるのが最もコスパが高いです。AWSのEC2無料枠を使う方法もあります。実際に手を動かすことが上達の近道です。

Linux実機演習、一緒にやりましょう

最後に、全体のポイントを整理します。以上のように、ここまでの内容を振り返りながら行動に移してください。

「コマンドを覚えたけど使いこなせない」「現場で実際にどう使うか教えてほしい」という方に向けて、2026年7月よりフリーランス講師として個別の実機演習サポートを開始予定です。

Linux実機演習サポート LPIC試験対策オンライン対応

無料相談はこちら →

現場で使えるLinuxコマンド実践集｜運用監視で即使えるコマンド30選

現場で使えるLinuxコマンド実践集｜運用監視で即使えるコマンド30選