LayerX Tech Advent Calendar 2025 記念すべき1日目の記事です。めでたいですね。初日は @frkake さんの「OCR技術の変遷と日本語対応モデルの性能検証」との二本立てです。
バクラク事業部 スタッフエンジニアの @izumin5210 です。
Platform Engineering 部 Enabling チームでいろいろなことをしています。
最近は AI Agent 基盤開発系の話ばっかりしてたので、今日は AI じゃなくて Vim の話をします。
開発環境のカスタマイズ、楽しいですね？ 楽しくなっちゃっていろいろ入れちゃいがちです。 が、自分は最近「余計な思考を減らし、コードに集中するための環境」というコンセプトで開発環境を構築しています。 特に AI の登場によりコードの読み書きの量が増えている現在、コードの読み書きにかかるオーバーヘッドを減らし、コードに集中することの重要性は高まっているのではないでしょうか。 「余計な思考を減らし」は「ルールを決めて考えることを減らす」かもしれないし、「視覚的なノイズを減らし重要なところにアテンションを向ける」かもしれない。 この記事では「余計な思考を減らし、コードに集中する」ために自分がどのような tmux や Neovim の使い方をしているかを紹介します。
いろいろ言ったけど、要するに自分の tmux と Neovim をちょっと見せびらかしたいだけです。
ghq: ディレクトリ配置を迷わない
PC 上のディレクトリ配置や探索に迷いたくないため、とりあえずなんでも Git リポジトリにして ghq で管理しています。
バージョン管理のモチベーションが弱い書き捨てのコードもとりあえず雑なリポジトリにつっこんで雑にコミットしています。 雑コミットでよければそこまで脳のリソースを使わないのでオーバーヘッドは個人的には許容範囲です。 あとはそういう雑リポジトリを配置できる sandbox organization を GitHub 上に作っています。
ghq 管理下のプロジェクトは ghq list で一覧できるので、これを fzf などの fuzzy finder に食わせることで高速に移動できるようにしています。
tmux session は ghq で管理するディレクトリに対応させる
自分はターミナル上で複数のセッションを開くために tmux を利用しています。 Terminal Emulator に Ghossty を使うようになって tmux をやめた… という話もよく聞きますが、自分は Ghostty 上で tmux を利用し続けています。
ここまで tmux に固執しているのは tmux の session - window - pane の3層構造に依存した開発ワークフローになっているためです。
- session: プロジェクト, Git リポジトリ
- window: タブのように、プロジェクト内で別作業をするための別画面
- pane: タブ（window）内の画面分割
1プロジェクト（Gitリポジトリ）内でもタブを分けたい, プロジェクトごとでもタブを分けたい, でも macOS 上の window は増やしたくない…。 それを実現するために tmux を使い続けています。
このワークフローを快適に使うために「ghq list と fzf でリポジトリを絞り込んで tmux session を作るあるいはアタッチ」をする簡易なコマンドを作っています。
ここまでやることで、前述の ghq 利用と合わせて以下2つを運用の原則としています。
- 「とりあえず Git リポジトリにする」
- 「とりあえず Git リポジトリを tmux session に対応させる」
これら2つを前提とすることで、プロジェクト管理やターミナル上のセッション管理について何も考えなくていいような縛りとしています。
git worktree は ghq に認識させるように作る
Coding Agent の普及で git worktree を利用するようになりましたが、これも前述の tmux 運用に乗せるため worktree は兄弟ディレクトリ（= ghq 管理下）に置いています。 ghq list でリストアップされ、 worktree が単独の tmux session を持っています。
tmux, Neovim の UI は目立たせない
Neovim はコードの読み書きに利用しています。 なるべくコードに集中したいので、コード以外にアテンションを取られず、かつコードの表示面積を広く取れるようにするため、 tmux や Neovim の UI はなるべく減らす・目立たせないような工夫をしています。
Neovim の statusline は出さない
出していません。以前は lualine.nvim などを利用していましたが、常に1行以上消費されるのがもったいなく感じたのと、目立つ割に意外と見てないことに気づき、思い切って statusline ごと非表示にしています。 statusline にあった情報は後に紹介するように tmux statusline, incline.nvim, modes.nvim などに分散させています。
リポジトリ情報は tmux の statusline にミニマルに出す
現在のリポジトリや branch の情報などは tmux 側の statusline に出しています。前述のとおり「ファイル編集はいずれかのリポジトリ上で行う」「tmux session はいずれかのリポジトリに紐づく」というケースがほとんどなため、リポジトリに紐づく情報は tmux 側にまとめて表示できるような設計としています。
incline.nvim: カレントファイルの情報は小さな floating statusline に出す
現在開いてるファイルが何か、そのファイルでエラーが起きてないか等はさすがに画面に出ていて欲しいので、incline.nvim を使って右下に floating で情報を出しています。
ファイル名以外にもファイル種別を表すアイコンや、ファイルの状態を多少わかりやすくなるように表示させています。
- 未保存のファイルにはオレンジの丸を表示
- LSP の Diagnostics や何らかのエラー・警告がある場合は文字色変更 + アイコンでアピール
- inactive なときは存在感を弱める
- 一般的すぎるファイル名の場合は親ディレクトリも表示
modes.nvim: モードの情報は現在行ハイライトの色で表す
現在のモードも Vim の statusline に出すケースが多いと思いますが、これは modes.nvim を利用し現在行の背景色で表すようにしています。
modes.nvim はモードごとの色と opacity を指定できるため、適用している colorscheme のパレットから色を選び違和感のない（アテンションを取られない）配色をしています。
winbar は出さず、ファイル切り替えは Snacks.nvim の picker に任せる
winbar は開いているバッファの一覧や切り替えに便利ですが、これは使っていません。 UI を減らしたいから。
開くファイルを変更したいときは基本的に Snacks.nvim の picker を使っています。
以下のような関数を定義して <space><space> に割り当て、とりあえずこれ呼び出しておけばいいようにしています。
ファイルサーチが高度化し補完なども LSP や Copilot が主になったことでアクティブでないバッファを保持し続けるモチベーションも下がっているため、非アクティブなバッファを自動で閉じるプラグインを入れています。（Vim を使いこなせてない感もありますが…）
noice.nvim: cmdheight=0 でさらにノイズを減らし編集領域を稼ぐ
statusline を消すと画面下部に残るのは cmdline です。 これも必要なのはコマンド入力時や通知がある時だけなので、常に1行取られるのはちょっともったいなく感じてしまいました。 cmdline は cmdheight = 0 とすることで非表示にできます。
これで編集領域が pane の下限いっぱいまで広がります。
代わりに noice.nvim を導入し、cmdline や messages を floating window に逃がしています。 エラーや警告などのメッセージが cmdline よりも目立つかたちで、かつその severity が色で判別できるように出てくるので視認性も向上した気がします。
Vimade: 編集中のバッファ以外の存在感を減らす
普段の作業環境はディスプレイが大きく複数のファイルを同時に開くことがあります。 このとき「いま自分が特に関心のあるファイルはどれか」を視覚的にわかりやすくするため、Vimadeアクティブなバッファ以外の文字色を薄くしています。
Vimade も fadelevel と basebg を指定することで colorscheme に合わせた違和感の少ない配色を設定できます。
overlook.nvim: ファイルジャンプを視覚的にもスタックで表現
脳のワーキングメモリがあまり大きくないと、LSP 等でのコードジャンプで飛んでるうちにコンテキストを見失うことがあるかもしれません。自分はあります。
そういうときに便利なのが overlook.nvim で、コードジャンプの結果が floating window で表示されるようになります。
これならジャンプ元ファイルや経路が見えてる状態なので、飛んでるうちはコンテキストが視覚的に維持されます。ここから飛んだ先のファイルを編集したいときはそのまま編集もできますし、元の window や split で開くこともできます。 自分は <CR> で元のウィンドウで開く, <C-CR> で split して開くような設定を入れています。
Sidekick.nvm: AI とのおしゃべりも Vim 上で済ませる
自分は Claude Code など Terminal 上で動作する Coding Agent を使うことが多いです。 毎回 Neovim を ctrl+z でバックグラウンド送りにしてもいいんですが、コードを見ながら AI と会話したり、コードを AI に送りつけたりしたいケースはよくあるため Sidekick.nvim を利用して Neovim 上で Claude Code 等を開くように設定しています。
Sidekick.nvim は Terminal-mode で開きますが、ここから Normal-mode への移動をデフォルトの <c-\><c-n> でやるのは面倒なため、 better-escape.nvim を使い jk の高速入力でNormal-mode まで戻れるようにしています。
なお、Sidekick.nvim に標準搭載されている tmux インテグレーションは無効化しています。 worktree と tmux を使って Coding Agent にフィットするセッション管理は自分でやっているため。
Snacks.nvim lazygit: Git 操作, diff 確認を Neovim からシームレスに
Coding Agent により Git の status や diff の確認の重要性は急激に高まっているのではないでしょうか。 これをなるべく快適に・シームレスに行うために Snacks.nvim の lazygit インテグレーションを使い floating window で Git 操作ができるようにしてあります。
また、lazygit 上でのファイルの詳細確認を快適にするために、元の Neovim でファイルを開けるような設定を仕込んでいます
おわりに
「余計な思考を減らし、コードに集中する」ために、ルールを定め、視覚的ノイズを減らしてアテンションを誘導し、なるべく tmux, Neovim を中心に生活できるようにした自分の開発環境を紹介しました。 でもそれっぽい理屈をいろいろこねましたが、自分が気持ちよく開発できればそれでいいんだと思います。 このあと大そうじ・年末年始の季節ですので、この機会に開発環境を見直してみるのはいかがでしょうか。
Discussion