開発環境2026

日本語

Poem

私はNeovimの中で生活している。

朝起きてターミナルを開き、Neovimを起動し、コードを書き、ドキュメントを読み、AIと対話し、gitを操作し、そして夜になってNeovimを閉じる。この生活がもう何年続いているだろうか。正確には覚えていない。覚えていないということは、もうそれが当たり前になっているということだ。

2026年1月。世間では生成AIを活用した開発が当たり前になり、「AIがコードを書く時代にプログラマーは不要になる」と言われ始めてからもう数年が経った。結論から言うと、プログラマーは不要になっていない。AIと対話しながらコードを書く時間が増えただけである。

この記事では、そんな2026年の私の開発環境を晒しておく。1年後に見返したら「あの頃はこんな環境だったのか」と懐かしむことができるかもしれない。あるいは「1年経っても何も変わってないじゃないか」と呆れるかもしれない。どちらでも構わない。

OS: Linux Mint 22.2

WSL2との別れ

かつて私はWindowsユーザーだった。

開発にはWSL2（Windows Subsystem for Linux 2）を使っていた。WSL2は素晴らしい技術だ。Windowsの上でLinuxを動かせる。GUIアプリも動く。Dockerも動く。理論上は最強の環境である。

理論上は。

現実には、WSL2を起動するとCPU使用率が謎に跳ね上がる問題に悩まされていた。何もしていないのにファンが回り始める。ターミナルを開いているだけでCPUが20%ほど消費される。これを業界では「WSL2ファン回転症候群」と呼ぶ（呼ばない）。

最初は「まあ、仮想環境だし多少は仕方ない」と思っていた。しかし、真夏に冷房をつけていない部屋でファンがフル回転し始めると、さすがに考え直す。「俺は今、何のためにPCを動かしているんだ？」と。コードを書くためか？ファンを回すためか？

ネイティブLinuxなら、この問題は存在しない。ファンは必要なときにだけ回る。当たり前のことが、当たり前に起こる。それだけで幸せになれることを、私は知ってしまった。

なぜLinux Mintなのか

Linuxディストリビューションは無数にある。私は複数のノートPCを持っており、それぞれに異なるディストリビューションを入れて遊んでいる。Arch Linux（Manjaro）、Fedora、そしてもちろんWindows。しかし、メインマシンにはLinux Mintを選んだ。

理由は単純で、Debian系のディストリビューションをWSL2以外で使ったことがなかったからだ。Arch系もRed Hat系も経験した。残るはDebian系。その中で安定リリースに定評のあるLinux Mintを選んだ。

「安定リリースに定評がある」と書いたが、正直に言うと、決め手は別にあった。

Steamである。

そう、ゲームである。Steamのゲームが、Linux Mintで安定して動いたのだ。

「開発環境の記事でゲームの話をするな」という声が聞こえてくる気がする。ごもっともである。しかし、人間は仕事だけで生きているわけではない。仕事の合間にゲームをしたいこともある。そのたびにWindowsに切り替えるのは面倒だ。

ProtonとSteam Playの進化により、Windowsゲームの多くがLinux上で動くようになった。Linux Mintでは特に安定していた。これが決め手になった。技術的な理由ではなく、生活の質を上げるための選択である。開発環境とは、仕事をする場所であると同時に、生活する場所でもあるのだ。

あと、Macは高い。M1チップ以降のMacは確かに素晴らしいが、同じ予算でLinuxマシンを組めば、もっとスペックの高いマシンが手に入る。そして私はWindowsのUIに慣れているので、macOSの「閉じるボタンが左にある」UIにいつまで経っても馴染めなかった。これも正直な理由として書いておく。

ターミナル: Wezterm

ターミナルエミュレータはWeztermを使っている。

選んだ理由は4つある。

Rust製である
GPUアクセラレーションに対応している
Luaで設定できる
クロスプラットフォームである

1つずつ説明しよう。

Rust製である

