はじめに

AWS re:Invent 2025 の Keynote にて、Amazon.com CTO の Dr. Werner Vogels は自身最後となる登壇で、AI という荒波の中を進む開発者に向けて「Renaissance Developer（ルネサンス・デベロッパー）」という指針を示しました。 セッションの締めくくりには、世界中の開発者に向けた、非常に印象的なメッセージも語られています。

私自身、深く心を動かされた Keynote でした。本来であればぜひ動画そのものをご覧いただきたいところですが、1時間16分というボリュームがあるため、本記事では、AI を活用して要約した内容を掲載します。
ぜひ本編動画とあわせてご活用ください。

Keynoteの動画はこちら。
https://youtu.be/3Y1G9najGiI

全文を確認したい場合は以下の記事もご覧いただくとよいかと思います。
https://zenn.dev/kiiwami/articles/0a7e4f918c9a129b

要約

今回が最後のKeynote登壇

2012年から14年間にわたり、AWS re:Inventのステージで開発者たちを鼓舞し続けてきたAmazon CTO、Werner Vogels。

今年のキーノートは、ひとつの時代の終わりを告げる、衝撃的な言葉から始まりました。

"But today this streak ends. This is my final re:Invent keynote."
（しかし今日、この連続記録は終わります。これが、私の最後の re:Invent キーノートです。）

彼はAmazonを去るわけではありません。しかし、「若く、新鮮な声」にステージを譲る時が来たと語りました。

1. AIは私たちを「時代遅れ」にするのか？

世界中のエンジニアが今、抱えている不安。「AIは私の仕事を奪うのか？（Will AI take my job?）」。

Wernerはこの問いに対し、一部のタスクが自動化されることを認めた上で、質問をこう再定義しました。「AIは、私自身を時代遅れにしてしまうのか？」と。

その答えは力強く、明確です。

"Will AI make me obsolete? Absolutely not. If you evolve."
（AIは私を時代遅れにするのか？ その答えは、“絶対にノー”です。もし、あなたが進化し続けるのであれば。）

アセンブラからCOBOL、オブジェクト指向、クラウドへ。ツールやアーキテクチャは常に変わり続けてきました。しかし、「価値を生むビルダー」という私たちの役割が変わったことは一度もありません。

"The work is yours, not the tools."
（仕事はあなたのものです。ツールの仕事ではありません。）

AIやクラウドはあくまで 「道具（ツール）」 に過ぎません。
それらを組み合わせ、現実世界の複雑な問題を解き明かすのは、AIではなく開発者自身です。

2. 「ルネサンス・デベロッパー」：AI時代を生き抜く5つの資質

Wernerは現在の状況を、かつての「ルネサンス期」に重ね合わせました。
宇宙開発、AI、ロボティクス。複数の黄金時代が同時に進行し、アートとサイエンスが融合して爆発的な進化を生んでいる今こそ、私たちは 「ルネサンス・デベロッパー」 になるべきだと提唱します。

彼が挙げた「ルネサンス・デベロッパー」の5つの資質。それは、これからの時代を生き抜くための必須スキルです。

① 好奇心 (Curiosity)：快適な場所から飛び出し、外の世界へ

変化の速い世界で唯一のエンジンとなるのが「好奇心」です。
Wernerは、すべての開発者には「何かを分解して、それがどう動くのかを見てみたい」という本能があると言います。

そこにあるのは、理解したい、改善したい、構築したいという純粋な欲求です。
彼は、この 「本能を守り抜け（Protect that instinct）」 と強く訴えました。 なぜなら、好奇心こそが学習と発明につながるからです。

"An experiment is not an experiment If you already know the outcome."
（結果がすでにわかっているなら、それは実験とは呼べません。）

ダ・ヴィンチの「飛べなかった飛行機」のように、失敗は恥ずべきことではなく、学習のプロセスそのものです。
彼は言語学習を例に挙げました。文法書を延々と読むよりも、会話に飛び込んで間違いを訂正される方が早く学べます。ソフトウェアも全く同じです。

