【2026年】Starship プロンプトカスタマイズ2026｜クロスシェル対応プロンプト完全ガイド

Homebrew 経由でインストールした場合、自動でシェルの初期化設定を行うプロンプトが表示されることがありますが、手動で設定ファイルを指定する場合でも問題なく動作します。また、Windows ユーザーに対しては Scoop や Windows Package Manager (winget) が利用可能です。Scoop を使用している場合、以下のコマンドでインストールが可能です。

scoop install starship

それぞれのインストール方法には特徴があり、パッケージマネージャーを利用することで、OS 上の他のツールとの依存関係の解決がスムーズに行われます。一方、ソースコードからビルドしてインストールする「手動ビルド」の方法もあります。Rust を環境にインストールしており、最新の機能や非公開の機能を試したい場合や、特定のアーキテクチャ向けの最適化を行いたい場合に有効です。ただし、一般的な開発用途においてはパッケージマネージャー経由でのインストールが安定性と保守性の観点から推奨されます。

表 1：Starship インストール方法比較

設定ファイルの基本構成とカスタマイズ

Starship の設定は starship.toml という TOML 形式のテキストファイルで行います。このファイルは通常、ユーザーホームディレクトリの .config/starship/ 以下に配置されます。Linux や macOS では ~/.config/starship/starship.toml、Windows では %USERPROFILE%\AppData\Local\nu\starship.toml などが標準的なパスですが、環境変数 $XDG_CONFIG_HOME を利用することで、設定ディレクトリをカスタマイズすることも可能です。

初期段階では、インストール時に生成されたテンプレートファイルを利用するのが一般的です。しかし、このままの状態では多くのモジュールが無効化されているため、実際の開発環境に合わせた調整が必要です。設定の構造はシンプルで、トップレベルに各プロンプト要素（モジュール）の名前をキーとして配置し、その中にプロパティを設定します。例えば、Git ブランチ名を表示する git_branch モジュールの設定を行うには、ファイル内に以下のような記述を追加します。

[git_branch]
symbol = ""
format = "[[$symbol $branch(:$remote_branch)]($style)]($style)"

この設定では、symbol で表示されるアイコン、format で文字列の最終的な出力形式を定義しています。$style は変数であり、ブランチ名や色などのスタイル情報を自動で埋め込むプレースホルダーです。TOML 構文の理解があれば比較的容易に設定が組めますが、エラーが発生した場合は starship config check コマンドを使用して構文検証を行うことができます。

また、各モジュールには disabled というブール値のパラメータが存在します。特定の機能を完全に無効化したい場合や、起動速度を最優先して最小限の表示に抑えたい場合に利用します。例えば、開発中に Git 操作を行わないプロジェクトでは git_branch の設定で disabled = true とすることで、不要なチェック処理がスキップされ、パフォーマンスが向上します。さらに、特定の言語環境でのみ表示を設定する条件付きロジックもサポートされており、より高度なカスタマイズを可能にしています。

必須モジュールの深掘り設定

プロンプトの基本構成において最も重要なのが、ディレクトリパスと Git 情報の表示です。これらは開発者にとって常に必要なコンテキストであり、適切な設定を行うことで、現在の作業場所やコードの状態を一目で把握できます。directory モジュールは、現在いるディレクトリのパスを表示する機能ですが、長いパスが画面を埋め尽くさないよう工夫することが重要です。

[directory]
style = "blue"
format = "[ $path ]($style)"
truncation_length = 3
truncation_symbol = "//"
read_only_icon = "🔒"

上記の設定では、パスの表示長さを truncation_length で制限し、それより長い場合は // で省略しています。これにより、深い階層にあるディレクトリでもプロンプトが短く保たれます。また、読み取り専用（Read-only）モードでマウントされたボリュームの場合にのみ read_only_icon を表示させることで、重要なシステムファイルへの誤書き込みを防ぐ視覚的な警告にもなります。

次に、Git 関連のモジュール群について解説します。Starship は Git リポジトリを検出すると自動的に Git ブランチ名とステータス（コミット数、変更ファイル数など）を表示します。git_branch モジュールはブランチ名を、git_status モダジュールは変更状況をそれぞれ管理しています。これらを組み合わせることで、コードの状態を視覚的に把握できます。

