Linux入門｜初心者向けのインストールと基本操作

Linuxを始めたいと思っても、最初の分かれ道で止まりがちです。
WSL『VirtualBox』Ubuntuのどれを選ぶべきか、そこで迷うと手が動かなくなります。
この記事では、WindowsユーザーやこれからLinuxに触れる初学者に向けて、WSL・仮想環境・実機インストールの3ルートを目的別に整理し、Ubuntu 24.04 LTSを例に導入から初期設定、基本コマンド、トラブル対応の入口までを順番に案内します。

筆者は業務でも自宅のスマートホームでもLinuxを常用しており、新人研修ではWSLから始めて『VirtualBox』などの仮想環境、そこから実機へ進む流れをよく使っています。
実際につまずきやすいのは、USBが起動しない場面と権限まわりの操作ミスです。
そこで本記事では、最初に判断軸を示し、事故が起きやすいポイントを先回りして押さえることで、遠回りせずLinuxの基礎に入れる構成にしました。

Windowsでまず安全に試すならWSLの導入が最短で、『WSL のインストール』でも wsl --install による導入手順が案内されています。
一方で、Linuxらしい起動やディスク操作まで体験したいなら仮想環境や実機が向いています。
自分の目的に合った入口を選べば、Linux学習は難しいものではなく、GUIとコマンドラインの両方を無理なく身につけていけます。

linuxとは何か初心者が最初に知るべき基礎">Linuxとは何か｜初心者が最初に知るべき基礎

Linuxはひとことで言うとOSそのものではなく、まずカーネルと呼ばれる中核部分があり、その上に使いやすい初期設定、パッケージ管理の仕組み、デスクトップ環境、各種ツール群をまとめたディストリビューションが載る形で成り立っています。
UbuntuFedoraはこのディストリビューションの名前で、同じLinux系でも操作感や標準ツール、更新方針に違いがあります。
初学者が「Linuxを入れる」と言うとき、実際にはLinuxカーネルを土台にしたUbuntuのような配布形を選んで導入している、と捉えると全体像がつかみやすくなります。

この構造を最初に押さえておくと、「Linuxの本を読んだのに、自分の画面と少し違う」という戸惑いも整理できます。
たとえばコマンドの考え方やファイルシステム、権限の基本は多くのディストリビューションで共通ですが、パッケージの入れ方はUbuntuなら apt、Fedoraなら dnf というように入口の道具が変わります。
DigitalOceanのPackage Management Essentialsでも、Debian／Ubuntu系、Fedora／RHEL系、Arch系で管理ツールが分かれる前提で整理されています（詳細は公式サイト等で確認してください）。

Linuxが広く使われている理由は、学習用のPCだけで完結する存在ではないからです。
Webサーバーやデータベースが動くサーバー環境、クラウド上の仮想マシン、ラズパイやESP32と組み合わせるIoTの下準備、開発環境の土台としての『Docker』ホストまで、同じ考え方が横断的に通用します。
画面を見ながら操作するGUIも使えますし、端末でコマンドを打つCUIも使えます。
Linux Foundationの無料コースLFS101-JPやUbuntuのコマンドライン入門でも、初心者がGUIとコマンドラインの両方から学ぶ流れが自然な入口として扱われています。

筆者自身は、IoT工作の下準備やサーバーの基本操作では、最初からCUIに触れたほうが理解が早いと感じています。
たとえばファイルをどこに置いたか、サービスが起動しているか、権限が足りないのかといった問題は、端末で確認すると仕組みがそのまま見えます。
GUIは設定箇所を探す助けになりますが、学習の主役というより、詰まったときの補助として使うほうが知識がぶれません。
この感覚は、あとでリモート接続したLinuxサーバーを扱う段階でもそのまま生きます。

初心者がUbuntuから入る理由

とくにUbuntu 24.04 LTSは長期サポート（LTS）版で、一般的に標準サポート期間は5年と案内されています。
正式なサポート終了日は公式リリースノートで確認してください。
更新頻度の落ち着いた環境で基礎を固めたい人と相性が合います。
長期サポートの正式な年限はUbuntu公式の案内に従う前提です。
初心者向けの学習環境として安定運用を重視するなら、LTS を軸に考える意味があります。
Windows環境から始める場合も、この選択はそのまま使えます。
前のセクションで触れたWSLでもUbuntuを選んで学習を始められますし、Microsoft LearnのWSL で Linux を始めるでは、仮想マシンやデュアルブートを組まずにLinux環境へ入る流れが整理されています。
Windows 10 version 2004以降（Build 19041以降）またはWindows 11なら、Linuxの基本操作を試す入口としてWSLは収まりがよい構成です。

最初に学ぶ範囲は4つに絞ると迷いが減る

Linuxはできることが多いぶん、最初からネットワーク設定、サービス管理、カーネル、シェルスクリプトまで一気に追うと視界が散りやすくなります。
本記事で中核に置くのは、ファイルシステム、基本コマンド、権限、パッケージ管理の4つです。
ここが固まると、その先で『Docker』に進んでも、SSHでサーバーに入っても、何を見れば状態を把握できるかが見えてきます。

ファイルシステムでは、どこに何が置かれるのかを理解します。
基本コマンドでは、pwd、ls、cd、cp、mv、rm のような操作で「自分が今どこにいて、何を動かしたのか」を把握できる状態を目指します。
権限では、所有者・グループ・その他の3区分と、読み取り・書き込み・実行の r w x の組み合わせを理解することが土台です。
Red Hatの権限解説でも、この考え方を基準に整理されています。
パッケージ管理では、Ubuntu系なら apt と dpkg が基本になり、ソフトをどう入れてどう更新するかをここで覚えます。

このセクションは、Linuxを「何となく難しそうな黒い画面」ではなく、どの層を触っているのか、何から覚えれば手が止まらないのかを把握するための地図にあたります。
以降ではUbuntu 24.04 LTSを例に、導入後の初期設定や基本操作へ進みながら、この4つの軸を順番に固めていきます。

初心者におすすめの始め方3選｜WSL・仮想環境・実機インストール

Linuxの入口は1つではありません。
ここで迷いやすいのは「どれが正解か」ですが、実際には何を守りたいかで選ぶと整理できます。
Windows環境をそのまま残して最短で入りたいならWSL、OSを壊さずに何度でも試行錯誤したいなら『Oracle VM VirtualBox』のような仮想環境、本番に近い感覚で使いたいなら実機インストール、という切り分けです。
筆者は研修でもこの順番で案内していて、まずWSLでコマンドと権限の感覚をつかみ、次にVMのスナップショットで失敗を戻せる状態を作ると、操作ミスへの怖さが薄れて実機導入まで進む人が増えました。

比較の軸を先に置くと、選び方がぶれません。

方法	向いている人	メリット	デメリット	安全性	必要な準備
WSL	Windowsユーザー、まず学習を始めたい人	導入が速い、既存のWindows環境への影響が小さい、Linuxコマンド学習に直結する	GUI中心のLinux体験や実機周辺機器の扱いは限定される場面がある	高い	Windows 10 version 2004 / Build 19041以降、または Windows 11、管理者権限、初回再起動
仮想環境	OSを壊さず練習したい人	仮想マシンを丸ごと分離できる、スナップショットで戻せる、デスクトップ版Ubuntuを画面ごと試せる	メモリーとストレージを多めに使う、ホストOSより動作は重くなりやすい	高い	『Oracle VM VirtualBox』などの導入、ISOイメージ、初回再起動
実機インストール	本格運用したい人、古いPCを活用したい人	性能を引き出しやすい、Linux本来のブートやデバイス管理を体験できる、長く使う土台にしやすい	ディスク操作を伴う、既存データ消失のリスクがある、USB起動やUEFI設定で詰まりやすい	中	インストール用USB、ISOイメージ、バックアップ、再起動、ブート設定の変更