"It is the failed builds and the broken assumptions that really teach you how a system behaves."
（ドキュメントをいくら読んでも、システムの本当の挙動を教えてくれるのは、「失敗したビルド」であり、「裏切られた前提」なのです。）

また、彼はストレスとパフォーマンスの関係を示す「ヤーキーズ・ドットソンの法則」にも触れました。
プレッシャーがなさすぎれば退屈し、ありすぎれば圧倒されます。目指すべきは、その中間にある 「好奇心と挑戦が出会うスイートスポット」 です。快適な椅子に座っているだけでは、そこへは到達できません。

そして、学習は「認知的」なだけでなく、「社会的」なものでもあります。
Wernerは、"Touch the glass"（外の世界に触れろ） と表現しました。
部屋に閉じこもって一人で学ぶだけではなく、いつもの環境を抜け出し、ユーザーグループに参加し、友人とコーヒーを飲みながらシステムについて語り合うこと。

"One of the best ways to stay sharp is to be around other people who are building things."
（感覚を鋭く保つための最良の方法の一つは、モノを作っている他の人たちのそばにいることです。）

Werner自身も、世界中を旅して顧客と会うことで、自分たちが想像した使い方ではなく、「実際にテクノロジーがどう使われているか」を学び続けていると語りました。
好奇心を持って外に出ること。それこそがルネサンス・デベロッパーの源泉です。

② システム思考 (Think in Systems)：リトライポリシーひとつが全体を変える

「イエローストーン国立公園のオオカミ」の話が印象的でした。
かつてオオカミを駆除したことで生態系が崩れましたが、再導入すると植生が回復し、「川の流れ（コース）さえも変わった」 という事例です。たった一種の捕食者が戻っただけで、地形というシステム全体が変容したのです。

これは日々の開発業務でも同じです。
例えば、「リトライポリシーを変更する」 という小さな修正が、システム全体の負荷を変え、予期せぬ障害を引き起こすことがあります。
キャッシュの追加ひとつが、トラフィックフローを劇的に変えてしまうこともあります。

"The Renaissance Developer thinks in systems."
（ルネサンス開発者は、システムとして考えます。）

システムは単なるパーツの寄せ集めではなく、「フィードバックループ」 によって形作られます。
AIがコードを書く時代だからこそ、部分最適ではなく、相互作用を含めた全体を俯瞰する「システム思考」がこれまで以上に重要になります。

Wernerは、この思考法を学ぶために、ドネラ・メドウズの論文『Leverage Points』を読むことを、私たちへの「宿題」として課しました。
https://www.donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/

③ コミュニケーション (Communicate)：曖昧なプロンプトを捨て、仕様を書く

Wernerは、エンジニアや技術リーダーがキャリアのために実践できる 「最も重要なことの一つ」 が、強力なコミュニケーションスキルを磨くことだと語りました。

例えば、システムの重要度を「Tier 1（必須機能）」や「Tier 3（あれば良い機能）」に分類することは、単なる技術的な設計ではなく、ビジネスサイドと「コストと可用性のトレードオフ」を議論するための共通言語になります。
エンジニアは、技術用語ではなくビジネスの言葉でシステムを語る必要があります。

そして、この「正確に伝える力」は、対AIにおいても同様に求められます。

Wernerは、私たちがこれまでプログラミング言語という「厳密な言葉」で機械と対話してきましたが、AI時代には「自然言語」という曖昧な言葉で指示を出さなければならないジレンマを指摘しました。
この曖昧さを排除し、AIに意図を正確に伝えるためのメカニズムこそが 「仕様（Specifications）」 です。

ここで、Kiroチームのシニアプリンシパルデベロッパーである Clare Liguori氏 が登壇しました。
彼女は、Kiro IDEが生まれたきっかけは、彼女自身の「Vibe coding（雰囲気でのコーディング）」へのフラストレーションだったと明かしました。
AIに意図を伝えるためにプロンプトがどんどん長くなり、結果として「仕様書」のようなものを書いている自分に気づいたこと。それが 「Spec-driven Development（仕様駆動開発）」 の原点です。

