Ghostty + tmux + Claude Code で最強ターミナル開発環境を作る|エディタを捨てた僕の開発スタイル

「VS Code や Cursor を開かずに、ターミナルだけで1日の開発が完結する」 と言ったら、信じてもらえるでしょうか。

僕は半年前まで Cursor をメインエディタにしていました。でも Claude Code の登場で状況が一変し、今は Ghostty + tmux + Claude Code の3点セットがメイン開発環境です。エディタを開くのは週に1〜2回、GUI でないと確認しづらい作業のときだけ。

僕は福祉事業の IT 全般を担当する CTO と個人事業(開発受託・コンサル・コンテンツ制作)を兼業しているエンジニアです。Mac mini M4 Pro で AI エージェントシステムを24時間稼働させつつ、iPad + SSH でカフェからもコードを書いています。

この記事を読むと、以下のことがわかります。

  • なぜエディタからターミナル中心の開発に移行したのか
  • Ghostty を選んだ理由と実用的な設定例
  • tmux のセッション設計(案件単位で管理する方法)
  • Claude Code と組み合わせた実際のワークフロー
  • Cursor / VS Code との現実的な使い分け

なぜエディタからターミナルに移行したか

きっかけは Claude Code の登場です。

それまでの AI コーディングは「エディタの中で AI を呼び出す」という形でした。Cursor も GitHub Copilot もそう。エディタが主役で、AI はあくまで補助。

Claude Code は逆です。ターミナルが主役で、AI がファイルを読み書きし、テストを実行し、Git 操作まで完結する。エディタの GUI を介さず、コマンドラインで直接やり取りする。このアプローチを体験したとき、「エディタ、もう要らないのでは?」と感じました。

実際に試してみると、想像以上に快適でした。理由は3つ。

  1. コンテキストスイッチが減る: エディタのタブやサイドバーを切り替える必要がない。tmux のペイン切り替えだけで済む
  2. SSH 越しでも同じ環境: iPad からでも、外出先のラップトップからでも、tmux にアタッチすれば完全に同じ開発環境が復元する
  3. AI に任せる範囲が広がる: エディタの GUI を前提とした操作(マウスでの選択、ファイルツリーのクリック等)がなくなり、すべてをテキストベースの指示で完結できる

Claude Code の生産性をさらに上げる方法でも詳しく書いていますが、ターミナルベースの開発は「AI と人間の協業」に最適化された形だと感じています。

Ghostty とは — 選んだ理由

Ghostty は、HashiCorp 創業者の Mitchell Hashimoto が開発したターミナルエミュレータです。2024年末に v1.0 がリリースされ、2026年現在も活発に開発が続いています。

選んだ理由

僕がそれまで使っていた iTerm2 から Ghostty に乗り換えた理由は以下の3つ。

Ghostty の最大の強みはGPU 描画 + macOS ネイティブ + シンプルな設定の3点。tmux と組み合わせるなら、他のターミナルエミュレータを圧倒するパフォーマンスが得られます。

1. GPU 描画による高速レンダリング

Ghostty は OpenGL を使った GPU アクセラレーションで描画します。大量のログを流しても、長いファイルをスクロールしても、描画が引っかからない。tmux 内で複数ペインを開いて同時にビルドログを流す場面では、この差が体感できます

2. macOS ネイティブ UI

Swift + AppKit で書かれているため、macOS のネイティブタブがそのまま使えます。Mission Control との統合もスムーズ。「ターミナルだけど OS の一部のように動く」感覚は、他のクロスプラットフォーム系ターミナルにはないものです。

3. 設定がシンプル

Ghostty は設定ファイルがなくてもそのまま使えるくらいデフォルトが優秀です。フォントは JetBrains Mono が組み込まれ、Nerd Fonts もビルトイン。必要最小限の設定だけ書けばいいので、.vimrc のように設定ファイルが肥大化する心配がありません。

Ghostty が向いている人

  • macOS をメインで使うエンジニア
  • tmux と併用する人(描画の安定性が重要)
  • 設定に時間をかけたくない人
  • GPU 描画による滑らかさを重視する人

逆に、Windows がメインの人には現時点では向きません(Windows 版は開発中)。

tmux のセッション設計 — 案件単位で管理する

