日本語
Windows / macOS 統合ターミナル環境の構築

Windows / macOS 統合ターミナル環境の構築

WindowsとmacOSの両方で動作するクロスプラットフォームのターミナル環境の構築手順

はじめに


最近MacBook Airをアップグレードしたため、環境を再設定する必要性を感じた。

M1からM5への性能面での変化には満足しているが、以前使っていた環境を再び整えようとすると手間がかかることが分かり、この機会に全プロセスを文書化し、手軽に再設定できるよう標準化しようと思った。

[2026 Mac ターミナル完全設定 (Ghostty + Starship + AI コーディング環境)](https://blog.dnd.ac/settings-mac-terminal-2026/

)


その過程で特に印象に残った資料が、上記のリンク先のものだった。すっきりとしていて見栄えの良い環境がスクリプトとしてまとめられており、大いに参考になった。

結論から言うと、以下のような形でターミナル環境を構築することができました。



内部的には、Wezterm + Nushell + LazyVimを大枠として設定しています。

[Githubリンク](https://www.github.com/TraceofLight/global-terminal-settings

) で設定の全ガイドを確認でき、そのガイドを通じてWindows、MacOSに同一の環境を構築できるようにしています。

目標設定


この作業の目標は明確だった。

  • Windows / MacOSで同一のターミナル環境を使用すること

  • LazyVimベースのエディタと問題なく動作すること

  • 既存の使用環境と大きく変わらないこと

  • tmuxのようなマルチプレクサツールを問題なく使用できること


このような目標を達成するために作業を進めてみた。

進行過程


まず、使用する技術を選定する必要があった。最近のトレンドとしては、GPUアクセラレーションによるレンダリングが可能なGUIを備えたターミナルエミュレーターが主流であり、実際にこうしたツールが注目されている理由は、高速で装飾が可能であるという点にある。前述のリンクで示したように、ターミナルを構築するにはこうした要素が必要だったため、その中からWeztermを選択することにした。


  1. ターミナルエミュレーター

    まず、クロスプラットフォームで同一のUXを提供する必要があったため、エコシステムが構築されたクロスプラットフォームのターミナルエミュレーターとしてはAlacrittyやWezterm程度があると考えた。ミニマリズムを追求するAlacrittyは拡張性に欠けると感じたため、Weztermを選択することになった。マルチプレクサーを搭載している点もメリットの一つだ。

  2. シェル

    両プラットフォームで同一の操作感を保証する必要があったため、まずはUnixコマンドが使用できる環境に統一しようと試みた。その結果、Windowsではbash、macOSではzshを使用することに初期段階で決定していた。しかし、いくつかの問題があり、最終的にはNushellベースに統一することになった。

  3. LazyVim

    実はこちらについては、すでに使用していたツールがあり、問題なくほとんどの環境で統合できたため、難しくはなかった。 もともとSpaceVimを使用していたが、こちらはすでに[メンテナンスが終了した状況](https://wsdjeg.net/why-spacevim-is-archived/

)であったため、LazyVimに移行してからある程度時間が経過していたことに加え、基本的にはIDEを使用しており、補助的なツールとして利用しているため、スムーズにインストールが進んだようだ。

問題の発生

この過程でいくつかの問題が存在したが、2つの問題はいずれもNushellへの移行に関連している。

  1. Windowsではbashが体感できるほど遅すぎる

    実際、後で確認してみると、これは予見されていた結末だったようだ。Windows環境下では、POSIX式の動作をWindowsで処理するために、互換性のための処理が追加レイヤーとして挿入されることが分かった。そのため、実際にwsl2環境に移行することも検討したが、それは結局Linuxを使用することと変わらないため、除外した。

    -> この問題を解決するためのツールとして、nushellを導入することになった。Unixコマンドと互換性のある部分が多い点、Rustベースで設計されておりある程度のパフォーマンスも保証されている点、MacOSでも同様の環境設定が可能である点を考慮した。

  2. Windowsのnushellでnaviプラグインが動作しない

    naviは、ターミナルコマンドのチートシートとして参照するためのプラグインである。それほど頻繁に活用するわけではないが、当該ツールの機能が全く動作しないのは困るため、いくつかの方法を検討した。結局、naviをフォークして当該問題を解決した後、新たにビルドしたプラグインを使用することで対処した。

    • 原因:ユーザーのシェルが変更されても、内部ではbashベースの構文が適用されるため、nushell使用時に不具合が発生する状況

    • 解決策:該当部分をシェルスクリプトによるコマンドで処理する代わりに、関連する依存関係を排除するため、wgetを使用すべき箇所でRustのHTTPクライアントを使用し、bashを使用すべき箇所でpwshを使用するなど、内部ヘルパーがbashに依存している部分を排除した

    • [詳細な修正履歴](https://github.com/TraceofLight/navi/tree/fix/nushell-usability

)

結論

開発者はターミナルを使用する機会がかなり多く、環境が一つに統合されれば使い勝手が良くなるのは当然のことだ。だからこそ、クロスプラットフォームかつ同一のユーザビリティをサポートするJetBrainsのIDEにはメリットがあるのではないだろうか。同様に、ターミナルにおいても、自分が追求するものが様々な環境において統一された操作感を維持することであるならば、このような方法を試してみるのも良いと思う。

댓글 작성

게시글에 대한 의견을 남겨 주세요.

댓글 0