AIに実装を任せたあと、通ったテストを見ながら少しだけ不安になることがあります。

画面は動いている。lintもtestも通っている。差分の説明も、頼めばきれいにまとめてくれる。

それでも、ときどき立ち止まります。

この変更を、私はどこまで自分のものとして持てているのだろう。

AIでコードを書くことには、もうそれほど特別な感じがなくなってきました。少し前までは、AIにコードを書かせること自体が話題でした。今は、設計の相談をし、実装を任せ、テストを直してもらい、レビューの観点まで出してもらうことが、かなり自然な作業になっています。

もちろん、これはうれしい変化です。

思いついたものを形にするまでの距離は短くなりました。知らないAPIを調べる時間も減りました。面倒で後回しにしていた小さな改善にも手をつけやすくなりました。

ただ、その明るさの横で、少し気になることもあります。

コードは以前より速く生成されるようになった。では、そのコードが入っていくシステムのほうは、同じ速度で理解され、手入れされ、見直されているのだろうか。

そんなことを考えていたときに、Google I/O 2026のWorkshopとして公開されていた、Adam Benderさんの "Software engineering at the tipping point" を見ました。¹

この動画で印象に残ったのは、AIによってソフトウェア開発が速くなる、という話を、単なる生産性の話で終わらせていないところです。

コードを書く速度が上がる。エージェントがテストを走らせ、修正し、またテストを走らせる。個人でもチームでも、これまでよりずっと多くの変更を扱えるようになる。

それは確かに大きな希望です。同時に、こちらの準備が整うのを待ってくれる変化でもなさそうです。

けれど、コードだけが増えていくとき、レビュー、テスト、設計理解、リリース、組織文化はどうなるのか。人間と技術が絡み合ってできているソフトウェアの生態系は、その速度に耐えられるのか。

動画は、そこにかなりまっすぐ踏み込んでいました。

コードは資産でもあり、負債でもある

ソフトウェア開発では、コードが増えることを自然に前進として扱ってしまうことがあります。

新しい機能が増える。できなかったことができるようになる。手作業だったものが自動化される。そういう意味で、コードはたしかに力になります。

でも、コードは書いた瞬間に終わるものではありません。

読まれる。直される。テストされる。移行される。誰かが障害対応の夜に追いかける。使われなくなったあとも、依存関係や運用手順の中に残り続ける。

そう考えると、コードは資産であると同時に、負債でもあります。

この感覚は、AI時代にかなり重要になると思います。AIがコードを書く速度を10倍にするなら、単純にはコードという負債も10倍になりうるからです。

もちろん、AIが書いたコードだから悪い、という話ではありません。人間が書いたコードにも、よくわからないものはたくさんあります。逆にAIを使ったほうが、説明を残しながら、テストも添えて、丁寧に変更できる場面もあります。

問題は、誰が書いたかではなく、そのコードがシステムの中でどう扱われるかです。

レビュー待ちの差分、背景が残っていないテスト、READMEには書かれなかった判断、運用手順に増えた小さな分岐。そういうものは、コードそのものより少し遅れて効いてきます。

レビューが追いつかない。テストが通っていることだけを根拠に、なぜ安全なのかを誰も説明できない。小さな便利ツールがあちこちで増え、いつのまにか保守者も利用範囲も曖昧になる。

そういう状態になると、コードは生成されているのに、システムは少しずつ別の振る舞いを見せはじめます。

プラクティスは仮置きだった

動画の中でおもしろかったのは、AI時代の開発を考えるとき、既存のプラクティスそのものを疑う必要がある、という話でした。

たとえば、コードレビュー。

今の開発では、人間が差分を読み、コメントし、承認してからマージすることがよくあります。これはとても大事なプラクティスです。少なくとも、変更に対して誰かが目を通すという緊張を作ってきました。

でも、AIによって変更の量が大きく増えたとき、同じやり方をそのまま保てるとは限りません。差分が大きすぎて、どこから読めばよいのかわからない。レビューする人がボトルネックになり、やがてレビューが形式だけになるかもしれない。あるいは、追いつかないからといって、人間が見ること自体をあきらめてしまうかもしれない。

