モダン Bash & シェルスクリプティング 2026 完全ガイド - Bash 5.2 · Zsh 5.9 · fish 4 · Nushell · Murex · ShellCheck · Bashly · just 徹底解説

• プロローグ — なぜ 2026 年に再びシェルを語るのか
• 第 1 章 · Bash 5.2 — Brian Fox が始め Chet Ramey が継ぐ標準
• 第 2 章 · Zsh 5.9 — macOS の既定、Oh My Zsh の本陣
• 第 3 章 · fish 4 — Rust で生まれ変わったユーザーフレンドリーシェル
• 第 4 章 · Nushell — 構造化データパイプライン
• 第 5 章 · Murex · xonsh · Elvish — 第三の道のシェルたち
• 第 6 章 · POSIX シェル · dash · ksh · tcsh — レガシーとミニマリズム
• 第 7 章 · シェルスクリプティングの strict mode — set -euo pipefail
• 第 8 章 · trap と mktemp — 後片付けを忘れない
• 第 9 章 · 引数パース — getopts とその先
• 第 10 章 · 配列と連想配列 — bash 4 以降の核
• 第 11 章 · 関数と local · readonly · プロセス置換
• 第 12 章 · ShellCheck · shfmt · bashly — モダンシェルワークフロー
• 第 13 章 · fzf · ripgrep · fd · bat · eza — モダン Unix ツール
• 第 14 章 · システムモニタリング — bottom · btop · htop · glances
• 第 15 章 · jq · yq · dasel · gron — 構造化データ処理
• 第 16 章 · 並列実行 — xargs · parallel · rush
• 第 17 章 · gum · charm — シェルから美しい TUI
• 第 18 章 · just · task · xc · mise — モダンタスクランナー
• 第 19 章 · シェルプロンプト — Starship · Oh My Posh · Powerline
• 第 20 章 · AI シェル — sgpt · gptme · Warp · Amazon Q
• 第 21 章 · ターミナルエミュレータ — Ghostty · Wezterm · Alacritty · Kitty · iTerm2
• 第 22 章 · 日韓運用チームのシェル — クーパン · LINE · サイボウズ · メルカリ
• 第 23 章 · 2026〜2028 年のシェルの未来
• 第 24 章 · シェルスクリプティング・チェックリスト(10 項目)
• 第 25 章 · 7 つの実戦アンチパターン・カタログ
• 第 26 章 · 結論 — シェルは依然としてインフラの中核にある
• 参考資料(References)

プロローグ — なぜ 2026 年に再びシェルを語るのか

1989 年 6 月。Brian Fox は GNU プロジェクトの一環として Bourne-Again SHell の最初のバージョンを公開した。それから 37 年が経った 2026 年 5 月、私たちは今もシェルを毎日叩いている。AI がコードを書いてくれる時代になっても、cd、ls、grep、git、kubectl、ssh は指の筋肉記憶として残っている。

ただし風景は確かに変わった。

• Bash 5.2(2022 年 9 月リリース)が依然として GNU 標準であり、5.3 は 2026 年中に到着予定。Chet Ramey が 1990 年代初頭から保守している。
• Zsh 5.9 は macOS Catalina 以来の既定シェルであり、Oh My Zsh・Prezto・Antigen といった巨大なプラグインエコシステムを抱える。
• fish 4 は 2024 年に Rust で完全に書き直された。起動時間、シンタックスハイライト、オートサジェストが速くなり、メモリも減った。
• Nushell 0.105+ はシェルの定義そのものを揺さぶる。すべてのコマンドが構造化データ(テーブル)を受け渡しし、ls | where size > 1mb | sort-by modified のような SQL 風パイプラインを書ける。
• Murex — 型システムを持つシェル。xonsh — Python で書くシェル。Elvish — 表現力豊かなシェル。それぞれが居場所を見つけている。
• そしてツール群。ShellCheck はシェルスクリプトの ESLint。shfmt はフォーマッタ。bashly は bash でフルスタック CLI アプリを生成する。gum はシェルから美しい TUI を作る。fzf、ripgrep、fd、eza、dust、bottom、just、mise — どれも GNU coreutils を Rust/Go で書き直した次世代ツールだ。
• AI も入ってきた。shell_gpt(sgpt) は自然言語からシェルコマンドを作り、Warp Terminal が AI コマンド提案を表示し、Amazon Q Developer(旧 Fig)が補完を強化する。

本稿は上記のツールとパターンを 22 章にまとめた深掘りガイドだ。シェル本体(1〜6 章)、スクリプティングのベストプラクティス(7〜12 章)、モダン CLI ツール(13〜17 章)、ビルド/タスクランナー(18〜19 章)、AI とターミナル(20 章)、日韓運用チームの事例(21 章)、そして未来(22 章)の順に整理する。

シェルは消えない。ただ シェルはもはや単なる入力行ではない。私たちは「シェル vs IDE」の時代から「構造化シェル + モダンツール + AI」の時代に移ってきた。

第 1 章 · Bash 5.2 — Brian Fox が始め Chet Ramey が継ぐ標準

Bash は GNU プロジェクトの標準シェルだ。1989 年に Brian Fox が最初に作り、1992 年以降は Chet Ramey(ケース・ウェスタン・リザーブ大学)がほぼ単独で保守している。2026 年 5 月時点の安定版は 5.2.37(2025 年 11 月のパッチリリース)で、5.3 は同年末リリースが予告されている。

Bash 5.2 で入った新機能

• BASH_REMATCH の正規表現マッチがより安定した。
• globskipdots シェルオプション — * マッチで . と .. を落とし、長年のハマりどころを潰す。
• varredir_close — プロセス置換が終わるときに fd を安全に閉じる。
• ${var@k} パラメータ変換 — キーだけを取り出す新パターン。
• wait -p VAR — wait の結果 PID を変数に格納。
• 関数トレースが改善され、set -T/trap ... DEBUG の組み合わせがより正確に。