WSL（Windows Subsystem for Linux）：最短・安全な導入

Windowsを使っていて、まずLinuxのコマンドやファイル構成を学びたいならWSLがいちばん入りやすいです。
Microsoftの『WSL のインストール』でも案内されている通り、Windows 10 version 2004 / Build 19041以降に対応しています。
これらの環境では wsl --install で導入を始められます。
仮想マシンを自分で細かく組み立てなくても、Windows上にLinux環境を用意できるのが強みです。

この方法のよいところは、パーティション操作を伴わないことです。
ストレージを切り分けて既存OSを書き換える工程がないので、最初の事故ポイントが一気に減ります。
Linuxで最初に学ぶべき ls、cd、pwd、chmod、apt といった基本操作にすぐ入れるので、学習対象を絞り込みやすいんですよね。
Ubuntu系の環境を入れておけば、この記事の後半で扱う権限やパッケージ管理にもそのままつながります。

一方で、WSLは「LinuxそのものをPCに入れた感覚」とは少し違います。
たとえばブートローダー、USBメモリーからの起動、UEFIまわりの設定、実機のディスク構成といった要素は触れません。
つまり、Linuxの運用手前までを安全に学ぶ場所としては優秀ですが、OSインストールの実地練習にはなりません。
逆に言えば、そこを切り離して進められるので、初心者の最初の一歩として向いています。

導入後はGUIよりも端末を中心に使う形になります。
Microsoftの『WSL で Linux を始める』の流れに沿って、まずはホームディレクトリー、パッケージ更新、ファイル権限の確認まで触ると、Windowsとの違いがはっきり見えてきます。
最初から実機の起動トラブルまで抱え込むより、ここでLinuxの文法を先に覚えた方が、その後の切り分けが短く済みます。

{{product:0}}

Install WSL

Install Windows Subsystem for Linux with the command, wsl --install. Use a Bash terminal on your Windows machine run by

learn.microsoft.com

仮想環境（VirtualBox等）：壊さず練習・スナップショットで安心

「Windowsはそのまま残したいけれど、Ubuntuのデスクトップ画面も含めて体験したい」という場合は、仮想環境がちょうどよい立ち位置です。
代表例は無料で使える『Oracle VM VirtualBox』で、Windows上にもう1台の仮想PCを作り、その中にUbuntu 24.04 LTSを入れるイメージです。
ホストOSとゲストOSが分かれているので、失敗しても被害範囲をVMの中に閉じ込められます。

仮想環境の決め手は、スナップショットで戻せることです。
設定を崩した、パッケージの依存関係で詰まった、設定ファイルを編集しすぎて起動しなくなった、というときでも、前の状態へ戻せます。
筆者は研修でこの戻し先を最初に作る運用を標準にしていて、失敗しても数分前の状態に戻れるとわかるだけで、受講者の手が止まりにくくなりました。
実機インストール前にこの安心感を一度体験しておくと、Linuxへの苦手意識が残りにくいです。
仮想環境では、GUIとCUIを行き来しながら学べるのも大きな利点です。
ネットワーク設定、ソフトウェアの追加、エディタ操作、日本語入力の導入など、実機に近い手順を画面付きで追えます。
WSLが端末中心で進むのに対して、仮想環境ではUbuntu Desktopの画面構成ごと学べる点が特に有益です。

準備としては、『Oracle VM VirtualBox』本体の導入、UbuntuのISOイメージ、仮想マシン作成、初回起動時の再起動が基本です。
USBメモリー作成やパーティション変更が不要なので、実機より段取りは短く済みます。
OSインストールを練習したいけれど、今使っているPCを触りたくない人には、最初の本命になりやすい方法です。

{{product:1}}

Moved

docs.oracle.com

実機インストール：本来の体験と性能、ただしバックアップ必須

Linuxを日常的に使う前提なら、実機インストールがいちばん自然です。
OSの起動から電源管理、ストレージ、Wi-Fiや周辺機器とのやり取りまで、LinuxがPCを直接動かす状態になります。
古いPCを再活用したいケースとも相性がよく、Windowsでは重くなっていたマシンでも、用途を絞ればLinux機として息を吹き返すことがあります。
実機インストールの魅力は、仮想化レイヤーがない分だけ挙動が素直で、ハードウェアまわりの振る舞いをそのまま体験できる点です。
サーバー用途や常設の開発マシンを想定するなら、実機で覚えた知識がそのまま生きます。
古いPCの再活用にも向きますが、ディスク操作やUEFI設定といった工程が増えるため、事前のバックアップと手順確認は必須です。

実機での最大の注意点は、ディスク操作が伴うことです。
既存のWindows領域を触る構成では、操作を誤ると元の環境に戻す手間が大きくなります。
そのため、学習目的だけならメインPCよりも、使っていないノートPCや古いデスクトップの方が相性がよいです。
実機の成功率を上げる観点でも、筆者はWSLや仮想環境でLinuxの基本操作を先に済ませてから進む流れをよく採ります。
端末操作そのものに慣れていれば、実機で詰まったときに「インストール手順の問題」なのか「Linux操作の問題」なのかを分けて見られるからです。

{{product:2}}

迷ったら：目的別の決め方

判断を一文で言うなら、WindowsならWSL、壊したくないなら仮想環境、本格運用なら実機です。ここを起点にすると、選択で迷いにくくなります。

WindowsのノートPC1台で始めるなら、WSLが最短です。
再起動を挟んでも導入は軽く、既存環境への影響も小さいので、「まずLinuxの考え方を知りたい」という段階に合っています。
コマンド、権限、apt によるパッケージ管理まで触れれば、学習としては十分な入口になります。

Ubuntuのデスクトップ画面を含めて試したい、設定変更を何度もやり直したい、という目的なら仮想環境が合います。
『Oracle VM VirtualBox』のスナップショットは、学習中の保険として本当に効きます。
設定を崩す前に保存し、問題が起きたら戻すという流れがあるだけで、試行錯誤の量が増えます。
そこがそのまま理解の深さにつながります。

Linux機として継続利用したい、あるいは古いPCを再活用したいなら、実機インストールの価値が出てきます。
起動やストレージの扱いまで含めて経験できるので、サーバー運用や常設マシンへ進む土台になります。
学習順としては、WSLで入口を作り、次に仮想環境でUbuntu Desktopとインストールの流れをつかみ、その先で実機へ進むのが失敗を減らしやすい順番です。
まずはWSLからでも十分で、Linuxらしさをもっと体感したくなった段階で一段ずつ広げていくと、途中で手が止まりにくくなります。

関連記事Linuxファイル権限入門｜chmod・chownの使い方Linuxの権限は、ls -l の10文字表示と 644・755・777 の意味がつながった瞬間に、一気に見通しがよくなります。この記事は、chmod と chown の違いがまだ曖昧な人や、

Ubuntuを例にLinuxをインストールする手順

インストール前チェックリスト

今回の例はUbuntu 24.04 LTSです。
LTS は長期サポート版のことで、安定性を重視して使いたい人に向いています。
Ubuntu 24.04 LTSは一般に標準サポートが5年と案内されていますが、正式な終了日は公式ページで確認してください。

着手前に見ておきたい項目は次の5つです。

• インストール先のPCがUbuntu 24.04 LTSを動かす前提で使えること。
• 既存データのバックアップが終わっていること。
• インストール用のUSBメモリを用意していること。
• UEFI/BIOS でUSB起動に切り替える必要があることを把握していること。
• 初回セットアップや更新に使うインターネット環境があること

