Starshipとは・使い方｜bash・zsh・fishの設定と表示速度の実測

プロンプトとは、シェルがコマンドの入力を待つときに行の先頭へ出す文字列です。Starship は、そのプロンプトの文字列を毎回作って返す役目だけを持つプログラムです。補完や履歴の検索はシェル側の機能で、Starship は担当しません。

flowchart TD
    A[Enter でコマンドを実行] --> B[PROMPT_COMMAND<br>または precmd]
    B --> C[starship prompt<br>終了コードと時間を渡す]
    C --> D[starship.toml を読む]
    C --> E[フォルダーを調べる<br>.git など]
    E --> F[git・node を実行]
    D --> G[文字列を返す]
    F --> G
    G --> H[PS1 として表示]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（2 CPU・メモリ 8GB の共有マシン）で、GNU bash 5.2.21、zsh 5.9（Ubuntu の 5.9-6ubuntu2 の .deb を作業場所に展開）、fish 3.7.0（同じく .deb を展開）、git 2.43.0、Node.js v22.23.4、Python 3.13.18、Go 1.24.7、fontconfig 2.15.0 を使いました。シェルの設定ファイルは作業用に作った HOME の中だけで書き換え、env -i で環境変数を外して各シェルを起動しています。Starship 本体（GitHub Releases のビルド済みファイル）の取得は、この環境の権限で拒否されたため実行していません。そのため Starship 自体の表示と starship サブコマンドの出力は、公式ドキュメント（starship.rs）、GitHub の Releases の記載、初期化スクリプトのソースコード（src/init/starship.bash・starship.zsh を読んだ範囲）で確かめた内容です。手元で実行したのは、本体が無いときの各シェルのエラー、bash の設定ファイルの読み込み順、Starship の Git・言語モジュールが行うのと同じ種類の処理（git status・node --version など）の所要時間、starship.toml の文法と設定名の照合（公式ドキュメントの設定表から自作した照合スクリプト）、フォントの字形の有無と文字コードの確認です。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

Starshipとは（シェルのプロンプトを表示するツール）

この節では、Starship という言葉が指すものの違いと、ツールとしての Starship が何をするものかが分かります。

「Starship」で検索すると、宇宙船や音楽事務所の情報も混ざります。この記事で扱うのは、端末（ターミナル）の行頭に出るプロンプトを作るツールです。

ツールの Starship は、公式サイトで「Cross-Shell Prompt」と名乗っています。シェルごとに別の書き方をしていたプロンプト（bash の PS1、zsh の PROMPT、fish の fish_prompt 関数など）を、1つの設定ファイルで共通にできるのが特徴です。ライセンスは ISC で、無料で使えます。

表示する部品は「モジュール」と呼ばれます。手元で公式ドキュメントの設定の章を数えると、設定例の付いたモジュールが91個ありました。ディレクトリ（directory）、Git のブランチ（git_branch）と状態（git_status）、言語の版（nodejs・python・rust・golang など）、直前のコマンドの所要時間（cmd_duration）、入力位置の記号（character）などです。

Starshipの使い方：最初の5分で表示するまで

この節では、Starship を入れてプロンプトが変わるまでの最小の手順と、つまずきやすい点が分かります。

手順3の1行を、本体を入れる前に書いてしまうと、次の端末を開いたときにエラーが出ます。作業用の HOME で3つのシェルに初期化の行だけを書き、本体が無い状態で起動した実物です（[… を読みました] は読み込みを確かめるために足した echo の出力です）。

