【AWS re:Invent 2025】基調講演レポート A Special Closing Keynote with Dr. Werner Vogels #AWSreInvent #KEY005

概要

• Werner が re:Invent の基調講演から「卒業」し、「次の世代の新しい声に道を譲る」と宣言。
• 基調講演のテーマは、開発者の役割の変遷とAI 時代に求められる“ルネサンス開発者”。
• AI は仕事を「奪う」のではなく、役割を変える存在である。
• 成功するルネサンス開発者像として、好奇心（Is curious）・システム思考（Thinks in systems）・明確なコミュニケーション（Communicates）・オーナーシップ（Owner）・ポリマス/T型人材（Polymath）の5つの資質からなるフレームワークを提示。
• 最後のメッセージは「Have pride in your work.」誰も見ていないところでも正しくやる、そのプロフェッショナルとしての誇りこそが開発者を定義すると締めくくりました。

座席に置かれた新聞

会場に着くと、座席には１部ずつ新聞が置かれていました。
タイトルは「The Kernel」
https://thekernel.news/

基調講演の中でWernerは「この新聞のAndy Warfieldの記事を読んでみてください」と紹介していました。実際に読んでみましたが、本当に素晴らしい内容でした。特に、
「こうした恐ろしい（そして時には恐怖を感じる）瞬間こそが、私たち全員が最も多くを学ぶ瞬間」
という一節は、私自身の経験とも強く重なりました。

長文なので、以下に要約を掲載します。




「A Little Bit Uncomfortable」（少し不快）　　アンディ・ウォーフィールド

「君を怖がらせることはできる。それが僕の仕事なんだ。
もし君が覚悟しているなら、僕が提案するのはこれだ。」
— スケアード、ザ・トラジカリー・ヒップ

筆者は人前で話すことに強い恐怖心を抱いており、若い頃、イタリアで初めて論文発表をした際には、毎日不安で嘔吐し、発表本番ではPlan 9の作者たちから厳しい批判を浴びて大きく傷つき、「二度と発表したくない」と思ったと振り返ります。それでもシステム構築や研究が好きで、そのキャリアには発表が不可欠だったため、うまく話せない失敗を何度も重ねながら人前に立ち続けました。実際に一番つらいのは、本番そのものよりも、直前数時間の圧倒的な不安だといいます。

恐怖の対象は講演だけではなく、会議で人と話すこと、上司との1on1、面接、会議で発言すること、重要な設計変更を提案すること、起業すること、助けを求めることなど、多くの「不安をかき立てる出来事」にも及びます。しかし振り返ると、そうした居心地の悪い瞬間こそが、自分のスキルや人格が最も成長した場面だったと気づきます。ヤーキーズ・ドットソンの法則が示すように、適度なストレスはパフォーマンスを高め、恐怖は「未知に踏み込んでいる」というサインになり得るからです。

キャリアを重ねリーダーになると、自分が勇気を出すだけでなく、他者がリスクを取れるよう支援することも重要になります。「今、何が怖いですか」「どう自分を伸ばしていますか」と問うことで、人々が成長の機会に気づく手助けができます。また、人が固まったり攻撃的になったり話題をそらしたりする瞬間は、不安と真剣さの表れであり、リーダーが関わるべき重要なタイミングです。勇気とは大声で叫ぶことではなく、「難しい道を選び続ける静かな粘り強さ」であり、滅多に発言しない人が挑戦的な質問をしたときなどは、それを認めて支える好機でもあります。re:Inventの週を終えた今、筆者は「成長は不安の縁で起こる」と改めて強調し、「今週あなたを怖がらせることは何か、それを実行できるか自問してみてほしい」と読者に問いかけています。

テーマ：開発者の役割の変遷と“ルネサンス開発者”

Werner のメインメッセージは大きく 2 つでした。

1. 開発者の役割は、ツール／アーキテクチャ／期待値の変化とともに常に変わってきた。

2. AI 時代を勝ち抜くためには、「ルネサンス開発者」という新しいフレームワークが必要だ。

変化の波：言語・アーキテクチャ・IDE の進化

プログラミング言語の進化、アーキテクチャの変遷、IDE や開発ツールの高度化……。
開発者は常に新しい波にさらされ、変化への適応を求められてきました。

• モノリシックからマイクロサービスへ

• オンプレからクラウド、そしてサーバレスへ

• 手書きのボイラープレートから、AI 支援によるコード生成へ

