はじめに
本稿では、GitHub Blogが2026年7月17日に掲載したDalia Abuadas氏のエッセイ「The cost of saying yes has changed」を基に、AIコーディングエージェントの普及によって、小さな機能要望をめぐる意思決定の作法がどう変わりつつあるかを解説します。
参考記事
- タイトル: The cost of saying yes has changed
- 著者: Dalia Abuadas
- 発行元: GitHub Blog
- 発行日: 2026年7月17日
- URL: https://github.blog/engineering/the-cost-of-saying-yes-has-changed/
関連記事
要点
- AIコーディングエージェントの普及により、変更の試作(パッチ)を作成するコストは大きく下がった。
- 一方で、生成されたコードを人間が理解・検証し、その挙動に責任を持つ「引き受けるコスト」は変化していない。
- 認可処理やデータ保持の仕様変更のように、コードの分量にかかわらず引き受けるコストが高い変更が存在する。
- 実装前に是非を議論するより、機能フラグの範囲内で最小限のパッチを作らせ、実際の差分をもとに判断する方法が有効とされている。
- スコープの妥当性を判断する規律は、実装前の議論から、生成された差分をレビューする段階へと一部移りつつある。
詳細解説
「議論」のコストが「試作」のコストを上回った
GitHub Blogの記事では、これまで小さな機能要望に対応する際、最もコストがかかっていたのは実装そのものだったと振り返っています。テストの追加や展開計画の検討、想定外の影響範囲の洗い出しが必要になるケースが多く、エンジニアが「本当に小さな変更か」を慎重に見極める習慣を持っていたためです。ところがAIエージェントによって最初の実装コストが大きく下がった結果、これまで数日かけていた「対象範囲に含めるべきか」という議論そのものが、パッチを1件実際に作らせて確認する30分程度の作業に置き換えられつつあると同記事は指摘しています。
例として、バックエンドに既に存在するタイムスタンプ項目を設定画面に表示するだけの変更が挙げられています。過去の類似事例や納期への懸念から40分間の議論に発展し、結局「1〜2日はかかりそうだ」という確信の薄い結論に落ち着いたといいます。実際に手を動かして確かめる前に結論を出そうとする点に、従来の意思決定プロセスの非効率さがあったと考えられます。
「最初のパッチ」は成果物ではなく価格を確認するための試作品
同記事は、AIエージェントが生成する最初のパッチを「成果物」ではなく「価格を確認するための試作品」と位置づけています。想定していたファイルだけを変更しているか、テストを書きやすい構造になっているか、既存の抽象化を壊していないか、半年後も自信を持って引き受けられる内容かといった観点から、その差分を検証することが推奨されています。想定どおり数行程度の差分にテストが付いてくるならそのまま採用してよく、逆に認可処理のような重要な箇所まで変更が及ぶなら、その要望は最初から「小さな変更」ではなかったと判断できるとされています。
エージェント生成PRのレビューで見落としてはならない5つの落とし穴でも指摘されているように、AIエージェントが生成したコードは人間が書いたコードと同じ観点だけでは見落としが生じやすく、レビューの視点そのものを調整する必要があると考えられます。
「書くコストの安さ」と「引き受けるコストの安さ」は別物
記事が強調しているのは、コードの生成が安く済んだからといって、その変更自体が「安い」わけではないという点です。技術的には動作する差分であっても、誰も引き受けたがらない内容であれば、それは安い変更ではなく将来に先送りされたコストにすぎないとされています。バックエンドに既にある項目を表示するだけの変更は概ね安価である一方、認可の挙動を変更する場合や、データ保持の仕様を変更する場合は、差分がどれほど整っていても引き受けるコストが高いといいます。製品の契約に関わる変更、サポート負担を生む変更、プライバシー・課金・コンプライアンスに触れる変更は、コードが単純であっても却下すべき対象として挙げられています。
この整理は、AI活用を検討する開発チームや中小企業の経営判断にも参考になると思います。「エージェントが書けるかどうか」ではなく「人間が自信を持ってレビューし、責任を持てるかどうか」を基準にする発想は、AI導入の可否を判断する一つの目安になると考えられます。
スコープの規律を、実装前の議論から証拠に基づくレビューへ
従来、変更範囲についての規律は実装に着手する前に発揮されるものでした。実装そのものが高コストだったためです。しかし記事では、その規律の一部を「レビュー段階」に移すことができると論じています。具体的には、既存の機能フラグの範囲内に収め、公開されているインターフェースや仕様を変更せず、テストを追加または更新した上で、可能な限り最小のパッチを作らせるという制約を設けることが提案されています。この制約下でAIエージェントがきれいなパッチを作れなければ、その要望は思っていたより大きなものだったと分かり、逆に作れれば、それも判断材料になるとされています。
これは計画を省略することを意味するのではなく、どの議論が本当に投資に見合うかを見極める発想の転換だと言えます。AIによるコードレビューの活用が広がる中、こうした証拠に基づく判断という考え方は今後さらに重要になっていくと考えられます。
まとめ
本稿では、AIエージェントによってコードの試作コストが下がった一方、生成されたコードを引き受けるコストは変わっていないという視点を紹介しました。今後は「書けるか」ではなく「人間が自信を持って引き受けられるか」を基準にした判断が重要になると考えられます。AIによるコードレビューの広がりについてより詳しく知りたい方は、過去記事でも整理していますので、あわせてご覧いただければと思います。