--- bash
[.bashrc を読みました]
bash: starship: command not found
PS1=[${debian_chroot:+($debian_chroot)}\u@\h:\w\$ ]
--- zsh
[.zshrc を読みました]
/dev/shm/t189/home/.zshrc:2: command not found: starship
PS1=[%m%# ]
--- fish
[config.fish を読みました]
~/.config/fish/config.fish (line 2): Unknown command: starship
starship init fish | source
^~~~~~~^
from sourcing file ~/.config/fish/config.fish
	called during startup

どのシェルも止まらず、プロンプトは元のまま（bash は Ubuntu の既定の PS1、zsh は %m%# ）で起動しました。エラーの文言はシェルごとに違い、bash は command not found、zsh は command not found: starship、fish は Unknown command です。この文言が出たら、本体が入っていないか、PATH が通っていないかのどちらかです。

この環境では本体を取得できなかったため、Starship が描いたプロンプトの画面は載せていません。公式の既定の書式（format = '$all'）では、Git のリポジトリの中で次の順に部品が並びます。

~/work/myapp on  main [!?] via  v22.23.4 took 3s
❯

上の例は、公式の設定表に載る既定の書式（directory の後に on＋git_branch、[...] の git_status、via＋nodejs、took＋cmd_duration、2行目に character の ❯）を並べたもので、実行結果ではありません。cmd_duration は既定で2秒（min_time = 2_000）以上かかったコマンドの後だけ出ます。

Starshipのインストール方法（Mac・Linux・Windows）

この節では、OS ごとのインストールのコマンドと、版の確かめ方、2026年10月29日時点の最新版が分かります。

Ubuntu 24.04 では apt に Starship がありません。手元で確かめると、パッケージの情報が何も返りませんでした。

$ apt-cache policy starship
$ apt-cache search --names-only '^starship'
$ echo $?
0

何も表示されないのは「そのパッケージが見つからない」という意味です。公式のインストールの表でも、apt で入るのは Debian 13 以降と Ubuntu 25.04 以降と書かれています。Ubuntu 24.04 では、公式スクリプト・Homebrew（Linuxbrew）・cargo・conda のどれかを使います。

公式スクリプトは、ダウンロードしたシェルスクリプトをそのまま実行する形です。会社の端末や共有のマシンでは、先に curl -sS https://starship.rs/install.sh -o install.sh で保存して中身を読み、社内の決まりに合うかを確かめてから実行すると安心です。

版の確かめ方と2026年10月の更新

入ったかどうかは starship --version で確かめます。2026年10月29日時点で GitHub の Releases の最新は v1.27.0（2026年10月17日）です。この版の Security の欄には、GHSA-x486-6jjc-phfp（ファイルの読み込み量に上限が無かった問題）と GHSA-679r-jwc5-r5m3（信頼できない環境で git のコマンドを実行しないようにする修正）の2件が修正として載っています。ほかに Jujutsu（jj）のモジュール4種、bash で Flyline を使った右プロンプト、hostname の SSH の判定に SSH_CLIENT・SSH_TTY を足す変更などが入りました。

複数の人が使うマシンや、外から取ってきたリポジトリをよく開く環境では、v1.27.0 以降へ更新しておくと安全です。更新は入れた方法と同じ経路で行います（brew upgrade starship、winget upgrade --id Starship.Starship、公式スクリプトの再実行など）。パッケージマネージャーの収録版は、リリースより遅れることがあります。

bash・zsh・fishへのStarshipの設定（初期化の1行）

この節では、シェルごとに初期化の行を書く場所と、本体が無いときにもエラーを出さない書き方、bash で .bashrc が読まれないときの直し方が分かります。

「末尾に書く」のは、ほかのプラグインやテーマがプロンプトを書き換えた後で、Starship が最後に上書きするためです。Oh My Zsh と一緒に使う場合も、source $ZSH/oh-my-zsh.sh より後に置きます。

本体が無いときもエラーを出さない書き方

dotfiles を複数のマシンで共有していると、Starship が入っていないマシンでも同じ設定ファイルが読まれます。コマンドがあるときだけ初期化する書き方にすると、前の節のエラーが出なくなります。

# ~/.bashrc（zsh の ~/.zshrc も同じ書き方で動く。init の引数を zsh にする）
if command -v starship >/dev/null 2>&1; then
  eval "$(starship init bash)"
fi

# ~/.config/fish/config.fish
if type -q starship
    starship init fish | source
end

作業用の HOME に、本体が無いときに1行の案内を出す形で書き、3つのシェルを起動した結果です。どれもエラーにならず、終了コードは0でした。

[starship が見つからないので既定のプロンプトのまま]
rc=0      ← bash
[starship が見つからないので既定のプロンプトのまま]
rc=0      ← zsh
[starship が見つからないので既定のプロンプトのまま]
rc=0      ← fish

zsh で (( $+commands[starship] )) と書く例も見かけます。これは zsh/parameter モジュールの機能で、通常の zsh では読み込まれています。手元では .deb を作業場所に展開した zsh を使ったため、モジュールの場所が合わず failed to load module `zsh/parameter' と出ました。モジュールの有無に左右されない command -v の書き方のほうが、環境を選びません。

bash で ~/.bashrc が読まれないとき

「.bashrc に書いたのに Starship にならない」ときは、ログインシェルとして起動しているかを確かめます。bash はログインシェルのとき ~/.bash_profile（無ければ ~/.bash_login、~/.profile の順）を読み、~/.bashrc は読みません。作業用の HOME で、.bash_profile に読み込みの印だけを書いて試した結果です。

$ bash -l -c 'echo login'          ← ログインシェル
[.bash_profile を読みました]
login
$ bash -i -c 'echo interactive'    ← 対話シェル（ログインでない）
[starship が見つからないので既定のプロンプトのまま]   ← .bashrc が読まれた
interactive
$ bash -c 'echo noninteractive'    ← スクリプトなど
noninteractive

ログインシェルでは .bashrc の内容（案内の1行）が出ていません。Mac の「ターミナル」や SSH での接続はログインシェルになることが多いため、~/.bash_profile に次の1行を足して .bashrc を読み込ませます。

# ~/.bash_profile
[ -f ~/.bashrc ] && . ~/.bashrc

足した後は、ログインシェルでも .bashrc が読まれました（[.bash_profile を読みました] の次に案内の1行が出た）。PATH や alias を書く場所の使い分けは、関連記事「Linux環境変数PATHの設定方法｜exportと.bashrcの使い分け早見表」で扱っています。

Starshipが動く仕組み（PROMPT_COMMANDとprecmd）

この節では、初期化の1行が何をしているのかと、所要時間（took 3s）がどう測られているのかが分かります。

starship init bash は、シェルに読み込ませるスクリプトを出力するコマンドです。eval "$(…)" は、その出力をいまのシェルで実行するという意味です。読み込まれるスクリプトの中身は、公式リポジトリの src/init/starship.bash（157行）と starship.zsh（102行）で読めます。読んだ範囲で、要点は次のとおりです。

zsh のスクリプトの最後は、次の形です（ソースから引用。::STARSHIP:: の部分は初期化のときに本体のパスへ置き換わります）。

PROMPT='$('::STARSHIP::' prompt --terminal-width="$COLUMNS" --keymap="${KEYMAP:-}" --status="${STARSHIP_CMD_STATUS:-}" --pipestatus="${STARSHIP_PIPE_STATUS[*]:-}" --cmd-duration="${STARSHIP_DURATION:-}" --jobs="$STARSHIP_JOBS_COUNT")'

つまり、プロンプトが出るたびに starship のプログラムが1回起動し、その出力が行頭に表示されます。Starship の本体は状態を持たず、渡された情報と今いるフォルダーの中身だけで文字列を作ります。公式の FAQ には、対応していないシェルでも PS1="$(starship prompt --status=$STATUS --jobs=$NUM_JOBS)" の形で使えるという例が載っています。

zsh の所要時間は EPOCHREALTIME（小数の秒）から作られ、ミリ秒の整数で --cmd-duration に渡ります。zsh のスクリプトは VIRTUAL_ENV_DISABLE_PROMPT=1 も設定するため、Python の venv を有効にしても (venv) が二重に出ません。venv の名前は python モジュールが表示します。

starship.tomlの書き方（Starshipの設定ファイル）

この節では、設定ファイルの場所、基本の書き方、format 文字列の読み方、書き間違えたときに出るエラーが分かります。

設定ファイルは ~/.config/starship.toml です。環境変数 STARSHIP_CONFIG で別の場所を指せます。警告やエラーのログは既定で ~/.cache/starship/session_${STARSHIP_SESSION_KEY}.log に書かれ、STARSHIP_CACHE で場所を変えられます。

次の設定は、Git の状態・言語の版・所要時間を出す最小の例です。公式の設定表をもとに作った照合スクリプトで、すべての設定名が文書に載っていることを確かめました（7モジュール・16項目、問題0件）。

"$schema" = 'https://starship.rs/config-schema.json'

# プロンプトの前に空行を入れない
add_newline = false
# 外部コマンド（git や node --version）の待ち時間の上限（ミリ秒）
command_timeout = 500

[directory]
truncation_length = 3
truncate_to_repo = true

[git_branch]
symbol = '🌱 '
format = 'on [$symbol$branch]($style) '

[git_status]
ahead = '⇡${count}'
behind = '⇣${count}'
diverged = '⇕⇡${ahead_count}⇣${behind_count}'

[nodejs]
format = 'via [⬢ $version](bold green) '

[python]
format = 'via [py $version( \($virtualenv\))]($style) '

[cmd_duration]
min_time = 500
format = 'took [$duration](bold yellow) '

[character]
success_symbol = '[❯](bold green)'
error_symbol = '[✗](bold red)'

1行目の "$schema" は、VS Code などのエディターで設定名の補完と型の確認を効かせるための行で、表示には影響しません。git_branch の記号を絵文字の 🌱 にしたのは、Nerd Font が無い端末でも表示できるようにするためです（既定は Nerd Font の記号 U+E0A0）。

format 文字列の読み方

Starship の format は、変数・テキストグループ・条件付きの3つでできています。公式の説明を、上の設定の例で読むと次のとおりです。

TOML の文字列には、シングルクォートの「リテラル文字列」とダブルクォートの「基本文字列」があります。公式は、エスケープが少なくて済むシングルクォートを例に使っています。ダブルクォートで \[ と書くと、TOML のほうで \ がエスケープの始まりとして解釈され、文法エラーになります（次の表の7番）。

starship.toml の書き間違いと出るエラー

よくある書き間違いを7通り作り、Python 3.13 の tomllib（TOML 1.0 のパーサー）と、公式の設定表から作った照合スクリプトにかけた結果です。Starship 本体が出す文言とは異なりますが、どこがおかしいかの見当を付けるのに使えます。

1番・2番と6番は TOML としては正しいため、ファイルを読み込めても思った表示になりません。Starship は設定が読めない・合わないときにログへ警告を書きます。starship print-config で実際に効いている設定を表示でき、エディターで "$schema" の行を入れておくと、綴りの誤りや型の違い（6番の文字列と真偽値）をその場で指摘してもらえます。

照合に使ったスクリプトの考え方です。公式の設定の章（docs/config/README.md）から、各モジュールの「Options」の表にある設定名を集め、starship.toml の表名・設定名と突き合わせています。

import re, sys, tomllib
doc = open("config.md", encoding="utf-8").read()
opts = {}
for s in re.split(r"\n## ", doc):
    m = re.search(r"```toml\n# ~/.config/starship.toml\n\n\[([a-z0-9_.]+)\]", s)
    o = re.search(r"### Options\n\n\|[^\n]*\n\|[^\n]*\n((?:\|[^\n]*\n)+)", s)
    if m and o:
        opts.setdefault(m.group(1), set()).update(
            re.findall(r"^\| `([a-z0-9_]+)`", o.group(1), re.M))
cfg = tomllib.load(open(sys.argv[1], "rb"))
for k, v in cfg.items():
    if isinstance(v, dict):
        for kk in v:
            if kk not in opts.get(k, ()):
                print(f"[{k}] {kk} は文書にない設定名")

Git・言語の版・所要時間を表示する設定

この節では、Starship のプロンプトによく出る記号の意味と、言語の版がどんなときに表示されるかが分かります。

git_branch と git_status の記号

Git のリポジトリの中では、git_branch がブランチ名を、git_status が変更の状態を記号で出します。公式の設定表にある既定の記号です。

既定の書式は '([\[$all_status$ahead_behind\]]($style) )' で、全体が条件付き（ ）なので、変更が無いときは何も出ません。ahead・behind に件数を出したいときは、前の節の設定のように ${count} を使います。

記号は git status の結果をまとめたものです。手元の小さなリポジトリで1つのファイルを変更し、追跡していないファイルを1つ作ったときの git status --porcelain=v2 --branch の出力です。

# branch.oid a35d2fcd2408869c648dbf7f4309ccf75575d9dc
# branch.head main
1 .M N... 100644 100644 100644 d00491fd7e5bb6fa28c517a0bb32b8b506539d4d d00491fd7e5bb6fa28c517a0bb32b8b506539d4d f1.txt
? new.txt

.M（作業ツリーで変更）が !、? の行が ? にあたり、Starship の既定ならブランチ名の後ろに [!?] と出る状態です。2文字の記号の読み方は、関連記事「git statusの見方｜Untracked等の意味と-s短縮表示の記号一覧」で扱っています。

git_status は既定で gitoxide（Rust で書かれた Git の実装）を使って状態を計算し、use_git_executable = true にすると git コマンドを使います。WSL で Windows 側のフォルダーを開いたときに遅い場合は、windows_starship に Windows 版の Starship のパスを指定する設定があります。

言語の版が出る条件

言語のモジュールは、今いるフォルダーに決まったファイルがあるときだけ表示されます。何も無いフォルダーで Node.js の版が出ないのはそのためです。

nodejs の detect_files には !bunfig.toml・!deno.json のような「!」付きの指定があります。これは「このファイルがあれば表示しない」という否定の指定で、Bun や Deno のプロジェクトで Node.js の版を出さないためのものです。表示を止めたいモジュールは、format から外すより disabled = true を書くほうが公式のおすすめです（新しいモジュールが増えても意図が残るため）。

Starshipのプリセット（見た目の見本）

この節では、公式のプリセットの種類と、Nerd Font が要るかどうか、書き出すときの注意が分かります。

プリセットは、公式が用意した starship.toml の見本です。starship preset 名前 -o ~/.config/starship.toml で書き出せます。-o の先にファイルがあると上書きされるため、今の設定を残したいときは先に別名で保存しておきます。公式のプリセットのページに載っている12種です。

Nerd Font を入れていない端末で試すなら、No Nerd Fonts か Plain Text Symbols から始めると文字化けが起きません。帯で区切る系のプリセットは、端末が24ビットカラーに対応しているかでも見え方が変わります。

Starshipの文字化け（□・?）の直し方とNerd Font

この節では、アイコンが□や?になる原因と、手元で確かめる方法、OS ごとの直し方が分かります。

Starship の既定の記号には、Nerd Font の「私用領域」の文字が含まれます。私用領域は、Unicode が意味を決めず、フォントごとに自由に絵を入れてよい範囲です。手元で、Starship の既定に出てくる記号を Python の unicodedata で調べた結果です。

このマシンのフォント（335件）のうち、どのフォントがその文字の形を持っているかを fc-list で調べました。

$ fc-list | grep -i -c 'nerd\| NF'
0
$ fc-list ':charset=e0a0' family | sort -u | head -3
Inter
Inter Display
Inter Display,Inter Display Black
$ fc-list ':charset=1f40d' family | sort -u | head -1
Noto Color Emoji
$ fc-list ':charset=276f' family | sort -u | head -2
DejaVu Sans
DejaVu Sans Mono

Nerd Font は1つも入っていませんでした。注目したいのは U+E0A0 です。Nerd Font ではない Inter が、この私用領域の番号に別の絵を持っていました。私用領域はフォントごとに中身が違うため、Nerd Font 以外のフォントで表示されると、□ではなく意図しない記号が出ることもあります。❯（U+276F）や 🐍（U+1F40D）は Unicode に正式な文字なので、一般的なフォントや絵文字フォントで表示できます。

もう1つの原因は、ロケールが UTF-8 になっていないことです。同じ3バイト（U+E0A0）を、ロケールを変えて wc -m（文字数）で数えた結果です。

LC_ALL=C        文字数=3
LC_ALL=C.UTF-8  文字数=1

C ロケールでは3バイトが別々の3文字として扱われ、端末の表示や行の幅の計算がずれます。手元のシェルでも locale の LC_CTYPE が "POSIX" でした。公式の FAQ は、ja_JP.UTF-8 のような UTF-8 のロケールにすること、絵文字フォントがあること、Nerd Font を使うことの3点を挙げ、次の2行で確かめる方法を載せています。

echo -e "\xf0\x9f\x90\x8d"   # 蛇の絵文字が出れば絵文字フォントは OK
echo -e "\xee\x82\xa0"       # ブランチの記号が出れば Nerd Font は OK

OS・端末別の直し方

SSH で接続した先のプロンプトが化けるときに、サーバーへ Nerd Font を入れても直りません。文字を描いているのは手元の端末だからです。サーバー側で確かめるのはロケール（UTF-8 か）です。

Starshipのプロンプト表示速度の実測

この節では、プロンプトが出るまでに裏で何が実行され、どれくらい時間がかかるのかを、手元の実測と公式の仕組みで説明します。

Starship はプロンプトのたびに、フォルダーの中を調べ（scan）、必要なら外部のコマンドを実行します。公式の既定では、フォルダーを調べる時間の上限が scan_timeout = 30 ミリ秒、外部コマンドの上限が command_timeout = 500 ミリ秒です。上限を超えたコマンドは打ち切られ、Executing command "..." timed out. という警告が出ます。

本体を動かせなかったため、Starship の Git・言語のモジュールが行うのと同じ種類の処理を、作業場所で30回ずつ実行して時間を測りました。小さなリポジトリ（10ファイル）と、200フォルダー×100ファイルの大きなリポジトリ（2万ファイル）を用意しています。

大きなリポジトリで、全ファイルの更新時刻を touch で変えた直後に git status を実行すると、117〜133ミリ秒かかりました。Git は更新時刻が変わったファイルの中身を読み直すためです。ブランチの切り替えやビルドで大量のファイルが書き換わった直後のプロンプトが一瞬重くなるのは、この処理です。その後の数回は38〜53ミリ秒で、共有のマシンのため測るたびに10ミリ秒ほどの揺れがありました。

言語の版は1つあたり2〜4ミリ秒で、どれも command_timeout の500ミリ秒には遠く届きません。一方で、nvm・pyenv・asdf などのバージョン管理ツールが node や python の前に挟まる環境では、版の表示に数百ミリ秒かかることがあり、警告の原因になりがちです。

シェルの起動時間との比較

プロンプトの重さと混同しやすいのが、シェルの起動の重さです。作業用の HOME で、各シェルを -i（対話）で起動してすぐ終了するまでの時間を20回ずつ測りました。

zsh で補完の初期化（compinit）を入れるだけで、起動は約10倍の23ミリ秒になりました。Oh My Zsh のような設定一式は compinit に加えて多数のプラグインやテーマを読むため、起動はさらに重くなります。Starship は起動時に初期化のスクリプトを1回読むだけで、重さの大半は「プロンプトのたびに走る処理」のほうにあります。

自作の PS1 で同じことをすると

比較のため、ブランチ名と ?・!・+ の記号を出すプロンプトを bash の関数だけで書き、PROMPT_COMMAND に登録しました。

__mini_prompt() {
  local st=$? b s=""
  if b=$(git symbolic-ref --short -q HEAD 2>/dev/null); then
    local out; out=$(git status --porcelain 2>/dev/null)
    [[ $out == *$'\n'"??"* || $out == "??"* ]] && s+="?"
    [[ $out =~ (^|$'\n').M ]] && s+="!"
    [[ $out =~ (^|$'\n')[AM] ]] && s+="+"
    b=" on $b${s:+ [$s]}"
  fi
  local c='\[\e[1;32m\]'; (( st )) && c='\[\e[1;31m\]'
  PS1="\[\e[1;36m\]\W\[\e[0m\]\[\e[1;35m\]${b}\[\e[0m\] ${c}❯\[\e[0m\] "
}
PROMPT_COMMAND=__mini_prompt

bash 5 の ${PS1@P} でプロンプトを展開した結果（色の制御文字を除いたもの）と、関数1回あたりの時間です。

repo-small on main [?!] ❯       ← 変更と未追跡のファイルがあるリポジトリ
tmp ❯                           ← Git の外
$'\E[1;36mrepo-small\E[0m\E[1;35m on main [?!]\E[0m \E[1;31m❯\E[0m '   ← 直前が失敗（赤い ❯）

関数1回あたり：小さなリポジトリ 15ms／2万ファイル 77〜84ms（10回の中央付近）

小さなリポジトリでも15ミリ秒かかったのは、$( ) のたびに bash が子プロセスを作り、git を2回起動しているためです。Starship は1つのプログラムの中で Git の状態をまとめて計算し、git コマンドを毎回起動しません（既定は gitoxide を使用）。自作の PS1 は依存が無く軽い反面、表示を増やすほど書く量と起動するプロセスが増えます。

遅いときの切り分けの順番

1. 1starship timings で重いモジュールを探す1ms を超えたか、何かを表示したモジュールの所要時間が一覧で出る
2. 2starship explain で、いま出ている部品の意味を見る知らない記号の正体と処理時間が分かる
3. 3env STARSHIP_LOG=trace starship timings で原因のコマンドを特定1つのモジュールなら starship module 名前 で切り出す
4. 4使わないモジュールを disabled = true で止める言語の版・クラウドの情報・package がよく候補になる
5. 5それでも警告が出るなら command_timeout を上げる警告だけ消したいときは STARSHIP_LOG=error

Starshipと Oh My Zsh・Powerlevel10k・自作PS1の比較

この節では、似た目的のツールとの違いと、どれを選ぶかの考え方が分かります。

Powerlevel10k の README の冒頭には、2026年10月29日時点で「THE PROJECT HAS VERY LIMITED SUPPORT」「NO NEW FEATURES ARE IN THE WORKS」と書かれています。今動いている環境をすぐに変える理由にはなりませんが、新しく選ぶ場合は保守の状況も判断に入れます。Powerlevel10k の Instant Prompt（zsh の起動を待たずに入力を始められる機能）は Starship に同じものがありません。

# ~/.zshrc（Oh My Zsh と併用する場合）
export ZSH="$HOME/.oh-my-zsh"
ZSH_THEME=""                      # テーマは使わない
plugins=(git)
source $ZSH/oh-my-zsh.sh
eval "$(starship init zsh)"       # 最後に置く

tmux の中で使う場合も Starship の設定は同じです。tmux のステータスバーは tmux 側の設定で、Starship のプロンプトとは別に動きます。tmux の設定は関連記事「tmuxの使い方｜キーバインド早見表とコピペ用.tmux.conf」で扱っています。

Starshipのよくあるエラー・つまずき

この節では、Starship でよく出るエラーや症状と、その原因・直し方を表で確かめられます。

入れる前の確認

• 1使っているシェルを確かめたecho $SHELL。Mac の既定は zsh、多くの Linux は bash
• 2今の設定ファイルを控えた.bashrc・.zshrc を別名でコピーしておくと、戻すのが簡単
• 3端末のフォントを決めたNerd Font を入れるか、No Nerd Fonts のプリセットにするか
• 4入れる経路と更新の方法を決めたHomebrew・winget・パッケージ・公式スクリプト。更新も同じ経路で
• 5会社の端末なら決まりを確かめたソフトの導入の許可・スクリプトの実行の可否

Starshipを使うか決める判断表

この節では、自分の状況で Starship を選ぶか、別の方法にするかを判断できます。

シェルの設定ファイルに書く alias や関数の整理は関連記事「Linux alias設定と.bashrcの書き方｜おすすめエイリアス50選」、シェルスクリプトとして書く場合の基本は関連記事「シェルスクリプトの書き方｜基本構文の早見表と安全なテンプレート」で扱っています。

Starshipについてよくある質問

この節では、Starship について検索されやすい疑問に短く答えます。

Q. Starship とは何ですか？
A. bash・zsh・fish・PowerShell など多くのシェルで使える、プロンプトを表示するツールです。Rust で書かれ、ISC ライセンスで無料で使えます。設定は ~/.config/starship.toml の1ファイルです。

Q. Starship の読み方は？
A. 「スターシップ」です。英語の宇宙船（star＋ship）と同じ綴りです。

Q. Starship は無料ですか？
A. 無料です。ライセンスは ISC で、有料版はありません。

Q. starship.toml が無いとどうなりますか？
A. 既定の設定で表示されます。ファイルは、見た目を変えたくなったときに作り、変えたいモジュールの表だけを書けば動きます。

Q. Starship に補完やプラグインの機能はありますか？
A. ありません。補完はシェルの機能で、公式の FAQ は zsh なら zsh-autosuggestions を案内しています。表示する項目を増やすには custom モジュールでコマンドの出力を出せます。

Q. 右側にプロンプトを出せますか？
A. right_format で出せます。対応は elvish・fish・zsh・xonsh・cmd・nushell・bash で、bash は Ble.sh（v0.4 以降）か Flyline（v1.7.1 以降）が必要です。

Q. 実行し終わった行のプロンプトを短くできますか（transient prompt）？
A. 公式の高度な設定に、PowerShell（Enable-TransientPrompt）、cmd（Clink）、fish（enable_transience）、bash（Ble.sh）の方法があります。fish はコマンド行が空のときは短縮されないと書かれています。

Q. ホスト名がいつも出ません。
A. hostname モジュールは既定で SSH の接続中だけ表示されます（ssh_only = true）。常に出すには [hostname] に ssh_only = false を書きます。

Q. 時刻を出すには？
A. time モジュールは既定で無効です。[time] に disabled = false を書くと表示されます。

Q. Starship をアンインストールするには？
A. シェルの設定ファイルから初期化の行を消し、本体を削除します。Homebrew や winget などで入れた場合は、それぞれのアンインストールのコマンドを使います。

Q. Claude Code のステータスラインにも使えると聞きました。
A. v1.25.0 で Claude Code 向けの statusline のサブコマンドが追加されました。設定は公式の高度な設定の「Statusline for Claude Code」に載っています。

まとめ

• Starship は、多くのシェルで同じ見た目にできるプロンプト専用のツール。本体を入れ、設定ファイルの末尾に初期化の1行を足すと使える。補完や履歴はシェル側の機能。
• 本体が無いまま初期化の行を書くと、bash・zsh・fish でそれぞれ違う文言のエラーが出た。command -v・type -q で囲むと、どのシェルでも終了コード0で起動した。
• Ubuntu 24.04 の apt には無い（apt-cache は空）。2026年10月29日時点の最新は v1.27.0 で、セキュリティの修正2件を含む。
• starship.toml はシングルクォートで書くとエスケープの失敗が少ない。設定名の綴りの誤りは TOML として正しく、エラーにならないまま効かない。
• □や?の原因は、Nerd Font が無いこととロケールが UTF-8 でないこと。手元では Nerd Font 以外のフォントが私用領域 U+E0A0 に別の絵を持っていた。git status は2万ファイルで約26ミリ秒、大量の書き換え直後は100ミリ秒を超えた。

次に読むとよい記事です。Git の状態の記号の読み方は関連記事「git statusの見方｜Untracked等の意味と-s短縮表示の記号一覧」で、端末を分割して使う方法は関連記事「tmuxの使い方｜キーバインド早見表とコピペ用.tmux.conf」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• Starship 公式「ガイド（インストールとシェルの設定）」：https://starship.rs/ja-JP/guide/
• Starship 公式「Configuration」：https://starship.rs/config/
• Starship 公式「Advanced Configuration」：https://starship.rs/advanced-config/
• Starship 公式「Presets」：https://starship.rs/presets/
• Starship 公式「FAQ」：https://starship.rs/faq/
• GitHub starship/starship「Releases（v1.27.0）」：https://github.com/starship/starship/releases
• GitHub starship/starship「src/init/starship.bash・starship.zsh」：https://github.com/starship/starship/tree/master/src/init
• GitHub romkatv/powerlevel10k「README」：https://github.com/romkatv/powerlevel10k
• GitHub ohmyzsh/ohmyzsh「README・oh-my-zsh.sh」：https://github.com/ohmyzsh/ohmyzsh
• TOML「TOML v1.0.0（文字列）」：https://toml.io/en/v1.0.0#string
• GNU「Bash Reference Manual：Bash Startup Files」：https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。