tmux は「ターミナルの中にターミナルを作る」多重化ツールですが、使い方の設計で生産性が大きく変わります。

僕の設計方針は 「1セッション = 1案件」 です。

tmux セッション一覧
┌───────────────────────────┐
│ masu-agent    ← 常駐サービス群(24時間稼働)        │
│   ├── 1:bot          Discord Bot                  │
│   ├── 2:dashboard    ダッシュボード API           │
│   ├── 3:orchestrator 自動タスク実行               │
│   └── 4:logs         ログ監視                     │
│                                                      │
│ client-work      ← 案件作業                         │
│   ├── 1:code        Claude Code セッション        │
│   ├── 2:server      開発サーバー                  │
│   └── 3:test        テスト実行                    │
│                                                      │
│ personal      ← 個人事業の案件作業                  │
│   ├── 1:code        Claude Code セッション        │
│   ├── 2:server      開発サーバー                  │
│   └── 3:test        テスト実行                    │
└───────────────────────────┘

なぜ案件単位なのか

以前は「1つのセッションにウィンドウを大量に作る」やり方でした。でも複数案件を並行すると、すぐにウィンドウが10個以上に膨れ上がって管理不能になります。

「1セッション = すべての案件」という構成は避けましょう。ウィンドウが10個以上に膨れると、Ctrl+b → w(ウィンドウ一覧)で迷子になります。

案件単位でセッションを分けると:

  • tmux ls で「今どの案件が動いているか」が一目でわかる
  • 案件が終わったら tmux kill-session -t 案件名 で綺麗に片付く
  • 各セッションのウィンドウ構成が統一されるので、迷わない

階層の使い分け

階層 用途 粒度
セッション 案件・プロジェクト クライアント or プロダクト単位
ウィンドウ タスク種別 code / server / test / logs
ペイン 並列作業 ログを見ながらコマンド実行

この「セッション = プロジェクト、ウィンドウ = タスク、ペイン = ビュー」という階層設計は、慣れると非常に見通しがよくなります。

Claude Code 連携 — ターミナルだけで開発が完結する

Ghostty + tmux の環境に Claude Code を組み合わせると、開発のほぼすべてがターミナル内で完結します。

graph LR A[Ghostty] --> B[tmux セッション] B --> C[ウィンドウ1: Claude Code] B --> D[ウィンドウ2: 開発サーバー] B --> E[ウィンドウ3: テスト/Git] C --> F[ファイル読み書き] C --> G[コマンド実行] C --> H[Git 操作] C --> I[WebSearch / MCP] style A fill:#e8f4f8,stroke:#39b7ff style C fill:#d4edda,stroke:#28a745

Claude Code が担う作業

  • コード生成・編集: 「この関数をリファクタリングして」「エラーハンドリングを追加して」
  • テスト実行と修正: テストを走らせ、失敗したら自動で修正を試みる
  • Git 操作: コミット、ブランチ作成、差分確認
  • ファイル検索: GrepGlob でコードベース全体を横断検索
  • Web 検索: 最新のドキュメントや API 仕様を調べる

バイブコーディングの実践比較で詳しく書きましたが、Claude Code のターミナル内完結型のアプローチは、エディタ統合型とは根本的に異なる体験です。

CLAUDE.md でプロジェクトルールを定義

Claude Code はプロジェクトルートの CLAUDE.md を自動で読み込みます。ここに技術スタック、コーディング規約、禁止操作などを書いておくと、毎回指示しなくても正しく動いてくれます。

CLAUDE.md はプロジェクトごとに作成。技術スタック、コーディング規約、禁止操作を書いておくと、Claude が生成するコードの品質が劇的に変わります
## テクノロジースタック
- TypeScript (Node.js) / ESModules
- npm workspaces(モノレポ)
- SQLite

## Git 規約
- コミットメッセージは日本語で記述

実際のワークフロー

僕の1日の開発フローを紹介します。

朝のルーティン

# Mac mini に SSH 接続(Tailscale 経由でどこからでも)
ssh masu-mini

# 常駐セッションの状態を確認
tmux ls

# 案件セッションにアタッチ
tmux attach -t client-work

Mac mini を AI エージェントサーバーとしてセットアップする方法で詳しく書いていますが、Tailscale を使えば VPN 不要でどこからでも安全に接続できます。

