「もしAIが最初から存在していたら」：コードが安くなったからと言って、どの機能を実装するか決めるのが簡単になったわけではない

ソフトウェアの歴史のほとんどにおいて、開発のコストが高かった。チームはアイデアを実際のコードに変換するのに数ヶ月を費やし、その希少性がすべての作業の組織化を形作った。

ロードマップは利用可能なエンジニアリングの能力に基づいてシーケンス化され、アーキテクトはシステムを理解してテーブルに座るようになった。プロダクトマネージャーは、開発者が実行できるものに変換するために、ビジネス要件を翻訳するために週を費やした。ソフトウェアの開発がボトルネックであり、当然、そこがレバレッジのある場所だった。

しかし、それはもはや真実ではない。エンジニアリングのリーダーがそれを理解する時間よりも、変化は早く起こった。

AIコーディングツールは実装のコストを削減した。従来、エンジニアチームが数週間かかった作業が、エージェントが数時間で完了する。当然の仮定は、より速い開発が直接、より速い価値の提供につながるというものだった。

しかし、実際のところは、もっと複雑である。チームは、どのように扱うかわからないほど多くのソフトウェアを生成できるようになり、遅れていたものが静かに別の場所に移動した。

「AIを破壊されたプロセスに適用することはできない」と、intiveのテクノロジー担当アメリカズ担当Pablo Gambaは述べた。「それは、労働者により速いシャベルを与えるのと同じだ。彼はより速く作業できるが、間違った方向に進むだけだ」。

より速い実行、同じ古い制約

テクノロジーの大きな変化 – インターネット、クラウド、オフショア開発 – すべてが同じパターンに従っている。高価だったものが、ほぼ一夜にして安くなり、企業がそのコストの前提で構築したすべてを破壊して再構築しなければならなかった。

今回、安くなったのは、サービス企業やエンジニアリングチームが数十年間請求してきた適用技術知識そのものである。Gambaは主張する。

実行のコストが安くなったからといって、制約が消えるわけではない。ただ、制約が見えにくい場所に移動するだけだ。たとえば、コーディングのボトルネックは、上流に移行して実装を速めたが、障害はコードレビューに移動した。コードレビューを自動化すると、テストとデプロイに障害が現れ、さらに自動化すると、最終的に人間がエージェントが作業するための仕様を書くところに障害が現れる。

エージェントは、行動するために必要な情報を正確に記述されていないと、推測するしかない。

多くのチームが今、気づかずにこの罠に陥っている。もしあなたが、従来よりもはるかに短い時間でほとんど何でも構築できるなら、間違ったものを構築するコストは低くならず、むしろ高くなる。なぜなら、間違ったことをより速く、そしてより多く出荷することになるからだ。

従来、数週間かかったコーディングの間にゆっくり浮かび上がる仮定は、誰も疑問に思わないで、出荷されたコードの基盤となるインフラストラクチャになる前に現れる。優先順位付け、生産性ではなく、AI投資が実際に自分で支払うかどうかを決定する。

Gambaは、企業が開発のスピードではなく、意図から生産までの全サイクルを追跡するべきだと考える。 「もし開発のスピードを改善しても、QAがボトルネックになっているなら、ただQAに早く到達しただけだ。次にQAを修正すると、ボトルネックは要件に移動する」と彼は述べた。

数字も彼を裏付ける。クラウドセキュリティアライアンスの調査によると、AI支援開発を使用するフォーチュン50企業は、同業他社よりも3倍から4倍もコミットを迅速に出荷している。しかし、新しいセキュリティの問題を約10倍の割合で導入している。

明確な目的地がない場合、スピードはただの無駄遣いではなく、セキュリティチームが追いつくよりもリスクを速く増加させる。

AIが活用できる言語で要件を記述する

もし定義が実際の制約になっているなら、解決策はより多くのドキュメントを書くことではない。AIシステムが独自の推論なしに実行できる形式で書かれた、異なるドキュメントが必要だ。

それは、人間が判断をもとに解釈するために書かれた要件ドキュメントを退役させ、エージェントが実行できる構造化された受け入れ基準、明示的なドメインモデル、契約テストに置き換えることを意味する。契約テストでは、機能が何をしないべきかを、機能が何をすべきかと同じくらい明確に記述する。

エージェントは、ジュニアエンジニアと同じように、曖昧さを推測する。違いは、後者の推測が、ある程度の躊躇い、上司への警告、間違っているかもしれないという感覚とともにくることだ。