この中で最優先なのはバックアップです。
初心者の実機インストールでは、操作ミスそのものよりも「どの選択肢が消去を伴うのか」を読み切れない場面で事故が起きます。
とくにインストーラーの「ディスクを削除してインストール」に近い選択肢は、既存のOSや保存データを消す方向に進むため、意味を理解しないまま選ぶと戻せません。
前のセクションでも触れた通り、実機インストールはディスク操作リスクがある方法なので、ここだけは省略せずに進めます。

起動メニューの呼び出しキーは機種やメーカーで異なります（例：F12、Esc、Del など）。
実際の呼び出しキーはお使いのPCのマニュアルやメーカーサポートページで確認してください。

Step 1：Ubuntu 24.04 LTSのISOを入手

最初に行うのは、インストールイメージである ISO ファイルの入手です。
対象はUbuntu 24.04 LTSに絞ります。
LTS を選ぶ理由は、更新頻度よりも安定した利用を優先できるからです。
学習用でも常用機でも、最初の一台はこの系統の方が扱いやすくなります。

ダウンロード元はUbuntuの公式配布ページを使います。
ISO はOSそのものの土台なので、第三者配布サイトより公式から取る方が切り分けも簡単です。
途中でファイル名や保存先が分からなくなると、USB作成ツール側で選び直す場面で詰まるので、ダウンロード先フォルダは覚えておくと作業がつながります。

もし「いきなり実機は怖い」と感じる段階なら、先にMicrosoft Learnの『WSL のインストール』でWindows上からLinuxに触れておく方法もあります。
こちらは既存環境への影響が小さく、コマンドやパッケージ管理に慣れる入口として素直です。
そのうえで実機に進むと、インストール時の迷いが減ります。

Step 2：ブータブルUSBを作成

ISO を入手したら、次はUSBメモリをブータブルUSBに変換します。
Windows なら『Rufus』、Windows・macOS・Linux のいずれでも使いたいならbalenaEtcherが定番です。
どちらも無料で使えます。

『Rufus』は細かい設定まで触れるタイプで、UEFI や MBR/GPT まわりを調整したいときに便利です。
一方のbalenaEtcherは手順が少なく、ISO を選ぶ、書き込み先を選ぶ、書き込む、という流れが見やすいので、最初の1本なら迷いが出にくい構成です。

作業の流れは共通しています。

1. USBメモリをPCに接続する
2. 『Rufus』またはbalenaEtcherを起動する
3. ダウンロードしたUbuntu 24.04 LTSのISOを選ぶ
4. 書き込み先のUSBメモリを選ぶ
5. 書き込みを開始し、完了まで待つ

『Rufus』では項目がいくつか並びますが、Ubuntu の通常インストール用なら、まずは UEFI 前提の既定値を軸に進めれば十分です。
細かい設定を最初から触りすぎると、USB作成の失敗なのか起動設定の問題なのか見えにくくなります。

balenaEtcherは書き込み後の検証機能があるため、イメージ破損の見落としを減らせます。
反面、書き込み後にWindows側でドライブ表示が普段と変わって見えることがあり、そこで不安になる人もいます。
Ubuntu用の起動USBとしては珍しい挙動ではありません。

筆者の経験では、書き込み完了後にOS側で「安全な取り外し」操作を行ってからUSBを抜くと、起動トラブルの切り分けがしやすくなることがありました。
これはあくまで経験則であり、環境やツールによって効果は異なるため、書き込みツールの検証機能や公式ドキュメントも併せて確認することをおすすめします。

Rufus - 起動可能なUSBドライブを簡単に作成できます

rufus.ie

Step 3：UEFI/BIOSでUSBから起動

ブータブルUSBができたら、PC をそのUSBから起動させます。
ここは Linux の操作というより、PC の起動経路を切り替える段階です。
普段のOSではなくUSB上のインストーラーを先に読ませる必要があります。

方法は大きく2つあります。
ひとつは電源投入直後に起動メニューを開き、その場でUSBを選ぶやり方です。
もうひとつは UEFI/BIOS 設定画面に入り、ブート順でUSBを上位にして保存するやり方です。
前者は一時的な切り替えで済むことが多く、初回はこちらの方が扱いやすい場面が多めです。
迷いやすいポイントは3つあります。
まず、起動メニューにUSBが見えていても、内蔵SSDやWindows Boot Managerを選ぶといつものOSが立ち上がることです。
次に、Secure Boot が絡む場面です。
Secure Bootは署名されていないブートローダーの実行を防ぐ仕組みで、Linux 側でも配慮されていますが、起動に失敗したときの確認ポイントとして覚えておく価値があります。
もうひとつが保存操作で、ブート順を変えただけで画面を閉じると反映されず、再起動後に元のOSへ戻ることがあります。

USB起動に成功すると、Ubuntuの試用またはインストール画面が表示されます。ここまで来れば、ディスクに書き込む前の入り口は通過できています。

Step 4：インストーラーの各画面

インストーラーが起動したら、画面ごとに必要事項を選んでいきます。
ここで触るのは、言語、キーボード、タイムゾーン、インストール先、ユーザー作成です。
初心者が戸惑いやすいのはインストール先の選択なので、そこだけは一段丁寧に見ます。

まず言語です。
日本語で使うなら最初から日本語を選んで進めると、以後の画面表示も揃います。
次のキーボードレイアウトでは、日本語キーボードか英語キーボードかを実機に合わせます。
ここをずらしたまま進むと、記号の位置が合わず、パスワード入力で詰まります。

タイムゾーンは日本で使うなら日本時間に合わせます。
地域設定がずれると、ファイル時刻やログ時刻が想定と食い違います。
学習用途でも、あとでログを見るときに混乱のもとになります。

インストール先の画面は、最も慎重に見る場面です。
Ubuntu 専用機としてまっさらなPCに入れるのか、既存OSがあるディスクを触るのかで意味が変わります。
初心者が意味を理解しないまま「ディスクを削除」系の選択肢へ進むと、既存データを保持する余地がありません。
USBから起動できた安心感で先へ進みたくなる場面ですが、ここだけは「どのディスクに」「何を書き込むのか」を画面上で読み切ってから進めます。
古いPCをLinux専用に再活用するなら選択はシンプルですが、普段使いのPCでは判断が一段重くなります。

続いてユーザー作成です。
ここでは表示名、ログイン名、PC名、パスワードを決めます。
ログイン名はホームディレクトリ名にも関わるので、後から見ても分かる短い名前にしておくと扱いやすくなります。
パスワードは初回ログインだけでなく管理者権限を使う操作でも使います。
入力時のキーボード配列が合っているかもここで必ず確認してください。

画面の流れ自体は複雑ではありません。
迷う箇所はほぼ「どこに入れるか」と「消してよい対象はどれか」に集まります。
インストール開始後はファイルコピーと設定処理が進み、完了すると再起動を促されます。

Step 5：初回起動とネットワーク接続の確認

再起動後、USBメモリを外して内蔵ストレージから起動できれば、Ubuntu の初回起動は完了です。
ログイン画面が出たら、作成したユーザー名とパスワードで入ります。
もしUSBを挿したままだと、またインストーラー側へ戻ることがあるので、再起動のタイミングで外しておくと流れが切れません。

デスクトップが表示されたら、まずネットワーク接続を見ます。
有線ならリンクが上がっているか、Wi-Fi なら接続先が見えているかを確認します。
ブラウザでページが開けるかまで見ておくと、その後の更新作業に進める状態か判断できます。
初回セットアップ後は更新が入ることも多いため、ネットワークが不安定だと次の作業で止まります。

この段階で日本語入力や追加設定まで一気に触りたくなりますが、まずは「OSが単体で起動する」「ネットワークにつながる」という2点が通っていれば、インストール作業としては一段落です。
学習を進めるなら、基礎コマンドを順に触れる教材としてLinux Foundationの『Linux入門（LFS101-JP）』のような無料コースも相性がよいです。
初回起動直後のつまずきを減らせます。

