Linux 開発環境構築ガイド（dev environment setup）- 最初に入れる道具一式

Linux 開発環境構築ガイド（dev environment setup）- 最初に入れる道具一式
読了時間: 約12分 難易度: 中級

この記事で分かること

  • 新しい Linux マシンで 最初に入れるべき道具一式 が分かる
  • パッケージマネージャ・エディタ・シェル・Git・SSH 鍵を 正しい順番 で整えられる
  • 環境を 再現可能（reproducible） にして、次のマシンでも迷わなくなる

結論（実務の型）

  • まず パッケージマネージャ を起点にする（依存解決を一元化）
  • 次に エディタ・シェル・Git・SSH 鍵 の 4 点を揃える
  • 最後に 手順をスクリプト / dotfiles 化 して再現性を確保する

前提（対象環境）

  • Debian / Ubuntu 系（apt）を例に説明する
  • 他ディストリのコマンド対応は パッケージマネージャ概観 を参照
  • ターミナル操作と sudo が使えること

開発環境（dev environment）に最初に入れる道具は？

結論: 最初に入れるのはパッケージマネージャ・エディタ・シェル・Git・SSH 鍵の 5 点。これだけで大半の開発作業が回る。

優先度の高い順に並べると次のとおり。1 つずつ後続セクションで掘り下げる。

順番 道具 役割
1 パッケージマネージャ すべての道具を入れる土台
2 エディタ コードを書く・読む
3 シェル コマンドを実行する対話環境
4 Git バージョン管理・コード共有
5 SSH 鍵 リモート / GitHub への安全な認証

なぜパッケージマネージャから始めるのか？

結論: OS 標準のパッケージマネージャを起点にすれば、依存解決と更新を一元管理でき、環境構築の再現性が上がる。

個別のインストーラを寄せ集めると、更新もアンインストールも管理できなくなる。まずパッケージ一覧を更新し、開発に最低限必要な土台を入れる。

sudo apt update
sudo apt install -y build-essential git curl wget ca-certificates

build-essential は gcc / make などコンパイルに必要な道具をまとめて導入するメタパッケージ。多くの言語ランタイムやツールがビルド時にこれらを要求する。

導入後はバージョンを確認しておくと、後でトラブルを切り分けやすい。

gcc --version
git --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
git version 2.34.1

エディタとシェルはどう選ぶか？

結論: エディタは普段使いの 1 つに絞り、シェルは bash か zsh を既定にすると学習コストを抑えられる。

エディタは好みで構わないが、最初は 1 つに集中 したほうが習熟が早い。ターミナル内で完結させたいなら vim / nano、GUI なら VS Code が定番。

sudo apt install -y vim

シェルは Debian / Ubuntu の既定が bash。補完や履歴を強化したいなら zsh も選択肢になる。違いと選び方は shell 比較（bash/zsh/fish） を参照。

迷ったら bash のまま で十分。シェルを変えるのは基本操作に慣れてからでよい。

Git と SSH 鍵はどう設定するか？

結論: Git の user 設定と SSH 鍵生成・登録を最初に済ませれば、認証で詰まらず push まで通せる。

まず Git のコミット作者情報を設定する。これを忘れると最初のコミットで止まる。

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

次に SSH 鍵を生成する。現在は ed25519 が推奨。

ssh-keygen -t ed25519 -C "you@example.com"

生成した 公開鍵 を表示し、GitHub などのサービスに登録する（秘密鍵は絶対に共有しない）。

cat ~/.ssh/id_ed25519.pub

登録後、接続確認すると成功メッセージが返る。

Hi your-name! You've successfully authenticated, but GitHub does not provide shell access.

言語ランタイムはグローバル導入でいいか？

結論: 言語ランタイムはグローバル導入を避け、バージョン管理ツールでプロジェクト単位に切り替えるのが安全。

apt で言語ランタイムを直接入れると、プロジェクトごとにバージョンが異なる場面で詰む。バージョン管理ツール を使うと、プロジェクトごとに切り替えられる。

言語 代表的なバージョン管理ツール
Node.js nvm / fnm
Python pyenv
Ruby rbenv
Rust rustup

例として Rust は公式インストーラ rustup が標準。

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

インストール用の curl | sh は URL が公式か を必ず確認してから実行する。出所不明のスクリプトをそのまま流さない。

環境を再現可能にするには？

結論: インストール手順をスクリプトや dotfiles にまとめておけば、新しいマシンでも同じ環境を再現できる。

ここまでの手順を毎回手作業でやると、マシンを移るたびに差異が生まれる。手順をコード化 しておくと再現性が上がる。

簡単なのは、導入コマンドを 1 枚のシェルスクリプトにまとめておく方法。

#!/usr/bin/env bash
set -euo pipefail

sudo apt update
sudo apt install -y build-essential git curl vim
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

設定ファイル（.bashrc / .gitconfig / .vimrc など、いわゆる dotfiles）は Git リポジトリで管理し、新しいマシンで clone するのが定番。

git clone git@github.com:your-name/dotfiles.git ~/dotfiles

最初から完璧を目指さなくてよい。使うたびに追記 していくと、自分用の構築スクリプトが自然に育つ。

よくあるつまずきと対処

結論: つまずきの多くは権限・PATH・鍵の登録漏れが原因。sudo の乱用を避け、エラーメッセージを読む習慣が近道。

  • Permission denied: 書き込み先の権限不足。むやみに sudo を付けず、まず対象の所有者と権限を ls -l で確認する
  • command not found: インストール済みでも PATH が通っていない可能性。which <コマンド> で実体を確認する
  • Git push で認証エラー: SSH 公開鍵をサービス側に登録できているか、ssh -T git@github.com で確認する

やってはいけないこと

  • エラーを読まずに sudo を付けて再実行する
  • 出所不明のスクリプトを確認せず実行する
  • 秘密鍵をリポジトリにコミットする

次に読む