コードを書くのはもうエージェントです。開発者の仕事はこう変わりました

家族に開発者がいる家の食卓では、必ずこの質問が出ます。機械がコードを書くなら、いったい何が残るのか。

正直に答えるなら、その質問は仕事の間違った部分を狙っています。コードを書くことが仕事のすべてだったことは、一度もありません。それは目に見える部分であり、机の後ろを通りかかった人に仕事らしく見える部分でした。そして多くの週において、いちばん小さい部分でもありました。

自動化されたのは、もともと仕事の一部でしかない

リリースされるものはすべて、6つの工程がつながった1本の鎖を通ります。

1. 誰かが何かを欲しがり、それをうまく言えない。
2. 誰かが、やる価値があるかどうかと、いつやるかを決める。
3. 誰かが、それを実行できる精度の説明に変える。
4. 誰かが作る。
5. 誰かが、ほかが壊れていないことを確かめる。
6. 誰かがリリースして、頼んだ人に伝える。

エージェントが奪ったのは4番目の工程です。しかも説得力のある形で奪いましたし、これからもうまくなり続けます。ほとんど誰も口に出さないのは、それが残る5つに何をしたかです。5つは軽くなったのではなく、重くなりました。

理由はスループットです。作るのに2週間かかっていたころ、周りの5つの工程にも2週間の猶予がありました。真ん中が遅いから5つも遅かっただけで、遅いことに誰も気づいていませんでした。作るのが午後の数時間で済むようになると、残り全部が一斉にボトルネックになります。

1つの工程が縮みました。その工程が隠していた重さを、いまは残りの5つが背負っています。

話の骨格はこれで全部です。ここから先は、その5つを毎日実際にやるとどうなるのかを1つずつ見ていきます。

工程1: 何を作るかを聞き取る、半分を取りこぼさずに

新しい失敗の形ははっきりしていて、しかも高くつきます。何でも作れるようになったので、間違ったものをより速く作るようになりました。

要望はあらゆる場所から届きます。サポートのスレッドに来た1通。打ち合わせの終わり際のひとこと。SNSでの不満。中身は機能要望なのに、バグ報告の顔をしているもの。以前はそれほど問題になりませんでした。どうせ2週間に1つしか作れず、いちばん分かりやすいものを選んでおけばだいたい正解だったからです。週に5つ作れるようになったいま、正しい5つと間違った5つの差が、あなたの1年のほとんどを決めます。

必要なことは2つあり、それぞれ別のことです。

1つ目は、書き込む側にとって手間が小さいことです。アカウントを作り、フォームを探し、問題を2回説明しなければならないなら、ほとんどの人はやりません。それでもやってくれる人は、代表的なサンプルではありません。誰でも要望を出せて、スクリーンショットを添えられて、その後どうなったかを追える公開フィードバックボードは、その摩擦をなくします。プロダクトを使っている本人が、自分の言葉で、文脈を添えて要望を書いてくれます。

2つ目は、仕分けが自動であることです。生のフィードバックは、長くは役に立ち続けません。ほぼ同じことを言っている20通は、誰かが20通すべてを読んで1つの問題だと気づくまで、20個の問題に見えます。そしてそれは、誰にも時間がない種類の仕事です。Idea Radarがそこへの答えです。生の声は手を加えられないまま届き、自分でテーマごとにまとまり、重複は2つの開発になる前に突き合わされ、それぞれのアイデアには何人が別々に要望したかの数が付きます。書かれた言葉そのものは決して書き換えません。その人が使った言葉こそがデータだからです。

この工程が生み出すのはバックログではありません。読める形になった、生の声の集まりです。

工程2: 決めること、いまいちばん足りない資源

アイデアのボードは計画ではありません。前者を後者に変えるのは判断であり、かつては四半期に薄く引き延ばされていたその判断を、いまは毎週下さなければなりません。

ここで効く動きは2つです。

