開発環境の話は、たいてい道具の一覧になりがちだ。エディタ、ターミナル、パッケージマネージャ、AI のモデル。数え上げれば立派に見えるが、日々の作業が回るかどうかは、道具の数より「誰が何をして、どの順で検査するか」で決まる。いまの環境は、その二点に絞って組み直したものだ。増やしたものより、減らしたもののほうが多い。

入口はひとつ、役割は三つ

作業の入口は Paseo に集約している。そこで起動したエージェントに、役割を分けて仕事を渡す。

  • 実装・調査・修正: 日常の作業はほぼこれ。DeepSeek V4.1 Flash を thinking high で使う
  • 設計・議論: 構成や方針を決めるときだけ、別のモデルに相談する
  • レビュー: 独立した Codex を読み取り専用で走らせる

大事なのはモデル名ではなく権限のほうだ。レビュアーは読み取り専用で、ファイルを書き換えず、commit も push もしない。修正は必ず実装側が行う。レビュアーに書き込み権限を渡すと、指摘と修正が同じ手の中で完結して、独立した目という前提が崩れる。

自分用の運用ルールでは、その役割表にモデル名を書かないことにしている。書いた瞬間に更新漏れが起きるし、モデルは数か月で入れ替わる。実際のモデルと thinking の設定は Paseo のプロファイル側に置き、ルールには役割と権限と、渡す指示の形だけを残す。そうしておけば、中身が変わっても運用は壊れない。

機械で分かる問題は、レビューの前に落とす

レビューに渡す前に、機械的に判定できるものは通す。順序は format、lint、typecheck、unit test、build。

前の段が落ちたら後ろには進まない。型で分かる問題をテストで探し直すのは無駄だし、壊れたものをレビューに読ませても、指摘の質は上がらない。長いログや生成物まで渡すとコストが増えるだけで、重大な問題への注意も薄まる。

format、lint、typecheck、unit test、build で判定できる問題を Codex へ読ませる必要はありません。

これは 11 月 11 日に自分で言葉にした方針で、いまはその通りに動いている。このサイトのリポジトリでいえば、format・lint・typecheck は未定義なので「なし」と記録する。unit test は node --test scripts/、build は astro build。無い段階を空欄にせず「なし」と書くのは、通ったのか、やっていないのかを後から区別するためだ。

検査を緩めて通すことはしない。lint のルールを切る、テストを削る、型エラーを抑える。どれも一瞬で緑になるが、緑の意味が消える。落ちたまま進むのは、失敗を承知で判断したときだけにしている。

レビューは往復で、指摘は評価してから

レビュアーはこちらの会話を知らない。だから依頼には、作業ディレクトリ、対象の差分、実装の意図、実行済みの検査とその結果を毎回すべて書く。文脈を渡さないレビューは、一般論の寄せ集めになりやすい。

返ってきた指摘は、そのまま全部は採用しない。採用するもの、しないものを一つずつ決めて、しない理由を残す。独立したレビュアーの指摘にも、設計意図を知らないがゆえの誤読は混ざる。

blocker と major が消えるまで、同じセッションに修正版を渡して再レビューする。3 ラウンドを超えたら、反復を続けずに相談する。往復は品質のためであって、無限に回すためのものではない。

待ち方も決めている。レビューは投げたら完了の通知を待つ。状態を何度も問い合わせない。ポーリングは、待っている間に別の作業を進めた気にさせるだけで、実際には何も速くしない。

増やさずに減らした

ここ数か月で、候補に挙がったものをいくつか落とした。

  • 複数のモデルによる合議は、使えないと判断して閉じた
  • 高難度実装用の上位モデル追加は見送った
  • 長時間タスク向けの別ハーネスへの移行は、そもそも必要になるほど複雑な実装をしていないので見送った
  • Bun への移行は、開発環境と本番でランタイムが食い違うメンテコストを考えて見送った

共通しているのは、極端に複雑な実装が日常にないという認識だ。足りないのは実装力ではなく、往復の回数と精度だった。実装とレビューを一往復させるほうが、モデルを一つ増やすより効く。

地味な土台

派手さはないが、土台は次の構成で動いている。nvm-windows で Node 26、パッケージは pnpm 12、サイトは Astro 7 でビルドし、Cloudflare Pages へ GitHub Actions から配信する。開発サーバはバックグラウンドで起動して、停止・状態・ログをコマンドで扱う。

記事の公開も同じ考え方で経路を一つにした。Markdown を書いて PR を出し、プレビューを確認してマージする。マージされたものだけが公開される。下書きフラグは持たない。状態は「ブランチ上」と「main 上」の二つで足りる。

速くはない。ただ、どこで何をするかが決まっていれば、道具を入れ替えても戻ってこられる。いまの自分には、そのほうが強い環境だと思っている。