8月8日、Atomic Objectが「How I Rebuilt My Development Workstation for Agentic Work」と題した記事を公開した。複数のAIエージェントを並列で動かす「アジェンティックワーク」に最適化した開発環境を一から再構築した実践レポートだ。
「蓄積」から「設計」へ——8年分の環境をリセット
筆者は8年のエンジニアキャリアの中で、設計されることなく積み上がってきた開発環境を持っていた。プロジェクトのたびに増えるエイリアス、プラグイン、エディタ設定——気づけば、もう使っていないツールへの参照が設定ファイルに残り続けていた。
リセットの動機は単なる「掃除」ではない。開発スタイル自体が変わったからだ。以前の環境は「タスクに最適なツールを選び、1つに集中する」ことを前提としていた。新しい環境は「複数の並列スレッドを調整すること」を前提に組まれている。それぞれのスレッドでAIエージェントが動いている場合も多い。
※編集部の考察：Claude Code、Cursor、GitHub Copilot WorkspaceといったAIコーディングエージェントの実用化が進んだ結果、「エージェントに作業を投げて待つ」より「複数エージェントを同時並行で回してレビューする」スタイルが現実的な選択肢になりつつある。筆者の環境再構築はその流れを体現した事例といえる。
エージェントを複数のプロジェクトにまたがって管理するのはそれだけで認知コストが高い。そこに別々のアプリケーション、ウィンドウ、エディタ、チャットインターフェースが分散していると、オーバーヘッドはさらに増す。目指したのは、プロジェクト・ブランチ・シェル・エディタ・エージェント・レビューワークフローが一か所に収まる環境だ。
スタックの中核は **WezTerm、zsh、tmux、Neovim、Codex**。加えて ripgrep、fzf、LazyGit、RevDiff を多用する。
最も面白いアイデア：「ブランチ = ワークスペース」の自動化
この環境で最もユニークな発想が、Gitワークツリー・tmuxセッション・エージェントを1コマンドで束ねる仕組みだ。
複数エージェントを並列で動かすと、まずGitの問題が発生する。同一リポジトリの異なるブランチで複数の作業を同時進行させると、ブランチとディレクトリと端末の紐づけが崩壊する。筆者が採用したのは Git worktree（リポジトリを別途クローンすることなく、ブランチごとに独立した作業ディレクトリを持てる機能）だ。
project/
worktrees/
feature-one/
fix-something/
experiment/
さらに、ブランチからワークスペースを一気に起動するカスタムユーティリティを自作した。その構造はシンプルだ：
branch
└── Git worktree
└── tmux session
├── shell
└── agent
このわずかなオーケストレーションによって、「新しいワークスペースを作ること」がデフォルトになる。関係のない作業が同じブランチ・ディレクトリ・端末コンテキストを共有するインセンティブがなくなる。
tmux のセッションが「永続的で、名前で呼び出せて、コマンドラインから操作できる」という特性が、この仕組みの土台になっている。単に端末を分割できるというだけなら現代の端末エミュレータならどれでもできる。重要なのはセッションが自動化の部品として機能する点だ。
tmuxの設定：シンプルに保つ
tmuxの設定は意図的に最小限だ。プレフィックスキーをControl-Spaceに変更し、Vimライクなペイン操作を設定している：
unbind C-b
set -g prefix C-Space
bind | split-window -h -c "#{pane_current_path}"
bind - split-window -v -c "#{pane_current_path}"
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
bind w choose-tree -Zw
prefix + w でセッションとウィンドウのツリーが表示され、並列スレッド間の移動がここから行える。「どのウィンドウがどのブランチか」を頭で管理する必要がなくなる。設定がこれだけ簡潔なのは意図的であり、ツール固有の複雑さを抑えることで、ユーティリティ側のロジックに集中できるようにしている。
Gitレビューの役割分担
エージェントが生成したコードのレビューには、ツールを使い分けている：
- lazygit：リポジトリ全体の状態把握や、インタラクティブなGit操作に使う
- RevDiff：エージェントの成果物を一括レビューし、フィードバックをまとめて返すために使う。変更のたびにコメント→修正→再確認を繰り返す代わりに、差分全体を見てフィードバックを集約できる
- CLI git：それ以外の通常操作はこれ
「1つのGitインターフェースに全タスクを通す」のではなく、用途が明確な少数のツールを持つという方針だ。
※編集部注：元記事でRevDiffとして言及されているツールの詳細は原文を参照していただきたい。本文中では固有名詞として使用されているが、リンク先の特定には至らなかった。
NeovimとWezTerm
Neovim への移行について、筆者は「Vimとの完全互換があるため劇的な変化ではなかった」と述べている。主な利点はIDEの代替というより、tmuxセッション内でシェル・プロセス・エージェントと同じ空間にエディタが存在できることだ。GUIのIDEはどうしても「別のアプリケーション」として存在するため、エージェントや自動化スクリプトとの連携に断絶が生じやすい。Neovimはターミナル内で動作し、他のプロセスと同じインターフェースで操作できる点が、この設計思想と一致している。設定にはLuaを使い、Telescope（ファジー検索）、Oil（ファイル操作）、Treesitter（構文解析）、LSPクライアント等のプラグインを導入している。
ターミナルエミュレータの WezTerm については「まだ完全には納得していない」と正直に書いている。現状の設定はフォント・カラースキーム・パディングといった最低限のみ。Luaでスクリプトが書ける点を評価しているが、今のところ「邪魔をしない」役割に徹している。将来的にはWezTerm側のLuaスクリプティングを活用して、ワークスペース起動ユーティリティとの連携を深める可能性にも言及している。
設計思想：「調整コスト」を下げる環境
筆者がこの再構築から得た最大の気づきは、アジェンティックワークでの希少リソースは「実装を生み出すこと」ではなく「複数の実装を追跡・レビュー・管理すること」に移ったという点だ。
すべてのツールがコマンドラインインターフェースを持ち、通常のファイルとプロセスで動く。だから人間にもエージェントにも同じ操作が可能になる。GUIアプリケーションごとに別の自動化ストーリーを用意する必要がない。
この環境は「意図的に未完成」だとも述べている。WezTermを変えるかもしれない。Neovimの設定は確実に変化する。実際の作業負荷の中でどのパターンが有効かを見極めながら、カスタムユーティリティも増やしていく予定だという。
詳細はHow I Rebuilt My Development Workstation for Agentic Workを参照していただきたい。