昇格は意識的に行います。アイデアがバックログのチケットになるのは、誰かが作る価値があると決めた時点であって、投稿された時点ではありません。それ以外は、要望した人数を付けたままレーダーに残ります。それが正直な状態です。聞いてはいる、まだ予定はしていない、という状態です。8割の行が永久に作られないバックログは計画ではなく、計画のような見た目をした保管庫です。

スコープを決めるのは、作る前です。作りながらではありません。曖昧なフィードバックは、要望した本人が見て確認できる検証済みのモックアップになります。5分の確認は、間違った画面を作る午後に勝ちます。しかもこの取引は、その午後が自分の午後ではなく、ほかに使えたはずのエージェントの午後に変わった日から、はるかに割の良いものになりました。

工程3: 指示を書くこと、打ち込む作業に取って代わった技能

本当の腕前が移った先がここです。

エージェントは、同僚のように曖昧な指示に食い下がってはくれません。「待って、決済フローは2つあるけど、どっちのこと」とは言いません。空白をもっともらしい推測で埋め、筋は通っているのに間違ったものを渡してきます。曖昧さの代償は、かつては会話1回でした。いまはdiff 1本です。

良い成果を出す人と、1日中エージェントと格闘する人を分けているのは、プロンプトの巧みさではありません。使い回せる文脈です。4種類あり、見返りの大きい順に並べます。

エージェントが探索を始める前に読む文脈。 リポジトリにコミットされた規約ファイル（CLAUDE.md、AGENTS.md）と、アーキテクチャの決定、過去に踏んだ罠、いまの形になっている理由を持つプロジェクトメモリです。一度書けば、すべてのマシンのすべてのエージェントが、いつまでも読みます。いま開発者が書く文章のなかで、いちばん見返りが大きいのがこれで、しかもほとんど誰も、そのための時間を確保していません。

手順は、手順として保存する。 リリースのチェックリストを10回目に説明しているとき、あなたは指示を書いているのではなく、打ち直しています。スキルライブラリは、繰り返す手順を、タスクが一致したときにエージェントが読み込むものに変えます。プロンプトライブラリは、指示そのものに対して同じことをします。

説明する代わりに、見せる。 ずれたボタンを説明する段落より、ずれたボタンの画像のほうが上です。画面の一部をそのまま送るか、その上に描き込んでどれのことかを指し示してください。ウェブページなら、生きているDOMをエージェントに渡すほうが、説明するより毎回勝ちます。

打つ代わりに、話す。 話した3文の指示は、わざわざ打つ気になった1文より多くのニュアンスを運びます。短い指示ならボイス入力、キーボードに触らずやり取りしたいならボイスモードです。快適さのための機能に聞こえます。実際には帯域幅の機能です。人は打つより話すほうが多くを伝えますし、エージェントはあなたが伝えた内容の範囲でしか動けません。

最初の3つはタスクごとに支払います。4つ目は一度払えば、あとはずっと回収し続けます。

工程4: 作業を走らせる、正しいマシンの上で

エージェントが1体なら道具です。複数になるとシステムであり、システムには運転する人が要ります。

現場の問いは華やかではありませんし、それこそが仕事です。2体が同じモジュールを触らずに並行できるのはどれか。走っている間、目を離してはいけないタスクはどれで、離していいのはどれか。自分が寝ている間に走らせておくべきものは何か。

最後の問いが、作業をどこで実行するかを決めます。途中で止めたり、直したり、向きを変えたりする可能性のあるものは、目の前のマシンに置きます。長くて、指示が固まっていて、曖昧さの少ない作業は別の場所に出します。自分が持っている別のコンピュータか、SSHでつないだサーバーです。2時間かかる作業に、ノートPCを人質に取られないためです。繰り返す作業はスケジュールに載せます。判断を分けるのはマシンの生の性能ではなく、自分が介入する必要が出てくる確率です。