案件作業の切り替え

# 今の作業をデタッチ(セッションは裏で動き続ける)
# Ctrl+b → d

# 別の案件にアタッチ
tmux attach -t personal

エディタだと「プロジェクトを閉じて別のプロジェクトを開く」という手順が必要ですが、tmux ならデタッチ → アタッチの2秒で完了。しかも前のセッションは裏で動き続けるので、ビルドやテストが途中でも中断されません。

リモート開発(カフェから iPad で)

# iPad の SSH クライアントから接続
ssh masu-mini

# 朝の続きがそのまま残っている
tmux attach -t client-work
# → Claude Code のセッション、開発サーバー、すべてそのまま

これが tmux の最大の強みです。状態がサーバー側に保持されるので、接続元のデバイスが何であっても、まったく同じ環境が復元します。iPad だろうがラップトップだろうが関係ありません。

Ghostty のおすすめ設定

Ghostty の設定ファイルは ~/.config/ghostty/config に置きます。僕の設定は最小限にしています。

# フォント
font-family = JetBrains Mono
font-size = 14
font-thicken = true

# テーマ
theme = GitHub Dark Default

# 背景の透過(tmux と併用するなら控えめに)
background-opacity = 0.95

# macOS 固有
macos-titlebar-style = tabs
macos-option-as-alt = true

# ウィンドウ
window-padding-x = 8
window-padding-y = 4

# キーバインド(tmux と干渉しない範囲で)
keybind = cmd+d=new_split:right
keybind = cmd+shift+d=new_split:down

設定のポイント

macos-option-as-alt = true の設定は必須です。これがないと tmux のキーバインド(Option+矢印でペイン移動など)が正しく動きません。
  • font-thicken = true: Retina ディスプレイでフォントが細く見える問題を解決
  • background-opacity = 0.95: 完全透過にすると背後の画面が邪魔になるので、ほんのり透ける程度がベスト
  • macos-option-as-alt = true: Option キーを Alt として使えるようにする。tmux のキーバインドで重要
  • テーマ: ghostty +list-themes で一覧表示できる。Catppuccin Mocha や Dracula も人気

設定を変更したら Cmd+Shift+, でリアルタイムにリロードされます。ターミナルを再起動する必要はありません。

tmux のおすすめ設定

~/.tmux.conf の設定例です。

# プレフィックスキーを Ctrl+a に変更(Ctrl+b より押しやすい)
set -g prefix C-a
unbind C-b
bind C-a send-prefix

# マウスサポート(スクロールやペイン選択)
set -g mouse on

# ウィンドウ番号を1始まりに
set -g base-index 1
setw -g pane-base-index 1

# ペイン分割のキーバインド(直感的に)
bind | split-window -h -c "#{pane_current_path}"
bind - split-window -v -c "#{pane_current_path}"

# ペイン移動を Vim 風に
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# 256色サポート + Ghostty との互換性
set -g default-terminal "tmux-256color"
set -as terminal-overrides ",xterm-ghostty:RGB"

# Ghostty の拡張キーサポート
set -s extended-keys on
set -as terminal-features 'xterm-ghostty:extkeys'

# ステータスバー
set -g status-style 'bg=#1a1b26 fg=#c0caf5'
set -g status-left '#[fg=#7aa2f7,bold] #S '
set -g status-right '#[fg=#565f89] %Y-%m-%d %H:%M '

# コピーモード(Vi キーバインド)
setw -g mode-keys vi

Ghostty + tmux の互換性設定

以下の3行は必ず設定してください。これがないと tmux 内で色がおかしくなったり、特殊キーが正しく伝わらなかったりします。

特に重要なのは以下の3行です。

set -g default-terminal "tmux-256color"
set -as terminal-overrides ",xterm-ghostty:RGB"
set -s extended-keys on

Ghostty と tmux を併用するなら必ず設定しておきましょう。

Cursor / VS Code との使い分け

「エディタを捨てた」とタイトルに書きましたが、完全に捨てたわけではありません。正直に使い分けを書きます。

ターミナル(Ghostty + tmux + Claude Code)が向いている作業

  • 新機能の実装(Claude Code に任せる範囲が大きい)
  • リファクタリング(複数ファイルの一括変更)
  • バグ修正(エラーログを見ながら修正 → テスト)
  • Git 操作全般
  • リモートからの作業
  • AI に指示を出して放置する自動化タスク