エージェントの推測はそうは見えない。完全なコードとして現れ、間違っていても、そこに疑問の余地はない。

エージェントが推論することなく生存できるほど正確な仕様を書くことは、製品のブリーフを書くことのように感じるのではなく、契約書を書くことのように感じる。

チームは、仕様の書き方をドキュメントの作業として扱うと、教訓を学ぶ。曖昧な意図は、機械のスピードで曖昧なソフトウェアを生み出す。

生産性の向上を実現しているチームは、仕様の書き方を独自のエンジニアリングの分野として扱っている。バージョン管理、レビューサイクル、テストの厳格さと同じレベルで、コード自体に従来予約されていたものだ。

Gambaの言葉を借りて言うと、AIネイティブはプロセスを省略する許可ではなく、最初から再設計する要求だ。 「多くの組織は古いプロセスにAIを適用しようとしている。だが、それは変革ではない。AIネイティブな組織は、別の質問から始める。もしAIが最初から存在していたら、どのように設計するか？」

バックログマネージャー、意図のキュレーター

製品、建築、エンジニアリングは、クリーンなハンドオフを伴う3つの別々の機能として実行されていた。製品は何を作るかを決定し、建築はどのように作るかを決定し、エンジニアリングはそれを出荷した。

実装が安価で速くなると、それらのハンドオフが全体の最も遅い部分になる。ここで重要になるのは、全体像を把握し、エージェントが実行できるものに意図を翻訳し、間違った仮定が出荷されたコードになる前にそれを捕まえることができる人だ。

その再設計は、誰が定義するか、そして仕事が何であるかを静かに形作っている。

「ソフトウェアエンジニアの役割が何をしているか考えてみて。彼らはコードを書くだけでなく、エージェントの出力を監督し、仕様を定義し、テストを準備し、結果を検証している。つまり、以前は別々の3つの役割を1つにまとめたようなものだ」とGambaは述べた。

つまり、価値があるのは、チケットを書く方法やスプリントを実行する方法を知っていることではなく、仕事が始まる前に「素晴らしい」とはどういうことかを知っていることだ。知恵があって、顧客が本当に必要としているものと、知的に興味深いものの違いを判断する能力が必要だ。明らかにそれが基準を満たさない場合、アイデアを迅速に却下する勇気が必要だ。

これらは、製品マネージャー、建築家、テックリードがノートを比較検討していた判断呼び出しだった。増えているのは、仕事を定義することに最も近い人にそれらが着地することだ。

そして、重要なのは、これはタイトルが消えることを意味しない。ただし、タイトルの間の線は、より難しく防御することが難しくなっている。しかしそのブラーの中で生き残っているのは、意図のキュレーターとして行動する人たちだ。

ガードレールのない高速実行は勝利ではない

意図が明確で、AIパイプラインが真正に活きている場合に、見落としやすいリスクがある。高速で、明確に定義された実行は、より遅く、より人間の介入が必要なプロセスでは捕捉されていた失敗を導入する可能性がある。

数字は近くない。Veracodeの2026年春のテストによると、有力なモデルをテストした結果、明示的なセキュリティガイダンスが提供されていない場合、コード生成タスクの55%のみがセキュアな出力を生成し、2年間で機能的精度が大幅に改善されたにもかかわらず、ほとんど変化していない。

シンタックスを正しくすることが難しい部分ではなくなったことは明らかだ。セキュリティ、コンプライアンス、どのシステムがどのデータに触れるべきかについて、人間のエンジニアが直感的にタイプしながら行っていた判断呼び出しは、置き換えられない。

これは、機能要件と同じくらいの注意深さで、セキュリティの境界、データ処理のルール、倫理的制約を定義することを意味する。

それらを暗黙のままにして、エージェントが正しく推論することを期待することは、製品要件を曖昧にして、構築がうまくいくことを願うのと同じ間違いだ。

リーダーシップとは

これは、AI加速開発に反対するものではない。開発は、以前より速く、安くなった。瓶に戻すことはできない。

しかし、どの機能を実装するかを正確に決定することは、仕様を十分に記述することは、また、どの線を越えるべきではないかを定義することは、簡単になったわけではない。

企業レベルでは、先を行っているチームは、最も速いコードエージェントを持っているチームではない。明らかだ。競合他社よりも先に、定義が常により難しい問題になることを理解し、それに対処し始めたチームだ。