PHP 3の創設に貢献した一人であり、GoogleでAgentic Data Cloudを率いるAndi Gutmansは、エージェントを活用したソフトウェア開発を、過去との完全な断絶とは捉えていない。Stack Overflowの番組「Leaders of Code」でEira MayとPeter O'Connorが行ったインタビューで、Gutmansは現在の変化を、コンピューターサイエンスの専門家ではない人々を含め、より多くの人がウェブサイトを構築できるようにしたPHPの影響になぞらえた。
しかし、新たにアクセスしやすくなったからといって、エンジニアリングの専門性が消えるわけではない。Gutmansの見解によれば、個々の開発者は徐々に「エージェントのチームリーダー」に近い存在へと変わっていく。何が必要かを定め、作業を割り振り、結果をレビューし、制約なしには委任できない意思決定を行うのだ。
価値はコードを書くことからエンジニアリング上の判断へ移る
Gutmansは、エージェントの登場後も、いくつかの基本的な問いは変わっていないと考えている。チームは依然として、解決策が正しい問題に取り組んでいるか、アーキテクチャが拡張可能か、システムが安全で適切にガバナンスされ、使いやすく、コスト面でも妥当かを確認しなければならない。新しいのは、エージェントがより多くの作業を自律的に実行できる点であり、そのため生成されたコードを単にレビューするのではなく、エージェントを監督する方法を設計する必要がある。
Gutmansはその例として、あるエージェントを使って約1,000件のテストを作成し、別のエージェントにそれらのテストを批評させたケースを紹介した。レビューによって、成果物は十分に良くないことが明らかになり、Gutmansは自分で改善しなければならなかった。この場合、人間の判断が不要になったのではない。判断の位置が、細部の実装から設計、調整、評価へと移ったのである。
この変化は、 unfamiliarなコードベースを理解することにも及ぶ。エージェントはプロジェクトのより広い範囲を横断でき、人間のレビュアーがシステムの限られた部分を調べる際には見つけにくい種類のバグを発見することもある。それでもGutmansは、Googleでは人間によるレビューとエージェントによるレビューを併用しており、とりわけ意思決定や変更がセンシティブな場合にはそうしていると述べた。
レビューは絶対的な信頼ではなく、リスク管理の問題
この対話では、監督を3つの形態で捉えることが提案されている。人間がループ内にいる形、エージェントがループ内にいる形、そしてエージェントがループの上位にいる形だ。これはすべてのケースに有効な単一の選択肢を意味するのではなく、エラーの可能性とその影響に応じて、適切なレビュー水準を定めることを意味する。
セキュリティトークンなど、セキュリティ上センシティブなコンポーネントに関わる変更では、人間の専門家が関与することがより重要になる。一方、CSSやHTMLの変更、あるいは一部のPythonスクリプトについて、エージェントにセキュリティチェックを行わせる場合には、異なるレベルの自動化に頼る方が実用的かもしれない。ここでの基本的な考え方は、エージェントが間違えないということでも、人間がすべてを同じ効率でレビューできるということでもない。レビューの判断は、リスクの大きさと結果を反映すべきだということである。
Gutmansは、感覚とデータの隔たりを説明する例としてWaymoの経験を挙げた。Waymoでは、Uberのドライバーが運転する車に乗る場合と比べて、人が有害な事故に遭う可能性が80%低いと述べた。それでも、多くの人は人間がハンドルを握っている方が安心だと感じ続けている。同様に、指標が特定の作業でエージェントを使う方が人間による代替手段よりリスクを減らせると示していても、印象を理由にエージェントの自律性を拒むチームがあるかもしれない。
採用と学習は、指示する能力の評価へ向かう
Gutmansは、コンピューターサイエンス教育はなくならないと考えている。ただし学生は、エージェントの支援によって、より複雑で規模の大きいプロジェクトを完成させられるようになる。そのため、システムの構築、運用、拡張の方法に関する知識は依然として必要であり、同時に、問題を定式化し、解決策を評価し、インテリジェントなツールに指示する能力も重要になる。
また、Googleはエンジニアリング面接の一部を変えようとしていると述べた。候補者にquick sortのようなアルゴリズムを手作業で書かせることに重点を置くのではなく、Geminiとエージェントを使って問題を解くことを認め、その思考方法、問題処理の手順、エージェントへの指示方法を評価する。このことは技術的スキルをなくすものではないが、面接で測ろうとするものを変える。抽象的な解決策を素早く生み出す能力から、推論、設計、調整の質へと移るのである。
最大の障害はモデルではなくデータにあるかもしれない
Gutmansによれば、GeminiやOpusのようなモデルは、企業の作業の大部分を自動化できるようになっている。そのため、モデルだけが主なボトルネックなのではなくなった。より重要な課題は、意味的な関係、権限、ガバナンスを維持しながら、企業データをエージェントが理解し、利用できるようにすることだ。
これには、構造化データや運用データに加え、クラウドストレージやその他の場所に存在する画像、PDF、契約書などの非構造化データも含まれる。Googleは、エージェントがデータの所在を発見し、相互のつながりを理解し、これまで大勢のデータスチュワードを必要としていた意味的な概念モデルを構築する支援をできると考えている。Gutmansはこの方向性を「borderless lakehouse」という概念の一環として説明している。この概念は、データがGCP、AWS、Azure、オンプレミス環境のいずれに存在するかにかかわらず、データを活用可能にすることを目指す。
Gutmansは、Icebergのようなオープンデータ形式の重要性にも触れた。また、クラウド間の統合によって、1ギガバイトごとのデータ転送料金に全面的に依存せず、データへアクセスできる可能性があるとも述べた。さらに「knowledge catalog」についても話し、オントロジーの構築を、人間が全面的に主導するプロセスから、エージェントが主導するプロセスへ移行し、人間は重い手作業を実行するのではなく、調整と編集を担う方向性を示した。
実際に何が変わるのか？ 技術チームにとって、ソフトウェアエージェントを用意して動かすだけでは十分ではない。効果的に利用するには、自動化する価値のある作業を特定し、リスクに応じたレビュー水準を設定し、エージェントがアクセスするデータと権限の品質を確認する必要がある。開発者の役割が消えるわけではない。むしろ、実行可能なツール群を指揮するエンジニアに近づき、生成物について最終的な判断を下す責任を担うことになる。