[git_branch]
symbol = ""
format = "[[$symbol $branch(:$remote_branch)]($style)]($style)"

[git_status]
format = '([$all_status$ahead_behind]($style) )'
style = "bold green"
conflicted = "🔴"
ahead = "📈"
behind = "📉"
diverged = "😵"
untracked = "🤷"
staged = "+"
modified = "~"
deleted = "x"

この設定により、ブランチ名がアイコン付きで表示され、遠隔リポジトリとの差分（ahead_behind）も色付きのアイコンで示されます。さらに、未 tracked のファイルやステージされた変更など、細かな Git ステータスごとに異なるアイコンを割り当てることで、プロンプトから一瞬でリポジトリの状態を読み取ることが可能になります。2026 年現在では、Git のステータス表示の精度も向上しており、サブモジュールやリポジトリのネスト構造に対しても正しく検知するようになっています。

ランタイム関連モジュールの詳細

現代の開発環境では、複数のプログラミング言語のランタイムが併存することが一般的です。Starship はこのような多様な環境を自動的に検知し、対応するバージョン情報を表示します。これにより、プロジェクトごとに異なるバージョンのツールを使用している際にも、混同を防ぎます。特に Web 開発やデータサイエンスの分野では、Node.js や Python、Rust のバージョン管理が頻繁に行われます。

Node.js の場合、nodejs モジュールが対応しています。.nvmrc ファイルが存在する場合、自動的にそのファイルに記載されたバージョンが反映されます。同様に、Python については非常に多様なバージョン管理ツールに対応しており、conda、venv、pyenv、uv などすべて検知可能です。

[nodejs]
format = "[[($version)](bold yellow)]"

[python]
detect_files = ["python", "python3", "pyenv.toml"]
detect_extensions = ["py"]
symbol = "🐍"
style = "208"
format = "[[$symbol $pyenv_version ( $virtualenv )]]($style)"

Python の設定では、detect_files でプロジェクトの識別子を指定し、detect_extensions で拡張子を検出します。また、pyenv_version はバージョン管理ツールが検出したバージョンを、virtualenv は仮想環境の名前を表示する変数です。これにより、コンテナや仮想環境の中であっても、どの Python バージョンで動作しているかが明確になります。

Rust や Go、Java などの言語にも同様のモジュールが存在します。Rust の場合、rustup で管理されているバージョンが自動検知され、Go は go.mod ファイルの存在をトリガーにします。これらはデフォルトでは有効になっていますが、表示スタイルを統一したい場合は各モジュールの style 属性を調整します。

[rust]
format = "[[$version](bold yellow)]"

[golang]
symbol = "🐹"
format = "[[($version)](blue)]"

[java]
format = "[[($version) 🌊](green)]"

これらの設定を組み合わせることで、プロジェクトの技術スタックがプロンプトから明確に示されます。例えば、Rust で書かれた CLI ツールを開発中は黄色のバージョン表示、Go のマイクロサービス開発中なら青色など、色分けで言語を区別すると、複数言語を扱うチーム開発環境でも混乱を防ぐことができます。

環境変数・クラウド系モジュール

近年の開発トレンドとして、サーバーレスアーキテクチャやクラウドネイティブな環境での作業が増加しています。Starship は AWS、Google Cloud Platform (gcloud)、Azure のプロファイル情報をプロンプトに表示する機能を提供しており、マルチクラウド環境における誤操作リスクを低減します。また、Docker や Kubernetes などのコンテナ関連モジュールも標準でサポートされています。

AWS モジュールは、~/.aws/config ファイルや AWS_PROFILE 環境変数を読み込みます。アクティブなプロファイル名とリージョンが表示されるため、異なる AWS アカウント間で切り替えている際にも、誤って本番環境のデータを更新するなどのミスを防ぎます。Azure と gcloud も同様のロジックで動作し、それぞれのクラウド SDK が設定したコンテキスト情報を取得します。

[docker_context]
detect_files = ["docker-compose.yaml", "Dockerfile"]
symbol = "🐳"
format = "[[($symbol)](cyan bold)]"