Linux 入門 (LFS101-JP) ｜ Linux Foundation Education

この無料の Linux 入門コースで、グラフィカル インターフェイスとコマンド ラインの両方を使用して Linux に関する実践的な知識を深めましょう。

training.linuxfoundation.org

インストール直後にやる初期設定

まずは全体更新

インストール直後は、最初にパッケージをまとめて更新しておくと後の作業が安定します。Ubuntu では、まず次のコマンドを実行する流れが基本です。

sudo apt update && sudo apt upgrade -y

apt update は、いま利用できるパッケージ一覧を取得する処理です。
ソフト本体を更新するのではなく、「何が新しくなっているか」を手元に取り込む役目です。
続く apt upgrade -y は、その一覧をもとに実際の更新を適用します。-y は確認メッセージに自動で yes と答える指定なので、途中の対話を減らせます。

この1行を最初に入れておく理由は、初回起動直後の状態だと、インストールイメージ作成時点の古いパッケージが残っていることがあるからです。
ネットワークが通っているなら、先にここを整えた方が、その後の追加設定で余計な切り分けをせずに済みます。
筆者は新規セットアップのたびに、更新を入れて再起動し、その後に必要ならドライバ、続いて日本語入力まわりという順で進めています。
この並びにすると、入力方式の不具合なのか、更新不足なのかが混ざりにくく、原因を追いやすくなります。

更新のあとに再起動が必要になる場面もあります。
カーネルや低レイヤのライブラリが入れ替わったときは、いったん再起動して新しい状態で入り直した方が話が早いです。
デスクトップ用途でも、更新直後にWi-Fiや表示まわりの挙動が変わることがあるので、初手で再起動を1回はさんでおくと、そこから先の設定が素直に進みます。

コマンドラインにまだ慣れていないなら、Ubuntu公式のThe Linux command line for beginnersのような入門資料を横に置いておくとよいです。sudo やパッケージ操作の意味がつながりやすくなります。

タイムゾーンと時刻

時刻設定は地味ですが、ズレたままだとログの読み取りやファイル更新時刻の判断で混乱します。まずは現在の状態を確認します。

timedatectl status

この出力で、ローカル時刻、タイムゾーン、NTP の同期状態を見ます。
日本で使うなら、タイムゾーンが Asia/Tokyo になっているかを確認します。
ずれている場合は次のように設定できます。

