水曜の午後、プロダクトマネージャーが小さな要望を出した。レポートの書き出しに項目を一つ増やしたい。エンジニアはそれを coding agent、つまり自分でコードを読み、書き換えられる AI ツールに渡し、10 分後には変更を受け取った。五つのファイルが変わり、テストはすべて通っている。仕事は終わったように見える。
だがこの時点で、チームにはまだわかっていないことがいくつかある。なぜ五つのファイルすべてを変える必要があったのか。明日書き出しが壊れたら、どこから調べればいいのか。半年後にこのコードを更新するとき、誰が仕組みを覚えているのか。
GitHub は 2026 年 7 月のエンジニアリングブログで、AI が出した変更の第一版を「試し見積もり」にたとえた。安く手に入り、ありうる解決策とその範囲をごく低いコストで見せてくれる。だが安くなったのは「書く」部分だけだ。レビューと保守のコストは、AI によって下がってはいない。だから第一版を完成品として扱うべきではない。その役目は、この変更を受け入れるのにどれだけの代価がかかるのかを、チームに見せることにある。
書くのは安くなったが、残りの二つの請求は変わらない
コード変更の総コストは、おおよそ三つの請求に分けられる。
作るコスト：この版を得るまでに、どれだけの時間と背景説明を費やしたか。これは確かに AI が大きく下げた。
レビューのコスト：変更が正しいと確信するまでに、人がどれだけの労力をかけるか。GitHub の記事ははっきり書いている。人が自信を持って検証できて初めて、変更は安いと言える。レビューできない変更は、コストを後回しにしているだけだ。
保守のコスト：半年後、このコードの振る舞いに責任を持つ人がいるか。記事の筆者が使う確認の問いは、6 か月後にこの振る舞いを引き受けても構わないか、というものだ。
後の二つの請求は誰が払うのか。2026 年 5 月に公開され、ソフトウェア工学の国際会議 EASE 2026 に採択された研究は、人気のある 100 のオープンソースリポジトリで、AI が生成した 1,000 を超えるファイルと約 3,200 回のその後の変更を分析した。その結果、AI が書いたコードのその後の保守の大部分は、人間の開発者が担っていた。AI はコードを渡して去っていき、残るのはチームだ。
第一版で三つのことを確かめる
第一版が試し見積もりなら、受け取った後にやるべきことは、それを使って三つのことを確かめることだ。
変更が範囲を超えていないか。 「項目を一つ増やす」要望で五つのファイルが変わった。それは妥当なのか、それとも AI がついでに別のことをしたのか。GitHub の記事が勧める確認のサインには、変更が複数のモジュールに広がっていないか、テストしにくくないか、新しい製品上の判断を必要としていないか、が含まれる。どれも、その変更が見た目より高くつくことを示している。
レビューする人が自分で説明できるか。 レビュー担当者に AI との対話記録をいったん脇に置いてもらい、この変更が何を解決するのか、データがどう流れるのか、失敗したら一つ前の版にどう戻すのかを、直接説明してもらう。説明できれば、レビューのコストは本当に支払われたことになる。できなければ、肝心な知識は対話記録の中にしかない。
引き受ける人がいるか。 このコードの担当者を決め、はっきり尋ねる。半年後にここで問題が起きたら、あなたが対応しますか。この問いはテストが通ったかどうかより答えにくく、そしてより大事だ。
三つとも答えが出たら、変更を取り込んでよい。方向は正しいが範囲が大きすぎる、あるいはテストが足りないなら、AI に範囲を絞ってやり直させる。試し見積もりの結果、要件そのものがまだはっきりしない、あるいは誰も引き受けたがらないとわかったなら、そこで止める。止めるのは試作が無駄だったという意味ではない。本格的な開発に投資する前に、この請求は割に合わないと見抜けることこそ、第一版の価値だ。
小さな修正にここまでは要らない
この確認は小さな変更を遅くする。一行の文言修正やバージョン番号の更新に、誰が保守するかまで一つずつ確かめるのは明らかにやりすぎだ。こうして確認する価値があるのは、データの流れを変える変更、依存パッケージを増やす変更、課金、プライバシー、権限に触れる変更である。GitHub の記事も、サポートの負担、プライバシー、課金、法令に関わる変更は、コードがどれだけ短くても高くつくままだと指摘している。
チーム自身の土台も、この確認が役に立つかどうかを左右する。ソフトウェアのデリバリー性能を長年研究している DORA は、2025 年の報告書で、AI の主な役割は増幅器であり、組織がもともと持つ強みと弱みを大きくすると述べている。テスト、デリバリーの流れ、責任の分担がもともとはっきりしているチームほど、AI の速さを成果に変えやすい。その土台が弱いところでは、増えた成果物が混乱をより速く広げるだけだ。
次に AI が第一版を出してきたら、取り込む前に二つ問うてほしい。レビューする人は、対話記録を見ずに説明できるか。半年後に引き受けると言った人はいるか。二つとも「はい」なら取り込む。AI がコードを書くときにどこで止まるべきかをまだ決めていないなら、その issue を coding agent に渡せるかは、最初の diff を書き出せるかで決まるを参考にしてほしい。レビューがスマートフォンのような情報の限られた画面で行われるなら、AI が書いたコードをスマホでマージする前に、リポジトリの規則に関所を任せるも参考になる。
AI 整理カード
AI がコードの変更一式を出してきたので、取り込む前に受け入れる価値があるか判断したい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/ai-code-change-ownership-price-check/
記事の見方はこうだ。AI によって第一版を書くのは安くなったが、レビューと保守のコストは下がっていない。第一版は試し見積もりであり、取り込む前に三つを確かめる。変更が範囲を超えていないか、レビューする人が AI との対話記録を見ずに説明できるか、半年後の保守を引き受けた人がいるか。
まず私に 3 つ質問してほしい：
1. もとの要件は何か。AI はどのファイルを変え、どの依存パッケージを加えたか；
2. レビューする人は、この変更が何を解決し、データがどう流れ、失敗したらどう戻すかを説明できるか；
3. このコードに担当の保守者は決まっているか。その人は引き受けることに同意しているか。
私の回答をもとに、次を出力してほしい：
- 変更が要件を超えていないか、AI がついでに行ったかもしれない部分はどこか；
- 作る、レビューする、保守するの三つのコストそれぞれの状況と、まだ足りない証拠；
- 唯一の提案：取り込む／範囲を絞ってやり直す／止める、と理由；
- いますぐできる最小の次の一歩。
ファイルは一切変更しないこと。証拠のない部分は「要確認」とし、自分で補わないこと。取り込むかどうかは、そのプロジェクトに責任を持つ人が決める。
参考資料
- GitHub Blog：The cost of saying yes has changed — https://github.blog/engineering/the-cost-of-saying-yes-has-changed/（2026-07-17）
- arXiv（EASE 2026）：To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — https://arxiv.org/abs/2605.06464（2026-05-07）
- DORA：State of AI-assisted Software Development 2025 — https://dora.dev/research/2025/dora-report/ [accessed: 2026-10-11]
