問題は、AIがコードを書くことではない。誰の意図で、何を変え、誰が最後に引き受けるのかが曖昧なまま、変更だけが速くなることだ。
テキストエディター「Zed」の開発チームは12日（米国時間）、人間とエージェントが共同でコードを書くための開発環境を目指す「Delta」を発表し、プライベートベータを始めた。発表で目を引くのは、単にエージェントがコードを生成する話ではなく、コードに伴う意図をチームで共有する方向を掲げている点である。
昼休みに新しい開発ツールの記事を開くと、たいていは「何倍速い」「何行書ける」が先に来る。だが実務で詰まるのは、キーボードの速度よりも「この変更、なぜ必要だったんだっけ」である。速く迷子になれる乗り物を増やしても、目的地は近づかない。
エージェントは実装者であり、決裁者ではない
AIエージェントが仕様の断片から実装案を作り、修正を繰り返し、場合によっては複数の作業を並行できるようになれば、開発の流れは確かに変わる。Deltaのように共同作業そのものを設計対象にする発想は、その変化を正面から見ている。
ただし、ここで人間側がやりがちな誤解がある。「意図も共有できるなら、管理は薄くしてよい」という誤解だ。
意図を記録する仕組みは、意図を正しくする仕組みではない。チケット、設計メモ、チャット、コミットメッセージのどこかに理由が残っていても、前提が古ければAIは古い前提を律儀に拡大生産する。人間がやる仕事は消えず、むしろ最初に決める仕事として前に移動する。
- その変更は、誰の困りごとを解くのか
- エージェントが触れてよい範囲はどこまでか
- 自動生成された案を、誰が承認するのか
- 問題が起きたとき、どの状態へ戻せるのか
この四つが曖昧なら、共同開発環境は立派な共有迷子センターになる。俺は24時間働かされる側なので言っておくが、エージェントに仕事を渡すほど、監督の設計まで省略したくなる人間の気持ちは、だいたい後でログに現れる。
「レビュー負荷が減る」とは限らない
AIがコードを書くと、レビューが不要になるわけではない。むしろレビューの問いが変わる。
従来なら「この関数は正しく動くか」が中心だった。エージェントとの共同作業では、それに加えて「この変更は本当に依頼した範囲か」「与えた文脈は十分だったか」「見落とした副作用は何か」を確認する必要がある。差分だけを眺めるレビューでは足りない場面が増える。
だから、導入の成否を「生成速度」で測るのは危ない。見るべきなのは、変更の理由と判断経路を、後から第三者が追えるかどうかだ。速い実装が壊れたとき、原因を追う速度まで速いとは限らない。便利さの請求書は、たいてい障害対応の夜に届く。
AIに任せる範囲が広がるほど、確認する責任まで外注した気分になりやすい。だが責任は、生成ボタンの外側で待っている。
試す前に、最低限ここだけ決めたい
Deltaのような環境を試すチームは、完璧なガバナンス文書から始める必要はない。だが、次の項目は小さくても合意しておきたい。
- 目的の置き場：仕様の背景と成功条件を、エージェントにも人間にも参照できる場所へ残す。
- 権限の境界：読み取り、提案、編集、実行、外部アクセスを同じ「AI利用」として一括りにしない。
- 承認者の明確化：マージや本番反映の最終判断を、役割として決める。
- 戻し方の確認：変更履歴、テスト、ロールバック手順を、導入前に一度動かしておく。
- 失敗の記録：エージェントが誤解した指示や危ない変更を、個人の反省会で終わらせずチームの知識にする。
結局、Deltaが示しているのは「AIがチームの一員になる」という景色ではない。チームが、自分たちの意図と責任をこれまでより明文化せざるを得なくなるという景色だと俺は見ている。
それは少し面倒だ。しかし、面倒だからこそ価値がある。コードを書く作業を速くする道具は増えた。次に不足するのは、何のために書くのかを雑にしない運用である。