[kubernetes]
detect_files = ["Kubeconfig", "kustomization.yaml"]
context_names_override = { prod="production", dev="development" }
style = "bold red"
format = "[[[$name](red bold)][$namespace]]($style)"

Docker モジュールは、コンテナファイルが存在するディレクトリで有効化され、Kubernetes モジュールは Kubeconfig の設定に基づいてアクティブなコンテキストを表示します。特に Kubernetes においては、context_names_override を使用して、複雑なコンテキスト名をユーザーフレンドリーな名前（例：prod, dev）に置き換えることが可能です。これにより、長い Kubernetes コンテキスト名がプロンプトを圧迫するのを防ぎます。

また、時間表示やバッテリー残量などのシステム情報を表示するモジュールもあります。time モジュールは現在時刻を表示し、battery モジュールはノートパソコンの残量をアイコンで示します。これらは環境によってオンオフを切り替えることで、プロンプトの情報密度を調整できます。

[time]
disabled = false
format = '🕙[\[ $time \]]($style)'
time_format = "%H:%M"
use_12hr = true

Nerd Fonts とアイコンの導入

Starship の視覚的な魅力、特にアイコン表示を実現するためには、Nerd Fonts が不可欠です。Nerd Fonts は、既存のフォントにプログラミング用や開発環境向けのアイコンをパッチしたフォセット群です。Starship がデフォルトで使用する文字コードは Unicode の絵文字や Powerline 記号ですが、一部のシステムやエディタではこれらが正しくレンダリングされない場合があります。Nerd Fonts を使用することで、これらのアイコンが均一に美しい形で表示されます。

推奨される Nerd Font には、「JetBrains Mono Nerd Font」、「Hack Nerd Font」、「FiraCode Nerd Font」、「MesloLGS NF」などがあります。2026 年時点では、JetBrains Mono Nerd Font が最も人気を集めており、コードの可読性とアイコン表示のバランスが優れています。Hack Nerd Font は、より高い文字密度を必要とする環境に、FiraCode は開発者コミュニティでの採用率が高いという特徴があります。

# Ubuntu/Debian 系の場合（例：JetBrains Mono Nerd Font）
sudo apt install fonts-jetbrains-mono-nerd

# macOS の Homebrew 経由でインストールする場合
brew tap homebrew/cask-fonts
brew install --cask font-jetbrains-mono-nerd-font

Linux ユーザーはディストリビューションのレポジトリから、macOS ユーザーは Homebrew Cask から Font をインストールできます。Windows の場合は、フォントファイル（.ttf または .otf）をダウンロードしてシステムにインストールする必要があります。インストール後、ターミナルの設定で「使用するフォント」を選択し、「JetBrains Mono Nerd Font」などを指定してください。

表 2：推奨 Nerd Fonts 比較

フォントが正しく設定されていない場合、プロンプトに ? や豆腐（口文字）が表示されることがあります。この場合、ターミナルの設定を見直して、正解の Nerd Font が選択されていることを確認してください。また、Starship はフォントが見つからない場合に自動的にデフォルトの絵文字へダウングレードする機能も備えていますが、視認性を高めるためにも Nerd Font の使用を強く推奨します。

プリセットとテーマの活用

Starship には開発者がすぐに使える「プリセット」が用意されています。これらは、特定の色彩構成やスタイルをまとめた設定テンプレートです。pure は元祖のプロンプトの一つである Pure プロンプト風のデザインで、pastel-powerline はパステルカラーの Powerline スタイル、tokyo-night は人気のある IDE テーマ「Tokyo Night」の配色を採用しています。

プリセットを使用するには、設定ファイル内で style = "..." を指定するのではなく、トップレベルで style = "..." にプレセット名を記述します。例えば、starship.toml の先頭に以下のように記述すると、東京夜景風の配色が適用されます。

style = "tokyo-night"

このように設定することで、各モジュールの色やアイコンの配置を一度に切り替えることができます。カスタマイズが難しい初心者にとっては、プリセットから始めるのが最も効率的です。また、2026 年時点ではコミュニティによるカスタムテーマも多数公開されており、GitHub や Starship の公式ドキュメントで確認できます。