sudo timedatectl set-timezone Asia/Tokyo
```bash
sudo timedatectl set-timezone Asia/Tokyo

この設定は後で journalctl や各種ログを見るときにも影響します。
ログ時刻と画面時刻がずれていると調査が止まることがあるため、初回にタイムゾーンを確認しておくと見通しが良くなります。

この設定は、あとで journalctl や各種ログを見るときにも効いてきます。
たとえばサービスの起動失敗やネットワークの切断時刻を追う場面では、「画面では朝9時に起きた問題なのに、ログでは深夜0時台に見える」という食い違いがあるだけで、調査の流れが止まります。
Linux を学び始めたばかりの時期ほど、時刻が正しいだけで見通しが一気によくなります。

WSL や仮想環境ではホスト側と時刻がそろうことが多いものの、初回セットアップ直後に timedatectl status を一度見る習慣をつけておくと、実機でもサーバーでも同じ目線で確認できます。
タイムゾーンは見た目の設定ではなく、ログ運用の土台そのものです。

localeと日本語入力の考え方

日本語環境は、表示言語の設定 と 日本語を打つための入力方式 を分けて考えると整理できます。
ここがごちゃつくと、「画面を日本語にしたいのか」「ターミナルやブラウザで日本語入力したいのか」が曖昧になり、不要な設定変更まで触りがちです。

locale は、システムがどの言語・文字コード・地域設定で動くかを決める仕組みです。現在の状態は次のコマンドで確認できます。

locale

ここで LANG や LC_* に日本語系の設定が入っていれば、日本語表示寄りの構成です。
一方、学習用や開発用では、システムメッセージは英語のままにしておく運用もよくあります。
エラーメッセージを検索しやすく、公式ドキュメントの記述とも一致しやすいからです。
筆者も、サーバー寄りの用途では英語表示のまま使うことが多く、必要なのは画面の日本語化ではなく、日本語が入力できる状態だけという場面が少なくありません。

そのため、初期設定では「OS全体を日本語化するか」よりも、「まず時刻と更新を整え、必要ならあとから日本語入力を追加する」という順番の方が失敗が少ないです。
Ubuntu Desktopなら日本語表示の導線もありますが、無理に最初から全部を日本語に寄せなくても困りません。
特にコマンド学習中は、英語のままのプロンプトやメッセージに慣れておくと、書籍や海外記事ともつながります。

日本語入力が必要になったら、Mozc系を追加する方法が定番です。
Ubuntuでは ibus-mozc を使う構成や、fcitx5-mozc を使う構成がよく選ばれます。
たとえば sudo apt install ibus-mozc や sudo apt install fcitx5-mozc という形で導入する例が広く使われています。
どちらを選ぶかで設定の流れは少し変わりますが、考え方は同じで、「入力フレームワーク」と「日本語変換エンジン」を組み合わせて使います。
表示言語の設定と、日本語を打つための設定は別物だと理解しておくと、ここで迷いません。

apt/dpkg と dnf/yum の違い

Linux を触り始めると、まず覚える管理の基本がパッケージ操作です。
Ubuntu系では apt を多く使いますが、その下には dpkg があります。
この2つは役割が違います。

apt は、リポジトリから必要なパッケージを探し、依存関係ごとまとめて入れたり更新したりするための入口です。
ふだんの install、update、upgrade は主にこちらを使います。
一方の dpkg は、.deb パッケージを直接入れる低レベル寄りの道具です。
依存関係を自動で解決する役割は薄いので、初心者のうちは apt を中心に触る方が流れをつかみやすくなります。

たとえばDigitalOceanの『Package Management Essentials』でも、apt と dpkg、さらに yum や dnf の関係を分けて説明しています。
ざっくり言えば、DebianUbuntu系は apt と dpkg です。
FedoraRHEL系は dnf と yum、Arch Linux系は pacman という対応です。

ここで押さえたいのは、「コマンド名が違っても、やっている仕事は似ている」という全体像です。
パッケージを検索する、導入する、更新する、削除するという基本動作はどの系統にもあります。
いま使っているのがUbuntuなら、まずは apt search、apt install、apt remove、apt upgrade の4つを読めるようになるだけで十分です。dpkg は .deb を直接扱う必要が出たときに思い出せば足ります。

この違いを早めに意識しておくと、将来Rocky LinuxやFedoraの記事を読んだときも、「dnf はUbuntuでいう apt 側の役割だな」と頭の中で対応づけできます。
Linux はディストリビューションごとに作法が違って見えますが、パッケージ管理の見取り図がつかめると、表面の違いに振り回されにくくなります。

Package Management Essentials: apt, yum, dnf, pkg ｜ DigitalOcean

Learn how apt, yum, dnf, and pkg manage software on Linux and FreeBSD. Compare commands, workflows, and best practices.

digitalocean.com

Linuxの基本操作｜最初に覚えるコマンド10選

インストール直後は、まず「今どこにいて、何が見えていて、どう移動するか」が分かれば手が止まりません。
Linux のコマンドは数が多く見えますが、最初はファイル操作の流れに沿って覚えると頭に入りやすくなります。
Ubuntuの初心者向けチュートリアルであるThe Linux command line for beginnersも、現在地の確認と一覧表示から入っています。
筆者もこの順番で教えることが多く、コマンド名を暗記するより、実際に1つずつ打って結果を見るほうが定着します。

作業ディレクトリと移動

最初の3つは pwd、ls、cd です。
これだけで「現在地を知る」「周囲を見る」「別の場所へ行く」ができます。
ターミナルで迷う原因の多くは、実はコマンドそのものではなく、どこで作業しているかを見失うことです。

pwd は print working directory の略で、いまいるディレクトリの絶対パスを表示します。

pwd

たとえば /home/mai と出れば、ホームディレクトリにいる状態です。
まず pwd を打つ癖があるだけで、「ファイルを作ったのに見つからない」という初歩的な詰まりが減ります。

ls は、その場所にあるファイルやディレクトリを一覧表示するコマンドです。

ls
ls -l
ls -la

ls -l は初心者のうちから使う価値があります。
権限、所有者、サイズ、更新日時まで一度に読めるからです。
筆者は受講者に ls -l で権限・所有者・サイズ・更新日時を読む癖を付けてもらうのですが、その後のトラブル対応の速さが目に見えて変わります。
単に「あるかないか」ではなく、「誰のファイルで、いつ更新され、どの権限か」を見られるようになると、削除できない、編集できない、想定と違うファイルを見ていた、といった問題の切り分けが早くなります。

cd は移動です。相対パスと絶対パスの両方を使います。

cd /home
cd /home/mai
cd ..
cd ~

cd .. は1つ上の階層、cd ~ は自分のホームディレクトリに戻ります。たとえば次のように打つと、移動の感覚がつかめます。

pwd
cd /tmp
pwd
cd ~
pwd

この3行だけでも、パスがどう変わるかを目で追えます。
Linux は画面上のフォルダをクリックする代わりに、文字で移動先を指定する世界です。
だからこそ pwd と ls と cd が最初の土台になります。

ファイルとディレクトリの作成/整理

移動できるようになったら、次は自分で何か作って動かしてみます。mkdir、touch、cp、mv、rm の5つが分かると、日常的な整理作業の大半に触れられます。

まずは練習用の場所を作ります。mkdir はディレクトリ作成です。

mkdir linux-practice
cd linux-practice
mkdir notes
ls -l

これで linux-practice の中に notes が作られます。
ディレクトリをまとめて作るときは mkdir -p もよく使いますが、最初は1階層ずつ作るほうが構造を理解しやすくなります。

touch は空ファイルの作成や更新日時の変更に使います。最初は「空のメモを置く」感覚で十分です。

touch memo.txt
touch notes/todo.txt
ls -l

新規ファイルは一般に基本パーミッションが 666、新規ディレクトリは 777 を土台にして、実際には umask で差し引かれた権限で作られます。
ここでは細かい仕組みまで追わなくても、ls -l で結果を読むことに集中すれば十分です。

cp はコピーです。元を残したまま複製します。

cp memo.txt memo-backup.txt
cp notes/todo.txt notes/todo-copy.txt
ls -l

mv は移動ですが、同じ場所で使うと名前変更にもなります。

mv memo-backup.txt archive.txt
mv archive.txt notes/
ls -l
ls -l notes

この「移動と改名が同じコマンド」という点は、GUI に慣れていると最初だけ少し引っかかります。
ただ、実態としては「ファイルの場所や名前を変える操作」と考えるとまとまります。

rm は削除です。ここは意味を曖昧に覚えないほうが安全です。

rm memo.txt

ファイル1つならこれで消えます。
ディレクトリを削除するときに出てくるのが -r と -f です。-r は再帰的に削除する指定で、ディレクトリの中身ごと辿って消します。-f は確認なしで強制的に進める指定です。
つまり rm -rf は「中身ごと、確認を飛ばして削除する」動きになります。
意味を分解して理解していないまま使うと危険です。

安全寄りに使うなら、まずは確認つきの実行を混ぜると事故が減ります。

rm --interactive archive.txt
rm -r --interactive notes

--interactive を付けると、削除前に確認が入ります。alias rm='rm -i' のような運用を好む人もいますが、初心者のうちはまずオプションの意味を明示的に読めるほうが学習になります。
デスクトップ環境ではゴミ箱に入れる運用もありますが、rm 自体は基本的にゴミ箱を経由しません。
消した時点で「戻す前提ではない削除」だと捉えたほうが、コマンドの重みを理解できます。

中身を確認する

ファイルの存在が見えても、中に何が入っているか分からなければ作業は続きません。
ここで覚えたいのが cat と less です。
どちらも中身を見るためのコマンドですが、用途が違います。

cat は短いファイルを一気に表示するときに向いています。たとえば自分で1行だけ入れたメモを確認する場面です。

echo "Linux practice" > memo.txt
cat memo.txt

出力結果がそのまま画面に表示されるので、設定ファイルや短いテキストの確認に便利です。ただし行数が多いファイルだと一気に流れて読みづらくなります。

そこで使うのが less です。

less /etc/passwd

less は1画面ずつ読めるビューアです。
矢印キーや PageDown で進み、q で終了します。
ログや設定ファイルの確認では cat より less のほうが扱いやすい場面が多く、実務でも登場頻度は高めです。
「中身を見るだけで編集はしない」という距離感も初心者にはちょうどいいです。

最初の練習としては、次の流れが分かりやすいです。

mkdir ~/linux-practice
cd ~/linux-practice
touch memo.txt
echo "hello linux" > memo.txt
cat memo.txt
less memo.txt

同じファイルでも、cat は一気に表示、less はページ送りで確認、という違いが体感できます。
手を動かしておくと、設定ファイルやログを開いたときに慌てません。

権限と管理者操作の入口

Linux に慣れていないうちは、「ファイルがあるのに編集できない」「コマンドが拒否される」で止まりがちです。
その入口にあるのが chmod と sudo です。

chmod はファイルやディレクトリの権限を変更します。
よく見る rwx は、読み取り、書き込み、実行を意味します。
代表例として覚えやすいのが 644 と 755 です。644 は一般的なテキストファイル、755 は実行可能なスクリプトやディレクトリでよく見ます。

touch script.sh
ls -l script.sh
chmod 755 script.sh
ls -l script.sh
chmod 644 script.sh
ls -l script.sh

このように ls -l とセットで見ると、権限変更が文字列としてどう反映されるかが分かります。
先頭の -rwxr-xr-x や -rw-r--r-- を読めるようになると、実行できない理由や書き込めない理由を自分で説明できるようになります。

sudo は管理者権限でコマンドを実行するための入口です。
システム全体に関わる設定変更やパッケージ操作で使います。
たとえば前のセクションでも触れた apt の操作は代表例です。

sudo apt update
sudo apt install nano

sudo は「何でも通す魔法の言葉」ではなく、「通常ユーザーでは触れない領域に一時的に入る」ための仕組みです。
たとえば /etc 配下の設定変更や、システム全体へのインストールが該当します。
日常作業を全部 sudo 付きで行う必要はありません。
むしろ通常ユーザーでできることと、管理者権限が必要なことを分けて理解したほうが、事故も減って学習も進みます。

ファイルシステム階層の基本

コマンドを覚えるのと同じくらい、Linux の「どこに何があるか」をざっくり知っておくと迷いにくくなります。
全部暗記する必要はありませんが、よく出る場所は押さえておくと cd や less が急に意味を持ちます。

図にすると、こんなイメージです。

/
├── home   ユーザーの作業場所
├── etc    設定ファイル
├── var    ログや可変データ
├── tmp    一時ファイル
└── usr    コマンドや共有プログラム

/ はルートで、すべての起点です。Windows の C:\ に少し近い立場ですが、Linux ではここから全部が木構造でつながっています。

/home は各ユーザーの作業領域です。
最初に触るファイルの多くはここに置かれます。
自分のホームディレクトリは ~ と表せるので、cd ~ がすぐ戻るコマンドとして便利です。

/etc はシステム設定の置き場です。
たとえばサービス設定やネットワーク設定など、管理対象のファイルがここに集まります。
編集には sudo が必要になる場面が多く、「管理者権限が必要な場所」の代表格として覚えると理解が進みます。

/var はログやキャッシュ、アプリケーションが変化させるデータの保管場所です。
ログ確認の文脈で見かける /var/log はその典型です。
あとでトラブル調査に進むと、この階層の意味が効いてきます。

/tmp は一時ファイルの場所です。
ちょっとした検証や捨てても困らない作業ファイルを置くのに向いています。
前半で cd /tmp を試したのは、この場所が「練習で触っても心理的な負担が少ない」からでもあります。

/usr には多くのコマンドや共有プログラムが入っています。
普段は直接いじるより、「インストールされたコマンドが配置される側の大きな領域」と捉えておくと十分です。

この階層がぼんやりでも見えてくると、コマンドは単なる呪文ではなくなります。pwd で今いる場所を知り、ls -l で中身と属性を読み、cd で移動し、mkdir や touch で作り、cp、mv、rm で整理し、cat や less で確認する。
そこに chmod と sudo が加わると、インストール直後の Linux で何を触ればいいかが一本の流れとして見えてきます。

ファイル権限とsudoの基礎

ls -l の見方とr/w/xの意味

ls -l を見ると、Linux がそのファイルを「誰にどこまで許可しているか」が一行で分かります。たとえば次のような表示です。

-rw-r--r-- 1 mai mai 1200 sample.txt
drwxr-xr-x 2 mai mai 4096 public

先頭の - や d は種類を表します。- は通常のファイル、d はディレクトリです。
その後ろの rw-r--r-- や rwxr-xr-x がパーミッションで、3文字ずつ 所有者、グループ、その他 の順に並んでいます。
英語では user、group、other です。

rw-r--r-- を分解すると、所有者は rw- なので読み取りと書き込みができ、実行はできません。
グループは r-- で読み取りだけ、その他も r-- で読み取りだけです。rwxr-xr-x なら、所有者は読み取り・書き込み・実行、グループとその他は読み取りと実行だけができます。

r は read、w は write、x は execute です。
ただしディレクトリでは少し意味が変わります。
ファイルでの x は「実行できる」、ディレクトリでの x は「その中に入れる、たどれる」という意味になります。
だからディレクトリでは r だけあっても中に自由に入れるわけではありません。
一覧を見る権限と、その中をたどる権限は別です。

ls -l の mai mai のように見える部分は、左が所有者、右がグループです。
たとえば自分が作ったファイルでも、グループ設定によっては共同作業ユーザーに書き込みを渡せますし、逆に other まで広げると関係ないユーザーにも影響します。Permission denied が出たときは、ここを読むだけで原因が見えることが少なくありません。

chmodの基本

chmod は、この rwx を変更するコマンドです。
初心者のうちは数値表記だけ覚えると整理しやすくなります。
各桁は所有者、グループ、その他を表し、r=4、w=2、x=1 を足し算します。

chmod 644 sample.txt
chmod 755 script.sh
chmod 775 shared-dir
chmod 664 team.txt

644 は所有者が rw-、グループが r--、その他が r-- です。
一般的なテキストファイルでよく見ます。755 は所有者が rwx、グループが r-x、その他が r-x で、ディレクトリや実行可能スクリプトの定番です。775 は所有者とグループに書き込みを許し、共同作業用ディレクトリで使われます。664 はファイルをグループで更新したいときの形です。

777 は全員に rwx を与える設定です。
つまり、所有者でもないユーザー、同じグループでもないユーザーまで書き込みできます。
これが危険なのは、動けばよいという一時しのぎで終わらず、あとから「誰でも書ける状態」が残るからです。
Web アプリのアップロード先や公開ディレクトリでこれをやると、意図しない上書きや改ざんの入口になります。
筆者は Web ルートを 755 と 644 で運用し、書き込みが必要なディレクトリだけを最小権限に絞る形を基本にしています。
現場でも「とりあえず 777」で通して後から権限設計をやり直す例を何度も見てきました。

数字だけを機械的に覚えるより、「誰に書き込みを渡しているか」を一緒に考えると事故が減ります。
たとえば公開用の HTML や設定ファイルなら、other に書き込みを与える理由は普通ありません。
実行する必要がないファイルに x を付ける必要もありません。
権限は多いほど便利ではなく、必要な分だけ与えるのが基本です。

umaskで決まる初期パーミッション

ファイルやディレクトリを新しく作ったときの権限は、毎回ゼロから手で決めているわけではありません。
もともとの基本値があり、そこから umask で権限が引かれます。
Red Hatのファイルシステム権限の管理でも、この考え方が整理されています。

新規ファイルの基本パーミッションは 666、新規ディレクトリの基本パーミッションは 777 です。
ただし、ファイルは最初から実行可能にする前提ではないため、実際には umask で引かれて 644 になることが多いです。
ディレクトリは入れる必要があるので、777 から引かれて 755 になる形がよく出てきます。

たとえば umask 022 なら、ファイルは 666 - 022 = 644、ディレクトリは 777 - 022 = 755 になります。umask 002 なら、グループに書き込みを残すので、ファイルは 664、ディレクトリは 775 です。
チーム開発や共有ディレクトリで 664 や 775 を見かけるのはこのためです。

umask
touch note.txt
mkdir work
ls -l note.txt
ls -ld work

ここで ls -ld work としているのは、ディレクトリ自身の権限を見るためです。
初心者が詰まりやすいのは、「自分で chmod していないのに、なぜ最初から 644 なのか」という点ですが、答えは umask にあります。
既定値を知っておくと、毎回の見え方に納得がいきます。

sudoはどんなときに必要か

sudo は、一時的に管理者権限でコマンドを実行する仕組みです。
普段のユーザー権限では触れない場所や操作に入るための入口と考えるとつかみやすいです。
システム全体に影響する作業、たとえば /etc の設定変更、パッケージのインストール、サービス管理、システム領域への書き込みでは sudo が必要になります。

sudo apt install nginx
sudo nano /etc/hosts

この種の操作はシステム全体に影響する可能性があるため、編集前に内容を確認し、必要ならバックアップを取ってから実行してください。

逆に、自分のホームディレクトリの中でファイルを作る、編集する、削除するといった日常作業では不要です。ここで毎回 `sudo` を付けると、作ったファイルの所有者が `root` になり、あとで通常ユーザーでは編集できないという別のトラブルを生みます。初心者が `sudo` を乱用すると、最初の問題は消えても、次の問題が増えることが多いです。

`sudo` を使える人は、`sudoers` の考え方で許可されたユーザーです。つまり、誰でも管理者になれるわけではなく、「このユーザーにはこの権限を委ねる」という設定の上で成り立っています。だから `sudo` は万能コマンドではなく、管理作業の境界線をまたぐための仕組みです。

判断基準はシンプルで、「その操作がシステム全体を変えるかどうか」です。自分の作業領域なら通常ユーザー、OS の設定や全ユーザーに関わる変更なら `sudo` です。この線引きが見えてくると、`Permission denied` を見たときも反射的に `sudo` を足さずに済みますし、権限の問題と所有者の問題を切り分けて考えられるようになります。

{{related:ssh-connection-guide}}

## よくあるトラブルと対処法

### 起動系

Linux を触り始めた直後は、インストールより前の「そもそも起動しない」で止まりがちです。実機インストールでは USB から立ち上がらない、Windows では WSL が開かない、この2つが定番です。ここは闇雲に設定をいじるより、起動経路を順番に分けて見たほうが早く進みます。

USB から起動しないときは、まずインストール用 USB 自体を疑います。筆者の経験では、同じ ISO でも 『Rufus』 で作ると通り、balenaEtcher で作ったものでは起動メニューに出ない、あるいはその逆ということがあります。こういう場面では USB を作り直し、ツールを変え、PC の別ポートに挿し替え、必要なら別の USB メモリーに替えるだけで通ることがあります。とくに UEFI 起動では、書き込み時の方式やメディアの相性で最初の1歩が詰まります。

それでも起動しないなら、UEFI の起動順を見ます。USB がブート対象の先頭になっていないと、内蔵ストレージの Windows がそのまま立ち上がります。加えて Secure Boot が有効なままだと、署名まわりでブートローダが弾かれることがあります。Linux 側が対応していても、USB 作成の状態と噛み合っていないと起動まで進みません。ここで「USB を認識していない」のか「認識はしているが起動対象に選ばれていない」のかを分けて考えると、原因が絞れます。

WSL が起動しない場合は、要件・仮想化・権限の3点を見るのが近道です。Microsoft Learnの『WSL のインストール』では、Windows 10 version 2004 以降か Windows 11 が前提として案内されています。要件を満たしていても、BIOS 側で CPU の仮想化機能が無効だと途中で止まりますし、`wsl --install` を管理者権限なしで実行して失敗することもあります。初回セットアップ後の再起動も抜けやすいポイントです。

筆者は WSL の不調に当たったとき、いきなり設定を増やすより `wsl --shutdown` で一度止めてから Windows を再起動する流れを先に試します。これで直るケースは珍しくありません。原因特定では、症状が出るまでの操作を短く書き出して、その時刻とログの時刻を突き合わせると一気に進みます。たとえば「端末を開く」「`wsl` を実行する」「数秒後に終了する」とメモしておくと、あとでどのログを見るべきか迷いません。

### 権限・sudoまわり

`sudo` 付きでコマンドを打ったのに失敗する場合、まず見るべきなのは「そのユーザーに sudo 実行権があるか」です。Ubuntu 系では、対象ユーザーが `sudo` グループに入っていないと管理権限を借りられません。ここが抜けていると、コマンド自体が正しくても先へ進めません。

一方で、権限エラーを見た瞬間に何でも `sudo` を付ける流れも別の詰まりどころになります。ホームディレクトリ内の作業にまで `sudo` を混ぜると、作成されたファイルの所有者が `root` になり、あとから通常ユーザーで編集できなくなります。前のセクションで触れた通り、`sudo` は管理操作の境界をまたぐときだけ使うほうが事故を減らせます。筆者も設定ファイル編集では、必要なコマンドだけに `sudo` を付け、パイプやリダイレクト全体を root で流さない形をよく使います。権限を上げる範囲が狭いほど、壊す面積も小さくなります。

ファイルやディレクトリの権限エラーでは、先に `ls -l` で所有者とモードを見ます。ここを見ずに `chmod 777` へ飛ぶと、原因の切り分けが止まります。たとえば自分のファイルなのに書けないなら、所有者ではなく書き込みビットの問題かもしれません。所有者が `root` なら `chown` の話です。Red Hatの『ファイルシステム権限の管理』でも、所有者・グループ・権限を分けて考える流れが整理されています。

修正は最小権限が基本です。所有者が違うなら `chown`、読み書きの範囲が合っていないなら `chmod` を使います。公開用ファイルなら `644`、実行が必要なディレクトリなら `755` といった定番がありますが、ここでも「誰に書き込みが必要か」を先に決めるほうがぶれません。読みたいだけのユーザーに書き込みを渡すと、動作確認の時点では目立たなくても、後から別のトラブルに変わります。

> [!TIP]
> [!NOTE]

{{ogp:https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/9/html/configuring_basic_system_settings/managing-file-system-permissions_configuring-basic-system-settings|第9章 ファイルシステムの権限の管理 ｜ 基本的なシステム設定 ｜ Red Hat Enterprise Linux ｜ 9 ｜ Red Hat Documentation||}}

### 更新・パッケージのエラー

パッケージ更新で詰まったときは、まず `apt update` と `apt upgrade` のどちらで止まっているかを分けます。`apt update` はパッケージ一覧の取得、`apt upgrade` は実際の更新です。前者で失敗しているならリポジトリ情報や鍵、通信まわり、後者で失敗しているなら依存関係や途中で壊れた状態を疑う、という見方ができます。エラーメッセージは長く見えますが、先頭から全部読むより「どのパッケージで」「何が足りないのか」を拾うほうが実務では早いです。

`.deb` ファイルを `dpkg -i` で直接入れたあとに依存エラーが出るのも典型例です。この場合、`dpkg` は指定されたパッケージを展開するところまで進めても、必要な依存パッケージを自動では解決しきれないことがあります。そんなときは `apt install -f` で不足分の依存を補完すると復旧できる場面があります。筆者も手元検証で `.deb` を先に入れて依存関係を崩したときは、無理に再インストールを重ねるより、この経路で整えることが多いです。

サービスが更新後に起動しなくなった場合は、パッケージの問題とサービスの問題を切り分けます。まず `systemctl status サービス名` で現在の状態を見て、`Loaded` や `Active`、終了コードを確認します。そのうえで `journalctl -u サービス名 -n 50` のようにサービス単位のログを見ると、設定ファイルの文法ミスなのか、依存サービス待ちなのかが追いやすくなります。`systemctl status` と `journalctl` をセットで見る流れは、遠回りに見えて最短です。

カーネルやデバイス認識が絡みそうなら `dmesg` も入口になります。USB ストレージ、ネットワーク、ファイルシステムのエラーは、アプリケーション側ではなくカーネル側に先に出ることがあります。起動直後からおかしいときは `journalctl -b`、前回の起動で失敗した内容を見たいなら `journalctl -b -1` という見方も有効です。筆者は再現手順を書いてからログ時刻を突き合わせるやり方をよく取りますが、この順番だと「どのコマンドの直後に異常が出たか」が見えやすく、ログの海で迷いにくくなります。

### 容量不足とログの見方

更新が失敗したり、一時ファイルが作れなかったり、アプリの動作が急に不安定になったりするとき、原因がディスク容量不足ということは珍しくありません。Linux では空き容量ゼロ付近まで使い切ると、単に保存できないだけでなく、ログ書き込みやパッケージ展開にも影響が出ます。まず `df -h` でどのファイルシステムが埋まっているかを見て、次に `du -sh` で大きいディレクトリを当たり、場所を特定します。

埋まりやすい場所は `/var/log`、パッケージキャッシュ、ホームディレクトリ配下の不要ファイルです。ログが膨らんでいるなら古いログの整理、キャッシュが残っているなら不要分の削除で戻せることがあります。仮想環境ではスナップショットやイメージが積み上がって想像以上に食うこともあります。見える場所だけ掃除しても空きが戻らないときは、仮想ディスクやコンテナ関連の保存領域まで視野を広げると詰まりがほどけます。

ログを見る入口も、役割を分けると迷いません。`journalctl` は systemd 配下のシステムログを見るときの中心で、サービス単位にもブート単位にも追えます。`dmesg` はカーネルリングバッファを見るコマンドで、起動時のハードウェア認識やドライバの警告を拾うのに向いています。`systemctl status` はサービスが今どういう状態かをつかむための最初の窓口です。つまり、サービスが落ちているなら `systemctl status`、その理由を掘るなら `journalctl`、USB やストレージ認識そのものが怪しいなら `dmesg`、という並びです。

容量不足とログ確認は別の話に見えますが、実際にはセットで扱うことが多いです。空きが尽きるとログ自体が残りにくくなり、原因調査の材料まで減ります。逆に、ログを追うと「No space left on device」のように症状がそのまま出ていることもあります。症状だけ眺めるより、ディスク使用量とログ時刻を一緒に見るほうが、手がかりが具体的になります。

## 次に進む学習ロードマップ

GUIで触っていた操作を、少しずつ端末から再現できるようになると、Linuxは「見慣れないOS」から「自分で扱える道具」に変わります。次に進むなら、画面上のボタンを探す学び方から、コマンドで状態を確かめて操作する学び方へ軸足を移すのがおすすめです。無料で体系的に復習したいなら、Linux FoundationのLFS101-JPが入口としてまとまっていて、断片知識を一本の線につなぎやすくなります。Ubuntuを入れて終わりではなく、端末、ネットワーク、コンテナ、そしてRaspberry Piまでつながる流れで触れると、学びが急に立体的になります。

### 端末操作・テキストエディタ

最初の一歩は、GUI中心の操作からCUI中心の操作へ寄せることです。ファイルを開く、移動する、編集する、保存するという日常動作を、端末で繰り返してください。`cd` や `ls` で移動と確認をしながら、設定ファイルを `cat` で眺め、必要ならテキストエディタで直す。この流れが自然になると、トラブル対応でも迷いにくくなります。

テキストエディタは、まずnanoで十分です。画面下にショートカットが出るので、保存と終了の流れを体で覚えやすく、サーバー上の軽い修正にもそのまま使えます。そこからVimに進むと、最初はモード切り替えに戸惑っても、設定ファイルを何度も触る人ほど恩恵を受けます。筆者は初心者に対して、最初からどちらか一方に絞り込むより、nanoで編集を怖がらなくなってからVimの移動と保存だけ覚える順番を勧めています。

ファイル権限もこの段階で一緒に見ると理解がつながります。新規ファイルの基本パーミッションは 666、新規ディレクトリーは 777 が土台になり、実際には umask を通して少し絞られます。ここで `chmod 644` や `755` の意味が腹落ちすると、設定ファイルと実行ファイルを見分ける視点が育ちます。数字を暗記するより、読めるのか、書けるのか、実行できるのかを端末上で確認する癖を付けるほうが伸びます。

### パッケージ管理とシェルスクリプト

端末に慣れてきたら、次はパッケージ管理を深掘りしてください。Ubuntuなら `apt update` と `apt upgrade` をただ打つだけで終わらせず、どのリポジトリから何を取得しているのか、依存関係がどう解決されるのかを見る段階に入ると、システムの見え方が変わります。ibus-mozcやfcitx5-mozcのような日本語入力も、手で入れて設定する経験があると、GUIの設定画面だけでは見えない構造がつかめます。

その次に効いてくるのがシェルスクリプトです。毎回同じコマンドを順番に打っているなら、自動化の余地があります。バックアップ、ログ確認、更新、サービス再起動のような定型作業は、小さなスクリプトに切り出すだけで操作の抜け漏れが減ります。最初は `#!/bin/bash`、変数、`if`、`for`、終了コードを見る程度で十分です。Linuxを使いこなす人ほど、派手なツールよりも、毎日の細かな反復をシェルに預けています。