テストも同じです。

「すべてのテストがグリーンならリリースしてよい」という考え方は、これまで多くの場面で有効でした。けれど、エージェントが自分の作業確認のために何度もテストを走らせ、コードベースもテスト群も大きく膨らんでいくと、単純に全部を同じ重みで扱うことは難しくなります。AIが直したテストが、本当に仕様を守っているのか、それとも今の実装に合わせて安心の形だけを作ったのかも、見なければわかりません。

だからといって、レビューやテストがいらなくなるわけではありません。

むしろ逆だと思います。

レビューやテストというプラクティスを、絶対に変えてはいけない儀式としてではなく、何を守るために置いていたのかという原則から見直す必要がある。

プラクティスは仮置きだったのだと、少し見えてきました。

ここで言う仮置きは、雑に置いたものという意味ではありません。原則を守るために、その時点で選び取られていた可変の手段だった、ということです。

そう認めることは、過去のやり方を捨てることではありません。いままでそのプラクティスが守ってくれていたものを、別の形でも守り続けるために、一度手に取って確かめ直すことです。

私の言葉で言えば、これは「決めきらず、放り投げず」に近い感覚です。

今のレビュー手法を永遠の正解として決めきらない。けれど、AIが書いたから、テストが通ったから、あとはよしなに、とは放り投げない。

何を観測すればよいのか。どこまでを自動化してよいのか。どの判断は人間の手元に残すべきなのか。

その仮置きを、チームやシステムの状態に合わせて更新していくことが必要になるのだと思います。

システムを見失わないこと

動画では、知的コントロールという言葉が出てきます。

少し硬い言葉ですが、私はこれを「システムを見失わないこと」と受け取りました。

たとえば、AIが直した差分を受け取って、テストも通っていて、PRの説明ももっともらしい。それなのに、次にここが壊れたとき自分はどこから見るのだろう、と思う瞬間があります。

それは、単に自分が細部を読み切れていないという話だけではない気がします。

同じ問題意識は、いろいろな形で表現されています。たとえばShopifyのHead of Engineeringは、Inside Shopify's AI-first engineering playbookの中で、comprehension debt と呼んでいます。²

AIによって開発は速くなる。けれど、その速さの中で考えることや学ぶことまで手放してしまうと、システムを保守し、壊れたときに直し、次の形へ進めるための理解が少しずつ痩せていく。Shopifyの記事では、AIには面倒な作業を任せてよいが、考えることまで委ねてはいけない、という趣旨の話が出てきます。

すべてのコードを人間が手で書くことではありません。すべての関数を暗記していることでもありません。

そうではなく、自分たちが作っている大きなシステムについて、まだ人間が推論できる状態を保つこと。

この変更はどこに波及しそうか。障害が起きたとき、どのあたりから疑えばよいか。このテストは何を守っていて、何を守れていないのか。アーキテクチャ図を描いたとき、チームの理解が完全にばらばらになっていないか。

そういう見通しが、ぎりぎりでも手元に残っていることです。

個別のコードという木だけではなく、依存関係、運用、チームの合意、ユーザーへの影響まで含んだ森を、完全ではなくても見ようとすること。

AI時代には、ここがいちばん危うくなるのかもしれません。

AIは、こちらが頼めばコードを書いてくれます。テストも足してくれます。エラーも直してくれます。その流れは便利で、気持ちよく、時にはかなり頼もしい。

でも、速く進めることと、見失わずに進めることは違います。

自分がなぜその変更を受け入れたのか説明できない。どの前提でAIに任せたのか思い出せない。動いているけれど、次にどこを触れば壊れるのかわからない。

そういう小さな見失いが積み重なると、システムは自分たちのものではなくなっていきます。

ここで大事なのは、AIを遠ざけることではないと思います。

むしろ、AIをシステムを見失わないために使うことができるはずです。

同じAIに、増えた差分の説明をさせている自分もいます。変更の影響範囲を一緒にたどる。依存関係を可視化する。なぜこの設計になっているのかを問い直す。もしユーザー数が大きく増えたら、どこが詰まりそうかを考える。テストが通っていることではなく、何がまだわかっていないのかを言語化する。