技術の “当たり前” が更新されるたびに、開発者の役割と求められるスキルセットも変わり続けています。

「AI は仕事を奪うのか？」

よくあるこの問いに対して、Werner の答えは非常に明快でした。

• AI は仕事を置き換えるのではなく、役割を変える。

• そしてもっと本質的な問いは 「AI があなたを時代遅れにするか？」 である。

この問いへの答えとして、Werner はこう述べます。

“あなたが進化し続けるなら、断じてノーだ。”

常に学び、好奇心を持って進化し続ける限り、AI によって仕事を奪われることはない。
むしろ AI をツールとして使いこなし、価値を増幅できる開発者こそが生き残る——という、力強いメッセージでした。

いま私たちは“震源地（epicenter）”にいる

宇宙開発、AI、ロボティクスなど、複数の黄金期が同時に進行し、互いを加速し合っている時代。
Werner はこの状況を “epicenter（震源地）” と表現し、歴史上のルネサンスになぞらえました。

この「技術ルネサンス」のど真ん中にいる現代の開発者に向けて提示されたのが、次の “ルネサンス開発者” フレームワーク です。

ルネサンス開発者：5つの資質（フレームワーク）

 １）好奇心を持つ（IS CURIOUS）

Wernerは、ウフォルト・ホイットマンの以下の言葉を引用しました。

　We are not what we know, but what we are willing to learn.

　（人の価値は、すでに知っていることではなく、これから学ぼうとする意志にある。）　

そして、

• 「結果が分かっているものはもはや実験ではない」

• 「真の学習は、自分が失敗するリスクを取って主体的に取り組んだときにのみ起こる」

と語り、実験と失敗を恐れない姿勢 の重要性を強調しました。
新しいツールや技術は、実際に手を動かし、うまくいかなかった経験からこそ本当の学びが得られる——これが Werner の一貫したメッセージです。

また、学びは本質的に「社会的な行為」でもあります。

• ユーザーグループへの参加

• カンファレンスでの開発者同士の交流

• 顧客との直接対話

といった “日常の外” に出る経験によって、学びは一段と深くなります。Werner 自身も、世界中の現場でテクノロジーを使って課題解決に挑む人々から多くのインスピレーションを得てきたと語っていました。

講演では、好奇心と学びによって社会課題に挑む事例として、次のような組織が紹介されました。

Grupo AJE（南米の飲料会社）

アマゾン川流域のコミュニティに仕事と経済的な未来を提供し、都市部への人口流出を防ぐ取り組み。ビジネスの利益と社会貢献を両立させています。

オーシャン・クリーンアップ・プロジェクト

ドローンや AIカメラ、GPS付きダミー・プラスチックなどを活用し、河川から海へのプラスチック流入を予測・抑止するプロジェクト。限られたリソースで効果を最大化するエンジニアリングの好例です。

ルワンダ保健省

ヘルスケアデータの収集・可視化を通じて、医療アクセスが徒歩 30 分以上の地域を特定し、妊産婦向け医療施設を戦略的に配置。データ駆動型の政策で公衆衛生の課題を解決しています。

KOKO Networks（ケニア・ナイロビ）

安価でクリーンな調理用燃料エタノールを、少額から購入できる Fuel ATM として提供。木炭など有害な燃料の使用による健康・環境問題に、テクノロジーで挑んでいます。

こうした事例は、「好奇心を持って学び続ける開発者が、社会にどれだけ大きなインパクトを与えられるか」を具体的に示していました。

YOUR CURIOSITY + YOUR SKILLS = WORLD-CHANGING

私もこの言葉を胸に刻み、少しでも世界を変えていければと思います。



今年もHeroの皆さんが紹介されてうれしかったです。

2) システムで考える（Thinks in Systems）

次に重要なのが システム思考 です。

システム思考とは：

複雑なシステムが時間の経過とともに独自の振る舞いパターンを生み出すことを理解し、
個々の要素ではなく “全体” として捉える考え方

です。

講演では、生態学の有名な事例である イエローストーン国立公園のトロフィック・カスケード が紹介されました。

• 20 世紀初頭、捕食者であるオオカミが絶滅させられた結果、

  • ヘラジカが増えすぎて植生を食い尽くす

  • 森林が失われ、土壌が侵食される

  • 川の流れにまで悪影響が及ぶ

• その後、オオカミを再導入すると、生態系全体がゆっくりと回復し、川の流れまで安定していった