彼女は、Kiro IDEを用いた具体的なワークフローを紹介しました。いきなりコードを書かせるのではなく、以下の3つのドキュメントを生成・合意するのです。

1. 要件 (Requirements)
2. 設計 (Designs)
3. タスク (Tasks)

実例として挙げられたのが「システム通知機能」の実装です。
当初、AIは「エージェントコードの中に通知システムを丸ごと作る」という 過剰に複雑な設計 を提案してきました。
しかし、設計ドキュメントの段階で人間が介入し、「IDEのネイティブAPIを使う」というシンプルな方針に修正したことで、手戻りを防ぎ、開発時間を半分に短縮できたのです。

"Natural language doesn't have to mean high ambiguity."
（自然言語だからといって、必ずしも高いあいまいさを抱えたままでいる必要はありません。）

④ オーナーシップ (Be an Owner)：なぜ今、コードレビューが「最強の学習」なのか

Wernerは、AI時代のエンジニアに対し、単にIDEのレバーを引いて「何か良いコードが出ることを祈る」ような態度は 「ソフトウェアエンジニアリングではなく、ギャンブルだ」 と強く戒めました。

そこで彼が指摘した最大の課題が 「Verification Depth（検証の深さ）」 です。

• 人間が書く場合： コードを書きながら理解が構築される（Comprehension comes with creation）。
• AIが書く場合： コードは一瞬で生成されるが、理解はゼロ。人間はレビュー時に理解を再構築しなければならない。

AIの生成スピードに人間の理解が追いつかないこのギャップにより、「誰も中身を理解していないコード」が本番環境に投入されるリスク が高まっています。

ここでWernerは、Amazon初期の「返品率70%のテーブル」のエピソードを紹介しました。
誰もが「不良品を売りたくない」という善意 を持っていたにも関わらず、問題は解決しませんでした。
解決したのは、トヨタ生産方式の 「アンドン・コード（Andon Cord）」に倣い、カスタマーサービスが販売を即座に停止できる「メカニズム」を導入した時です。

"Mechanisms convert good intentions into consistent outcomes."
（メカニズムは、善意を一貫した結果へと変換します。）

開発現場におけるメカニズムは、それぞれのチームの規模や仕事の性質に合わせて作られます。

• S3チームの事例：
  彼らは「耐久性」を祈るのではなく、変更のたびに 「Durability Reviews（耐久性レビュー）」 を行います。あらゆる障害モードをモデル化し、データを守るためのガードレールを設計するのです。
  これにより、耐久性は単なる「コードの属性」から、「組織の習慣」 へと変わります。

そして、私たちの最も身近にあるメカニズムが、コードレビュー です。

正直なところ、私たちはみんなコードレビューが嫌いです。それはまるで、12歳の時にクラスの前に立って発表させられているような気分にさせられます。
しかし、これこそが 「意図（Intent）」と「実装（Implementation）」が出会う瞬間 を作り出す、極めて重要なメカニズムなのです。

AI駆動の世界では、モデルは私たちが理解するよりも速くコードを生成します。だからこそ、レビューはバランスを取り戻すための制御ポイントになります。
ここで人間の判断をループに戻し、ソフトウェアが本当に期待通りに動くかを確認するのです。

Wernerは、人間同士のコードレビューをさらに増やすよう強く勧めました。

• シニアエンジニア： パターン認識と、苦労して得た判断力を持ち込む。
• ジュニアエンジニア： 新鮮な視点を持ち込み、ベテランが見落とす詳細を発見する。

AIは多くのことを変えるでしょう。しかし、知識はこのようにして継承され、クラフト（職人芸）は依然として人から人へと学ばれるもの なのです。

⑤ 博学者 (Become a Polymath)：T型人材へ

最後は「博学者（ポリマス）」であること。
Wernerは、自身のメンターであり友人の Jim Gray（チューリング賞受賞者） を例に挙げました。