Bash 5.3 で予告されているもの

• BASH_TRAPSIG — トラップが処理したシグナル番号を変数として公開。
• set -o curses 的なモードの検討。
• 一部 POSIX 互換性の強化。

なぜ今なお bash か

三つの理由がある。1) 遍在性(ubiquity) — Linux、macOS、WSL、BusyBox、Docker alpine までほぼあらゆる場所に存在する。2) CI/CD の標準 — GitHub Actions、GitLab CI、Jenkins の既定シェルが bash。3) 40 年分の資料 — man bash、Stack Overflow、ABS Guide の積み重ねは他シェルを圧倒する。

# Bash 5.2 の新機能の使用例
shopt -s globskipdots   # * が . と .. を拾わなくなる
echo *

# wait -p でバックグラウンドの PID を取得
sleep 5 &
wait -p PID $!
echo "直前のバックグラウンド PID は $PID"

# パラメータ変換の新書式
declare -A map=([a]=1 [b]=2)
echo "${map[@]@k}"   # キーだけを列挙

macOS の罠 — Bash 3.2.57

ここに大きな罠がある。macOS の /bin/bash は 2007 年から止まっている Bash 3.2.57 だ。Apple が GPLv3 を拒否しているからである。4.0 以降のあらゆる機能(declare -A、mapfile、readarray、${var,,} 小文字化、** globstar)が動かない。解決策は brew install bash で 5.2 を入れ、#!/usr/bin/env bash を書くこと。絶対に #!/bin/bash を書かないこと — macOS では 3.2 が引かれる。

第 2 章 · Zsh 5.9 — macOS の既定、Oh My Zsh の本陣

Zsh は 1990 年に Paul Falstad(プリンストン大学)が始めた。2026 年 5 月時点で 5.9 が安定版、5.10 が間もなく到着する。2019 年の macOS Catalina で Apple が既定シェルを Bash 3.2 から Zsh 5.7 に切り替えて以来、世界の開発者ノート PC の半数以上が Zsh を使う(Stack Overflow Developer Survey 2025)。

Zsh の核となる差別化点

• グローバルエイリアス(global alias) — alias -g G='| grep' とすれば cat foo G bar のようにどこからでも呼べる。
• 拡張グロブ — **/*.go(.) で通常ファイルだけ、*(om[1,10]) で最新 10 件。
• 連想配列 が標準搭載(Bash は 4.0 から)。
• マルチファンアウト・リダイレクト — cmd > >(tee a) > >(tee b)。
• プロンプトシステム が豊富 — PROMPT_SUBST で動的プロンプト表現。
• 補完システム が圧倒的 — compinit がほぼあらゆるコマンドのオプションを知っている。

# Zsh 拡張グロブ
setopt EXTENDED_GLOB
ls **/*.log~*backup*       # backup を除く全 .log
ls *(om[1,10])             # 最新 10 件
ls *(/^F)                  # 空ディレクトリのみ

Oh My Zsh — 最大のフレームワーク

Robby Russell が 2009 年に始めた。2026 年で GitHub スター 17 万。200+ テーマ、300+ プラグイン。git、kubectl、aws、docker、node、python プラグインが補完とエイリアスを一行で有効化する。

# ~/.zshrc 例
plugins=(git kubectl aws docker fzf z)
ZSH_THEME="agnoster"
source $ZSH/oh-my-zsh.sh

Prezto / Zinit / Antidote — より速い代替

Oh My Zsh はリッチだが起動が遅くなる場合がある。より速い選択肢:

• Prezto — Sorin Ionescu、2012 年。モジュール式、軽量。
• Zinit — turbo mode で非同期ロード、起動時間 50ms 程度。
• Antidote — 次世代、プレーンテキストの plugin file。

# Zinit turbo mode 例 — 非同期でロードしプロンプト表示を阻害しない
zinit wait lucid for \
  OMZP::git \
  OMZP::kubectl \
  zsh-users/zsh-autosuggestions \
  zdharma-continuum/fast-syntax-highlighting

Zsh の弱点

POSIX 100% 互換ではない。一部スクリプトは bash と異なる挙動になる。だから #!/usr/bin/env zsh で明示するか、共通スクリプトは bash で書き、インタラクティブだけ zsh を使う分離が一般的。

第 3 章 · fish 4 — Rust で生まれ変わったユーザーフレンドリーシェル

fish は "friendly interactive shell" の略。2005 年に Axel Liljencrantz が始めた。2024 年の 4.0 で C++ から Rust に全面書き換え された。2026 年 5 月の安定版は 4.1 で、起動時間は 30〜50ms 程度。

fish の真骨頂 — 即座に効く既定値

• オートサジェスト — 履歴ベースの自動提案が常に有効。グレーで表示され → で確定。
• シンタックスハイライト — 入力中に赤(誤コマンド)・緑(正常)・黄(引用)が即座に色付け。
• アブリビエーション(abbreviation) — エイリアスより強力。入力時点で展開され履歴には本コマンドが残る。
• 豊富なオプション補完 — man ページを解析してオプションを知る。
• Web ベース設定 — fish_config でブラウザからテーマを選ぶ。

# fish の文法は bash と異なる。変数、関数、if すべてより明確。
set -gx PATH $HOME/bin $PATH

function gco --description "git checkout"
    git checkout $argv
end

# アブリビエーション: 入力時点で展開される
abbr -a gc git commit
abbr -a gst git status

fish の弱点 — POSIX 非互換

fish は POSIX 互換ではない。[ ]、&&、|| など一部文法が異なる。だから .zshrc、.bashrc をそのまま持ち込めない。スクリプト共有の観点では bash で書き、fish はインタラクティブ用にする運用が一般的。

4.0 の Rust 書き換えがもたらしたもの

• 起動時間がほぼ半減。
• メモリ使用量低下。
• C++ のメモリ安全性問題の解消。
• 外部コントリビュータの参入障壁が下がった。