作業のなかに本当に性質の違う段階があるとき、エージェント1体はその形に合いません。作ってからテストして、それからレビューするものは、3つの異なる専門を持つ3つの仕事です。エージェントチームを使えば、その受け渡しを明示的に描けます。段階ごとに文脈を説明し直す必要はありません。

そしてこのどれも、あなたがそこに座っていることを要求しません。だからスマートフォンから操作することは、目新しさのための機能ではなくなります。電車のなかでエージェントの質問を読み、20秒で答える。それが、終わったタスクと、あなたを4時間待っていたタスクの差になります。

工程5: レビュー、責任が宿る場所

ここは人に渡せない工程で、その理由は技術的なものではありません。

行を追う作業の大半は、すでにエージェントが引き受けました。エージェントが引き受けられないのは署名です。責任はモデルには移りません。本番でマイグレーションがカラムを1つ落としたとき、「書いたのはエージェントです」は誰も受け入れない言い分ですし、受け入れられるべきでもありません。

変わるのはレビューの形であって、レビューの存在ではありません。全行を読むやり方は、5体のエージェントが並行して動く現実には耐えません。午後6時に900行のdiffをざっと眺める人間は、知識を生まずに署名だけを生みます。持ちこたえる方針は、爆風半径に比例してレビューすることです。文言やスタイルはざっと見る。認証、決済、権限、個人データ、マイグレーションは毎回、自分でも書けたはずの人が1行ずつ読む。

これを現実的にするものが2つあります。1つは、混ざった山ではなくエージェントごとにdiffを見られることです。3体が同じリポジトリで作業したとき、誰が何を変えたのかが分かります。もう1つは会話をコミットに紐づけることです。半年後に本当に時間を食う問いは「何が変わったか」ではなく、いつでも「なぜ変えたか」だからです。

画面のあるものについては、確認はdiffで終わりません。本物のブラウザを操作するエージェントは、自分がいま作った導線を実際にたどって、見えたものを報告できます。ソースの上ではまったく問題なく読めてしまう種類のバグは、そこで捕まります。

その注意をどこに使うかについては、記事を1本まるごと書いています: AIエージェントのコードをまだレビューすべきか。

工程6: リリースして、ループを閉じる

この工程のうち、リリースは簡単なほうの半分です。飛ばされるのは、頼んだ人に伝えるほうの半分です。

そして見返りがいちばん大きいのも、そちらの半分です。何かを報告して、後でそれがリリースされたと知ったユーザーは、次も報告してくれます。報告しても沈黙しか返ってこなかったユーザーは報告をやめ、工程1を養っていた入力が失われます。公開の要望から生まれたチケットが閉じたとき、書いた本人には、誰かがメールを送るのを覚えていなくても届くべきです。

その手前にはたいてい、動いているところを見る必要があるのに、あなたの開発環境を持っていない人がいます。クライアント、デザイナー、別の大陸にいる同僚です。手元のマシンを指す公開HTTPS URLがあれば、それはデプロイではなくリンクを1本渡すだけの話になりますし、返ってきた感想はそのまま工程1に入ります。

こうして鎖が閉じます。これが、待ち行列ではなく仕事である理由です。

本当に縮んだもの、本当に大きくなったもの

この表を正直に読むと、不安の形が変わります。縮んだのは、人を採りやすかった部分です。大きくなったのは、システムとユーザーと結果を理解している人が必要な部分です。それはより難しい仕事であって、より小さい仕事ではありません。しかも、1日中打ち込んでいたころより、はるかに孤独ではありません。

AgentsRoomはこの中のどこにいるのか

私たちが作っているのは、この鎖を丸ごと支える道具です。そうしなければ、互いのことを知らない6つの道具を使うことになるからです。

具体的には、要望はボードに届き、自分でアイデアにまとまり、チケットに昇格し、エージェントが読み違えられない形にスコープされ、あなたのマシンかリモートのマシンで1体のエージェントかそのチームに実行され、会話が紐づいた状態でエージェントごとにレビューされ、頼んだ人に伝えたうえで閉じられます。ウィンドウは1つ、作業の状態が本当のことを言っている場所も1つです。