エディタが向いている作業

  • UI/UX のデザイン確認(プレビューが必要)
  • 大規模なコードリーディング(ファイルツリーを行き来する)
  • 画像・SVG の編集
  • Jupyter Notebook の操作
  • Git の差分を視覚的に確認したいとき

僕の体感では、日常の開発作業の8割はターミナルで完結します。残り2割のためにエディタを残していますが、起動頻度は週に1〜2回まで減りました。

AI コーディングエージェントの比較記事でも触れていますが、ターミナル型とエディタ統合型は排他ではなく、組み合わせるのが現実的な最適解です。

エディタ依存を続けた開発者が失うもの

ターミナル開発環境に興味がありながら「まだ今のエディタで困っていないし」と先延ばしにすると、以下のような状況が近い将来やってきます。

  • AI コーディングツールの進化についていけない: Claude Code や Gemini CLI のようなターミナルネイティブの AI ツールは、エディタの拡張として使うよりもターミナルで直接使うほうが機能をフルに活かせる。ターミナル操作に慣れていないと、最新ツールの恩恵を半分しか受けられません
  • リモートワークの選択肢が狭まる: SSH + tmux が使えれば iPad 1台でどこからでもフル開発ができる。エディタ依存だと、常にメインマシンが必要になる
  • 自動化の壁にぶつかる: CI/CD、cron ジョブ、AI エージェントの自動実行。これらはすべてターミナル環境で動く。ターミナルに不慣れだと、自動化の設計で毎回つまずく
  • 環境の再現性が低い: エディタの設定、拡張機能、テーマの同期は意外と面倒。tmux + dotfiles なら Git で管理するだけで、どのマシンでも同じ環境が一発で再現できる

2026年の開発は確実にターミナル回帰の流れが来ています。今のうちに少しずつ慣れておくことをおすすめします。

この記事を書いている理由

僕はエディタ不要論を唱えたいわけではありません。VS Code も Cursor も素晴らしいツールです。

ただ、「ターミナルだけでも開発できる」という選択肢を持っておく価値は間違いなくあります。

僕がこの環境に落ち着いたのは、Mac mini M4 Pro で AI エージェントを24時間稼働させる中で「SSH 越しに操作できないと困る」場面が増えたからです。サーバーに SSH して、tmux にアタッチして、Claude Code で作業する。この流れが自然になったとき、エディタの優先度が自然に下がりました。

もう1つの理由は、iPad でカフェから開発する体験があまりに快適だったこと。重いラップトップを持ち歩かなくても、SSH クライアントさえあれば Mac mini のフルパワーにアクセスできる。これは Ghostty + tmux + Claude Code の組み合わせだからこそ実現できるワークフローです。

「ターミナルは難しそう」と感じる人もいると思います。でも Ghostty はデフォルトのまま使えるし、tmux は基本操作を5つ覚えれば十分です。1週間試すだけで、開発体験がガラッと変わるはずです。

まとめ

Ghostty + tmux + Claude Code で構築するターミナル開発環境について、設定例と実際のワークフローを紹介しました。

押さえるべきポイント:

  1. Ghostty: GPU 描画 + macOS ネイティブ + 設定がシンプル。tmux との相性が抜群
  2. tmux: セッション = 案件単位で設計する。デタッチ/アタッチでデバイスを問わず作業継続
  3. Claude Code: ターミナル内でファイル操作・テスト・Git 操作が完結。CLAUDE.md でプロジェクトルールを定義
  4. 組み合わせの強み: SSH 越しのリモート開発、AI 自動実行、案件の瞬時切り替え
  5. エディタとは共存: 完全に捨てる必要はない。8:2 の比率でターミナルを主軸にする

noteでターミナル開発の体験談を公開中

この記事では設定とワークフローを中心に解説しましたが、実際にターミナル開発に移行してどう変わったかのリアルな体験談は note でも書いています。

noteアカウント(@mamamasu_3)はこちら


質問・相談はお気軽にDMでどうぞ

Ghostty や tmux の設定で困ったこと、Claude Code の使い方で詰まったことがあれば、X(@mamamasu_3)の DM でお気軽にご相談ください。


関連記事もあわせてどうぞ。