第 4 章 · Nushell — 構造化データパイプライン

Nushell は 2019 年に Jonathan Turner と Yehuda Katz が始めた。Rust で書かれており、2026 年 5 月時点の安定版は 0.105。「すべてのコマンドがデータ(テーブル)を受け渡すシェル」 という点で PowerShell のインスピレーションを受けているが、Unix 哲学と結びついてより軽く速い。

真骨頂 — テーブルベースのパイプ

# ディレクトリ一覧をテーブルで受け、サイズフィルタ、ソート、5 件
ls | where size > 1mb | sort-by modified | first 5

# JSON を自動でパースして扱う
http get https://api.github.com/repos/nushell/nushell | get stargazers_count

# CSV → JSON 変換が一行
open data.csv | to json | save data.json

なぜ重要か

bash の世界では awk、cut、jq、xargs でテキストパイプを組む。一行パースコードが積み重なると可読性が落ちる。nushell はテーブル自体を一級オブジェクトとして扱うので、where、sort-by、group-by、select、each のような SQL 風表現で解ける。

制約

• シェルスクリプトの互換性問題。bash スクリプトはそのままでは動かない。
• 外部コマンドはテキストを受け渡すため、データ化するには from json/from csv 変換が必要。
• 0.x 系のためリリースごとに文法が変わる — 本番スクリプティングよりインタラクティブ分析/探索用に使うのが安全。

誰に向くか

• データエンジニア — ローカルで小さなデータを扱うシェル環境として優秀。
• クラウド運用者 — kubectl get pods -o json | from json | where ... のように JSON を直接扱う。

第 5 章 · Murex · xonsh · Elvish — 第三の道のシェルたち

Murex — 型システムを持つシェル

英国の開発者 Andrew Stewart が作っている。2026 年 5 月時点で 6.x 系。変数が型を持ち、JSON・YAML・TOML を一級で扱う。nushell より bash 互換寄りの折衷案だ。

# 変数の型宣言
set: int counter = 0
set: string name = "world"

# JSON 処理が一級
open my.json -> [name age] -> format json

xonsh — Python で書くシェル

Anthony Scopatz が 2015 年に始めた。Python とシェルを一つのファイルに混ぜて書ける。データサイエンティストに愛されるシェル。

# .xonshrc — Python とシェルが混在
import os
echo @(os.getcwd())

# シェル変数が Python リスト
ls = $(ls -la).split('\n')
for line in ls:
    print(line)

Elvish — 表現力の強いシェル

Qi Xiao(中国)が 2014 年に始めた。Go で書かれている。ラムダ、クロージャ、第一級関数がシェルにある。nushell より早くから「構造化されたシェル」を試みた先駆者だ。

fn greet [name]{
  echo "Hello, "$name
}
greet world

三つに共通するのは

POSIX 互換を捨てて表現力を得たという点だ。本番サーバの init スクリプトとして使うのは危険だが、個人ノート PC のインタラクティブシェルやデータ作業用としては魅力的。

第 6 章 · POSIX シェル · dash · ksh · tcsh — レガシーとミニマリズム

POSIX シェル は IEEE 1003.1 標準が定めるシェル。bash 4 以降の華麗な機能([[ ]]、(())、declare -A、<<<)はどれも使えない。代わりに ほぼ全ての Unix で動作する。

dash(Debian Almquist SHell)は Debian が /bin/sh として採用した最小 POSIX シェル。Ubuntu、Debian の /bin/sh は dash。bash より起動が 4〜10 倍速く、init スクリプトが速い。

# POSIX 互換スクリプトの模範
#!/bin/sh
set -eu
# [[ ]] 使えず、[ ] のみ
if [ "$1" = "build" ]; then
  echo "building..."
fi
# 配列もない — 位置パラメータで代用
set -- a b c
for x in "$@"; do echo "$x"; done

ksh(Korn Shell)は 1983 年に Bell Labs の David Korn が作った。かつては Solaris/AIX の標準だった。ksh93 が最後のメジャーバージョンで、2020 年に ksh93u+m フォークが出て今も一部保守されている。AIX/Solaris のレガシーシステムでだけ見る。

tcsh は C shell の後継。BSD の一部で既定として使われていた。1990 年代の大学 Unix でよく見た。2026 年にはほとんど使われない — FreeBSD が root の既定で残している程度。

いつ何を使うか

• 本番サーバの init/cron スクリプト → POSIX /bin/sh(dash/ash)。速くて確実。
• 開発者ノート PC の一般スクリプト → bash 5.2。豊富な機能、広範な資料。
• インタラクティブな日常シェル → zsh または fish。
• AIX/Solaris レガシー → ksh。

第 7 章 · シェルスクリプティングの strict mode — set -euo pipefail

#!/usr/bin/env bash で始まるすべてのスクリプトの 2 行目は、ほぼ常に set -euo pipefail であるべきだ。

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

各オプションが防いでくれる罠

• set -e(errexit) — コマンドが非ゼロで終わると即座に終了。if/while/|| の中では適用されない(意図された例外)。
• set -u(nounset) — 未定義変数を使うとエラー。タイプミスによる silent failure を防ぐ。
• set -o pipefail — パイプ中間のコマンドが失敗すれば全体が失敗。既定では最後のコマンドの終了コードだけを見る。
• IFS=$'\n\t' — 単語分割を改行/タブに限定し空白を含むファイル名に安全。

set -e の罠

set -e は絶対ではない。cmd | other、cmd || true、if cmd; then ... のような場合には作動しない。だから pipefail と組み合わせて初めて意味を持つ。また set -e はトラップが噛んだ関数内の挙動でしばしばわかりにくい挙動になるので、トラップと一緒に使うときは明示的な if 検査を好む のが安全だ。

比較 — よく書かれたスクリプトの先頭数行