部品はそれぞれ、よそにもあります。誰も出していなかったのは部品どうしのつなぎ目のほうで、仕事が漏れるのはそのつなぎ目です。

実際によく聞かれる質問

AIは開発者の仕事を奪いますか？

奪われたのは打ち込む作業であって、仕事そのものではありません。コードを書くことは1本の鎖の1つの工程にすぎず、その鎖には、ユーザーが何を必要としているかを聞き取ること、何を作る価値があるかを決めること、それを正確に書き下すこと、実行を回すこと、ほかが壊れていないか確かめること、そしてリリースすることが含まれます。エージェントが安くしたのは1つの工程のコストだけで、その結果、残りの5つがボトルネックになりました。行数を生み出すことで報酬を得る人は減ります。どの行が存在すべきかを決め、それが本番に出たあとに責任を取る人のほうが増えています。

エージェントがコードを書くなら、開発者は実際に何をするのですか？

6つのことをします。そのうちコードで埋まった画面に映っていたのは1つだけです。人が何を求めているかを集め、何をどの順番で作るかを決め、エージェントが読み違えられない粒度で指示を書き、複数の作業を同時に走らせながら見失わず、その変更が壊しうるものに応じてレビューし、リリースして頼んだ人に伝えます。腕の見せどころは、変更を生み出すことから、変更を定義してその責任を負うことへ移りました。

今でもコードを書けるようになる必要はありますか？

あります。しかも読む力については以前より必要です。年に2回しか触らない言語の文法を覚えておく必要はもうありません。エージェントが書くからです。必要なのは、diffを開いて数秒で判断することです。そのマイグレーションは巻き戻せるのか、認証のチェックが動いていないか、そのクエリは10倍のトラフィックに耐えるのか。コードを読めない人はエージェントをレビューできませんし、エージェントをレビューできない人はエージェントを操縦しているのではなく、ただ祈っているだけです。

コードをエージェントに任せると、最初に壊れるのは何ですか？

優先順位づけです。作るのに2週間ではなく午後の数時間しかかからなくなると、間違ったものを作るコストが見えなくなり、だから作られてしまいます。リリースした機能は増えたのに、解決した問題は1つも増えていない。そんなチームができあがります。次に壊れるのはフィードバックのループです。ユーザーからの要望は誰かが仕分けできる速さより速く届くので、チャットのスレッドに積み上がって消えていき、同じ要望だと誰も気づかないまま同じものが2度作られます。

この新しい進め方でいちばん難しいスキルは何ですか？

エージェントが読み違えられない指示書を書くことです。エージェントは、同僚のように曖昧な指示に食い下がってはくれません。空白をもっともらしい推測で埋め、筋は通っているのに間違ったものを出してきます。良い成果を出している人は、気の利いたプロンプトを持っている人ではありません。使い回せる文脈を整えている人です。リポジトリにコミットされた規約ファイル、繰り返す作業ごとに保存された手順、エージェントが探索を始める前に読むプロジェクトメモリ、そして画面を文章で描写する代わりのスクリーンショットやスケッチです。

コーディングエージェントは手元のマシンとリモートのどちらで動かすべきですか？

タスクごとに選んで、両方です。途中で見ていたい、止めたい、直したいものは目の前のマシンに置きます。長くて、指示が固まっていて、曖昧さの少ない作業は、自分の持っている別のマシンかSSHでつないだサーバーに出します。2時間かかる作業にノートPCを人質に取られないためです。判断の基準はマシンの性能ではなく、自分が介入する必要が出てくる確率です。

要点だけ

仕事は消えていません。エディタの外に出て、その周りの鎖のなかに移りました。

今月ひとつだけ変えるなら、工程1を選んでください。その下流はすべて、間違った問題に向いていれば無駄になります。そして工程1は、あなたの1時間の注意が、いまだにエージェントの1時間を、誰にも測れないほどの差で上回る唯一の工程です。