ある時、Jimはサーバールームに入ってわずか30秒で出てきて、「データベースのレイアウトが間違っている」と指摘したそうです。ディスクのカタカタという音を聞いただけで、ランダムアクセスが多すぎることを直感的に見抜いたのです。
これは、数十年の経験から培われた圧倒的な「専門性の深さ」 を示すエピソードです。

しかし、Jimは単なる専門特化型の「I型」ではありませんでした。彼の好奇心はデータベースを遥かに超え、ビジネスや人々、そして幅広い技術をも理解していました。これこそが 「T型開発者」 です。

"Great developers are T-shaped."
（偉大な開発者はT型です。一つのドメインで深く、理解の幅は広いのです。）

例えば、データベース開発者が「フロントエンドのパフォーマンス」や「コスト」を理解していれば、自分の仕事がシステム全体をどう形作るかが見えるため、より良いアーキテクチャの選択ができます。
その幅広い知識こそが、構築するものを改善し、トレードオフを正しく判断するための視点を与えてくれるのです。

T型開発者は、この「深さ」と「幅」を巧みに組み合わせています。彼らは特定の問題に深く潜ることができますが、同時にそれがより大きなシステムにどのように適合するかも理解しています。

Wernerは私たちにこうアドバイスしました。

"Build both. Develop depth in your domain, but cultivate a range to connect to multiple disciplines and ideas."
（深さと幅の両方を構築してください。自分のドメインで深さを開発しながら、複数の分野やアイデアとつながるための幅を育ててください。）

「ルネサンス・デベロッパー」のまとめ

1. 好奇心を持ち続け、学び続けること (Be curious and keep learning)
2. システムとして考えること (Think in systems)
3. 精度高くコミュニケーションすること (Communicate with precision)
4. オーナーシップを持つこと (Be an owner / You build it, you own it)
5. 知識の幅を広げること (Expand your knowledge / Become a polymath)

5つの資質を挙げたあと、彼はこう締めくくりました。

"Then you'll have plenty of time next week to start putting all of this into practice."
（来週から、ぜひこのフレームワークを実際の仕事の中で試してみてください。）

3. 誰も見ていない場所での「誇り」

そして最後に、彼は一つだけ伝えたいことがあると語り始めました。それは、そうした開発者の仕事の「不可視性」についてです。

ユーザーはボタンをクリックし、荷物が届くという体験を享受します。しかし、その裏にあるカタログ管理、サプライチェーン、データベース、監視システム…それらを支える膨大な労力について、顧客が思いを馳せることはありません。

"Your customers are never going to tell you that."
（お客様がそのことについて、あなたに感謝を伝えることは決してないでしょう。「データベースエンジニアが良い仕事をしてくれた」なんて、誰も言わないのです。）

その苦労を理解できるのは、同じ開発者である私たちだけです。
夜通し動き続けるシステム、綺麗なデプロイメント、誰も気づかないうちに処理されたロールバック。

では、なぜ私たちはそれをやり続けるのでしょうか？ Wernerはその理由をこう断言しました。

"The only reason why we do this well is our own professional pride in operational excellence."
（私たちがそれを上手くやり続ける唯一の理由は、オペレーショナル・エクセレンス（運用の卓越性）に対する、私たち自身の「プロフェッショナルとしての誇り」があるからです。）

"That is what defines the best builders. They do the things properly even when nobody is watching."
（それこそが、最高のビルダーを定義するものです。彼らは、誰も見ていないときでさえ、物事を適切に行うのです。）

そして最後に、彼は会場、そして世界中の開発者に向けて語りかけました。

"And when I look at the work that you deliver every day, I see that commitment everywhere. So for that, I am immensely proud of you."
（みなさんが毎日届けている仕事を見ると、私はそのコミットメントをいたるところに感じます。だからこそ、私はみなさんのことを、信じられないほど誇りに思っています。）

"Thank you for all that you do."
（みなさんが成し遂げているすべてのことに、感謝します。）

2012年から14年間にわたり開発者を鼓舞し続け、今そのステージを「若く、新鮮な声」へと譲る男の、最後の言葉。

"Werner, out."