#!/usr/bin/env bash
# vim: set ft=bash ts=2 sw=2 :
set -Eeuo pipefail   # -E は ERR トラップを関数内でも動作させる
IFS=$'\n\t'

# デバッグモード: BASH_X=1 ./run.sh
if [[ "${BASH_X:-0}" == 1 ]]; then
  set -x
fi

readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly TMP_DIR="$(mktemp -d)"
trap 'rm -rf "$TMP_DIR"' EXIT

第 8 章 · trap と mktemp — 後片付けを忘れない

スクリプトが一時ファイルを作るなら、必ず片付けなければならない。単純な rm は失敗経路で漏れる。trap を使う必要がある。

TMP=$(mktemp -d -t myapp.XXXXXX)
trap 'rm -rf "$TMP"' EXIT

# より複雑な場合: シグナル別に分ける
cleanup() {
  local exit_code=$?
  rm -rf "$TMP"
  if [[ $exit_code -ne 0 ]]; then
    echo "スクリプトが異常終了(code=$exit_code)" >&2
  fi
  exit $exit_code
}
trap cleanup EXIT
trap 'echo "INT 受信"; exit 130' INT
trap 'echo "TERM 受信"; exit 143' TERM

mktemp のベストプラクティス

• 常に -d でディレクトリを作り、その中にファイルを置く — 片付けが一行で済む。
• -t prefix.XXXXXX で prefix を与えるとデバッグが楽。
• macOS の mktemp は GNU とオプションが異なる。クロスプラットフォームでは mktemp -d "tmp.XXXXXX" の短形式を使う。

なぜ /tmp/myscript を使ってはいけないか

三つだ。1) TOCTOU 攻撃 — 誰かが先に同名を作って権限回避。2) 衝突 — 同時に二つのインスタンスが回ると衝突。3) 片付け不能 — 他インスタンスのファイルを消すと危険。

第 9 章 · 引数パース — getopts とその先

基本は getopts

bash のビルトインなので外部依存なし。単一文字オプションだけ対応するが、99% のケースで十分。

usage() {
  cat <<'USAGE'
使い方: deploy.sh [-e env] [-n name] [-d]
  -e env    デプロイ環境 (dev/staging/prod、必須)
  -n name   サービス名 (既定: $(basename $PWD))
  -d        dry-run モード
  -h        このヘルプ
USAGE
}

DRY_RUN=0
NAME="$(basename "$PWD")"

while getopts ":e:n:dh" opt; do
  case $opt in
    e) ENV="$OPTARG" ;;
    n) NAME="$OPTARG" ;;
    d) DRY_RUN=1 ;;
    h) usage; exit 0 ;;
    \?) echo "不明なオプション: -$OPTARG" >&2; usage; exit 2 ;;
    :)  echo "オプション -$OPTARG には引数が必要" >&2; usage; exit 2 ;;
  esac
done
shift $((OPTIND - 1))

: "${ENV:?ENV is required (-e)}"

ロングオプションが必要なら — 自前パース

# --help、--env=dev のようなロングオプションを自前で処理
while [[ $# -gt 0 ]]; do
  case $1 in
    --env=*)  ENV="${1#*=}"; shift ;;
    --env)    ENV="$2"; shift 2 ;;
    --help|-h) usage; exit 0 ;;
    --)       shift; break ;;
    -*)       echo "不明なオプション: $1" >&2; exit 2 ;;
    *)        ARGS+=("$1"); shift ;;
  esac
done

代替 — bashly / docopt.sh

複雑な CLI は bashly(後述 12 章)でコードを生成するか、docopt.sh でヘルプテキストからパーサを自動生成する。

第 10 章 · 配列と連想配列 — bash 4 以降の核

通常の配列

arr=("a" "b" "c")
echo "${arr[0]}"          # a
echo "${arr[@]}"          # 全要素
echo "${#arr[@]}"         # 要素数
arr+=("d")                # 追加
unset 'arr[1]'            # インデックス 1 を削除(インデックスが sparse になる点に注意)

連想配列(associative array) — bash 4.0+、zsh は標準、macOS bash 3.2 では不可

declare -A users
users[alice]=admin
users[bob]=guest
users[carol]=admin

for u in "${!users[@]}"; do
  echo "$u: ${users[$u]}"
done

# キーの存在確認
[[ -v users[alice] ]] && echo "alice あり"

配列を関数に渡す — bash の永遠の罠

# 間違い — 配列が平坦化されて一引数になる
print_arr() { for x in "$@"; do echo "$x"; done; }
arr=(a "b c" d)
print_arr "${arr[@]}"   # 正解 — クォート + @ 展開で要素ごとに渡す

# より安全 — nameref(bash 4.3+)
print_by_ref() {
  local -n ref=$1
  for x in "${ref[@]}"; do echo "$x"; done
}
print_by_ref arr

第 11 章 · 関数と local · readonly · プロセス置換

関数の模範

# 関数は常に local 変数を使う。さもないとグローバル汚染。
greet() {
  local name=$1
  local greeting=${2:-"Hello"}
  echo "$greeting, $name!"
}

# 戻り値は stdout に、終了コードは 0/非ゼロで
add() {
  local a=$1 b=$2
  echo $((a + b))
}
sum=$(add 3 4)

readonly で定数定義

readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly TIMEOUT_SECONDS=30
readonly -a ENVS=(dev staging prod)

プロセス置換 — <() >()

パイプで解けない場合のトリック。一時ファイルを作らずに fd を直接渡す。

# 二つのコマンドの diff
diff <(sort file1) <(sort file2)

# 一つの出力を二箇所に同時に流す(tee)
program | tee >(grep ERROR > err.log) >(grep WARN > warn.log) > full.log

# 入力を fd として受けるコマンドにそのまま流す
psql -f <(echo "SELECT * FROM users WHERE id=$ID")

第 12 章 · ShellCheck · shfmt · bashly — モダンシェルワークフロー

