AIエージェントに選択肢　「AWS re:Invent 2025」レポート 第13回

AWSのカルチャー「NOW GO BUILD」を高らかに掲げ、巨人が舞台を去る

ありがとうヴァーナー　「自らの仕事に誇りを持て」は働くすべての人に向けたエール

　12年に渡り、AWS re:Inventで学び続ける尊さをエンジニアに訴えてきたAmazon CTOのヴァーナー・ボーガス氏。昨年末に登壇した最後のre:Invent基調講演では、まさに総決算とも言える90分の熱血講演が繰り広げられた。幸運にもラスベガスでボーガス氏の講演を直接聴くことができたASCII大谷が、AI時代を生きるエンジニアへの熱いメッセージを数回に分けてお届けしたい。

　前回は今回はルネッサンス期の発明家たちになぞらえた「ルネッサンスデベロッパー」で重要な5つの資質のうち、3つ目に当たるコミュ力の重要性、そしてAIコーディングツール「Kiro」と仕様駆動型開発について取り上げた（関連記事：AIに「丸投げ」は厳禁　AWSのIDE「Kiro」はなぜ仕様駆動型開発に行き着いたのか？）。最終回の今回は、4つ目の「所有者であること」、5つ目の「博学者であること」を紹介するとともに、全エンジニア、いや働くすべての人に向けた熱いエールをお伝えしたい。

レビューのないバイブコーディングはギャンブルである

　ボーガスCTOが提唱するルネッサンスデベロッパーの4つ目の資質は「オーナーであること（IS AN OWNER）」だ。「開発者は所有者だ。ソフトウェアの品質を所有する」とボーガス氏は語る。

　AIにより、われわれはこれまで以上に大きなシステムを構築し、多くのアイデアを探求し、より迅速に行動できるようになる。「現代の哲学者」（ボーガス氏）であるDAFT PANKが畳みかける「Harder、Better、Faster、Stronger」のように、より強くで、よりよく、より速く、より強いソフトウェアを作るのに役立つ。今後はこうした高品質なソフトウェアの開発をAIは支援していくことになる。

AIでのソフトウェア開発で、より強くで、よりよく、より速く、より強いものを作るのに役立つ

　しかし、一部の開発者のAIツールを使い方にはリスクが伴うという。「バイブコーディングで問題ないのは、構築されている内容に細心の注意を払った場合のみだ。IDE（統合開発ツール）のレバーを引いて、良いものが出ることを期待するだけではいけない。それはソフトウェアエンジニアリングでなく、ギャンブルだ」とボーガス氏は警告する。

人間のレビューのないバイブコーディングはギャンブルである

　ボーガス氏は、「仕事はあなたのものであり、ツールのものでありません」を再掲する。「医療や金融サービス、規制要件となる要件で、AIが明らかに規制要件に違反するコードを生成しても、AIに罪をなすりつけることはできない。あくまで責任は開発者にある」とボーガス氏は語る。

　一方で、ソフトウェア開発の世界は大きく変わりつつある。AIによってコードは迅速に生成されるようになったが、人間はレビューすべきコードが増えている。人間がコードを記述する場合は、作成とともにコードの理解も得られるが、機械が書いた場合は、人がそれを読んでコードを理解した上で、正しいかをレビューしなければならない。

　これが「検証負荷（VERIFICATION DEBT）」だ。「AIは人間が理解するより速くコードを生成できる。コードはすぐに届くが、人間の理解は追いつかない」。このギャップがあるため、ソフトウェアが実際になにを行なうのかを検証する前に、本番環境に移行できてしまう。

AIによる開発で立ちはだかる検証負荷とハルシネーションの課題

　もう1つの課題は、ご存じ「ハルシネーション（幻覚）」だ。「先ほどクレアはまさにその完璧な例を示しました。モデルは自信に満ちているようにデザインを生み出したが、アーキテクトにはまったく適していなかった」とボーガス氏は語る。一部のAPIは変更され、存在しない属性を作り上げ、不適切で過剰に設計されたソリューションを提案したり、システムの長所を無視してしまう。「正しそうに見えるが、現状に即していない」というのが難しい点だ。

ベソスCEOがカスタマーセンターで電話を受けてわかったこと