Rust製のソフトウェアには信頼を置いている。メモリ安全性が保証されているというのもあるが、それ以上に「Rustで書き直そう」と思う開発者は、往々にしてソフトウェアの品質に対する意識が高い。これは偏見かもしれない。しかし、経験則として、Rust製のCLIツールは動作が速く、クラッシュしにくい傾向がある。

ターミナルエミュレータは毎日何時間も使うソフトウェアだ。その品質に妥協したくない。

GPUアクセラレーションに対応している

「ターミナルにGPUアクセラレーションが必要か？」という疑問を持つ人がいるかもしれない。

必要だ。

大量のログを流したとき、巨大なファイルをcatしたとき、ターミナルの描画がカクつくのはストレスになる。WeztermはGPUを使って描画を行うため、どれだけ大量のテキストを流してもぬるぬる動く。一度この快適さを知ってしまうと、もう戻れない。

これを「ターミナルGPU信者」と呼ぶ人もいるだろう（いない）。私は信者で構わない。

Luaで設定できる

これが実は一番大きな理由かもしれない。

私のエディタはNeovimであり、NeovimはLuaで設定する。つまり、エディタとターミナルの設定を同じ言語で書ける。設定ファイルを行き来するときに頭を切り替える必要がない。.wezterm.luaとinit.luaを同じ感覚で編集できる。

これは些細なことに思えるかもしれないが、毎日の作業の積み重ねでは大きな違いになる。

クロスプラットフォームである

前述の通り、私は複数のマシンを使っている。Linux、Windows、そしてたまにMac。Weztermはすべてのプラットフォームで動く。設定ファイルをdotfilesリポジトリで管理しておけば、どのマシンでも同じ環境が再現できる。

他のターミナルを試した結果

Wezterm以外のモダンなターミナルエミュレータも試した。特にGhosttyは気になっていた。Zig製で高速、ネイティブUIを採用しており、評判も良い。

しかし、Debian系はコミュニティ版の配布となっている。出来れば公式配布が安心だ。

また、Ghosttyは現時点でmacOSとLinuxのみ対応しており、Windowsはまだ開発中だ。複数のOSを行き来する私にとって、クロスプラットフォーム対応は譲れない条件だった。

というわけで、Weztermに落ち着いている。

エディタ: Neovim

本題である。私が「中で生活している」と言ったNeovimについて語ろう。

なぜNeovimなのか

「2026年にもなってVim系エディタを使っているのか」と言われることがある。VS CodeやJetBrains IDEのほうが機能が豊富ではないか、と。

その通りである。VS Codeは素晴らしいエディタだ。拡張機能が豊富で、設定も簡単で、多くの開発者に愛されている。JetBrains IDEは言語ごとに最適化されており、リファクタリング機能は圧倒的だ。

しかし、私はNeovimを選んだ。理由は「自分だけの環境を作りたかった」からだ。

Neovimは、デフォルトの状態ではほとんど何もできない。シンタックスハイライトすらまともに動かない。そこから、自分で必要な機能を足していく。プラグインを選び、キーマップを設定し、見た目を調整する。この過程が楽しい。

「エディタの設定に時間をかけるより、コードを書く時間に使ったほうがいいのでは？」という意見もある。ごもっともである。しかし、エディタの設定を「趣味」と割り切れば、何の問題もない。私にとってNeovimの設定は、盆栽を育てるようなものだ。少しずつ手を入れ、理想の形に近づけていく。終わりはない。

dotfilesという沼

私のNeovim設定はdotfilesリポジトリで公開している。

ディレクトリ構成はこんな感じだ：

nvim/
├── init.lua
├── lazy-lock.json
├── after/
│   └── lsp/
│       ├── rust_analyzer.lua
│       ├── ts_ls.lua
│       └── ...
└── lua/
    ├── plugins/
    │   ├── sakurajima.lua
    │   ├── blink-cmp.lua
    │   ├── snacks.lua
    │   └── ...
    └── daiki/
        ├── lazy.lua
        └── lsp.lua

