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

エンジニアに必要な「インタビュー力」　顧客の真の望みをAIに伝えるためのコミュニケーション術

AIに「丸投げ」は厳禁　AWSのIDE「Kiro」はなぜ仕様駆動型開発に行き着いたのか？

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

　前回は今回はルネッサンス期の発明家たちになぞらえた「ルネッサンスデベロッパー」という概念で、AI時代のエンジニアを身につけるべく5つの重要な資質について語るパートだった（関連記事：ダ・ヴィンチに学べ　AI時代に求められる「ルネサンス・デベロッパー」という生き方）。今回は3つ目に取り上げた「コミュ力」がテーマ。あいまいすぎる自然言語の弱点を解消するための仕様駆動型開発についても掘り下げる。

コミュニケーションは思考そのものと同じくらい重要

　ルネッサンスデベロッパーの3つ目の資質はいわゆる「コミュ力（COMMUNICATES）」だ。ボーガス氏は、「人間はコミュニケーションを行なう。この観点に立つと、考えを明確に表現する能力は、思考そのものと同じくらい重要であることに気づく。だからこそ、エンジニアや技術リーダーがキャリアのためにできるもっとも重要なことの1つは、強力なコミュニケーションスキルを実践し、開発することだと考えている」と語る。

Amazon CTO ヴァーナー・ボーガス氏

　ボーガス氏は2年前の基調講演のテーマである「The Frugal Architect」のスライドを再度披露する（関連記事：倹約的なアーキテクトとは？　AmazonボーガスCTOが今一番気になるコストとAIを語る）。イメージはAmazonのホームページだが、システムは3つの階層（ティア）に分かれている。ティア1はショッピングサイトとして必須とも言える検索、閲覧、ショッピングカート、チェックアウト、レビューなどの機能。一方、ティア2はパーソナライズや推奨事項などで、ティア3はあれば便利な仕組みだ。

　これらの階層付けは、エンジニアとしてではなく、ビジネスに向けたコミュニケーションツールとしても重要だという。エンジニアはビジネス側とこのティアにいくつかの9が必要なのかを話し合えばよい。「『4つの9（＝99.99％）』だったら、それなりのコストがかかります。でも、ティア2は『3つの9（99.9％）』かもしれないし、ティア3は『2つの9（99％）』かもしれない。この場合のデータセンターがオフラインになったら、手動で復旧しなければならない。このビジネス機会について、エンジニアはビジネス側に明確に説明できなければならない」とボーガス氏は語る。

階層分けしたシステムでビジネス側とディスカッション

あいまい過ぎる自然言語を機械との対話で利用できるのか？

　人間が利用する自然言語はあいまいだ。同時にさまざまな意味を持つため、抽象的になってしまう。一方、人間はさまざまな感覚を持つため、自然言語をあいまいさの少ないものに変えることができる。「Let's eat Grandma」は「おばあちゃんを食べよう」だが、「Let's eat, Grandma」は「おばあちゃん、食べよう」になる。実際はカンマがなくても、多くの人は文脈から正しい意味を理解するだろう。

カンマの有無で文章の意味は全く異なるが、人間はそれを理解する

　人間同士で利用するあいまいな自然言語に対して、人間が機械に対して利用してきたプログラミング言語は正確で、精緻であるが故に、機械は人間の意図を汲み取ることができる。しかし、生成AIの登場であいまいな自然言語でも機械との会話で利用できるようになった。裏を返せば、自然言語の抽象性を減らし、あいまいさを軽減できる仕組みを開発ツール側も実装する必要がある。これを実現するのが、従来システム開発で利用されていたスペック（仕様）をAI開発で用いる仕様駆動型開発だ。

　ボーガス氏の紹介で仕様駆動型開発について説明したのは、AWS シニアプリンシパルエンジニアのクレア・リーゴリ氏だ。

　リーゴリ氏が課題に感じたのは、コーディングアシスタントでのバイブコーディングで望んだ成果物がうまくできなかった経験だ。生成したコードはよかったが、完成したソフトウェアがよくなかったため、イチから作り直すことが何回もあった。ただ、「時間が経つにつれ、ソフトウェアを定義するプロンプトがどんどん長くなっていったことに気がつきました」とリーゴリ氏は振り返る。

AWS シニアプリンシパルエンジニア クレア・リーゴリ氏

　ソフトウェア開発の前に、自分の意図をAIに伝えるべく、動作やふるまいを定義するプロンプト。これはまさに仕様書だ。「アポロ開発から、UNIXに至るまで、多くの歴史的なシステムは仕様書に依存していました。仕様書こそがコーディングアシスタントとの対話で欠けているものだと気づいたのです」とリーゴリ氏は振り返る。

プロトタイプ制作を迅速に行なうため、Kiroに何が必要だったのか？

　AIを用いた仕様駆動型開発においては、仕様の定まらない真新しいアイデアを伝えるのが難しいという課題がある。これに対しては、なによりプロトタイプを作ることが重要だ。「ラピッドプロトタイピングは決して新しいアイデアではありません。1960年代はパンチカードが使われていた頃。1964年にはラーグ・エンゲルバートは、底に車輪が付いており、それをテーブル上でスライドさせ、コンピューターの画面上の何かを指すデバイスのアイデアを思いつきました」（リーゴリ氏）。

　もちろん、今のわれわれはこのデバイスのことを頭に思い浮かべることができる。しかし、1960年代にこのアイデアやデバイスを説明するのは困難だったはず。そこで作られたのが、まさにマウスのプロトタイプだ。「それは木製の殻で、底に車輪、上にボタンが付いていました。このおおまかなプロトタイプは、どんな図や説明よりも、最低限必要な仕様を伝えることができました。人々はそれを手にとれば、その概念を即座に理解できました」とリーゴリ氏は語る。

1964年、デバイスのアイデアをプロトタイプに

　AWSのIDEツール「Kiro」においても、仕様駆動型開発におけるプロトタイプ制作の機能は重要だった。人間との対話によって、よいと悪いのフィードバックを繰り返し、プロトタイピングを容易にする。「AIは迅速なプロトタイピングを可能にしました。1つのアイデアをコード化するのに今までは数ヶ月かかっていましたが、AIでは動くプロトタイプを数分で作れます。こうすればフィードバックがすぐに行なえます」とリーゴリ氏は語る。