> [!TIP]
> 端末学習が止まりにくいのは、「毎日1つだけ自動化する」と決めたときです。たとえば更新前に日付を出す、ログを50行だけ表示する、特定ディレクトリをまとめて圧縮する、といった小粒の題材なら挫折しにくく、書いたスクリプトがそのまま自分用の道具になります。

### SSHでのリモート運用

Linuxの学習が一段進んだと感じやすいのは、別のマシンに入って作業できるようになったときです。`ssh` で接続し、`scp` でファイルを送り、遠隔のサービス状態を確認する流れは、ローカル端末の延長にあります。ここでネットワークの基礎も一緒に押さえておくと、接続できない理由を切り分けやすくなります。IPアドレス、名前解決、ポート、どのサービスがどの待ち受け口を使うか。このあたりが曖昧なままだと、Linuxの問題なのかネットワークの問題なのかを分けられません。

リモート運用では、`systemctl status` と `journalctl` を遠隔で見られるようになると世界が広がります。自分の手元で動かないのではなく、離れた場所のLinuxを保守する感覚が生まれるからです。学習対象としては、まず自宅内の1台で十分です。古いノートPCでもWSLの先でもよいので、別端末から `ssh` で入って、設定ファイルを `nano` で直し、ログを追って、必要なら `scp` で持ってくる。この往復ができると、サーバー運用の入口に立てます。