さらに、色のカスタマイズは HEX コードや RGB カラーを使用することで可能です。特定のモジュールの色だけを変更したい場合、個別のモジュール設定内で style を指定します。例えば、エラーを示す赤いアイコンをより鮮やかな crimson に変更するには以下のように記述します。

[git_status]
conflicted = "crimson"
style = "bold red"

色の選定は視認性に直結するため、コントラスト比に配慮した配色が推奨されます。特に、長時間ターミナルを使用する環境では、目に優しい配色（例：Dark 系テーマ）を選ぶことで疲労軽減につながります。また、明るい背景のターミナルであれば、逆に明るい色をスタイルに指定することで、文字と背景の区別をつけやすくします。

Starship と Powerlevel10k の比較

Shell プロンプトの世界では、Starship と並ぶ人気ツールとして「Powerlevel10k (P10k)」があります。特に zsh ユーザーの間では P10k が非常に一般的ですが、両者には明確な違いと長所短所があります。2026 年現在でもこの比較は重要であり、自身の開発環境や使用するシェルに合ったツールを選ぶ必要があります。

Powerlevel10k は zsh の高度なカスタマイズを前提としており、インタラクティブなクエリによる設定ウィザードを提供しています。その結果、非常に洗練された表示が可能ですが、zsh 以外のシェル（bash、fish、PowerShell など）では使用できません。一方、Starship はクロスシェル対応であり、環境が変わっても同じ設定ファイルを維持できます。

表 3：プロンプトツール比較詳細

速度の観点では、Starship が Rust で書かれたバイナリであるため、Shell スクリプトを解釈するオーバーヘッドが少なく、起動時間が短くなります。特に、Git のステータスチェックなど重い処理を行う際にも、バックグラウンドで非同期処理を行うなどの最適化により、ターミナルの応答性を損ないません。Powerlevel10k は zsh の機能を活用しているため多少重くなる傾向がありますが、その分、インタラクティブな情報提供（クエリやヒント）に優れています。

カスタマイズ性においては、Starship はファイルベースであるためバージョン管理システム（Git）で設定を管理しやすく、チームでの共有も容易です。Powerlevel10k はスクリプトベースのため、環境ごとの差異が出やすいですが、詳細な制御が可能です。どちらを選ぶかは、「クロスシェル対応が必要か」および「起動速度とリソース使用量を重視するか」によって決まります。

トラブルシューティングとパフォーマンス最適化

Starship を導入した際に発生する可能性のある問題に対する対処法を解説します。最も一般的な問題は、インストール後の設定が反映されないケースです。これは、シェルの初期化スクリプト（init.bash など）が呼び出されていない場合に起こります。各シェルでの設定ファイル（.bashrc, .zshrc 等）に以下の行を追加して確認してください。

# zsh の場合
eval "$(starship init zsh)"

# bash の場合
eval "$(starship init bash)"

このコマンドは、Shell 起動時に Starship を初期化し、プロンプトを有効化します。もしエラーが発生する場合は、init.bash が存在するかを確認し、パスが正しいかを確認してください。また、古いバージョンの Starship のキャッシュが残っている場合は、starship cache clear コマンドでキャッシュを削除すると改善されることがあります。

パフォーマンスに関する問題では、モジュール数が多すぎることによる遅延が発生することがあります。Git リポジトリ内の Git 操作が頻繁な場合や、ネットワーク接続が必要なクラウドコンテキストの取得がボトルネックになることがあります。この場合は、git_status や time モジュールを無効化（disabled = true）するか、表示形式を変更して計算コストを下げる設定を行います。

# Git 情報を非同期で取得する設定（Starship 1.23+ で強化）
[git_branch]
async = true

また、起動時のメモリー使用量が高い場合は、Nerd Fonts のインストール状態を確認してください。フォント読み込みエラーが繰り返されると、ターミナルの再描画に時間がかかることがあります。デバッグモードである starship module -v を実行することで、どのモジュールがどの程度時間を消費しているかをログ出力から確認できます。これにより、ボトルネックとなっているモジュールを特定し、最適化を行うことが可能です。

よくある質問（FAQ）

Q1: Starship プロンプトがインストールされた後、プロンプトが表示されない場合どうすればいいですか？ A1: 設定ファイルに初期化スクリプトの読み込み記述がない可能性が高いです。シェルの設定ファイル（.zshrc や .bashrc）を確認し、「eval "$(starship init zsh)"」のようなコマンドが追加されているか確認してください。また、ターミナルを再起動して設定を適用させてください。