ShellCheck — シェルスクリプトの ESLint

Vidar Holen(ノルウェー)が 2012 年に始めた。Haskell で書かれている。2026 年 5 月時点で 0.10 系。すべての PR で ShellCheck を回すのが標準実践。

# CI で
shellcheck script.sh

# よく拾う問題
# SC2086: $var をクォートしていない — 単語分割の危険
# SC2046: $(...) 結果をクォートしていない
# SC2155: declare/local とコマンド置換の併用で終了コードを失う
# SC2034: 変数が宣言だけで未使用

shfmt — シェルフォーマッタ

Daniel Martí(mvdan)が作る Go ツール。shellcheck と同じ立ち位置にある。gofmt スタイルで一貫したインデント・整形をしてくれる。

# 2 スペースインデント、case パターンもインデント、stdin リダイレクトを処理
shfmt -i 2 -ci -sr -d script.sh

# pre-commit hook 例
shfmt -l -w .   # すべての .sh ファイルを自動フォーマット

bashly — bash で作るフルスタック CLI

Danny Ben Shitrit が作った。YAML でコマンド構造を定義すれば bash スクリプトのフルスタック CLI を生成する。引数パース、ヘルプ、バージョン、補完まで。

# src/bashly.yml
name: mycli
help: 自分の CLI ツール
version: 1.0.0

commands:
  - name: deploy
    help: 環境にデプロイ
    args:
      - name: env
        required: true
        allowed: [dev, staging, prod]
    flags:
      - long: --dry-run
        short: -d
        help: dry-run モード

bashly generate
./mycli deploy prod --dry-run

第 13 章 · fzf · ripgrep · fd · bat · eza — モダン Unix ツール

fzf — ファジーファインダー

Junegunn Choi(韓国、Kakao)が 2013 年に始めた。Go 製。2026 年 5 月時点で 0.55 系。韓国の開発者が作った中で最も影響力のあるオープンソースの一つ。

# fzf 基本
ls | fzf
history | fzf
git log --oneline | fzf | awk '{print $1}' | xargs git show

# キーバインド(Ctrl+R で履歴、Ctrl+T でファイル、Alt+C でディレクトリ)
source /usr/share/fzf/key-bindings.bash

ripgrep(rg) — 速い grep

Andrew Gallant(BurntSushi)が作った。Rust 製。grep より 5〜10 倍速く、.gitignore を既定で尊重する。

# 基本
rg "TODO" --type rust
rg -i "error" -C 2     # 大文字小文字を無視、2 行コンテキスト
rg --files-with-matches "Apache"

fd — find 代替

David Peter(sharkdp)の Rust ツール。find より直感的で速い。

fd "\.rs$"                # 全 Rust ファイル
fd -e py -t f             # Python ファイルのみ
fd -H "node_modules"      # hidden 含む

bat — cat にシンタックス

同じく sharkdp の作品。cat にシンタックスハイライトと git diff 表示を加える。

bat README.md
bat -p src/main.rs   # plain モード、シンタックスのみ

eza — exa の後継、ls 代替

ogham の exa の fork。2024 年以降活発に保守されている。

eza -l --git --icons
eza --tree --level 2

なぜこれらすべてを使うか

GNU coreutils は 50 年前のインターフェイスだ。オプションが直感的でなく、出力に色がなく、.gitignore を知らない。上記ツールは 2010 年代以降の合理的な既定値 を提供する — カラー出力、インデックス、ignore ファイル認識、JSON 出力。

第 14 章 · システムモニタリング — bottom · btop · htop · glances

htop — 1990 年代後半に Hisham Muhammad が作ったクラシック。カラー + マウス + ツリービュー。現時点でも最も広くインストールされている。

btop — Aristocratos が作った C++ の後継。より華やかな可視化、GPU/ディスク/ネットワークグラフ、マウスナビゲーション。

bottom(btm) — ClementTsang の Rust 実装。クロスプラットフォーム、JSON 設定。

glances — Nicolas Hennion の Python。Web API/Prometheus エクスポータがあり、モニタリング統合が容易。

比較

# bottom 設定例 (~/.config/bottom/bottom.toml)
[flags]
hide_avg_cpu = false
mem_as_value = true
network_use_binary_prefix = true

第 15 章 · jq · yq · dasel · gron — 構造化データ処理

jq — JSON の標準

Stephen Dolan が 2012 年に始めた。関数型 JSON クエリ言語。あらゆる場所にある。

curl -s api.github.com/users/torvalds | jq '.public_repos'
kubectl get pods -o json | jq '.items[] | .metadata.name'
cat data.json | jq -r '.users[] | select(.age > 30) | .name'

yq — YAML 用 jq

Mike Farah(mikefarah/yq)の Go 実装が標準。jq の文法をほぼそのまま使える。

yq '.spec.replicas = 3' deployment.yaml
yq '.services | keys' docker-compose.yml

dasel — クロスフォーマット

JSON、YAML、TOML、XML、CSV を同じクエリで扱う。

dasel -f config.yaml '.database.host'
dasel put -f config.json '.version' -v '2.0'

gron — JSON を grep 可能に

Tom Hudson(TomNomNom)が作った。JSON を 1 行のキー=値形式に平坦化する。

gron https://api.github.com/users/torvalds | grep public_repos
# json.public_repos = 7;

各ツールは シェルパイプの中に自然に入る。これが核心だ — シェルスクリプトが JSON/YAML を扱う能力が 2020 年代に飛躍的に向上した。

第 16 章 · 並列実行 — xargs · parallel · rush

xargs -P — 最も単純な並列

# 8 個同時に圧縮
ls *.log | xargs -n 1 -P 8 gzip

# null 終端入力(安全なファイル名処理)
find . -name '*.log' -print0 | xargs -0 -n 1 -P 8 gzip

GNU parallel — Ole Tange が作った、より豊富な並列実行エンジン

