Starship でシェルプロンプトを自分仕様にする実践Tips

2026年5月9日 7分で読める

ターミナルを開いた瞬間、Git ブランチ名が赤く点滅していた。コミットしないまま帰るところだった、と気づいた金曜の夜。Starship を入れる前の自分なら、たぶん見落としていた。

Starship はクロスシェル対応のプロンプトツール。Rust で書かれていて、Bash でも Zsh でも Fish でも同じ starship.toml 一つで見た目を統一できる。Raspberry Pi 5 のターミナルから VPS の Ubuntu まで、自分はこれで揃えている。一年使ってきて、ようやく「素の設定をこねくり回す価値がある」と思えるレベルに落ち着いてきたので、ここにまとめておく。

そもそもなぜ Starship に乗り換えたのか

長らく Powerlevel10k を使っていた。速いし、見た目もそこそこ。ただ、Bash に戻った瞬間に世界が変わるのが嫌だった。SSH 先のサーバーは Bash 縛りも多い。プロンプトの記法が頭の中で二重化していくのが地味にストレスで、ある日 ~/.zshrc をいじっている最中に「これもう統一していいか」と切り替えた。

結論から言うと、乗り換えて正解だった。設定ファイルの書き味が TOML なので、Bash の謎エスケープと格闘する時間がゼロになる。あとは速い。実測で平均 18ms、Raspberry Pi 5 でも 25ms 前後。体感ラグはほぼ無い。

インストールから最低限の動作まで

公式インストーラーを使うのが一番早い。curl 一発で済む。

curl -sS https://starship.rs/install.sh | sh

Zsh ならこう。

# ~/.zshrc の末尾
eval "$(starship init zsh)"

Bash と Fish もコマンドが違うだけで考え方は同じ。starship init bash、starship init fish をそれぞれの設定ファイルから呼ぶ。注意点として、Nerd Font 系のフォントを入れていないとアイコンが豆腐になる。自分は JetBrainsMono Nerd Font を Mac/Linux 双方で揃えた。

starship.toml の構造を最初に押さえる

設定ファイルは ~/.config/starship.toml。中身は大きく分けて二層になっている。

format: プロンプト全体の並び順を決めるトップレベルの行
各モジュール: [git_branch]、[python]、[directory] のようにブロックごとに細かい挙動を書く

順番を変えたいなら format を、表示のスタイルだけ変えたいならモジュールのブロックを触る。この役割分担がわかってから、設定をこねるスピードが一気に上がった。最初の一週間はここを混同して時間を溶かしたので、これから入る人はぜひ覚えておいてほしい。

一年使って残った、本当に効く設定5つ

1. Git の汚れ具合を一目で見せる

これは最重要。git_status モジュールを尖らせると、コミット忘れがなくなる。

[git_status]
format = '([\[$all_status$ahead_behind\]]($style) )'
style = "bold red"
conflicted = "⚔️"
ahead = "⇡${count}"
behind = "⇣${count}"
diverged = "⇕⇡${ahead_count}⇣${behind_count}"
untracked = "?"
stashed = "$"
modified = "!"
staged = "+"
renamed = "»"
deleted = "✘"

未コミット変更があれば !、ステージ済みは +、push 漏れは ⇡3 のように出る。冒頭で書いた金曜の夜の話、これのおかげ。

2. Python の仮想環境表示を簡素化

デフォルトだと via 🐍 v3.12.1 (venv) みたいに長い。venv 名だけ見えればよい派なので、ここはバッサリ。

[python]
format = 'via [${symbol}${pyenv_prefix}(\($virtualenv\) )]($style)'
symbol = "🐍 "
style = "yellow bold"

Python の uv や direnv と組み合わせるとプロジェクトごとに自動で venv が見える。direnv の設定については別記事で書いた。

3. コマンドの実行時間を出す

cmd_duration は地味だが効く。重いコマンドが何秒かかったか可視化されると、CI の最適化対象が肌感でわかってくる。

[cmd_duration]
min_time = 2_000
format = "took [$duration]($style) "
style = "yellow"

2秒以上かかったコマンドだけ表示にしておくと邪魔にならない。pytest が想定外に遅くなった時、最初に気づくのはここ。hyperfine でちゃんと測る前段の警報装置として優秀。

4. ディレクトリパスを賢く省略

長いプロジェクトパスを毎回フル表示するのは視覚ノイズ。

[directory]
truncation_length = 3
truncate_to_repo = true
style = "bold cyan"

truncate_to_repo を true にしておくと、Git リポジトリのルートからの相対表示になる。~/Workspace/2026-04-09_make_money/seoblog/content が make_money/seoblog/content に縮む。

5. 終了コードを赤で目立たせる

失敗を見落とさないための最後の砦。

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

シンプルだが、シェルスクリプトを書く日は本当に助かる。cron で動かしているスクリプトのデバッグ中、ターミナルで連続実行する時の視認性が段違い。

パフォーマンスを落とさないための注意

Starship は速い、と書いたが、設定次第では遅くなる。たとえば aws や gcloud のモジュールは、デフォルトで認証ファイルを読みに行く。プロンプト表示のたびに数百ミリ秒かかる、なんてのはここで起こる。使わないクラウド系モジュールは明示的に disabled = true しておくのが鉄則。

[aws]
disabled = true

[gcloud]
disabled = true

[azure]
disabled = true

あと、git_status はリポジトリが巨大だと遅くなる。Linux カーネルみたいなツリーで作業する時は git_status.disabled = true を一時的に切り替えるか、git_metrics 側に役割を寄せると良い。

ハマったところと自分なりの落とし所

Starship 自体は安定しているが、運用面で軽くハマった話を二つ。

一つ目。chezmoi で dotfiles を同期している環境で、Mac と Linux でフォントが違うとアイコン位置がズレる。これは Starship のせいというより Nerd Font の入れ方の問題で、両環境とも Patched 版を入れて解決した。VPS 側はこの作業が面倒だったので、今は DevTools サイトで軽い作業を済ませることも増えた。

二つ目。Raspberry Pi 5 の起動直後、最初のプロンプトだけやけに遅い時があった。原因は Git のリモート問い合わせ。git_status.ahead_behind は基本ローカル参照だが、特定の hook が走るリポジトリだとフェッチが発生していた。command_timeout = 500 を入れて回避している。VPS で本番運用するサーバーをいくつか持っている関係で、お名前.comの高性能VPS側も同じ starship.toml をシンボリックリンクで共有していて、SSH した瞬間から見た目が変わらないのは想像以上に楽。

正直、まだ custom モジュールは試行錯誤中。例えば「現在のブランチが本番マージ済みかどうか」を出したくて作りかけている。完成したらまた書く。

最後に — 派手にしすぎないのがコツ

Starship を入れ始めた頃、絵文字とアイコンを盛りまくった結果、肝心の情報が埋もれた。半年経って気づいたが、プロンプトは「異常を一瞬で検知する HUD」であって装飾ではない。今は色を 4 色までに絞っている。緑=正常、黄=注意、赤=異常、シアン=ナビゲーション。これだけで十分。

もし最初の一歩で迷うなら、まずは git_status と character だけ整えて、あとは触らずに一週間使ってみる。何が足りないかが自然に見えてくる。設定ファイルをいきなり 200 行書くより、不便を感じたところを一行ずつ足す方がずっと長続きする。