この例が示すのは、「一見ローカルな変更が、システム全体に予期せぬ波及効果をもたらす」ということです。

Werner は、ソフトウェアシステムも同じだと指摘しました。

• キャッシュの導入はトラフィックパターンを変える

• リトライポリシーの変更は負荷のかかり方を変える

• チームの所有範囲を変えると、開発のペースやボトルネックも変わる

ソフトウェアは、相互依存する要素と遅延・フィードバックからなる「動的な生態系」です。
システム全体を俯瞰し、二次・三次の影響まで考える視点 が、レジリエントなシステムを設計できる開発者かどうかの分かれ目になる——というメッセージでした。

To build resilient systems, understand the bigger picture.

回復力のあるシステムを構築するには、全体像を理解する必要があります。

3) 明確にコミュニケーションする（Communicates）

Werner は、

「良いアイデアを持つこと」と同じくらい、
「それを明確に伝える力」も重要だ

と強調しました。

エンジニアや技術リーダーにとって、コミュニケーションはもはや「付属スキル」ではなく中核スキルです。

• 技術用語だけでなく、ビジネスが理解できる言葉に翻訳する

• システムの重要度と可用性・コストのトレードオフを整理して伝える

• 機械（AI）に対しても、曖昧さの少ない指示を与える

「質実剛健なアーキテクト」のフレームワーク

Amazon のウェブサイトを例に、システム機能を Tier 1〜3 に分類するフレームワークが紹介されました。

• Tier 1
  検索、商品閲覧、カート、決済、レビューなどサイトの根幹機能 → 99.99% の可用性が必要（その分コストも高い）

• Tier 2
  パーソナライズやレコメンドなど、重要だが “なくてもサイト自体は動く” 機能 → 99.9% 程度でも許容可

• Tier 3
  あれば嬉しい付加価値機能 → さらに低い可用性でもよい

このように整理することで、「どのレベルの可用性を確保するために、いくらコストをかけるか」という議論を、ビジネス側と共通言語で行えるようになります。
技術の話を、ビジネスにとって意味のあるストーリーに翻訳する力 が求められているのだと思います。

Spec-Driven Development（SDD）

AWS のシニアプリンシパル開発者 Claire Liguori 氏（Kiro チーム）がゲスト登壇し、AI 時代の曖昧な “Vibe coding” を乗り越えるために生まれた Spec-Driven Development（SDD） を紹介しました。

• いきなりざっくりしたプロンプトで AI にコードを書かせるのではなく、

• まず AI と一緒に Requirements / Designs / Tasks といった仕様の素案を作る

• 人間がその仕様を精査・修正し、十分に明確になってからコード生成に進む

このワークフローを導入した結果、Kiro IDE の開発チームでは「なんとなくプロンプトを書く」従来のやり方に比べて、約半分の時間で新機能をリリースできたとのことです。

仕様を書くという “ひと手間” が、結果的に開発速度を上げる。

AI 時代だからこそ、人間側のコミュニケーション精度がこれまで以上に重要になる、という良い例だと感じました。

プロトタイピングの重要性

また、Werner はプロトタイピングの話にも触れました。

• アイデアは頭の中にあるだけでは意味がない

• ラフでもいいので動くものを作り、早くフィードバックをもらう

• AI の力を借りれば、試作→フィードバックのサイクルをこれまで以上に高速に回せる

AI によって「作る」コストが下がった時代だからこそ、素早く作って見せて、対話を深めるためのプロトタイプ がますます価値を持つようになるのだと思います。

4) オーナーである（Owner）

4 つ目は オーナーシップ です。

ツールがどれだけ高度になっても、
成果物の責任は開発者自身が負う。

AI が自動生成したコードに不具合や法令違反があったとしても、「AI がやったことだから…」とは言えません。出荷したコードに対する責任は、最終的には人間にあります。

Werner は、AI 時代の開発者が直面する課題として特に次の 2 点を挙げました。

1. Verification debt（検証の深さ）

   • AI は一瞬で大量のコードを生成するが、人間が理解して検証するには時間がかかる

   • 誰もきちんと把握しないまま本番環境に進んでしまうリスクが高まる

2. Hallucination（ハルシネーション）

   • もっともらしいが完全に誤ったコードや設計を自信満々に提示してくる

   • 存在しない API をでっち上げる／現実には動かないアーキテクチャを提案する など

これらに対処するには、「気合」や「良心」だけでは足りません。
Werner は、継続的に良い結果を出すには属人的努力ではなく 仕組み（Mechanisms） が必要だと強調しました。