　しかし、ツールは前進している。仕様駆動型開発を実現するKIROのようなツールで、どのような仕様に基づいて、検証されたコードを作成されているかも披露された。自動推論を利用して、AWSのAPIに対して、生成されたコードが正しいかを確認する方法も示された。また、CI/CDパイプラインの中で自動テストが組み込まれることも多くなった。これらはいわゆるメカニズムだ。ここでボーガス氏が強調したのは、このメカニズムと善意が必ずしも同じではないということだ。

　Amazon.comでは、顧客の真の要望を理解するため、幹部は毎年2日間を費やしてカスタマーサービスで顧客の電話に対応することが義務づけられていたという。これは幹部だけではなく、創業者であるジェフ・ベソスCEOも行なっていたという。「ジェフはカスタマーサービスエージェントの隣に座ります。電話がつながると、自動システムがこの顧客の注文と履歴を表示しており、隣のエージェントは、『この顧客はテーブルを返品するつもりです』とジェフに語る」（ボーガス氏）。

なぜ顧客はテーブルをキャンセルするのか？

　実際、顧客はテーブルが壊れているため、返品したいと言ってくる。ベソスCEOは、なぜ返品がわかったのかを聞くと、エージェントは「このテーブルの7割は、正しく梱包する方法を知らないドロップシッピング業者がいるため、返品されます」と答える。つまり、エージェントはなぜ返品されるのか原因を知っており、原因は業者が梱包できないからということもわかっている。返品は、誰かの悪意によって起こっているわけではないということだ。

　

　このように関係者すべてが善意を持っている場合、不具合は解消されない。これを解消するメカニズムとして導入されたのが、Amazon版の「あんどんコード」だ。

Amazon版のあんどんコードを導入

　トヨタ生産方式で用いられるあんどんコードは、製造現場に問題が発生した場合に、作業者がひもを引っ張ると、電光掲示板（あんどん）が点灯され、すべての生産ラインが問題解決まで停止するという仕組みだ。Amazon版のあんどんコードは、製品を使用不可能にするというボタン。製品の責任者が問題を修正しなければ、警報が鳴ってしまうというものだった。ボーガス氏は「誰もが善意を持っていたにもかかわらず、このメカニズムが導入されない限りは、なにも変わらなかった」と振り返る。

人間同士のコードレビューは継続し、今後も増やしていくべき

　テクノロジーの世界でもメカニズムはさまざまな形で導入されている。Amazonでも各チームが独自のメカニズムを設計し、実装している。Amazon S3のチームが導入しているのは耐久性レビューと呼ばれる仕組み。これは　システムの耐久性に影響を与える変更を提案する場合、いったん作業を止めて、レビューを行なう。リスクをモデル化し、変更内容を記述し、あらゆる脅威をリスト化し、データを安全に保つためのガードレールを計画する。

　「非常に強力な効果を持つメカニズムだ。耐久性をコードの特性から組織の習慣へと変える」とボーガス氏は語る。エンジニアは成功前提ではなく、失敗前提で考えるようになり、なぜメカニズムが重要かを考えるようになるという。メカニズムにより、善意は一貫した成果に変換されるわけだ。

　もちろんコードレビューも仕組みの一つだ。「みなさんがコードレビューを苦手としているのはわかっています。12歳にして教壇に立っているような感じですよね。でも、意図と実行が出会う瞬間を作り出すために、非常に重要なメカニズムなんです」とボーガス氏。他のエンジニアが前提に疑問を持ち、変更によって見えなくなった点を把握できるようになるという効果もある。

　そして、AI主導の世界では、このコードレビューがこれまで以上に重要になるという。「モデルは人間が理解するよりも速くコードを生成できます。したがってレビューはバランスを回復するための制御ポイントとなる。ここで人間の判断をループに戻し、ソフトウェアが期待通りに動くかどうかを確認します」（ボーガス氏）。

モデルがいくら多くのコードを生成しても、人間でのレビューは重要

　人間同士でのコードレビューは、これまで通り継続し、さらに増やしていくことがオススメだという。「上級エンジニアと初心者エンジニアがいっしょにコードに取り組むと、効果的な学習メカニズムの1つになる」とボーガス氏。上級者はパターン認識力と苦労して得た高度な判断力を持っており、初心者は新鮮な視点を持ち、細かい点に気がつくことも多いという。「私たちはこれが知識を伝達し、次世代のビルダーを育成するやり方だと考えています。AIは多くのことを変えるが、その技術は依然として人によって習得されるものだ」とボーガス氏は語る。

　ルネッサンスデベロッパーの資質の4つ目はオーナーであること。「あなたがビルドすれば、あなたが所有者だ」とボーガス氏は締める。