### Docker/Composeでサービスを育てる

Linux操作に慣れてきたら、『Docker』でサービスを1つ動かしてみると、学んできた知識がまとまります。イメージを取得して、コンテナを起動して、ポートを割り当て、ログを見る。ここにはプロセス管理、ネットワーク、ファイル配置、設定の分離といった要素が凝縮されています。『Docker Engine』はLinux上のコンテナ実行基盤で、『Docker Desktop』はWindowsやmacOSで使うための周辺機能を含んだ別物です。この違いが見えると、ローカル開発とサーバー運用の境界も整理できます。

筆者は自宅の『Home Assistant』運用で『Docker』を活用していますが、理解が一段進んだのは、最初に1コンテナだけ動かし、その後で『Docker Compose』に広げたときでした。単体コンテナの段階では「動いた」で終わりがちでも、複数サービスをまとめて起動・停止・更新するようになると、設定ファイルで構成を表現する意味が見えてきます。『Docker Compose』は現在のV2系では `docker compose` とCLIに統合されていて、アプリ本体、データベース、キャッシュのような組み合わせを一つの定義で扱えます。

自宅サーバーや検証環境を育てるなら、この順番が効率的です。いきなり大規模構成に行くより、Webアプリ1つ、次にDBを追加、必要ならリバースプロキシを足す、という積み上げのほうが、どこで壊れたか追いやすくなります。コンテナは魔法ではなく、Linux上で動く整理されたプロセス群だと実感できると、ログやボリュームの扱いにも納得感が出ます。

