2026年5月29日の開発環境

最近、すごい速さでコロコロと開発環境が変わるので備忘のために残しておきます。

ちょっと前まで

今年の4月くらいまでは opencode を emacs 内で動かして開発することが多かったです。
opencode.el というパッケージがすごく便利で、
左側のバッファで編集、右のバッファで opencode.el を立ち上げて、エージェントと共同で開発するみたいなスタイルが多かったです。
結構間違えてくることも多かったので、そういう時は自分で直接編集したり、範囲選択した箇所を opencode.el に直接渡して編集を指示するみたいな流れが多かったです。

エディタからターミナルへ

でもエージェントやモデルの進化とともに、直接自分でコードを書く頻度が激減し、エージェントが主体でコードを書くことが増えてきました。
そうなってくると、エディタ上でエージェントを起動するというメリットが少なくなりました。
ターミナル上でデバッグ環境を立ち上げたり、テストをしたりといった操作をやりやすくする方が開発スピードの向上に寄与するようになりました。
合わせて、ターミナルエミュレータとして cmux を使いだしましたが、Plannotator を使ってブラウザ上でプランを見たり、コードレビューをしたりしますし、動作確認も cmux 上のブラウザで行うようになりました。
emacs は自分でコードを読みたいなと思った時だけ、terminal 上の pane から emacs -nw を起動するようにしています。

エージェント主体の開発フロー

ざっくりとした開発フローを記述します。
エージェントをベースとした割と普通の開発の流れなんじゃないかなと思っています。

  1. 計画
    実装に入る前に方針を文章化させて、判断材料が複数あれば opencode の機能で選択肢として並べてもらいます。
  2. 作業の環境を分ける
    チケットごとに独立した worktree ディレクトリを作成してもらって、並行作業や中断・再開がしやすい状態を保ちます。
  3. 小さくレビュー & コミット
    一気に書かせず、レビューを挟みながら進めます。自分がチェックする必要がある場合は plannotator review とかを使います。
  4. PR 作成
    PR 作成前に、サブエージェントによるレビューをした後、PR を作成します。PR の内容は .github/PULL_REQUEST_TEMPLATE.md を最初に参照させ、人間が読みやすいフォーマットで作成します。

Plannotator を使った開発フロー

Plannotator というツールを使ってエージェントの書いてきたプランやコードの変更をレビューしています。

エージェントがどんどん速く進めるようになってきて、出してくる計画や diff の量も増えました。
書く側のスピードが上がるほど、こちらのレビュー側の手間が相対的に膨らんできます。
少しでも簡単にレビューできる仕組みを入れたかったというのがあります。

ツールとしてはもしかしたら他にもあるかもしれないんですが、現状探した感じだと、Plannotator が良さそうといった感じです。（もしターミナル上だけで完結するものがあれば知りたいです。）

cmux 上でターミナルを開いて opencode を動かしておくと、エージェントの出力に合わせて、右側のペイン（ブラウザ）にそのまま Plannotator のレビュー画面が立ち上がるようにしています。
ターミナル → ブラウザ → ターミナルの往復をしなくてよくなり、レビュー → 修正指示 → 再レビューのループが速くなりました。

開発フローの中で、Plannotator が入る場面はだいたい 2 つあります。

1. 計画レビュー

エージェントが計画を出してきたら、まず Plannotator で開きます。

  • ブラウザで計画書を行単位に読み下せます
  • 「ここは別案で行ってほしい」「この前提は違う」みたいなコメントを差し込めます
  • 却下した理由はそのままエージェントに戻り、計画を直してもらえます

ターミナルのままプランの本文を読んでコピペして指示するより、効率が上がった気がします。

2. コードレビュー

まだ brown field の開発をやっている時は自分がコードベースを理解する必要があるので、その場合はコードレビューが必要だと思っています。

実装が終わったら plannotator review で worktree（または PR URL）を開きます。

  • diff をファイル単位・hunk 単位で確認できます
  • 気になった箇所にコメントを付けられます
  • セッションに戻すと、エージェントが該当箇所を修正してくれます

GitHub のレビュー UI と近い感覚で、ローカルの worktree に対してレビューできるのが大きいです。

これから

と書いたんですが、まぁこれはあくまで今の状態の開発のフローの話です。
人間が開発のボトルネックになっている事は明白なので、これからモデルの進化とともに、人間がレビューする頻度がより少なくなってくるでしょう。
単に 1 コントリビューターとして、減らせる部分はだいぶ減ったと思うので、これからは開発からリリースのライフサイクルすべてで、人間が関わる部分は減っていくんだろうなと思います。

まとめ

  • 3ヶ月前までは opencode.el on emacs で、エディタの中にエージェントを置いていました。
  • 今はエージェントが主体でコードを書くので、エディタの外（ターミナル）に開発の中心が移りました。
  • cmux + opencode + Plannotator の 3 点でターミナルとブラウザを行き来する形に落ち着いています。
  • 自分が判断しているのは、計画・小さなレビュー・PR 内容の確認くらいで、残りはエージェントに任せています。
  • この役割分担は今後さらにエージェント側に寄っていくはずで、今の構成もいつまで通用するかはわかりません。