Back to Blog
GhosttyNeovimvimCUIターミナルAWSLinux独学

Ghostty + Neovimを選んだ理由 ― CUIに慣れるための合理的な選択

エンジニアリングは手段であって目的ではない

最初に断っておくと、私の最終目標はエンジニアになることではない。

目指しているのは、AIを活用した何かしらの起業や事業開発だ。エンジニアリングはそのための手段の一つに過ぎない。

ただ、誤解のないように言っておくと、エンジニアリングやコードを書くこと自体は楽しい。新しい技術を学ぶたびに視野が広がるし、作りたいものが作れるようになる感覚は純粋に面白い。極めてポジティブな状態で、必要なスキルを一つずつ身につけているフェーズだ。

この前提があるから、「エンジニアとして正しい学び方」にはこだわらない。最短で実践に使えるスキルを身につけることを優先している。

独学で開発スタイルを構築している

周りにエンジニアがいない。会社にもいないし、プライベートでも聞ける人がいない。

この環境で開発スキルを身につけるには、自分で情報を集めて、自分で試すしかない。私が採用している方法は以下の3つだ。

  1. 技術書を読む — 体系的な知識のベースを作る
  2. AIに相談する — やりたいことを言語化し、選択肢を整理する
  3. YouTubeの動画を見る — 実際の操作感やワークフローを視覚的に理解する

これらを組み合わせて「これが良さそう」という仮説を立て、実践に移す。試してみて合わなければ別の方法を探す。この繰り返しだ。

Ghostty + Neovimという組み合わせも、この方法で行き着いた。

なぜGhostty + Neovimなのか

エディタ選びには大きく2つの流派がある。

  • ターミナル派: Ghostty/iTerm2/Alacritty + vim/neovim
  • GUI派: VSCode、JetBrains系、Zed

Neovimを選ぶ時点で「ターミナル中心のワークフローを好む」という自己選択が働いている。GUIの快適さを優先するなら、最初からVSCodeやJetBrainsを選ぶ方が合理的だ。

では、なぜあえてターミナル派を選ぶのか。

動機: Linux/AWSを操作したい

自分の場合、CUIに慣れたいという明確な動機があった。

  • スタートアップでサーバーを自前で立ち上げる可能性
  • AWS EC2インスタンスの操作
  • ネットワーク設定やトラブルシューティング

これらの場面では、GUIエディタは使えない。sshでサーバーに接続し、ターミナルで作業することになる。そのとき使えるエディタは、ほぼvimかnanoの二択だ。

vimが最も汎用的な理由

サーバー上での作業を考えると、vimをある程度使えるようにしておくのは合理的だ。

  • ほぼ全てのLinux環境にvi/vimがプリインストールされている
  • 最小構成のDockerコンテナやAlpine Linuxでもviは入っている
  • リカバリーモード、シングルユーザーモードでも使える
  • /etc/配下の設定ファイル編集はvimが事実上の標準

必要な操作は意外と少ない

「vimをマスターする」と聞くと身構えるかもしれないが、サーバー作業に必要な操作は限られている。

操作 コマンド
移動 h/j/k/l, gg, G
挿入モード i, a, o
保存・終了 :wq, :q!
削除・コピペ dd, yy, p
検索・置換 /, :%s/old/new/g

これだけで設定ファイルの編集は十分こなせる。そして、この操作は全てNeovimで練習できる。

Neovimで練習 → サーバーの素のvimでも使える

Neovimはvimの上位互換なので、Neovimで覚えた操作はそのままサーバー上の素のvimで使える。

逆に、Neovim特有の機能（LSP補完、Treesitter、プラグイン等）はサーバー上では使えないことが多いが、基本操作は共通だ。

Ghosttyは単なるターミナルエミュレータなので、Neovimの操作には影響しない。Ghosttyの高速レンダリング、True Color対応、ligature対応といった恩恵を受けながら、サーバー作業に必要なスキルを身につけられる。

UTMでUbuntuを試している

現在、MacにUTMを入れてUbuntu Desktopを動かしている。GUIも入っているが、意図的にターミナル中心で操作している。

これは学習目的として正しいアプローチだ。実際の本番サーバーはUbuntu ServerなどGUIなしが一般的なので、ターミナル操作に慣れておく必要がある。

慣れてきたらUbuntu Server（GUIなし）をUTMに入れると、より実践的な環境になる。

AWS環境も基本的に同じ

AWS EC2インスタンスも、基本的にはssh接続 + ターミナル操作だ。GUIなしのAmazon LinuxやUbuntu Serverが標準で、UTMでやっているターミナル操作がそのまま本番の作業に使える。

ただし、最近のトレンドとして:

  • マネージドサービス（RDS、Lambda、Fargate等）を使うと、直接sshする機会は減っている
  • IaC（Terraform、CloudFormation）でインフラをコード管理
  • コンテナ化（ECS、EKS）でサーバーに入らず運用

つまり「sshしてvimで設定ファイル編集」は減少傾向だが、トラブルシューティングや緊急対応では必ず必要になる。

sshして調査・対応とは

「sshして調査・対応」とは、具体的にはこういう作業だ。

シナリオ: Webサービスが突然動かなくなった

# 1. サーバーに接続
ssh ubuntu@your-ec2-instance

# 2. アプリのログを確認
tail -f /var/log/app/error.log

# 3. プロセスが動いているか確認
ps aux | grep nginx

# 4. ディスク容量を確認（満杯で止まることがある）
df -h

# 5. メモリ確認
free -m

# 6. 設定ファイルを確認・修正
vim /etc/nginx/nginx.conf

# 7. サービス再起動
sudo systemctl restart nginx

普段はマネージドサービスやIaCで運用していても、問題が起きたらsshでサーバーに入り、原因を調べて直す。このときvimが使えないと詰む。

NASへのファイル共有とsshの違い

会社の共有サーバーにFinderからアクセスしているなら、それはsshではなくSMB/NFSによるファイル共有だ。

接続方法 プロトコル 操作 用途
NAS接続 SMB, NFS Finder、ドラッグ&ドロップ ファイルの読み書き
ssh接続 SSH ターミナル、コマンド サーバー自体の操作

NASは「ファイルを置く棚にアクセスしている」、sshは「サーバーの中に入って操作している」という違いがある。

そして、ファイル共有の権限とssh権限は別物だ。多くの組織では:

  • ファイル共有: 一般社員に開放
  • ssh接続: 管理者のみ

sshで接続できるとサーバーの設定を変更できてしまうため、セキュリティ上、限られた人にしか与えないのが一般的だ。

まとめ

Ghostty + Neovimを選んだのは、Linux/AWSを操作するためにCUIに慣れたいという動機からだ。

  • ターミナル中心のワークフローを好む人がNeovimを選ぶ
  • GUIを重視するならVSCodeやJetBrainsの方が合理的
  • サーバー作業ではvimが事実上の標準
  • Neovimで練習した操作は、サーバー上の素のvimでそのまま使える
  • 必要な操作は限られており、マスターまでは不要

今UTMで練習している内容は、そのまま本番のサーバー運用に活きる。入門ステップとして妥当な選択だと考えている。

Share:
View all posts