そこには、計算資源やトークンのような現実的なコストも含まれます。テストを増やせば安心が増える、という単純な話ではなく、その安心をどの範囲で、どれくらいの負荷をかけて得るのかも考えなければいけない。

AIはコードを増やして、レビュー、テスト、設計理解の関係を変えていくこともできます。

同時に、その変化を観測するための道具にもなりえます。

どちらになるかは、AIそのものというより、私たちが何を見ようとしているかにかかっているのだと思います。

AIは基礎を増幅する

もう一つ、動画で強く残ったのは、AIが組織の基礎を増幅するという見方です。

AIは魔法のように、弱い開発文化をよい文化に変えてくれるわけではありません。

曖昧なものは、曖昧なまま速くなります。

意思決定が曖昧なチームでは、曖昧なまま生成物が増えるかもしれない。責任の置き場所がはっきりしない組織では、誰が育てるのかわからないツールが増えるかもしれない。セキュリティや運用への感度が低い場所では、その低さもまた、生成速度と一緒に増幅されるかもしれない。

これは少し怖い話です。

ただ、悲観だけではありません。

観測する文化があるなら、AIは観測を助けてくれます。仮置きを見直す習慣があるなら、AIはその更新を速くしてくれます。わからないことをわからないままにせず、誰かに押しつけず、言葉にして持ち寄るチームなら、AIはその対話の相手にもなります。

私が守りたい基礎があるとすれば、たぶんそこです。わからなさを、誰かの足元に転がしたままにしないこと。まだ決められないものに、次に見るための置き場所を作ること。

結局、AIが何を増幅するのかは、そこにある基礎によって変わります。

だから、AI時代のソフトウェア開発を考えることは、ツール選びだけの話にはならないのだと思います。

ソフトウェア開発は、コードとツールだけでできているわけではありません。人の相談の仕方、レビューで何を大事にするか、障害のあとに何を残すか、そういう社会的な構造も一緒にシステムを形作っています。

どんなレビュー文化を持つのか。何をテストで守り、何を観測で見るのか。どういう変更は歓迎し、どういうわからなさは一度立ち止まるのか。誰が決め、いつ見直し、どこに記録するのか。

そういう地味な問いが、コード生成の速度が上がるほど、かえって前に出てきます。

変化を観測する

AIによって、これからもコードはもっと速く生成されていくと思います。

その流れを止めたいわけではありません。

むしろ、作りたいものに近づくまでの距離が短くなることには、まだ見えていない可能性があります。小さなチームや個人が、以前なら届かなかった場所に手を伸ばせるようになる。面倒で放置されていた不便が、少しずつ直される。そういう未来を、最初から怖いものとしてだけ扱いたくはありません。

それは穏やかな追い風というより、すでに足元まで来ている波でもあります。

だからこそ、その横でシステムがどこで変わりはじめているのかは、見逃さないでいたいです。

次にAIが出してくれた差分を受け取るとき、私は何を確かめればよいのか。

レビューが形式になっていないか、テストの緑色だけを見ていないか、受け入れたあとも自分たちはそれを育てられるのか。そういう問いを、面倒な確認としてではなく、システムの変化を観測するための小さな習慣として持っておきたい。

プラクティスは変わっていくと思います。変わってよいのだと思います。

けれど、何をよいシステムだと思うのか。なぜその品質を守りたいのか。誰かが困ったときに、どこから一緒に考えられるのか。

そのあたりの原則や責任まで、生成の速度に流してしまわないようにしたい。

コードは生成される。

そのとき、システムもまた変わっていく。

その変化を、恐れすぎず、見なかったことにもせず、次の仮置きを考えるための手がかりとして持っておく。

AI時代のソフトウェア開発で、私がしばらく大事にしたいのは、たぶんそういう態度です。

Footnotes

1. Google I/O 2026, "Software engineering at the tipping point." Transcript available on YouTube. ↩

2. Bessemer Venture Partners, "Inside Shopify's AI-first engineering playbook," 2026. ↩