メカニズムの例：アンドン・コード

例として紹介されたのが、Amazon 創業者 Jeff Bezos 氏による「アンドン・コード」の話です。

• ある家具製品で購入者の 7 割が「破損品」として返品していることに、カスタマーサービスが気づいた

• 原因は配送業者の梱包不良だったが、問題は長く放置されていた

• Bezos 氏は、トヨタの生産ラインを参考に、現場が商品を一時販売停止できる「アンドン・コード」を導入

• ボタンが押されるとアラートが鳴り、原因究明と改善が完了するまでその商品は購入不可となる

ポイントは、「問題に気づいた人がすぐに止められる仕組み」を組織として用意したことです。

ソフトウェア開発におけるメカニズム

ソフトウェア開発でも同様に、品質を支えるメカニズムが重要です。

• S3 チームの Durability Review（耐久性レビュー）

  • 耐久性に影響し得る変更を行う際には必ずレビューを実施

  • 起こりうる脅威をすべて洗い出し、リスクをモデル化して対策を検討

• コードレビュー

  • AI がコードを書く世界だからこそ、最後の人間によるチェックポイントとして重要性が増す

  • 単なるバグ探しではなく、知識移転と人材育成の場 として位置づける

特に印象的だったのは、

「AI がコードを書く世界だからこそ、コードレビューがこれまで以上に重要なコントロールポイントになる」

という一言でした。

要するに、

「作ったものは自分のもの」 という強い当事者意識と、
それを支える組織的なメカニズムを持つこと

これが AI 時代の開発者に求められるオーナーシップだと言えます。

5) ポリマスになる（Polymath）

最後の資質は ポリマス（Polymath）、つまり「多才／博学」であることです。

Werner が推奨するのは、深い専門性（I 字） × 広い知識の幅（－）を持つ T 字型の開発者 です。

• フロントエンドが専門でも、DB やインフラの知識があれば、自分の変更がシステム全体に与える影響を理解できる

• バックエンドの専門家でも、UX やビジネスの知見があれば、プロダクトの方向性についてよりよい判断ができる

こうした「幅」を持つことで、

• 全体最適なアーキテクチャの意思決定ができる

• 異なる領域の知識を組み合わせた新しいアイデアを生み出せる

まさにルネサンス期の巨人たちがそうであったように、現代の開発者も 1 つのドメインでの深さ × 多くのドメインにまたがる幅 を持つことで、AI 時代において真に価値ある成果を出せる「ルネサンス開発者」になれる——というメッセージでした。

見えないところで“正しくやる”

Werner は、運用の卓越性（Operational Excellence）を プロとしての誇り と重ね合わせて語りました。

• ユーザーの目に触れない、夜通し止まらないシステム

• 静かにロールアウトし、問題があれば静かにロールバックする運用

• 誰も見ていないときでも、正しいことをやり続ける姿勢

これらは表彰されることもニュースになることもありませんが、最高のビルダーを定義する要素 だと言います。

最後は恒例のメッセージ：

“Have pride in your work.”

開発者一人ひとりの仕事への誇りを尊重してきた Werner らしい締めくくりでした。

感想

専門性の深さを磨きながらも、専門外の領域にも好奇心を向けること。
耳にすると “当たり前” に聞こえるメッセージですが、次の技術の波が来たときに、基本へ立ち返って時代に適応できるかどうか がキャリアを分ける——そう強く感じました。

特に心に残ったのは、

• 「成長は不安の淵で起こる」という Andy Warfield の記事

• 「AI はあなたの仕事を奪うか？」ではなく、「あなたは進化し続けるか？」という問い

です。

私自身も、「進化し続けること」を言葉だけでなく行動で示していきたいと感じました。

さいごに

Werner の最後の一言は、シンプルに：

“Werner, out.”

次の世代にバトンを渡しつつも、
開発者の誇りと、進化し続ける勇気を残してくれたクロージングでした。

YOUR CURIOSITY + YOUR SKILLS = WORLD-CHANGING
この言葉を、この一年、自分自身の行動指針としていきたいと思います。

Werner、本当に長い間ありがとうございました。
この基調講演は、きっと何年経っても色あせることなく、次の世代のビルダーたちにも語り継がれていくことでしょう。

動画リンク

基調講演の動画はこちらです（英語）：

https://youtu.be/3Y1G9najGiI?si=Lr2JIEoZE9PY9v1D

※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。