parallel -j 8 gzip ::: *.log
parallel --bar 'convert {} {.}.png' ::: *.jpg
parallel --eta wget {} ::: $(cat urls.txt)

GNU parallel はクォート/エスケープが厄介だが、ETA、進捗バー、リトライ、リモート SSH 分散実行まで可能。

rush — shenwei356(中国)の Go 実装。クォート処理がより直感的

rush 'echo Hello, {}' ::: a b c
rush -j 8 'gzip {}' ::: $(ls *.log)

いつ何を使うか

• 単純な並列 → xargs -P。速くてどこにでもある。
• 進捗バー・リトライが必要 → parallel。
• クォート問題を避けたい → rush。

第 17 章 · gum · charm — シェルから美しい TUI

Charm.sh は Toby Padilla と Christian Rocha が運営する Go ライブラリ/ツール集。シェルスクリプトが美しいインタラクティブ UI を持てるようにする。

# ユーザー入力(テキスト、多重選択、確認)
NAME=$(gum input --placeholder "お名前は?")
ENV=$(gum choose dev staging prod)
gum confirm "本当にデプロイしますか?" && deploy.sh "$ENV"

# スピナー
gum spin --spinner dot --title "ビルド中..." -- ./build.sh

# カラフルな出力
gum style --foreground 212 --bold "成功!"

# Markdown レンダ
gum format -- "# タイトル" "**太字**"

なぜ重要か

bash スクリプトのインタラクティブ UI は通常 read で終わる。gum はそれを「現代的」に引き上げる — 色、スピナー、multi-select、ファイルピッカーまで。CI/CD の結果を人が確認するインタラクティブツール、デモ、セットアップウィザードによく合う。

Charm のその他ツール

• glow — ターミナルで Markdown レンダリング。
• vhs — ターミナル GIF 録画(スクリプトで定義)。
• bubble tea — Go の TUI フレームワーク。lazygit、k9s が同カテゴリ。

第 18 章 · just · task · xc · mise — モダンタスクランナー

just — Casey Rodarmor のモダン Makefile

2026 年 5 月時点で 1.40 系。Rust 製。Makefile の良さだけを取り、罠を全部抜いた。

# justfile
default: build test

build:
    cargo build --release

test:
    cargo test

deploy env="dev":
    @echo "Deploying to {{env}}"
    ./scripts/deploy.sh {{env}}

# bash 直接呼び出し
notes:
    #!/usr/bin/env bash
    set -euo pipefail
    grep -r "TODO" src/

Makefile と比較した just の利点

• タブ vs スペースの問題なし。
• 変数展開が一貫している(Make の $$ vs $ の罠なし)。
• 依存関係がより明確(recipe-name: dep1 dep2)。
• .PHONY のような儀式なしで既定が「コマンド実行」。

task(taskfile.dev) — YAML ベース

# Taskfile.yml
version: '3'
tasks:
  build:
    cmds:
      - go build ./...
  test:
    deps: [build]
    cmds:
      - go test ./...

xc — Markdown で書くタスクランナー

Joe Brockwill の作品。README.md の中にコードブロックでタスクを定義する。

## build

```bash
cargo build --release
```

## test

Requires: build

```bash
cargo test
```

mise(旧 rtx) — バージョンマネージャ + タスクランナー

Jordan Pittman の Rust ツール。asdf の後継として始まったが、タスクランナー機能まで入った。

# .mise.toml
[tools]
node = "20"
python = "3.12"

[tasks.build]
run = "npm run build"

選択基準

• 単純なコマンド集 → just。最も軽量で直感的。
• 複雑な依存グラフ → task(taskfile)。
• バージョン管理も同時に → mise。
• 自己文書化が重要 → xc。

第 19 章 · シェルプロンプト — Starship · Oh My Posh · Powerline

Starship — 普遍的、速い Rust プロンプト

2019 年に Matan Kushner と Tim Sosa が始めた。bash、zsh、fish、PowerShell、Nushell、ion、elvish、tcsh、xonsh、cmd すべて対応。TOML 一つで設定。

# ~/.config/starship.toml
add_newline = false
format = "$directory$git_branch$git_status$character"

[directory]
truncation_length = 3
truncate_to_repo = true

[git_branch]
symbol = " "

[character]
success_symbol = "[➜](bold green)"
error_symbol = "[➜](bold red)"

# bash
eval "$(starship init bash)"

# zsh
eval "$(starship init zsh)"

# fish
starship init fish | source

Oh My Posh — クロスシェル、Windows フレンドリー

Jan De Dobbeleer の作品。元々は PowerShell 用だったが全シェルに拡張。Windows ユーザがよく使う。テーマが 100+ で豊富。

Powerline — レガシー

Python 製。最初の「美しいプロンプト」世代を作った。2026 年ではほぼ使われない — Starship がほぼ全ての席を引き継いだ。

なぜ Starship が標準になったか

1. シェル非依存 — 一つの設定ファイルでどこでも同じプロンプト。2) 速い — Rust 製、バックグラウンドキャッシュ。3) 情報が適切 — git ブランチ、言語バージョン、Kubernetes コンテキスト、AWS プロファイルを自動認識。

第 20 章 · AI シェル — sgpt · gptme · Warp · Amazon Q

shell_gpt(sgpt) — TheR1D

Python 製。OpenAI API をシェルから呼ぶ。

sgpt "find all .log files modified today"
# 出力: find . -name "*.log" -mtime -1

sgpt --shell "compress all png in this dir"
# (Enter で実行、e で編集)

sgpt --code "fibonacci in rust"

gptme — Bjorn Holm

似たコンセプトだが、複数ターンの会話とツール呼び出し(ファイル読み書き/実行)をサポート。ローカル LLM にも接続可能。

Warp Terminal — AI ファーストのターミナル

2022 年から Zach Lloyd が運営。2024 年に Linux サポート、2025 年に stable。AI コマンド提案、AI explain command、ノートブック機能。Free と Pro プランがある。

