> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2026/w21-the-inflection-point-of-software-engineering.md).

# W21-ソフトウェアエンジニアリングの転換点

先週、GoogleのエンジニアAdam BenderによるGoogle I/O 2026の講演、[Software engineering at the tipping point](https://io.google/2026/explore/workshop-2)を見た。AIがソフトウェアエンジニアリングに与える衝撃と、コード生成速度が10倍、あるいはそれ以上になったとき、既存のソフトウェア生態系がどんな限界に達するかを論じたものだ。

この講演で、『[Googleのソフトウェアエンジニアリング](https://abseil.io/resources/swe-book/html/toc.html)』、いわゆるFlamingo bookを思い出した。Googleの20年以上の経験をまとめ、Monorepo、トランクベース開発、大規模変更、コードレビュー、テスト、エンジニアリング文化を扱う本だ。以前は大企業の開発体系のベストプラクティスとして読んだ。今見ると、個別ツールではなく、ソフトウェアが時間と規模の両軸でどう進化し続けるかを論じていると分かる。

ソフトウェアエンジニアリングとプログラミングの最大の違いはここにある。プログラミングはコードを書き、目の前の問題を解く。ソフトウェアエンジニアリングは、数年後、何百人もの人が関わった後でも、そのシステムを理解し、変更し、検証し、安全に進化させられるかを考える。コードを書くのは始まりであり、長く制御可能な生態系の中に保つことが本当に難しい。

Googleの多くの実践は、運命を共有する仕組みを作っている。単一のリポジトリは全社で同じコード資産を共有させ、トランクベース開発は同じ版への継続的な整合を促す。大規模変更は下位ライブラリや安全上の問題の自動修正を可能にし、コードレビューと非難しない振り返りは個人の経験を組織の能力に変える。単純なツール崇拝ではなく、社会技術システムだ。技術的な道具が規模を、開発文化が協働を支える。

Benderの講演で最も面白かったのは、AIがコードを書けるかだけでなく、この生態系の中にAIを置いたことだ。AIが現れても、従来の問題は消えず、拡大しただけだ。DORAの[AIは増幅器である](https://dora.dev/capabilities/user-centric-focus/)という見方に、私は同意する。AIは強さを増すが、方向は決めない。テスト、構造、協働の仕組みが健全なら効率を増幅し、土台が弱ければ混乱を増幅する。

以前は1人が1日に数十行、数百行を書くので、問題の露呈も遅かった。今後、複数のAgentが同時に変更し、生成速度が10倍、100倍になれば、開発体系はもっと速く限界へ近づく。コードが安くなると低品質なコードが積み上がり、資産がすぐに負債になる。ビルドとテストへの負荷は増し、今は終えられるテストも、コードと依存関係の膨張で耐えられなくなるかもしれない。レビューも処理量が制約になる。人間の専門家がAIの大量の変更をreviewするだけで疲弊すれば、基準を下げざるを得なくなる。

さらに厄介なのは、全体の制約がない複数のAgentが、互いのコードを変更し合う可能性だ。あるAgentがリファクタリングし、別のAgentが元へ戻して、「Agent同士の編集内戦」になる。冗談に聞こえるが、高速・低コストでコードを生む環境では、起きないとは言えない。明確な抽象化の境界とフィードバックがなければ、混乱も高速に自動化される。

だからAI時代の開発は、「AIにもっとコードを書かせるには」にだけ目を向けてはいけない。書く費用が下がるほど、システムの制約、検証能力、アーキテクチャの判断が希少になる。1本の木から、森全体を管理する視点へ移る必要がある。単一の関数、モジュール、CRだけでなく、生態系全体の境界、フィードバックループ、進化の秩序を考えるべきだ。

チームが先に備える価値のある方向が、いくつかあると思う。

第一に、Tokenとテスト用計算資源は新しい開発資源となる。無限の裏方と見なしてはいけない。

第二に、検証戦略を賢くする必要がある。単純な全件テストと人のreviewだけには頼れない。

第三に、分離能力を高め、実験的なAIのコードが中核の処理経路へ簡単に混ざらないようにする。

第四に、人がシステムを理解する能力を取り戻す。AIの大きな価値はコード作成だけでなく、複雑なシステムの理解、動的な構成図の生成、依存関係の検討、二次的な影響の分析にもある。

これは、最近議論しているAI-Readyな開発にも近い。ツールをいくつかつなぎ、promptを少し増やすことではない。より高速で、並列度が高く、不確実な生産方式に、既存の開発体系が耐えられるようにすることだ。基盤、コード規約、テスト、文書、アーキテクチャの表現、レビューの仕組み。従来は「遅い」仕事に見えたものが、AI時代にはむしろ重要になる。

原則は変わっていない。変わったのは生産力とシステムへの圧力だ。コード生成が速くなるほど、基礎へ戻る必要がある。チームの競争力は、AIでより多くのコードを書けるかではなく、AIが安全に参加し、継続して検証され、制御可能な形で進化する開発生態系を設計できるかで決まるのかもしれない。