ターミナルだけで仕事が完結する時代が来ている
最近、業務時間の8割以上をターミナルで過ごしている。コード書き、調査、レビュー、コミュニケーション。ほぼ全部がターミナルで完結する。
数年前までVS Codeを常時開いていた自分が、気づけばターミナルのウィンドウしか並んでいない。この変化がどう起きたのか、何が便利で何が不便なのかを整理してみる。
ターミナル環境の土台
まず、素のターミナルだけでは仕事にならない。快適に作業するための基盤がいくつかある。
tmuxがウィンドウ管理の中核。ペインを分割して、左でコードを編集しながら右でビルドログを流す。セッションを維持できるので、SSH先での作業が切断されても続きから再開できる。
zsh + starshipでシェルをカスタマイズしている。Gitブランチ名、Kubernetesコンテキスト、GCPプロジェクトがプロンプトに常時表示される。今どの環境で作業しているかが一目でわかるのは、事故防止の面でも大きい。
fzfはファジーファインダー。ファイル検索、コマンド履歴検索、Gitブランチの切り替え、あらゆる場面で使う。Ctrl+R で履歴をインクリメンタルに絞り込めるだけで、作業速度が体感で2倍になる。
**ripgrep（rg）**はコード検索。grepより圧倒的に速く、.gitignore を自動で尊重してくれる。数万ファイルのリポジトリでも一瞬で結果が返ってくる。
ターミナルで完結する作業リスト
具体的に何をターミナルでやっているか。
コーディング。Claude Codeで対話しながら実装。エディタを開くこともあるけど、簡単な修正ならClaude Codeに指示して終わり。複雑なリファクタリングも、ファイルの読み書きから差分確認、テスト実行まで一連の流れがターミナル内で完結する。
コードレビュー。gh pr diff でPRの差分を見て、Claude Codeにレビューさせる。ブラウザでGitHubを開かなくても完結する。指摘事項のコメントも gh pr review で書ける。
調査。ログの確認は kubectl logs、設定の確認は gcloud コマンド。クラウドコンソールをブラウザで開くより、CLIの方が速い。特にGKEのPod状態確認やログのフィルタリングは、CLIの方が圧倒的に柔軟で、パイプでjqに繋げばJSONログの解析もその場でできる。
コミュニケーション。SlackもMCP連携でターミナルから読み書きできる。全メッセージをターミナルで処理するわけじゃないけど、問い合わせの調査と返信の下書きまではターミナルで済む。
黒い画面に白い文字
隣から見ると、一日中黒い画面に白い文字が流れているだけ。何をしているか全くわからないと思う。
でもこの黒い画面の中で、設計判断をして、コードを書いて、テストを走らせて、レビューして、デプロイしている。GUIより情報密度が高くて、マウス操作がない分速い。
IDEからターミナルに移行して変わったこと
VS Codeを手放したわけではない。今でも複雑なデバッグやノートブックの編集ではIDEを開く。ただ、日常の作業の大部分はターミナルに移った。
速くなった点。起動が速い。IDEは起動だけで数秒かかるし、拡張機能の読み込みでさらに待たされる。ターミナルは開いた瞬間から作業開始できる。ファイル間の移動もfzfで一発。複数リポジトリをtmuxのウィンドウで並べておけば、コンテキストスイッチも一瞬で済む。
不便になった点。型情報のホバー表示やリファクタリング支援はIDEの方が強い。大規模なリネームや定義ジャンプを多用する作業では、正直IDEの方が楽。あとは、差分の視覚的な比較もIDEのビルトインdiffビューアの方が見やすい場面がある。
結局のところ、ターミナルとIDEのどちらか一方に絞る必要はなくて、作業内容に応じて使い分けるのが現実的な着地点だった。
実際の作業フロー：朝の定型作業
ある日の朝の作業を具体的に書いてみる。
- ターミナルを開いてtmuxセッションをアタッチ
gh pr list --search "is:open review-requested:@me"でレビュー待ちのPRを確認gh pr diff <番号>で差分を読む。気になる箇所があればripgrepで関連コードを探す- Claude Codeにレビュー依頼を投げて、指摘事項を確認
gh pr reviewでApproveまたはコメント- 自分の作業ブランチに切り替えて、前日の続きを再開
kubectl get pods -n <namespace>でデプロイ状態を確認- Slackの未読を確認して、対応が必要なものに返信
ここまでブラウザを一度も開いていない。だいたい30分くらいで完了する。
ブラウザを開く瞬間
ターミナルで完結しない作業もある。
GUIが必要な確認。GrafanaダッシュボードやCloudflareのアナリティクスは、グラフで見た方が直感的。数値の確認はCLIでできるけど、トレンドの把握はビジュアルの方が強い。
ドキュメント作成。長文のドキュメントはNotionやConfluenceで書く方が楽。マークダウンで書いてターミナルからアップロードすることもあるけど、レイアウトの調整はGUIが必要。
会議。Google MeetやZoomはさすがにブラウザ。ここだけはCLIでは代替できない。
CLIツールの組み合わせ
ターミナルワークフローを支えているツール群。
gh — GitHub CLI。PR作成、レビュー、マージまで全部できる。gh pr create でPRを作り、gh pr checks でCIの状態を確認し、gh pr merge でマージする。一連の流れが全部コマンド。
kubectl + gcloud — Kubernetes とGCPの操作。インフラエンジニアの主力。kubectlにはkrew経由でプラグインを追加して、kubectl neat や kubectl ctx も使っている。
jq — JSONの整形とフィルタリング。APIレスポンスの確認に必須。kubectl get pods -o json | jq '.items[] | select(.status.phase != "Running")' のように、パイプで繋いで一行で複雑な抽出ができる。
fzf — ファジーファインダー。ファイル検索、履歴検索が爆速になる。
bat — catの代替。シンタックスハイライト付きでファイルを表示できる。行番号もデフォルトで出るので、コードの確認がしやすい。
eza — lsの代替。Gitステータスがファイル一覧に表示されるので、変更ファイルが一目でわかる。
効率化の本質
ターミナルが速いのは、操作がキーボードだけで完結するから。マウスに手を伸ばす時間、タブを切り替える時間、ページが読み込まれる時間。全部省略できる。
もうひとつ大きいのは、操作の再現性。コマンドは履歴に残るし、シェルスクリプトにまとめれば自動化できる。「先週やったあの手順」をhistoryから引っ張り出して再実行できるのは、GUIの操作では真似できない。
ただし、ターミナルに固執する必要はない。GUIの方が適している作業はGUIを使う。大事なのは「どのツールが最速か」を作業ごとに選ぶこと。
結果としてターミナルが多くなっているだけで、ターミナル原理主義ではない。
関連記事
他の記事
ブラウザ横スクロールアクションゲーム開発記｜TypeScript×Canvasで作るネオンランナー
HTML5 CanvasとTypeScriptで横スクロールアクションゲーム「ネオンランナー」を自作した。物理エンジン、衝突判定、操作性の工夫を解説する。
ブラウザで遊べるテトリス風パズルをTypeScriptで作った話
HTML5 CanvasとTypeScriptでテトリス風ブロックパズルを実装した。エンジンとUIを分離するSnapshotパターンや、ネオン演出のこだわりを解説する。
ゲーム実況のサムネイル作りで学んだデザインの基本
非デザイナーがゲーム配信のサムネイルを自作し続けて気づいた、視認性・配色・構図の基本ルール。試行錯誤の記録。
配信のコメント欄が動いた瞬間の話。ゼロからイチの体験
ゲーム配信でコメントがゼロの日々を超えて、初めてリアルタイムでコメントが来た瞬間の話。ゼロからイチの体験がモチベーションを変えた。