プラグインマネージャーはlazy.nvimを使っている。補完エンジンはblink.cmp、ファイルピッカーはsnacks.nvim。どれも比較的新しいプラグインだ。Neovimのエコシステムは進化が速い。去年まで定番だったプラグインが、今年には新しいプラグインに置き換わっていることも珍しくない。

私は常に最新を追いかけるタイプだ。「安定を求めるならプラグインを固定しろ」という意見もあるが、新しいプラグインを試すのが楽しいのだから仕方がない。

キーマップの哲学

私のNeovim設定で一番こだわっているのは、キーマップの統一性だ。

すべてのアクションは;（セミコロン）をプレフィックスとして始まる：

;se - ファイルエクスプローラーを開く
;sf - ファイルを検索する
;gr - grep検索
;gs - Git状態を確認
;ih - InlayHintsをトグル

なぜ;なのか。Vimにおいて;は「直前のf/t検索を繰り返す」キーに割り当てられている。しかし、私はこの機能をほとんど使わない。使わないキーを潰して、自分用のプレフィックスキーにした。

この統一性により、「あの機能のキーマップは何だっけ？」と悩むことがなくなった。とりあえず;を押せば、which-keyが候補を表示してくれる。

sakurajima.nvim

私は自作のカラーテーマ「sakurajima.nvim」を使っている。

名前の由来は、鹿児島県の桜島。活火山である。黒い火山灰と、赤いマグマ。そのイメージをカラーテーマに落とし込んだ。

背景は黒に近いダークグレー（#22272e）。テキストは灰色がかった白（#8b9aaa）。アクセントカラーにはオレンジ（#E38D2C）やシアン（#2BB6BA）を使っている。

このテーマを作ったのは2024年。そして2年間、毎日このテーマを使い続けた。「いつか直そう」と思っている箇所がいくつもあった。2年間ずっと思っていた。

そして2026年1月、ついに重い腰を上げて大改修を行った。2年分の不満を一気に解消した話は、別の記事「Neovimのカラーテーマ「sakurajima.nvim」を作成して学んだこと」に書いたので、興味があればそちらも読んでほしい。

Rust第一主義

私の主要な開発言語はRustだ。したがって、Neovimの設定もRust開発に最適化している。

rust-analyzerとの連携にはrustaceanvimを使っている。このプラグインは、単なるLSP設定以上のことをしてくれる：

マクロ展開の表示（;rm）
テストの実行（;rr）
親モジュールへのジャンプ（;rp）
Clippyによるチェック

Cargo.tomlの依存関係管理にはcrates.nvimを使っている。依存クレートのバージョン確認と更新がエディタ内で完結する。

「RustのためにNeovimを使っている」のか、「Neovimを使うためにRustを書いている」のか。もはやどちらが先かわからない。

生成AI: Claude Code

さて、2026年の開発環境を語る上で避けて通れないのが生成AIだ。

私はClaude Codeを使っている。これが私にとって初めての「開発に本格的に使う生成AIツール」だ。

なぜClaude Codeなのか

GitHub Copilotは使ったことがない。Cursorも使ったことがない。ChatGPTをコード生成に使ったこともほとんどない。

なぜか。

ターミナルで完結しないからだ。

私はNeovimの中で生活している。ブラウザを開いてChatGPTにアクセスするのは、Neovimの外に出ることを意味する。VS CodeにCopilotを入れるなら、そもそもVS Codeを使わなければならない。Cursorに至っては、専用のエディタを使う必要がある。

「OpenAIにもCodex CLIがあるじゃないか」という声が聞こえてくる気がする。確かに、2025年4月頃にOpenAIはターミナルで動くコーディングエージェント「Codex CLI」をリリースした。Rust製で、Claude Codeと同じくターミナルで完結する。

しかし、私がClaude Codeを使い始めたのはCodex CLIのリリース前だった。そして、一度慣れた環境を変えるのは面倒だ。Claude Codeで特に不満がないので、乗り換える理由がない。これを「先行者利益」と呼ぶ（呼ばない）。

