DevOctane
LinuxインフラコマンドSSHサーバー

【2026年版】インフラエンジニアが実務で使うLinuxコマンド完全ガイド

2026.05.2530 min read
【2026年版】インフラエンジニアが実務で使うLinuxコマンド完全ガイド

新卒でSESに入ったとき、サーバーに接続して最初に打ったのが lspwd だった。それから自社開発・フリーランスと経験を積み、今は副業でConoHa VPSを使って社内ツールを構築している。Linuxコマンドはキャリアのどのフェーズでも必ずついてくる。

「Linuxコマンドは覚えなくていい」という話を聞くことがある。クラウド全盛でコンソールからポチポチ操作できる時代に、なぜコマンドラインを使うのか。答えは単純で、トラブルシューティングと本番操作ではコマンドラインを避けられないからだ。ディスクが枯渇したとき、プロセスが暴走したとき、ログを素早く絞り込みたいとき——GUIでは対応できないことがある。

この記事では、SES新卒から現在のフリーランス副業まで実務で使い続けているLinuxコマンドを、ユースケース別に整理する。基礎の ls から、現場で真価を発揮するサーバー調査コマンド・SSH操作・コンテナ時代の変化まで網羅する。

この記事でわかること
① ファイル・ディレクトリ操作の基本コマンド
② ディスク枯渇・プロセス暴走など不具合調査に使うコマンド
③ ログ調査の鉄板コマンド(tail -f / grep)
④ SSH・SCP によるリモートサーバー操作
⑤ コンテナ時代のLinuxコマンドの変化(docker exec / Datadog)

対象読者

  • SESや自社開発でLinuxサーバーを触り始めたエンジニア
  • EC2やVPSを運用しているが、コマンドに自信がないエンジニア
  • トラブルシューティングでコマンドを使いこなしたいエンジニア
  • コンテナ移行後もLinuxの基礎を押さえておきたいエンジニア

なぜLinuxコマンドを覚える必要があるか

クラウド時代でも、サーバーの直接操作が必要な場面は必ず来る

EC2にSSHで接続してNginxの設定を変更する、VPS上でCronの動作を確認する、コンテナ内に入って環境変数を確認する——これらはGUIコンソールではできない操作だ。AWSマネジメントコンソールはリソースの管理には便利だが、サーバーの中身を調べたり即座にファイルを編集したりするのはコマンドラインが圧倒的に速い。

また、本番環境のトラブル対応はスピードが命だ。サービスが落ちているときにGUIを操作する時間的余裕はない。top でCPUを確認し、df でディスクを確認し、tail -f でログを流しながら原因を特定する——この一連の操作をスムーズにこなせるかどうかで、インフラエンジニアとしての実力差が出る。

Linuxコマンドが活躍する場面
日常運用
デプロイ・設定変更・ログ確認
トラブル対応
ディスク枯渇・プロセス暴走・サービス停止
コンテナ時代
docker exec・監視ツール連携

ファイル・ディレクトリ操作の基本

最初に覚えるのはこのグループだ。SES時代に最初に使ったのも lspwd だった。

ファイル確認・移動

ls -la          # ファイル一覧(隠しファイルも含む詳細表示)
pwd             # 現在のディレクトリを表示
cd /var/log     # ディレクトリ移動
cd ~            # ホームディレクトリへ移動
cd -            # 直前のディレクトリへ戻る

ls -lals の中で最もよく使う形だ。ファイルの権限・オーナー・サイズ・更新日時が一覧で確認できる。

ファイルのコピー・移動・削除

cp file.conf file.conf.bak      # ファイルのコピー(バックアップ作成)
cp -r /etc/nginx /tmp/nginx_bak # ディレクトリごとコピー
mv old_name.conf new_name.conf  # ファイル名変更・移動
rm file.log                     # ファイル削除
rm -rf /tmp/old_logs/           # ディレクトリごと削除(要注意)

rm -rf は本番で最も危険な操作
rm -rf は確認なしにファイルを完全削除する。本番サーバーで削除・更新系のコマンドを実行する前は必ずバックアップを取ること。「消してから気づく」では取り返しがつかない。