Q2: 起動時に「command not found」というエラーが出ます。 A2: Starship のインストールパスがシステム PATH に含まれていない可能性があります。which starship コマンドでパスを確認し、starship --version でバージョンが出力されるか試してください。インストールスクリプトの実行権限を付与していない場合もあります。

Q3: アイコンが豆腐（□）や？マークに変わって表示されます。 A3: 使用しているターミナルフォントが Nerd Fonts に対応していない可能性があります。「JetBrainsMono Nerd Font」などをインストールし、ターミナルの設定でそのフォントを選択してください。Starship は対応フォントがない場合、デフォルト文字へダウングレードします。

Q4: プロンプトの表示が遅いと感じます。 A4: 有効になっているモジュールが多いか、Git ステータスチェックに時間がかかっている可能性があります。不要なモジュールを disabled = true で無効化するか、git_status の設定を見直してください。また、非同期処理が有効になっているか確認します。

Q5: Powerlevel10k と Starship、どちらを使うべきですか？ A5: zsh 専用で高度なカスタマイズと対話型設定を希望する場合は Powerlevel10k がおすすめです。一方、複数のシェルや OS で統一された環境が必要な場合は Starship が最適です。起動速度も Starship が優れています。

Q6: Python のバージョン管理ツール（pyenv, conda）が検知されません。 A6: 環境変数が正しく設定されているか確認してください。starship module -v python でデバッグ情報を取得し、どのファイルやパスを検索しているか確認します。プロジェクトルートの pyproject.toml や .venv ファイルの存在もチェックしてください。

Q7: AWS のプロファイルを自動検知させたいです。 A7: ~/.aws/config 内に設定済みのプロファイル名が Starship によって自動的に検出されます。特に追加設定は不要ですが、AWS_PROFILE 環境変数がアクティブな場合に依存するため、ターミナルでプロファイルを切り替えてからプロンプトを確認してください。

Q8: Starship の設定をバックアップしたいです。 A8: ~/.config/starship.toml ファイルが設定ファイルの本体です。このファイルを Git リポジトリやクラウドストレージ（Dropbox など）に保存しておくことで、環境移行時に迅速な復元が可能です。

Q9: 複数の開発環境で色を統一したいですが可能ですか？ A9: はい、可能です。style = "tokyo-night" のようにトップレベル設定でプレセットを指定するか、共通の TOML ファイルをコピーして利用することで、複数端末でも同じ見た目に統一できます。

Q10: 2026 年以降も Starship はメンテナンスされ続けますか？ A10: はい、Rust 言語によるクロスシェル対応プロンプトとして需要が高く、公式チームによって継続的に更新されています。2026 年時点でも主要な機能は安定してサポートされており、セキュリティアップデートも行われています。

まとめ

本ガイドでは、Starship プロンプトのインストールから高度なカスタマイズ、トラブルシューティングに至るまでを網羅的に解説しました。2026 年の開発環境において、Starship はクロスシェル対応と高速性を両立する最強のプロンプトツールの一つです。以下の要点を心に留めておいてください。

• インストールはパッケージマネージャー推奨: Homebrew や Scoop を使用することで、システムとの整合性が高まります。
• 設定ファイルの統一: starship.toml を Git で管理し、複数の環境間で設定を共有します。
• Nerd Fonts の活用: 視認性を高めるため、JetBrainsMono Nerd Font などのフォントインストールが必須です。
• モジュールの最適化: 不要な表示を無効化することで、起動速度とレスポンスを最大化できます。
• Powerlevel10k との違い理解: シェル依存性やカスタマイズの自由度を理解し、用途に合わせて選択します。

Starship を活用して、より洗練された開発環境を手に入れましょう。設定の調整は継続的なプロセスであり、自身の作業スタイルに合わせた最適化を繰り返していくことが、生産性の向上につながります。

Windows PowerShellのプロファイルをカスタマイズして開発効率を向上させるガイド。Oh My Posh・PSReadLine・モジュール管理・エイリアス設定の実践的な設定方法を解説。