Claude Codeは違う。ターミナルで動く。つまり、Neovimの中から:terminalで起動できる。

:terminal claude --permission-mode plan

このコマンドを打つだけで、AIとの対話セッションが始まる。Neovimの画面を分割して、左側にコード、右側にClaude Code。コードを書きながらAIに相談し、AIの提案を見ながらコードを修正する。この作業がすべてNeovimの中で完結する。

これが最高である。

Plan Modeという発明

Claude Codeには--permission-mode planというオプションがある。このモードでは、AIはファイルの編集を行わない。コードの調査と提案のみを行う。

私はこのモードを愛用している。

なぜなら、 AIにコードを勝手に書かれたくない からだ。

AIが生成したコードをそのまま使うのは危険だ。バグが含まれているかもしれない。自分のコーディングスタイルと合わないかもしれない。そもそも、何をやっているのか理解しないままコードを使うのは、技術的負債を積み上げる行為である。

Plan Modeでは、AIは「こういう方針で実装するのはどうですか」と提案してくれる。私はそれを読み、理解し、自分でコードを書く。AIは先生であり、私が生徒だ。先生が黒板に書いた内容をそのまま写すのではなく、理解した上で自分のノートにまとめる。そういう使い方をしている。

生成AI時代の開発スタイル

「AIがコードを書く時代にプログラマーは不要になる」という予測は、今のところ外れている。

確かに、AIは驚くほど賢い。複雑なアルゴリズムを実装させれば、数秒で動くコードを生成してくれる。しかし、「何を作るか」を決めるのは人間だ。「このコードで本当にいいのか」を判断するのも人間だ。AIは道具であり、道具を使う人間がいなければ、道具は何も生み出さない。

2026年の開発は、「AIと対話しながらコードを書く」というスタイルになった。AIに質問し、AIの回答を読み、自分で考え、コードを書く。このサイクルを繰り返す。AIがいなかった時代と比べて、確かに開発は速くなった。しかし、プログラマーの仕事がなくなったわけではない。むしろ、AIを上手く使える人と使えない人の差が広がっている気がする。

私はClaude Codeのおかげで、開発が楽しくなった。一人で悩んでいた問題を、AIに相談できる。「この設計、どう思う？」と聞けば、AIは真面目に答えてくれる。深夜3時に壁打ち相手になってくれるAIは、ありがたい存在だ。

ブラウザ: Chrome

ブラウザはChromeを使っている。

特にこだわりはない。

Webアプリケーションを開発しているため、ユーザーのデファクト環境で動作確認ができることが重要だ。世界で最も使われているブラウザはChromeなので、Chromeで動作確認をする。それだけの理由である。

開発者ツールは便利だ。それ以上でも以下でもない。

まとめ

2026年1月時点の私の開発環境を振り返ってみた。

OS: Linux Mint 22.2（WSL2から卒業、Steamが決め手）
ターミナル: Wezterm（Rust製、GPU、Lua、クロスプラットフォーム）
エディタ: Neovim（sakurajima.nvim、;プレフィックス、Rust第一）
生成AI: Claude Code（ターミナルで完結、Plan Mode）
ブラウザ: Chrome（特にこだわりなし）

振り返って気づいたことがある。私の開発環境は、 「ターミナルの中で完結させたい」 という欲求に貫かれている。

OSはLinuxを選び、ターミナルはWeztermを選び、エディタはNeovimを選び、AIはClaude Codeを選んだ。すべて「ターミナルで使える」という基準で選んでいる。ブラウザだけは例外だが、それはWebアプリの動作確認という避けられない理由があるからだ。

2026年の開発環境は、 「エディタ + AI」 が中心になっている。エディタでコードを書き、AIに相談し、またコードを書く。このサイクルが日常になった。

1年後、この記事を読み返したとき、私はどんな環境を使っているだろうか。Neovimはまだ使っているだろうか。Claude Codeはまだ存在しているだろうか。Linux Mintは22.3になっているだろうか。

わからない。わからないからこそ、記録を残しておく。