ファイル作成・確認

mkdir -p /opt/myapp/logs    # ディレクトリ作成(-p で親ディレクトリも一緒に作成)
touch app.log               # 空ファイル作成・タイムスタンプ更新
cat /etc/nginx/nginx.conf   # ファイル内容を全表示
less /var/log/syslog        # ページ送りで確認(q で終了)
head -n 20 app.log          # 先頭20行を表示
tail -n 50 app.log          # 末尾50行を表示

サーバー状態の確認(不具合調査の基本)

「サービスが重い」「ディスクがいっぱいでデプロイできない」——SES時代から現在まで、このグループのコマンドは不具合調査の第一歩だ。

CPU・メモリの確認

top             # CPU・メモリ使用率をリアルタイム表示(q で終了)
htop            # topの見やすい版(要インストール)
free -h         # メモリ使用量を人が読みやすい形式で表示
vmstat 1 5      # 1秒間隔で5回、CPU・メモリ・IO統計を表示

top はサービスが重いときに最初に開くコマンドだ。%CPU%MEM の高いプロセスを探し、何が原因かを特定する。

# top のキー操作
# P キー: CPU使用率順でソート
# M キー: メモリ使用率順でソート
# k キー: プロセスをkill(PIDを入力)
# q キー: 終了

ディスクの確認