# Warp の # コマンド
# how do I rebase from main?
→ Warp が git rebase コマンドを提案し、ユーザが Enter で実行

Amazon Q Developer(旧 Fig)

Fig が 2024 年に Amazon に買収され、Amazon Q Developer CLI に統合された。補完が強力になり、自然言語からコマンド生成が可能に。

Aiken · Codex CLI

Anthropic Claude Code、GitHub Copilot CLI、OpenAI Codex CLI のようなツールはシェルコマンドを直接実行できる「エージェント」として地位を確立した。これはシェルが人だけでなく エージェントのインターフェイスにもなった ことを意味する。

シェル + AI の二つのモデル

1. suggest mode — AI がコマンドを提案し、人が確認後に実行(sgpt、Warp)。
2. agent mode — AI が直接シェルを実行し、結果を見て次の判断(Claude Code、Codex CLI)。

agent mode は危険なのでコンテナ/サンドボックスで回すのが安全。

第 21 章 · ターミナルエミュレータ — Ghostty · Wezterm · Alacritty · Kitty · iTerm2

Ghostty — Mitchell Hashimoto の新作

HashiCorp 創業者(Vagrant、Packer、Terraform)の Mitchell Hashimoto が 2024 年に発表。2025 年に 1.0 stable、2026 年 5 月時点で 1.2 系。Zig 製、GPU 加速、macOS ネイティブ + Linux。シグネチャは「既定設定が非常に良い」と「ネイティブ macOS 統合」。

# ~/.config/ghostty/config
font-family = "JetBrains Mono"
font-size = 14
theme = "Catppuccin Mocha"
window-padding-x = 8
window-padding-y = 8

Wezterm — Wez Furlong

Rust 製。Lua 設定。タブ/ペイン、リガチャ対応、SSH クライアント内蔵。

local wezterm = require 'wezterm'
return {
  font = wezterm.font 'JetBrains Mono',
  font_size = 14,
  color_scheme = 'Dracula',
  hide_tab_bar_if_only_one_tab = true,
}

Alacritty — Joe Wilm

Rust 製。最も速いターミナルの一つ。TOML 設定。タブ/ペインなし(tmux と併用)。

Kitty — Kovid Goyal

Python + GPU。強力な image protocol(直接 PNG 表示)。

iTerm2 — George Nachman

macOS 専用のクラシック。プロファイル、ホットキー、スプリットペイン、検索、ブロードキャストなど豊富な機能。2026 年でも macOS 標準の一つ。

Hyper · Tabby

Electron 製。ユーザが少ない — 重く GPU 加速が弱い。

選択基準

• macOS 軽量 → Ghostty または iTerm2。
• クロスプラットフォーム軽量 → Alacritty(+tmux)または Kitty。
• リッチな設定 → Wezterm。
• AI 統合 → Warp。

第 22 章 · 日韓運用チームのシェル — クーパン · LINE · サイボウズ · メルカリ

韓国 — クーパンのシェル運用の特徴

クーパンのインフラ運用チームは大規模トラフィックを扱い、2020 年代初頭から bash + Ansible + Terraform の組み合わせを標準として使ってきた。シェルスクリプトのベストプラクティス(strict mode、shellcheck の CI ゲート)が社内 PR ルールとして定着したと韓国カンファレンスで公開されている(if-kakao、AWS Summit Seoul)。

韓国 — Kakao 出身、fzf の起源

第 13 章で見た fzf は Kakao 出身の開発者 Junegunn Choi の作品。Kakao 時代に社内で fzf を初めて作り、その後 GitHub に公開してグローバル標準となった。韓国の開発者が作った中で最も影響力のあるオープンソースの一つとされる。

日本 — LINE のシェル運用

LINE は東京本社から多数のマイクロサービスを運用する。2010 年代後半から社内のシェルスクリプト規約を公開した LINE Engineering ブログの記事が日韓両方でしばしば引用される — strict mode、mktemp、trap、shellcheck を必須化しているのが特徴。

日本 — サイボウズ(Cybozu)の運用ツール

サイボウズの Kintone チームは長年 bash + Ruby + Go の組み合わせで運用ツールを書いてきた。kintone-cli のような社内ツールが bash で書かれた事例が Cybozu Developer Network で公開されている。

日本 — メルカリの SRE シェル文化

メルカリは GCP ベースのマイクロサービスでシェルスクリプトの使用を最小化し Go CLI で代替する方針を SRE カンファレンス(SRE NEXT、SREcon)で公開している。ただし起動/デバッグ/緊急運用には依然として bash が標準という立場。

共通パターン

三社とも共通して 1) set -euo pipefail を必須化、2) ShellCheck を CI ゲートとし、3) 1000 行を超えるスクリプトは Go/Python で書き直し、4) #!/usr/bin/env bash を標準とする方針を持つ。

第 23 章 · 2026〜2028 年のシェルの未来

展望 1 — Bash 5.3 → 6.0 への道

5.3 は 2026 年中に到着し、6.0 は 2027〜2028 年頃と予想される。大きな変化はないだろう — Bash の哲学は「互換性を壊さない」だ。ただし内部のクリーンアップ、パフォーマンス、エラーメッセージの改善は続く。

展望 2 — fish 4 の Rust 効果

2024 年の Rust 書き換え以降、起動時間/メモリが大きく減った。2026〜2028 年は外部コントリビュータが増え、新機能(構造化データ対応など)が速まるだろう。

展望 3 — Nushell の参入

本番スクリプトへの参入はまだ難しいが、データエンジニアとクラウド運用者のインタラクティブシェルとして地位を固めつつある。1.0 が到着すれば(2027 予想)より速く広がる。

展望 4 — AI 統合の標準化

agent mode のシェル利用が一般化するだろう。それに伴い サンドボックス、権限制限、コマンド実行ログ がシェルの既定機能として入ってくる。Claude Code、Codex CLI のようなエージェントがシェルを「第二のユーザ」として扱う時代。