{{ogp:https://docs.docker.com/|Home|Docker Documentation is the official Docker library of resources, manuals, and guides to help you containerize applicati|}}

### Raspberry Pi・IoTへの展開

Linux学習を趣味の実物に接続したいなら、Raspberry PiやIoT機器への展開がよい流れです。小型で常時動かしやすいマシンにLinuxを載せると、単なる勉強用OSではなく、家の中で役割を持つ機械になります。ファイル共有、VPN、センサー収集、スマートホーム連携など、題材に困りません。『Home Assistant』も公式に複数の導入方式を用意していて、Raspberry Pi系の常設運用と相性がよい題材です。

ここで生きるのが、端末操作、パッケージ管理、SSH、Dockerの積み重ねです。ラズパイをネットワークにつなぎ、`ssh` で入り、必要なパッケージを入れ、コンテナでサービスを起動し、ログを見る。さらにESP32のようなマイコンや各種センサーとつなぐと、Linuxが現実の温度や照明や在室検知と結び付きます。筆者もスマートホームを触るなかで、CUIで設定を詰められる人ほど、GUIだけでは届かない細部まで制御できると感じています。

学習の順番としては、いきなりIoT全体を理解しようとしなくて大丈夫です。まず1台のRaspberry Piにログインし、更新できること。次に1つのサービスを常時動作させること。そこからセンサーや自動化に広げると、Linuxの知識が机上の理解で終わりません。自分の家で動く小さなサーバーを持つと、学習内容がそのまま日常の仕組みに変わります。

{{ogp:https://www.home-assistant.io/installation/|Installation|Install Home Assistant|https://www.home-assistant.io/images/default-social.png}}

{{related:docker-compose-guide}}

{{related:home-server-raspberry-pi}}