df -h                                      # ディスク使用量をパーティション別に表示
du -sh /var/log                            # 指定ディレクトリのディスク使用量
du -sh /var/log/* | sort -rh | head -20    # サブディレクトリを大きい順に表示

df -h でどのパーティションが枯渇しているか確認し、du でどのディレクトリが原因かを特定する。本番でディスクが枯渇するケースの多くはログファイルの肥大化だ。

# ディスク枯渇の調査手順
df -h                                      # 枯渇しているパーティションを特定
du -sh /var/log/* | sort -rh | head -20    # 大きいログファイルを特定
ls -lh /var/log/nginx/                     # ファイルサイズを確認

プロセスの確認と終了

ps と kill は「プロセスが応答しない」「ゾンビプロセスが残っている」ときに使う。SES時代に現場で覚えたコマンドのひとつだ。

ps aux                      # 全プロセス一覧(CPU・メモリ使用率付き)
ps aux | grep nginx         # nginx のプロセスだけ絞り込む
ps aux | grep -v grep       # grep自身を除外して表示
 
kill 1234                   # PID 1234 のプロセスに TERM シグナル送信(正常終了)
kill -9 1234                # PID 1234 を強制終了(killで終わらないときの最終手段)
pkill nginx                 # プロセス名で kill
# プロセス調査の手順
ps aux | grep myapp         # アプリのPIDを確認
kill -9 <PID>               # 応答しない場合は強制終了
systemctl restart myapp     # サービスとして管理している場合は再起動

kill -9 は最後の手段
kill -9(SIGKILL)はプロセスにクリーンアップの機会を与えず強制終了する。まず kill(SIGTERM)で試し、それでも終了しない場合に kill -9 を使う。

ポートとネットワークの確認

ss -tlnp                        # リスニング中のTCPポートを表示(プロセス名付き)
netstat -tlnp                   # ss の旧コマンド(古いサーバーではこちらが使える)
curl -I http://localhost:3000   # HTTPレスポンスのヘッダーを確認
ping google.com                 # 外部への疎通確認

「ポート3000で起動しているはずなのに繋がらない」というときに ss -tlnp でポートの状態を確認する。


ログ調査の鉄板コマンド

ログを素早く読む力はインフラエンジニアの核心スキルだ。エラーが出たとき、tail -f でリアルタイムにログを流しながら grep で絞り込む操作は毎日のように使う。

tail と grep の組み合わせ

tail -f /var/log/nginx/error.log              # ログをリアルタイムで流す
tail -f /var/log/nginx/error.log | grep "ERROR"  # エラーだけ表示
tail -n 100 /var/log/app.log | grep "500"     # 末尾100行からHTTP500を絞り込む

tail -f はログを流しっぱなしにしてデプロイや操作の影響をリアルタイムで確認するのに使う。Ctrl + C で止める。

grep でログを絞り込む

grep "ERROR" app.log                          # ERRORを含む行を抽出
grep -i "error" app.log                       # 大文字小文字を無視
grep -n "ERROR" app.log                       # 行番号付きで表示
grep -A 5 -B 2 "ERROR" app.log                # エラー行の前後も表示(A:after B:before)
grep -v "INFO" app.log                        # INFOを含まない行を表示(除外)
grep "2026-05-25" app.log | grep "ERROR"      # 日付とエラーを両方で絞り込む

複数条件での絞り込みは | でパイプしてつなぐ。「特定の日付のエラーだけ見たい」というときに重宝する。

ログファイルをナビゲートする

less +F /var/log/syslog     # リアルタイム追記しながらページ送りもできる
# スペースで次ページ、b で前ページ、/で検索、q で終了
# +F モード中は Ctrl+C でスクロールモードに戻れる
 
zcat /var/log/app.log.gz | grep "ERROR"   # 圧縮ログを展開せずに検索

SSH・SCP:リモートサーバー接続の基本

「絶対押さえておくべきコマンド」として最初に挙がるのが SSH と SCP だ。EC2・VPS・踏み台サーバー経由のアクセス——リモートサーバーへの接続は現場で毎日使う操作だ。

SSH の基本

ssh user@192.168.1.100                    # IPアドレスで接続
ssh -i ~/.ssh/my-key.pem ec2-user@<IP>   # AWS EC2 への接続(鍵ファイル指定)
ssh -p 2222 user@hostname                 # ポートを指定して接続
ssh -L 8080:localhost:3000 user@hostname  # ローカルポートフォワーディング

AWS EC2 への接続では鍵ファイル(.pem)のパーミッションが 600 でないと接続を拒否される。

chmod 600 ~/.ssh/my-key.pem   # 鍵ファイルのパーミッション設定(必須)

SSH config で接続を簡略化する

毎回 -i オプションで鍵ファイルを指定するのは面倒だ。~/.ssh/config に設定を書いておくと ssh myserver だけで接続できる。

# ~/.ssh/config の例
Host myserver
    HostName 192.168.1.100
    User ec2-user
    IdentityFile ~/.ssh/my-key.pem
    Port 22
 
Host conoha-vps
    HostName xxx.xxx.xxx.xxx
    User root
    IdentityFile ~/.ssh/conoha-key.pem

設定後は ssh myserver または ssh conoha-vps で接続できる。複数のサーバーを管理しているときに非常に便利だ。

SCP でファイルを転送する

# ローカル → サーバーへアップロード
scp -i ~/.ssh/my-key.pem ./app.tar.gz ec2-user@<IP>:/home/ec2-user/
 
# サーバー → ローカルへダウンロード
scp -i ~/.ssh/my-key.pem ec2-user@<IP>:/var/log/app.log ./
 
# ディレクトリごと転送
scp -r -i ~/.ssh/my-key.pem ./deploy/ ec2-user@<IP>:/opt/myapp/
 
# SSH config を使う場合(鍵ファイル指定不要)
scp ./app.tar.gz myserver:/home/ec2-user/

ログファイルをローカルに落として調査したり、ビルド済みのパッケージをサーバーに転送するときに使う。


ファイル権限の管理(chmod・chown)

「Permission denied」エラーはインフラ作業でよく遭遇する。権限の仕組みを理解していないと原因がわからない。

パーミッションの読み方

ls -la /etc/nginx/nginx.conf
# -rw-r--r-- 1 root root 1234 May 25 10:00 nginx.conf
# 意味: オーナー=読み書き、グループ=読み取りのみ、その他=読み取りのみ
数値権限意味
7rwx読み・書き・実行
6rw-読み・書き
5r-x読み・実行
4r--読み取りのみ
0---権限なし
chmod 644 config.conf           # オーナー=rw、グループ・その他=r
chmod 755 deploy.sh             # オーナー=rwx、グループ・その他=rx(実行スクリプト)
chmod 600 ~/.ssh/my-key.pem     # オーナーのみrw(SSH鍵は必ずこれ)
chmod -R 755 /opt/myapp/        # ディレクトリ以下を再帰的に変更
 
chown ec2-user:ec2-user app.log         # オーナーとグループを変更
chown -R nginx:nginx /var/www/html/     # ディレクトリ以下を再帰的に変更

vim の基本操作

設定ファイルを編集するとき、サーバー上で使えるエディタは vim(または vi)が基本だ。最初はとっつきにくいが、最低限の操作を覚えておけば実務で困ることはない。

vim の操作モード
ノーマルモード
起動直後・ESCキーで戻る
カーソル移動・コピー・削除操作
:wq で保存終了、:q! で破棄終了
インサートモード
i キーで入る
テキスト入力ができる状態
ESC でノーマルモードに戻る
コマンドモード
: キーで入る
:w 保存、:q 終了、:wq 保存終了
/検索文字 で文字列検索
# vim の起動
vim /etc/nginx/nginx.conf
 
# 最低限覚えるキー操作
# i     インサートモードに入る(編集開始)
# ESC   ノーマルモードに戻る
# :w    上書き保存
# :q    終了(未保存の変更がある場合は失敗)
# :wq   保存して終了
# :q!   変更を破棄して強制終了
# /keyword  キーワードを検索(n で次の一致箇所へ)
 
# よく使うノーマルモード操作
# dd    カーソル行を削除(カット)
# yy    カーソル行をコピー
# p     ペースト
# u     アンドゥ(Ctrl+Z 相当)
# G     ファイルの末尾へ移動
# gg    ファイルの先頭へ移動
# :行番号  指定行へジャンプ(例: :50)

「vim を開いたら閉じ方がわからない」という話はよく聞く。最初に :q!(強制終了)だけ覚えておけば詰まることはない。


本番操作の鉄則:バックアップ必須

実務で一番大切なことをまとめておく。

削除・更新系コマンドの前は必ずバックアップ
本番サーバーで rmmvchmod・データ更新を行う前は、必ずバックアップを取ること。「後で気づいた」では取り返しがつかない。特に rm -rf は確認ダイアログなしに即座に削除が完了する。

バックアップの基本パターン

# 設定ファイルを変更する前のバックアップ
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.20260525
 
# ディレクトリごとバックアップ
cp -r /opt/myapp /opt/myapp.bak.20260525
 
# データベースのバックアップ(MySQL例)
mysqldump -u root -p mydb > /tmp/mydb_backup_20260525.sql
 
# 変更後に問題があれば戻す
cp /etc/nginx/nginx.conf.bak.20260525 /etc/nginx/nginx.conf
nginx -t && systemctl reload nginx

日付をファイル名に含めるのが重要だ。複数のバックアップが並んだとき、どれが最新か一目でわかる。

危険な操作の前に確認する

# rm の前に ls で対象を確認する
ls /var/log/old_logs/
rm -rf /var/log/old_logs/   # 確認してから実行
 
# find + rm は特に注意(まず find だけで対象を確認)
find /var/log -name "*.log" -mtime +30
find /var/log -name "*.log" -mtime +30 -delete   # 確認後に削除を実行

コンテナ時代のLinuxコマンドの変化

ECS/Fargateのような本格的なコンテナ環境を使うようになると、直接サーバーにSSHして調査する機会が減る。大手自社開発でECS/Fargateを使っていたとき、従来のLinuxコマンドをEC2時代ほど使わなくなったのは事実だ。

コンテナ内に入る

EC2ではSSHで接続するが、コンテナ環境では docker exec でコンテナに入る。

# Dockerコンテナ内に入る
docker exec -it <コンテナID> /bin/bash
docker exec -it <コンテナID> /bin/sh    # bashがない場合
 
# コンテナのログを確認
docker logs <コンテナID>
docker logs -f <コンテナID>             # リアルタイムで流す
 
# コンテナの状態確認
docker ps                               # 起動中のコンテナ一覧
docker stats                            # コンテナのCPU・メモリ使用率

ECS/Fargate では CloudWatch でログを確認する

ECS on Fargate ではサーバーに直接SSHできない。代わりに CloudWatch Logs でコンテナのログを確認する。

# AWS CLI でCloudWatchのログを取得
aws logs tail /ecs/myapp --follow
aws logs filter-log-events --log-group-name /ecs/myapp --filter-pattern "ERROR"

New Relic・Datadog による監視

大規模なコンテナ運用では、topdf で個別サーバーを確認する運用から、New RelicやDatadogなどの監視ツールにメトリクスを集約する運用に変わる。

CPU使用率・メモリ使用量・ディスク容量・レスポンスタイムなどをダッシュボードで一元管理し、閾値を超えたときにアラートが飛ぶ仕組みを作る。大手自社開発での実務もこの形だった。

コンテナ時代でもLinuxの基礎は必要
ECS/Fargateに移行してもDockerfileの書き方・コンテナ内のデバッグ・AWS CLIでのログ確認など、Linuxの知識が土台になる操作は残る。監視ツールが入っていても、突発的なトラブルでは直接コマンドで調査する場面がある。

ECS/FargateとCloud Runの使い分けについてはECS/FargateとCloud Run実務で選ぶ判断基準も合わせて読んでほしい。


よく使うコマンドのチートシート

カテゴリコマンド用途
基本操作ls -laファイル一覧(詳細・隠しファイル含む)
基本操作pwd現在のディレクトリ確認
基本操作cp -r src dstディレクトリをコピー
基本操作rm -rf dir/ディレクトリを削除(要注意)
サーバー調査topCPU・メモリ使用率をリアルタイム確認
サーバー調査df -hディスク使用量を確認
サーバー調査du -sh dir/ディレクトリのサイズを確認
サーバー調査free -hメモリ使用量を確認
プロセス管理ps aux | grep nginxプロセスを確認
プロセス管理kill -9 <PID>プロセスを強制終了
ログ調査tail -f app.logログをリアルタイムで流す
ログ調査grep -n "ERROR" app.logエラーを行番号付きで抽出
ログ調査tail -f app.log | grep "ERROR"リアルタイムでエラーだけ表示
SSHssh -i key.pem user@IPEC2/VPSに接続
SSHscp file user@IP:/path/ファイルを転送
権限chmod 600 key.pemSSH鍵のパーミッション設定
権限chmod 755 script.sh実行スクリプトのパーミッション設定
vimi / ESC / :wq編集開始 / ノーマルモード / 保存終了

まとめ

Linuxコマンドは「全部覚える」必要はない。まず実務でよく使う操作から覚えて、トラブルが起きたときに対応できるセットを身につけるのが効率的だ。

最優先で覚えるべきコマンド

  1. SSH・SCP — リモートサーバーへの接続と転送。これがないとサーバーに入れない
  2. df / du / top — ディスクとCPU・メモリの確認。不具合調査の第一歩
  3. tail -f / grep — ログ調査の鉄板。エラーの原因特定に直結する
  4. ps / kill — プロセス管理。応答しないプロセスへの対処
  5. vim の最低限操作 — 設定ファイルの編集。:wq:q! だけ覚えれば詰まらない

コンテナ時代になっても、LinuxとSSHの知識は土台として残る。DockerfileはLinuxコマンドで書かれ、docker exec でコンテナ内のデバッグもLinuxの操作だ。

Linuxを含むクラウドインフラ全般をUdemyで体系的に学ぶことで、実務での応用力が大きく変わる。EC2の操作やサーバー構築を学ぶついでにLinuxコマンドを習得するのが効率的だ。

UdemyでLinux・AWSコースを探す →

※本リンクはアフィリエイトリンクです

クラウドエンジニアとしてのキャリアをさらに広げたい場合はクラウドエンジニア学習ロードマップ2026も参考にしてほしい。VPSを使って実際にLinuxサーバーを操作する環境を作りたい場合はConoHa・Xserver・さくらVPS比較Xserver VPS + Dockerで個人開発環境を構築するも合わせて読んでほしい。