展望 5 — コアツールの Rust 書き換え

ripgrep、fd、eza、bat、bottom、just、mise、Starship — ほぼ全てのモダンツールが既に Rust だ。2028 年頃には「Unix コアツールの Rust 世代交代」が完了するだろう。

展望 6 — POSIX の地位

POSIX シェルは消えない。init スクリプト、Docker alpine、組み込み Linux、CI マトリクスの最低共通分母として生き残る。だから portable スクリプトは依然として #!/bin/sh で書く のがベストプラクティス。

第 24 章 · シェルスクリプティング・チェックリスト(10 項目)

毎回シェルスクリプトを書くときに確認すべき 10 項目をまとめる。

1. shebang — #!/usr/bin/env bash または portable なら #!/bin/sh。
2. strict mode — set -Eeuo pipefail を 2 行目に。
3. IFS — IFS=$'\n\t' で空白を含むファイル名に安全。
4. mktemp — 一時ファイルは常に mktemp -d で、trap '...' EXIT で片付け。
5. クォート — $var はほぼ常に "$var" でクォート。${arr[@]} は "${arr[@]}"。
6. 終了コード — 関数の結果は stdout、成功は 0、失敗は非ゼロ。
7. shellcheck — CI で必須化。警告は # shellcheck disable=... で明示無視。
8. shfmt — フォーマット一貫性。pre-commit hook で自動化。
9. エラーメッセージ — stderr(>&2)に送り終了コード明示。
10. ドキュメント — 先頭コメントブロックに使い方、引数、依存、例。

第 25 章 · 7 つの実戦アンチパターン・カタログ

アンチパターン 1 — クォートなし変数

# 危険
rm $file        # $file に空白/ワイルドカードあると爆発
# 安全
rm -- "$file"

アンチパターン 2 — set -e だけ信じて pipefail を入れない

curl ... | jq .x で curl が失敗しても jq が空入力で成功すると全体が成功に見える。

アンチパターン 3 — cd の結果を検査しない

# 危険
cd /tmp/build
rm -rf *        # cd 失敗すると現在ディレクトリで爆発

# 安全
cd /tmp/build || exit 1
rm -rf -- ./*

アンチパターン 4 — [ ] と [[ ]] の混在

bash は [[ ]](キーワード)を使う。POSIX 互換が必要なら [ ]。混ぜないこと。

アンチパターン 5 — バックティック(`cmd`)

$(cmd) を使う。ネスト可、クォート安全、可読性が良い。

アンチパターン 6 — eval

ユーザ入力を eval に入れないこと。ほぼ全ての場合に別の方法がある(配列、関数、bash -c "$(...)")。

アンチパターン 7 — 巨大な単一スクリプト

1000 行を超えたら Go/Python での書き直しを検討する。シェルの強みは glue(糊) — 他のツールを束ねること。ビジネスロジックは他言語で。

第 26 章 · 結論 — シェルは依然としてインフラの中核にある

37 年前、Brian Fox が最初に bash を公開したとき、彼は GNU プロジェクトの一部として「自由な Bourne シェル代替」を作っているつもりだった。その一行の決断が、今日ほぼ全てのコンピュータの最も内側に居座っている。

2026 年のシェル風景をまとめると:

• Bash 5.2 が標準 — どこでも動く。スクリプトの既定。
• Zsh 5.9 が macOS の既定 — インタラクティブ限定。
• fish 4 が Rust で再誕 — フレンドリーなインタラクティブ。
• Nushell が構造化データシェル — データエンジニア/クラウド。
• ShellCheck + shfmt + bashly がモダンワークフローの核。
• fzf、ripgrep、fd、bat、eza、just、mise、Starship が次世代ツール。
• gum がシェルに美しい TUI を。
• sgpt、Warp、Claude Code が AI 統合。
• Ghostty、Wezterm、Alacritty、Kitty が次世代ターミナル。

シェルは消えない。シェルはより豊かに、より安全に、より表現豊かに進化する。私たちがすべきは、そのツールを上手く選び、strict mode と shellcheck で堅牢に書き、1000 行を超えたら他言語に移す決断をすることだ。

シェルは運用の中核にある。運用が消えない限り、シェルも消えない。

参考資料(References)

1. GNU Bash Manual — https://www.gnu.org/software/bash/manual/
2. Bash 5.2 Release Notes — https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00214.html
3. Zsh Documentation — https://zsh.sourceforge.io/Doc/
4. Oh My Zsh — https://ohmyz.sh/
5. fish shell — https://fishshell.com/
6. Nushell Book — https://www.nushell.sh/book/
7. Murex — https://murex.rocks/
8. xonsh — https://xon.sh/
9. Elvish — https://elv.sh/
10. ShellCheck — https://www.shellcheck.net/
11. shfmt(mvdan) — https://github.com/mvdan/sh
12. bashly — https://bashly.dannyb.co/
13. gum(Charm) — https://github.com/charmbracelet/gum
14. fzf — https://github.com/junegunn/fzf
15. ripgrep — https://github.com/BurntSushi/ripgrep
16. fd — https://github.com/sharkdp/fd
17. bat — https://github.com/sharkdp/bat
18. eza — https://github.com/eza-community/eza
19. bottom — https://github.com/ClementTsang/bottom
20. just — https://github.com/casey/just
21. taskfile.dev — https://taskfile.dev/
22. mise — https://mise.jdx.dev/
23. Starship — https://starship.rs/
24. Oh My Posh — https://ohmyposh.dev/
25. Warp — https://www.warp.dev/
26. Ghostty — https://ghostty.org/
27. Wezterm — https://wezfurlong.org/wezterm/
28. Alacritty — https://alacritty.org/
29. POSIX Shell Standard — https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
30. Google Shell Style Guide — https://google.github.io/styleguide/shellguide.html